Re: NSTimer and trackpad and mouse clicks
Re: NSTimer and trackpad and mouse clicks
- Subject: Re: NSTimer and trackpad and mouse clicks
- From: James Chandler Jr <email@hidden>
- Date: Tue, 08 Nov 2011 07:23:14 -0500
- Importance: Normal
Yes handling the MIDI timing from its own thread helps isolate it from the GUI.
Perhaps in some cases one could maintain the MIDI from the audio thread, but I
have traditionally used a separate thread dedicated to MIDI timing, with
mechanisms to keep the MIDI time and audio time running in sync with each other.
For one thing, my program can run in a "MIDI-only" mode where audio is
negligibly used, so in that case it might be untidy to expect the audio thread
to also maintain MIDI. MIDI is typically such a low-bandwidth thing, though it
needs fairly precise timing. It could be that piggy-backing the MIDI timing into
an audio thread could cause MIDI jitter when the audio thread gets real busy
doing audio-related tasks.
One aspect with the GUI, apologies being "mister obvious"-- Any GUI buttons
which allow the user to control MIDI in "real time" should probably fire on the
Mouse-Down rather than wait for a click and fire on Mouse-Up. For instance if a
button sends a MIDI note when clicked, it seems non-intuitive for the user to
hold a button down then release it exactly when he wants the note to fire. It is
more intuitive for the note to fire on the Mouse-Down.
But that would only be applicable to GUI controls which need to real-time
control the output. The likely majority of controls which don't require
immediate "real-time" audible consequences, seem usually best to use the default
case of responding to clicks on the Mouse-Up.
James Chandler Jr.
-----Original Message-----
From: Brian Willoughby
Sent: Tuesday, November 08, 2011 2:27 AM
To: coreaudio-api API
Subject: Re: NSTimer and trackpad and mouse clicks
On Nov 7, 2011, at 21:21, Kyle Sluder wrote:
On Nov 7, 2011, at 7:56 PM, Tom Jeffries <email@hidden> wrote:
Thanks, Brian- that's an excellent solution. I'm not totally familiar with
the way run loops work on OSX, I assumed that NSTimer would automatically
function on a different run loop. I was wrong.
Every thread has at most one run loop. The main thread is special in that it
has a run loop by default (in Cocoa applications, at least) and its run loop
is responsible for dispatching the main Grand Central Dispatch queue's
operations.
Your audio engine should really be running in its own entirely separate
thread (or set of threads). For best results, it should provide information
to and pick up input from the UI in a synchronization-free manner.
Of course this makes the interface between your UI code and your audio engine
more complicated, but it also hides that complication under a cleaner
internal interface.
Tom's question came from the point of view of CoreMIDI. The audio
engine comments above are generally applicable, but not quite exactly
as difficult for MIDI as audio.
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
_______________________________________________
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