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: Fri, 25 Oct 2002 14:36:28 -0400
On Friday, October 25, 2002, at 02:01 PM, Art Gillespie wrote:
I'm sympathetic to what you're saying
Huh?
What's the confusion? I'm not saying what I'm proposing is the perfect
solution but
one where the pros outweigh the cons. I'm not going to say that Option
3 is without
cons which is why I can be sympathetic.
but I'm just troubled about whether
we can give the user the best interface without a stricter scheme. If
all the
presets are named xxxx.plist then it will appear in any file
selection box that
the user can load any preset they see, when in fact there's only a
limited subset.
Fine for the experienced user, perhaps, but potentially confusing as
hell for a novice.
Or do you mean, 'pain in the ass for host developers to make easy for
users'? It's not too hard to override the behavior of a
NavigationServices' Open Dialog (read: NSOpenPanel for all you Cocoa
types) to peek inside each plist and only show those that will work
with whatever plug-in is currently the focus of the user's attention.
Though, as a user, I would definitely think this was a nice
enhancement and not an absolute necessity... perhaps we should leave a
*little* room for host differentiation?
This is good to learn and not a feature of the NSOpenPanel I was aware
of. I'll
see if I can make an "AUPresetOpenPanel" class that does the right
thing.
Also, I think the notion of 'bank' files is an important one to
alleviate some of the horrible, dreadful, sky is falling type things
you suggest will happen if we let users do their own preset/bank
management.
I agree with the need for banks which was one of the neat things about
the preferences
file, it's kind of a built in bank.
Unlike you I don't think of presets as documents, they're not big
enough to
warrant that overhead.
Well, there's a conceptual disconnect here obviously. I don't
understand what 'overhead' has to do with it, and using size is just
plain silly (what if I want to store some large-ish things in my
presets to make it easier for users to share, say, single-cycle
waveforms, etc.)... presets meet every definition of user document
that I can think of... I guess maybe you're thinking of simple
two-parameter effects? What about a 100-parameter synth where you
slave over it for two hours getting just the right sound, hmmm?
Conceptually, you think that's the equivalent of a Macro or a Mail
rule? I've got a few hundred MB of SysEx dumps that says you're > wrong.
A few hundred MB sysex dump of a single preset? Or is that a bank + a
ton of samples?
I think presets are more like Mail.app's Rules or Microsoft
Word's Macros: small useful customizations that shouldn't be a big
organizational
headache, and shouldn't get lost!
Well, personally, I never thought the file system constituted a big
organizational headache... I mean, users have audio files, host
project files, plug-in files, the host applications themselves,
pictures of Britney Spears... they're not exactly unable to save and
load files, you know?
If we can look inside the .plist as you say above then it's not - my
main concern was that
the .plist files were not differentiatable and thus would need the user
to come up with a
scheme to make it easy to remember which preset went with which AU and
avoid a
bunch of error dialogs.
> If everyone is happy with making the user pull up a file selection
box every time
> they want to choose a user preset and potentially telling them that
they're trying to
> load an incompatible preset (because we won't know until we look
inside) then I
> guess the argument is moot.
If everyone is happy having preset/bank management foisted upon them
by the standard, then I guess the argument is moot.
Well I think you're proposing a standard bank scheme which would call
for some
standard bank management wouldn't it? Like adding/removing presets in a
bank?
> To me, though, it sounds a bit un-Mac like.
I wouldn't know. I don't even have a .mac e-mail address.
Whatever.
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.