[Tool Idea] Param Predictor (working prototypes attached)

Renoise Tools
3

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:

Currently this is what we have

  
  
class: DeviceParameter  
 properties:  
 is_automatable  
 is_automated  
 is_automated_observable  
 is_midi_mapped  
 is_midi_mapped_observable  
 name  
 polarity  
 show_in_mixer  
 show_in_mixer_observable  
 time_quantum  
 value  
 value_default  
 value_max  
 value_min  
 value_observable  
 value_quantum  
 value_string  
 value_string_observable  
 methods:  
 __STRICT  
 record_value

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.

4

Good stuff vV, but we do know the index. It’s i

  
for i = 1, param_count do  
 data[i] = plugin.parameters[i].value  
end

In your example it’s [x]. The order won’t change.

For sure there are limitations, but with clever hacks and motivation someone could certainly build something useful if they tried?

5

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

6

Well, I hope someone builds it up to the most usable point, then whatever is missing could be added to the API with concrete demands.

Prototyping by numbers.

Might even be me, but probably not though as I am a bit swamped these days. Also, an asshole.

7

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.

8

My brand!

I disagree? Try it.

[s]Attachment 3885 not found.

EDIT: Keep scrolling, this sucks compared to what is next.

TODO:

  • Will crash if you change the instrument out from under it.
  • Make this better.
  • I will not work on this anymore. I just wanted to show it’s not bad the way I described it. Tag, someone else is it.
9

I’ve been thinking about midi learning too.

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”.

Why shouldn’t it work?

10

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.

11

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.

12

That’s odd. It works for me. Oh well.

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).

But yeah, improvements welcome.

Cheers.

13

Okay Dac,

Here’s one using the parameter notifiers.

http://www.renoise.com/tools/getpluginparams

5cecYzo.png1097×679

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.

14

Hey! Great work VV.

I edited the first post to mention this.

15

Bug, sort of.

I don’t have any good plugins, so just imagine this one has a thousand parameters with crappy names.

Attachment 3891 not found.

  • Red indicates what is always moving, ie. Mid Freq.
  • Turquoise indicates params I’m moving by hand.

Expected: Selected param in dropdown changes.
Actual: It’s always showing Midi Freq.

The tool should be able to ignore params that are constantly moving, and throw the data away as uninteresting.

Good times.

16

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?

17

Tried it. Mute works great. Cheers!

18

This is a great tool Thanks, I know its not possible by scripting but it should be part of the vst window itself between keyboard and random.

19

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.

20

Still loving this tool!!

21

I’ve just remembered that I had shoehorned in automatic mapping to Instrument Automation Device, so no need for searching the list anymore

wow this is awesome!

22

It’s also in tuned shortcuts tool with the most complete implementation, AFAIK: https://forum.renoise.com/t/topic/43378

Simply move any handle in the vsti -> automation device is auto setuped. No additional gui involved.