drobilla.net - LV2

Jalv 1.8.2

2026-06-08T23:50:00-04:00

Jalv 1.8.2 has been released. Jalv (JAck LV2) is a simple host for LV2 plugins. It runs a plugin, and exposes the plugin ports to the system, essentially making the plugin an application. For more information, see http://drobilla.net/software/jalv.

Changes:

Add log window to Gtk interface
Add separate menu item for saving current preset
Clean up on exit from console interface
Disable delete preset action for non-writable presets
Fix control output refresh rate
Fix port controls
Fix state scratch directory location
Fix updating message-based parameters when loading presets
Improve command parsing
Improve save preset dialog
Only create a state scratch directory when necessary
Remove obscure save-as action
Update string controls when focus leaves entry in Gtk interface

Lilv 0.28.0

2026-06-08T22:25:00-04:00

Lilv 0.28.0 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.

Changes:

Add early assertions for non-null parameters in public API
Add lilv_state_get_bundle_path()
Always create state files with O_CLOEXEC on glibc >= 2.7
Clarify relative symbolic link creation when saving state
Fix build with dynmanifest support
Fix crash when loading plugin classes on Windows
Fix potential file loss when saving state with no link directory
Fix potential iterator leaks and resulting log message flood
Fix replacing links when saving over state
Fix test build when no C++ compiler is available
Improve error handling when writing and deleting state

lv2plug.in outage

2026-05-15T17:56:00-04:00

Some irresponsible and/or malicious crawlers brought down lv2plug.in this week. To avoid this happening again, I've removed lv2plug.in/git entirely, since it was the only dynamic thing at that domain. There used to be a cgit interface to the repositories there, but I doubt anyone will miss this anyway. Everything else should now be back up and working as before.

Suil 0.10.26

2026-02-10T19:50:00-05:00

Suil 0.10.26 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. It provides wrappers that allow Gtk and Qt hosts to load, and potentially embed, plugin GUIs that use the "native" windowing API (Coca, WIN32, or X11).

Changes:

Add clang nullability annotations
Address new warnings in clang and clang-tidy 21
Fix documentation build without sphinx_lv2_theme

Lilv 0.26.4

2026-02-10T18:47:00-05:00

Lilv 0.26.4 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.

Changes:

Add clang nullability annotations
Address new warnings in clang and clang-tidy 21
Fix default LV2 path on cross-compiled Windows builds
Fix loading of duplicate bundles with equivalent versions
Fix potential crash when UIs have multiple types or binaries
Use consistent quoting and punctuation in log messages

Sratom 0.6.22

2026-02-10T18:45:00-05:00

Sratom 0.6.22 has been released. Sratom is a small library for serializing LV2 atoms. Sratom reads/writes atoms from/to RDF, allowing them to be converted between binary and text or stored in a model.

Changes:

Add clang nullability annotations
Address new warnings in clang and clang-tidy 21
Fix documentation build without sphinx_lv2_theme
Gracefully handle reading vectors with missing childType properties
Gracefully handle writing vectors with zero childSize properties
Improve error handling

A More Modern Gtk3 Jalv Frontend

2025-11-26T21:36:00-05:00

My simple single-plugin LV2 host, Jalv, isn't quite sure whether it's a developer utility or polished user program, but in any case, it had become stale in the past few years and needed an update.

Most of those changes are internal and only interesting for those who use it as a basis for larger systems. The internals have been largely rewritten to support various things, but this post isn't about that. This post is about a more obviously stale thing: the Gtk2 interface.

In keeping with the free desktop tradition of constant breakage with reduced functionality, that toolkit is now EOLed, and soon the ability to embed GUIs whatsoever will probably go away. Luckily though, we're not quite there yet, and it's still possible/feasible to embed GUIs in Gtk3 (at least on X11), so things can continue roughly as they were for a while. Gtk2 is EOLed though, which is a problem for distributions, and I have no interest in maintaining code for a dead toolkit, so that frontend is gone entirely in the latest release. This does mean that some plugin GUIs written in Gtk2 will no longer work, but that's inherent to the situation (and why general plugin GUIs shouldn't use Gtk).

This seemed like a good time to update the UI to be a bit more “modern”, particularly since a menu bar has never really made much sense here anyway. I replaced this with a header bar, which I think does suit plugins better. For example, here's the custom GUI for the LSP Compressor:

As always, there's also generic controls, with a few refinements but still using the same boring stock widgets:

All of the menu items have been moved into a single menu button, which is a pattern I'm sceptical of in general, but it works fine for a very simple application like this. The preset menu can be unwieldy, but that's a whole topic unto itself that I hope to tackle more comprehensively later.

Code-wise, it's long been a problem that the rudimentary (lack of) architecture couldn't easily support the more advanced features people wanted from it. So, I've reworked everything into a more serious application, with a more explicit architecture and communication patterns that make adding new features much easier. As far as the Gtk frontend goes, I've also switched to using more modern APIs like GtkApplication, GAction, and so on. To be fair, these parts are quite nice. Actions are a pretty good model for building accessible GUI applications, and these new APIs encourage doing the right thing. There's still some areas that need work, but jalv.gtk3 (the version which has a .desktop file and all that) is much closer to being a proper application that integrates with the desktop environment now, and smells less like a hackey program that developers just use to check if their plugin works.

That aside, Jalv is still frequently used from the command-line, and there's a major QoL improvement there as well: the positional argument now accepts files and directories, not just plugin URIs. The code will try to figure out what to do automatically, for example, if a bundle or data file only describes a single plugin, then that plugin is loaded. Presets can also be passed (by path or by URI), which will load the appropriate plugin with that preset initially applied. In short, it's more like the “do what I mean” interface many people expect.

It's been entirely too long since the last release, but now that the host libraries and Jalv are up to date with most issues resolved, I'm going to try to do some broader cross-project efforts to address a few things that are a mess across the LV2 ecosystem as a whole, with Jalv serving as a sort of reference implementation. For now, though, it's just a much better implementation of the same old features.

Jalv 1.8.0

2025-11-26T20:13:00-05:00

Jalv 1.8.0 has been released. Jalv (JAck LV2) is a simple host for LV2 plugins. It runs a plugin, and exposes the plugin ports to the system, essentially making the plugin an application. For more information, see http://drobilla.net/software/jalv.

Changes:

Add "quit" console command
Add AppStream metainfo file
Add Qt6 version
Add missing short versions of command line options
Add option to install tool man pages
Add support for advanced parameters in console frontend
Add support for control inputs with time:beatsPerMinute designation
Add support for control outputs with lv2:latency designation
Avoid over-use of yielding meson options
Build Qt UI with -fPIC
Clean up and strengthen code
Clean up command line help output
Cleanly separate audio thread from the rest of the application
Fix Jack latency recomputation when plugin latency changes
Fix clashing command line options
Fix minor memory leaks
Make help and version commands exit successfully
Only send control messages to designated lv2:control ports
Only send position to ports that explicitly support it
Reduce Jack process callback overhead
Remove Gtk2 interface
Remove limits on the size of messages sent from plugin to UI
Remove transport position dumping from Jack process callback
Replace use of deprecated Gtk interfaces
Rework Gtk3 interface into a relatively modern Gtk application
Rewrite man pages in mdoc
Simplify and unify plugin and preset command-line arguments
Switch to external zix dependency
Use Gtk switches instead of checkboxes for toggle controls
Use fewer platform-specific APIs
Use portable zix filesystem API

Lilv 0.26.2

2025-11-25T19:49:00-05:00

Lilv 0.26.2 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.

Changes:

Actually reload files if bundles are unloaded then reloaded
Add support for loading xsd:float literals, "INF", and "NaN"
Avoid warning about non-existent entries in LV2_PATH
Fix crash when duplicate plugins are discovered
Fix lilv_node_is_literal() with booleans
Refine command line tool interfaces and documentation
lv2bench: Add support for common features and options
lv2bench: Use more realistic real-time scheduling

Sratom 0.6.20

2025-11-12T19:26:00-05:00

Sratom 0.6.20 has been released. Sratom is a small library for serializing LV2 atoms. Sratom reads/writes atoms from/to RDF, allowing them to be converted between binary and text or stored in a model.

Changes:

Avoid over-use of yielding meson options
Avoid use of scanf when reading MIDI events
Fix lint checks
Fix potential memory error when writing ambiguous relative paths
Improve code quality

Suil 0.10.24

2025-11-12T19:20:00-05:00

Suil 0.10.24 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. It provides wrappers that allow Gtk and Qt hosts to load, and potentially embed, plugin GUIs that use the "native" windowing API (Coca, WIN32, or X11).

Changes:

Add header warnings test
Avoid over-use of yielding meson options

Lilv 0.26.0

2025-11-12T19:15:00-05:00

Lilv 0.26.0 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.

Changes:

Add header warnings test
Add option to control indexing overhead for subject queries
Avoid over-use of yielding meson options
Cache LANG value and add option to override it
Fix Python tests
Fix build with dynmanifest support
Fix loading plugins that haven't been loaded yet as state
Fix loading plugins with invalid lv2:appliesTo properties as state
Fix potential memory leak in lilv_world_load_plugin_classes()
Fix potential memory leak in lilv_world_set_option()
Gracefully ignore and warn about non-directories in LV2_PATH
Improve loading performance when many plugin versions are found
Improve performance when loading and deleting state
Only consider manifest data when discovering related presets/etc
Print a warning when a property unexpectedly has several values
Reduce temporary node allocations during query operations

Lilv “Object Index” Option Revised

2025-11-12T13:58:00-05:00

My previous post, “Improving LV2 Discovery Performance”, described adding an option to lilv that controls whether an additional index is maintained for loaded LV2 data. While testing those changes for release, I discovered a few things (like lv2lint) that break without the index, which convinced me that disabling it by default wasn't the right decision.

So, I'm instead enabling it by default, which avoids this “break by default” situation. The downside is that hosts will need to add code in order to enjoy the performance improvements. To make this change as simple as possible, I also made lilv_world_set_option accept a null value to disable boolean options, so most hosts can simply add this line:

lilv_world_set_option(world, LILV_OPTION_OBJECT_INDEX, NULL);

This requires the new version, but the same change can be made without bumping the required version by avoiding the niceties:

LilvNode* false_node = lilv_new_bool(world, false);

lilv_world_set_option(
  world,
  "http://drobilla.net/ns/lilv#object-index",
  false_node);

lilv_node_free(false_node);

This will log a warning about the unsupported option on older versions, but otherwise have no effect.

Improving LV2 Discovery Performance

2025-09-29T10:25:00-04:00

