On 1/30/12 9:33 AM, Tim Burgess wrote:

Hi,

 

I just want to double-check my understanding of PortMIDI’s approach to SysEx:

 

1.        The first and last PmEvents received as part of a SysEx message will have their status bytes set to f0 and f7, respectively and can be treated as 3-byte messages if the time-stamp isn’t required;

This is only partly correct. Non-sysex messages are encoded one MIDI message per PmEvent. The status byte is in a fixed position so you can decode the message and figure out how many bytes to read. Sysex messages are arbitrary length. They begin with F0 in the normal status byte position, but then all 4 bytes of every PmEvent are used to transmit the sysex message, which normally terminates with F7.

Some details: real-time messages may be embedded in the sysex message -- if a sysex message is in progress (you saw F0 but not a matching F7), single byte real-time messages can appear anywhere in byte stream.

Sysex messages might be incomplete, e.g. if the user pulls the cable in the middle of a big message, you may not receive a complete sysex message. You will know this happened when you receive a non-real-time message, indicated by a non-real-time messages status byte. Note that if a sysex message is not terminated with F7, you have no way to find out exactly how many bytes were sent since some padding bytes may be added to fill out the 4 bytes in a PmEvent.

There is a MIDI Monitor program (mm) and a sysex send/receive program in the pm_test directory with parsing examples.

2.       Any PmEvents containing SysEx data, except as described above, use all four bytes of a PmEvent, so the time stamp byte becomes just another data byte.

MIDI does not have time stamp bytes, so I'm not sure what you mean here. PmEvents have timestamps, but they are 32-bit. Standard Midi Files have timestamps, but they are variable length.

_______________________________________________
media_api mailing list
media_api@...
http://lists.create.ucsb.edu/mailman/listinfo/media_api