Re: Parameter automation from a Cocoa view
Re: Parameter automation from a Cocoa view
- Subject: Re: Parameter automation from a Cocoa view
- From: Marc Poirier <email@hidden>
- Date: Fri, 28 Nov 2003 13:16:39 -0600 (CST)
On Fri, 28 Nov 2003, Mark's Studio wrote:
>
Here is what i use for a slider, i know it's not perfect but i work's
>
for now, but what about a button do i have to send both mouse down and
>
up or just one of them but which one?
You always have to do both. You need to mark the beginning and the end.
You should do MouseDown when the control is hit and MouseUp when it is
released. This allows hosts to know how to handle this stuff in "touch"
automation mode, for example. Even if maybe a button only has 2 states,
and as soon as you click in it, it enters the other state and isn't going
to leave that until another click arrives, you should still wait until the
mouse is released to do the MouseUp.
>
But i think part of the problem is that the host eventListener is
>
changing with the carbonview, so i think sometimes the callback is not
>
working.
??? I don't think I understand...
>
That's way i asked if the AudioUnit needs to generate automation data,
>
how that is that done without the carbonview.
Oh yeah, you do need to make sure that, for each parameter value change in
the automation gesture, you do either AUParameterSet() or
AUParameterListenerNotify(). AUPS will change the parameter value and
send notification of the change to listeners, whereas AUPLN only does the
notification.
There's also a newer and nicer API for this stuff, and property changes,
that came with Panther and QuickTime 6.4 for Jaguar. Look at the
AudioUnitEvent* and AUEventListener* stuff in
AudioToolbox.framework/AudioUnitUtilities.h. However, being new, I'm not
sure how many hosts are supporting this yet (I haven't checked into this
yet, so I'm not sure). It wasn't actually mentioned anywhere in the SDK
release notes or added to the API docs so far as I could see, so it may
have slipped under many people's radar... :( It is well documented in
the framework header, though. But the important thing to realize is that,
if you use these, you will need to check to make sure that the QT version
is 6.4 or higher or OS version is 10.3 or higher, otherwise your plugin
goes kabloom. If you do wind up doing a Cocoa view at some point, then
you don't need to worry, though, since that was introduced in the same API
update, so it wouldn't work in incompatible systems anyway.
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.