I’m looking into adding support for binding catchup/takeover/jump preventation and while I’m at it I might add support for rotary encoders.
First off, which name do you like best:
Jump Prevention (my preference)
Catch Up
Take Over
Something else?
Second, there’s a few different ways rotary encoders send MIDI data. I think I’ve got a device here somewhere with a rotary encoder, but I’d like a few more samples.
So, if you have a device with a rotary encoder, I’d be interested in a recording of it as follows: (Timing and angles don’t need to be precise)
[EDIT: To be clear - I’m after recordings of endless rotary encoders, not just a standard knob control].
Setup Cantabile’s recorder to record the port that the device is attached to.
Play a note (just as a waypoint)
Slowly rotate the encoder right 180deg (over about 3 seconds)
Play another note
Slowly rotate the encoder left 180deg (3 seconds again)
Play a note
Quickly rotate the encoder right 180deg (over say 0.5 seconds)
Play a note
Quickly rotate the encoder left 180deg (0.5 seconds)
Play a note
Stop the recorder.
Send me a copy of the file with some details about the device (in case I need to look up it’s user guide) and I’ll make sure Cantabile works with it.
Jump Prevention seems clearest. I know Take Over is used in some products but it’s not obvious what it means until you know. Not keen on Catch Up.
Very excited that this feature is coming up - it’s the one last remaining thing preventing me from moving all my performance data into Cantabile and being able to use a “dumb” controller.
Experimental Build 3160 available now has support for both Jump Prevention and Rotary Encoders. Both need more real world testing so please report any issues.
“When the Jump Prevention mode is selected if the source and target values are out of sync, Cantabile waits until the value is moved past the current target value before the binding starts working - in order to prevent large jumps.”
Am I right in saying this out of sync detection starts when the binding becomes active? If so, if a binding remains active across a song state transition, will jump prevention kick in again if the target parameter is different in the new state? And if the target parameter is updated by a trigger, will jump prevention kick in similarly?
How about if I jump on my expression pedal, so the value changes rapidly in one direction; will jump prevention then think the source and target are out of sync, and go into jump prevention mode? This would be undesirable if so - the jump was intentional.
It seems to me that jump prevention should only be allowed to kick in when a binding becomes active, or when the target parameter is changed by a state change, or changed by a different binding.
Some clarification on how this works under the covers please!
After a binding sends a value to a target parameter it reads the value back and stores it.
Next time the binding is invoked it compares the saved value to the current target value
If it hasn’t changed then things are still in sync and binding takes place.
If it has changed then it enters a mode where it waits for the source controller to touch or cross the current target parameter value.
In practice, this means:
Large jumps by moving a slider very quickly will always works and won’t confuse the jump prevention.
When the binding is initially loaded, the “previously set value” is set to a very out of range value so the first binding event is always in “out of sync” mode.
If the target parameter is changed by another means (states, another binding, loading a preset, adjusting it with an on-screen controller etc…) the binding will automatically reset into out of sync mode.
Just an extra note to say, jump prevention is working great for me!! Quite a lot of my band’s songs have volume and other controller fades, and it’s handling everything beautifully
