Re: Parameter scope quandry
Re: Parameter scope quandry
- Subject: Re: Parameter scope quandry
- From: Chris Rogers <email@hidden>
- Date: Wed, 30 Jul 2003 16:10:44 -0700
AJ,
Why don't you just publish N oscillator paramID's (where N may be variable
depending on some other configuration) and order the ID's sequentially
such that
kMyAU_Osc1Hz = kMyAU_Osc1Hz + 0
kMyAU_Osc2Hz = kMyAU_Osc1Hz + 1
kMyAU_Osc3Hz = kMyAU_Osc1Hz + 2
kMyAU_Osc4Hz = kMyAU_Osc1Hz + 3
kMyAU_Osc5Hz = kMyAU_Osc1Hz + 4
.
.
.
(using the above method, you don't need to explicitly define constants for
anything except for kMyAU_Osc1Hz)
Then you can easily compute an index:
index = paramID - kMyAU_Osc1Hz;
Where 0 <= index < N and you can easily index instance arrays, etc.
Your code should be very simple this way.
I don't think element is not going to work for what you're trying to do.
1. Can property state be saved or somehow reflected in presets?
You can, and should save any relevant property state in your preset.
2. I lose the frame offset ability available in SetParameter()
Not sure what you mean here...
Chris Rogers
Core Audio
Apple Computer
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.
_______________________________________________
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.