I was asked if it is possible to change the range of a parameter between versions, such as to add new selections to a drop-down menu (which is tied to an automatable parameter).
My opinion was that we could easily load old session (chunk) data, by having a version number in the data and handling old vs. new data differently. But the loading of old automation values would be an issue, because hosts simply store the normalized value, and there would be no way to know that a given normalized value needs to be converted from an older range to a newer one. So, changing the range of a drop-down, for example, would result in potentially mapping to the wrong selection when the DAW sends us that old automation data.
Is there any way to get around this?
1 Like
You’re totally right here.
We did this in the past:
v1.0 of our synth had 50 parameters, but we told the DAW that it had 70 parameters - 51-70 for future use. In v1.0, parameter 20 was the filter type, with 4 possible values.
We introduced two more filter types in v1.1., and used one of the previously reserved parameters - parameter 51 - for the new filter type.
Now, when v1.1 receives automation of parameter 20, we map it to one of the 4 filter types that v1.0 had, and set the value for the new filter type accordingly, and let the DAW know that parameter 51 has changed.
However with this approach AU validation will fail, as the AU validation will make sure that if you change one parameter, that no other is changed too. You can declare macro parameters, but I must admit that I’ve never tried it; would be great to learn if it works, though.
A few of our plugins use meta-parameters, which affect other parameters, and they pass AU validation. Haven’t checked with the new JUCE 6, where meta-parameters are not available by default. We’ll have to make our own derived classes that allow that flag to be set, and maybe hack the AU wrapper. Won’t know until I address it.
But a problem with this scheme is then you have parameters exposed to automation that aren’t what they seem, and users will wonder why there are similarly named parameters and which one they should use. And what if they automate both? Not a very clean solution, unfortunately.
Did you find a good solution to this problem?
Nope. At the moment, we’re just not going to modify any parameter ranges. We’d like to, but not without a good solution. It’s not really a JUCE issue, though… it’s been a problem with all audio SDKs, the whole time I’ve been working in this field.
Thanks. I guess the only way is to inform users that it will break things in their old projects!
