Re: Audio Unit suggestions
Re: Audio Unit suggestions
- Subject: Re: Audio Unit suggestions
- From: Chris Rogers <email@hidden>
- Date: Fri, 26 Jul 2002 11:59:03 -0700
Hello. I've got a few more Audio Unit suggestions, coming over from
VST-world...
The parameter stuff in AU so far is good and an improvement from VST
in a few ways. Being able to define min and max is good and the
units constants are useful, but it's not quite enough. What if you
have a parameter that you want scaled in a non-linear way, like
perhaps a frequency cutoff for a filter?
In general, you are free to define a parameter whose type is "generic"
which internal to your DSP code may end up changing something in a non-linear
way. For frequency in particular, this issue of linear vs. non-linear
comes up a lot (as it does for volume scaling - but we have linear
and decibels units for that).
Internally, we've discussed this issue about frequency and came up
with two possible solutions:
1. Always publish a frequency parameter units as Hertz. Then, the UI
or other controlling code would be required to do the appropriate
logarithmic scaling before calling AudioUnitSetParameter().
This is what our "generic" AudioUnit view does when it creates a slider
for a parameter of type Hertz. You can also use our functions
AUParameterValueFromLinear() and AUParameterValueToLinear() in
Jaguar's AudioUnitUtilities.h to do this type of conversion.
2. Create a new type of frequency parameter called "AbsoluteCents"
where differences of 100 AbsoluteCents correspond to one semi-tone
change in frequency (1200 corresponds to an octave change). There
would be then need to be an "anchor" point to establish the frequency
value of say middle C in absolute cents. One way to do this is simply
take the MIDI note number corresonding to a particular frequency and
multiply it times 100. AbsoluteCents then are useful both for musical
pitch and filter frequencies...
Internally, we've decided on solution (1) above. Although personally
I much prefer (2). There's actually no reason both methods couldn't
be used. Let us know what you think...
Or what if your parameter is not numeric at all, like a LFO
waveform parameter, where the values would be things like saw,
triangle, sine, etc. rather than 1, 2, 3. As it is now, so far as I
can tell AU does not accomodate for anything like this (without a
custom GUI). Perhaps something like VST's getParameterDisplay would
be good, or maybe there's a better solution?
There is a parameter type kAudioUnitParameterUnit_Indexed which can
be used for menues, etc. The value *is* still an integer, but names
can be assigned to each integer value. See the
kAudioUnitProperty_ParameterValueStrings property in Jaguar's
AudioUnitProperties.h
I think that it would be a lot nicer to have separate resources for
plugin name and manufacturer name, just like VST has the two methods
getEffectName and getVendorName (a string for the manufacturer, not
just the 4-byte code). The convention of "Manufacturer: PluginName"
for AU is kind of stupid, in my opinion. Especially when using
these with hosts that truncate the names. It would also give hosts
a good easy way to sort the AU plugins menu into submenus, placing
plugins with matching manufacturer names together. I see that AUs
are not found if placed in subfolders within
Library/Audio/Plug-Ins/Compenents/ (which itself is kind of bummy;
any chance of that changing? people are going to want to organize
their AUs as they proliferate). You could say that the host could
just scan for the : and split the string, but what if the
manufacturer name has a : in it?
Marc
We've already addressed this issue with version 2 AudioUnits, where the
subtype and manufacturer fields of the ComponentDescription are left
free for the developers use....
Chris Rogers
Core Audio Engineer
Apple Computer
_______________________________________________
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.