• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Parameter odds and ends
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parameter odds and ends


  • Subject: Re: Parameter odds and ends
  • From: Bill Stewart <email@hidden>
  • Date: Thu, 31 Jul 2003 17:36:29 -0700

Funny you should ask...

On Thursday, July 31, 2003, at 04:04 PM, Marc Poirier wrote:

On Wed, 30 Jul 2003, Bill Stewart wrote:

These are the implementation of two topics we discussed previously -
shortened paramter names and parameter clumps - comments?

Yes, 3 comments... :)


1) Big thanks for implementing this!

Good idea - even found a use for it already :)


And: Clump it is :)
kAudioUnitParameterFlag_HasClump

We'll reclaim the next four bytes of the c-string parameter name field....

char name[56]; // UTF8 encoded C string, may be treated as 56 characters
// if kAudioUnitParameterFlag_HasCFNameString not set
UInt32 clump; // only valid if kAudioUnitParameterFlag_HasClump
CFStringRef cfNameString; // only valid if kAudioUnitParameterFlag_HasCFNameString

2) Not sure if this really matters, but I guess I wonder why the clump ID
is going on top of old name[] territory rather than just getting appended
to the end of ParameterInfo, which I'm pretty sure doesn't impact any
backwards compatibility. Although I remember you once mentioning that you
might be obsoleting name in favor of cfName, so maybe the plan is to just
slowly erode its usefulness by plucking off bytes every few months... ;)
I guess there won't be any compatibility problems since you still need to
show that clump is there with a HasClump flag, so yeah, maybe this doesn't
really matter...

As you can see, slowly we will erode the space taken up by the c string.. we do expect AU's to make some attempt at localisation now for one thing... :)



Thus, if a parameter says it has a clump, then you can get the clump
number from the parameter info struct, then when displaying them, you
can clump them in together :)

3) But there's one missing piece: the name of the clumps. How does the
plugin specify these and how does the host query these? They need names,
don't you think? Like if, for example, a host is going to use clumps to
structure a parameter list and put parameters in sub-menus, it will need
names for those sub-menus to make the clumps make sense to the user.

I've also added a property (Chris Reed beat you to it), to get the name of a clump...

One other thing - the Generic view will parse through the parameters and clump them together and draw them appropriately...



I think I like it, its a word that an
Australian would use, and its both a noun (which clump) and a verb
(clump them together) - maybe I should add a "mate" after it somewhere
- you can clump them in together mate! - I really need to get out
more... :)

Glad you like the name, mate. :)

No worries cobber :)

avagoodweekend

Bill


Marc


-- 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.
  • Prev by Date: Re: OS9 (was: Re: of timestamps & midi packets)
  • Next by Date: Re: DefaultOutput puzzler
  • Previous by thread: Re: Parameter odds and ends
  • Next by thread: AU versions
  • Index(es):
    • Date
    • Thread