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: Stephen Blinkhorn <email@hidden>
- Date: Sun, 23 May 2010 15:27:22 -0600
On 21 May 2010, at 18:00, Wayne Pickering wrote:
Let's say, for example, that we have a complex audio unit with
multiple signal processing blocks.
In the UI, we would like to put a preset mechanism to load some-but-
not-all of the audio units parameters, for example, say the AU has
among other things a reverb block, we would like a popup that says
"hall, plate, chamber, toilet, etc.".
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).
The usual DAW solution to this is to change the preset name to an
italic font or something like that to indicate that it has been edited.
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.
In my preset loading mechanism for distortion/filter presets I use a
drop down menu with an open file icon so if the user loads a 'tube
amp' preset the parameters are updated but the preset name isn't
displayed anywhere. These are hard-coded default settings that the
user can use as starting points.
I hope I explained that well. This whole thing is somewhat twisted...
I'm wondering if anybody has developed something similar, and what
you did to ensure a congruent user experience. I wasn't planning to
implement a user load/save for these "sub-presets" as that
introduces a whole 'nother layer of complications when moving from
machine to machine, this is just for some quick and dirty factory
settings.
I also allow the user to save a fixed number of their own presets and
the user preset menu items are built by inspecting the saved preset
names in the dictionary. Well, I say I do this but it hasn't been
released yet :) Works though.
Hope I understood properly,
Stephen
_______________________________________________
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