…VSTis? (looks like it cut off my topic title, heheh)
Often times I’m messing with features on external VSTis and I want to automate the function, but I can’t find what parameter it’s attached to (especially if there are hundreds of them); is there any way to show the name of the parameter at the bottom of the screen (like effects column/DSP descriptions) as I’m moving things around in the VSTi?
The idea I have in mind would be that moving a parameter in a VSTi would display a message in the status bar, telling you the name of the parameter being moved.
Renoise should display a message in the ‘status’ area (bottom left hand corner) of which VST/VSTi parameter name is being tweaked, so that it’s easier to find it in the instr.automation device.
I have tried to experiment with this (midi instr automation learning, which is similar to what is suggested here). It is theoretically possible imo, but I got stuck due to the fact that you have to create observables in lua for a lot of parameters (about 600 for a vst in the case i tried) to detect which one is being changed.
Tech talk: You would also need to code some workarounds to exclude and/or detect parameters that are already automated by an lfo, for example.
Any scripter here who can help or give any feedback on my approach?
If this idea is possible, Renoise can detect parameter change through playing with a vst(i)'s gui, then why not have the ability to record gui-tweakage to automation envelopes automatically?
Press record, tweak knob, automation is written. No more searching through a list of parameters.
Yes, theoretically possible. But you are indeed correct about the possibility of another device (LFO et al.)
modulating any parameter as the reason why it could get really complex to code such a tool.
Basically, you would have to map the entire relationship between all devices in order to determine
which ones are in fact being manipulated by a human and not Renoise itself.
I think it’s an interesting approach suggested by OP - a tool could temporarily attach itself to a plugin,
and report which parameter(s) are being changed with regular intervals.
So, instead of simply printing out any message in the status bar for each event (possible resulting in
flickering, unreadable messages as several messages arrive in slightly offset amount of time),
the script could use the famous “on_idle” loop to gather parameter names which are then output in a
more relaxed manner - I think it would then be quite easy to determine which of the parameter names
we would be manipulating.
As for keeping track of parameters already automated, I don’t think it should be that difficult. Just some track/dsp iteration, interpretation, and if statements in the monitoring algorithm.
The on_idle loop seems to be a great way to go compared to using observables. I will check if plugin_device.active_preset_data contains information sufficient enough to interpret what parameter has been changed - translatable to instr automation device “language”.
Here the API offers something even more precise: “is_automated” is available for each device parameter.
But it’s not a magic solution for when some other device is modulating a parameter - in such a case it’s technically not automated, even if it’s controlled externally.
Quite complex stuff, to build a map of the parameters that are affecting each other (at least personally, I tend to use lots of meta-devices and cross-parameter routings). Also, it’s quite possible that you would want to control a parameter which already happened to be automated?
Oh, I’ve never gone so deep into the plugin properties but I would think you simply obtain an XML representation of data that are already (and more easily) available in the API?
In any case, my suggestion was simply to attach notifiers (even if it means 100s of them), and then use the idle loop to collect the parameters that get’s changed.
Then, the list of parameters could be represented in a more intuitive fashion - for example, by assigning a “lifespan” of a few seconds to each modified parameter, a period of time where you display the parameter name(s).
This approach would still require that you could manually tell apart parameters which were changed by Renoise itself, but we humans are quite capable of such things as pattern recognition (a - very sophisticated - example of this: the planet hunters project )
)