• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Timing mechanism for MIDI ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Timing mechanism for MIDI ?


  • Subject: Re: Timing mechanism for MIDI ?
  • From: Brian Willoughby <email@hidden>
  • Date: Tue, 9 Dec 2008 04:35:11 -0800

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


On Dec 9, 2008, at 04:16, Aengus Martin wrote:
Hi Peter,

Does this mean that you're relying on the accuracy of [NSThread sleepUntilDate:] ?

Can you say more about how you get CoreMIDI to schedule events at the correct times?

Thanks,

Aengus.



On Tue, Dec 9, 2008 at 8:15 AM, Peter Johnson <email@hidden> wrote:
Hi Aengus


In my AppKit sequencer application I use a thread for the timing. The sequencer runs on a separate thread which blocks on a semaphore, this is then signalled when the timer expires. The sequencer schedules MIDI events to occur at a specific clock value (in PPQN). The MIDI send code uses this value and converts it to system nanoseconds with AudioConvertNanosToHostTime() so that CoreMIDI schedules the event at the correct time. I've found this approach to give good timing.

_______________________________________________ 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
  • Follow-Ups:
    • Re: Timing mechanism for MIDI ?
      • From: Carlos Eduardo Mello <email@hidden>
References: 
 >Re: Timing mechanism for MIDI ? (From: Peter Johnson <email@hidden>)
 >Re: Timing mechanism for MIDI ? (From: "Aengus Martin" <email@hidden>)

  • Prev by Date: Re: Timing mechanism for MIDI ?
  • Next by Date: Re: Timing mechanism for MIDI ?
  • Previous by thread: Re: Timing mechanism for MIDI ?
  • Next by thread: Re: Timing mechanism for MIDI ?
  • Index(es):
    • Date
    • Thread