I’m working on a plugin project which requires A LOT of parameters. I have currently got these working inside a value tree. Essentially I am creating a xy graph component and am needing to store the xy settings for multiple points and bezier curves. This means that I have 100 x and y values for the anchor points, 100 x and y values for the bezier points and various other data determining if they are enabled or not. Does anyone have any ideas on how best to recreate this under audioProcessorValueTreeState? Is it possible to vectorise parameters e.g. make a vector of x parameters? Thanks for any help you can give, I’ve never had to deal with this many parameters before!
Do all those things actually have to be automatable with the host application? That would be the main reason to have them as plugin parameters.
If not, you could look into using non-parameter state instead. State variables in the plugin don’t have to be plugin parameters in order for the host project saving and loading to work.
However, if you really want them all as plugin parameters, it’s of course possible to create them using loops and such.
Thanks for the response. I had thought of using parameters to enable the host to control undo/redo functionality. They would be hidden as I can’t see any use in them being automatable. I’m all ears if there is a more sensible way to go about doing this.
Unfortunately, there is no reliable way to get undo points in the host unless plugin parameters are used. It’s quite hit and miss what happens when you call AudioProcessor:: updateHostDisplay. That is supposed to inform the host that something else than a plugin parameter changed in the plugin, but the reports have been such that it doesn’t always work. One hacky possibility to get around this is to add a single “dummy” plugin parameter that is changed when the non-parameter state changes.
I think Undo is handled by the host for a good reason. What is to be undone depends on e.g. automation settings. If there is an automation on a parameter, something different is to be done on undoing a change.
There are two ways of how undo could be done: via set/getStateInformation or by setting the parameters. I think the first is the more reliable. If your state is saved in the set/getStateInformation, then all is good IMHO. No need to make that state all parameters. But you have to test yourself, if that suits your needs.
The problem here is how to get the host to register a new undo point, if the plugin has a change that isn’t happening on a plugin parameter. As far as I know, AudioProcessor::updateHostDisplay does not work reliably for that.
Oh yes, I see. Indeed I heard about that problem (it worked for me, at least in terms of register the state dirty. But I haven’t tested, if it also helps with undo. I have a hunch that is host dependent.
I’ve seen the approach you mentioned with the dummy parameter, seems to be the safest workaround.