Re: The Plugin Settings Approach.
Re: The Plugin Settings Approach.
- Subject: Re: The Plugin Settings Approach.
- From: Marc Poirier <email@hidden>
- Date: Wed, 12 Feb 2003 16:12:12 +0100 (CET)
On Wed, 12 Feb 2003, Jay Vaughan wrote:
>
My approach attempts to make it *easier* for the musician to use
>
their plugins, across multiple apps and across multiple computes.
>
The existing approach requires an "import/export" stage for the muso,
>
and also has the problem that plugin settings are not safely stored
>
individually, nor are they transportable across apps, easily.
Yeah, I see that that is an issue... (more below)
>
In fact, there's a 3):
>
>
3) Make all plugin settings easy to back up, and support the
>
"~/Documents" design guide which Apple would like everyone to use,
>
I'm sure (it makes for easy backups, user admin, etc).
Yes, easy to back up, but when you actaully want to look in that folder...
(see below)
>
>Solving #1 with a chunk (sorry for the VST terminology) in the song
>
>file is a fine solution.
>
>
Until you want to use that preset setting elsewhere, in which case
>
you have to remember which song file it was in and do an
>
'export/import' step. Blagh!
>
>
Seems to me you're the one not thinking like a muso!! :) (No offense intended)
Well, as the muso part of me speaking, I find this solution a little bit
like using a blowtorch to light a candle. In my songs, I use tons of
plugins, and I would say that probably less than 1% of the settings that I
come up are useful in any other context than the specific track of that
specific song. What I would be left with, using your approach, it a
folder full of thousands of settings with filenames using some obtuse hash
naming system and I would never be able to find the 0.6% of useful presets
in that overflowing folder! If I come up with some setting while working
on a song that I think is really generally useful, then I export a preset.
Then I name it something that I will remember, put it somewhere where I
will find it, and it's great. With your system, sure I would have all of
those presets already ready to go, but in a totally chaotic mile-high pile
of files that I'd need to spend ages searching through.
Please don't be offended by my disagreement, I respect your ideas and
definitely do recognize the problems that you're trying to address and
that they are real, but I think that your proposed solution would create
new problems that are worse than the ones that are being solved.
On Wed, 12 Feb 2003, B.J. Buchalter wrote:
>
OK, but this does have a number of practical problems as well:
>
>
1) If the user copies the session file to another computer without
>
copying the plug-in settings files, they cannot open the session
>
properly (e.g. The session is not self contained).
Yes, I was thinking about this too. I see a potential tech support
nightmare brewing already... ;)
>
2) If the hash changes for some reason the link breaks -- any number of
>
unexpected events could cause this to happen.
>
>
3) If you change the contents of the preset later, it will
>
in-advertently change one or more sessions (silently). This is a huge
>
problem. If this is avoided by having unique setting files for each
>
session, the management of the settings becomes the users problems.
Yes yes, all very serious problems.
>
Note that there is a fundamental difference between current state and
>
named settings. Pro Tools gets this right. VST does not. IMHO,
>
individual settings should be represented by one preset file (XML is
>
file). "Banks" should be represented by directories containing preset
>
files. If we want to bundle the directory so that it looks like a file
>
to a casual user, that would be fine. Multiple "banks" should be
>
available to the user at any given time in all hosts -- organized and
>
browse-able hierarchically.
That all sounds nice to me, personally. :)
Marc
_______________________________________________
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.