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: Chris Reed <email@hidden>
- Date: Fri, 18 Jul 2003 18:53:40 -0500
Why don't we add a parameter-info dictionary somewhere that will let us
provide as much additional information about each parameter as we like,
without having to worry about about structure sizes or new properties
or whatever? Instead of stealing another 8 bytes from the C-string name
for two fields, why not steal just 4 bytes for a CFDictionaryRef?
As for other things to put in the dictionary, what about a "bag" name.
(Btw, look up "group" in a thesaurus. There are some pretty funny
synonyms for this context.. :-)
Using a dictionary means that we won't have to worry about adding and
checking new flags. If the key is in the dictionary, the value can be
considered valid. Although, I guess there should be a flag to indicate
the presence of a valid dictionary.
Also, instead of having a single short name, what about an array of
short names of different lengths? I think having more than a single
short name is important--some control surfaces have 6 chars, some 4,
etc. It's very little more effort for a vastly better result. Why go
only part of the way to solving the problem?
-chris
On Friday, Jul 18, 2003, at 17:02 US/Central, Bill Stewart wrote:
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.
_______________________________________________
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.