Extra limits whilst dragging knobs or sliders

[sm_jamieson]

I would like knobs and sliders to have an extra pair of limits that could be called "Safe Min" and "Safe Max", or maybe "Drag Min" and "Drag Max". These limits would control how far the knob or slider can be dragged in a single action by mouse or touch. This means in a live situation you can have a subset of values that can be swept between without any delicate fiddling to get it just right. Once you slide up to the limit the values stay fixed at that value until the mouse/finger is lifted.
When you are on this limit, if you lift your finger and touch again, a further slider movement will allow the full range of values to be reached. In slider absolute mode if you touch outside the limits that value will be allowed too.

Note that the slider graphical control always shows the full range of values. An extra cursor drawn on the slider would show the values of the extra limits. The extra limits would default to the same as the main limits, so the feature would not affect existing patches.

I have a patch to do something like this by manipulating the normal Min and Max, but to have it included on the knobs and sliders would be excellent.
An example: I use this at lot with a touchscreen on a bright VA synth with a filter control, where the chorus has the filter open and the verse has it closed to a certain position to sound like a pad, but at then end of the song the filter can be closed all the way to close off the sound.
Without this feature I would need extra concentration to get the fader end points just right which makes live control more stressful.

I hope this makes sense !

Simon.

[x.iso]

As alternative here's another suggestion. Ability to draw a 'sensitivity' or 'acceleration' curves for knobs, faders and other controls like that (like range fader and hopefully range knob if that's going to be added in future), so then you could draw safe zones for you controls, and in response the position of control would get 'stuck' in valleys of the graph and latch onto regions of choice until you push it far enough or give it extra acceleration.
This way beside min-max arbitrary 'limiters' we could also make 'ratchet' like behaviour for several positions. As this curve would be basically an array, it would be possible to 'flatten' this curve and ease this 'ratchet' on the fly with separate control doing the mixing of arrays.

In a way you can do something similar already, but that would require making 'ghost' control on top of mock-up one that would display the actual value position. But I would prefer direct visual feedback and also for this 'scale curve' to apply for acceleration or sensitivity of input rather than position of the control.

[23fx23]

no offense itended but imo thats kind of quite specific and could be done as a tailored user subpatch/module, cause there a an infinite numbers of way user could like its fader beavours (reset on mouse up, snap to values, velocity accelered, inertia ect ect...). basic UI items are used all over the place by usine itself, in patchs, settings ect like on loading a wks there are already say 1000 faders, combobox and stuff, if all items add more vars, arrays and stuff that means more ram, more cpu ect for stuff that will be rarerly used. in most situations.
or that would need to be 'new' different "boosted" items maybe, but pers i wouldn't bloat too much base items.

[x.iso]

Yes, perhaps that's needed for separate controls, since regular ones might be used just for patching purposes. maybe this could be suggestion for your Touch_fader module then? it is bundled in HH3 now anyway.

And speaking of this matter, maybe there is a need for stripped down technical 'controls' just for patching and low level use, minimal parameters etc. And UI-centric ones. Perhaps Touch_fader could be branched to individual types of controls for demanding customization options.

[x.iso]

Just tried out a way to patch around this idea and the touch precision factor certainly isn't made for modulations, if I modulate it according to graph, then the value starts to jiggle around and in turn precision factor as well, so it's all jittery as hell in the output, even with smoothers and other tricks.

[23fx23]

^^yes i reckon i have let a bit down touch fader.. cause it was kinda badly coded (i was quite new to cpp/sdk when started it and went too complex trying to make an 'all in one' wich was prob a bad idea.. that lead to this kind of bloating of internal variables^^ and messy organized/coded...

I pers totally agree with the idea of 2 levels, simpler items for patching ( actually kinda like they are), and new more advanced UI oriented items.
gonna try to contribute with a new better fader only module

[senso]

I'm afraid that this suggestion could seriously weighing the engine for a very specific use and probably not sufficient to cover all possibilities. In Usine adding an inlet in a fader means 2ko more on each fader, knob, etc. so we have to avoid too specific inlets?

[x.iso]

I'm afraid that this suggestion could seriously weighing the engine for a very specific use and probably not sufficient to cover all possibilities. In Usine adding an inlet in a fader means 2ko more on each fader, knob, etc. so we have to avoid too specific inlets?

What about idea of separating UI-centric controls from technical ones?