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