I’m trying to handle patch version migration, to be able to guarantee downwards compatibility for plugin-patches in the future.
Ok, so now I have an old patch which contains an audioparamter which no longer exists, and does not contain one which was added to the plugin. I do
m_value_tree.state.replaceState(new_state);
and now my processorstate has the old parameter set. I was able to add and remove non-audio params with ValueTree::removeParameter(), but this doesn’t seem to work with audio params. Which makes sense considering these have much deeper connections with min-max ranges and curves and stuff.
JUCE doesn’t support a dynamic number of plug-in parameters. You can change the names of existing parameters and groups (and hide them in most hosts by giving them an empty name) but changing the number of them won’t work.
The good thing about APVTS is that the state IS a plain juce::ValueTree.
So you can have a middleware in your get/setStateInformation to test which children are available and reconstruct it, drop or do whatever you need.
As far as I undertand it it has a ValueTree member, which contains all the data, however the ranged audio parameters have a somewhat special place, and they can only be created in the initializer list in the constructor. See also t0m’s answer.
Guess for my goal to support old plugin patches I can’t use the replaceState() function then (since old patches may not contain new parameters), but override them one at a time.
