[LAD] LV2 dyanic manifest extension proposal

Stefano D'Angelo zanga.mail at gmail.com
Sun Jun 8 01:31:59 UTC 2008


First of all I want to announce that the next version of NASPRO will
shift to LV2 as its internal model, which means that it will contain a
collection of bridges from other APIs to LV2 and viceversa

In order to accomplish such a thing (writing wrappers for LV2), a
special extension is needed to make the host call some function in a
shared object file to generate a new manifest.ttl-like file (possibly
using tmpfile() or similar). The host will call this function and read
the file to know about bridged plugins.

Now, I wrote something (taking "inspiration" from other extensions,
etc.), but since I'm a total beginner with RDF and LV2, please someone
check whether the following stuff is correct.


@prefix :       <http://naspro.atheme.org/ext/dyn-manifest#> .
@prefix lv2:    <http://lv2plug.in/ns/lv2core#> .
@prefix dman:   <http://naspro.atheme.org/ext/dyn-manifest#> .
@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix doap:   <http://usefulinc.com/ns/doap#> .
@prefix foaf:   <http://xmlns.com/foaf/0.1/> .

<http://naspro.atheme.org/ext/dyn-manifest#> a lv2:Specification ;
        doap:license <http://usefulinc.com/doap/licenses/bsd> ;
        doap:name "LV2 Dynamic Manifest" ;
        rdfs:comment "" ;
        doap:mainainer [
                a foaf:Person ;
                foaf:name "Stefano D'Angelo" ;
                foaf:homepage <http://zanga.netsons.org/>
        ] .

:DynManifest a rdfs:Class ;
        rdfs:label      "Dynamic Manifest" ;
        rdfs:comment    """
The class which represents a dynamic generator of a manifest.ttl-like file.
""" .



#include <stdio.h>

/* This function shall create a temporary file containing the dynamically
 * generated manifest.ttl-like file and return a FILE pointer or NULL in case
 * of failure.
 * The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();


I hope this is enough since I'm guessing that manifest.ttl can also
contain plugin-related information (the LV2 wiki suggests using
separate files, but maybe it's possible/valid nonetheless).

Then, some kind of API property could be associated to a plugin class
to indicate the original plugin API (needs an extensions or

In the end, I'm using FILE * because of file locking + standard C
library. If anyone is against that, please say so (with motivations).

Thanks in advance,


More information about the Linux-audio-dev mailing list