Sratom 0.2.0
Sratom 0.2.0 has been released. Sratom is a small library for serialising LV2 atoms to and from RDF, for converting between binary and text or storing in a model. For more information, see http://drobilla.net/software/sratom.
Sratom 0.2.0 has been released. Sratom is a small library for serialising LV2 atoms to and from RDF, for converting between binary and text or storing in a model. For more information, see http://drobilla.net/software/sratom.
The first unified LV2 release, LV2 1.0.0, is out.
This release merges the previous lv2core package with all the official extension packages, as well as example plugins, lv2specgen, and additional data. From a developer point of view, the biggest change is that all LV2 API headers can be used by simply checking for the single pkg-config package "lv2" (for compatibility the previous "lv2core" package is still installed). Implementations are encouraged to abandon the "copy paste headers" practice and depend on this package instead.
With this release, several new extensions have become stable that together greatly increase the power of LV2: atom, log, parameters, patch, port-groups, port-props, resize-port, state, time, worker.
I have been working on full round-trip serialisation for everything in the LV2 Atom extension (which also applies for implementing state). I am doing this as a small library with a simple API, with the goal that it be simple to include in any project.
svn co http://svn.drobilla.net/lad/trunk/sratom
Currently this only writes (using Serd), I still need to move the reading stuff into it (which will probably use a model and thus require using Sord).
The Atom extension defines a simple data model for use in LV2 plugins and hosts (or elsewhere). The general Big Idea here is to have a smallish set of primitive types, a few collections, and out of that one can build arbitrarily complex structures. Everything (including containers) is a simple and compact chunk of POD data, but serialises to/from (a subset of) RDF, so it can nicely be described in a plugin's Turtle file, among other advantages.
An easy to adopt serialisation API is important to making these advantages a reality for many implementations, so I have decided to provide one before marking these extensions stable. It also serves as a nice test case with complete coverage. Here is an example of an Atom that contains every currently defined Atom type, as well as MIDI, serialised to Turtle by sratom:
[]
rdf:value [
a eg:Object ;
eg:one "1"^^xsd:int ;
eg:two "2"^^xsd:long ;
eg:three "3.0"^^xsd:float ;
eg:four "4.0"^^xsd:double ;
eg:true true ;
eg:false false ;
eg:path </foo/bar> ;
eg:uri eg:value ;
eg:urid eg:value ;
eg:string "hello" ;
eg:langlit "bonjour"@fra ;
eg:typelit "value"^^eg:Type ;
eg:blank [
a eg:Object ;
] ;
eg:tuple [
a atom:Tuple ;
rdf:value (
"foo"
true
) ;
] ;
eg:vector [
a atom:Vector ;
rdf:value (
"1"^^xsd:int
"2"^^xsd:int
"3"^^xsd:int
"4"^^xsd:int
) ;
] ;
eg:seq [
a atom:Sequence ;
rdf:value (
[
atom:frameTime 1 ;
rdf:value "901A01"^^midi:MidiEvent ;
] [
atom:frameTime 3 ;
rdf:value "902B02"^^midi:MidiEvent ;
]
) ;
] ;
] .
I anticipate/intend for all plugin control to happen via such messages, since this approach has a few important qualities:
The atom extension includes an API that makes it relatively simple to build such objects in C, so plugins can write them directly to an output port or a ring buffer. See the "forge" API in the Atom extension for details. There are also iterators for all the collections and a "get" function for objects to make reading data simple.
Just in case it's not crystal clear, the above is only the external representation of the corresponding atom. At run-time, an atom (i.e. what plugins work with) is just a blob of data with an integer type and size header. 100% of the API provided for reading and writing atoms is real-time safe and suitable for use in an audio processing thread.
For an example, see the LV2 sampler example, which has a UI that loads samples via such messages. It currently works in Jalv, Ardour support is coming soon. This is the way forward for more powerful LV2 plugin control, and hopefully will end the worrying practice of abusing direct instance access to provide such functionality.
This work isn't finished yet, but the important parts are done and not likely to change significantly. I am interested in hearing any developer feedback, feel free to comment on this post or at the LV2 mailing list.
Lilv 0.5.0 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications. For more information, see http://drobilla.net/software/lilv.
Changes:
Lilv 0.4.4 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications. For more information, see http://drobilla.net/software/lilv.
Changes:
Suil 0.4.4 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. For more information, see http://drobilla.net/software/suil.
Changes:
Lilv 0.4.2 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications. For more information, see http://drobilla.net/software/lilv.
Changes:
Suil 0.4.2 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. For more information, see http://drobilla.net/software/suil.
Changes:
Lilv 0.4.0 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications. For more information, see http://drobilla.net/software/lilv.
Changes:
Suil 0.4.0 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. For more information, see http://drobilla.net/software/suil.