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
[email protected]
http://lists.create.ucsb.edu/mailman/listinfo/media_api