Also known as Midi learn, but this tool doesn’t require Midi IMHO.
Idea taken from here. It would be cool if instead of looking for a parameter through a menu (some vsti have awfull lot of different parameters) you could have a tool tell you what parameter you are moving. You’d just hit a button named [Go] or [Learn], move the knob, and your parameter would be highlighted in the list of parameters.
One approach could be to take a snapshot of all the values of plugin_properties by iterating over ‘parameters’. Then, the user clicks a Lua button that says [Go]. Then, when you move a knob one of the plugin_properties will have changed and all the others would not have changed. With that data, you can easily conclude that “Param365” was turned.
Problem: Sometimes you have an oscillator that constantly shifts values. You could compensate for this by taking a dozen snapshots when the user presses [Go]. Then you see: analyzing. Then: ready. Then: User moves a knob. Anything that was already changing is disregarded from the data set.
Highlighting is probably not possible, but displaying the name certainly is.
Some code to get someone else started. A lot more todo but the concept is sound IMHO.
local data = table.create()
local selected = renoise.song().selected_instrument
local plugin = selected.plugin_properties.plugin_device
if (plugin == nil ) then
renoise.app():show_message("Invalid selection. No plugin here!")
return
end
local param_count = #plugin.parameters
for i = 1, param_count do
data[i] = plugin.parameters[i].value
end
-- Your data set:
-- rprint(data)
-- TODO:
-- A loop in a renoise.tool().app_idle_observable, compare to data, when found do:
--[[
for i = 1, param_count do
if data[i] ~= plugin.parameters[i].value then
found = i
break
end
end
]]---
local j = found;
renoise.app():show_message( "You moved the " .. plugin.parameters[j].name .. " parameter.")
-- Teardown app_idle_observable, etc.
Nice start.
Some things may be possible, but not in all cases.
With the effect plugins, i suspect stuff is possible. you could figure out which parameter you are changing in the Fx plugin editor and allow a user to make the parameter "visible"in the mixer.
Even though the is_automatable parameter is read-only, this way, one can at least tag parameters for automation by rightclicking on them in the mixer-view because we can influence if parameters are shown or hidden in the mixer view.
With instrument plugins, we have a pretty serious problem because we lack two two fundamental aspects for the instrument automation device in the current API.
Just to continue on your above suggestion, i once created this snippet right after i released the pitch device plugin:
function get_active_instrument_parameters()
local sng = renoise.song()
local cur_ins = sng.selected_instrument_index
if sng.instruments[cur_ins].plugin_properties.plugin_loaded == false then
return -1
end
local vsti_parameters = sng.instruments[cur_ins].plugin_properties.plugin_device.parameters
for x = 1, #vsti_parameters do
local func_ref = 'i'..tostring(cur_ins)..'p'..tostring(x)
if device_notifiers[func_ref] == nil then
device_notifiers[func_ref] = function()
local ins_name = sng.instruments[cur_ins].name
local title = vsti_parameters[x].name
local parvalue = vsti_parameters[x].value_string
local message = "Instrument ["..ins_name.."] is changing parameter #"..tostring(x).." ["..title..
"] with value ["..parvalue.."]."
renoise.app():show_status(message)
end
end
if not vsti_parameters[x].value_observable:has_notifier(device_notifiers[func_ref]) then
vsti_parameters[x].value_observable:add_notifier(device_notifiers[func_ref])
end
end
end
renoise.tool():add_menu_entry {
name = "Main Menu:Tools:show plugin parameters",
invoke = get_active_instrument_parameters
}
In the above case we speak of figuring out which parameter of VSTI plugin X we need. The only way we can do some figuring out is if we can control the Inst. automation device in more details
There are however two problems that we as scripters can’t overcome here.
Problem one:We cannot change the selected parameter link in the instr. automation device
Problem two:We cannot find out which parameters are exactly linked to the vsti instrument.
And what do i mean with problem two? Well the parameters in the instrument automation device don’t have a relative link number, only a name, but the name won’t help us as this painful screenshot illustrates:
We lack a parameter index (which parameter number of that plugin is frankly selected?) to do the actual comparing with what we got back from the parameter notifier of the vsti plugin that we are monitoring.
And we also need this index to be read/write enabled, else we won’t be able to program the instr. automation device for the user.
So if the instr. automation device would be expanded with that one editable property, we can script a parameter-learning system for vsti plugins.
Owhyeah, ofcourse, we need to know which plugin is linked, so also the linked instrument index needs to be available for reading and writing.
In the plugin parameters, yes we have the index.
But on the instrument automation device (we are still trying to find the right VSTI parameter to automate), what is the current index-value of the dropdown of parameter x?
We can read its name and its value. but that’s it. We can’t alter it, we can’t match it.
Ofcourse, our code snippets are already helpful for a lot of plugins that have very cryptic parameter names and in that regard you may be able to find them, as long as their name is really unique.
But voyager has quite a few parameters called “Lfo1 → Pitch”, if you have to look that up in the instrument automation device, which one to take? The code snippets above tells someone it is for example parameter #563, but are you going to scroll down and count up to 563 manually?
You will of course perform an educated guess and pick one of the lower copies instead of the top options. But still not really user-friendly, specially not if a plugin has thousands of those
I like this idea, but IMHO it would need another approach than statistical sampling and educated guesses.
WHAT IF
The tool came with a dialog that automatically got populated with any & all parameters that were modified for the currently selected device, since the dialog got opened.
Then, using your (special) eyes you could easily determine which one was the knob you were currently twiddling.
The parameter index of Instr. Automation seems to match the parameter index of the VSTi instrument, so I don’t see the problem there?
My idea was to temporarily add notifiers to all parameters of a VST (not the ones already automated or controlled). Sometimes a plugin can have tons of parameters, so interpreting .active_preset_data and using a fake notifier loop could possibly be an option.
Then add the menu in the context menu of Instr. Automation: “Learn parameter #no”.
The instr. automation device is limited to support only 35 parameters of a VSTI plugin. The first 35 will naturally match the first 35 ones of the linked VSTI plugin. However if you want to control a parameter beyond those first 35, you need to manually adjust one or more of those first 35 parameters.
And if these matches are manually changed, your script fails in matching if it assumes parameter 1 of the inst. automation device would be linked to parameter #1 of the vsti, after somebody altered the choice.
If you do can check this, I so far failed to find any API call that allows me to scan these parameter indexes (in the instr. automation device!) and adjust them in that device because then my parameter learn tool would have been finished for a long time.
You can’t check which VSTI plugin is linked to which instr. automation device in Lua.
This means you can’t alter that option either.
Again here:if somebody found an API reference, let me know, i haven’t been able to find the option myself.
I just did - it display a dialog, and hangs until a script timeout occurs.
Fresh install of Renoise with a (take a deep breath) selected instrument/instance of Synth1 with an Instr. Automation device attached to it, on an (also selected) track.
Anyway, I really like the idea of a smart MIDI learn. If the issues mentioned by vV are ironed out, it could become truly great.
I was mostly talking about visual feedback. If you get this script working you will get visual feedback on your last modified knob in a dialogue box. If you turn 10 knobs it will tell you the 10 in the order that you turned them. The feedback will continue until you close the dialogue box.
I’m saying, assuming there is something to show and not — like in Vv’s screenshot, that this is quite sufficient information. There’s no reason to overengineer this with some Franken interface. The whole goal at the end of this is that there is no interface. The only reason we do an interface right now is because we can’t select items in the dropdown using Lua (yet).
This one works for both DSP plugins and VST instruments.
It will automatically pop up the external editor if one is available.
Rightclick either on the DSP effect, mixer area or automation list or the instrument slots.
Depending on which area is clicked it will automatically select the DSP or VSTI learner mode.
The show in mixer button turns active in DSP mode only. in DSP mode it will also indicate parameters whether they are automated, midi mapped or combined.
Midi mapped: no parameter name
Automated : ^no^ parameter name
both:^no* parameter name
No attachments:[no] parameter name
Currently nothing much possible with the Instr. automation device. I hope the devs would save us the hassle of using extra API calls and simply abuse this starter-snippet to add a learn and attach functionality in those devices and dsp frames themselves.
Another suggestion i would like to make is to add a view-trigger to only show the parameters that one learned (if an external GUI is available!). And if the DSP would be expanded to two columns, a horizontal scroller would allow to scroll through all the parameters rather than that we have to scroll through the whole DSP chain, perhaps even missing the end of the DSP parameter list of that DSP plugin with 5000+ parameters. Just to give DSP parameter fields a more comprehensive birds-eye view.
Ofcourse it is, the LFO is consequently triggering the Mid-Freq parameter. If you would be fast enough, you would be able to somehow review the parameters that you are manually triggering among them, but the tool cannot (well will not) distinguish what is modified by hand or a meta device.
Added a (un)mute button now so you can exclude the specific parameter for listening.
Would that suffice?
I’ve just remembered that I had shoehorned in automatic mapping to Instrument Automation Device, so no need for searching the list anymore. be warned: bugs and limitations.
