Re: Question on clumps
Re: Question on clumps
- Subject: Re: Question on clumps
- From: Bill Stewart <email@hidden>
- Date: Fri, 1 Aug 2003 12:57:50 -0700
On Friday, August 1, 2003, at 08:11 AM, Marc Poirier wrote:
Reserving 0 as the un-clump ID is exactly what I proposed in my
original
clump implementation suggestions. However, there were 2 other
important
differences with my implementation ideas: there was no HasClump
parameter
flag and the clump ID value in AUParameterInfo came after everything
that
already is in there (rather than on top of name's old territory). I
think
that interpretting 0 as "no clump" is fine as long as you move the
clump
value out into its own new space in AUParameterInfo. Otherwise, I
don't
think you can base your clumpness conclusions strictly on the clump ID
value; you will need to still check the HasClump flag. I say this
because
an old, non-clump-saavy AU could very well have uninitialized random
memory, or the end of a name string, in bytes 57-60 of name. Then the
"lazy host" would think that it was getting some valid clump IDs in the
AUParameterInfo, but really they would not be valid, it would just be
an
old AU that didn't even have a concept of clumps yet.
You misunderstand... you have to SET the flag in the parameter info's
flag field (which already has to be set appropriately to tell the host
whether the parameter is read/write, etc...)...
If the flag is not set, then there is no clumpID.
We will continue to reclaim the c-string case, because parameter names
in general should be localizable friendly, and the only way to do this
is with CFStrings. (more to say about CF stuff shortly - I haven't
forgotten!)
So anyway, what I'm saying is that I think that taking out the last 4
name
bytes for clump ID is fine as long as the HasClump flag is always
taken as
the evidence of a valid clump ID existing. I like the idea of a
reserved
0 anti-clump ID just fine, but it is redundant if there's also a
HasClump
flag, and in that case I don't like it as much since I don't like
redundancy of that sort. But if the HasClump flag is dropped *and* the
clump ID value gets appended to the end of the AUParameterInfo struct,
then I think that it's fine (but note that, as I said in my original
implementation ideas message, the host should zero out the
AUParameterInfo
struct before Getting the ParameterInfo property, so that the host
doesn't
get bitten by an old AU that doesn't touch that tail end of the
AUParameterInfo struct).
Its not redundant if some of the parameters are clumped and some are
not.. (That was the concern I had with my lazy:) code)...
If all of the parameters are clumped, then it isn't an issue.
So, I think we are in agreement at least that clumpID==0 is a
"reserved" value (which is great, because the code can actually be
quite clean then to deal with clumps and non-clumped paramters)
Oh, and Marc - thanks for the original suggestion - sorry it took a
while to understand it, but it really is a nice feature.
Bill
Maybe I am just not thinking totally clearly since I just rolled out of
bed, but that's how it looks to me...
Marc
On Thu, 31 Jul 2003, Bill Stewart wrote:
This might be me being lazy :)
I'm looking at the code for our generic UI which now supports clumps.
Its very simple and straight forward to "reserve" the clumpID of zero
to capture those parameters that are not clumped
The logic looks something like this:
UInt32 clumpID = 0;
param.GetClump (clumpID); //no clump, clumpID is left unchanged
map[clumpID].push_back (param);
This deals quite effectively with parameters that aren't clumped at
all, and deals with mixtures of clumped and non-clumped parameters if
none of these clump ID's are zero. If there is a mixture of
non-clumped
and clumpID==0, then you'd get these all clumped together... which is
probably not what you want.
So, given that the above is simple logic, I imagined that others would
appreciate being able to deal with this so simply as well, so I'd
propose reserving zero as a value that shouldn't be used by individual
AU's
enum {
kAudioUnitClumpID_System = 0
};
Thus, if you have a mixture of clumped parameters and non-clumped
parameters, then the non-clumped parameters will be treated as if they
are clumped into a clump where the ID is zero.
Does that make sense? Seems like a nice thing to do for us lazy host
writers? Is this going to cause any problems for people?
In fact, if we reserve the clumpID==0 for "system" use, then AU's that
don't provide explicit clumps, could still provide a name for all of
their parameters that aren't clumped (for the GetClumpName property)
by
just providing support for this system clump
Bill
--
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.