Please, do a true fine mode


#1

Hello,
I’m convainced Juce should have a true fine mode, and not a velocity mode.
Meaning a fine mode that just /10 the mouse moves.
The velocity mode redefines the mouse behavior, and totally change your feeling, looking like you’re using an old mouse with the ball stucked with some hair inside.
Please, for the good of the community, just do the simple behavior (/10 moves).
I use the velocity mode as a fine mode for so many years in every juced plugins, and unfortunately I never got used to it.
Thanks a lot,
Louis


#2

I guess this is about the slider? Yes!
Also it looks like the velocity mode on windows is somehow broken, the slider moves very jerky after a certain distance


#3

Yes it’s absolutly about the slider. :slight_smile:
With the velocity mode, when you move too slowly, you do not change the value.
So you try to move faster and it does a big jump, hoping you’re not setting a hi shelf gain that will does a +30dB in your poor ears. I don’t now if it works better with mac, but for me this is deliberately the behavior of this velocity mode.
If i want my mouse to behave like this I’ll do the settings in my OS, not specifically for one vst.
People just want a fine mode to fine tune their knobs, they don’t want to redefine the behavior of the mouse.
Why make it complicated when it can be simple?
Please just replace this crazy velocity mode by a true fine mode that just divide by 10 the mouse move.
Then the fine mode of all juced vst will work properly.
For now it’s like a broken feature and when you ask to the dev a fine mode they say “it’s already here”. Surely they are not using there softwares daily to see how much this velocity mode is dirty.
Thanks,
Louis


#4

Yes please! If for backwards compatibility the velocity mode cannot be ditched altogether, at least allow us to set a factor that, when set, means that the slider will “fine tune” by that factor (10x in the above posts) rather than using the velocity mode


#5

I guess the current behaviour is somehow a malfunction, i remember (but maybe i’m wrong) this was working differently a long time ago


#6

Velocity based editing is a bad anyway. Humans can not really handle it effectively and tend to severely under-shoot or over-shoot.

A simple, configurable multiplier would be much better.


#7

Doesn’t Slider::setSliderSnapsToMousePosition and Slider::setMouseDragSensitivity do exactly this?


#8

No. Slider::setMouseDragSensitivity sets the speed, no matter if you hold a modifier key (like ctrl, alt or shift). What is suggested in this discussion is to keep everything as it is and replace/improve the velocity behavior to make fine adjustments.

An example: you use a Slider to adjust the panning (-64 to +63, where 0 is the center). You load a preset and the panning is at -1. You’re trying to adjust it, but when you move the mouse up it suddenly jumps to +3. Now you’re moving the mouse down a bit, but it jumps to -2 now.

The proposal is to have a modifier key (for example, shift) and now the mouse-movement speed is reduced to 1/10 (or any other configurable multiplier) so you can easily hit that “0” spot.

The velocity system build into the sliders is designed to achieve that, but it’s unsuitable for small ranges (like only 128 values) as it makes the problem worse, not better.


#9

Yeah I know but what I mean is that the sensitivity is adjustable. So you could intercept the mouseDown, check the current modifiers and set it to be more sensitive, on mouseUp, reset it.


#10

Sure, everything that the JUCE library doesn’t do itself, could be done by developers that use it.

What is proposed here is to integrate this feature into JUCE, so that each developer using it doesn’t have to build its own version reinventing the wheel.

The original post gained 5 likes in 23 hours, and most JUCE users don’t even visit the forum on a regular basis. I believe this is an indicator of a significant appreciation for this idea from the JUCE community, enough to give it a serious consideration.


#11

I’m not opposed to adding a fine tune mode, I was merely pointing out that the components are already there for those that can’t wait for something to be added to JUCE.

I was trying to be helpful in pointing out that in the toolkit, the tools are already there to achieve what they want to do in a fairly straightforward way. Knowing this may also prompt someone into using those code parts and offering up a PR which would undoubtedly make an addition to JUCE much speedier.


#12

Velocity based editing is a bad anyway. Humans can not really handle it effectively and tend to severely under-shoot or over-shoot.

A simple, configurable multiplier would be much better.

Exactly what I think.

What is proposed here is to integrate this feature into JUCE, so that each developer using it doesn’t have to build its own version reinventing the wheel.

Absolutly.

I’m not opposed to adding a fine tune mode, I was merely pointing out that the components are already there for those that can’t wait for something to be added to JUCE.

When I tried the only solution was to patch slider.cpp from juce.
Also it should be the default behavior to be reflected in every juced plugins.


#13

You’re all shouting very loudly, but I don’t think anyone here would argue with this! The velocity stuff is extremely old and could certainly use some updating.

Obviously we’d need to retain the current behaviour for people who want backwards-compatibility, but maybe we could have a lambda or something to give it a custom curve?


#14

That sounds awesome ! Something like a lambda that inputs the normal knob offset and outputs the fined knob offset.
Thanks a lot !
Louis


#15

The current behavior is broken on windows (maybe not for everyone, but I’ve seen crazy jumps like chkn mentionned). So retaining would be bad, first we need some fixing!

I for one like the velocity based dragging. A 10x “zoom” only gives you 10x the resolution which often isn’t enough. Maybe the upper speed could be bounded to 10x, but IMHO having the option to do very fine adjustments with very slow mouse movements is very valuable.


#16

IMHO having the option to do very fine adjustments with very slow mouse movements is very valuable.

Please no.
If you want this behavior, the simplest way is to buy this thing :
image

But as again, if we could have a lambda it would be super fine.
Thanks,
Louis


#17

Maybe you are misunderstanding what I wrote. I do actually have some mice in my collection that are similar to the one you pictured and they don’t give me more precision for slow movements, but what I really mean is the following: Say you have a parameter going from 0-100 and normal mouse movement produces integer increments. A 10x modifier would still only give you 1000 steps while velocity based movement can give you almost unlimited precision if you need it. The problem is that on the OSes I know mice can only move by 1 pixel as the minimum which is limiting resolution and a velocity based scheme provides a way to get around that by using the much more precisely measurable time as a factor.

Of course I agree a lambda would make it usable for everyone.


#18

For that you can use the skewfactor.


#19

I know, but at least it would be usable. A mode that handles all the cases as the velocity one is not.
Double click can be used else if you want a precise value.
Thanks,
Louis