[gmpi] Re: 3.13 Persistence
- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 1 Jun 2004 11:08:52 -0400
I'm happy with this summary.
Apologies for going dark these last few weeks. My day job has been
pretty demanding lately...
-----Original Message-----
From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On
Behalf Of Chris Grigg
Sent: Friday, May 28, 2004 6:00 PM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: 3.13 Persistence
>It's time for topic #3.13 - Persistence.
>
>Have at it:
> http://www.gmpi-plugins.org/gmpi/requirements.php#sec_3.13
>
>Tim
Hi --
Sorry for the lag, I was vacationing (mid-Pacific, far too bright for
LCDs). 8-)
I think the meaning of the text is fine, but the nouns should be made
more consistent. Plus a little grammar fixing. And I think we should
have more specificity about the purpose and organization of the files.
Also I think the state definition concepts should come first.
So... can I suggest?:
"Req 59: The plug-in's state is defined to be the collection of
its stateful parameters' values. Every parameter is either stateful or
non-stateful (this parameter property may not change over the plug's
lifetime), and GMPI must define a mechanism for the host to determine
this for each parameter. <<Should this idea also be reflected in the
Parameters section?>>
Req 60: For a host to save the state of a plugin, it simply queries all
the plug's stateful parameters and saves them somewhere.
Likewise, to restore the state of a plugin, a host simply sets all its
stateful parameters to the stored values.
Req 61: GMPI must define a simple file format for storing plugin
state, for use both in user preset libraries and GMPI graph
save/restore. Such files are called Presets. A Preset file must include
the values for all of a plug's stateful parameters, therefore completely
describing the plug's state. The format must also indicate what plugin
(manufacturer, product, and product version) provided the data. For GMPI
graph save/restore, it is up to the host to keep track of what plugin
instance the state represents. The file format must be human-readable
and editable with an ordinary text (incl. Unicode) editor. Host usage
of this file format is optional.
Req 62: GMPI must define a simple file format for storing user
libraries of Presets, probably based on the Preset file format described
above. Such files are called Banks. A Bank file must also indicate the
plugin product (manufacturer ID, product ID, and product version ID)
that provided the data. A Bank file may contain any number of Presets.
Within a Bank, each Preset may be named, and must be numbered. Preset
numbers must be unique but need not be contiguous. The file format must
be human-readable and editable with an ordinary text (incl. Unicode)
editor. Host usage of this file format is optional."
ALSO ---
All the above goes along with two design decisions I'm not actually all
that crazy about:
1 - Specifying XML as the preset/bank file meta-format is OK for
computers, but not necessarily so good for tiny devices; depends on
whether the DTD is close-ended or open-ended (open-ended is way
bigger/harder to implement, close-ended is probably fine).
2 - I don't understand why we make the host query every plug for its
parameters and then query state on each one of them, when we could just
require the plug to provide one big Preset parameter. Very modest
impact on plug authors, IMHO.
3 - In a Bank, what if there are different product versions? Can their
Presets still go into the same Bank file? Put the other way around, how
much need to be in common for a preset to be allowed into a given Bank?
We need to take product renaming, cross-compatibility, etc. into account
here.
-- Chris G.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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:
