I apologise if this has been asked before. I did check through some posts but I didn’t see anything that specifically covered it - maybe I missed it. I am hoping that someone who has already implemented such a thing reads this post and can provide some insight.
So… for context, lets say I have some parameters that I add to the AudioProcessorValueTreeState beforehand and I want to add more during runtime. How would I go about doing this?
For example, lets say I have a bunch of parameters for an oscillator. But I want to be able to add more oscillators within my plugin and have more copies of those parameters exposed to the DAW (Reaper in this case). Lets keep it simple and just say that there is just a Frequency parameter for each oscillator.
So conceptually, when the plugin launches I can see ‘Osc 1 Freq’, and this is able to be automated. But when I click a button ‘Add Oscillator’, it creates another parameter so now theres:-
Osc 1 Freq
Osc 2 Freq
in the plugins parameter list and able to be automated.
Assuming the host can support changing parameters this way, how would be the best way to implement this? For example… is it possible to add to the AudioProcessorValueTreeState during runtime? I assume not. In this case would I need to create a bunch of unused parameters before launch, which would get renamed when I add more oscillators? I have seen other plugins that do this kind of thing, but yikes… it is messy having loads of parameters that are basically pointless when not in use.
Alternatively, is it possible to do this some other way such as by getting the parameter tree and using the ‘add’ method on a juce::Array?
You can change the name, but you can’t change the numbers. Because JUCE does not support adding/removing parameter after the construction of the AudioProcessor.
Ah so this would suggest then that the approach of adding a bunch of unused parameters is the only “real” workable solution then?
EDIT: Oh but what about… if you add more oscillators, then save the project and then unload the plugin / reload the plugin and create the parameters for it at start up? Oh but… nah because this would mean the parameters need to be created before the plugin state can be re-instantiated wouldn’t it? Gah. Ummm maybe.
The reason you should not do it is that by adding or removing parameters dynamically, you create a situation where it is logically impossible for the DAW to match up its own saved parameter data with the plugin. e.g. on day1 you save a session in the DAW, on day 2 you remove some parameters, on day 3 - you add some new parameters. Then you try to load the session from day1, and the DAW is completely confused about how its recollection of the parameters ‘syncs’ with the actual parameters.
I am a little confused about this reply because wouldn’t the Day 1 memory block reflect the state that is required to be loaded, as would the day 2 sessions memory block, etc?
yeah, the plugin could unambiguously recall which parameter was which (from it’s own perspective).
But also in the saved session, the DAW has associated some data with each parameter (like an automation lane). I have not discovered any reliable algorithm for the DAW to know which parameter to apply the automation to (when the plugin has the freedom to delete or add parameters at will).
The way I visualize it is: the plugin and the DAW have a ‘contract’ which is that a plugin is represented by its parameters. This is is what allows the two to cooperate effectivly. And if you alter those parameters’ meanings too much - you have, to all intents and purposes, created a different plugin.
