Re: AU->View communication
Re: AU->View communication
- Subject: Re: AU->View communication
- From: Russell Edwards <email@hidden>
- Date: Thu, 14 Jul 2005 13:27:48 +1000
Thanks for your reply & my apologies for taking so long to respond:
An alternative I have seen little references to seems to be to use
properties. But apparently you shouldn't send property change
notifications from the audio thread as they might block for too long.
No. You can use the AUEventListener notification mechanism with
properties just as you can with parameters; this is a non-blocking
notification. A view which *listens* to private property changes
should also use this mechanism so that it ensures that its
notification occurs on the main thread. Thus, this becomes a
"render process" safe mechanism.
Oh that's interesting! So is the second paragraph of the following
post wrong, out of date, or pertaining to some other listening
mechanism? :
http://lists.apple.com/archives/coreaudio-api/2003/Jun/msg00056.html
CAUGui, in its "internal parameters" stuff, therefore just polls them
in the GUI's idle timer.
Yes, that is a very bad approach and one we would discourage - the
exception to this is a metered, read-only parameter which by its
nature needs to be drawn on a regular basis.
I have something like that, but I don't do it with a timer loop like
this because I don't want to be drawing the meter more often, or less
often, than the update interval of the meter value in the actual
audiounit thread. So, I have the audiounit "push" meter values via
private parameter change notifications ... is there anything "wrong"
with that? (I update them every 100 ms, done by counting samples).
thanks
Russell
_______________________________________________
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