Wrong values shown using SliderAttachment

General JUCE discussion
1

I’m using an AudioProcessorValueTreeState with SliderAttachments. Drags are snapped by a custom snapValue() at some specified interval, say 20. Then, sometimes the values shown are off by one: 180, 199, 220. I know this happens because they get normalized and denormalized: SliderAttachment sets a lambda to textFromValueFunction which calls getTextForDenormalisedValue() -here it’s normalized-, which calls AudioParameterFloat::getText -here it’s re-denormalized. Is there any way to avoid this zigzagging? It’s not a terrible quirk, but a quirk nonetheless.

2

You shouldn’t normalise or denomralise in the textToValue function/lambda. The number that is coming in as argument is the number you want to display. And vice versa in valueToText.

Also for a better setting of the NormalisableRange of the parameter, have a look at the alternative Constructor of AudioParameterFloat, which takes a NormalisableRange object. And then have a look at the various constructors to NormalisableRange. With that approach you can define things much more precise.

3

I’m using the second constructor, actually to set a string-from-value function for setting the amount of decimals shown. It’s not me that’s normalizing, it’s SliderAttachment. In Slider::getTextFromValue:

if (textFromValueFunction != nullptr)
    return textFromValueFunction (val);

In SliderAttachment::Pimpl constructor:

slider.textFromValueFunction = [param](double value) { return param->getTextForDenormalisedValue ((float) value); };

In AudioProcessorValueTreeState::ParameterAdapter:

String getTextForDenormalisedValue (float value) const
{
    return parameter.getText (normalise (value), 0);
}

float normalise (float denormalised) const
{
    return getParameter().convertTo0to1 (denormalised);
}

In AudioParameterFloat:

String AudioParameterFloat::getText (float v, int length) const { return stringFromValueFunction (convertFrom0to1 (v), length); }

So we’re doing stringFromValueFunction(convertFrom0to1(convertTo0to1(value))). SliderAttachment normalizes and denormalizes before converting to String. The value is alright before that, but loses precision afterwards.

4

The lambda the SliderAttachment is setting is the one from the connected AudioParameterFloat.

  • What is the range you are setting to the parameter?
  • Is the range actually divisible by the step size?
  • What if you supply the step size in the NormalisableRange of the parameter instead of overriding the snapToValue function?
5

In the particular case I’m talking about, the range is 20…10020, and the step size is 20. I’m using snapValue instead of the range interval because I don’t want to quantize automation. Otherwise slow automations on small ranges get badly staircased, and I’m not smoothing all parameters. In this case I may end up setting a small interval, because it doesn’t matter that much. I just hoped there was some way to bypass that zigzagging without quantizing the actual values.