Re: dynamically add / remove parameter
Re: dynamically add / remove parameter
- Subject: Re: dynamically add / remove parameter
- From: William Stewart <email@hidden>
- Date: Tue, 18 Aug 2009 11:39:40 -0700
On Aug 18, 2009, at 2:56 AM, Stefan Kirch wrote:
On 18.08.2009, at 01:21, William Stewart wrote:
My workaround consists of defining the dynamic parameters as
generic parameters (eg Custom1, Custom2 etc) and simply suppling a
0..1 range. In the UI I map the values appropriately for user
feedback and if the host supports value<>strings then I can supply
something more meaningful in automation editors as well. Also, if
the user has recorded automation data at least it will be in the
correct range even when the changes happen.
Yes, this is a common approach
Ok. Thanks for all the replies.
In my case i have a synth where the user can build his own modules
with any number of parameters. He can simply drag and drop custom
controls to a module and assign them to a parameter of this module.
Something like a cheap Reaktor clone. :-)
If i take Stephen's workaround does that imply that i have to create
a pool of "hidden" generic parameters and if the user needs a new
control i take the next unused parameter out of this pool and assign
it to the new control? Something like this? And then call
PropertyChanged to tell the host that the parameter might have
changed?
Think of it like this
You have a collection of "internal parameters" that you expose to the
user to construct the basic parameters of the synth. These parameters
*never* leave the AU, so you have to be careful about how you use
these in your AU
You have another collection of "automatable parameters" - these
parameters that are published (so AULab's generic view would see
these, as would automation gestures, etc). Lets say that you choose to
have 50 parameters that you can automate (I'd also clump these into
say 5 clumps of 10 as a convenience for the user). These parameters
are all generic parameters, with a range of 0 to 1, and you can
provide custom names, string values, etc (which you can edit -
inlcuding even the name of the clump). But you don't change the number
or parameter ID of these published parameters.
In your UI you can allow the user to make an internal parameter,
published (or automatable) - you then map your internal parameter's
range (change the name, etc) of this generic,published parameter, and
as you change that generic parameter's value you map that change to
the internal one.
As you make this mapping, I think its fine to change the name, string-
to-value, etc (though some hosts may not pick this up immediately) and
you would send a notification that the parameter info changed for that
parameter (the generic one).
I don't think this will work flawlessly at first (it will with AULab
though), so then I think you should expect the host apps to fix their
implementation to support what you need - so file radar bug reports
for the apple products, etc...
At least, that is how I'd do this. It would also allow you to add a
view pane that would show the connections between the "internal"
parameters and which ones of these are published as which generic
parameter. I think you can make a kind of nice semantic out of this -
certainly a better experience for generic views and automation menus
than exposing tens (or hundreds) of parameters
Bill
stiwi
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden