Elements:

  • factory presets (installed with a plugin, possibly via RDF bundles or other means)
  • user presets (saved by the user in his home directory, hopefully with least effort possible, i.e. one-click + optionally type a name, not a filesystem-based save dialog - so the mechanism must handle the naming and path management internally)

Challenges:

  • file format
    • RDF is preferred
    • compact format a la larsl (1:0.4 2:0.8 ...) is compact, but may be considered ugly, and this particular one isn't compatible with LV2 core v3 (because of the possibility of rearranged/inserted ports)
    • verbose format is insanely verbose, leading to obscene amount of data per preset, even more per preset bank (and compressed RDF sounds really desperate). A 200 port plugin with 40 bytes per port is ~8 KB, which is bad but acceptable. 128 presets, each 8 KB, is 1 MB, which is also acceptable (apart from embedded world, which can use its own non-RDF version). Calf's XML format uses similarly obscene data sizes without anyone complaining.
    • we definitely want to use symbols, not port indices (in fact, Calf already does), even if it causes super-ultra-bloat - it's the only good way to keep it compatible with LV2 core v3
  • some plugins (calf) already have their own preset management, which allows for reusing the same presets (including user presets) by different versions - DSSI and standalone, and by different hosts
    • it doesn't work particularly well in DSSI, and supporting DSSI should not be a top priority - but for now there is no realistic alternative for Qt hosts
  • host authors already don't have time to develop hosts (at all), adding more burden is counterproductive
  • plugin authors would prefer to concentrate on developing plugins, not on managing presets (though frameworks like calf's make that point moot)
  • loading and updating RDF is not so pleasant
  • those are *plugin* presets, not *host* presets, so being able to use the same preset in multiple hosts seems rather understandable
  • common data interchange format (like fxp/fxb in VST) - especially for export/import
  • where to store user data? (bundles in .lv2? what goes into a single bundle? how to update?)
  • XML vs RDF (RDF might be fine except redland/raptor/rasqal is generally a PITA and will probably remain one for some time)
  • there are different ways instruments handle presets:
    • fixed number of indexed slots (array model - typical for hardware instruments) vs just a list with names (map model - software instruments)
  • grouping presets in banks makes sense because it makes finding easier - but larsl's extension doesn't give that information (that might be added by separate extension though)

Solutions:

  • factory presets - via RDF file(s) in a bundle - the only contention point is representation
  • user presets - at least three solutions:
    • it is up to the host to manage user's plugins, and no other host or other software can access those presets (simple but hopefully we can do better)
    • a shared library that could be used by LV2 hosts and non-LV2 plugins to access the same preset "database" (which could be a bunch of TTL files, or a single text/XML/sqlite file, or a cluster of Oracle databases etc. - just kidding)
    • an interface for "preset manager plugin" libraries, just like we already have with GUIs and dynamic manifest (by Stefano D'Angelo); I could make such a .so from existing calf code (and hopefully it will be the only one used, unless it's really so bad or someone has a bad case of NIH) - this ensures preset compatibility while letting each plugin decide how to store presets (possibly in a way that allows cross-host interoperability)
      • maybe Stefano's dynamic manifest can be reused instead of inventing a new thing?
    • can be built into SLV2 (though adding more stuff to it is not what SLV2 currently needs)
    • RDF or XML files, one file per preset in a separate path (outside bundles) - LV2_PRESET_PATH, defaulting to $HOME/.lv2/presets/ ? (the factory presets might still be obtained via normal LV2 bundles)
  • export/import - could use the same format as factory presets

DO NOT WANT:

  • classification (almost essential, but may be added later) - we don't need to solve the problem of searching in 300 presets when we don't have 300 presets yet