Very easily reproducible thing I’m running into now which I’m sure was previously working normally. I quite often manually manipulate toggle states even for simple things (rather than using Toggle Mode) because it offers more control over precisely what provokes the state change.
Today I’ve discovered this no longer works (see attached). Two messages on an otherwise blank preset. MSG 1/POS 1 toggles engage, MSG 2/POS 2 toggles disengage. Toggle Mode is not set on the preset. Here are some test outcomes:
With both messages as shown, preset state does not change on switch press at POS 1
If I use the editor to toggle the preset, switch press at POS 2 successfully disengages.
If I set MSG 2/POS 2 to “no action”, or remove it entirely, the preset engages w/ switch press at POS 1
If I flip the order of the messages (i.e. MSG 2 above MSG 1) preset engages on press of POS 1 but will not disengage with press on POS 2.
If I carry out these same tests with the trigger of both messages set to “release” instead of “press”, same outcomes are shown.
This seems to indicate something strange with the filtering/message order behaviour.
Let’s carry on:
If I set BOTH messages to “Engage Preset”, the preset successfully toggles on press at POS 1
If I set MSG 1/POS 1 to Disengage and MSG 2/POS 2 to Engage, no outcome on press at POS 1
If I set MSG 1/POS 1 to “no action” and MSG 2/POS 2 to Engage, no outcome on press at POS 1
If MSG 1/POS 1 is set to Engage Toggle on Press, MSG 2/POS 2 to Disengage on Release, the preset toggles on with press and then immediately off on release of the switch. Release of switch seems to obey the new state toggled by the prior press message.
With the above modification, If I move MSG 2 (release pos 2 disengage) to first in the order, ahead of MSG 1 (press pos 1 engage) the same on & immediate off behaviour appears. Seems to indicate that midi message order does not influence behaviour as I proposed just a minute ago. The message now on release of POS 2 is sent before the press of POS 1 can change the state to POS 2, so the instruction to disengage should logically be ignored, but it is obeyed.
Based on this I can only conclude that filtering messages for positions seems to be broken for some reason, at least in this use case / for toggling states. Any assistance with this would be greatly appreciated!
