I would like to know how do you deal with parameters that have a list of choices. Currently, I’m treating those like any other parameter, but if I end up to add more options in an update, the entire 0-1 mapping is inevitably changed.
Example: having a list of 10 choices named “TYPE”, we get that each entry starts from 0 and increments by 0.11 (1.0 / N-1). If I add 2 more choices, we’ll have a list of 12 elements and now these values will be translated with an increment of 0.091.
In this case, I check if the preset version matches the current plugin version and adapt the mapping, but it’s cumbersome and not the very best way to do that. I could add a sort of UID to each list entry and store that instead of the 0-1 value and manage the mapping later, but that won’t work if a user automated that parameter change, since parameter automations are stored as 0-1 values.
A couple of workarounds that jumps in my mind would be either store the last UID as a session var or preallocate N values for the list, even if I’m not using all of them (set the parameter to have 255 values, use 10). Both of them are definitely ugly.
This problem has to do with automation in general. Imagine that you change the range of some DSP filter in a product update, then any automation from an old session will break, it will sound different. My suggestion is to simply not change the ranges or choices. I like that @valhalladsp clearly mentions on his website that once a product is released, it will not change and (nearly) no features will be added. Support - Valhalla DSP
I think if I really have to change the range then maybe I would make it a new parameter (change the ID) so that old automation data is ignored.
To just convert the state, you can write conversion functions, make sure to add the version number of the product in the state so you can easily detect from what version to convert.
Thanks, but @valhalladsp also have similar situations, since he added new algorithms to existing products. I’d find very bad, nowdays, to keep new features away from a product just become we can’t handle that. Changing the parameter ID is a no-go for users, especially if they won’t be able to recall old projects and lost automations. This would be very bad for a brand reputation.
I already have range converters in my existing products but, as said, I find this approach quite ugly. I believe that a better way to handle that exists, but I’m struggling to find one that will be manageable in the long term.
The only clean way to add more choices, is to add more parameters to your product, or use non-automatable data (which is only saved in your state; not as a “parameter”), but you will loose backwards compatibility anyway.
I guess I’ll try the pre-allocated steps way. I tried in the past to make these parameters as not automatable, ending up in several support tickets asking why they weren’t able to automate them -_-
I’ve allocated more “slots” in parts of my plugins, by mapping the 0-1 range of a parameter to 12 or 24 slots, and then shipping with only a few of those filled. This allows me to add more modes over time. If I didn’t pre-reserve these slots when the plugin was launched, I can’t change this.
Another good idea, is to have several reserved parameters at the end of your parameter list. I did this with ValhallaDelay, which allowed me to add a new parameter to a later release without breaking any existing DAW projects.
My guess is that most DAWs are OK nowadays with adding a parameter to the end of a parameter list, but I haven’t verified this. In this case, you could add a second parameter that works with an existing parameter, to extend the range. Think of it as adding more “banks” or whatever. Your existing parameter might cover 10 choices, and the new parameter then adds 10 banks, with the first bank reserved for the existing 10 choices, and 90 more slots can open up this way.
Sorry to reopen this thread, but I’m hitting this right now and while I like the idea of preallocating more steps than I will currently use for a “choice” type parameter, how then do you deal with the control ranges? If my preallocated parameter range is {0.0, 24.0, 1.0}, but I’m only currently using 10 or so, then I have to have a special case for anything that uses that range. Any elegant way to deal with this?
