Re: Question on clumps
Re: Question on clumps
- Subject: Re: Question on clumps
- From: Marc Poirier <email@hidden>
- Date: Fri, 1 Aug 2003 10:11:23 -0500 (CDT)
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.
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).
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
_______________________________________________
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.