On Mon, Dec 11, 2000 at 01:07:11PM +0100, Frank Neumann wrote:
> - what data fields does a plugin want to store:
> - one or several lines of text describing the name/purpose of a preset
> (probably including the author, date, revision - this might sound like
> overkill for simple filters, but looking at Steve's "Hermes" plugin,
> it's maybe good to give credit to an author somewhere)
Dublin Core. http://purl.oclc.org/dc/
The whole world should use the Dublin Core, I see red everytime someone
cooks up a halfassed metadata format. It has XML, RDF and MIME
representations, but you can express it in pretty much anything text
based.
Unfortunalty I think it's too late to make LADSPA plugins DC compliant,
but we can for the presets.
XML eg (might not be quite right, its been a while)
<DC>
<coverage>1200</coverage>
<title>A preset for Hermes</title>
<creator>John Smith</creator>
<creator.email>[EMAIL PROTECTED]</creator.email>
<subject>A preset that does stuff</subject>
<date>2000-12-11</date>
<identifier>/presets/1200/thing.xml</identifier>
</DC>
> - parameters, put into some sort of a "name, type, value" list, like
> "roomsize float 3000.0" for a 3000ms roomsize
> - ...
Well thier all floats, so the type field is easy ;)
<PORT label="foo" value="1.0"/> ?
> - the user should be able to create/modify/delete presets. So the number of
> entries can grow. Also, a way to import presets that other people have
> designed might be necessary.
Yes, cp, and rm are my favourite import and delete methods ;)
> - where and under what name to store the data. As LADSPA gives each plugin
> a unique ID, this could be part of the name. Maybe something like
> ~/.ladspa/presets/<plugin_id>.pre ? Or rather make <plugin_id> a directory
> and put the presets under it, one per file?
This is metadata, but I guess for efficiency its best to encode it into
the filename too.
You probably want /usr/local/share/ladspa/presets/ too for defaults.
> - A utility library that unifies accesses to the preset data would be a good
> thing to have. It should probably offer such functions as
If you store the presets in decent XML then you don't need one of these,
but I guess it would be good to have a standard one for ease.
> - Of course, this also requires that all plugins have a way to offer their
> presets to the user (GUI); this is where probably the XML stuff is called
> for.
I think this is a job for the host. But then I would say that ;)
NB I've used XML in these examples but I don't neccesarily think its the
best thing, just that I use it alot. RDF is probably more appropriate.
Also, how about combining this with net descriptions? Or is that too
much / too unrelated.
- Steve
