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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
