Re: When is an event not an event?
Re: When is an event not an event?
- Subject: Re: When is an event not an event?
- From: Bjorn Roche <email@hidden>
- Date: Wed, 5 Sep 2007 13:49:37 -0400
On Sep 4, 2007, at 8:45 PM, William Stewart wrote:
On 04/09/2007, at 1:59 PM, Bjorn Roche wrote:
Hey all,
I've been testing my app for working with Audio Unit Plugins,
and, in particular, their native UIs. It seems there are several
ways a user can change the value of a parameter, and I had
previously assumed that they would either do so through my app's
interface, or through a "gesture" a la
kAudioUnitEvent_ParameterValueChange,
kAudioUnitEvent_BeginParameterChangeGesture, and
kAudioUnitEvent_EndParameterChangeGesture. This assumption allowed
me to ignore events that are, for example, a side-effect of a
preset recall. Unfortunately, I discovered the user can change
values through the AU GUI without firing
BeginParameterChangeGesture, for example, by typing in a new value
into a text field. GRRRRR!
Sure. There's no guarantee or requirement that the begin/end
notification be sent. Those events don't actually change the value
of a parameter, they just signify that the user has initiated (or
ended) a gesture that may (or may not) lead to the parameter value
being changed.
You can't tell from where the change occurs. Would you consider a
control surface to be the UI, or if a parameter has changed as a
result of a MIDI mapping? These are just different routes to
changing the parameter as you surmise.
As for discriminating whether the parameter has changed as a result
of a preset being set; we haven't discriminated between that
source. So, I don't think you are missing anything there.
Bill,
thanks for your reply, but I'm not sure you understand the problem.
I will try again: My app, like many others, uses a stack for it's
undo list. Now imagine that my app receives a
kAudioUnitEvent_ParameterValueChange without any indication it
belongs to a gesture. This could be a result of several things. Here
are some examples:
*) the user entered a new value (text field/midi controller/
whatever), in which case my app needs to respond by storing the new
value and adding an edit to the undo list.
*) the event was fired in response to another event, say a preset
restoration or a meta-parameter, in which case I don't want to add it
to the undo list because that change is already accounted for in
another change.
*) the event is fired in response to a previous change being undone/
redone, in which case it should not be added to the undo list.
Without the ability to distinguish source, the only way to know if
something goes on the undo list is hackery which may not work in all
cases. (eg. using timers and so on).
I think this is a bug.
With the cocoa view, we explicitly removed the preset menu from the
default UI - this allows the host to exercise a more precise
control and management of how presets are handled. This can include
a bracketing notion around the action of setting a preset (factory
or custom) where you can ignore the parameter change notifications
within that period. Working with this I think you should be able to
solve your problem.
I have experimented with this in the past and found that parameter
change events are sometimes sent after the preset change has been
completed. I may have been doing something wrong, but I don't think
that's a workable solution even if I could guarantee that the AU
wasn't going to change the preset on its own (most AUs I've seen DO
let you change the preset).
bjorn
-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave
_______________________________________________
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