MIDI Port corruption?


    Feb 18 2016 | 3:04 pm
    In some situations my patch stops sending MIDI as it should. Using MIDI monitor (OSX) I found that Max was sending "invalid" messages. Re loading the patch didn't make any difference. Just after closing and opening Max all returned to the expected behaviour.
    After some trails and errors I guess that in some situations sending "out of range" values to a MIDI port, renders that MIDI port unusable.
    So my questions are: - Is this possible? - Is there some way to recover a MIDI port without closing and opening Max?
    Thanks!

    • Feb 09 2020 | 8:10 am
      I'm running into this problem as well, but not because of out of range values. It occurs intermittently when I adjust a control manually that sends a MIDI message while other controls are sending automated messages. My assumption is that multiple messages are getting sent without a sufficient delay between them. I've tried using zl.queue and it seems to happen less, but still too often to be reliable. If I come up with a solution I'll share it here. Or if anyone else has an idea? Thanks!
    • Feb 09 2020 | 1:31 pm
      Maybe [speedlim] could help.
    • Feb 09 2020 | 1:39 pm
      In first place it would help to provide more information about the max patch and Midi Device in use. There are midi interfaces simply not capable of dealing with larger ammount of data, worst case being cheap chines midi - usb cables, that can't even send more than 2 notes at same time.
    • Feb 09 2020 | 5:15 pm
      [speedlim] is what fixed it for me. If my patch was sending a stream of MIDI messages without any limit on the rate for an extended period of time (eg. more than 15-20 seconds), the port would stop working entirely... I originally thought it was some issue with loopmidi, but it happened when I used my MOTU MIDI interface as well.
    • Feb 10 2020 | 5:50 pm
      Brilliant! [speedlim] solved it! Thanks everyone for your responses. The MIDI device in use is the Prophet REV2 Synthesizer from Sequential. With [speedlim] in place I'm actually able to send even faster streams of NRPNs to it without the "invalid message" response.