Re: GetParameterValueStrings
Re: GetParameterValueStrings
- Subject: Re: GetParameterValueStrings
- From: Jim Wintermyre <email@hidden>
- Date: Tue, 19 Aug 2003 23:58:26 -0700
At 9:15 AM -0500 8/19/03, Marc Poirier wrote:
On Mon, 18 Aug 2003, Jim Wintermyre wrote:
The thing is, the host can never know all possible types of
parameters that a plugin might want to use. I guess that's what
kAudioUnitParameterUnit_Generic is for; but currently, there's not a
way to get the required display information to make it at least as
complete as VST. I guess kAudioUnitProperty_ParameterValueName will
help in this regard. There also should be a way to specify the
parameter unit label for generic params (see getParameterLabel() in
original message).
Perhaps that would be useful...
To me, it's as useful as your value distribution curve request. :-)
> >So you'll find that, once you define your parameters properly in AU, the
>host and any generic interface has a lot more information about your
>parameters than with VST, and you can get much better generic interfaces.
>For example, you could check out our Skidder at
>http://destroyfx.org/audiounits.html and look at it in an app that uses
>the GenericView, like AudioUnitHosting, and you'll see that it's very good
>what with all of the sliders with literal ranges and pop-up menus and
>checkboxes and whatnot.
I was checking out one of the TC plugins installed by Spark
(SparkDelay) in this case. In Logic 6 on OS 9, in controls mode the
controls display useful information; in Logic 6 on OS X in controls
mode the param values are meaningless. This could be fixed in
subsequent Logic versions (this was 6.0 I think).
It's nothing with Logic (6.0 should be fine), but with the particular
plugin, which simply isn't doing what it should be doing.
One of the plugins in question is the VST_AU wrapper. In an ideal
world, which is what I am looking for, the VST API could be mapped
well enough to the AU API that the generic view for AU-wrapped VST
plugins would work correctly. As it stands currently this is not
possible for the reasons I've been mentioning.
> >In my opinion, the one important thing missing is a way to specify a value
>distribution curve. Like if you have some sort of parameter and you want
>it to be have it's values scaled logarithmically rather than linearly to
>get a nicer response with a generic interface, currently there's no way to
>specify that, but I'll keep trying to convince Apple folks that it's
>important... ;-)
Well, from my VST-ish background, I'd say just do the mapping in the
plugin... but I can see where this would be useful.
Yes, VST-ish, too VST-ish to work in AU. ;-) If you're dealing with
literal values for parameters, like with AU, then you won't be scaling
internally, because what you get is what you get, e.g. if your 3 - 9
parameter gets set to 8 as its value, then the value is 8, there's nothing
to map. But with VST, it's all squashed into 0 to 1, so you always need
to do mapping with everything.
Or think of it this way: with VST, you don't actually know what the
parameter's value is until you've set it. The only way to know is after
setParameter and then getParameterDisplay have both returned, after the
fact. So this only works in the context when you are "finding" the value
that you want by gradually adjusting some continuous control. But if you
have a parameter value in mind and want to set it right now, you are sore
out of luck with VST, but it is no problem with AU since it presents its
parameter value ranges as what they actually are.
I guess I can see that being a problem in the generic editor. In our
custom editors we handle this with editable text boxes for things.
It will accept appropriate text for the given control.
Parsing/translation happens inside the plugin code.
The difference is most apparent if you use a host app like Max/MSP, for
example. Max/MSP offers incredible control and arrangement possibilities,
but VST plugins are kind of left out of that because in order to interface
with the other control elements in the app, you need to set parameters as
values. But with VST plugs, you never know what the hell value will
correspond with the actual value of the parameter that you want. It's
fine if you're just tweaking with the plug's GUI editor, but it becomes
really difficult when you try to connect the plug's control into the rest
of your patch. Other Max users will know what I'm talking about, it's a
real pain in the ass...
I understand what you're saying.
However, I still stand by my requests as useful. Here's a key point
for me. All of the plugins I'm working on basically use VST as the
primary "platform-neutral" interface to the plugin. We have these
plugins running in VST (Mac/Win), MAS (Mac), DX (Win), and TDM (Mac).
All of the non-VST versions actually talk to the VST API and
translate appropriately. It works fine. I want it to work fine in
AU too. It already does work fine using the custom editor which is
what people will use 95% of the time. I just want it to work fine in
the generic editor as well.
For many parameters we can map them to the appropriate AU units etc,
but there will still be some generic ones. For those params, the few
requests I made will make it work fine.
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.