-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Factory Presets #55
Comments
Read-only is a filesystem property, so this can and IMO almost certainly should be gotten from there somehow.
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...
This is obviously a bug (assuming the host isn't doing something silly anyway). |
One that comes with the plugin (in the plugin's main manifest.ttl)
How?
|
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. |
I suppose checking if You can have 3rd party presets for a plugin. |
The current implementation of |
Entirely empty, or entirely empty of presets? If the latter, it would be inappropriate to delete the manifest file. |
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. |
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 pluginIt would be nice if presets found in
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.
The text was updated successfully, but these errors were encountered: