Rotary Slider and setSliderSnapsToMousePosition()

General JUCE discussion
1

I’d like to use a Rotary Slider in a way more like an adjustor, so I need to set this option and work with velocity.

It seems to be disabled for rotary sliders. Is there a technical reason for that?

Bruce

2

It wouldn’t really make any sense when you’re moving the mouse circularly, would it?

3

Well first, that could be a finger, not mouse, and second, there’s physical controls that work that way - multi-turn pots, infinite potentiometers. If a control has considerable fidelity, the rotary adjustor is currently unable to access that fidelity.

So, yes, I think it would make sense. I’d like to at least try it. I get the feeling I’ve worked with other apps that allow it. Is there a reason apart from that it seemed odd to you? Could it work?

I find I’m quite capable of moving a mouse in a circle, btw. :wink:

Bruce

4

I guess if you make it do multi-turn changes… At the moment it’s not written like that at all, it just rotates the knob to point directly towards the cursor. It’d require some cunning re-jigging to also make it support a relative-circular-motion mode.

5

I was afraid you’d say that. Well, the main thing I wanted was to make it a ‘knob’, not a ‘dial’, by which I mean wherever you touch it, you can start adjusting from there, much like a physical knob. I’m surprised that isn’t normal, it being such a normal audio control (and so many audio apps mimicking physical controls). Let me look through the contributions - maybe someone has done this before.

Bruce

6

So, running into this again.
On a small or smallish touchscreen, the following applies:

Due to screen real estate, a rotary control is best. Any other control has insufficient range and/or accuracy without your finger running off the screen.

Due to finger size, a click is almost guaranteed to hit a different point. That will cause a jump in values unless the control is relative.

Maybe a velocity/relative mode combined with no snap might work fine.

Can you give me a clue on the rejiggering?

Bryce

7

It would be cool if Juce separated the drawing of a control from the way the user interacts with it. I architected my own classes to implement this but it meant having to write my own slider / knob.

Juce kind of tries to do that through the LookAndFeel but its a little bit rough.

I have something like this working in my app:

Control* c = new Ui::KnobControl(
  new Facade::StandardKnob (colorScheme),
  new Model::VSTParameter (plugin, 1));

Facades are interchangable objects that only know how to draw, while a Model is a domain specific object that represents the data. In this case, its a parameter to a VST plugin - a double in the range 0…1.

Using this technique I can re-use the Facade and Model, and change to a different Control. Or I can swap in a new knob Facade to make the control look different while preserving all the behavior.

Models are reference counted and thread safe so multiple controls can be views to the same model.

8

That’s a very cool setup. I suspect values + drawables will do about the same pretty soon.

I’m fairly keen to stick with the standard juce classes until the very last minute, I was just hoping that rotary controls would be able to come up to par (non jump, velocity mode etc.)

Bruce

9

I’m also having trouble with the rotary knob jumping to the mouse position.

I’ve implemented a sort of panning control, the main component of which is a large infinitely-turnable (value-wrapping) rotary knob. This UI just doesn’t seem right with the current snap to mouse position behaviour - it really needs relative adjustment.

See screenshot:
[attachment=0]Capture.PNG[/attachment]

BTW: massive massive thanks for making Juce available - it’s taken a whole ton of pain out of writing these plugins and just works beautifully (for 99.9% of things :wink: ) :smiley: