Future expansion of "AudioParameterChoice" parameter values

Sorry if this is a recurring topic. I only from this thread and I’m in a similar situation:

I have some parameters using “AudioParameterChoice” on an AudioProcessorValueTree. Some of them linked to Sliders, others to Comboboxes.

These choices can grow between versions, but doing so by naively adding choices would break existing automation. No news here.

When using the search function, what everyone seems to be doing is to add reserved values to the range. But from the preliminary analysis I’m doing, it seems that this is going to be cumbersome.

It seems more or less straightforward to just derive “RangedAudioParameter” and copy paste the “AudioParameterChoice” implementation, but adding an extra tail of reserved parameters that map to the default/last value instead. Same on the audio processor.

But then how to make the Sliders and Comboboxes to ignore the reserved range GUI/wise? Is there a way to map a Widget value range to a parameter subrange? How are you doing this? Is there a clean and clever way?

As of now I’m toying with just vanilla AudioParameterChoices with extra unused values at the tail.

On the Combobox I have seen that they don’t break when you set indexes/ids that weren’t added via “addItem”, they just get Id 0. So from the “OnChange” callback they can be set to a suitable default (“none” value in my case). This is in some way some kind of range limitation.

Let’s see how this works with a Slider mapped to “AudioParameterChoices”, as at construction time I know how many dummy values are on the tail of the range.

Just to document one of the many solutions to this.

As I already had thin wrappers around JUCE’s widgets, what I did was to have dummy parameters/sliders/comboboxes with the extended range exposed to the DAW on the AudioProcessorValueTreeState and the ones exposed on the GUI have the reduced range. They are linked via callbacks.

It’s a lazy solution, as it wastes some components (I don’t think components are heavyweight objects at all), but it doesn’t require dealing with extending and maintaining extra classes.