Re: Bug in AUEventListener?
Re: Bug in AUEventListener?
- Subject: Re: Bug in AUEventListener?
- From: Urs Heckmann <email@hidden>
- Date: Mon, 1 Nov 2004 20:14:58 +0100
Hiya Bill and Luke,
as I said, I'm back to AUParameterListener for value changes and it
works pretty well (I just draw within a RunLoopTimer now instead of
during event handling, which is less elegant but still as good, user
experience wise).
I *would* use AudioUnitEvents for BeginParameterChangeGesture and
EndParameterChangeGesture notifications if certain hosts supported them
(Does any? - Dunno). Unless every host does, I'm back to
AudioUnitCarbonViewEvents for MouseUpInControl and MouseDownInControl
for this case as well :-( It's a pity that there's no hoval!
So, everything is fine here, just not as modern as I wanted it to be
8-))
Thanks,
;) Urs
Am 01.11.2004 um 19:58 schrieb William Stewart:
For more detail and a workaround:
Bug: AUEventListener does not handle
kAudioUnitEvent_ParameterValueChange
events correctly
Events aren't still in the queue, as Urs hypothesizes. When listening
to ParameterValueChange events using the AUEventListener mechanism, the
remove-listener API does not take listeners out of its
object-notification queue -- so future notifications are being sent to
stale objects.
The workaround for the problem is to use AUEventListener only
for ParameterBegin and End notifications, and use a separate
AUParameterListener instead of kAudioUnitEvent_ParameterValueChange for
parameter value changes.
Best,
Luke
Urs,
Let me know if this works for you and we'll write this up as a tech
note.
_______________________________________________
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