Shortened endpoint domain of choice mapping

Inside the AudioParameterChoice is a default mapping via a normalisable range:

                NormalisableRange<float> rangeWithInterval { 0.0f, (float) choices.size() - 1.0f,
                                                             [] (float, float end, float v) { return jlimit (0.0f, end, v * end); },
                                                             [] (float, float end, float v) { return jlimit (0.0f, 1.0f, v / end); },
                                                             [] (float start, float end, float v) { return (float) roundToInt (juce::jlimit (start, end, v)); } };

But this sort of mapping clips off the end points so they have a smaller amount of travel to select them from a control.

As an example of what this is doing lets use start = 0, end = 10, and interval = 1, so steps = 11. Here are some plots to show how juce reduces the size of the end point domains (x values for which end values are mapped from) in the quantisation mapping, and how to do the mapping so there are equal lengths for each value:

It looks like the guys at Steinberg have got it right, as this is how they show to do it for the VST3 conversions:

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Parameters+Automation/Index.html#parameter-styles--step-count

That’s an interesting find. I’m figuring that won’t be changed any time soon because it’ll screw up selections in a lot of existing plugins if the mapping from 0…1 suddenly changes.

On the other hand for general choices (i.e. selection lists or combo boxes etc) it probably doesn’t matter. It’ll rear its head if you apply some host automation such as cycling backwards and forwards using an LFO for example. In that case the first and last elements won’t be chosen for long enough. Is this kind of automation likely for choice types though?

I checked the classes and there’s only const reference access to the NormalisableRange range so unfortunately there’s no ability to override it at this point.

yeah, my own old wrapper-class also used the equal lengths, which also seems to be my natural choice.

On the other hand, if you interpret the value as an integer number, it makes sense to put the first and the last value on the first and last position, as discrete “points”, and expand the “numerical space” around it.

I think it’s a matter of definition, no right or wrong here.

1 Like

I don’t think that’s actually possible, because you can only have steps in automation lanes for discrete parameters, which is the main reason why making a numeric parameter discrete instead of quantizing it internally is such a bad choice. It may slightly affect a slider connected through an attachment: the thumb position would be right, because it would be quantized by the interval, but the lengths of mouse drag would be wrong.

It is possible. In Ableton for example I exposed an AudioParameterChoice as an automatable parameter and had no problem automating it. It’s really after all just a 0…1 value under the hood with custom to text and from text convertors. Notably, through the Ableton interface it just lets you smoothly drag the value but the text snaps to the fixed amounts and in accordance with Andy’s finding, so shorter at the start and end.

1 Like

It depends on the plugin type and host type. In Ableton Live they do support enums / bools in AU, but not in VST2/3, but in Cubase they do support VST3 enums/bools.

I’m coming clean to this and have all my own converters which use equal length snapping stages, so I line up with Steinberg just fine, but there may be some edge cases if different quantisation methods are used in the DAW vs the plugin.