Quote:
Originally Posted by Geoff Waddington
Since all values are normalized, do these even make sense ?
|
They really do. I'm currently writing my oscii-bot script for Novation SL and I'm experiencing different issues, related to those modes.
Imagine having single rotary encoder. So, -1/1 around rotary center for rotation.
Now, try to adjust volume on currently selected track, without making fader jump from min to max. Then, try to do the same with the volume on a new selected track, using the same fader.
This is where relative rotary mode is needed.
Try to do the same with a non-motorized fader. Let's say that your fader is in zero position, while track's volume is on 9/10 of the scale.
You'll move fader up and volume will start going up towards max immediately.
Remember, your fader is still at the bottom of the range. You won't be able to lower the volume, until you'll move fader all the way up and then back down. Somewhere around the max value of master track's volume your monitors will blow up. Is this behavior that you'd want from a fader?
That's why soft pickup mode is used. Volume value won't change until fader reaches the value.
Quote:
Originally Posted by Geoff Waddington
These are 2 sides of the same coin, and really have to do with smoothing / amplifying the data control stream, perhaps they belong somewhere in the map, not sure...
|
The main map is useful to interpret value from the real controller, while those values and behavior should be altered for different plugins/actions, mapped to the same widget.
As I already said, I'm currently programming my controller, so I'm dealing with encoders, faders, pots, buttons, modes, shifts, LEDs and, later, LCD data. They all act differently.
Button can be toggle, momentary, hold, double click. It can send command on press, on release or on both, depending on the current task. It can send multiple commands at once, like "turn on compressor AND eq".