[gmpi] Re: 3.13 Persistence

On Fri, May 28, 2004 at 03:00:18PM -0700, Chris Grigg wrote:
> Sorry for the lag, I was vacationing (mid-Pacific, far too bright for 
> LCDs).  8-)

I hear that it is so impractical to use a computer there, that people
actually turn theirs off.  Instead they spend time on "beaches" (big plots
of raw silicon, known as "sand") and frolicking in the ocean like some
sort of fish, as if any other mammal would be as silly. :)

> "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?>>

I'll add one to the parameters section requiring this.

> 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."

This one is getting too "speccy".  Mind if I nix a few of the later
details?  I think the requirement is summed up well up to "A Bank file may
contain any number...".  The numbering and contiguity are not really
requirments, are they?  Also, I disagree that it needs to be human
readable.  Instead, I'd say it needs to use existing technology, (such as
zip or tar).  I also want to leave off anything that says it is optional.
I'd like to see the GMPI format become THE format for distributing
presets, so it's not really optional.

> 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).

I'm no XML nut, but it makes a nice extensible format.  That said, I don't
care if it is XML or any other text-based format.  That's the requirement
- human readable. :)

> 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.

At some point we agreed that the benefit was twofold:
1) ONE and ONLY ONE mechanism of saving/restoring state
2) human readable presets is a nice feature.

Now, I don't think that the final preset format will ONLY be the
parameters, but will be some meta-data and probably some optional binary
blob header or something.  The main goal is to make a preset
hand-tweakable.

> 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.

This is an important detail, but I don't know what the requirement is in
terms of compatibility.

I think the general rule should be that a plugin is always backwards
compatible with old presets.  If you need to break compatibility with old
presets, change the plugin ID.

I will update the doc today.

Tim

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: