Hello, 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. lv2_dyn_manifest.ttl: @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. """ . lv2_dyn_manifest.h: #ifndef LV2_DYN_MANIFEST_H_INCLUDED #define LV2_DYN_MANIFEST_H_INCLUDED #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(); #endif /* LV2_DYN_MANIFEST_H_INCLUDED */ 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 something?). 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, Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
