Re: Parameters & Listeners & Host & Cocoa
Re: Parameters & Listeners & Host & Cocoa
- Subject: Re: Parameters & Listeners & Host & Cocoa
- From: Marc Poirier <email@hidden>
- Date: Thu, 4 Dec 2003 12:49:02 -0600 (CST)
On Wed, 3 Dec 2003, William Stewart wrote:
>
Let me tackle this in 3 parts:
>
Parameter listener doesn't change - it works as it always has
>
>
Property Listening is not really a problem. The property change when
>
used in conjunction with this is still using the underlying mechanism
>
as it is currently with the AU.
>
What the new API does do is allow the listener to fire on another
>
thread than the one that the property change occurs on, whereas the
>
AU's direct notification that a property value has changed would occur
>
on the thread that changed the property. This provides essentially a
>
good mechanism for an AU for instance to communicate to listeners that
>
property values have changed where the only real thread that an AU
>
executes code on is the render thread.
>
However, I think for the AU there is no difference - it just internally
>
calls the PropertyChanged method of AUBase.
>
But, the AU View can use this event listener rather than a direct
>
property change listener to receive notifications of property changes
>
and all will be good, because the AU's view can ensure that the
>
property changes it does receive are all received on its UI thread
>
regardless of where they originated.
>
>
So, for my mind, all of the views should move over to this API where
>
possible (the API exists wherever the bundle version of
>
AudioToolbox.framework is 1.3 or greater).
So then are you saying that if I use AUEventListenerCreate to create a
listener for some property and AUEventListenerCreate to create another
listener for parameter values, then I will receive notifications when
someone uses AUEventListenerNotify, and also if someone uses the old
AUParameterListenerNotify or AUBase::PropertyChanged? And vice versa, if
my listeners were created with AUListenerCreate and
AudioUnitAddPropertyListener, then I will still get notifications to these
if someone sends parameter value change or property change notifications
using the newer AUEventListenerNotify? So all of these are doing the same
thing in the end, but with new interfaces, and some new options? Am I
understanding correctly? If so, then that does make things simpler
indeed...
>
The main problem is begin/end parameter gesture.
>
>
I'm not sure that I have a really good answer for this, but just a
>
recommendation that people move over to use the new mechanism and the
>
host apps are forced to move through sheer weight of numbers. We can
>
help to coordinate this with some of the hosts - but essentially this
>
is a matter of coordination I think - I can't think of any real yes/no
>
answer for this.
Do you think that it would make sense for an AU, at this moment in time,
to do both TellListener(kBlah_MouseDown) and
AUEventListenerNotify(kBeginParamGesture) and such redundantly, and then
eventually take the TellListener out of their code? Should hosts be
prepared to deal with that? I'm just thinking about this because we're
about to release Pluggo, and I don't want to just jump on the new thing
and with no hosts supporting it yet and then hear everyone say, "they
released Pluggo with broken automation," and on the flipside, I don't want
to do both if that might break hosts, well, anyway, it's something that I
need to decide on very soon...
Thanks,
Marc
_______________________________________________
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.