Div Slomin

I'm working on a set of Max for Live devices which use [send] and [receive] for sidechaining MIDI messages and combining them in interesting ways with the regular MIDI messages that come through [midiin] and [midiout].  This mostly works, but when there are a lot of messages flowing at once, as when one of the inputs is a looping clip, the device will sometimes stop emitting any MIDI output, requiring the device to be reloaded from the Ableton Live browser.  Here's a minimal reproducible example:

I guessed that the bytes from the respective streams were getting interspersed, thereby confusing [midiout] and leaving it in an unresponsive state.  So I changed my code to make sure that each stream had its own [midiparse] to accumulate the bytes and emit the MIDI messages atomically.

But I'm still seeing the same issue.  Adding message boxes for debugging, I can see that bytes are still flowing out of the [midiformat] even when it gets in the "stuck" state.  Any ideas?

Edit: I'm using Live 12.0.2 and Max 8.6.2 on Windows 11.

I'm working on a set of Max for Live devices which use [send] and [receive] for sidechaining MIDI messages and combining them in...

midiout-stops-working-when-merging-midiin-with-sidechain-midi-from-receive

you will have to live with crashes if you combine inputs in such way.

to solve this problem, remove midiout at the output and replace it with

print or something else that captures the stream,

which will give you idea what you are sending to midiout.

if it was max, I would use separated midiout per stream,

no idea,  it has it's own head when it comes to midi output from a track

I agree... I would try two separate [midiout] objects, one for each stream.   I don't think there's any limitation in Max for Live devices about this.

This version exhibits the identical behavior.

I don't find this surprising since, like the original version, code somewhere in the stack is having to merge two streams of single-byte Max messages and has the potential to erroneously interweave the bytes from different MIDI messages.  But in the second version, the Max messages in the streams being merged are compound, not single bytes, so that shouldn't be able to happen.

I feel like I'm barking up the wrong tree.  Should I be looking at scheduling priority (deferlow)?  Rate limiting?  Those are obviously not attractive options for a realtime system, but I'm at a loss for other ideas.

you should maybe take it that max and live do not function in same way.

noteout maybe helps you a bit as it does not mess with status bytes.

which says that midiout is the correct way to send MIDI output back into Live.  For what it's worth, I'm handling arbitrary MIDI messages, not just notes (I'm posting minimal test cases that are significantly simplified from my actual application).  I'm also happy enough to do my own byte and nibble level MIDI parsing if I can get access to the right I/O and synchronization primitives in Max, if that's what it takes for a workaround; I've been writing standalone MIDI applications in C for a few decades now.

I had a thought that maybe forcing all the messages come through the send/receive door might help with any scheduling difficulties.  But no luck.  This one still exhibits the same behavior.

This isn't realtime anyway if you use send/receive. Realtime would be to merge midi by setting the output routing of other tracks to the target track.

The actual application is an arpeggiator that combines a sequencer-driven pattern from one stream with live played notes from another stream in a mathematically-derived manner.  The two streams need to be passed to different parts of the algorithm.  If Live supported more than a single MIDI channel within a track, then I could handle the two streams via multiple channels on the same port, from Max's perspective, using Live's routing to get them onto that port regardless of origin.  But since Live does not support this, I have to use global send/receive sidechaining to be able to tell them apart.

Source Audio, while I originally thought your suggestion of using noteout instead of midiout was inapplicable here, I pursued it anyway, extrapolating to the other MIDI messages.  This version actually appears to be working -- thanks!

And it works without the extra send/receive too.  Problem solved!

Nevertheless, there are ways to distinguish between 2 streams. For example, you can convert stream 2 to sysex, send it to track 1, then filter it out again and convert it back. But if you're happy with that, everything is fine

"The actual application is an arpeggiator that combines a sequencer-driven pattern from one stream with live played notes from another stream in a mathematically-derived manner."" Same thinking

midiout stops working when merging midiin with sidechain MIDI from receive