Re: Presets etc.
Re: Presets etc.
- Subject: Re: Presets etc.
- From: Marc Poirier <email@hidden>
- Date: Fri, 10 Jun 2005 10:08:51 -0400 (EDT)
While personally I'm not against the possibility to change a factory
presets list, and I can see some reasons where it makes sense, I just want
to say that, in my opinion, most of your reasons don't make sense...
On Fri, 10 Jun 2005, Urs Heckmann wrote:
Examples of changes to the list of Factory Presets and reasons therefore:
- The custom gui of an AU lets the user retrieve a folder of .aupreset files
to be treated as Factory Presets for this single instance.
- For a live gig a musician prepares several instances with different lists
of Factory Presets because he can switch through them with Midi Program
Changes. He needs different sets for different instances.
- The AU treats a certain folder as the list of Factory Presets. The user
puts a new .aupreset into this folder and expects *all* instances to change
their list. In that case all instances will listen to folder changes and
issue a PropertyChanged notification on the list of Factory Presets. (Is this
the token worst case?)
All of these I think are handled just fine, or really better, by just
taking advantage of the "blessed" AU presets locations. Simply build your
directory hierarchies, sorted however you want, of aupreset files in the
standard location and good AU hosts know to scan those and build a
structured UI for the user to load those preset files. "Translating" the
aupreset files to factory presets just seems a little, well, pointless to
me, and kinda silly and weird.
- A modular AU (think Reaktor) switches to a new structure of "patch cords"
(think Reaktor Ensembles). The list of Factory Presets would change to
presets that comply with the new structure.
Yes, this makes sense to me. Or the example that I've been thinking from
the start is that I've thought of maybe trying to implement something like
this for SFX Machine RT, removing some of its factory presets when it is
configured in mono-mode rather than stereo-mode, since some of the presets
do nothing but stereo-based processing and are entirely ineffectual in
mono-mode.
- A crazy plugin developer generates all Factory Presets by randomization.
Thus every instance has a different list from the beginning, but the user can
re-randomize the list.
Ehhh, well sure, but honestly I think it would be better design to just
provide a randomize state button of sorts. It's 2 steps to randomize your
presets and then load one, but only 1 step to just randomize the current
state, and either way you get the same results, so there's no point in
randomizing the presets, in my opinion. But if someone wants to do it,
whatever... Of course, though, probably you're just talking about
randomizing the parameter state data, which isn't even a part of what the
factory presets property data is about (that is just preset number and
name), so as long as that doesn't get randomized, then the property
technically hasn't changed, at least according to what the host sees.
- An AU has different sets of Factory Presets depending on environmental
properties, i.e. if a Side Chain is available or any type of Channel
Configuration is present (Stereo/Surround/Quattro). Changing the track
properties makes the AU instance change the list of Factory Presets.
Yes, this one makes sense to me, too.
Marc
_______________________________________________
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