[gmpi] Re: Requirements
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 11 Feb 2003 22:03:16 +0100
On Tuesday 11 February 2003 18.10, Marc Poirier wrote:
[...]
> > As to the XML part, that's a great idea for a standard preset
> > file=3D20 format (so all hosts can use the same presets), but IMHO,
> > it's too=3D20 high level and too complex for a real time plugin
> > API.
>
> I'm not sure I agree, but maybe that's just because I'm coming at
> this as a Mac OS X user and there are all these super easy
> CoreFoundation methods for handling XML data. Isn't there
> something called GnuStep or something like that which has a lot of
> similar stuff for other platforms?
There are Free and portable solutions for XML, so that's not an issue.=20
It's having plugins deal with presets in the first place that seems=20
wrong to me.
> I really would prefer not to
> discount something like XML right from the start. Settings
> compatibility and readability and upgradeability is very very
> significant with music plugins.
Good points, and I definitely think we should define an XML format for=20
preset data "while we're at it".
However, my point is that I don't see the need for a specific preset=20
API in plugins *at all*. Plugins should just be able to provide and=20
take the data - and they could do that without a special API. In=20
fact, they could even do it without being aware of the existence of=20
presets.
My line of reasoning behind this:
1) If you have preset data to save and load, it must be
possible to edit it somehow. (Or you might as well make
it static data in the plugin!)
2) If you want to edit anything, you need to hook the plugin
up to a GUI somehow. (Custom or automatically generated
from the plugin's metadata.) Why not use the control API
for that? It's *meant* for controlling plugins! :-)
3) In some cases (quite a few, actually), there's no strict
separation between parameters and controls. (By all means,
they can be non-rampable, non-RT safe or whatever, but
they can still use the same API.) Sometimes you may want
to modulate all controls of a plugin, while in some other
case, you might just want to load them with fixed values
from a preset.
Now, considering the above, my first thought is "Use the same=20
interface for all that!"
* A "save preset" operation becomes a matter of the host
getting the current values for all inputs of the plugin
and storing them somewhere.
* "Load preset" means the host reads values from a file
and sets inputs accordingly.
* Connecting a GUI means you bring up another plugin
(normally out-of-process) and connect it 1:1 to the DSP
plugin, possibly with "smart switches" in between, if
you want some controls to be automated or controlled
by other plugins.
//David Olofson - Programmer, Composer, Open Source Advocate
=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
