Q:how?: Re-Enable Line-In Devices After Panic()

Renoise Tool Development Beginners Lua API Sandbox
1

Hi. if I’ve got 4 line-input devices which are all playing some sounds, and I use the renoise.song().transport:panic() - they all shut up and everything stops. This is exactly how it’s nice to have it. But what would I be able to do to be able to re-enable them? A quick bypass/re-enable?

… Ok, continuing onwards, got the bypass/re-enable working for “selected_track”.
What would be the best method of cycling through all the tracks of the song and making sure that somewhere along the track devices there is a #Line in Device and then catching the number of that and bypass+enable?

I know it could probably be done bruteforce with (table.count(renoise.song().selected_track.devices)) and cycling through 2 - last number for each audiotrack available, but it seems that this would be a slow method, wouldn’t it?

2

I’ve tried to look at this but I suppose 4.42am is not the time to do more than start the creation of one.

renoise.tool():add_keybinding{name="Global:Paketti:Re-Enable Line-In Devices on All Tracks", invoke=function()  
for i=1,renoise.song().sequencer_track_count do  
if (table.count(renoise.song().tracks[i].devices)) >1 then  
if renoise.song().tracks[i].devices[2].name=="#Line Input" then   
renoise.song().tracks[i].devices[2].is_active=false  
renoise.song().tracks[i].devices[2].is_active=true  
end  
else end  
end  
renoise.song().selected_track.devices[2].is_active=false  
renoise.song().selected_track.devices[2].is_active=true  
  
  
end}

At first I thought it was working, but then quickly realized that only the current track was enabled via selected_track.

----- time passes
And why didn’t it work? Because I had changed the name of the shortcut and that had caused the script to become unkeybound.
This works for when the Line in device is the first effect on the track.
And it works nicely. For, you see, I just spent a bit of time fixing my VST / AU efx, Native EFX loading to recognize if there’s an effect on the track - if there’s an effect on the track they check if the name is #Line in Device - if it is, the efx are hard-wired to appear to 3 instead of 2 (where the line in device is).

This, coupled in with the create_midi_instrument+create_line_input_device_using_preset_for_midi_instrument_audio_channel scripting just leaves that sample recorder thingy nondone :)

3

But is there a way of going through each track and identifying these line in devices and enabling and bypassing them, instead of having multiple for loops which tend to make it fairly slow…

4

Enumerate the DSP devices for each device insertion or removal upon a track (using a notifier for device insertion/removal) and store the detected line in device number locations inside a table.
Then you know which device exactly you need to reset after a panic without having to do this enumeration constantly for all tracks.

5

Can you explain what “enumerate the dsp devices” means? I only use a shortcut to create a #line-in-device, so i suppose it’d be easy to add a notifier for the addition of a specifically named + presetted line-in-device, and then read the notifier and if the notifier is set, remove the line-in device which has the notifier designed to be for a specific set of input channels.

6

That might also work.

7

Would this be the snappiest if I tried to think of it from the point of view of having a table with four entries inside it?

{1, 0, 1, 0} – in this case, this 4 entry table would signify that the first entry on the table is the first input, second is the second, third is the third and fourth is the fourth, with 1 being “enabled” and 0 of course being “not present”. When a line-input device for a specific input out of these 4 is created, the table-entry is changed. When creating a new one, the creation script consults the table, and if it is 1, the script then launches a track-wide search for #line input device (set to preset x = which calls the required line-input settings), remove the notifier, remove the line-in device, and then place the a new line-in device (with preset x loaded) to the selected_track_index.

While I was writing this fairly convoluted sentence, it just made me wonder - is there a “:move_device” kind of a thing? that would make things very simple. actually, even just bypassing the currently_in_use device if it is the device of the same name… would be easy.
From previous scripting (yeah, this is pretty hardcoded), I know that the shortcut for creating a line-input device for any of these 4 inputs will insert the input device to devices-slot [2]. therefore it would be quite easy to go through the track index amounts and just bypass the one which has the specific preset.

