[gmpi] Re: Requirements
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 12 Feb 2003 02:03:05 +0100
On Tuesday 11 February 2003 19.33, Marc Poirier wrote:
> > > It seems desirable for all hosts, regardless of platform, to
> > > store plug=3D in settings in the same format. Mayne that is not
> > > necceasry.
> >
> > Ok, but that's a host thing. It has nothing at all to do with
> > plugins (right?).
>
> Maybe I'm missing something here, but so far as I see it, plugins
> obviously need to be concerned with the settings format. They have
> to receive and process settings
Yes.
> and they have to produce them.
No - unless they can "learn" from audio and control input, but I think=20
that's a separate issue. (A plugin doubling as it's own UI,=20
basically.)
Normally, presets would be generated by the *GUI* part of a plugin,=20
and then (considering that plugins may come without custom GUIs) it=20
has to be sent to the plugin in a way that
=09* avoids sending a full preset for every change
=09* allows gatewaying through whatever connection is
=09 used between DSP and GUI parts
=09* allows hosts to query, intercept or otherwise get
=09 hold of the data for storing it to file
> So far, a few possible schemes have been suggested. The data can
> be completely under the control of the host and simply a snapshot
> of parameter values.
I prefer this way.
> In that case, the plugin need not know
> anything about the settings format, however, no one's going to
> agree to that since it's clearly not sufficient for a lot of
> plugins' needs.
Like what? (Though this is a deep subject... We've probably written a=20
few hundred kB on the topic over at LAD.)
> Another possibility is totoally opaque data
> blocks, which the plugin needs to know about; in fact, the plugin
> is the only one who understands it.
What about the GUI? What about plugins without custom GUIs...? There=20
*has* to be a finer grained interface to the data, no matter what.=20
Why not base it on the control interface?
> And another possibility is
> some sort of data format, which could be defined as a data
> structure, a data block with tags, or a keyed XML structure. So
> anyway, if the plugin is provided with a keyed XML data block, it
> certainly will need to know that it's a keyed XML data block,
> otherwise what will it do?
Well, yes - but then you have two options for GUIs:
=091) Have them parse and generate XML as well.
=092) Use a separate (private or public) interface
=09 for GUI/DSP communication.
If 2) + public, it's no longer obvious why *plugins* should read and=20
generate preset files, since hosts could easilly intercept the data=20
on the way from the GUI to the DSP plugin.
//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:
