Raw MIDI data split into 250-byte chunks instead of 256 on Mac?
On Mac OS X long SysEx messages are supposed to be split into chunks of 256 bytes each. When routing a Capture object containing such a long SysEx message into a MidiOut object and then dumping the sysEx message, this is not happening: Max is sending chunks of 250 bytes instead, so the receiver has to resolve that situation in some way.
This also happens when explicitly slicing the Capture output with a "zl iter 256" intermediate object.
Is this a bug or what? Anyone from Cycling?
No Mac users sending big SysEx messages out of Max? Surprising…
Where is it stated, that long sysex is split? that is new to me…
In Max 4.x most list objects had been restricted to 256 elements, but this limitation is gone at least for the zl group of objects.
If you would post the patch which exhibits your problem, together with some info about your device, including the sysex specs, there is hope…
(though I don’t have any sysex spitting device here anymore, got rid of the last some decades ago…;-)
the split into packages ("chunks") is part of the CoreMIDI specs. It’s not something "visible" if not e.g. in debug mode on the receiving application, where you can check the actual packet datasize of the incoming MIDI data.
In my case I noticed that while debugging the sysEx decoder of a synth engine I am developing in c++.
It’s not "wrong" to have 250 bytes long chunks, but let’s say it is "very unusual" in OS X and it may cause issues on the receiving side, because you’d generally expect chunks of 256 bytes in CoreMIDI.
This sounds as if you would write an external. Within Max the only conncetion to CoreMidi is through the built in objects, and I don’t know how they would exhibit this problem (they must not…)
The recent problems of ctlin skipping values had been an issue with the chunks as far as I know, but it is finally resolved in the latest builds, maybe that is related to your problem…
It seems this is better covered in the dev forum though…
I just contacted Cycling ’74 support, who verified this issue and determined it is caused by the Max/MSP CoreMIDI driver object. They also said this is likely to be fixed with the next build.
Victor – please try the attached CoreMIDI object. This comes from Cycling, not from me – I’m just a messenger!
Thanks Dan. Cycling ’74 support provided me with that file yesterday as well, and that works fine (256 bytes chunks). The issue is solved – and big thanks to Cycling ’74 for the great support.
I’ve been trying to send sysex messages from Max/MSP to Max Magic Microtuner, and I’m encountering the "long sysex" problem. I’ve upgraded to 5.1.3 and I don’t want to screw up here. How do I install the "incremental" mentioned above; Do I simply replace the coremidi.mxo in the mididriver folder?
Yup – just replace the old one. If you want to be extra careful, you could save a copy of the old one somewhere else (outside of Max’s search path), just in case the incremental fouls things up for you.
I saved the old and good thing. When I replace it with the new coremidi.mxo, the only midi Max/MSP can "see" is the AUsynth. To be clear, with the old coremidi.mxo, Under "Midi Setup" I can see all my midi programs (Max Magic Microtuner, MidiKeys, Sysex Librarian, etc) as well as the AUsynth. With the new coremidi.mxo, I can only see the AUsynth. I tried re-starting Max/MSP, but it stays the same. When I double click on the midiout object in my patch, the only option is AUsynth. As soon as I plugged the old coremidi.mxo back in, all the other midi "devices" re-appear.
and just to be even more clear, I’m replacing the coremidi.mxo in the mididrivers folder.
Quit Max and delete the "Max 5 Preferences Folder" in your user Library/Preferences.
(keep a copy of it somewhere else, I you have a complex setup.)
Doest it work now?
No, I get the message posted below in the Max window on launch AND there is only the AUsynth in the Midi Setup, nothing else (including "to Max/MSP"). Would it be a good moment to mention I have a 1.5 Ghz PPC powerbook? Maybe the new coremidi.mxo isn’t PPC friendly? Jawnypants
coremidi: unable to load object bundle executable
2010-03-11 16:09:55.628 MaxMSP[13624:20b] Error loading /Applications/Max5/Cycling ’74/mididrivers/coremidi.mxo/Contents/MacOS/coremidi: dlopen(/Applications/Max5/Cycling ’74/mididrivers/coremidi.mxo/Contents/MacOS/coremidi, 262): no suitable image found
. Did find:
/Applications/Max5/Cycling ’74/mididrivers/coremidi.mxo/Contents/MacOS/coremidi: mach-o, but wrong architecture
Jitter 1.7.0 installed
cosm version: ‘Prince Jammy’
The incremental coremidi.mxo is Intel Mac only at this time.
can anyone imagine a way to send sysex (particularly long ones) messages on a mac PPC? Can I simply split the sysex into 256 byte chunks and send it sequentially?