Re: The Plugin Settings Approach.
Re: The Plugin Settings Approach.
- Subject: Re: The Plugin Settings Approach.
- From: Jay Vaughan <email@hidden>
- Date: Wed, 12 Feb 2003 08:42:16 +0100
I'd have to agree with Marc. This sounds like a design an engineer
would be happy with, but not a musician. Imagine trying to gather
up all the files you used in a project for backup or to carry
to another studio.
You've misunderstood me completely. If your plugins are saving their
settings off ~/Documents/PluginSettings, there is only one place to
go to back things up - ~Documents (or wherever it has been configured
by the user in a SysPref).
That you don't see this implies that you don't fully understand my
design idea, and I apologize for that. It was late at night when I
wrote up my 'idea'.
The existing method means that if you've got plugin settings you use
on a big Pro Tools session, and then 'lose' that session file
somewhere, then the plugin settings go with it.
Sorry, though, it seems like you've got it backwards in terms of
understanding my 'Approach' text.
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.
I believe there are two fundamentally different ways that patches
are archived:
1) as a faithful record of the settings used in a particular project
This can *still* be done with my approach, and is the first order of
business for plugins using the hash passed them by the host app on
load time.
2) as a library from which patches may be retrieved for use in future
projects.
This is the *second* order of business that my approach solves,
putting all Plugin settings in a single folder instead of having them
scattered across the disk, archived in each individual apps project
files...
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).
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)
My approach allows this:
1. I set up a Reverb plugin just the way I like it.
2. I can use that same Reverb plugin setting in *any* host app I choose.
3. I can go to ~/Documents/PluginSettings and see all my plugin data
saved as .XML files, which I can then easily back up.
4. Plugins know which settings file to load for each host apps
project, using the hash (or filename, simply) passed to them at
load-time. Likewise, this same hash is used at save-time to
associate session settings with plugin settings.
What _is_ missing, from VST (and perhaps AU) is a good solution to
the second problem. Ideally you should be able to easily add a patch
to the library and efficiently browse it from any host,
preferably with one-mouse click loading a single patch for auditioning.
- Glenn
Riiiight, that's what I'm getting at with my approach. My solution
solves both problems.
--
j.
Jay Vaughan email@hidden
>>music:technology:synthesizers - www.access-music.de/
_______________________________________________
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.