AU Indexed parameters problems
AU Indexed parameters problems
- Subject: AU Indexed parameters problems
- From: Marc Poirier <email@hidden>
- Date: Wed, 11 Dec 2002 20:38:51 +0100 (CET)
I think that the kAudioUnitParameterUnit_Indexed unit type for AU
parameters is kind of problematic. Currently it means two things, one
definite and one potential: (1) the unit of the value is integer type,
and (2) the parameter's value *might* require an indexed array of strings
for display. The second thing is what's most problematic.
For one thing, the use of value strings is a property of its own, and
definitely not a type of unit. It shouldn't be mixed up in the unit type
protocol.
Secondly, it already is a property of its own:
kAudioUnitProperty_ParameterValueStrings. That should be enough. If an
AU responds positively to that property for a given parameter, then that
should be enough to indicate support of that property for that parameter.
Requiring a parameter to use the _Indexed unit *and* the
_ParameterValueStrings property is redundant.
Thirdly, since it's currently required that a parameter use _Indexed for
its unit type in order to indicate the use of ValueStrings, that precludes
the use of a real unit type for the parameter. That's how I became more
aware of this problem: When the _beats unit type was added, I though,
"great, I have lots of parameters that are in units of beats." However, I
never use the beats unit type because any parameter that I make for beat
sync provides ValueStrings because beats is the kind of parameter where
custom values makes a lot more sense then just a range of continuous
values (i.e. I use things like 1/4, 1/3, 1/2, 1, 2, 3, 4, 6, 8, 12, etc.).
So I always have to make those parameters have unit type _Indexed even
though they are really unit type _Beats.
So anyway, my point is that I think that _Indexed should do its own thing
(indicate integer value units), _ParameterValueStrings should do its thing
(indicate the ValueStrings property), and they shouldn't be mixed up. And
it seems to me like making this change wouldn't really mess with backwards
compatibility enough to make a significant difference. All that it would
affect is that hosts would now have one step less in the ValueStrings
detection process. Does this all sound reasonable?
Thanks for listening,
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.