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: Bill Stewart <email@hidden>
- Date: Fri, 18 Jul 2003 15:02:19 -0700
OK...
So we are thinking of adding support for both of these... (though we'll
do this slightly differently than Marc (who should get the credit for
first bringing this up) proposed...)
We'll have two new parametre flags:
- has short name
- has display "bag"
I really don't want to use the word group as we already use that with
group scope, so we're trying to come up with a synonym for group - any
ideas???
Then, as for the values:
At the moment we have space for a 64 character c string in the
parameter info... We've already stolen the last 4 bytes for the
CFString name and this is really the way that the parameter names
should be published...
So, we're going to steal another 8 bytes of that, 4 for the CFString
for the short name (and we will *recommend* that this name be no more
than 8 characters long, and that they be ASCII characters), and 4 bytes
for the display bag ID of the parameter. Both of these are only valid
if the appropriate parameter flag is set...
I also think at some point in the not too distant future that we should
STOP using the c-string names for parameters completely (and just set
the first byte (maybe the first 4) to zero...
Bill
On Friday, July 18, 2003, at 02:04 PM, Urs Heckmann wrote:
Am Freitag, 18.07.03, um 22:04 Uhr (Europe/Berlin) schrieb Marc
Poirier:
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. :)
Marc,
now you get me curious 8-)
You mentioned in an older incarnation of the topic that the
AUParameterInfo struct can easily be extended. Have you tested it?
For now, these extensions make only sense inside the particular AU
(and its View), because only the AU developer knows about them.
As this struct is something that the world beyond plugin borders
(host...) is also aware of, shouldn't we set that couple of useful
extensions we might agree on in stone?
However, to chime in on VST flaws, it looks like the "category" names
appear redundantly in each parameter. If we agree that grouping
parameters make sense, we should also agree on a ParameterGroupInfo
struct that would be queried like the Parameter list. (And of course,
it needs Scope and Element stuff)
For the short names, I could also imagine we find something simple
like an optional "short_name:full_name" convention for the existing
Parameter name.
Cheers,
;) Urs
_______________________________________________
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.