[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


> 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

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: