• 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
CoreMIDI virtual source MIDIReceived concurrency question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CoreMIDI virtual source MIDIReceived concurrency question


  • Subject: CoreMIDI virtual source MIDIReceived concurrency question
  • From: Christopher Corbell <email@hidden>
  • Date: Sun, 07 Jun 2015 14:12:54 -0700

I have a question about the thread-safety of a virtual MIDI source endpoint and the MIDIReceived function.

I'm working on an app that will act as a virtual MIDI source and will be sending MIDI on multiple channels.

As a simple configuration example, the app could have one set of MIDI packet data generated by an internal sequencer, prerolled and stamped with app playback times, and another set of MIDI data that is based on live midi input from another device or source with timestamps converted to app playback time during a rn (for example, there will be a harmonizer feature that adds a note an interval above an input note at the same velocity and on the same channel). The app will be calling MIDIReceived() to send both sets of data with consistent timestamps.

My question is whether I could have two or more concurrent threads (as gcd concurrent queues) - e.g. one for the prerolled sequence, one for the realtime MIDI data, sharing the same virtual source endpoint (obtained via the same MIDI client ref) each calling MIDIReceived - whether that is a thread-safe thing to do in an application. If it isn't safe then I will likely have to create separate virtual sources for prerolled and "live" data which is less desirable... or figure out a way to just-in-time interleave the data to be handled by a single queue (or use a serial queue alternating between live and prerolled data) - which will be more complex in order to avoid any perceptible delay of the live MIDI.

Thanks,
Christopher

 _______________________________________________
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

  • Prev by Date: Re: ExtAudioFile woes
  • Next by Date: supported file formats
  • Previous by thread: Re: ExtAudioFile woes
  • Next by thread: supported file formats
  • Index(es):
    • Date
    • Thread