You know, having an understanding of preferences, and tables (which i somehow seem to regard as a kind of a preferences, a kind of a memory which can be put back (retaining, for instance, the original bpm + lpb of the song while altering both bpm+lpb - then when the same shortcut/midi_button is pressed, calling back the original bpm+lpb of the song, instructing transport with those numbers, and wiping the table?

8

Line In Device may not always be first device, especially if you have LFOs, MIDI Control or other Meta Devices that could quite easily sit before it and not effect anything.

Not 100% sure what you are trying to do but it seems you want to keep a table of which tracks have a line-in device and what position they are in, correct?

As vV says why not have a table of size=active number of tracks. If there is no Line-In Device then enter 0 into the table, if there is a Line-In Device then enter in its position in the DSP chain. Iterating for values other than 0 in this table should be easy (or a For Loop.)

Now how is Panic Mode disabling them? Is it just a matter of setting the Is_Active flag to True or do you have to do something more? Looks like you can set the active preset (load a preset) from the API but if you are likely only to need to set correct Input maybe it would be better to save relevant parameters in a second (or a nested) table?

9

Line in is always the first device. Why? Because I’ve made it so that everytime I add Line-in device it is added as the first device.

10

Nope. I already know where the line-in device will be. It’s always in devices[2].

Hmm, now, this is interesting. The table size would then be set by total track_index. Using a table for all the tracks would make it very simple. If all the portions of the table of a 27 track song are set to 0, then there are no line-in devices in the song. If a Line-In device is added with Shift-I, then the 27 entry containing table has one of the entries switch to 1 or whichever number theline in will be at. then if one wishes to add the same line-in device to a second track, the track which has 1 on the table will get a removal request fromthe script before the script adds the line-in device to the selected_track.
i can understand why your approach requires you to use the number on the table for actual positioning of the line-in device, but if the line-in device is always at [2], then that frees the table to signify which type of line-in device there is.
0 for nothing, 1 for linein1, 2 for linein2, 3 for linein3, 4 for linein4 (im only simplifying, since linein1 is actually preset=5, linein2 is actually preset=6, but that’s beside the point)…
that way the table can be used to discover which track_index has a line-in-preset4 in it, and then just send that info. i guess the table itself could be called to provide the track_index?

It’s just a case of bypassing and enabling them with a script after panic. I’m not sure what will happen if I make a panic-shortcut which does panic and then immediately bypasses (this has to be done, i tested it) and then enables them for them to start working. It’s hard to know until you try it in actual, non-theoretical conditions.

There’s something about #Line-In Device. It has two parameters. None of which are the input.

>>> rprint (renoise.song().selected_track.devices[2].name)  
#Line Input  
>>> rprint (renoise.song().selected_track.devices[2].parameters)  
[1] => userdata: 0x0x2609cb94 (DeviceParameter object)  
[2] => userdata: 0x0x2609cc64 (DeviceParameter object)  
>>> rprint (renoise.song().selected_track.devices[2].parameters[1].name)  
Panning  
>>> rprint   
Volume

When I encounter Track DSP Devices which do not have all their parameters available to be controlled by the Renoise API, such as #Line Input Device (Channel, Input, Latency unavailable), DC Offset (Auto DC On/Off unavailable), #MultiBand Send Device (Keep, Send Channel unavailable)… There are others. Suffice it to say that when thse are encountered, I’m really happy for the possibility of saving a preset and loading it with scriptage, since telling the device what to do is not (yet) possible. Suffice it to say that I will, in my scripts, always use direct parameter changes from the script instead of preset-loading, if they are available in the track dsp device. If not, it’ll be back to preset-loading, or in some cases, using the “Save Init” script to, for instance, change MultibandSend & Send to have specific things toggled by default.

When I then encounter the Sample_Recorder Window dialogue and realize that it’s Channel, Input, sync start&stop, record dry, create a new instrument on each take, compenstate input & output latencies, extra latency ms cannot be controlled via lua API, I’m filled with hope that these things will change. I believe it is the fundamental nature of APIs to be improved over time and for new API functions to be added in future iterations.

11

Contents of my post still stands just means you can change the number with Boolean in the table and that if True then it will always be devices[2] rather than using the contents from the table as position of the device.

(EDIT: If not Is.)

12

That doesn’t mean the user can’t interrupt to move the line-in device to another spot.
Never assume things will always remain the way you set them up. For you personally perhaps, but this may not be clear to anyone else using the script.
If the user moves the line-in devices position to some other point in the DSP chain, you need to also re-enumerate the devices on that track.