Oh well I really don’t like to make a topic about this problem (probably a very silly one).

I’ve been stuck for a couple of days with capture_nearest_instrument_from_pattern :(
I’m really confused - how is it supposed to work or what should it return?
Only thing I can get out of it is nil if I run this

captured_instrument =  

If someone could post a simple example of how it works I’d be really grateful.

Hi eeter.

capture_nearest_instrument_from_pattern is a “method” which is shown by the colon after It will do something and not necessarily return something to print.

If you run what you have posted in the test pad, you will see that on execution renoise will capture the nearest instrument from the pattern in the instrument list (presuming there is a song and instruments there etc.). It works as though you had used the renoise feature yourself [pressed shift+return] in a song.

according to the documentation, this function does not return anything: it should only perform the operation of capturing the instrument. It would be indeed reasonable to return the captured instrumet

It would be comfortable, but ain’t necessary.
Once you have executed that function, simply call the routine to fetch the currently selected instrument and you are done.

Perhaps, you need to add a notifier that watches instrument selection changes meanwhile, just for security reasons.

Thanks guys!
According to this false bug-report the Ledgers AutoCaptureFromFirstNote script was preventing the capture_nearest_instrument_from_pattern method to take effect. - And that’s why I was so confused in the first place.

But I got it now. Hmm… That makes things a bit bit more complicated for me. Would be great if there was a method to just get the nearest instrument index from anywhere you want and not depending on where’s the cursor at and not changing the selected instrument.

This may help, just paste into testpad and execute. It should print the index you want but not capture the instrument i.e. returns the selected instrument to the initial one:

local current_instrument = --get current index --capture  
local captured_index = --get captured index  
 print(captured_index) = current_instrument --return to initial instrument  

Edit: though I am not quite sure what you mean by “not depending on where’s the cursor at” as the capture depends on this? i.e. how would it know what instrument you are after?

edit 2: if you mean to work similarly to my autocapture script, then you need to do this with a track iterator.

I think he rather means that the instrument is not selected but simply an instrument index is returned.

In that case you indeed need to create your own instrument catcher by simply scanning the lines around the cursor using a track-iterator.

Indeed. But the snippet he gave was really useful though.
To accomplish what I’m up to I guess I have to just scan the whole song line by line, pattern by pattern, track by track and column by column and then collect all the instrument data to a table… Let’s see. I hope it won’t become too slow. I just wished there was a better way to do it.

The whole song?
I believe even the internal routine does not scan further than the current pattern…
If it would have to extent song-wise, i would go no further than the current track.
Also don’t forget to check if a subcolumn is visible or hidden. Note-data in hidden subcolumns are still readable by scripts and may cause confusion if you don’t know that the script has processed hidden data.

@ eeter is it possible to say exactly what you are trying to achieve with your script or is it something you do not wish to disclose?

it could be easier to point you in a useful direction and save you a bit (or maybe a lot) of time.

Sorry it took so long to reply.
Here’s the core of what I wanted to do. It finds and stores all the instrument indexes which are used on a track from whole song. Beginner as I am this code really sucks and it’s slow. So better test it on some shorter song ;)
There’s also a bug which I haven’t figured out yet how to avoid it - when there’s no note data on the first pattern on a track it just adds the selected instrument index."Processing... Please wait...")  
local tracks =  
local track_count = table.getn(tracks)  
local instruments =  
local patterns =  
local current_track =  
local current_instrument =  
local current_note_column =  
local current_pattern =  
local current_line =  
local line_step = 4  
local tracks_and_instruments = {}  
for i, v in ipairs(tracks) do  
 if tracks[i].visible_note_columns > 0 then = i   
 table.insert(tracks_and_instruments, i)  
 tracks_and_instruments[i] = {}  
 for i, v in ipairs(patterns) do = i  
 for i=1,, 1 do = i  
 for i=1,, 2 do -- line step = 2 = i  
---################## Collecting data to tracks_and_instruments  
 local selected_instrument =  
 local instrument_belongs_to_track_already = false  
 local no_instruments_found_yet = true  
-- detecting if instrument belongs to the track already, to avoid adding it twice  
 for i=0, table.getn(tracks_and_instruments[]) , 1 do  
 if instrument_belongs_to_track_already == false then  
 if tracks_and_instruments[][i] == selected_instrument then  
 instrument_belongs_to_track_already = true  
-- Adding a new entry to table tracks_and_instruments if the instrument doesn't belong to the track  
 if instrument_belongs_to_track_already == false then  
 table.insert(tracks_and_instruments[], selected_instrument)  
---################### End of collecting data to tracks_and_instruments  
-- Restoring the position = current_track = current_instrument = current_note_column = current_pattern = current_line  

I hope you guys have some ideas and can help me out a bit here.
And make sure you tell me if I’m doing something terribly wrong :)

Well for starters you could replace this line:
local current_instrument =
local current_instrument = -1

Then when you are working with your routines, you need to insert conditions to check if the current instrument is actually filled in or not before processing any specific data.
If you don’t use these conditions, you get errors pretty quickly but these errors allow you to get some insight on what goes exactly wrong where in your code.