Re: Filing of User Presets - files vs. builtin
Re: Filing of User Presets - files vs. builtin
- Subject: Re: Filing of User Presets - files vs. builtin
- From: Robert Grant <email@hidden>
- Date: Thu, 24 Oct 2002 21:50:28 -0400
On Thursday, October 24, 2002, at 02:15 PM, Bill Stewart wrote:
>
>
I'm still digesting the rest of the comments and trying to understand
>
if
>
there has been any consensus reached on this matter - if anyone feels
>
like
>
writing a summary of the ideas presented that would help an overworked
>
designer here understand:)
>
>
Bill
>
I'll try to take this on as I raised the issue in the first place.
First a description of the background to the problem.
AUs can ship with a small number of conveniently embedded factory
presets. User
can extend this set of presets by saving custom configurations as a
user preset
and setting the AU to use the preset by passing in the data and setting
the preset
number to -1.
In order to persist these user presets host applications are expected
to store them
somewhere on the user's computer.
The Problem:
With AUs being a system standard it is highly likely that they will be
supported in a
number of different audio applications. Given this fact it is also
highly likely that users
will want to access all their custom presets conveniently no matter
which host they might
currently be using. Additionally users typically share their presets
with other users which
means they need to be in a convenient and standard format for easy
exchange.
Possible solutions:
File Format: Everyone agrees that storing the preset in a .plist is
ideal.
The debate is really about where to put the user presets:
Option 0. Save the preset in any old place (where we are right now! :-)
Pros: Simple to implement and easy to share.
Cons: Users have to figure out an organization scheme and there's no way
for a host to build a complete list of the users presets for a
particular AU.
Option 1. Save the preset in a standard AU preset folder under
Library/Audio/Plugins
Pros: Simple to implement. The class info is already a CFDictionary so
reading and
writing the file is already coded. Easy to share.
Cons: Preset folder would soon fill up with a hodge-podge of presets.
Users would have
to come up with a sensible organization scheme. Hard to come up with a
list of
user presets for a particular AU.
Option 2. Save the preset in a standard subfolder based on the
manufacturer/plugin name or similar scheme that keeps the presets for a
particular AU together.
Pros: Same as above + user doesn't have to worry about organization
scheme and
easy to build a list of user presets. Very scalable.
Cons: Host writers have to worry about creating the directory
hierarchies correctly,
possibly mitigated by some common code? Seems a little untidy?
Option 3. Save the preset in a preferences dictionary in
Library/Preferences, using the
bundle id as the filename. Presets for an individual AU would all be
stored in the
same preferences file.
Pros: Same as 2 but without the con of having to do the directory
hierarchies and
it seems to fit nicely with OS X's way of doing things. Nice and tidy.
Cons: Getting at individual presets is more difficult thus making
sharing presets
less straight-forward. Would mean implementing an import/export scheme
for
individual presets. Concerns about scalability.
I think that covers it. A few a voting for 2 and a few are voting for 3
(including myself).
There is also the question of handling banks of presets but they're
really just
refinements of either 2 or 3 and not separate solutions.
Any other options?
Thanks,
Robert.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.