Posts

Suil 0.6.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:

• Correctly handle resizing for Gtk2 in Qt4
• Improve documentation

Suil 0.6.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:

• Allow run-time configuration of module directory via environment variable SUIL_MODULE_DIR
• Fix crashes when wrapper widget is destroyed by toolkit before suil cleanup function is called
• Link Gtk wrappers with 'nodelete' to avoid Glib type errors

LV2 allows plugins to implement UIs in any toolkit. This has led to UIs being implemented in several (which is a Good Thing, and works fine in all hosts via Suil), but mostly Gtk.

Unfortunately, Gtk is not really suitable for use in plugins on platforms where a "system Gtk" can't be relied on. Some toolkits are suitable for static linking, but personally, I am somewhat disillusioned with "toolkits" lately, and massive libraries in general. Sometimes all you want or need is a straightforward standard graphics API and some keyboard/mouse events.

When it comes to standard cross-platform graphics APIs, the undisputed heavyweight king is OpenGL. While not perfect (what is?), no other API is already there on almost any platform you'd care about (heck, most modern phones have hardware accelerated OpenGL). Unfortunately, OpenGL deals only with rendering, and not user input or windowing issues. What is needed is a minimal framework to get an OpenGL view to draw to, and receive keyboard and mouse events. Enter Pugl.

Pugl handles all the platform specific business behind an API very similar to GLUT, but much smaller and appropriate for plugins (which GLUT unfortunately is not). In terms of size, this is a few hundred lines of C per platform (on a personal note, this fits in well with my ever-increasing distaste in dealing with bloated junk with tons of dependencies... give me a Couple Hundred Lines of C™ any day). The breakdown on Pugl is on its homepage, but suffice to say after a few days' work it does the job it was designed to do on X11, Mac OS X, and Windows. Since embedding X11 works in LV2 land, that means an OpenGL plugin UI can be embedded in the host, and I have the pretty pictures to prove it:

This is a simple test plugin (complete with gratuitous use of 3D) embedded in Ingen and Ardour. Both are Gtk based programs, but this works in Qt as well. Testing so far on other platforms has only been top-level since I have no programs to embed in, but the bulk of the work is done. This includes full keyboard and mouse support, with significantly more complete keyboard support than GLUT.

Naturally I can't predict the future, so it remains to be seen how much OpenGL UI action we'll see for plugins. Being just a low level drawing API and not a set of boxed widgets, it's a bit open ended with a bit of a learning curve, but on the other hand there is lots of existing OpenGL code out there. Perhaps someone will throw together a library of audio appropriate widgets, if one doesn't already exist. Either way, I think an easy to use API for writing truly portable LV2 plugin UIs is a very good thing, which hopefully eliminates a barrier for some plugin developers and helps LV2 invade the territory of its proprietary adversaries... or, at the very least, makes for a really cool 3D panner GUI :)

Jalv 1.0.0 has been released. Jalv is a simple but fully featured LV2 host for Jack which exposes plugin ports to Jack, essentially making any LV2 plugin function as a Jack application. For more information, see http://drobilla.net/software/jalv.

Lilv 0.14.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:

• Fix dynmanifest support

Lilv 0.14.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:

• Add LilvState API for handling plugin state. This makes it simple to save and restore plugin state both in memory and on disk, as well as save presets in a host-sharable way since the disk format is identical to the LV2 presets format.
• Add lilv_plugin_get_extension_data
• Add lilv_plugin_get_port_by_designation() and lilv_port_get_index() as an improved generic alternative to lilv_plugin_get_latency_port_index().
• Add lilv_plugin_get_project() and get author information from project if it is not given directly on the plugin.
• Add lilv_plugin_get_related to get resources related to plugins that are not directly rdfs:seeAlso linked (e.g. presets)
• Add lilv_world_load_resource for related resources (e.g. presets)
• Fix compilation on BSD
• Fix lilv_world_find_nodes to work with wildcard subjects
• Install man page to DATADIR (e.g. PREFIX/share/man, not PREFIX/man)
• Make Lilv::uri_to_path static inline (fix linking errors)
• Only load dynmanifest libraries once per bundle, not once per plugin
• Print presets in lv2info
• Remove locale smashing kludges and use new serd functions for converting nodes to/from numbers.
• Remove use of wordexp.
• Support compilation as C++ under MSVC++.
• Update old references to lv2_list (now lv2ls)
• Use correct URI for dcterms:replaces (for hiding old plugins): "http://purl.org/dc/terms/replaces"
• Use path variables in pkgconfig files

Suil 0.6.0 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. For more information, see http://drobilla.net/software/suil.

Changes:

• Add support for embedding X11 UIs (ui:X11UI)
• Support new LV2 UI features automatically if provided by host
• Use path variables in pkgconfig files

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.

Documentation and more detailed change logs

Download LV2 1.0.0

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:

1. Typically no need to define new binary formats for things (and be held back waiting for others to implement them).
2. Everything has a portable serialization for free (meaning network transparency, saving/loading, and for developers or power users the ability to dump any message to see what is going on).
3. The convention is to use "objects" (resources, i.e. things with properties) as messages, which are inherently extensible. No "oops I needed to add a parameter so now compatibility is broken".
4. Easy to bind to other languages or syntaxes, so e.g. Python or browser-based UI frameworks should be possible.
5. Any RDF vocabulary can be used, meaning millions of well-defined and documented predicates ("keys") are available right now (though it is perfectly okay to create one-off objects - compatibility with RDF is a benefit, not a burden).

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.