Hi. I have a favorite old plugin, Mr Ray, which does not respond well to the continuous sustain input from my VPC-1 Controller Keyboard. (The damper samples are re-triggered with every sustain value, especially on release values.)
The Edge Trigger description says “If [edge option] checked the source controller is treated as a momentary MIDI button that sends a value > 64 when pressed and < 64 when released.”
I tried filtering controller #64, but it actually only works on pressing the pedal, but not on release.
I don’t fully understand how to set the “Target Values” which have 127,0 as default.
Maybe the function is intended to be Only Positive Edge Triggered, and not negative as well, as I have interpreted the text. (?)
Can anyone tell how to set these to get the desired result ?
Thanks
Stephen
Hi Stephen,
I have a similar problem using the Roland RP3 pedal which sends 0~127 like an expression pedal. I use Performer and currently use this binding to resolve this. Solo and Performer can both do this.
In the past I used 2 route filters to do it like these. This solution works with all versions of Cantabile. Note that both have the same source input.
example routes
1st route filter
2nd route filters
Hope this helps. 
Dave
Hi Dave. The first binding works great. Many Thanks.
I’m not sure I fully understand why it works also for the Release of the pedal since the condition only specifies =127.
Cheers,
Stephen
Hi Stephen,
I’ll try to explain a bit more. The condition field acts as an if / then / else connection for the simple type. So in this case “if” the continuous value coming in = 127 “then” send the 127 target value (target value #1), “else” send 0 or the alternate value (target value #2). When you use the “Range” type of condition it acts as an if && if / then / else switch so “if” range value 1 “and” “if” range value 2 are matched “then” send target value #1 “else” send value #2. The target values can be changed of course but the default will be 127 for value #1 and 0 for value #2.
Cheers,
Dave
Thanks Dave. I get this now.
I experimented a bit. I guess with your latest method you are creating an additional route, as well as the one made by dragging the line between the rack midi input and the plugin.
I found you can monitor the Midi In of the plugin, rather than the route itself, and I see that both sets of sustain are received, i.e. via the dragged line and the binding.
I suppressed the #64 controller messages in the Midi Route (dragged line), and now I can only see the 127 and 0 values being sent.
The only one down side of this, is that disabling the original route, leaves the new binding active.
Its not a big problem as the plugin will just receive the sustain messages, but no notes in this situation.
I’m not picking holes BTW Dave. It was great you took the time to answer, so it seemed right to share the further details I found. I found the monitor for the Midi in the right click menu on the top of the plugin icon.
Interested to know if you see the same.
Best Regards,
Stephen
Hi Stephen,
I checked out your post and see that you use the wiring view. I use the index view and it makes multiple routes with a common source sent to the same target easier to see and program. That said when you are in wiring view both routes are still there but one overlays the other making it hard to see the different filters used in each route but the MIDI monitor still sees both routes. I found that I was receiving duplicate note on/off, PG ch, etc because both routes were the same source so I suppressed the all but the CC messages I wanted to filter on the first route. The filters on the second route are the same as shown in previous post so it allows all the other messages blocked on route one and together they prevent duplicate note and other messages since the source is the same for both routes. Separate routes are required to do complex filtering tricks as shown here.
The following shows the MIDI monitor results for the target.
pedal press
pedal release
3 notes & a few assorted CC messages
So in my tests here it checks the boxes for treating the CC64 while passing the other CC messages without duplicating them.
Since this is an input route based solution it will not work well if you have bindings that also work on this input source so disable any bindings assigned to this task while testing that might cause conflicts.
Anyway, Thanks for posting , these are the results of my tests with the changes I showed you. Maybe they will work for you in your experiments.
Dave
Hey @dave_dore, how goes? 
I’ve been trawling through posts to try and address a, seemingly, simple issue, but…
It is simple enough to address a switch.
In this case, I’m using and FCB1010 to issue a controller to turn an effect on/off.
The effect is also controlled by state condition, which can put the FCB out of sync with the effect, requiring two presses to reestablish the correct status.
The desired outcome is that whenever I issue the controller, the receiver should change status. I guess ‘edge triggered’.
As there is no LED switch on the FCB non stomp switches, I’m using the Controller Bar to identify the current status. It works great, except for the sync issue, which requires the two press fix.
I’m using an UNO EPROM which is not BiDi.
Is there a purely binding approach to have the on/off status switch whenever a command is received, regardless of its value? Latches don’t seem to get me there.
Thanks for any and all insights!
Hi Adrian,
Things are going OK, lots of gigs this month anyway. Thanks for asking. I hope things are well with you too.
Regarding your question I do have some thoughts. For starters a good approach to this issue is for you to use a momentary style switch on the FCB 1010. In Cantabile it is referred to as a No Edge Button. Mechanical toggle switches can be a bear to keep synced in Cantabile whereas the momentary type are more friendly. So once that’s established you could have a single binding that addressed the toggling of the FX switch (I assumed the running switch for this example). Since the Run and Bypass Mode is checked for the FX plugin (Valhalla Supermassive) it will remember the last state is was and return the value instantly on a state change. The FCB 1010 momentary switch will toggle the current value of the Run and Bypass Mode no matter it’s state on the first press.
Does this look like it might fill the bill?
Dave
Thx for the thoughts!
I suspect I’m going to get into trouble with some associated events which need to know the status in a way that ‘toggle’ doesn’t accommodate - but if they are all bound to the on off condition of the plugin - that could be bullet proof.
I shall report 
Looking good so far! Had to alter the syntax a little to address an on/off parameter within the plugin, tweaked the FCB so that it doesn’t toggle, and the Controller No Edge Button addresses the need to action every time the FCB is addressed.
A few months back, Brad advised that this (Dave’s) kind of approach, as opposed to the cack-handed way I had achieved (sort of cough cough) the desired result, reduced dependency.
This has been a bit of an eye opener as to how efficient things can be. I had built on several independent switches and that was a recipe for irritating errors - like needing two button presses to get sync back.
Tomorrow, I redo a lot of bindings in need of a good Doreing!
As ever, you are a diamond @dave_dore
Hi.
For the continuous to switched sustain, rad made a filter in the end which does this in one simple setting.
It is some time now since I have been active … soon again I hope .. but I just saw this post go by.
Cheers
Stephen