Re: Parameter scope quandry
Re: Parameter scope quandry
- Subject: Re: Parameter scope quandry
- From: Bill Stewart <email@hidden>
- Date: Wed, 30 Jul 2003 15:22:57 -0700
I wouldn't use properties for this... though if you look through
AUBase::SaveState you'll notice that we do save some property values
anyway... but you lose the parameter scheduling mechanism...
I think there are many ways you can cut and slice this, both with
"Meta" params, as well as "Expert" mode params - which are more
tweaky...
For many of our effects we use the elementID as an index into a vector,
for a certain range say, and then reserve other ranges for params (like
read only level parameters) that are runtime dependent on the num
channels being processed...
It sounds to me like you should go ahead and do what is the most
powerful and flexible, then let it sit for a while and figure out how
best to publish it given the more common usage scenarios.
As Knuth said "Premature optimisation is the root of all evil", well
OK, not *all* maybe... :)
Bill
On Wednesday, July 30, 2003, at 02:55 PM, AJ wrote:
Well my example may have been too organized. I was not meaning to
imply that setting one oscillator would automatically change the
others.
I was trying to indicate that I'm...
1. not excited about the code replocation necessary when having 1
parameter per oscillator (kMyAU_Osc1Hz ..... kMyAU_OscNHz), and
2. trying to use an (as of yet undetermined) integer as an index into
a container of oscillators to reduce code size, and
3. going for the ability to dynamically create oscillators (which
means 1. has problems anyway since I will always be limited by
kMyAU_OscNHz for some N).
For 2) I'm trying to repurpose the element ID and see if I can use it
as an index as well. Given the contents of the e-mail thread, I
currently don't feel this will work well.
Soo... I'm going to either going to "give in" (typed with a chuckle)
and have different parameters for each oscillator
kMyAU_Osc1Hz, kMyAU_Osc1Phase, kMyAU_Osc1Amp,
kMyAU_Osc2Hz, KMyAU_Osc2Phader, kMyAU_Osc2Amp
... etc
and limit the number of oscillators I can have.
Or after investigating properties, use properties instead. For
example to set frequency I could use a kMyAUProperty_OscHz property
and associate the following struct with it:
struct OscChange {
UInt16 osc_num;
Float32 value;
};
Then I could add code at some point like the following:
osc_vector[change->osc_num]->setValue(chage->value);
I could also have a kMyAUPropery_NumOsc which would allow me to
get/set the number of available oscillators and acheive my goal of a
dynamic number of oscillators.
My concern with properties though is two-fold, and some further
comments should help me decide on this issue and get on with my life
(ermmm i mean coding) ;)
1. Can property state be saved or somehow reflected in presets?
2. I lose the frame offset ability available in SetParameter()
Thanks for the continued support.
--aj
From: Bill Stewart <email@hidden>
Date: Tue Jul 29, 2003 5:24:10 PM US/Pacific
To: AJ <email@hidden>
Cc: email@hidden
Subject: Re: Parameter scope quandry
AJ
OK - that makes sense...
We have a parameter flag called "Meta" that is used to describe the
situation you are outlining (as I believe that what you want is to
set the base level freq for an oscillator, and have the other 2
change according to that value)...
On Tuesday, July 29, 2003, at 05:12 PM, AJ wrote: <snip>
--
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.