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:38:29 +0100
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 concur that I may not understand the existing design - though my
"suggestion" was just wishful thinking as to how I thought it
*should* work, not how I think it currently works.
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.
Right, and I do not like this. This is the part I wish was different
- that the plugin details are stored with the specific session file,
instead of having their own unique datastore, globally accessible by
any app (indirectly, through the plugins) that can load and use any
installed plugins.
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.
I'm not requiring that extra plugin settings are saved, I'm saying
this should be the *only* place the plugins save their session data.
Separately from the actual session files in whatever app loaded the
plugin and used it...
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,
My method gets rid of this 'export'/'import' requirement, which I
find needless. If I've set up a Reverb in Pro-Tools, to use it in
Logic I have to 'import' the plugin settings first? Why can't all
settings ever created for a plugin be available to that plugin ...
Why should the user have to export a plugins settings in order to use
that same plugin details in a different app in which the plugin will
be loaded just fine?
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...
I don't think I misunderstand the existing situation. I'm just
wishful for something better - I don't like the inclusion of plugin
settings data in the *host app session files*; I'd prefer it if
plugins managed their own settings data, based on a hash they get
from their host apps ...
--
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.