Midi Channel Bandwidth or Crosstalk on Mac
I am currently in the testing phase of a set of Max for Live projects that can be triggered to send out a bunch of midi data to configure a set of physical midi devices remotely. On Windows everything works as expected, but on mac a decent chunk of the information gets lost in transit. It only happens when multiple devices are sending messages at once. If I output one device at a time everything works perfectly though. This is the setup in Ableton...
Max for Live Device 1 >> Midi Channel 1 >> Physical Device 1 (set to Midi Channel 1)
Max for Live Device 2 >> Midi Channel 2 >> Physical Device 2 (set to Midi Channel 2)
Max for Live Device 3 >> Midi Channel 3 >> Physical Device 3 (set to Midi Channel 3)
Max for Live Device 4 >> Midi Channel 4 >> Physical Device 4 (set to Midi Channel 4)
Max for Live Device 5 >> Midi Channel 5 >> Physical Device 5 (set to Midi Channel 5)
Flow of midi
Computer USB out >> Physical Device 1 USB in >> Physical Device 1 Physical Midi Port Out >> Midi Box that splits the Output to 4 outputs >> Physical Device 2-5 receive outputs 1-4 of midi box.
I have the built the devices within Max 8.1.11 (7de540) through Ableton 10.1.43 Suite on Windows 10 Home 19044.1826
I am testing on Windows as well as an Intel Macbook running Max 8.2.2 (85d93eb32e9) through Ableton 11.1.6 Suite on MacOS Monterey Version 12.2 (as well as an Apple Silicon Macbook with a similar setup to the Intel one)
Any insight into how Mac handles midi output differently is greatly appreciated!
I am commenting to bump this post because it has been edited significantly as I narrowed down the problem to something midi related. I wasn't sure how to delete the old one and just make a new post. Sorry!
Hello Trevor,
if I read you right at one point in your setup you have a bottleneck when your physical device 1 receives MIDI via USB and sends it out by DIN. USB MiDI allows much higher speeds than the DIN port version.
If you send out a lot of data via USB at some points packages must get lost when converting to the slower speed.
Maybe Windows limits the internal USB MIDI speed to the 31250 Baud of the MIDI 1.0 specs, hence no packages are lost. As I said I am guessing.
you could try to speed limit the messages your M4L devices send, not to ex the DIN port velocity.
Hey Jan, that's a good insight, I did not think about that. I would need a way to force the baud rate within max, but I did not see an object or attribute for that. Instead, I changed my code so messages are sent to each physical device one at a time. I still need to do some further testing, but it seems to be working now! The whole sequence will take much longer than before, but the time frame is definitely acceptable. Thank-you for your help!!
you could just put a [speedlim] object before sending the MIDI messages to limit output speed.
an ideal implementation would allow the user to set the speed (aka speedlim throughput) himself.
but i would not count on the transfer speed of DIN MIDI, some devices can recieve sysex only much slower than that, and you can easily overload the buffer of a receiving device by sending 2 presets dumps after another and things like that.
Sending the messages to one device at a time seems to be working consistently and reliably so far so I will stick with that for now. I messed around with speedlim and noticed I might run into a similar behavior if I sent to many messages to that as well. Appreciate the help, you guys rock!