Re: Handling a preset group internal to a plug-in
Re: Handling a preset group internal to a plug-in
- Subject: Re: Handling a preset group internal to a plug-in
- From: Brian Willoughby <email@hidden>
- Date: Fri, 21 May 2010 18:27:25 -0700
On May 21, 2010, at 17:00, Wayne Pickering wrote:
Now it is another issue to expose this as a parameter. Assuming
that the only implementation for this control needs to be in the
view, and not exposed as a parameter, then when you save/reload the
popup for the reverb preset is going to be incorrect. Next,
assuming we implement this as a parameter that has no effect other
than to load the UI popup state, that leads to a couple further
failure modes - first the user loads a preset, then changes some of
the values (so the reverb parameters no longer match the preset
popup). Now when they save/reload the popup will say "Hall" but the
user is actually looking at modified hall parameters. The other
would be if loading the value for that parameter actually changed
multiple underlying parameters - then we have a load order issue of
whether the values are saved/loaded correctly or not as the user
could have modified values from the preset.
I don't think that I can completely answer your question, but I will
say that the AudioUnit standard allows for an indexed string
parameter that could work for your popup. You can also notify the
system when the list of strings changes, and I seem to recall that is
a property change. Thus, even without a custom UI, you could have a
generic UI that gives the user a list of choices, but if some other
state in your plugin changes, then you could still control the
generic UI such that the popup should be reloaded with new options.
In other words, I think you're considering the wrong approach when
you talk about "a parameter that has no effect other than to load the
UI popup state." The fine designers of the AudioUnit specification
have already considered this general case, and have a mechanism that
should work just fine for you.
I think you do still have some decisions to make about what to do
with the indexed string selections when changing the list. I suppose
your best bet is to make sure that index 0 always means "none" and
force the index to 0 any time the list changes - otherwise you're
going to potentially get unexpected results.
Brian Willoughby
Sound Consulting
_______________________________________________
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