Re: MIDI packet processing
Re: MIDI packet processing
- Subject: Re: MIDI packet processing
- From: Scott Ruda <email@hidden>
- Date: Thu, 16 Sep 2004 15:05:15 -0700
On Sep 15, 2004, at 4:11 PM, Doug Wyatt wrote:
On Sep 14, 2004, at 8:53, Scott Ruda wrote:
From: Doug Wyatt <email@hidden>
Multiple events per packet ARE allowed. You WILL receive them (e.g.
from a USB MIDI interface) and you may create them.
Just don't use running status when writing a packet, or put realtime
in between the bytes of a non-realtime message (except sysex). And
you can make those assumptions when you parse packets.
I'm a bit confused now. According to the comments in the header file:
"In the case of system-exclusive messages, a packet may only contain
a single message, or portion of one, with no other MIDI events."
Thanks for catching me -- I shouldn't have excepted sysex.
While realtime MAY interrupt sysex on a MIDI stream -- and in the
"large-scale" streams moving around inside CoreMIDI -- within a single
MIDIPacket, it may not.
Forbidding this has two advantages:
[1] when a realtime byte is occurring in the middle of a sysex
message, it gets its own timestamp, which is extra desirable on
realtime.
[2] you can indeed assemble/disassemble chunks of sysex with memcpy()
Thanks for clearing that up. I can now rip out the sysex block
scanning/cleansing code I just put in... :-)
BTW, is this enforced by the CoreMIDI services, or is it the
responsibility of the driver writers to conform to this specification?
I.e. can I count on it, or should I be proactive and make no
assumptions that all third party drivers do it the 'right' way?
_______________________________________________
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