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.
I don’t understand, why you are not setting the original range?
myKnob->setRange(0.0, 255.0, 1.0);
You may be hitting the precision limit of
floats: 1/255 = 3.92156862E-3 which doesn’t quite fit. Try using
because all of my parameters work on a 0…1 range and are converted inside their class.
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?
Doubles are more than accurate enough. Most likely you’re converting the value to a string and back somewhere, and getting rounding errors
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.
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.
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
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?
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.
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.
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?
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.