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 00:43:23 +0100 (CET)
Jay, I think that you are seriously misunderstanding how settings work in
AU. Part of that is understandable, at least the stuff about "using Logic
settings in a Pro Tools session." That's because Logic and some other
apps currently are not following the AU specifications. If they were,
then all settings would be compatible accross all apps. The plugin does
not need to handle its own file i/o in order to accomplish that level of
compatibility; all that we need is for host apps to follow the spec that
already exists. In my opinion, offloading the chores of settings file i/o
to the plugin is a last resort measure for a seriously broken or deficient
API. Which is not what AU is, and it covers this area just fine.
I also think that you are confused about the ways that the settings are
stored. When you save your session/song data in Logic or Pro Tools or
whatever app, generally what happens is that the plugin settings are
embedded as a block of data in the host app's song document file. The
only time when the plugin settings are a file unto themselves are when you
explicitly export them to a "preset file" (or whatever the app wants to
call it). Requiring that extra plugin settings files be saved in a
dedicated directory every time you save a song document in a host app
seems to me to be way needlessly excessive and convoluted.
Basically the way it should currently work is that your settings data is
embedded within a host app's song document when saved, and then you can
also choose to export a specific plugin settings file if you want to,
which is in a standard XML format AU settings file which any AU host
supporting the AU spec can load. I think that the issue is just that some
apps (Logic and Metro, maybe others) are not complying. So your remarks
would be better directed at the developers of non-compliant software.
Unless I totally misunderstood you, in which case I apologize for the
off-base rambling...
Marc
On Tue, 11 Feb 2003, Jay Vaughan wrote:
>
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.