[LV2] how to supply a large number of factory presets with a plug-in

[David Robillard]

On Wed, 2013-04-03 at 20:36 +0100, Nick Dowell wrote:
> On 31 Mar 2013, at 22:47, Harry van Haaren <harryhaaren at gmail.com>
> wrote:
> 
> > On Sun, Mar 31, 2013 at 6:31 PM, David Robillard <d at drobilla.net>
> > wrote:
> >         <http://example.org/somebank>
> >             a pset:Bank ;
> >             rdfs:label "Bank of Americon" ;
> >             pset:bankEntry [
> >                 pset:preset <http://example.org/preset1> ;
> >                 lv2:index 0 ;
> >             ] , [
> >                 pset:preset <http://example.org/preset2> ;
> >                 lv2:index 1 ;
> >             ] .
> > 
> > 
> > I think this is the best solution if we can make the "index" an
> > optional tag.
> > 
> > That way simple preset banks don't have to specify an order, but if
> > its
> > 
> > wanted its possible.
> > 
> > 
> > I value being able to include a preset in multiple banks, so the 3rd
> > option is a -1 from me.
> > 
> 
> Agreed. I value the ability to specify the order of presets within a
> bank quite highly, making this the most suitable solution for me.

Any solution will need numbering, the main question here is whether a
preset can be a part of several banks.  If a preset must only be a part
of one bank, the data could be a bit simpler.

> Would it be bad form to infer the ordering of presets by the order in
> which they appear in the list, rather than requiring an lv2:index?

There is no such order here, just many values for the pset:bankEntry
property.  Multiple values have no order, the one in the file is
arbitrary and meaningless in the model.

It is possible to use lists to do that, though.  This would look like:

<http://example.org/somebank>
    a pset:Bank ;
    rdfs:label "Bank of Americon" ;
    pset:bankEntries (
        [
            pset:preset <http://example.org/preset1> ;
            lv2:index 0 ;
        ] [
            pset:preset <http://example.org/preset2> ;
            lv2:index 1 ;
        ]
    ) .

I tend to avoid lists deliberately in LV2 stuff though, since reading
them in code is more confusing and sticking with just properties makes
life easy and consistent.  In this case, compatibility with pre-defined
MIDI banks, which sometimes have gaps in the numbers, probably means
such a solution is no good anyway.

-dr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130404/4afc5cb7/attachment-0002.pgp>