I have a need for a variation of the rotary slider that acts like an endless rotary jog dial on video mixing consoles. Or like a platter on a turntable or dj mixer if that makes it clearer.
I'm aware that we can use stopAtEnd = false with a regular rotary slider, but the problem is in that case that:
clicking on the rotary will immediately jump to the clicked position (real jog dials don't act that way)
dragging up/down will not allow zero crossings (whereas a jog dial should allow multiple revolutions when dragging up/down far enough)
@Jules: Any chance for such a feature to make it into one of the next versions? It could be of use to many people I guess.
BTW as a workaround I wrote some experimental overrides on the MouseDown/Drag/Up methods that add this behaviour. However this has the problem that I cannot call pimpl.sendDragStart() because I obviously have no access to the Slider::Pimpl
A poor man's temp solution could be to add a protected sendDragStart() / sendDragEnd() pair on the Slider class that call the pimpl for me. I would already be very grateful for that!
It's not something that'd fit into the current Slider class, which is very firmly designed for a fixed range. It'd need to be a new separate class of component which has different behaviour. It's a good request, but not sure how big a priority it'd be for us, as it's actually not something that many people have asked for.
a new optimised class would be fine as well of course! But I can imagine there are more pressing things indeed
how about just adding the protected sendDragStart/End then - it's is a tiny change that would be unlikely to to disrupt any existing code, while it would help me avoid writing an entire new class myself :-)
Sorry, but exposing aspects of the internal implementation for users to access is never a "tiny change"!
Of all the types of request you can make to a library developer, asking for hidden methods to be made public is likely to be the least welcome - if we let you couple your code to the way things work internally, it means we can't change the implementation in the future.
point taken and even agreeing with it :-) Though that abstract/implementation boundary is often not black and white - it's always a balancing act between flexibility for the library writer (to change implementation without breaking anything) and for the library user (to adapt it to real-world needs)- one that Juce does admirably most of the time it must be said
I guess what I really wanted is to have some kind of implementation-independent semantics on the abstract Slider interface that inheritors can use to signal to the audioprocessor host that it's about to produce a lot of changes (via the SliderAttachment intermediate that is). I don't care how it is implemented really. Anyhow, not a matter of life and death!
Yeah, I agree. The slider class has always been a bad one for long-term feature creep, and I've often thought about breaking it up into a collection of classes to control various aspects of its behaviour. Will hopefully get chance to do that one day!
