• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: dynamically add / remove parameter
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
References: 
 >Re: dynamically add / remove parameter (From: Ian Kemmish <email@hidden>)
 >Re: dynamically add / remove parameter (From: Stephen Blinkhorn <email@hidden>)
 >Re: dynamically add / remove parameter (From: William Stewart <email@hidden>)
 >Re: dynamically add / remove parameter (From: Stefan Kirch <email@hidden>)

  • Prev by Date: Re: Wrapper class for Cocoa Audio Units in Carbon Hosts
  • Next by Date: Re: SDK questions
  • Previous by thread: Re: dynamically add / remove parameter
  • Next by thread: how to modify the recorded audio data?
  • Index(es):
    • Date
    • Thread