Slider setRange problem


#1

Hi guys,
I’m having an issue with the slider setRange. I have a parameter that goes from 0 to 255ms, a filstrip knob with 256 frames. I set the knob this way:

myKnob->setRange(0.0, 1.0, knobRatio);

where knob ratio is (1.0f / 255.f)

problem is… let’s say I set the knob to 140ms in the GUI. next time I click I see 139ms but the parameter is set to 140.25

the only way I have to get all consistent is by using 0.01 as interval… but in this way my 1ms steps for the knobs are totally lost.

Any advice?


#2

I don’t understand, why you are not setting the original range?

myKnob->setRange(0.0, 255.0, 1.0);

#3

You may be hitting the precision limit of floats: 1/255 = 3.92156862E-3 which doesn’t quite fit. Try using doubles.


#4

because all of my parameters work on a 0…1 range and are converted inside their class.


#5

it’s roughly 0.0039, but I also tried with doubles but nothing changed. @jules @timur should I expect this kind of error if I set the scaling to something less than 0.01?


#6

Doubles are more than accurate enough. Most likely you’re converting the value to a string and back somewhere, and getting rounding errors


#7

Thanks Jules. What I’m doing is this.

on the plugin i add a parameter using addParameter and FloatParameter class. all parameters here are 0…1 and converted to a different range in the FloatParameter class using a float NormalisableRange.

I also tried 0 instead of (1 / 255) there, but nothing changes.

In the getText method I have nothing trivial:

I tried several ways, but I can’t get a consistent result if I use a scale different than 0.01 in Slider->setRange.


#8

even float should be enough, they have a precision of approximately 6 significant digits. Due to rounding errors you may get 139.001 or 138.999 instead of 139, but if you’re getting 140.25 there’s probably a logical error somewhere.

@t0m, the precision limit of float depends on the order of magnitude (because it’s floating point). For values around 1.0 that limit is around 1e-7, in other words way smaller than 1/255.

Getting 139 instead of 140.25 is an error of almost 1 in 100, and very unlikely to be the result of a rounding error. More likely there’s a logic error somewhere.


#9

I was just pointing out that decimal representation of 1/255 has 9 significant figures, so you would be losing some accuracy irrespective of the exponent. Changing to a double was a quick test so I didn’t think too much about it :slight_smile:


#10

Thanks guys. At this point let me ask the question again in a different way:

I need to make a slider with 1ms interval, going from 0 to 255. What is the best practice to make that on the JUCE framework, keeping in mind that the slider range should be 0…1?

Thanks,
Luca


#11

:confused:
I guess what you want is to keep eveything between 0. and 1.
set you parameter range 0-1 and your slider range 0 to 1, and just make the string representation of your parameter showing a value between 0 and 255.


#12

Thanks lalala… and that’s what I’m actually doing. Internally both the parameter and the slider works at 0…1 range while the value show to the user is got using a NormalisableRange and, as previously wrote, I’m getting unconsistent values between the GUI and the parameters view.


#13

Are we missing a NormalisableRange::snapToLegalValue (value) call somewhere?

By default the NormalisableRange doesn’t do this, nor does AudioParameterFloat. However the more modern AudioParameterValueTreeState does automatically snap parameter values to the set interval (and provides a nice way of automatically binding to a slider or knob). Could you try with this and see if that’s the problem?


#14

Thanks Tom. I’ll check that, if already existing in 3.2. Unfortunately I didn’t updated to a more current version (even if I’m currently paying for that), because honestly I don’t know which one to use that will not break anything.