Re: GetParameterValueStrings
Re: GetParameterValueStrings
- Subject: Re: GetParameterValueStrings
- From: Jim Wintermyre <email@hidden>
- Date: Fri, 22 Aug 2003 04:09:44 -0700
(forgot to cc the list on this earlier...)
We will consider any suggestions for other parameter types; as Marc
has described the AU expresses parameters in their natural ranges,
not a normalised range, and these types are easily extended
(there's a few million or so slots available here :)
The issue for me is, regardless of how many slots you have for future
expansion, whenever you add a new one it requires an update. You
can't possibly know all types of parameters any plugin might want to
have at any given time (and there might be params that are so
particular to a certain plugin it doesn't make sense to add them to
the general list). So for those params that are generic, if the
generic param interface were fully supported, you could have all the
information you need to display ANY parameter properly in the generic
UI *without requiring an update* to a new version that adds this
param as a new non-generic parameter.
With the existing and additional API that have already been added
there are now I think sufficient mechanisms in place for generic
views (always a less satisfying user experience) to at least
present reasonable information about parameter values, etc
Agreed that the generic view is a less satisfying experience, and if
a custom editor is available users will use that probably 95% of the
time. All of our plugs have custom UI's so this really is not a big
deal, but I want our plugs to work 100% in AU, not 95%. Maybe that's
asking too much :-)
As for providing the ability to provide a "unit" name type for
generic parameters - I don't see a sufficient reason to add this,
and I see many ways in which this feature would be abused.
Huh? I don't understand that argument. To display a generic
parameter in the generic UI with the full amount of information
possible, it seems to me that you need:
- parameter name
- parameter range
- text string for actual current parameter value for display (also
used to get *displayed* parameter range)
- text string for "units" of parameter
So, for example let's say you have a parameter called "widgets". Its
actual value range in float is 0 to 5. However, you want it
displayed to the user in terms of some random unit called "zoids",
and that particular range is mapped non-linearly to the 0 to 5 float
range within the plugin. The minimum value of 0 corresponds to -7
zoids, max value of 5 corresponds to 23.7 zoids. Your custom editor
already displays this parameter in terms of "zoids", you want the
generic editor to do the same. So the generic UI would look like
this (in bad ASCII art):
Widgets: -7 --------X------ 23.7 (8.5) zoids
Here, the X represents the current position in a slider, which is 8.5
zoids. Obviously this is a very contrived example, but you get the
idea.
So anyway, as far as I can tell most of this functionality is already
there for generic params. You already have param name and range (the
"actual" range, not the "displayed" range). My understanding is that
the forthcoming kAudioUnitProperty_ParameterValueName will be used
for the displayed value, so that covers the displayed range and
current value. So the only thing left is the displayed units. I
don't see how adding this somehow opens up the generic interface for
abuse (any more than it already is?).
Jim
_______________________________________________
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.