Re: Timing mechanism for MIDI ?
Re: Timing mechanism for MIDI ?
- Subject: Re: Timing mechanism for MIDI ?
- From: Carlos Eduardo Mello <email@hidden>
- Date: Tue, 9 Dec 2008 11:04:14 -0200
Brian and William,
thanks a lot for all your explanations.
This gives me a lot to work on.
Just one more thing:
Is there a standard (API?) way to get updates back from CoreMIDI in
order to show time passing on the UI?
(I mean, knowing where CoreMIDI is in order show it acccurately in a
timeline.)
On Dec 9, 2008, at 10:35AM, Brian Willoughby wrote:
The basic CoreMIDI API pairs a MIDI event with a timestamp which
represents the correct time when that MIDI event should occur.
That's how you get CoreMIDI to schedule events at the correct
times. You should avoid using 'now' as the time stamp on MIDI
events unless you really know what you're doing.
Your best performance comes by delivering this pair of data to
CoreMIDI with enough advance notice that the internal accuracy of
CoreMIDI itself takes care of everything. You're not going to be
able to do a better job at timing than CoreMIDI, especially not if
you are still going to rely on CoreMIDI to deliver the MIDI event.
Your only obligation in a CoreMIDI application is to periodically
wake up and send another set of MIDI events for a future slice of
time. If you design this way, then the precision with which your
program wakes up is not part of the critical timing. You merely
need to make sure that you've given CoreMIDI everything it needs in
the worst case that your thread wakes up at the latest moment.
Pick a time window, T, and a safety offset, S. When you first
start your transport, set a reference time stamp taken from
CoreAudioClock. Then send all events within the time window from
time 0 to time S+T. With each subsequent wake-up call, send all
events for the next time window of length T beyond the most recent
position. Your users will tolerate a latency of hundreds of
milliseconds for infrequent things like start and stop of the
overall transport. The only trick is to make the time window small
enough that UI changes seem to happen "instantly." You'll also
need to estimate the worst case slop in the precision of your
thread wake up interval, and make sure the safety offset is long
enough to hide that completely.
Brian Willoughby
Sound Consulting
_______________________________________________
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