Re: Property notification questions
Re: Property notification questions
- Subject: Re: Property notification questions
- From: Bill Stewart <email@hidden>
- Date: Wed, 12 Feb 2003 14:19:34 -0800
I'd actually use the AUParameterListener to do this communication...
Create a bunch of private parameters that aren't going to be registered
or have values in the scope objects...
Then, as you need to get this information use the parameter listener
API to issue a notification of a parameter value change... (make sure
you actually change the value of the param - just do a ++ for instance
so that the param listener will actually register a change in the value
of the parameter...
Thus - you have a displayNoteOnFeedbackParam
in your au:
mDisplayNoteOnFeedbackParamValue++;
AUParameterListenerNotify(NULL, NULL, myFeedbackParamStruct);
Then your view registers for notifications for changes to that
parameter value and sets the run loop that it wants to get notification
on (including the granularity) - so then your view will see the
notification on its UI thread...
Then - when your view gets this notification it know what it has to do
(ie. query the value of the property for instance) in response to
that...
Bill
On Wednesday, February 12, 2003, at 12:36 PM, Chris Reed wrote:
Hello everyone,
I have a question concerning property notifications coming out of
audio units. Basically, I'm wondering what approaches other people
have taken. I have code that works perfectly fine, but it just seems
more complicated than necessary.
First, I am using private propeties to communicate information between
my audio unit and its edit view. In this particular instance (I'll
just pick one to make it easy to talk about), the property tells the
playing state of an instrument/voice (playing or not playing) so the
edit view can show graphic feedback when a note is triggered.
The problem here is that the notifications for this property are
triggered from within the buffer rendering code, called inside an
ioproc thread. Obviously, calling AUBase::PropertyChanged() is a bad
idea here because that directly calls the property notification
listeners and lets them do anything they want.
So I am creating a separate thread at audio unit initialisation time
and passing any property changes to that thread in a nonblocking
manner. The thread then pops items out of the queue and asks the audio
unit to inform its listeners for that property.
Now, in my edit view property notification listener I would like to
update the interface. But making any Control Manager calls will cause
weird things to happen if it's not in the main event loop thread. So I
create a one shot run loop timer with a delay of 0 (to fire
immediately) and install it on the main thread's run loop. In the
timer callback I can safely update the GUI.
Like I said, this all works fine. But it seems too complicated.
One thought I had was to have the property notification listener set
the run loop that it wants to be called back on (just like parameter
notifications). This would avoid having the listener callback
installing a run loop timer itself. Or we could even skip the whole
notification thread thing and install the run loop timer directly when
the notification is triggered--but that would probably be bad for a
realtime thread.
The only problem with the above idea is that
AudioUnitAddPropertyListener() does not have a run loop argument.
How were property notifications supposed to work? What approaches are
other people taking? I really really don't want to install a repeating
timer and poll to update the GUI.
cheers
-chris
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.