Another Wrinkle on Re: When is an event not an event?
Another Wrinkle on Re: When is an event not an event?
- Subject: Another Wrinkle on Re: When is an event not an event?
- From: Bjorn Roche <email@hidden>
- Date: Sun, 9 Sep 2007 14:19:55 -0400
All,
I recently discovered an effect (Crazy Ivan, by bram@smart
electronix) whose parameters change on their own! rather than
controlling internal oscillators, the parameters just start wiggling,
wizzing and banging about as soon as you start rendering audio. This
seems to go against reason -- not only is it obviously incompatible
with undo (unless I can make the distinction I describe in my
previous emails, below) but I don't see how this behavior could work
with automation. Is this a freakish case I should ignore, or do a lot
of audio units spontaneously change their parameter's values? It
seems very dangerous to do so, but if it's something a lot of AU's do
my app will need another approach.
bjorn
On Sep 5, 2007, at 1:49 PM, Bjorn Roche wrote:
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:
40xowave.com
This email sent to email@hidden
-----------------------------
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