Re: Parameter scope quandry
Re: Parameter scope quandry
- Subject: Re: Parameter scope quandry
- From: AJ <email@hidden>
- Date: Wed, 30 Jul 2003 14:55:36 -0700
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:
Thanks for the rapid response....
I'll try and be more clear by first explaining what would work but I
am trying to avoid. After that I will try and explain why I am trying
to avoid the approach.
I could (and may end up) have(ing) three different parameters in
global scope as in kMyAU_Osc1HzParam, kMyAU_Osc2HzParam, and
kMyAU_Osc3HzParam and then set frequencies:
// set three oscillators to A
AudioUnitSetParameter(au_osc_bank, kMyAU_Osc1Hz,
kAudioUnitScope_Input, 0, 220, 0);
AudioUnitSetParameter(au_osc_bank, kMyAU_Osc2Hz,
kAudioUnitScope_Input, 0, 440, 0);
AudioUnitSetParameter(au_osc_bank, kMyAU_Osc3Hz,
kAudioUnitScope_Input, 0, 880, 0);
I believe this is the solution you are suggesting? Then in a
parameter listener I can trap the parameter id and do the right thing:
switch(param->mParameterID) {
case kMyAU_Osc1HzParam:
osc1.setHz(inValue);
break;
case kMyAU_Osc2HzParam:
osc2.setHz(inValue);
break;
case kMyAU_Osc3HzParam:
osc3.setHz(inValue);
break;
}
... or I could try and be fancy
switch(param->mParameterID) {
case kMyAU_Osc1HzParam:
index = 0;
break;
case kMyAU_Osc2HzParam:
index = 1;
break;
case kMyAU_Osc3HzParam:
index = 1;
break;
}
osc_vector[index]->setHz(inValue);
So taking the long route to get back to what I mean when I say "Same
settings for different instances" I mean that each oscillator is
actually a different instance of the same class and having to write
seperate lines of code using seperate parameter IDs to change seperate
oscillators feels a bit tedious. Especially since I really just need
to map the parameter value to an index.
If I go back to to having only a single kMyAU_HzParam I would
ultimately (if possible within the API of course) like to not have 3
parameters but only 1. I feel as if I need only 1 since at a modeling
level changing the frequency on multiple oscillator instances is much
like your changing volume on multiple mixing channels. In short I was
hoping to have a parameter listener do something like:
switch(param->mParameterId) {
case kMyAU_HzParam:
osc_vector[param->inElement]->setHz(value);
break;
// other stuff
}
This code is much simpler and would seem to allow for the number of
oscillators to be changeable during runtime! Because of this
simplicity of code, I was attempting to see if AU scope and elements
could be molded to behave in this manner. Do you think they could?
I would do this using the meta parameter flag
(kAudioUnitParameterFlag_IsGlobalMeta) - ie. this is a parameter that
can change more than just its own value... The generic view will still
display meta flagged parameters...
Then, you'd still publish this parameter in global scope, el 0, and
you'd only have the one parameter that you'd set. You would also of
course have the other 2 parameters with real values, and if you want
these to be set independently, then you could publish these as "expert"
mode parameters (so generic UI's don't see them), or not publish their
information at all (so they become a private param for your own
purposes)...
Bill
cheers
--aj
--
"Chance is the limit of the notion of evolving symmetry."
-- Iannis Xenakis
_______________________________________________
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.