Re: Questions on data in MIDIPackets
Re: Questions on data in MIDIPackets
- Subject: Re: Questions on data in MIDIPackets
- From: Herbie Robinson <email@hidden>
- Date: Sat, 9 Feb 2002 18:44:04 -0500
OK, I'm getting down inside MIDI data as it passes through my code,
and I've got a couple of questions which the docs don't seem to
answer clearly. (My favourite line in the docs so far: "The
MIDIPacket contains one or more simultaneous MIDI events. The
exception is a system-exclusive events." :-)
1. Can I assume that an event will never be spread across multiple
MIDIPackets?
That's how I read it (except for SysEx).
Or, putting it the other way around, will I ever get an event that
has a status byte in one packet and some or all of its data in the
following packet?
Only with SysEx.
If not, what happens with really big SysEx dumps and the like?
I believe the documentation also states that SysEx must be in a
packet by itself and may span several packets.
That said, it appears that nothing is enforcing those rules except
the assumption that all of us are being good sports and using
MIDIPacketListAdd to build packets. Also, there is a bug fix to
MIDIPacketListAdd winding its way through the distribution system:
It was appending regular events onto the end of packets with SysEx in
them.
2. Given that all the data in a single MIDIPacket is supposedly
"simultaneous", does the positioning of real-time events (status
codes 0xf8 through 0xff) within the packet matter? Specifically, if
a real-time event occurs within the data of a normal MIDI event,
would it make any difference if the real-time event got moved to
elsewhere in the packet (presuming, of course, that multiple
real-time events in the packet would be kept in order)?
There is a little ambiguity in the spec there. Obviously, the events
are not simultaneous in the real world. There is a transmission time
for real world hardware and reports are that some of the
time-stamping interfaces are actually a good bit more accurate than
the transmission time. I already added a bug asking for
clarification as to whether the time-stamp applies to the beginning
or the end of the packet. If no clarification ever comes, then I
would assume the time-stamp applies to the END of the packet (i.e.
the instant the last byte has finished transmitting), because that's
when any real hardware will be able to start responding to the last
event in the packet.
Right now, these decisions are left up to the driver in the cases
where the timing is going to be accurate enough to matter (i.e., for
hardware with time-stamping support).
Given that there is no standard specified for how multiple events in
a packet are to be dealt with, I would say use separate packets (and
therefore separate time-stamps) for the events you care about and
make sure that what you generate has 320 microseconds per character
between packets to any given destination (taking into account running
status). This also makes sense from a system resource utilization
standpoint because you don't want the driver having to try and figure
out how to optimize timing to compensate for transmission delays
(it's not easy to do). The other catch is that there are going to be
things out there (like Softsynths and synths connected directly to
USB) that can respond instantaneously to the entire packet. There
really needs to be an endpoint property the specifies the per
character delay (probably in nanoseconds) and maybe whether or not
running status is used.
Incidentally, I had a, shall we say lively, discussion with some
users on the daw-mac reflector who feel that MIDI events should be
sample accurate! [Because they use MIDI to layer samples and they
want it to be repeatable.] There was absolutely no convincing them
that they should expect anything less.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.