The way i’m utilizing the controller is I modify the incoming PC to a more generic controller that doesnt change patches by default. Some triggers are toggle for play, tap tempo, playing samples etc. so sequential triggers are oftentimes inevitable.
I first thought of using the incoming midi message’s length since the fixed triggers only send one PC message while the A/B one sends the current plus the new one. Staring at the stream byte manual, I still have no idea how to approach such algo xD.
Edit: I’m starting to admire people who code for a living. This sh aint easy lol.
OK, well if you do press some of these multiple times we have to look at something different. The A/B message isn't a separate message so we can't use it's length to distinguish it.
What we can try is to use timing to detect it. If two program change messages are very close together (say within 10ms) then we discard both of them. Here is some code. I cannot test this at the moment, so hopefully it will work (it may not even compile!)
# setup if load alias Q0 threshold assign threshold = $10
# internal alias L0 queued assign queued = 0 end
# handle FC-50 program changes if M0 == C0 if M1 < A if queued == 1 # pc already queued, ignore this # and flag to cancel queued assign queued = 0 else # no pc queued, queue it assign queued = 1 send F0 7E M1 F7 +I +Dthreshold end block end end
# handle queued program change if M0 == F0 7E if queued == 1 # send message if still ok send C0 M2 # flag as nothing in queue assign queued = 0 end block end
Note, this does add 10ms latency to the button pushes. You can try reducing that 10ms to something lower and see if that works.