Re: Parameter scope quandry (again)
Re: Parameter scope quandry (again)
- Subject: Re: Parameter scope quandry (again)
- From: James Coker <email@hidden>
- Date: Fri, 1 Aug 2003 16:45:05 -0600
I am re-posting this at Bill Stewart's request. Also, I figgure that
if this sort of AU parameter handling gets added at all,
now is the time to do it..... Jim
........................................................................
Bill,
Actually, I think that what AJ means is that the oscillator values
are "array" values, or in Java / EJB terms, indexed properties--
not to be confused w/ AU indexed parameters. I mentioned this
a while back, and there was a question at the WWDC Feedback
forum as well, but if I remember your response correctly, I don't
think you quite groked what the speaker was getting at: A better
way to handle parameters that are essentially arrays of values,
whether they are bands in an equalizer, frequencies for a bank
of oscillators, or steps of a step sequencer.
Consider how you might specify the parameters for a step
sequencer with 16 steps. The current API forces you to define
16 parameters, each with an ID, and the need to code parameter
information appropriately. This code is pretty easy to handle,
but it hides useful information both from the user of the plugin and
from
the developer. A more informative approach to handle this
situation is to allow an array-valued parameter, which has
a defined size (number of items), and is set by specifying
both an ID and an index:
AudioUnitSetIndexedParameter(audioUnit, parameterId, parameterIndex,
kAudioUnitScope_Global, ....)
Now the array-valued-ness of the parameter is visible to the host,
so it could build a Generic UI properly, or present a more
intuitive UI for picking parameters to modulate. From the
AU coder's perspective, it makes communication between the UI
and plugin cleaner. Instead of indexing off of a base
parameter ID, or managing an explicit ID constant for
each parameter, you can explicitly specify the index for
the parameter. It is just like using:
char buffer[50];
buffer[4] = 'c';
instead of:
char buffer[50];
buffer + 4 = 'c';
i.e. If you know it is an array, and plan to treat
it like an array, then call it an array.
I should point out that the Apple 31-band EQ is
an obvious target for this approach. Note
that the editor for that plugin presets a row of vertical
sliders, rather than the more usual generic UI of vertically
stacked horizontal sliders. This layout implies a semantic
connection among the parameters that would not exist
if the UI interpreted them generically. Surely it also
makes sense to reflect that connection within the
parameter specification for the AU as well.
As I mentioned above, the JavaBeans / EJB specification
uses this approach, and from my own experience, I can
say it is very successful.
Cheers,
Jim
On Tuesday, July 29, 2003, at 10:52 PM, Bill Stewart wrote:
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]
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
--
mailto:email@hidden
tel: +1 408 974 4056
_______________________________________________
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.