Re: Parameters & Listeners & Host & Cocoa
Re: Parameters & Listeners & Host & Cocoa
- Subject: Re: Parameters & Listeners & Host & Cocoa
- From: William Stewart <email@hidden>
- Date: Wed, 3 Dec 2003 18:26:15 -0800
On 03/12/2003, at 2:28 PM, Marc Poirier wrote:
On Wed, 3 Dec 2003, William Stewart wrote:
Yes, we'd realised that this was a shortcoming in the parameter
control
mechanism, so we've added the begin and end gesture events to the new
AUEventListener that is available in both Jaguar (with QuicKTime 6.4
or
later as we updated Core Audio with that release as well), or Panther.
We will essentially deprecate the AU View Carbon methods here for
"mouse up" and "mouse down" - instead we expect both AU's and Hosts to
use the AUEventListener for these notifications.
The Cocoa View API we also published consequently does *not* have this
mouse down/up method - as this is supplanted by the new AU event
types.
This also simplifies the hosting side of this, as a host can get these
notifications (or send them) and not have to do different things for
either carbon or cocoa UI's. This also removes the need for an AU to
get access to the "this" pointer of the Carbon View in order to do
these.
There maybe some lag time as host apps pick up this new API, but the
only way to get this adopted is for people to move over to it and
"push" the host apps into properly supporting this feature. A bit of
short term pain, for a longer term gain :)
Ahh, interesting that you just sent this message, because I just wrote
the
one below. Since I'm still wondering about these questions, I'll just
send it out:
I was just wondering how the migration from old-style
AUParameterListeners
and AUPropertyListeners to new-style AUEventListeners is supposed to
happen. Is there any proposed plan?
Pre-Panther and/or QuickTime 6.4, we had this API for doing parameter
change listening and notifying:
AUParameterListenerProc, AUParameterListenerRef, AUListenerCreate,
AUListenerDispose, AUListenerAddParameter, AUParameterListenerNotify
and then this API for marking those as automatable changes:
AudioUnitCarbonViewEventID, AudioUnitCarbonViewEventListener,
AudioUnitCarbonViewSetEventListener
and this API for property change listening and notifying:
AudioUnitAddPropertyListener, AudioUnitRemovePropertyListener
Now with Panther or QT 6.4 in Jaquar, we have this unified API for all
of
that:
AudioUnitEvent, AudioUnitEventType, AUEventListenerProc,
AUEventListenerCreate, AUEventListenerAddEventType,
AUEventListenerRemoveEventType, AUEventListenerNotify
But I'm not sure how to move over to using this new API. It's not as
simple as just doing Gestalts for QT and System versions. There is no
Gestalt to see what a specific or plugin will be doing. And in fact,
the
very nature of these things is that one party doesn't have to know what
the other one is doing. You just install a listener and receive
notifications, if they occur. Or you just send out notifications,
without
needing to know whether anyone is listening to them. So in other
words,
so far as I can tell, we can't just simply try the new APIs and then
fall
back on the old ones if they fail or are ignored, since we can't really
know what is happening on the other side (host or plugin).
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).
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.
Bill
Should we just do both ways? Or what? I'm just not sure how this
transition is supposed to happen, or what I should be doing from my end
with my projects...
Thanks,
Marc
--
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.