Re: other AU parameter suggestions
Re: other AU parameter suggestions
- Subject: Re: other AU parameter suggestions
- From: Bill Stewart <email@hidden>
- Date: Wed, 13 Aug 2003 15:03:41 -0700
On Wednesday, August 13, 2003, at 02:13 PM, Marc Poirier wrote:
On Wed, 13 Aug 2003, Bill Stewart wrote:
parameter value distribution curves:
http://lists.apple.com/archives/coreaudio-api/2003/May/03/
auparametermetadata.txt
I think we've passed on this for the moment.
<SNIP> - bit I have to think about :)
index parameter value problems and inconsistencies:
This has been addressed: There is a new property called:
kAudioUnitProperty_ParameterValueName
That sounds great. :) Well, wait a minute, I'm not sure that actually
addresses the issue that I was talking about... Mmmm, I think it's
good
enough, though, providing an alternate means to do some things that
should
be possible with ValueStrings. And a means to do some new things that
will be nice to be able to do, too. :)
I also have a few gripes about parameter automation, but from what I
was told by someone I know who was at WWDC this year, it sounds like
that stuff is being improved.
Hmmm - can you ping me about your gripes (I'd like to make sure this
is
addressed or at least understood)
Sure, there are 3 problems that I see currently (lemme grab my notes):
1) An automation gesture shouldn't be limited to the domain of mouse
events. You should be able to produce an automation gesture (define
beginning point and end point, that sort of thing) without mouse
events,
and without a GUI.
I was told that this is being addressed, though.
yes indeed - on Panther we have AUEventListeners that extend the
semantic of AUParameter Listeners where they can:
(1) Signify a start/end of a ramp gesture
(2) Notify a property change
(3) Notify a parameter change (ie. what AUParameterListener already
does)
This is shimmied on top of the current param listener - so it *is safe*
to call this from the I/O thread and your listeners receive their
notification of the event that changed on their thread... woooeeee!!
(that's the closest I can come for the moment to Sekhar's haiku)
Bill
2) In addition, it should be possible for a plugin to produce a single
value change that can be recorded as automation, not necessarily a
gesture.
Okay, I just pasted that from my notes. Looking at it now, I don't
know,
maybe that's possible? I guess it's not really clear whether notifying
listeners of a parameter change implies that it's a change that should
be
automated. If so, then we have this already. If not, then there
should
be a sort of notify-listener-and-automate thingy or something like
that, I
think. Either way, maybe the first problem is that this issue needs a
little more clarity in the docs.
3) You can't send notifications of parameter changes in a way that you
can insure will *not* cause automation data to be written.
Uhhh, that is, if a notification implies automation. Which I'm still
not
sure, as I just said above. So I guess this ties right in with 2, but
basically I'm not sure what the current state of these two things are
right now, let alone in the future, so I guess that's a combo request
for
more docs and think about these ideas if the current scheme doesn't
jive.
Something like that, sorry for not being terribly clear, I'll try again
folks totally can't interpret what I'm trying to say...
Thanks,
Marc
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.