Re: Questions about receiving SysEx, compared to old OMS way
Re: Questions about receiving SysEx, compared to old OMS way
- Subject: Re: Questions about receiving SysEx, compared to old OMS way
- From: Kurt Revis <email@hidden>
- Date: Sun, 23 Apr 2006 11:42:51 -0700
On Apr 22, 2006, at 9:10 PM, Stephen Kay wrote:
I have a MOTU FastLane USB I'm using for testing at the moment, and
if I
dump an example program from one of my Korg keyboards into it, I
see that it
gets broken into a large number of single packet MIDIPacketLists,
with each
of them containing 32 Bytes, followed by whatever is left over at
the end
containing a 0xF7.
1. Is this behavior determined by the interface, the interface's
drivers,
the Korg, CoreMIDI, what? - who is deciding that these packets are
32 Bytes
long? Do different drivers/interfaces do it differently?
Primarily the MIDI interface and its driver. The CoreMIDI server is
just passing along whatever data the driver gives it.
It's entirely possible that other hardware and drivers might give you
different lengths of packets. You shouldn't even try to depend on
the packet length.
2. How is one supposed to handle and assemble this stuff, these
days? In the
"old day", there were contFlags that told you how to put things
together. Do
I simply assume that anything that isn't a complete MIDI message is
part of
a SysEx dump, and watch for the 0xF0 and 0xF7's?
Essentially yes: Look for an 0xF0 to start, and keep reading sysex
until you see an 0xF7.
As described in the docs for the MIDIPacket structure, the
differences between regular MIDI and what CoreMIDI gives you are:
A) You'll never get running status messages.
B) You are guaranteed that normal (1-3 byte) MIDI messages won't
cross packet boundaries.
C) If a packet contains any part of a sysex message, there should be
no other MIDI interspersed in it.
The last point is kind of subtle, and I personally don't trust all
the driver authors to implement it correctly. (I've spent too much
time tracking down far more blatant sysex problems, like dropping
every 4th byte...)
But, assuming that all works, all you have to do to receive sysex is
1) When you see a packet that starts with 0xF0, start accumulating
sysex data.
2) Look at the first byte of each subsequent packet.
== 0xF7: You're done with the sysex message.
>= 0x80: It's a MIDI message, ignore the whole packet.
Otherwise, you've got more sysex data, keep accumulating it (and
look for an 0xF7 to end).
I wrote my MIDI parser before I really understood the implications of
point (C) above, so I ended up parsing all the data in the packet
while receiving sysex. It's not much harder and it's a bit more
robust. I also needed a timeout mechanism, to handle badly-behaved
devices that don't end their sysex with 0xF7, or MIDI cables getting
unplugged, or drivers dropping bytes, etc.
The code is here: http://www.snoize.com/MIDIMonitor/Source/
Specifically, take a look at the SnoizeMIDI project,
SMMessageParser.* and SMInputStream.*. -[SMMessageParser
messagesForPacket:] is where all the parsing happens.
Hope this helps.
--
Kurt Revis
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden