[gmpi] Re: 3.13 Persistence

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

That's fine. I'll try to remember to put them back in when we get to the spec phase... in late 2009.


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 don't understand your motive then, as there's nothing editable about zip or tar. What are you really after?


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.

Well, I agree that would be a nice outcome, but good luck selling that to the big host companies who already have their own ways of saving session state data. I'm suggesting making it optional as a way of cutting to the chase.


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

Uhh... which side do you intend to argue? 8-) Above you said you .didn't. think it did need to be 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.

What if the plug decides to change its parameter set in the middle of a state save? How do you prevent that?


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.

Then that should be explained in this section. How would you put it? What metadata? Why the blob, what would be in it?


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

Another possibility is that a plug could expose not just a single plugin product ID, instead expose a list of the preset format versions it can read. In other words, the plugin ID is one build-time plug property, but the 'compatible preset types' list is another. The plugin ID is used for most purposes, but the list is used when figuring out what preset types the instance can access.


I will update the doc today.

Thanks!

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

Other related posts: