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: Thu, 14 Feb 2002 23:10:09 -0500
Herbie Robinson <email@hidden> wrote:
[ There probably needs to be some attributes on the endpoints that
[ specify the transmission delays. Then the application can correct
[ for them if it wants to. It's probably not a good idea to have
[ drivers try and correct for MIDI delays, because the algorithm
[ can get somewhat complex and would require constant re-computation
[ because the driver doesn't see all the data. The application can
[ adjust for transmission (and other) timing delays as edits are
[ being done. Attributes would be per character time, whether or
[ not running status is used and possible some info about whether
[ the device can respond to incomplete Events..
After my previous post on time stamping, I had some further thoughts
about the
possibilities.
If you consider the exact case of a Human Interface Device (keyboard,
expression controller, etc.) connected via MIDI 1.0, it seems like
it would be
a good thing if the CoreMIDI driver subtracted 320 microseconds from the time
stamp of the receive interrupt and reported that adjusted time as the actual
absolute time of the real event.
That's what I had in mind, too...
This seems like a way to improve the accuracy of time stamps. The problem is
how to determine whether the input is coming from a live event or a
sequencer.
In the case of a sequencer, there's no way to know if the sequencer has
already adjusted its timing to account for MIDI 1.0 delays.
If the timing spec is defined as the beginning of the packet, only
the receiver should be adjusting; so, if we are talking OS X to OS X,
this should work. If some other system had decided to sync to the
tail end of the packet, then there would be an inaccuracy.
Also, more modern
"MIDI" devices could use more advanced connections like USB instead of MIDI
1.0, and could thus communicate the time stamp directly so that adjustment is
not needed.
That was the idea behind having an attribute.
I like your idea of per-endpoint attributes for transmission delays. Aren't
there already there? or is that for output latency only?
I haven't actually read the documentation all the way through for
about 6 months, but the only one I remember being there is the
recommended queue ahead time.
In some respects it
may not be needed if the driver can "adjust" the time stamps on incoming data
before the app sees the events, but it might still help to have this
information around in the cases where it cannot be determined without human
help as to whether the incoming data is live or playback of a recorded
performance.
I was assuming that the driver would adjust the time stamps on input.
What you have brought up is that it would be useful to have that
controlled by the user based on what was connected... I was actually
thinking the driver would add the a constant to the MIDI device and
the application would read it. What I thought it would be used for
was having the application deal with the case where it wanted to
schedule many events at the same time: Dumping that chore on the
driver isn't a good idea. The application is the only thing that
knows what can be safely slid around (for example, the drums probably
want to be the most accurate and the driver has no idea which
channels are drums).
--
-*****************************************
**
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.