moinho
10-31-2009, 01:16 PM
Hi Jeff, hi everyone,
I'd like to do some writeup/reqspec regarding the topic of a more powerful implementation of MIDI CCs in Mobius. This refers to some thoughts discussed in http://www.circularlabs.com/forums/showthread.php?t=15.
Summary
There's two use cases I'll discuss, namely
a) visual feedback about controller changes (e.g. when triggered by a script),
b) avoiding controller "snapping" (e.g. if your knob is set to Feedback 0, Mobius uses a value of 127 and you want to reduce that by turning the knob, resulting in a sudden jump to feedback=1).
There's three technological approaches for this:
1. snapping algorithm
2. MIDI controller feedback,
3. relative MIDI controllers.
Not that both 2 and 3 require the controller to support this functionality.
It will be discussed how these two technologies can be used for those two use cases, and to which type of controller (e.g. footpedal, rotary) they can be applied.
Types of controllers
First of all, I'm gonna name several kinds of controllers which are relevant here for transmitting CCs.
i) rotary encoders (with end positions) and foot pedals
ii) endless rotary encoders, including the Boomerang-type wheel encoder
iii) endless rotary encoders with visual feedback (e.g. LEDs)
iv) faders
v) motorized faders
Use Cases:
This section simply explains our two use cases in more detail:
a) visual feedback:
Especially if Mobius is used without a computer screen, visual feedback for the controllers can make sense, i.e. that your faderbox displays the current value of the parameter you are controlling. This is of course only possible for controllers that provide a controllable visual feedback, so it's limited to iii) and v).
b) controller snapping:
Typically, MIDI CC sources (like those mentioned in the "Types of Controllers" section) send messages when you move them. Now here's the problem. Let's assume you place your footpedal (which you use to control output volume) to toe-down (i.e. value 0) and then load Mobius, which initializes the output volume to 127.
Using the technologies to address the use cases:
Starting with use case a), this can only be done using technology 2. Obviously, this requires the controllers to be of sort iii) or v).
As a sidenote, this can also be used to transmit non-controller information for visual clues - e.g. the circular loop position display could be sent to a LED ring round an unused controller.
For use case b), the mapping is somewhat more complicated:
For controllers ii) and iii), 3. can be used, while 1. and 2. is possible for all kinds of controllers.
Putting it together
As we've seen, there's only one technology that will solve both use cases at once, namely 2. On the other hand, the only technology that works with all kinds of controllers is 1. 3, finally, is only of use for controllers of type ii) and iii) and offers better handling than 1, but (like 1) only solves use case b).
So there's a reason for any technology to be implemented:
1. works with all kinds of controllers for use case b)
2. solves use cases a) and b) and allows for additional visual feedback, but requires controllers that support this technology.
3. solves use case b) for controllers of groups ii) and iii) which support this technology.
moinho's recommendation
As said before, none of these technologies does everything perfectly. From my personal experience with controllers, 3 is required the least, so a first implementation should perhaps focus on technology 1, followed by 2.
I'd like to do some writeup/reqspec regarding the topic of a more powerful implementation of MIDI CCs in Mobius. This refers to some thoughts discussed in http://www.circularlabs.com/forums/showthread.php?t=15.
Summary
There's two use cases I'll discuss, namely
a) visual feedback about controller changes (e.g. when triggered by a script),
b) avoiding controller "snapping" (e.g. if your knob is set to Feedback 0, Mobius uses a value of 127 and you want to reduce that by turning the knob, resulting in a sudden jump to feedback=1).
There's three technological approaches for this:
1. snapping algorithm
2. MIDI controller feedback,
3. relative MIDI controllers.
Not that both 2 and 3 require the controller to support this functionality.
It will be discussed how these two technologies can be used for those two use cases, and to which type of controller (e.g. footpedal, rotary) they can be applied.
Types of controllers
First of all, I'm gonna name several kinds of controllers which are relevant here for transmitting CCs.
i) rotary encoders (with end positions) and foot pedals
ii) endless rotary encoders, including the Boomerang-type wheel encoder
iii) endless rotary encoders with visual feedback (e.g. LEDs)
iv) faders
v) motorized faders
Use Cases:
This section simply explains our two use cases in more detail:
a) visual feedback:
Especially if Mobius is used without a computer screen, visual feedback for the controllers can make sense, i.e. that your faderbox displays the current value of the parameter you are controlling. This is of course only possible for controllers that provide a controllable visual feedback, so it's limited to iii) and v).
b) controller snapping:
Typically, MIDI CC sources (like those mentioned in the "Types of Controllers" section) send messages when you move them. Now here's the problem. Let's assume you place your footpedal (which you use to control output volume) to toe-down (i.e. value 0) and then load Mobius, which initializes the output volume to 127.
Using the technologies to address the use cases:
Starting with use case a), this can only be done using technology 2. Obviously, this requires the controllers to be of sort iii) or v).
As a sidenote, this can also be used to transmit non-controller information for visual clues - e.g. the circular loop position display could be sent to a LED ring round an unused controller.
For use case b), the mapping is somewhat more complicated:
For controllers ii) and iii), 3. can be used, while 1. and 2. is possible for all kinds of controllers.
Putting it together
As we've seen, there's only one technology that will solve both use cases at once, namely 2. On the other hand, the only technology that works with all kinds of controllers is 1. 3, finally, is only of use for controllers of type ii) and iii) and offers better handling than 1, but (like 1) only solves use case b).
So there's a reason for any technology to be implemented:
1. works with all kinds of controllers for use case b)
2. solves use cases a) and b) and allows for additional visual feedback, but requires controllers that support this technology.
3. solves use case b) for controllers of groups ii) and iii) which support this technology.
moinho's recommendation
As said before, none of these technologies does everything perfectly. From my personal experience with controllers, 3 is required the least, so a first implementation should perhaps focus on technology 1, followed by 2.