The Plugin Settings Approach.
The Plugin Settings Approach.
- Subject: The Plugin Settings Approach.
- From: Jay Vaughan <email@hidden>
- Date: Tue, 11 Feb 2003 23:05:50 +0100
All this 'import plugin settings from file' blah stuff is really a
solution to a problem that just shouldn't exist. Same with
artificial preset list limits.
Here's how I wished plugins would behave with regard to how to handle
saving their 'presets' and recalling them across different
application sessions:
1. All plugins in any host app are passed a "filename" on init, or
some hash derived thereof. This is a key derived from (or perhaps
just) the 'Pro Tools session name', or "Logic Song Name", etc. It
can be used by the plugin to uniquely identify the 'session' of the
host app with which its settings are associated, based on filename -
the same way that a unique filepath is used to associate all data
created during that session in the app itself.
2. Plugins have their own local store - unlimited (128 'presets' in
software plugins is a novelty with no reason whatsoever) in capacity,
just like any other app. This local store should be off ~/Library
somewhere, or maybe ~/Documents/PluginSettings/ would be better.
(This location should be adjustable in a "Plugins" Systems Pref
control panel... which I believe is seriously omitted from the AU
spec right now)
3. Plugins store the hash key (it could also just be the filepath
string) from #1 in their own personal settings files (which,
incidentally, should be using XML ...) as part of the plugin
'setting' that gets saved at end-of-session time.
This way, when an app tells a plugin to load settings using step #1,
the plugin can itself retrieve the details of its settings from its
own store - the plugin settings *should be disassociated* from the
host apps own 'session' data store.
This way:
a) Plugins are treated as 'mini applications' with their own context,
stashed in the users ~/Documents/PluginSettings dir, and these
settings are usable across *any* of the applications which will play
host to the plugin.
-The plugin datastore should be *separate* from the app datastore,
yet use a properly computed and well-documented hashing function to
be able to do its own load of settings on a per-session basis,
per-app, as well as saves.
b) The user can load plugin settings across-projects.
-If I set up a nice plugin Reverb in a LAW song one day, I *should*
be able to load that same plugin Reverb in a Pro Tools session file
later as well, simply by picking "LAW Songs - Happy Days - Reverb
Plugin Setting" from the Reverb Plugins 'preset' list (I *hate* the
use of the term 'preset' for a software plugin...) when I load the
plugin in ProTools.
--
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.