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.
What’s your way to deal with that?