@kritzikratzi oh yes please! One cool implementation is if you have endless rotary encoders configured to increment upwards and downwards as opposed to “absolute mode” with a standard CC command.
I use an Akai MPD232 with Bitwig. If I leave the rotary encoders of the Akai set to their default type (CC) and map those encoders to things like my Channel faders or my effect sends, the behavior is typical absolute encoder control with 128 steps of resolution for that particular fader. This seems to be OsciStudio’s implementation as well.
This is all great and cool, but there is problem if playback is running with automation on a lane you want to send a CC signal to. Imagine a performance is running and automation has lowered the CC command to 1 while the rotary encoder’s absolute position is still at 127. If you try to change the fader up because automation has made it too ‘quiet’ by touching your rotary encoder, the value will first shoot to 127 when the encoder retakes control before you can bring it down to the modest value you wanted. It would be more desirable in most situations to not “spike” your CCs this way. A similar thing happens in OsciStudio when I want to control a scene with the “cues” feature but I still want to control those sliders manually.
The cue will move the slider drastically, but if try to change that same slider afterwards with the rotary encoder the slider will jump to the value of the rotary encoder’s absolute position rather than increment upwards or downwards predictably.
The solution I have found is to set your encoders to “INC/DEC2” on the Akai. Now if you turn the rotary encoder “up” it sends “01” for that CC# and channel. If I turn it down it sends “7f”.
In Bitwig, I can select “relative 2s Complement” (again, the default is “absolute”). NOW if automation is running during a performance and I want to tweak a value that automation has changed, touching the same endless rotary encoder will predictably increment or decrement that value in whatever step resolution the software decides.
Ardour supports this as well, but you have to use an editor on the xml file that holds the various MIDI maps (*.map).
This would be super powerful in OsciStudio. You could allow the timeline automation or cues to drive complex automation, but you could still interact with the automation in ways that did not create unpleasant CC “spikes” as I described.