Re: Parameters & Listeners & Host & Cocoa
Re: Parameters & Listeners & Host & Cocoa
- Subject: Re: Parameters & Listeners & Host & Cocoa
- From: Marc Poirier <email@hidden>
- Date: Wed, 3 Dec 2003 16:28:59 -0600 (CST)
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).
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
_______________________________________________
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.