Creating a Max for Live device that periodically sends a SysEx message will randomly stop other midiout instances from working, even in other devices. This happens even for a "thru" MIDI effect device that doesn't do anything other than connect midiin to midiout (with or without MPE enabled). The MIDI Monitor M4L device included with Live also demonstrates this problem. The blocked midiout will eventually unblock after receiving enough other events. Sending a SysEx message through the blocked midiout will often unblock it immediately.
This happens even if the SysEx M4L device isn't routed to a MIDI output at all.
Usually, this causes stuck notes, but events other than Note Off get lost or delayed as well. The blocking tends to happen when a large number of MPE events are generated in quick succession. A higher frequency of SysEx events tends to cause more blocking (300ms or shorter interval, but 900ms still causes problems).
Details:
Ableton Live 12.1 (in trial mode)
Max 8.6.5 (though this also happens with the bundled Max)
M2 MacBook Air, macOS Ventura 13.7
Intuitive Instruments Exquis, connected via USB
I'm working on getting custom note layouts on the Exquis to work in a M4L device. This requires periodic SysEx messages to keep it in an app-controlled mode, instead of its default standalone controller mode.
I can easily demonstrate this problem and produce traces via an external MIDI Monitor app and some IAC devices, using the Exquis for the high-rate MPE events. Not including the log because it's enormous, and will require annotation.
Steps to replicate:
In a new set, create a M4L MIDI Effect in Track 1. Enable MPE, and add a tempo 300 to trigger a sxformat 240 125 247 (shortest possible SysEx). Select No Input and IAC Bus 1 as output.
In Track 2, add MIDI Monitor as a MIDI Effect. Select Exquis (with MPE enabled) as input, and IAC Bus 2 as output.
Press and release keys on the Exquis, wiggling them to trigger MPE events, while observing an external MIDI Monitor app. Eventually, some MIDI activity dots to the right of the MIDI Monitor Effect will get stuck on, and the external MIDI Monitor will show a lack of new output to IAC Bus 2.
Notes:
This does not happen if I start a standalone instance of Max (in demo mode) to send the periodic SysEx messages. I have also observed Live ignoring all input from the Exquis after it sends a SysEx message, but I can no longer replicate that problem.
This is a serious bug that will negatively affect my willingness to purchase a license for Live.
I also noticed that the M4L midiout does quite a lot of processing on its input, instead of passing it through unmodified. It will reassign MPE channels, and add pitch bend or channel pressure events to a Note On event. It also seems to delete duplicate Note Off events. This is somewhat surprising, and I wish it were documented. It also provides more opportunity for bugs.
Has anyone else seen any of this, or have any ideas about it? Thanks.
sending SysEx through midiout causes other midiouts to randomly stop
-
- Posts: 6176
- Joined: Mon May 15, 2006 12:15 pm
Re: sending SysEx through midiout causes other midiouts to randomly stop
Not sure I will have the time test to be honest.
But did you reach the official support ?
But did you reach the official support ?
MacBook Pro 13" Retina i7 2.8 GHz OS 10.13, L10.0.1, M4L.
MacStudio M1Max 32Go OS 12.3.1
MacStudio M1Max 32Go OS 12.3.1
-
- Posts: 22
- Joined: Fri Jul 12, 2024 9:56 pm
Re: sending SysEx through midiout causes other midiouts to randomly stop
Bit late and have not 100% soaked up your issue.
Have you tried sending on another channel?
Also, is your SysEx message correct? I know that wrong messages tend to hiccup Ableton or the Midi HW device.
The message 240 125 247 seems to be a bit short for me. But I'm not an expert expert and a don't know how your device processes SysEx. Devices I know of use an exclusive header.
E.g. a SysEx message on my Minilogue has a format like below (in hex):
F0, 42, 3g, 00, 01, 2C, ..., F7 where:
F0, 42, 3g, 00 ,01, 2C -> header (Excl. Status, Korg ID, etc., where g represents the channel number)
.... -> Function and Payload
F7 -> EOX
So, one sxformat object with a full SysEx command e.g. looks like this (get Program Dump from the Minilogue)
Is the device transmitting the Acknowledgement back you expect (as SysEx message, like Data Load Completed or Data Error)?
Have you tried sending on another channel?
Also, is your SysEx message correct? I know that wrong messages tend to hiccup Ableton or the Midi HW device.
The message 240 125 247 seems to be a bit short for me. But I'm not an expert expert and a don't know how your device processes SysEx. Devices I know of use an exclusive header.
E.g. a SysEx message on my Minilogue has a format like below (in hex):
F0, 42, 3g, 00, 01, 2C, ..., F7 where:
F0, 42, 3g, 00 ,01, 2C -> header (Excl. Status, Korg ID, etc., where g represents the channel number)
.... -> Function and Payload
F7 -> EOX
So, one sxformat object with a full SysEx command e.g. looks like this (get Program Dump from the Minilogue)
Code: Select all
sxformat 240 66 48 0 1 44 16 247
Is the device transmitting the Acknowledgement back you expect (as SysEx message, like Data Load Completed or Data Error)?
-
- Posts: 22
- Joined: Fri Jul 12, 2024 9:56 pm
Re: sending SysEx through midiout causes other midiouts to randomly stop
Also, there is no midi clock interfering? That's an issue I have if configured the Minilogue the wrong way. Though with larger SysEx blocks and not small messages like above.
Re: sending SysEx through midiout causes other midiouts to randomly stop
sorry if I'm not fully understanding you problem but to be clear did you reproduce this problem without the exquis if possible; using a midi interface or IAC?
I know not all midi interfaces are created equal; and some don't handle high volume of data well; some other don't handle sysex well.
on a related note are you clocking the midi data using a coll object to slow it down to manageable speeds? (basically buffering the midi through the coll object and sending it all in a clocked sequence in a loop. might be tricky maybe with MPE I'm not sure; I do it with CC because if don't midi will simply hang). Or easier solution you could use a speedlim object
I don't know how it's related to the sysex part but the rest of the description looks like the midi connection is simply saturated (remember midi connection original speed is 31,250 kbits/s so it's super easy to saturate). just an idea.
I know not all midi interfaces are created equal; and some don't handle high volume of data well; some other don't handle sysex well.
on a related note are you clocking the midi data using a coll object to slow it down to manageable speeds? (basically buffering the midi through the coll object and sending it all in a clocked sequence in a loop. might be tricky maybe with MPE I'm not sure; I do it with CC because if don't midi will simply hang). Or easier solution you could use a speedlim object
I don't know how it's related to the sysex part but the rest of the description looks like the midi connection is simply saturated (remember midi connection original speed is 31,250 kbits/s so it's super easy to saturate). just an idea.