Re: GetParameterValueStrings
Re: GetParameterValueStrings
- Subject: Re: GetParameterValueStrings
- From: Bill Stewart <email@hidden>
- Date: Wed, 20 Aug 2003 22:37:57 -0700
We will consider any suggestions for other parameter types; as Marc has
described the AU expresses parameters in their natural ranges, not a
normalised range, and these types are easily extended (there's a few
million or so slots available here :)
With the existing and additional API that have already been added there
are now I think sufficient mechanisms in place for generic views
(always a less satisfying user experience) to at least present
reasonable information about parameter values, etc
As for providing the ability to provide a "unit" name type for generic
parameters - I don't see a sufficient reason to add this, and I see
many ways in which this feature would be abused.
Bill
On Wednesday, August 20, 2003, at 07:07 PM, Marc Poirier wrote:
On Wed, 20 Aug 2003, Jim Wintermyre wrote:
If it were up to me, I would say don't use VST as the "neutral"
interface,
or use it with some supplementation (your own hooks or data or
whatever to
provide some additional necessary info). VST is definitely not a
neutral
platform. It's the dumbest and most deficient of all of the
interfaces,
so as a result, you're starving the rest of them.
Well, I guess we're just going to have to agree to disagree here.
Our current method works perfectly well for all the other platforms
we currently support (but thanks for explaining how dumb it is :-),
No, I called VST dumb, not your methods. But by using a VST
foundation,
you are losing out on the advantages of handling parameter values the
AU
way (not normalized), as I described. It's up to you whether you think
that's dumb or whatever, but it is true, so no need to shoot (or
sarcastically complain to) the messanger...
and it's just not going to happen that we're going to do any major
redesigning right now just to work with AU. We're already most of
the way there, in fact the main issue currently is just this generic
UI stuff. I don't understand why adding the things I suggested seems
like such a bad thing. It only helps improve the AU functionality
for generic params as far as I can tell.
I didn't say it was such a bad thing (that's exaggerated again), but
more
importantly, it's definitely not up to me anyway. ;) I was just
giving my
thoughts, mostly because your first message demonstrated that you
didn't
understand how AU parameters are used, so I've been trying to help you
determine whether AU parameters as they are now would be a good enough
possibility for you.
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.