Raw MIDI data split into 250-byte chunks instead of 256 on Mac?

Mar 2, 2010 at 10:29pm

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?

Regards,
Victor

#48868
Mar 3, 2010 at 7:24pm

No Mac users sending big SysEx messages out of Max? Surprising…

#175610
Mar 5, 2010 at 3:59pm

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…;-)

Stefan

#175611
Mar 5, 2010 at 7:56pm

Hi Stefan,

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.

Regards,
Victor

#175612
Mar 6, 2010 at 9:19am

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…

Stefan

#175613
Mar 6, 2010 at 11:09am

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.

Regards,
Victor

#175614
Mar 6, 2010 at 1:48pm

Victor – please try the attached CoreMIDI object. This comes from Cycling, not from me – I’m just a messenger!

Dan

Attachments:
  1. coremidi.mxo.zip
#175615
Mar 6, 2010 at 6:53pm

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.

Regards,
Victor

#175616
Mar 6, 2010 at 9:02pm

It’s on the incremental page now.

#175617
Mar 6, 2010 at 9:20pm

Thanks Emmanuel.

#175618
Mar 11, 2010 at 6:35am

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?

Jawnypants

#175619
Mar 11, 2010 at 12:35pm

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.

#175620
Mar 11, 2010 at 2:48pm

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.

Any ideas?

Jawnypants

#175621
Mar 11, 2010 at 6:07pm

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?

#175622
Mar 11, 2010 at 10:24pm

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’

#175623
Mar 11, 2010 at 10:41pm

The incremental coremidi.mxo is Intel Mac only at this time.

-Ben

#175624
Mar 11, 2010 at 10:56pm

thanks Ben,

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?

other ideas?

Jawnypants

#175625

You must be logged in to reply to this topic.