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 12:32:20 -0700
On Wednesday, August 13, 2003, at 11:42 AM, Marc Poirier wrote:
>
While we're at it, and since it seems to be the season for AU API
>
changes
>
(with 10.3 and the new SDK coming), I figure I might as well just send
>
a
>
little reminder list of issues that I have brought up before, that I
>
still hope will be addressed sometime:
>
>
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.
>
>
index parameter value problems and inconsistencies:
>
http://lists.apple.com/archives/coreaudio-api/2002/Dec/11/
>
auindexedparametersprobl.txt
To Quote you:
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.
This has been addressed: There is a new property called:
kAudioUnitProperty_ParameterValueName
This property is used with parameters that are marked with the
kAudioUnitParameterFlag_HasName parameter info flag. This indicates
that some
(or all) of the values represented by the parameter can and should be
represented by a special display string.
This is NOT to be confused with
kAudioUnitProperty_ParameterValueStrings. That property
is used with parameters that are indexed and is typically used for
instance to build
a menu item of choices for one of several parameter values.
kAudioUnitProperty_ParameterValueName can have a continuous range,
and merely states
to the host that if it is displaying those parameter's values, they
should request
a name any time any value of the parameter is set when displaying
that parameter.
For instance (a trivial example), a unit may present a gain parameter
in a dB scale,
and wish to display its minimum value as "negative infinity". In this
case, the AU
will not return names for any parameter value greater than its
minimum value - so the host
will then just display the parameter value as is. For values less
than or equal to the
minimum value, the AU will return a string for "negative infinity"
which the host can
use to display appropriately.
A less trivial example might be a parameter that presents its values
as seconds. However,
in some situations this value should be better displayed in a SMPTE
style of display:
HH:MM:SS:FF
In this case, the AU would return a name for any value of the
parameter.
The GetProperty call is used in the same scope and element as the
inParamID
that is declared in the struct passed in to this property.
If the *inValue member is NULL, then the AudioUnit should take the
current value
of the specified parameter. If the *inValue member is NOT NULL, then
the AU should
return the name used for the specified value.
On exit, the *outName may point to a CFStringRef (which if so must be
released by the caller).
If the parameter has no special name that should be applied to that
parameter value,
then *outName will point to NULL, and the host should display the
parameter value as
appropriate.
>
I don't know if either of those things are being thought about or
>
changed
>
or anything for the next AU revision, but I just wanted to bring them
>
back
>
up because I still think that they matter (especially the curves
>
stuff).
>
>
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)
Bill
>
>
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.
>
>
--
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.