03-11-2021, 08:40 AM
(This post was last modified: 03-11-2021, 10:18 AM by Dirk Offringa.)
(03-10-2021, 08:34 PM)Jesse Johannesen Wrote: I'll add this to the list of bug sightings and see if there's a good solution to the issue next time we take a look at NDLR firmware. Thanks for finding this and giving a good description of what might be happening that may make it easier to track down.
Jesse
I found the issue: the NDLR issues "all notes off" (CC#123) messages followed by regular "note off" messages which causes the system to hiccup. Filtering out CC#123 fixes the issue. Also, when the NDLR stops, CC#123 is issued on all 16 channels, causing everything that might be running elsewhere to silence too, depending on your routing. I am not sure if this is a good idea. One might want to stop and start the NDLR while playing live on other midi instruments, and unsolicited "all notes off" messages are unwanted of course.
If the NDLR is the only controller in the system, that could be of some interest, but in a more elaborated set-up it might just interfere with other stuff. I believe that the NDLR should issue "all notes off" messages only on request (panic button) and make sure the system is robust enough not to generate hung notes.
cheers
Dirk
EDIT 1: Every once in a while, when the NDLR is stopped (I use ext sync DIN B) it forgets to send "note off " messages, resulting in hung notes. That was not obvious because of the preceding CC#123 but now the I filtered that CC out, it's a bit annoying. As said above, the system needs to be rock solid , not needing these CC#123 messages ;-)
EDIT 2: CC#123 is not processed with real-time priority by most devices (like note on-note off's). It's a "panic" message. Each device has a specific way to react on such a message and can take time to recover. So it should not be used otherwise......