I’ve finally had some time to do some more experimentation with this, and have some new information.
As a reminder, I have a “pedal fade” rack that outputs controller 16, value 0 at song start, and maps expression pedal input to controller 11. The output of this goes to a strings rack, which has two bindings, from cc11 and cc16 both to a Cantabile gain control on an empty rack (rack stereo in routes straight to rack stereo out - basically the rack just acts as a gain control - I used to use FreeG for this). The cc11 binding is set to “Absolute with jump prevention” and the cc16 binding is set to “Absolute”. The idea is that cc16 always sets the desired start level, and expression pedal input won’t do anything until it passes the level set by cc16 (jump prevention). What I was finding was when this happens at the start of a song, the cc16 value appears to be ignored, so jump prevention on cc11 doesn’t work.
What I’ve found now is that jump prevention does appear to work, as long as some controller data passes through the “Absolute with jump prevention” binding before the absolute value is set with the cc16 binding.
To clarify, these are the two scenarios:
CC11 - “Absolute with jump prevention” binding to fader
CC16 - “Absolute” binding to same fader
Failing scenario:
Song state load
CC16 = 0 Set fader initially to zero (done using song state load trigger)
CC11 = 100 Fader incorrectly moves to 100 and tracks CC11 - should have remained at zero for jump prevention
Working scenario:
Song load
CC11 = 1 Set fader to something arbitrary on state load trigger with no delay
CC16 = 0 Set fader to zero, using song state load trigger after delay
CC11 = 100 Fader correctly remains at 0, until CC11 moves to 0, then tracks CC11
@brad , In this thread, you describe how jump prevention works as follows:
- 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.
Could it simply be that my cc11 binding has never sent a value to the target parameter in (1), so doesn’t have a stored value to compare against for jump prevention in (2) ? If that’s the case, it means jump prevention can only work properly with one binding. Wouldn’t it be more correct to set that initial stored value from the target parameter value, when jump prevention is enabled, so that in my scenario the binding starts in “jump preventing” mode?
Neil