Factory Presets

[x42]

There is no way to find out if a LV2 preset is part of a plugin bundle (factory preset), or in a read-only location.

If a user tries to delete a preset that is referenced from the plugin's main manifest.ttl, that whole file is removed (like it was a user preset). Some time later the host crashes in serd_reader_read_file.
Try jalv.gtk http://gareus.org/oss/lv2/midifilter#midichord and delete the "sus4" preset that comes with the plugin

It would be nice if presets found in

• read only locations
• the plugins own bundle
  would have a LilvNode identifying them as such.

--
Current workaround: factory presets can have a RDFS:comment (fi. zero-config-convolver has elaborate explanation of each of the IR file presets), while lilv generated user presets cannot. -- This can be used to identify some presets as "factory" presets.

[drobilla]

There is no way to find out if a LV2 preset is part of a plugin bundle (factory preset), or in a read-only location.

Read-only is a filesystem property, so this can and IMO almost certainly should be gotten from there somehow.

It would be nice if presets found in

read only locations
the plugins own bundle
would have a LilvNode identifying them as such.

Sounds like something hosts have all the information necessary to implement directly.

I'm not opposed to convenience API for this, but it's problematic to build very vague concepts like this into the library. What's a "factory" preset? What about preset bundles that are similarly "installed" content, but in a separate bundle? Should I not be able to delete some of those if they're in my user directory and I have the permissions to do so? Why not?

etc etc etc

That said...

Some time later the host crashes in serd_reader_read_file.

This is obviously a bug (assuming the host isn't doing something silly anyway).

[x42]

What's a "factory" preset?

One that comes with the plugin (in the plugin's main manifest.ttl)

Sounds like something hosts have all the information necessary to implement directly.

How?

LilvPlugin* lp;
LilvNodes* presets = lilv_plugin_get_related(lp, pset_Preset);
LILV_FOREACH(nodes, i, presets) {
  const LilvNode* preset = lilv_nodes_get(presets, i);
  ...?...
}

[drobilla]

Something along those lines I think, yeah. Path can be parsed from either the preset URI itself (if it's a file URI) or the rdfs:seeAlso, and you can do whatever with that (e.g. check if it's writable, check what bundle it comes from, etc).

I happened to be tinkering with the (terrible) preset UI in Jalv anyway, so I suppose I'll try to implement it.

Seems like this could resolve 99% of the concrete issues anyway. Concepts like "special" resources like "factor presets" or whatever don't really jive with how LV2 works. We would have to invent some things to have a "better" distinction here.

[x42]

I suppose checking if rdfs:seeAlso points to some path inside the bundle is feasible. That is only one part.

You can have 3rd party presets for a plugin.
Is there a way to check if the preset is declared inside a manifest.ttl that also has other presets?
Assuming the manifest (and state.ttl) are writable, that manifest must be edited when deleting a preset. Only removing the last preset inside a manifest can delete the file.

[drobilla]

The current implementation of lilv_state_delete already does that (or should, anyway). It is conservative in the sense that the manifest is only deleted if it is entirely empty.

[rerdavies]

in the sense that the manifest is only deleted if it is entirely empty.

Entirely empty, or entirely empty of presets? If the latter, it would be inappropriate to delete the manifest file.

[drobilla]

Entirely empty of statements. Removing data from bundles isn't particularly hard, deciding what's a "factory preset" (strictly speaking there is no such thing in LV2), or (what people usually actually mean) what presets users should be able to delete is tricky in practice, though, particularly since portable filesystem permissions are annoying. It's doable and I've been tinkering with it but I don't think there's any obviously correct solution, some heuristic like seeing if all the requisite things are writable and/or perhaps if they are in the same bundle as the plugin itself (which is what Ardour does on its own now) is probably the thing.

I am holding off the next release of Jalv until deleting presets is decently handled, so once that's done and things are more or less coherent with Ardour and hopefully other hosts as well, the way to do this should be generally established.