Re: other AU parameter suggestions
Re: other AU parameter suggestions
- Subject: Re: other AU parameter suggestions
- From: Marc Poirier <email@hidden>
- Date: Wed, 13 Aug 2003 16:13:46 -0500 (CDT)
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.
Awwwwwww... that's the one I think is by far the most needed. I think
it's also the easiest to add, so I'll make one final appeal. I think that
it just requires a few small changes:
1) define an enum like I suggested with a variety of curve types from
which to choose
2) take another few bytes from AUParameterInfo.name to use as value curve
identifier (integer, from the above mentioned enum) and the optional curve
specifier value (float or double)
3) update AUParameterValueFromLinear and AUParameterValueToLinear to
accomodate the curve declared for a parameter
For #3, you can even just steal all of the math from me, no work required:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tom7misc/vstplugins/dfx-library/dfxparameter.cpp
(see the expandparametervalue and contractparametervalue functions)
If it's a burden, you could forget about custom curve functions for now.
Just having a good variety of "presets" would do so much good.
In my opinion, you can't really have "natural" parameter value ranges
without a way to specify a value distribution curve. It's like going
half-way. In practice, it means that, too often, you have to give up
natural value ranges in order to have a moderately usable interface. Take
my port of Magnus' Ambience, for example:
http://smartelectronix.com/~magnus/
I finally decided that I had to just use normalized ranges for most
parameters and do the curving internally, because otherwise they were
pretty much unusable with a generic UI (which is all it has currently).
Magnus frequently gets complaints and "bug reports" about this, but it
sucks the other way, too. Basically, it sucks to have to make that choice
an either/or: do you make the parameter values meaningful, or do you make
the parameters usable? That shouldn't have to be an either/or choice...
Thank you, that's the end of my final appeal. :)
>
> 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.
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
_______________________________________________
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.