Re: Question on clumps
Re: Question on clumps
- Subject: Re: Question on clumps
- From: Urs Heckmann <email@hidden>
- Date: Fri, 1 Aug 2003 10:20:02 +0200
Haha,
damn, I have to reclump my clumps 8-)
Well, I had in mind to assign clumps to modules / dsp building blocks,
starting with Clump Zero (does William Gibson read this list?). Hence I
could assign her clumplessness to the plasma that keeps it all
together. But then, subtracting an Offset du Clump isn't such a big
deal.
While we're at it, is there a way to get a parameter's Inner Clump
Index? - It would be very convenient to have a method that provides a
parameter's position inside a Clump array. - Currently I do this by
Parameter ID, so that every parameters that belong to a module are
neighbours ( i.e. attackID = 15, decayID = 16, ... ) and I subtract the
first id to get the "inside module index" of a parameter group. (Is
this understandible?)
This way, if I add parameters for a new version of a device, I have to
add them somewhere inside of the current list. On the downside, this
may break automation data, if automation data is stored by parameter
index.
Now, if I could use Inner Clump Index, I could add new parameters to
the end of the list, and existing automation data will remain fine. -
So I think it would be nice to have your Clump array list inside AUBase.
Does this make sense?
(On the other hand, I could as well roll my own Clump Map, but maybe
it's useful anyway, so...)
Cheers,
;) Urs
Am Freitag, 01.08.03, um 08:33 Uhr (Europe/Berlin) schrieb Bill Stewart:
From: Bill Stewart <email@hidden>
Date: Thu Jul 31, 2003 10:28:36 PM US/Pacific
To: email@hidden
Subject: Question on Clumps
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.
_______________________________________________
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.