NOTE ON/OFF handling, when switching off a port.

[HighStop]

I have a question about using MRCC live.
If you hold a chord on a keyboard (note on) and switch off the output that received the chord (note on), then what happens:
A. The chord will hang forever.
B. The chord is stopped when the port is switch off using "All Note Off"
C. The chord is stopped when the port is switch off by sending "Note off" on the keys used.
D. The chord stays until you lift your fingers from the keyboard (note off).

I hope that it does "D" and if it does will it work with both "Note Off" and "Note On velocity = 0"?

The same goes for other type of MIDI message, if something is send while a port is on the MRCC should track it and allow
"reset" message to get thru after the port is switch off.

Thanks For some nice devices that I hope to add to my collection soon.

Kent 

[Darryl]

Interesting idea, we'll keep it in mind. As implementation progresses we'll be looking at these types of innovations to make working with MRCC "smart".

[oldgearguy]

I have a question about using MRCC live.
If you hold a chord on a keyboard (note on) and switch off the output that received the chord (note on), then what happens:
A. The chord will hang forever.
B. The chord is stopped when the port is switch off using "All Note Off"
C. The chord is stopped when the port is switch off by sending "Note off" on the keys used.
D. The chord stays until you lift your fingers from the keyboard (note off).

I hope that it does "D" and if it does will it work with both "Note Off" and "Note On velocity = 0"?

The same goes for other type of MIDI message, if something is send while a port is on the MRCC should track it and allow
"reset" message to get thru after the port is switch off.

Kent 

There's a good reason that no MIDI patchbay (that I know of) has done this before. If you switch off/out a port (or change destinations) the MIDI patchbay cannot just send the rest of the MIDI commands down the pipe to the old destination. If that destination is now hooked to a valid new device, those messages could change/mess up that device's current patch. Same with sending a reset - you cannot know what is on the other end of the wire so sending any commands would be neutral at best and produce unexpected results at worst.

Logically, the patchbay should be as neutral as possible and if unexpected sources/destinations are switched around (or off) the patchbay shouldn't attempt to fix or clean up the situation. Basically, you're asking the device to correct for a user error.

Now, I can agree that if the patchbay allows receiving of program change messages to automate configuration changes, it should (in this case only) verify that all streams are cleaned up/terminated properly before changing patches, but even that could be a programming headache to implement correctly and handle all the edge cases w. clock, sysex, etc.

[Darryl]

Worst case, there will be a "panic" button on MRCC that will send all notes off message to all active (routed) outputs.