Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Questions on data in MIDIPackets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions on data in MIDIPackets

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.
References: 
 >Re: Questions on data in MIDIPackets (From: RolandCorp R&D <email@hidden>)
 >Re: Questions on data in MIDIPackets (From: Herbie Robinson <email@hidden>)
 >Re: Questions on data in MIDIPackets (From: Brian Willoughby <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.