AU Parameter metadata
AU Parameter metadata
- Subject: AU Parameter metadata
- From: Marc Poirier <email@hidden>
- Date: Sun, 4 May 2003 02:11:47 +0200 (CEST)
On Sat, 3 May 2003, Urs Heckmann wrote:
>
One old thing I'd like to bring up again is metadata for parameters.
Yeah, and while we're at it, I guess I'll bring up my two major parameter
metadata requests again:
The first one is regarding the kAudioUnitProperty_ParameterValueStrings
property and how it shouldn't be tangled up with the
kAudioUnitParameterUnit_Indexed parameter unit specification. But I've
already said all that I have to say about it in this message in the
archives (although I don't recall anyone ever responding to the message,
hence I bring it up again now):
http://lists.apple.com/archives/coreaudio-api/2002/Dec/11/auindexedparametersprobl.txt
My other main request is that there be a field in the
AudioUnitParameterInfo struct for specifying a parameter value
distribution curve. This would make generic UIs (and any non-custom
interface to parameters, like host automation interfaces and such) much
more usable. As it is now, the best you can do is specify the units of
the parameter and then, if you're lucky, maybe that *implies* a preferred
value distribution curve, like logarithmic for Hertz, for example. But
implying it is not anywhere near good enough, and in most cases it's not
possible to assume anything aside from linear distribution, which (at
least in my experience) is a poor distribution more often than not. Even
the assumption of log distribution for Hertz can be terrible. For pitch
parameters it can be nice, but for LFO rate parameters log distribution is
horrible.
So I suggest adding another field (actually two, but more on that in a
moment) to AUParameterInfo for value distribution curve. It could be an
int and then there could be an enum in AudioUnit.framework that gives
valid options. We (DFX) have something like this already in our DfxParam
class and I would say that our enum at leaves gives a starting point, and
maybe other folks can think of other important options to add:
typedef enum {
kDfxParamCurve_undefined,
kDfxParamCurve_linear,
kDfxParamCurve_sqrt,
kDfxParamCurve_squared,
kDfxParamCurve_cubed,
kDfxParamCurve_pow, // requires curvespec to be defined as the value of the exponent
kDfxParamCurve_exp,
kDfxParamCurve_log
} DfxParamCurve;
The "undefined" option can be a default which would basically be the
equivalent of the current situation: the non-custom interface can make
assumptions about the best distributino curve if it wants to, and
otherwise just do linear. pow is the one tricky one because it requires
another value to complete the specification: the exponent. So this is
why I mentioned above that this actually requires two bits of metadata:
the curve type index and then, for certain curve types, an additional
value.
It also might be a good idea to add one more item to the enum:
ParamCurve_custom. Then this require something like adding another AU
property like kAudioUnitProperty_ParameterValueDistributionCurveFunction
(hmm, maybe we could make that even longer?) which could be a read-only
property that returns a function pointer of a given format, something
like:
typedef Float32 (*paramCurveFunction) (Float32 inValue, bool isLinear);
The isLinear argument specifies whether or not the value is already in
generic 0 to 1 form, or if it's in its real value representation and needs
to be squashed to generic format.
I hope this doesn't sound like something that's just esoteric and
nit-picky to other folks. I really do think that this is an important
thing and a significant short-coming of the current AU API. It's a real
problem not having a standardized way to specify a parameter distribution
curve. I am bitten by this problem very often: whenever I use a generic
UI, whenever I am editing automation data in a host app that draws
automation on a timeline/sequence and must scale the value linearly,
whenever I interface a plugin's parameters with MIDI CC control or any
sort of generalized control surface, etc. Basically doing all of those
things usually sucks because the response cureves for most parameters are
way out of wack and just feel really wrong, making the parameters very
hard to control. So, maybe I'm just being paranoid, but I have a feeling
that my concerns might be written off as trivial and esoteric, so I really
do want to emphasize that, as an end-user and musician, this is a problem
that comes up frequenty and IT REALLY SUCKS.
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.