LV2 plugins (and other data, like presets) are discovered by parsing Turtle files installed in various bundle directories. If the host only needs to know which things are installed, then only manifest.ttl files need to be loaded. That takes only a fraction of a second (60 ms on this machine, which has 897 plugins installed), but if the host needs more information (like the plugin's label or what ports it has), then the data files need to be loaded as well, which can take several seconds. The parser (from serd) is very fast, so the overwhelming majority of this time is spent inserting data into a model.

I was recently doing some work on lilv related to discovery, and got sidetracked into investigating how much of this overhead could be eliminated. Quite a bit, as it turns out, but before explaining how, I'll give a brief summary of the relevant fundamentals so people who don't spend their days in the triple mines can understand what I'm talking about.

LV2 data is written in the Turtle syntax, which can have a lot of structure, but is ultimately just a shorthand for data that is simply a “flat” series of triples. For example, the abbreviated Turtle

<http://example.org/amp>
    a lv2:Plugin ;
    doap:name "Amplifier" .

represents the two triples

<http://example.org/amp> rdf:type  lv2:Plugin .
<http://example.org/amp> doap:name "Amplifier" .

which describe a plugin with the name “Amplifier”.

Two implications of this format are important to understand here:

All data is a set of triples which can be stored in some lexicographical order to be quickly searchable (for example, a set ordered subject-first can be used to quickly find triples that start with a given subject).
All data can be streamed via a simple “flat” interface (for example a function with three parameters), and is trivial to inspect and/or filter on the fly (much like line-based text in POSIX pipelines).

The data may not be stored as a “literal” ordered set of triples (they're actually quads in memory for one thing), but this simplified way of thinking about it is good enough for this explanation.

Which order is best depends on the query. For example (borrowing a bit of syntax from SPARQL where ?name represents a query variable), if the host asks something like “what's the name of this plugin” or

<http://example.org/amp> doap:name ?name .

then it needs to find triples that start with the given subject and predicate (<http://example.org/amp> and doap:name) to see what object (?name) they have. So, a subject-predicate-object or “SPO” index will work well. If, however, the host asks something like “which things are plugins” or

?plugin rdf:type lv2:Plugin .

then an SPO index doesn't help because there's no known subject to search for. Most queries are like this, with either a subject or object wildcard (querying relatively “fixed” predicates is rare), so lilv has always had both an SPO and OPS index to support them.

This is convenient, but twice the indexing means roughly twice the overhead. The SPO index is the natural order used in the syntax, and supports most code (which mainly looks up properties of known things), but the OPS index isn't used so much. Can it be removed entirely to speed things up? It is used for many important things, but conveniently, there's only a few fixed cases of those (like finding plugins as above). So, we can take advantage of the streaming nature of the data to record this information while it's being read, instead of inserting it into an index only to query it out later.

To do this in the implementation, I introduced the concept of a “skimmer”. A skimmer inserts triples into a model as usual, but first “skims” them and records items of interest for later use. For example, a skimmer checks whether a triple has rdf:type lv2:Plugin, and if so, records the subject in a result set that stores only plugin URIs. Some cases are a bit trickier, and actually pulling this off cleanly took quite an overhaul, but details aside, it turns out that this approach can be used to eliminate the OPS index entirely without losing any functionality.

How much of an improvement does this make? On this machine, using lv2ls -n as a crude benchmark, the time goes from 3.11 to 1.72 seconds, or about a 45% improvement. The memory consumption goes down a bit as well, from (even more crudely) a max-RSS of about 138 to 112 MiB, or about a 19% improvement (everything here is an average of three runs). The improvement will vary dramatically based on what's installed, for example in some earlier tests with a different configuration I saw drops from around 7 to 4 seconds, but in general, not bad!

Are there any downsides to this? Yes, primarily two:

As with any significant change, there is the possibility of regression. Discovery is a little more restricted than before, so although I've done my best to test things, there is a possibility of things not being discovered anymore. Usually the fix for this is adding information to the manifest that should have been there anyway.
Though the implementation itself doesn't make queries that require the OPS index, hosts themselves can since lilv provides generic query functions. To support this, there's a new boolean option, LILV_OPTION_OBJECT_INDEX, which can be used to enable or disable the OPS index. Since most hosts don't need it, I decided to disable this by default. That will be a regression for hosts that do, however, who need to explicitly opt in to the old behaviour by enabling this option. A warning is printed if a query will be slow because of the missing index, so it should at least be obvious if this happens.

These changes are now in the main branch in git, which will be released soon, probably as version 0.26.0.

Suil 0.10.22

2025-01-19T13:58:00-05:00

Suil 0.10.22 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. It provides wrappers that allow Gtk and Qt hosts to load, and potentially embed, plugin GUIs that use the "native" windowing API (Coca, WIN32, or X11).

Changes:

Add support for X11 in Qt6
Fix library current_version on MacOS
Monitor size hints and window resizes for X11 in Gtk3

Lilv 0.24.26

2025-01-19T13:53:00-05:00

Lilv 0.24.26 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.

Changes:

Add lint option with project metadata and code quality tests
Avoid use of VLAs in lv2apply
Clean up and isolate platform-specific code
Fix C++ test build on MacOS
Fix library current_version on MacOS
Fix test suite when TMPDIR has no trailing slash
Fully separate library code from programs
Improve const correctness
Replace more platform-specific code with use of zix

Sratom 0.6.18

2025-01-19T13:49:00-05:00

Sratom 0.6.18 has been released. Sratom is a small library for serializing LV2 atoms. Sratom reads/writes atoms from/to RDF, allowing them to be converted between binary and text or stored in a model.

Changes:

Add lint option with project metadata and code formatting tests
Avoid snprintf when writing MIDI events
Enable clang nullability checks
Fix library current_version on MacOS

Lilv 0.24.24

2024-01-23T19:39:00-05:00

Lilv 0.24.24 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:

Avoid overriding state features passed by the host
Fix null dereference when trying to load state from a missing file
Fix potential null dereferences and conversion warnings

Lilv 0.24.22

2023-10-22T20:14:00-04:00

Lilv 0.24.22 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:

Allow LILV_API to be defined by the user
Clean up code
Clean up inconsistent tool command line interfaces
Convert man pages to mdoc
Fix crash when plugins pass NULL to the LV2_State_Retrieve_Function
Fix dependencies in pkg-config file
Fix potential crash when writing state files fails
Order plugin classes by URI
Override pkg-config dependency within meson
Remove junk files from documentation install
Replace duplicated dox_to_sphinx script with sphinxygen dependency
Switch to external zix dependency

Suil 0.10.20

2023-10-22T20:11:00-04:00

Suil 0.10.20 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 SUIL_API to be defined by the user
Fix dependencies in pkg-config file
Only check for Gtk Quartz support on MacOS
Override pkg-config dependency within meson
Remove Gtk in Qt and Qt in Gtk wrappers
Remove junk files from documentation install
Replace duplicated dox_to_sphinx script with sphinxygen dependency

Sratom 0.6.16

2023-10-22T20:06:00-04:00

Sratom 0.6.16 has been released. Sratom is a small library for serializing LV2 atoms. Sratom reads/writes atoms from/to RDF, allowing them to be converted between binary and text or stored in a model. For more information, see http://drobilla.net/software/sratom.

Changes:

Clean up code
Constrain relative URI references to the base URI
Fix dependencies in pkg-config file
Override pkg-config dependency within meson
Remove junk files from documentation install
Replace duplicated dox_to_sphinx script with sphinxygen dependency

Down to the Last Man, Doc!

2022-11-30T13:53:00-05:00

While working through some remaining things in the build/documentation/packaging/infrastructure cleanup phase I've been going through lately, I noticed that some of the man pages hosted at this domain have become stale (there was a helpful ticket about one of them, but more or less all of them were out of date).

I'm still not entirely sure what to do about the general duplication between README files and the neglected home pages I still (barely) maintain here, but this part struck me as obviously needing to be automated.

Of course, now that my attention was drawn to them, I noticed that many of the man pages themselves were in a terrible state. In recent years I've become more enthusiastic about man pages, particularly after moving to mandoc. As a language, mdoc is dramatically better than the “traditional” man macros (the ones most often used on Linux), and includes meaningful semantic markup for more or less everything you'll need. It's still line noise to write, but you actually get something for it. Since it's semantic markup, it feels like a better investment to me: superficially ugly, perhaps, but with high fidelity as a portable source material. Converting from mandoc to just about anything, I imagine, could be done automatically easily enough, if it wasn't already supported by the tool¹.

In practice, I find that the language encourages/enables writing more consistent pages with better formatting, and mandoc, unlike groff, emits clean and simple HTML pages that can be easily styled with CSS. It's relatively pleasant to use in general, and emits sensible error messages that point directly to the problem when you screw something up. I've also come to appreciate the BSD style of man page more: the summary is actually a summary, it's less YELLEY, and there is a standard for sections and their order. I may spend most of my time in a GNU/Linux universe, but BSD got man pages right. That's not terribly surprising: BSD culture in general actually likes and cares about man pages. GNU treated them as an unfortunate legacy to prop up a failed successor (info). Of course the BSD tooling around man pages is much better. I tend towards BSD style for command line interfaces anyway, but you can document GNU-style long options in mdoc as well.

So! If I'm going to be putting energy into man pages, I might as well convert them to mdoc. I think good tooling is very important, and nice command-line tools with clear and articulate man pages are a part of that. Unfortunately, neither the LV2 tools themselves nor their documentation have frankly ever been of very high quality. Addressing this is one of the next themes of upcoming work, but for now, simply converting the existing content (with a few touch-ups along the way) is an easy step forward. It meshes nicely with the “bring all projects in line with a consistent set of ‘modern’ quality standards and automate everything” arc I've been on lately anyway.

The process of going through all of these has made me realize that I should prioritize the tool work, because the state of some of these tools is frankly embarrassing, but, uh, pay no attention to the man behind the curtain! It's a formats and infrastructure kind of day!

Having manually converted all the pages and checked them in the terminal, I needed a place to have them automatically updated, converted to HTML, and uploaded. The (not-really-existing) lv2kit project is the (not-really) parent of LV2 itself and all the “official” libraries, so I put it in CI there for the time being. I don't know what the best organization is for man pages under the LV2 umbrella in the grand scheme of things, but for now, this gets things automatically updated and online:

It's possible to build the documentation into a broader HTML page to integrate with toolbars and the like, but for now these are just complete pages straight out of mandoc. I did however write a simple stylesheet to adopt the same colours, fonts, spacing, typography-inspired minimalism, and infamous green links that I use everywhere, so things at least look reasonably coherent. I think it looks Good Enough™, anyway, but more relevantly, if you poke around in the document structure you'll see that the output is, for the most part, sensible semantic markup as well: lists are lists, sections are sections, different “sorts” of things are given classes, tables aren't abused, and so on. Everything here, from input to output, is reasonably clear and feels like it has obviously had some care put into it. The output looks like something a reasonable human might write themselves (if you run it through a formatter, anyway). I certainly can't say any of that about the equivalent groff-based monstrosity. In short, mandoc is good and you should use it.

As for these pages, the future of lv2kit as an “actual” released project is still unclear, but it is regularly updated (since the libraries rely on it for CI), so the man pages should never be stale again. I certainly wouldn't call these good yet, but not rotten is a start!

mandoc currently supports emitting ascii, html, man, markdown, pdf, ps, tree, and utf8. ↩

On the LV2 Stack, Dependencies, and Incrementalism

2022-10-15T19:07:00-04:00

For quite a while now, I've been working on new major versions of the LV2 host stack (serd, sord, sratom, suil, and lilv) while maintaining the current stable versions. Mainly this is a task of trying to push as many changes back as I can, without actually breaking any APIs. Aside from the usual bug fixes and code improvements, this includes a lot of build system, tooling, and general quality control improvements. This keeps the divergence low, so it will be easier to go back and do maintenance on the old versions where necessary.

At this point, this process is almost done: everything uses meson now, has a consistent QC regime (high-coverage testing, multi-platform CI, strict compiler warnings, machine formatting, clean clang-tidy configurations, and so on), most long-standing issues are fixed, and I'm finally starting to run out of changes that I can do without finally breaking the APIs and releasing new major versions.

It recently occurred to me, though, that there's one more incremental thing I can do here before “ripping the band-aid off”, so to speak. In typical low-level C hacker fashion, I have some things that I just copy around piecemeal from project to project as necessary. One of those is zix, a simple library of basic data structures and portability wrappers. This has existed for over a decade, but I have never released it as a “proper” library. More dependencies, more problems, but copy-paste code reuse certainly isn't without its own problems. In this case, I have three projects that use it: sord, lilv, and jalv (and some other developers have discovered this and taken bits for their own purposes as well). This has been troublesome from time to time when bugs need fixing, and depending on how pedantic you are, might technically be considered a violation of some distributions' policies (notably Debian's).

Meanwhile, the lack of a common lowest-level dependency for this kind of very boring and generic stuff (something like the role that glib plays in that ecosystem) has proven increasingly problematic. There is some sketchy code around that exists solely to work around this “missing” dependency, and still some questionable use of things to skirt around missing facilities (for example, jalv has no mutexes). With the new versions I have in the pipeline, this problem becomes more acute for several reasons, so I've decided to release zix and depend on it as a proper released and versioned library, like all the others.

This is something that can be done before the new versions though, and, like all of the above tooling/etc improvements, I think it's best to do as much as possible on the current versions before replacing them, because that process will be painful enough as it is. My thinking originally was to not add any more libraries until I can take advantage of the solid “subproject” abilities of meson and wrap everything up into a single “lv2kit” to decrease the maintenance and packaging burden, but now I'm realizing that this isn't very realistic. For one, it's weird, and weird is bad. For another, it wouldn't really reduce packaging overhead, since distributions would surely want to package the individual libraries separately anyway. The lv2kit idea is still a goal, but pragmatically, I think it's best to just continue on in the good old “shotgun blast of little libraries” way and deal with that later.

Concretely, that will look like this:

serd <--\--- sratom
         --- sord --- lilv --- jalv
zix  <--/------------/--------/

That is, zix will become a thing, and sord, lilv, and jalv will gain it as a dependency. This will let any issues with packaging or subprojects or whatever get ironed out, without changing any of the APIs that LV2 hosts use directly whatsoever.

... and that, I think, is the last non-trivial thing I can do without rocking the boat, before the fun part where I finally get to change whatever I want in these APIs I hastily banged out over a decade ago now, and never intended to live this long in the first place. The dependency tree may get a bit more complicated, but a whole bunch of other things are going to get wildly simplified in exchange, which seems like a pretty good deal to me.

[Edited on 2025-02-16 to update broken links]

Jalv 1.6.8

2022-09-10T00:43:00-04:00

Jalv 1.6.8 has been released. Jalv (JAck LV2) is a simple host for LV2 plugins. It runs a plugin, and exposes the plugin ports to the system, essentially making the plugin an application. For more information, see http://drobilla.net/software/jalv.

Changes:

Add Gtk plugin selector UI and desktop file
Add missing option in console help output
Add version option to console executable
Build Qt interface as C++14
Change no-menu short option to m to avoid clash with jack-name
Clean up and modernize code
Fix "preset" console command when "presets" hasn't been called
Fix MSVC build
Fix atom buffer alignment
Fix crash when running jalv without arguments
Fix man page headers
Fix memory leaks
Fix outdated man pages
Fix spurious transport messages
Fix thread-safety of plugin/UI communication rings
Flush stdout after printing control values in console interface
Print status information consistently to stdout
Propagate worker errors to the scheduler when possible
Remove Gtkmm interface
Remove Qt4 support
Support both rdfs:label and lv2:name for port group labels
Switch to meson build system

Sratom 0.6.14

2022-09-09T17:29:00-04:00

Sratom 0.6.14 has been released. Sratom is a small library for serializing LV2 atoms. Sratom reads/writes atoms from/to RDF, allowing them to be converted between binary and text or stored in a model. For more information, see http://drobilla.net/software/sratom.

Changes:

Add project metadata
Adopt REUSE machine-readable licensing standard

Suil 0.10.18

2022-09-09T17:29:00-04:00

Suil 0.10.18 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 project metadata
Adopt REUSE machine-readable licensing standard
Fix MacOS build when Gtk3 and Qt5 are present without X11
Fix opening wrapped UIs multiple times in Gtk

Lilv 0.24.20

2022-09-09T17:28:00-04:00

Lilv 0.24.20 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:

Adopt REUSE machine-readable licensing standard
Update project metadata

MDA.lv2 1.2.10

2022-08-13T23:50:00-04:00

MDA.lv2 1.2.10 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

Fix preset installation

BLOP.lv2 1.0.4

2022-08-13T20:56:00-04:00

BLOP.lv2 1.0.4 has been released. BLOP.lv2 is a port of the BLOP LADSPA plugins by Mike Rawes to LV2.

Changes:

Add default values for controls
Add missing port metadata
Add option accessors
Fix pulse and sync_pulse option interfaces
Fix quantiser mode scale points
Remove invalid port type
Switch to meson build system

MDA.lv2 1.2.8

2022-08-13T20:51:00-04:00

MDA.lv2 1.2.8 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

Add REUSE licensing metadata
Add lv2lint test
Switch to meson build system

Fomp.lv2 1.2.4

2022-08-13T20:43:00-04:00

Fomp.lv2 1.2.4 has been released. Fomp is an LV2 port of the MCP, VCO, FIL, and WAH plugins by Fons Adriaensen.

Changes:

Add lv2lint test
Switch to meson build system

Suil 0.10.16

2022-08-12T22:17:00-04:00

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

Changes:

Fix wrapper module installation path

Lilv 0.24.18

2022-08-12T22:15:00-04:00

Lilv 0.24.18 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:

Allow programs to be used from subproject
Fix default LV2_PATH

Lilv 0.24.16

2022-07-19T01:16:00-04:00

Lilv 0.24.16 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 fallback flock() detection on MacOS
Switch to meson build system

Suil 0.10.14

2022-07-19T01:14:00-04:00

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

Changes:

Fix MacOS build
Fix documentation install path
Remove dead Qt4 support code
Switch to meson build system

Sratom 0.6.12

2022-07-19T01:13:00-04:00

Sratom 0.6.12 has been released. Sratom is a small library for serializing LV2 atoms. Sratom reads/writes atoms from/to RDF, allowing them to be converted between binary and text or stored in a model. For more information, see http://drobilla.net/software/sratom.

Changes:

Switch to meson build system

Suil 0.10.12

2022-05-27T01:43:00-04:00

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

Changes:

Fix build issues with newer toolchains
Fix some compiler warnings
Remove Qt4 support

Lilv 0.24.14

2022-05-27T01:38:00-04:00

Lilv 0.24.14 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 build issues with newer toolchains
Fix unused parameter warnings
Update zix tree

Sratom 0.6.10

2022-05-26T23:27:00-04:00

Sratom 0.6.10 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.

Changes:

Fix documentation installation directory
Fix potential blank node ID truncation

Fomp.lv2 1.2.2

2021-01-07T22:28:00-05:00

Fomp.lv2 1.2.2 has been released. Fomp is an LV2 port of the MCP, VCO, FIL, and WAH plugins by Fons Adriaensen.

Changes:

Various minor code quality improvements

MDA.lv2 1.2.6

2021-01-07T22:24:00-05:00

MDA.lv2 1.2.6 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

Various minor code quality improvements

BLOP.LV2 1.0.2

2021-01-07T22:09:00-05:00

BLOP.LV2 1.0.2 has been released. BLOP.lv2 is a port of the BLOP LADSPA plugins by Mike Rawes to LV2.

Changes:

Add missing properties for options interface
Avoid pedantic warnings
Fix compilation with default hidden visibility
Set Hz unit on frequency ports

Jalv 1.6.6

2021-01-07T22:05:00-05:00

Jalv 1.6.6 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.

Changes:

Add a command line argument to select a specific UI
Explicitly support lv2:inPlaceBroken
Ignore ports with nonsense lv2:control designations
Remove Jack session support
Support port events for ui:showInterface UIs

Lilv 0.24.12

2021-01-07T21:46:00-05:00

Lilv 0.24.12 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:

Allow connecting ports to structures in Python
Fix potential memory error when joining filesystem paths
Fix saving state with files on Windows
Fix unlikely undefined behavior when saving state
Fix writing state manifests on Windows
Remove the need for a generated configuration header

Suil 0.10.10

2021-01-07T21:40:00-05:00

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

Changes:

Clean up minor code issues
Remove the need for a generated configuration header

Sratom 0.6.8

2021-01-07T21:36:00-05:00

Sratom 0.6.8 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.

Changes:

Fix potential null pointer dereference

Beautiful C and C++ Documentation with Sphinx

2020-11-26T17:12:00-05:00

Like many, I've long suffered under the antiquated and inflexible HTML documentation generated by Doxygen. Having recently worked on some Python documentation using Sphinx, though, I found it powerful and pleasant enough to use. It also has a way of encouraging actually writing documentation, rather than just generating a dump of glorified comments, which is a good thing. Though I'm not at all a fan of ReStructuredText syntax (which at times seems like it's trying to be cryptic on purpose), Sphinx is undeniably powerful, and I like the “assemble a bunch of plainish text files” approach in general. The support for multiple languages is also very appealing, though not without its problems, as we'll get to.

So, is it possible to use Sphinx to generate documentation for C and C++ libraries? Yes! As explained somewhat recently in a post by Sy Brand, there is a project called Breathe that integrates Doxygen (for extracting documentation) with Sphinx (for generating output). That sounded promising, so I attempted to migrate a library to using Breathe instead of Doxygen's HTML support. Unfortunately, though, I encountered quite a few roadblocks where I couldn't quite get output that I was happy with. Worse, the project itself is very complicated, and as I poked around in swaths of originally generated but manually modified code, I decided that Breathe was not for me. That would feel like just exchanging one inflexible and unhackable system for another.

What, then, to do? Though I realize that deep integration via modules like Breathe is usually the way things are done with Sphinx, I am a KISS sort of person, so I like to think of it as something more like a Static Site Generator: it reads a bunch of plainish text input files, and outputs HTML (or whatever other presentation format). How do we describe C and C++ things in Sphinx? It turns out that recent versions have built-in support for these “domains” now, which define markup for describing everything in these languages. This means that everything to do with nicely formatting and cross-referencing C and C++ is already dealt with out of the box. Excellent.

So, taking a step back and assessing the situation: we have some XML files that describe the documentation, and we have a tool that reads text files and produces nice documentation. This strikes me as a relatively straightforward task for a nice and simple “files in, files out” script, not somewhere a Goldbergian contraption that mashes Doxygen into Sphinx is required. So, after investigating any other promising options (no such luck), I resigned myself to trying to write such a thing, at the very least to see if it's feasible. I certainly have no time or interest in writing and maintaining a Documentation System, but a self-contained script to convert one thing to another seems reasonable enough.

As it turns out, I wouldn't call it trivial, but it's certainly feasible. I ended up with a ~700 line Python script that does everything I need (though this is of course not the same as everything possible). It's a bit “gluey” and makes some assumptions about the structure and so on, but it does the job and is something I feel I can maintain as necessary. I won't be publishing or supporting this as an independent project any time soon, and make no claims about it being general purpose, but feel free to steal it if any of this sounds appealing.

With this, I was able to get around some long-standing gripes I have with Doxygen, and easily make whatever I wanted to happen a reality, so I'm pretty happy with this approach. Everything is nicely decoupled, so I don't feel over-invested in any of the tools involved. If, for example, someone finally writes a good clang-based extractor that gains traction (JSON please, I did not enjoy this revisitation of the horrors of XML at all), I should be able to switch to using that easily enough. I've actually found this somewhat crude and UNIXey approach quite convenient: you can simply look at the ReST files to understand what is happening, or tweak them a bit and run Sphinx to test what you're aiming for, and so on. Text files are good.

So, after however many years, I think I've found an approach to documentation I'm actually quite happy with, that can support all of the languages that I use, and in general doesn't seem to get in my way. Hooray. For starters, I did my window system portability layer, Pugl. The generated documentation for the C API can be seen at https://lv2.gitlab.io/pugl/c/singlehtml/, and the C++ at https://lv2.gitlab.io/pugl/cpp/singlehtml/. This is more or less the standard Alabaster theme with a few tweaks, which I'm not sure feels appropriate for API documentation (and is much more bloated with a bunch of Javascript than I'd like), but it's pretty enough, at least. I'll tinker with themes later when I feel like jumping down that rabbit hole.

The slightly cumbersome links are an artifact of the one problem I encountered using Sphinx domains: you can't really document C and C++ APIs nicely in the same documentation set. If you use the cpp domain everywhere, you get name mangling in links even for C symbols, which is really unfortunate, and you can't really mix them. To take a contrived example, if you have a struct MylibThing in C, then a type alias in C++ like using Thing = MylibThing, Sphinx isn't clever enough to figure out that MylibThing is from C, and will generate warnings and not link correctly. Perhaps someday it will, which would be nice, but for now I opted to simply generate completely separate documentation sets. This means the C documentation is duplicated in the C++ documentation so that things can be hyperlinked, which isn't ideal, but I can live with it. A certain amount of redundancy is inherent in multi-language documentation anyway.

As I add Python bindings to most libraries, having a unified documentation system for all of these languages will be very nice. There is one additional thing I'll need at some point for the LV2 documentation in particular: a domain for RDF properties and classes. The LV2 documentation really suffers from an unnatural code (via Doxygen) and data (via lv2specgen) documentation split, and my hope is that Sphinx can provide a nice environment for writing documentation that refers to both worlds freely. That, unfortunately, will be much more work, but hopefully writing a custom Sphinx domain isn't too hard...

Sratom 0.6.6

2020-09-27T15:18:00-04:00

Sratom 0.6.6 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.

Changes:

Fix various minor warnings and other code quality issues

Suil 0.10.8

2020-09-27T12:22:00-04:00

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

Changes:

Fix X11 in Gtk size regressions (thanks Robin Gareus)
Fix compilation on MacOS older than 10.12
Fix drag and drop for X11 in Gtk
Fix various minor warnings and other code quality issues

Lilv 0.24.10

2020-09-27T12:17:00-04:00

Lilv 0.24.10 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 memory leaks in lv2bench
Fix various minor warnings and other code quality issues
Make lilv_world_get() use translations
Split and clean up test suite

Lilv 0.24.8

2020-04-26T15:55:00-04:00

Lilv 0.24.8 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:

Allow passing strings for URIs in Python API when unambiguous
Fix cases where incorrect translation is used
Fix deleting state bundles loaded from the model
Fix memory leak when dyn-manifest has no plugins (thanks Michael Fisher)
Implement state:freePath feature

Cleaning Up the LV2 Extension Mess

2019-11-13T23:05:00-05:00

After reading my last post, and watching a few old talks around LV2 and so on, I got to thinking about the extension mess problem I mentioned, and it occured to me that there might be some commonality here with the “staging” or “contrib” area question as well.

This is all based on some ideas that have been bouncing around in my head for ages, but that I haven't really developed and certainly not written down, so I'm going to try and sketch out a proposal for how to handle these things without breaking anything.

Concretely, there are two problems here: one is that the spec is just a mess. For example, the Data Access and Instance Access extensions are really just parts of the same thing and should live together, nobody cares about Morph and it's not in a state that really belongs in the “recommended standard” list (sorry, flagrant abuse of power on my part there), and so on.

The other problem is that there are sometimes contributions which solve a problem, and are a reasonable enough pragmatic step, but also not really up to par. Maybe they aren't portable, aren't defined well enough, could do more harm than good if they're presented as recommendations, and so on. People, for whatever reason, want them “in LV2”. Yet, nobody has the time to spend to develop them into a more proper specification yet, and nobody is happy when things don't get merged.

It seems there is a common factor to these problems, and it's moving things without breaking anything. To clean up the current mess, we can move extensions to the contrib area. When a previously half-baked contribution is developed further, we can move it from the contrib area. This is an obvious coarse-grained use case; I think there is also a case for finer-grained URI migration, but I'll focus on the easy and most useful case for now.

How might we do this? Though moving instance-access to contrib is not a goal, it's about as simple as an extension gets, so I'll pretend we want to do that for the sake of a simple example. At the very least, it will be a nice little fantasy for me to pretend that the curse of crappy plugin UIs that mess with DSP guts has finally been vanquished for good :) This is just about the mechanism, what we should actually do to clean things up is a question for another time.

So, what's instance-access? It's a handful of URIs, and a feature. The feature is extremely simple, the payload is just some pointer. Can those URIs be moved without breaking anything? For at least this simple case, I think so:

Lilv, on loading data, aggressively maps everything to the new location. If it says http://lv2plug.in/ns/ext/instance-access in a data file, then it gets loaded into memory as http://lv2plug.in/ns/contrib/instance-access. In this case, that means that, as far as the host can tell, the UI has lv2:optionalFeature http://lv2plug.in/ns/contrib/instance-access. This can be done pretty easily just above the parser level so that it's universally true.
When the UI is instantiated, the (old) host passes the http://lv2plug.in/ns/ext/instance-access feature to lilv_plugin_instantiate(). Internally, lilv duplicates this, and passes both the old and new features to the UI with the same data.
The plugin is either old, and looks for the old feature URI, or new, and looks for the new feature URI, and either way, finds it.

I can't think of a reason this wouldn't work, and it doesn't even require any host changes. It's a bit bloated, but not in a way that matters, and would need a significant (but not too bad) amount of code specifically to deal with this in lilv, but such is my lot in life.

In the more general case, there is also the issue of URID mappings. Let's pretend that http://lv2plug.in/ns/ext/instance-access is mapped to a URID both by the host and the plugin, and that URID is sent between them. Though this isn't really an intended use-case for this particular extension, it's a perfectly valid thing to do:

The host URID-map maps both the old and new URIs to the same URID.

... that's it, actually. Regardless of which “version” either host or plugin know about, the URID is identical. This requires hosts to actually implement something though, or for a URI map to be added to lilv, so it's not as easy. It can't just be done in LV2 and would take some time to get established.

There is one remaining snag: extension_data. This one is a bit trickier, because we need to assume the hosts uses lilv_instance_get_extension_data which is just a trivial wrapper, and probably not used by everyone. That's an easy enough fix to make, though. Then, lilv just needs to call the plugin method for the new URI, return that if it isn't NULL, and fallback to calling it with the old URI.

All of this requires a map between old and new to exist, of course, but this would be written down in the specs themselves and it's easy enough to load such a thing inside lilv.

I'm sure there are other places where URIs as strings are used in the API that would need thinking about, and I'll have to scan through the spec to see, but I suspect the above is at least 90% of what matters.

So... am I missing something? Do send me (or lv2-dev) an email if so, but now that I write it down this seems more viable than I assumed it would be. There will definitely be corner cases, since plugins and hosts can use these strings for anything everywhere, but as far as the actual interface is concerned it seems possible to make this happen without too much pain. What could we do with this?

Merge data-access and instance-access
Merge buf-size and resize-port
Put all the “official” extensions in the same namespace (“directory”), and get rid of the annoying inconsistency of ext and extensions and so on (which doesn't really matter, except in the soft sense that ugliness matters). The header includes already look like this and it's so much nicer.
We could put the deprecated extensions in a special namespace so they really stand out, but this doesn't seem to really matter (though it should be done visually on the spec page regardless).
Move presets into lv2core itself? This isn't an extension-level move like the above, but why not? One less prefix to bother with, and in retrospect, a plugin spec without any kind of presets at all is pretty silly. Perhaps the same for port-groups.
Do... something with port-properties, and maybe parameters. Let's say combine them into a “control” extension that generally has all the definition of control related stuff.
Move morph to contrib.
Maybe move dyn-manifest to contrib. This is a bit more contentious, but it's a pretty ugly solution, and the caveats of using it currently aren't very clear.

That would leave a specification list like this (assuming parameters and port-properties move to “control”):

Atom: A generic value container and several data types
Buf Size: Access to, and restrictions on, block and buffer sizes
Instance Access: Provides access to a plugin instance
Log: A feature for writing log messages
LV2: An open and extensible audio plugin standard
MIDI: A normalised definition of raw MIDI
Options: Instantiation time options
Control: Common properties and parameters for audio processing
Patch: Messages for accessing and manipulating properties with events
State: An interface for LV2 plugins to save and restore state
Time: Properties for describing time
UI: LV2 plugin UIs of any type
Units: Meaningful units for values
URID: Features for mapping URIs to and from integers
Worker: Support for doing non-realtime work in plugins

Not everything left is immaculate, and from a user-facing documentation point of view other things like putting the data-only vocabularies in a separate section might help even more, but I think this would be a big improvement. More importantly, it would of course give us an attic to put slightly more sketchy things. Looking at LV2 as a Specification™, that feels wrong, but looking at it as a project, it seems really necessary.

LV2: The Good, Bad, and Ugly

2019-11-11T21:35:00-05:00

It occurred to me that I haven't really been documenting what I've been up to, a lot of which is behind the scenes in non-release branches, so I thought I would write a post about the general action around LV2 lately. I've also been asked several times about what the long-term strategy for LV2 is, if there should be an “LV3”, whether LV* can start to really gain traction as a competitor to the big proprietary formats, and so on.

So, here it is, a huge brain dump on what's good, what's bad, what's ugly, and what I think should be done about it.

The Good

LV2 is different from other plugin standards in several ways. This is not always a good thing (which we'll get to shortly), but there are some things that have proven to be very good ideas, even if the execution was not always ideal:

Openness: Obvious, but worth mentioning anyway.
Extensibility: The general idea of building an extensible core, so that plugin and host authors can add functionality in a controlled way is a great one. This allows developers to prototype new functionality to eventually be standardised, make use of additional functionality if it is available, and so on. Some problems, like ensuring things are documented, that implementations agree, and so on, get more difficult when anybody can add anything, but this is worth the benefit of not having a standardisation process block getting things done.
DSP and UI split: Also obvious in my opinion, but certainly not a universal thing. There are a lot of bad things to be said about the actual state of GUI support, but keeping them separate, with the option to have a pointer to the guts of a plugin instance is the right approach. Having a well-defined way to communicate between GUI and DSP makes it easy to do the right thing. Multi-threaded realtime programming is hard, and plugins dropping out because of GUI activity and so on should not be a thing.
Standard implementation between host and plugins (for some things): This is a huge win in reducing the burden on both host and plugin authors, and allows both to rely on certain things being done right. This also makes a location where stronger validation and so on can happen, which we should exploit more. The war between host and plugin authors, trying to make things compatible with the arbitrary behaviour of countless implementations is largely why everyone hates plugins. This doesn't have to be a thing. We haven't actually done well in that area with LV2 (quite the opposite), but having a place to put that code is the right move.
Transparent communication: Though you technically can do just about anything with LV2, a “proper” plugin has a transparent control interface that works in a standard way. This gets you all kinds of things for free, like human-readable debug tracing, network transparency, and so on, and also encourages design that's better from a user point of view, like having good host controls for parameters, automation, accessibility, and so on. This is somewhat related to having a DSP and UI split. The benefits of having plugins be controlled in a standard way are endless, as are the awful things that happen when GUIs and audio code aren't forcefully kept at arm's reach.

The Bad

Now to the more interesting part. There are some nice ideas in LV2, and I think an idealised and cleaned up version of it that adheres to the main underlying design principles would be beautiful. In reality, however, LV2 is an atrocious mess in all kinds of ways:

Control ports: LV2 uses LADSPA-style control ports, which contain a single float. This is a tricky one to put in the “bad” category, since pragmatically grafting extensibility onto LADSPA is why LV2 has been moderately successful. It had to be that way: we needed working plugins, not a tedious standardisation process that goes nowhere (there's already GMPI for that). That said, control ports are incredibly limiting and that they still exist is an endless source of trouble: they are static, they require buffer splitting for sample accuracy, they can only convey a float, there is no hook to detect changes and do smoothing, and so on. A control protocol (something like MIDI except... good) is the right way to control plugins. Notes and controls and all the rest should be in the same stream, synchronous with audio. It's hard to migrate to such a reality, but there should be one consistent way to control a plugin, and it should be a stream of sample-accurate events. No methods, no threading and ABI nightmares, no ambiguity, just a nice synchronous stream of inputs, and a single run function that reads those and produces outputs.
The connect_port method: Another LADSPA-ism. This means that using some signal means the host must call a method on the plugin to connect it first. This is an awful design: it forces both the host and the plugin to maintain more state than is necessary, and it's slow. I have written several plugins that would be completely stateless (essentially pure functions) except the spec requires the plugin to maintain all these pointers and implement methods to mutate them. Inputs and outputs just should be passed to the run method, so all of that goes away and everything is nicely scoped. As far as the basics of the C API are concerned, this is, in my opinion, the most egregious mistake.
Turtle: Everyone loves to hate Turtle. It's mostly a nice syntax (if the namespace prefix limitations are very annoying), but it's weird. Worse, people might search for “RDF” and find the confusing W3C trash-fire there. The underlying ideas are good, but that three-letter-acronym should be absolutely eliminated from the spec and documentation. The good thing in LV2 is really just “property-centric design”, which can be explained in a simple way anyone can understand. It's more or less just “JSON with URIs” anyway, and nobody ever got fired for using JSON. Speaking of which, syntax-wise, JSON-LD is probably the way to go today. JSON is annoying in different ways, but this would allow LV2 data files to look completely typical to almost any developer, but still have the same meaning and have the same advantages under the hood of a real data model. This could actually be done without breaking anything in practice, but JSON-LD is much harder to implement so I'm not quite there yet. It would also be some work to write the vocabulary (vocabularies?), but it's doable.
Lack of quality control: Again a consequence of pragmatic evolution, but the lack of standard quality control has become a real problem. There has been progress made there, with things like lv2lint and lv2_validate, but it's not good enough. The biggest problem with plugins (and plugin hosts) in general is that most of them are just broken. There should be a standard test suite for both, that is as strict as possible, and its use should be strongly “encouraged” at the very least. The above-mentioned existence of standard code in-between hosts and plugins could be useful here, for example, hosts could just refuse to load non-conforming plugins outright.
Extension spam: The “standard” extensions are not all very good, or widely supported. They also aren't broken down and organized especially well in some cases. We are at least somewhat stuck with this for compatibility, but it makes things confusing. There are many reasons for this, but in general I think a better thought-out standardisation process, and a “sort of standard” staging ground to put contributions that some implementations agree on but aren't ideal or quite at “recommended standard” yet would help. I'm still not sure exactly how to do this, there's no best practice for such things out there that's easy to steal, but with the benefit of hindsight I think we could do much better.
Library spam: The standard host implementation is quite a few libraries. This is a mostly good thing, in that they have distinct purposes, different dependencies, and so on, but in practice it's annoying for packagers, or anyone who wants to vendor it. I think the best approach here is to combine them into a meta-package or “SDK”, so libraries can still be properly split but without the maintenance burden. I am working towards this with “lv2kit”. It's currently hard for outsiders to even figure out what they need, a one-stop “all the LV2 things” in a single package would help immensely, especially for people outside of the Linux world (where distributions package everything anyway, so nobody really cares).
C++ and other language bindings: Plugin interfaces more or less have to be in C. However, outside of POSIXland, nobody wants to actually write C. Virtually the entire audio industry uses C++. Good bindings are important. Python is also nice for some things. Rust would be great, and so on.

The Ugly

These are things that are just... well, ugly. Not really “bad” in concrete ways that matter much, but make life unpleasant all the same.

Extensibility only through the URI-based mechanism: In general, extensibility is good. The host can pass whatever features, and plugins can publish whatever interfaces, and everything is discoverable and degrades gracefully and so on. It works. The downside is that there's some syntactic overhead to that which can be annoying. We should have put sizes or versions in structs so they were also extensible in the classical way. For example, the connect_port problem mentioned above could be fixed by adding a new run method, but we can't literally add a new run method to LV2_Descriptor. We would have to make a separate interface, and have the host access it with extension_data, and so on, which makes things ugly. Maybe this is for the best, but ugliness matters. In general there are a few places where we could have used more typical C patterns. Weirdness matters too.
Extension organization: The list of specifications is a complete mess. It annoys me so much. I am not really sure about this: in some cases, an extension is a clearly separate thing, and having it be essentially a separate spec is great. In other cases, we've ended up with vaguely related grab-bags of things for lack of anywhere else to put them. I sometimes wonder if the KISS approach of just having one big namespace would have been the right way to go. It would mean less prefixes everywhere at the very least. Maybe we could use some other way of grouping things where it makes sense?
Static data: This is a tough one. One of the design principles of LV2 is that hosts don't need to load and run any code to just discover plugins, and information about them. This is great. However, whenever the need for something more dynamic comes along (dynamic ports, say), we don't have any great way to deal with it, because the way everything is described is inherently static. Going fully dynamic doesn't feel great either. I think the solution here is to take advantage of the fact that the data files are really just a syntax and the same data can be expressed in other ways. We already have all the fundamental bits here, Atoms are essentially “realtime-ready RDF” and can be round-tripped to Turtle without loss. My grand, if vague, vision here is that everything could just be the same conceptually, and the source of it be made irrelevant and hidden behind a single API. For example, a data file can say things like (pseudocode alert) <volume> hasType Float; <volume> minimumValue 0.0; <volume> maximumValue 1.0 but a message from a plugin can say exactly the same thing at run time. If the host library (lilv) handled all this nicely, hosts could just do lv2_get_minimum(gain) and not really care where the information came from. I think this is a much better approach than grafting on ever-more API for every little thing, but it would have to be done nicely with good support. I think the key here is to retain the advantages we have, but put some work into making really obvious and straightforward APIs for everything.
Overly dynamic URIDs: URIDs are a mechanism in LV2 where things are conceptually URIs (which makes everything extensible), but integers in practice for speed. Generally a URID is made at instantiation time by calling a host-provided mapping function. This is, for the most part, wonderful, but being always dynamic causes some problems. You need dynamic state to talk about URIs at all, which makes for a lot of boilerplate, and gets in the way of things like language bindings (you couldn't make a simple standalone template that gives you an Int atom for an int32_t, for example). I think it would be a good idea to have a static set of URIDs for things in the standard, so that lv2_minimum or whatever is just statically there, but preserve the ability to extend things with dynamic mapping. This is easy enough by adding the concept of a “minimum dynamic URID value”, where everything less than that is reserved by the standard. Alternatively, or perhaps in addition, maybe having a standard loader to ease the pain of loading every little thing (like with OpenGL) would help make code cleaner and boilerplate free.
The Documentation Sucks: Of course, the documentation of everything always sucks, so you have to take this feedback with a grain of salt, but it's true of LV2. A lot of improvements here are blocked by the specification breakdown being set in stone, but it could be improved. I think the reference documentation is not the problem though, we really need example-driven documentation written as prose. This is a completely different thing to reference documentation and I think it's important to not confuse the two. There has been a bit of work adapting the “book” to be better in this sense, but it's not very far along. Once it's there, it needs to be brought to the forefront, and the reference documentation put in a place where it's clear it's about details. Optics matter.

The Work

I'm sure there are countless things floating around in my mind I've forgotten about at the moment, but that's all that comes to mind at a high level. There are, of course, countless little specific problems that need work (like inventing a control protocol for everything, and having it be powerful but pleasant to use), but I'm only focusing on the greater things about LV2 itself, as a specification family and a project. The big question, of course, is whether LV3 should be a thing. I am not sure, it's a hard question. My thinking is: maybe, but we should work towards it first. It's always tempting to throw out everything and Do It Right, but that never works out. The extensible nature of LV2 means that we can graft better things on over time, until all the various pieces feel right. I see no point in breaking the entire world with a grandiose LV3 project until, for example, we've figured out how we want to control plugins. I am a big believer in iterative design, and working code in general. We can build that in LV2. Maybe we can even do it and end up at more or less LV3 anyway, without causing any hard breakage. To that end, I have been improving things in general, to try and address some of the above, and generally bring the software up to a level of quality I am happy with:

Portability: The LV2 host stack has (almost) always been at least theoretically portable, and relatively portable in practice, but it's obvious that it comes from the Linux world and might work elsewhere. I have been doing a lot of work on the DevOps front to ensure that everything works everywhere, always, and no platform is second-class. The libraries live on Gitlab, and have a CI setup that builds and tests on Linux (both x86 and ARM), Windows, and MacOS, and cross-compiles with MinGW.
Frequent releases: Another consequence of the many-libraries problem is that releasing is really tedious, and I'm generally pretty bad at making releases. This makes things just feel stale. I've recently almost entirely automated this process, so that everything involved in making a release can be done by just calling a script. Also on the DevOps and stale fronts, I've been moving to automatically generating documentation on CI, so it's always published and up to date. Automating everything is important to keep a project vibrant, especially when maintenance resources are scarce.
Generally complex APIs: The library APIs aren't great, and the general situation is confusing. Most authors only need Lilv, but there are these “Serd” and “Sord” things in there that show up sometimes, all work with roughly the same sort of “nodes”, but all have different types and APIs for them, and so on. I have been working on a new major version of serd that takes advantage of the API break to make things much simpler, and improve all kinds of things in general. This will be exposed directly in lilv where it makes sense, eliminating a lot of glue, and eliminating the sord library entirely. The lilv API itself is also dramatically bigger and more complicated than it needs to be. At the time, it felt like adding obvious helper methods for every little thing was a good idea, so people can just find lv2_port_get_specific_thing_I_want() which is nice when it's there... except it's not always there. The property-based design of LV2 means that lv2_get(port, specific_thing_I_want) could work for everything (and this ability is already there). This results in situations like people thinking they are blocked by a missing function, and spending a lot of time writing and submitting patches to add them, when the functionality was there all along. It would be easier on everyone if everything just always worked the same general way, and it would make the API surface much smaller which is always nice.
Validation: There has been a data validator for a while, but it wasn't great. It didn't, for example, point at the exact position in the file where the error was, you just had to figure that part out. The new version of serd fixes this, so validation errors and warnings use standard GCC format to report the exact position along with a helpful error message, which automatically integrates with almost every editor or IDE on the planet for free.
SDK: As mentioned above, I'm working on putting all the “standard” host libraries into a unified “lv2kit” which is the one package you will need to build LV2 things. There are still some details about this I haven't sorted out (e.g. should the spec be in there or not? What about non-LV2-specific libraries like serd? Optional vendoring?), but it's coming along and I think will make it far more realistic to expect people to implement LV2.
The spec mess: I am idly thinking about whether or not it would be possible to add a compatibility mechanism to allow us to move URIs without breaking anything. It's largely superficial, but cleaning up the specification list would really help the optics of the project if nothing else. 90% here is trivial (just aggressively map everything forwards), but all the corner cases still need to be thought out.

That's all the work in the trenches going on at the moment to improve the state of LV2. Though I wish I, or anyone else, had the time and energy to invest effort into addressing the more ambitious questions around the plugin API itself, at the moment I am more than tapped out. Regardless, I think it makes sense to get the current state of things in a form that is moving forward and easier to work with, and raise the quality bar as high as possible first. With a very high-quality implementation and extensive testing and validation, I'll feel a lot more confident in addressing some of the more interesting questions around plugin interfaces, and perhaps someday moving towards an LV3.

On that note, feedback is always welcome. Most of the obvious criticism are well-known, but more perspectives are always useful, and silent wheels get no grease. Better yet, issues and/or merge requests are even more welcome. The bus factor of LV2 isn't quite as bad as it seems from the web, but it would help to get more activity on the project itself from anyone other than myself. The standards for API additions and such are pretty high, but there's plenty of low-hanging fruit to be picked.

Fomp.lv2 1.2.0

2019-11-10T22:38:00-05:00

Fomp.lv2 1.2.0 has been released. Fomp is an LV2 port of the MCP, VCO, FIL, and WAH plugins by Fons Adriaensen.

Changes:

Add missing default values
Add reverb and reverb_amb
Adjust some control ranges and defaults to more sensible values
Bump plugins to stable versions
Fix a few misspelled port symbols (breaks state compatibility)
Fix phaser plugin data and list phasers in manifest
Remove invalid reference to old LADSPA pulse_vco binary

MDA.lv2 1.2.4

2019-11-10T22:28:00-05:00

MDA.lv2 1.2.4 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

Fix a few minor metadata issues
Fix initial noise with Piano (zero comb filter and voices on startup)
Fix invalid Vocoder preset description
Fix misleading indentation warnings with GCC 6
Update build system
Use rdfs:label for port groups

Jalv 1.6.4

2019-11-10T21:56:00-05:00

Jalv 1.6.4 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.

Changes:

Support rdfs:label for port groups
Use screen refresh rate with Gtk3 and Qt5

Lilv 0.24.6

2019-11-10T21:39:00-05:00

Lilv 0.24.6 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 more strict error detection when storing plugin state properties
Add option to override LV2_PATH in applications
Don't print errors when saving state if correct links already exist
Fix GCC8 warnings
Fix creating directories across drives on Windows
Fix issues with loading state with saved files from the model
Fix memory errors and Python 3.4+ compatibility in Python bindings
Fix unit tests on Windows
Make Python bindings more Pythonic

Suil 0.10.6

2019-11-10T21:35:00-05:00

Suil 0.10.6 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 no-cocoa configure flag
Update build system

Sratom 0.6.4

2019-11-10T21:20:00-05:00

Sratom 0.6.4 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.

Changes:

Make sratom_free() safe to call on NULL
Various minor code cleanups

Jalv 1.6.2

2019-06-06T20:38:00-04:00

Jalv 1.6.2 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.

Changes:

Add jalv -i option to ignore stdin for background use
Add several commands to console interface
Add support for running as an internal Jack client (thanks Timo Wischer)
Add support for underscore in port names on command line (thanks Jośe Fernando Moyano)
Fix Jack deactivation
Fix compilation with recent Gtkmm versions that require C++11
Fix potential crash when closed with worker (thanks JP Cimalando)
Fix potential hang after Ctrl-c in console interface (thanks Laxmi Devi)
Make Suil dependency optional
Remove support for deprecated event and uri-map extensions

Suil 0.10.4

2019-06-06T19:02:00-04:00

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

Add support for Qt5 in Gtk3
Add support for min/base size hints for X11 in Gtk (thanks Hermann Meyer)

Suil 0.10.2

2018-12-20T17:22:00-05:00

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

Add support for Cocoa in Qt5
Fix resizing and add idle and update rate support for Qt5 in Gtk2
Fix various issues with Qt5 in Gtk2

Sratom 0.6.2

2018-07-22T18:48:00-04:00

Sratom 0.6.2 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.

Changes:

Various minor code cleanups

Lilv 0.24.4

2018-07-22T18:42:00-04:00

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

Don't attempt to load remote or non-Turtle files
Fix saving state when broken links are encountered
Gracefully handle plugins with missing binary URIs
Install Python bindings when configured without tests (thanks Clement Skau)
Remove use of deprecated readdir_r
lv2apply: Activate plugin before running
lv2apply: Use default values when they are not nan
lv2bench: Improve support for plugins with sequence ports
lv2bench: Support running a single plugin given on the command line

Suil 0.10.0

2017-10-03T20:11:00-04:00

Suil 0.10.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 suil_init() to support early initialization and passing any necessary information that may be needed in the future (thanks Stefan Westerfeld)
Add support for Qt5 in Gtk2
Add support for X11 in Gtk3
Fix building with X11 against custom LV2 install path (thanks Robin Gareus)
Fix minor memory errors

Jalv 1.6.0

2017-01-04T17:24:00-05:00

Jalv 1.6.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.

Changes:

Add PortAudio backend (compile time option, audio only)
Add Qt5 version
Add command prompt to console version for changing controls
Add generic Qt control UI from Amadeus Folego
Add option to print plugin trace messages
Allow Jack client name to be set from command line (thanks Adam Avramov)
Exit GUI versions on interrupt
Exit on Jack shutdown (patch from Robin Gareus)
Fix memory error on preset save resulting in odd bundle names
Fix semaphore correctness issues
Fix unreliable UI state initialization (patch from Hanspeter Portner)
Improve preset support
Print colorful log if output is a terminal
Report Jack latency (patch from Robin Gareus)
Set Jack port order metadata
Support CV ports if Jack metadata is enabled (patch from Hanspeter Portner)
Support numeric and string plugin properties (event-based control)
Support thread-safe state restoration
Update UI when internal plugin state is changed during preset load
Use moc-qt4 if present for systems with multiple Qt versions

Lilv 0.24.2

2017-01-04T16:48:00-05:00

Lilv 0.24.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 comparison of restored states with paths
Fix saving state to paths that contain URI delimiters (#, ?, etc)

Suil 0.8.4

2016-09-20T02:47:00-04:00

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

Add Cocoa in Gtk wrapper (patch from Robin Gareus)
Add Gtk2 and X11 in Qt5 wrappers (patch from Rui Nuno Capela)
Bubble X11 key events up to Gtk parent (patch from Filipe Coelho)
Center X11 UIs in Gtk (patch from Robin Gareus)
Configure based on compiler target OS for cross-compilation
Fix a few minor/unlikely memory errors
Fix compilation with -Wl,--no-undefined
Fix initial size of resizable X11 UIs in Gtk (patch from Robin Gareus)
Gracefully handle failure to open wrapper
Only report suil_ui_supported() if necessary wrapper is compiled in
Upgrade to waf 1.8.14
Various Windows fixes (patches from Robin Gareus)

Sratom 0.6.0

2016-09-20T02:25:00-04:00

Sratom 0.6.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.

Changes:

Add sratom_set_env() for setting prefixes
Fix padding of constructed vectors (thanks Hanspeter Portner)
Fix warnings when building with ISO C++ compilers
Support round-trip serialisation of relative paths
Support sequences with beat time stamps
Upgrade to waf 1.8.14

Lilv 0.24.0

2016-09-20T02:24:00-04:00

Lilv 0.24.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 LILV_URI_ATOM_PORT and LILV_URI_CV_PORT defines
Add lilv_state_set_metadata() for adding state banks/comments/etc (based on patch from Hanspeter Portner)
Add lilv_world_get_symbol()
Add lv2apply utility for applying plugins to audio files
Add new hand-crafted Pythonic bindings with full test coverage
Check lv2:binary predicate for UIs
Do not instantiate plugin when data fails to parse
Fix crash when NULL predicate is passed to lilv_world_find_nodes()
Fix crash when state contains non-POD properties
Fix documentation installation
Fix loading dyn-manifest from bundles with spaces in their path
Fix outdated comment references to lilv_uri_to_path()
Fix state file versioning
Replace bundles if bundle with newer plugin version is loaded (based on patch from Robin Gareus)
Support re-loading plugins
Unload contained resources when bundle is unloaded

Git migration

2015-11-14T16:46:00-05:00

I have finally migrated all of my software to git. This was not a very fun process due to the nested nature of my “drobillad” repository, but now all projects live in their own git repositories with history and tags from SVN preserved.

It is still possible to build all my audio software in one step, the top-level repository http://git.drobilla.net/drobillad.git is now a skeleton with git submodules for each project. Anyone using SVN should switch immediately, the SVN repositories will remain in their current state for the foreseeable future but all development activity will move to git.

All the repositories are available in cgit.

[Edited on 2025-02-16 to remove broken links]

Lilv 0.22.0

2015-10-08T19:39:00-04:00

Lilv 0.22.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 lilv_file_uri_parse() for correct URI to path conversion
Add lilv_free() for systems picky about such things
Add lilv_node_get_path() for convenient file URI path access
Add lilv_state_delete() for deleting user saved presets
Add lilv_state_emit_port_values() for special port value handling
Add lilv_state_get_uri()
Configure based on compiler target OS for cross-compilation
Expose lilv_world_load_specifications() and lilv_world_load_plugin_classes()
Fix a few minor/unlikely memory errors
Fix bindings for Python 3
Fix creation of duplicate manifest entries when saving state
Fix directory walking on some systems (thanks Matt Fischer)
Fix lilv_realpath() on pre-POSIX-2008 systems
Fix lilv_world_ask() to work with wildcards
Fix loading files with spaces in their path
Load discovered owl ontologies as specifications
Minor documentation improvements
Preserve absolute paths in state if no link directory is given
Tolerate passing NULL to lilv_state_restore()
Upgrade to waf 1.8.14
Windows fixes (thanks John Emmas)

LV2 Plugin Control Units in Ardour

2014-11-03T20:09:00-05:00

LV2 has had a “units” extension since the beginning, which allows plugins to specify units like Hz or dB for their controls. To date this information has not been used very widely by hosts, so I've done some work in Ardour to use this information for better UI generation and intelligent plugin control.

Units can specify a format string which describes how to print a value in that unit. This is now used to draw the text on control sliders:

The same controls are used in automation lane headers. If the control is a note number, then right-clicking will present a menu with an option to pop up a note selector dialog where the value can be chosen on a piano keyboard:

Similarly, numeric frequency controls have a context menu which can set the value to a specific number of beats in the current tempo, if the frequency range is low:

If the frequency range is high, then numeric frequency ports can be set with the note selector dialog just like note numbers:

In the future, it would be nice to have this idea applied more extensively so automation lanes can “pretend” a port is in the desired unit, for example allowing the user to automate an LFO frequency in beats, or a cutoff frequency in notes. Until then, being able to at least easily set controls to musically sensible values makes many production tasks easier, particularly in electronic music where it's often desirable to set plugin controls based on key or tempo.

Up next is setting time ports based on tempo, for cases like setting delay lines to a certain number of beats, but many plugins are missing the unit information required to make this possible. Hopefully better and more widespread host support will provide some incentive for plugin authors to specify the units of their ports. It is very simple to do so, see the LV2 units documentation for examples.

Jalv 1.4.6

2014-08-08T22:30:00-04:00

Jalv 1.4.6 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.

Changes:

Add option to print control output changes to stdout
Add support for data-access extension (based on patch by Filipe Coelho)
Generate Qt moc nonsense at build time for broader compatibility
Set port pretty names via new Jack metadata API
Show newly saved presets in the preset menu
Support new UI show/hide interface in console version
Support saving the same preset several times
Update for latest LV2 Atom Object simplifications
Update man pages and console jalv help output for new options
Upgrade to waf 1.7.16

Lilv 0.20.0

2014-08-08T22:21:00-04:00

Lilv 0.20.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 convenient lilv_new_file_uri for creating file URIs
Add lilv_world_unload_bundle() and lilv_world_unload_resource()
Call lv2_lib_descriptor separately for different bundle paths (fix loading several dynamic plugins like Ingen at once)
Don't load files multiple times if they are listed as rdfs:seeAlso for several plugins
Fix issues with lilv_plugin_get_author_name and friends (thanks Filipe Coelho)
Fix several minor memory leaks
Fix use of lv2info -m and -p options to write plugin data (useful for porting plugins bridges with NASPRO)
Improve test coverage
Improved/working lv2_apply.py to apply plugin to a .wav (thanks Joe Button)
Tolerate calling lilv_node_as_uri or lilv_node_as_blank on NULL
Upgrade to waf 1.7.16

Suil 0.8.2

2014-08-08T22:18:00-04:00

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

Add configure options to disable all Gtk or Qt support
Fix embedding several Qt UIs in Gtk
Upgrade to waf 1.7.16

Sratom 0.4.6

2014-08-08T22:14:00-04:00

Sratom 0.4.6 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.

Changes:

Don't set eg prefix in sratom_to_turtle
Update for latest LV2 Atom Object simplification
Upgrade to waf 1.7.16

MDA.lv2 1.2.2

2014-01-05T17:52:00-05:00

MDA.lv2 1.2.2 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

Fix compilation against LV2 < 1.8.0

BLOP.LV2 1.0.0

2014-01-05T17:00:00-05:00

BLOP.LV2 1.0.0 has been released. BLOP.lv2 is a port of the BLOP LADSPA plugins by Mike Rawes to LV2.

MDA.lv2 1.2.0

2014-01-04T22:47:00-05:00

MDA.lv2 1.2.0 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

Fix const-violating casts
Fix tuning of Piano and EPiano at sample rates other than 44.1 kHz

Jalv 1.4.4

2014-01-04T21:11:00-05:00

Jalv 1.4.4 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.

Changes:

Add --no-menu option for jalv.gtk
Add -c option for setting controls from the command line
Don't expose non-MIDI event ports to Jack
Hide controls for ports with notOnGUI property in generic UI (based on patch from Robin Gareus)
Preset menu support for Qt (patch from Timo Westkämper)
Support ui:portMap feature to allow UIs to avoid hard-coded port indices (useful for compatibility and separately distributed UIs)

Sratom 0.4.4

2014-01-04T21:09:00-05:00

Sratom 0.4.4 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.

Changes:

Escape invalid characters when writing paths as URIs
Fancier printing without subject and predicate

Lilv 0.18.0

2014-01-04T21:06:00-05:00

Lilv 0.18.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 lilv_port_get_node() for using world query functions with ports
Add support for running plugins from Python by Kaspar Emanuel
Allow lilv_state_restore() to be used without passing an instance, for restoring port values via a callback only
Allow passing NULL port_class to lilv_plugin_get_port_by_designation
Call GetProcAddress with correct calling convention on Windows
Clean up after test suite so multiple runs are successful
Fix unlikely memory leak in lilv_plugin_instantiate()
Support denoting latency ports with lv2:designation lv2:latency
lilvmm.hpp: Add wrappers for UI API
lv2info: Don't display invalid control maxes and defaults (patch from Robin Gareus)

Suil 0.8.0

2014-01-04T21:06:00-05:00

Suil 0.8.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 suil_instance_get_handle (patch from Rui Nuno Capela)
Fix compilation errors on some systems
Upgrade to waf 1.7.14

Suil 0.6.16

2013-09-17T03:48:00-04:00

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

Changes:

Fix crashes and resizing for X11 in Qt (patch from Rui Nuno Capela)
Fix suil_instance_extension_data() for UIs with NULL extension_data

Jalv 1.4.2

2013-08-09T14:40:00-04:00

Jalv 1.4.2 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.

Changes:

Add command-line option to control UI update frequency
Fix crash when running "jalv" with bad command line arguments
Fix default setting for non-sequential enumeration ports (patch from Robin Gareus)
Fix parameter changes with Qt UI
Fix potential crash with UIs and debug printing
Nicer printing of atom messages with -d
Support rsz:minimumSize for atom and event ports
Upgrade to waf 1.7.11
Work around Gtk bug for labels on sliders (patch from Robin Gareus)

Suil 0.6.14

2013-08-09T04:16:00-04:00

Suil 0.6.14 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 new LV2 idle interface
Lower dependency from Gtk 2.24 introduced in 0.6.12
Print system error message if module fails to load
Support resizing for X11 in Gtk (patch from Robin Gareus)
Upgrade to waf 1.7.11

Ingen as LV2 in Ardour

2013-06-08T23:02:00-04:00

I found some time today to make Ingen's support for running as an LV2 more solid. I have posted about this before, but it now works at RT appropriate buffer sizes, and several other bugs have been fixed. Here's the obligatory contrived screenshot:

People are sometimes confused about how Ingen works as an LV2 (I need to write proper documentation One of These Days): you don't load an “Ingen” plugin so much (it wouldn't do anything), as you save an Ingen graph as an LV2 plugin. The idea is that Ingen is a tool for visually building plugins. Since LV2 does not support dynamically adding ports, it's easiest to do your building as a Jack app, so the basic work flow is something like:

Run Ingen as a Jack app: ingen -eg
Build a graph, adding ports, plugins, etc.
Save the graph to somewhere in your LV2_PATH, e.g. ~/.lv2 (which happens to be the default directory of the save dialog for this reason).
Voila, your graph should now show up in any LV2 host (its URI will simply be its local filesystem path, unless you explicitly set a stable one). You can check with lv2ls.

There is no export or compilation involved, Ingen's native format is LV2 compatible (graphs are always saved in the same format). If you saved a graph elsewhere you can simply copy it to ~/.lv2 to use it as a plugin, though for now you may have to create or fix the symlink to the engine binary manually to do this.

Note that you can edit the graph while it's running as an LV2 plugin, including adding new nodes and connections, you just can't add top-level ports because the host doesn't know about them. There is still some work to be done polishing this up to be ready for prime-time, but for the brave, it's more or less good to go.

Jalv 1.4.0

2013-02-23T03:35:00-05:00

Jalv 1.4.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.

Changes:

Add menu bar and pass parent widget in Qt version for true UI embedding
Add spinbuttons for precisely setting control values
Group controls under headings if port group information is available
Make URI map thread-safe, fixing occasional crashes for plugins with UIs
Send time information to plugin when Jack tempo changes
Support state:loadDefaultState
Update to waf 1.7.8 and autowaf r90
Use a more efficient dense layout for controls

Suil 0.6.12

2013-02-22T18:03:00-05:00

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

Changes:

Fix compilation on BSD
Fix crash when a broken UI returns a NULL descriptor
Fix key events for X11 in Gtk without using a troublesome event filter

Lilv 0.16.0

2013-02-18T21:43:00-05:00

Lilv 0.16.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 lilv_nodes_merge()
Add lilv_world_ask() for easily checking if a statement exists
Add lilv_world_get() and lilv_port_get() for easily getting one value
Add va_list variant of lilv_plugin_get_num_ports_of_class()
Correctly depend on serd at build time (fix compilation in odd cases)
Disable timestamps in HTML documentation for reproducible build
Fail gracefully when lilv_state_new_from_string() is called on NULL
Fix several plugin functions that failed to load data if called first
Ignore state ports with no value instead of printing an error
Make lilv_plugin_get_port_by_designation() return a const pointer
Make state loading functions fall back to lv2:default for port values, so a plugin description can be loaded as default state
Require a URI for lilv_state_to_string() and fail gracefully otherwise
Support atom:supports in lilv_port_supports_event()
Update to waf 1.7.8 and autowaf r90 (install docs to versioned directory)
lilvmm.hpp: Add several missing methods
lilvmm.hpp: Support varargs for Plugin::get_num_ports_of_class()

Sratom 0.4.2

2013-02-18T16:17:00-05:00

Sratom 0.4.2 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.

Changes:

Disable timestamps in HTML documentation for reproducible build
Fix memory leaks
Fix serialisation of nested tuples
Update to waf 1.7.9 and autowaf r90 (install docs to versioned directory)
Use new sord API to clean up and shrink code

Better Stock LV2 Plugin UIs

2013-02-10T22:11:00-05:00

Today I implemented better UI generation for LV2 plugin controls in Jalv, particularly grouping controls under headings which makes a big difference. Unfortunately few plugins group their controls currently, but hopefully more host support will provide the incentive to do so.

Other improvements:

Added a spinbutton to slider controls for precisely setting values numerically
Much more efficient layout to pack more controls on the screen at once
Support for named scale points (“ticks”) on non-enumeration ports

Here is the UI generated for Amsynth (after I added the necessary metadata):

Still pretty utilitarian, but much more usable, which is the important thing. Of course, this plugin is quite large, and has a pretty good custom UI, but I happened to be polishing up its metadata anyway and the controls group nicely so I used it as my test case.

Maybe some day this code will get smarter and evolve into a library that can be used by other Gtk hosts. Better group layout is the obvious “next level” advancement, a flat linear list of controls is pretty limited. Unfortunately there's no stock Gtk container which can do text-like reflow, which would be ideal. Perhaps a simpler scheme based on a maximum reasonable width for a controller would do, where the table will expand to have more columns if the window is wide enough for several.

Most of the metadata required to generate a good UI is also useful for other purposes, for example groups make building a decent menu of many controls feasible (e.g. to add automation lanes in Ardour), and some types of host UIs like a modular patcher inherently need to generate their own “UI” of sorts.

Good metadata is not at odds with custom UIs, they each have their uses, but it is important to remove the burden of custom UIs for simple plugins with just a few controls that really don't need them. It's a waste of that most precious of all resources - developer time - to have to code UIs for a few sliders and toggles. Hopefully better host generated UIs and support for more advanced controls like file selectors free up developers to spend more time making useful plugins and less time wrestling with GUI toolkits.

It is, after all, all about the sound.

Host-Generated LV2 File Choosers

2013-01-10T00:29:00-05:00

LV2 has been slowly but surely moving towards message-based control to overcome the limitations of static ports. The required low level facilities have been available for a while now, but the lack of a standard way to document message-based parameters and host UI support has been a sticking point. One particularly pressing need is file parameters. The current sample example has a stop-gap UI to enable sample loading, but parameters really should be host controllable and simple plugins should not need a custom UI to be usable. Today I did some work towards resolving that situation.

Here is ConvoLV2 running in Jalv:

Note this is the built-in UI generated by Jalv and not a custom plugin UI. Unlike traditional LADSPA style controls, the impulse parameter is not a port, but is set by sending a message to an event port. The plugin lists parameters with the new patch:writable property, so the host knows which controls to display (or which parameters it can automatically set). Parameters are described as normal RDF properties, so any existing property can be used, or plugins can define them as needed in their data files (don't let the “RDF” scare you, the description of a Property is as simple as LV2 ports). One nice advantage of this over ports is that a project can describe a parameter once and use it in many plugins, without having to describe the parameter every time. This really adds up when you have hundreds of plugins with, say, an identical gain parameter.

These conventions will be established in the next LV2 release (1.4.0), and the sampler example will serve as a test case. When host support becomes established, we can also move towards using messages for numeric parameters, which will finally allow for dynamic parameters, control ramps, and so on.

Suil 0.6.10

2012-12-23T04:08:00-05:00

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

Changes:

Downgrade to waf 1.7.5, previous version does not build modules due to package check breakage in waf 1.7.6

Suil 0.6.8

2012-12-23T02:11:00-05:00

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

Changes:

Fix crash in x11_in_gtk2 when event_filter fires before widget is realized
Update to waf 1.7.8 and autowaf r90 (install docs to versioned directory)
Use libgtk-x11-2.0.so.0 (with .0 suffix) by default which is available on systems without the dev package

Ingen as Remote Server or LV2 Plugin

2012-12-22T13:52:00-05:00

I have been working on the control protocol aspect of Ingen, towards a few goals:

Working GUI communicating with the server via a socket
Decent Python bindings for socket interface
Ingen as an LV2 plugin

The Python bindings got fleshed out to support a script for loading AMS patches into Ingen I have been working on (very preliminary, but in the repository and installed as ‘ingenams’). The socket interface is now sensibly synchronous, e.g. you send a command, and recv on the socket to get the response, which will include a status as well as whatever patch updates happened as a result of the command. I am happy with this route to language bindings, it's much more pleasant than a mess of direct bindings (e.g. via swig) and being protocol controlled has many other advantages. The Python interface is implemented purely in Python, it should be simple to do the same in any language that can use sockets.

The Ingen GUI can communicate with the engine via the same protocol, so you can build patches over the network (e.g. if Ingen is running on a headless machine as part of an audio rig). It can also run in the same process and use direct function calls for maximum performance.

The Ingen protocol uses the LV2 Patch vocabulary to describe changes. For the socket interface, this is represented entirely in Turtle. When running as an LV2 plugin, Ingen uses conceptually the same protocol, except in a binary format using LV2 atoms. This is a nice example of the benefits of having things defined in a good abstract model which can be encoded in many ways. For example, it would be relatively simple to implement control via JSON for a browser-based Ingen UI, which seems like the best way to go for separate control panels, but that's a topic for another day.

Since Ingen control can be expressed as atoms, it can run as an LV2 plugin with a full patcher UI and communicate only via LV2 ports. The UI is embeddable, and there is no memory sharing between engine and UI or hidden communication, everything is host managed. Here is a screenshot of Ingen running in Ardour 3. The MIDI in Ardour is played through an Ingen synth plugin, and the output has been recorded to the audio track. The patch can be manipulated live while running in Ardour, except for top level ports.

Writing an LV2 Book

2012-11-29T23:15:00-05:00

It has been clear for a while that some kind of higher level documentation is needed for LV2. The reference documentation is much better than it used to be, but this isn't very good at giving an overview, and is very imposing to new developers since LV2 is a bit different than, say, a library API due to the code/data split.

Overview documentation can't really go in the extension documentation, since many tasks plugin developers want to achieve involve several extensions (or no extensions at all). I have been wondering for a while what form this documentation should take: FAQ? Wiki pages? Just examples that illustrate specific things? For whatever reason I had never thought of a book format, but now I think that is the best approach. Too many LV2 ideas live in my head alone, especially the umbrella ideas, which is not good. A book seems like the best way to convey an overall understanding of LV2. This is important - LV2 is what I call a “click” technology (like LISP or RDF), it seems insane until it “clicks” and you get it. You really need that little enlightenment experience to be able to work with it well (and especially to be able to work on it). I need to convey that to more people. Of course it would also serve as a simple “How To” manual for plugin developers, which is the primary goal.

By “book” I don't necessarily mean paper based. While that might be nice a web version definitely should exist. I mean a largish document with several chapters and sections, with a clear overall arc that starts with the most basic plugin possible, and each section is about a specific type of functionality, like “receiving MIDI events” or “transport synchronization”. That way, when a developer has a broad question like “how do I implement state, and dynamically control it?” there is a nice book chapter on exactly that topic with explanatory text.

The other thing that is definitely good is examples. We still have only a few official examples in the LV2 tree, more would be nice. Making this book very example centric would be a good idea, solving several problems at once. Perhaps a Literate Programming like approach, where each chapter is really just the comments of a working plugin that demonstrates the relevant functionality. This way, even people who won't read the documentation (i.e. most) still have working examples to build from, and these examples would also serve as nice test cases for hosts.

The early sections could also serve as a more proper specification for things like discovery, module loading, and so on, which thus far we haven't documented so well, but honestly I don't see this as a very high priority. It's a nice idea to have an authoritative LV2 document, but in practice hosts should just use a library (like Lilv) for that stuff anyway, and most do.

In terms of publishing tech, I am not sure. I would like the examples to be actual C source code without duplicating everything, hence the Literate Programming idea. Literate Programming in philosophy only, not actually using a weird format like CWEB. I'd just parse out the comments and render those as text, and pretty-print the code in-between. This is simple, and with Pygments it can easily output both HTML and LaTeX for both an online and a typeset version. This way, for “just show me the code” types, the example source is just normal C code, but heavily documented with explanatory prose. As it happens I banged out a little Python script to do just that this evening. The tricky part is things like links, references, and so on, that require special syntax. I'd really rather not have to invent and implement a new comment syntax. However, perhaps something so directly tied to code can just avoid the need for any of that anyway, and the master document can just include all the generated bits. Might have to manually make a separate HTML and LaTeX master document but that's not too bad. This would all be trivial if I only use LaTeX, but since this is documentation, being able to link to a chapter online and such is important. Anyway, this is beside the point, the important thing is the general idea of writing an LV2 book.

I think this is a really good idea, and though I don't exactly have all the time in the world to start a book-level project, I might start building it in the LV2 repository so it is part of the official distribution. As the spec grows, the book can grow along with it. I envision future LV2 releases adding specific functionality (like transport sync, which will be the upcoming one), along with a new book chapter on the topic. On a personal note, this meshes well with desire to stick to non-realtime communication (e.g. email), since I can't have the constant distraction of IRC in my life any more. I've spewed enough text on to the Internet to fill volumes, might as well put that into something of lasting value.

To me it seems clear that this is the best way to better document LV2 and make it more accessible to newbies, but I'm notoriously bad at predicting what others want, so any feedback would be appreciated. If I wrote an LV2 book, would you read it, or at least use it as a reference?

Is it worth my time to do this, or should I just stick to hacking when I have time to do LAD stuff? If there's a good chance that this will increase the Bus Factor of LV2, I think it's probably worth it.

LV2 Plugin Transport Synchronisation

2012-11-17T01:20:00-05:00

I have been working on getting accurate transport information provided to LV2 plugins. Until now, there was the ability to specially designate e.g. BPM control ports, but this has limitations, the most obvious being that it is is limited to conveying simple numeric values at the start of a cycle.

In general, things are headed in an event-based direction, and this is no exception. The LV2 Time extension defines all the properties needed to describe a transport position/speed/tempo/meter and the LV2 Atom extension defines a dictionary type that can be used to send several properties at once in a single event. The host sends updates whenever the transport has changed in a way the plugin can not anticipate (anything but rolling along at the same speed/tempo/meter). Since events are time stamped, this makes it possible to give plugins a sample accurate tempo map, even when there are changes in the middle of a cycle.

There is a new example plugin in the LV2 repository, eg-metro, which is a simple metronome that follows this scheme. If the host implements the above, the metronome will click in sync with the host transport.

I have implemented this in Jalv (which uses Jack transport), Ardour 3, and Ingen (via a new internal "Time" block). Ardour will send an update at the start of the cycle if a relocate has happened, and one on the exact sample of any meter or tempo change within the cycle. Due to the limitations of Jack transport, Jalv and Ingen will only send updates at the start of a cycle. The metronome should tick correctly when loaded in Jalv or Ingen when there is a Jack transport master active (I have tested with Ardour), and when loaded directly in Ardour.

This functionality is pretty important for many musical plugins, so hopefully other host authors implement it as well. Depending on feedback (and available time) I may document the above rules as a feature and add it to the time extension, and release LV2 1.2.2. I think a well-defined way to achieve this is worthy of a point release, and it will get the news out there to implementers.

Suil 0.6.6

2012-11-14T16:17:00-05:00

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

Changes:

Disable timestamps in HTML documentation for reproducible build
Fix embedding Gtk in Qt as a child widget (support reparenting)
Gracefully handle UIs with no port_event method
Replace host provided features that match Suil implemented features, rather than passing UIs duplicate features
Support for wrapping native Windows UIs in Gtk2