Using the normalisable range (in my case with a Slider) runs into an assertion when using Slider::setRange(Range::emptyRange(0)).
The assertion occurs in NormalisableRange::checkInvariants. I think it should say “end >= start”. The already algorithm supports an empty range.
what’s the use case for a slider with an empty range?
I think the way NormalisableRange and Slider behave are both correct.
I am implementing a crossfade in the example MPESamplePlayer. The length of the cross fade is capped to the length of (0 to loop start) and length of (loop start to loop end). Setting the loop start at the same position as the end point (which is easily possible by dragging) the possible cross fade length becomes zero. The source code would be a little easy to read (and shorter) if a slider range of zero would be possible. My current solution is to skip the Slider::setRange and disable it.
But if the loop end point is the same as the loop start point, then doesn’t your DSP code under the hood still need to implement some form of smoothing/windowing/crossfading to prevent clicks/artefacts at the looping boundary?
Why does this slider’s range ever need to change? Why can’t it just be “crossfade %”, and the DSP code translates the %age into an actual length for the crossfade based on the current loop points…?
Even if it makes sense for a NormalisableRange to be able to have a range of 0, a GUI slider with a range of 0 makes no sense. That would just be… an image of a block, sitting there
Having the same start end end point is implemented as just no loop.
OK, perhaps I’m a bit confused about what you’re actually doing. But I still think this suggestion is relevant:
Crossfade % is out of question. I want to be able to define the length precisely on frame level
if that level of precision is your goal, then perhaps a slider isn’t the best choice of GUI element. Maybe a text box, where you can type in the # of samples, but isn’t text-editable when the possible range is 0…?
Thats true, it dosn’t make perfect sense for a rotary slider. But the slider can be just a label and two buttons in which case it would make the code flow much easier, if this edge case is supported. In my opinion, at least for the slider, there is a well defined behaviour.
No, there’s not. Because a slider with a range of 0 can’t slide anywhere, which is what that component’s entire purpose is.
Even if you can make this work with a slider, I don’t think it would be a good design decision. For your users, they’ll be seeing one parameter’s range constantly changed by another parameter’s value. I think that would be very confusing. Also, this would make automating the crossfade length parameter next to impossible.
I don’t know if there is a legitimate UX case for that or not. But the problem with “the end allowed to be equal to start”, is that you will have a lot of divide-by-zero cases to handle (e.g. here). It is far more easy to design the class with a non-zero length invariant. The user is supposed to know how to handle this zero case whereas the JUCE framework doesn’t. I’m not sure that the need to catch exceptions will make people happy.
My 2 cents.
