[LV2] How to load a LV2 preset stored in a Turtle file?
d at drobilla.net
Mon Apr 30 04:46:56 PDT 2018
On Mon, 2018-04-30 at 03:42 +0200, Robin Gareus wrote:
> On 04/30/2018 02:23 AM, Sylvain Leroux wrote:
> > Hi everyone,
> > I would like to extend lv2apply
> > (https://github.com/drobilla/lilv/blob/master/utils/lv2apply.c) to
> > support presets and plug-in states stored as Turtle data files.
> Hi Sylvain,
> I guess you're coming from
> Coincidentally Julien _FrnchFrgg_ Rivaud and me discussed this
> today on IRC and I have whipped up a patch to `lv2file`:
> > As a starting point, I would like to load a preset (example below).
> > I
> > think I should use either serd,sord, or sratom. But I'm not quite
> > sure
> > which of these libraries is suitable for that task, nor how exactly
> > to
> > load a Turtle file. Maybe someone could point me to an example?
> lilv_state_restore() does it all and uses serd/sord under the hood.
Yes, use the state interface of lilv, don't attempt to do this
manually. This is what the state interface is for, that way more
complex things like state/presets with files and so on will work.
> For an example use, maybe the recent git-log of
> https://github.com/x42/lv2file can help.
> It would be nice to have a clean implementation of this, but IMHO it
> would make more sense to continue re-factoring lv2file and clean
> up there instead of extending lv2apply.
> For noise-repellent, you'll also have to add support for an LV2 URI
> to lv2apply at the very least.
> As opposed to lv2file, lv2apply is very clean and good example code
> in fact it seems that lv2file was initially inspired by it. I am not
> sure if it is a good idea to clutter up lv2apply with all the
> complexities of making it a feature-complete file processing host.
> Eventually there should be support for Atom ports, worker extension,
> replicated mono-plugin instances for stereo-files, downmixes for mono
> files, delay-compensation...
> @drobilla: What do you think?
I think it would be fine to extend lv2apply to be more featureful.
It's nice to have such things included in the "main" libs.
If it became such a huge mess that it would no longer be useful as an
example, that'd be unfortunate, but state shouldn't add very much.
Regardless, if that became the case, it would be highlighting a
problem, and it would be better to improve lilv or add utilities or
whatever to fix it.
More information about the Devel