Re: Hardware control surfaces (was Re: Private Parameters)
Re: Hardware control surfaces (was Re: Private Parameters)
- Subject: Re: Hardware control surfaces (was Re: Private Parameters)
- From: Jim Wintermyre <email@hidden>
- Date: Fri, 18 Jul 2003 13:15:20 -0700
At 3:04 PM -0500 7/18/03, Marc Poirier wrote:
On Fri, 18 Jul 2003, Jim Wintermyre wrote:
>The only plugin API that I know of that handles this is RTAS.
>Developers explicitly map parameters to hardware knobs and define what
>parameters appear on what pages. You can even provide a page table for
>a specific piece of hardware, to provide the absolute best mapping
>possible. Very, very nice. (There are definitely reasons that people
>stick with ProTools.)
Actually, VST does have a routine that allows you to specify the
ordering of parameters for "display" purposes (where "display" could
be either a generic UI, or external hardware controller). That
routine is called getParameterProperties(). It allows you to specify
a number of other useful things which would be useful for a hardware
controller to know, such as a "shortened" param name, whether a param
is a switch/discrete/continuous, display "categories" (which would be
like the related control groups you mention above) etc.
Unfortunately most hosts don't support this routine, or only
partially support it. One host which does support it in part is
Logic, and it is very helpful for making Logic Control work well with
with VST plugs.
Well, the other big "unfortunately" is that it's not documented at all in
the VST docs or headers. The details are very very fuzzy. It's always
seemed like something that could be useful, except that practically no
host supports it (no surprise, it's all undefined) and it's really only
useful on the plugin side if you can rely on the host supporting that
stuff, so even if that stuff was well defined, it's just kind of a hack
piled on top of the existing VST API, and not as useful as it should be.
Yeah, believe me I know your pain!! :-) But it *is* used in Logic to
support Logic Control, and implementing it in our plugins has made
them work *much* better with Logic Control.
> I'm new to AU, so I don't know this, but I would assume that AU has
some similar functionality? If not, it's definitely something to
think about adding.
In AU, parameters are handled properly period. There's no extra optional
stuff to give the necessary information about parameters. So yes, it's no
problem in AU. :)
That's good... but then, Chris says:
At 2:51 PM -0500 7/18/03, Chris Reed wrote:
The shortened param name in particular is another thing that is
missing from the AU spec. The way I'd prefer to see it implemented
is: add a new property that lets the host query for a parameter's
name given a number of characters that it has to fit in.
enum {
kAudioUnitProperty_ParameterShortName = ?
};
typedef struct {
AudioUnitParameterID mParamID;
SInt32 mNumberCharacters;
CFStringRef mShortName;
} AUParameterShortName;
You call AudioUnitGetProperty, passing in a pointer to an
AUParameterShortName structure with the mParamID and
mNumberCharacters fields filled out. Upon returning, the mShortName
field will contain a name that fits within mNumberCharacters.
There is also no way to specify that a parameter should appear on a
knob/slider or a switch when presented on a control surface.
Both of these are very important IMHO for getting useful behavior
from a control surface when controlling the plugins. Many control
surfaces will truncate the param names automatically using some
general algorithm, but the results are never as good as if you can
specify the short names directly from the plug. Also, we took a lot
of heat from Logic Control users when our params that were actually
switches didn't respond to the push button pots on Logic Control.
Once we implemented the aforementioned VST routine, things worked
fine and everyone was happy.
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.