drobilla.net - LAD

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

Zix 0.8.0

2025-11-12T18:40:00-05:00

Zix 0.8.0 has been released. Zix is a lightweight C library of portability wrappers and data structures.

Changes:

Add ZIX_REALTIME and ZIX_NONBLOCKING attributes
Add warning suppression macros
Annotate count and size parameters of allocator API
Avoid "deprecated" POSIX functions on Windows
Avoid over-use of yielding meson options
Clean up attribute documentation
Gracefully handle failed allocation in path and filesystem functions
Reduce empty BTree memory requirements
Strengthen zix_file_equals()
Use getenv() instead of environ to avoid issues on FreeBSD

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.

Software Pages Removed

2025-02-16T11:32:00-05:00

I haven't been sure what to do about the software pages here for quite a while. Most of them were essentially just stale versions of the README files from their projects, and for better and worse, most of the projects I maintain are libraries that don't have as much of a need for a homepage as user-facing software. It's easy to just ignore things that don't really matter in day-to-day work, but the embarrassingly bad state of things became really clear when I sat down to actually poke through this site.

Since it's much more important for me right now to streamline maintenance duties and eliminate as much overhead as possible, I've simply removed all of the software pages, and redirected those addresses to the corresponding Gitlab projects where possible. I might bring them back at some point, but for now, no pages are better than stale pages that really only serve to make things look bad. I don't have traffic metrics here, but I seriously doubt anyone will either notice or care.

I'm not sure about the utility of the software release posts or tarballs either. Ideally, the effort required to make a release could be reduced to simply pushing a git tag, and cross-domain posting hugely complicates that. Besides, the tarballs are made manually on my personal machine, so they're absolutely less trustworthy than the signed tags in git anyway, and, I assume, not reproducible. At the same time, for many reasons I'm wary of fully investing in some git forge or another, the automatic tarballs provided by all of them leave much to be desired (the silly “v” names for example), and I don't want to disrupt things for packagers. We'll see, but for now I'll leave the mechanics of actual releases as they are.

Ultimately, pages and posts are largely a waste of time for libraries and similar things that only support other projects anyway. So, a more radical simplification of the release process would be a good idea, but for now I'll just take out the trash and reduce the amount of things I need to consider in that process.

Intermission

2025-02-04T14:40:00-05:00

I don't suppose inactivity from me will be terribly surprising to anyone after the past several years. Still, since I was working on emptying my bug-fix and maintenance queue, making releases, and finally getting to some significant forward progress again, an update:

Unfortunately I got violently ill last week with some horrible flu-like thing, the worst I've ever had (and I'm a COVID casualty, so that's saying quite a lot). Somehow, it's still going strong. So, aside from maybe a few minutes a day of idle tinkering, everything I was doing is on pause for a while. Hopefully a short while, but so far so not good, so we'll see.

As an added bonus, Google just bricked my phone with a botched forced update, so I'm locked out of 2FA and many other things besides (I suppose I had to learn the hard way that I've gotten lazy and too dependent on that horrible device). So, yeah, things aren't going great, to put it lightly.

On the bright side, I do have some exciting things in the queue, but since I don't do vapourware or hype (to a fault, really), and have a huge amount of “infrastructure” work to do first anyway, you'll have to stay tuned for that. Assuming I don't die first, anyway.

... if I do, it would be pretty funny that this was my last post though, so I've got that going for me, which is nice.

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

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

Zix 0.6.2

2025-01-18T23:53:00-05:00

Zix 0.6.2 has been released. Zix is a lightweight C library of portability wrappers and data structures.

Changes:

Fix documentation build with sphinxygen fallback wrap

Zix 0.6.0

2025-01-18T21:49:00-05:00

Zix 0.6.0 has been released. Zix is a lightweight C library of portability wrappers and data structures.

Changes:

Add ZIX_NODISCARD attribute
Add option to build for older Windows versions
Add zix_expand_environment_strings()
Add zix_string_view_equals()
Avoid fdatasync() on Darwin
Fix build on POSIX systems without PATH_MAX defined
Fix library current_version on MacOS
Fix nullability annotations for zix_canonical_path() and friends
Fix ring unit test when mlock() is unavailable
Improve documentation
Support building for UWP
Support building for Windows with or without UNICODE

Main Branches Renamed

2024-10-31T23:23:00-04:00

As most git users are aware, the default branch name in git changed from master to main a while ago. Since I maintain projects created both before and after this change, some maintenance tasks have become more difficult to automate as a result (and I'm a sucker for consistency).

I put off dealing with this because I was planning to make master branches disappear at the same time APIs are broken, but that wasn't a good idea for several reasons beyond the scope of this post. So, I've changed all of my personal projects, and all projects maintained under the LV2 umbrella, to use main.

If you're tracking any of those repositories, maintain packaging infrastructure, or similar, please update your local trees and/or configuration accordingly. It's best to rename the local branch with git, since this preserves your local reftree and avoids accidental use of the old name:

git branch -m master main

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

Zix 0.4.2

2023-10-22T18:56:00-04:00

Zix 0.4.2 has been released. Zix is a lightweight C library of portability wrappers and data structures.

Changes:

Clean up documentation build
Fix documentation build in a virtualenv
Improve test suite code coverage

Zix 0.4.0

2023-08-23T23:25:00-04:00

Zix 0.4.0 has been released. Zix is a lightweight C library of portability wrappers and data structures.

In Search of the Ultimate Compile-Time Configuration System

2023-02-13T23:38:00-05:00

One of the many programming side quests I embark on from time to time is finding the best way to do compile-time configuration in C and C++ code. This is one of those characteristically C things that most projects need to do, but that has no well-established best practice. What you can find is all over the place, and often pretty half-baked just to suit the particularities of the “official” build. Let's try to come up with something better.

Ideal requirements:

Ability to enable or disable any features from the command line by defining symbols, including the ability to override or completely disable any automatic checks implemented in the code.
Good integration with, but no hard dependency on, any build system.
The code should build with reasonable defaults when simply thrown at a compiler “as-is”.
Mistakes, such as forgetting to include the configuration header or using misspelled symbols, are caught by tooling (preferably compiler warnings).
It's never necessary to modify the code to achieve a particular build.

Here's a skeleton of the best I've managed to come up with so far, for a made-up “mylib” project and a few POSIX functions. It has a bit of boilerplate, but there's good reasons for everything that I'll get to. This configuration header is written manually (not generated) and included (privately) in the source code:

#ifndef MYLIB_CONFIG_H
#define MYLIB_CONFIG_H

#if !defined(MYLIB_NO_DEFAULT_CONFIG)

// Derive default configuration from the build environment

// We need unistd.h to check _POSIX_VERSION
#  ifdef __has_include
#    if __has_include(<unistd.h>)
#      include <unistd.h>
#    endif
#  elif defined(__unix__)
#    include <unistd.h>
#  endif

// Define MYLIB_POSIX_VERSION unconditionally for convenience below
#  if defined(_POSIX_VERSION)
#    define MYLIB_POSIX_VERSION _POSIX_VERSION
#  else
#    define MYLIB_POSIX_VERSION 0
#  endif

// POSIX.1-2001: fileno()
#  if !defined(HAVE_FILENO)
#    if MYLIB_POSIX_VERSION >= 200112L || defined(_WIN32)
#      define HAVE_FILENO 1
#    endif
#  endif

// POSIX.1-2001: posix_fadvise()
#  if !defined(HAVE_POSIX_FADVISE)
#    if MYLIB__POSIX_VERSION >= 200112L && !defined(__APPLE__)
#      define HAVE_POSIX_FADVISE 1
#    endif
#  endif

#endif // !defined(MYLIB_NO_DEFAULT_CONFIG)

// Define USE variables for use in the code

#if defined(HAVE_FILENO) && HAVE_FILENO
#  define USE_FILENO 1
#else
#  define USE_FILENO 0
#endif

#if defined(HAVE_POSIX_FADVISE) && HAVE_POSIX_FADVISE
#  define USE_POSIX_FADVISE 1
#else
#  define USE_POSIX_FADVISE 0
#endif

User interface:

By default, features are enabled if they can be detected or assumed to be available from the build environment, unless MYLIB_NO_DEFAULT_CONFIG is defined, which disables everything by default to allow complete control.
If a symbol like HAVE_SOMETHING is defined to non-zero, then the “something” feature is assumed to be available. If it is zero, then the feature is disabled.

Usage in code:

To check for a feature, the configuration header must be included, and the symbol like USE_SOMETHING (not HAVE_SOMETHING) used as a boolean in an #if expression, like:
```
#include "mylib_config.h"

// [snip]

#if USE_FILENO
    int fd = fileno(file);
#endif
```
None of the other configuration symbols described here may be used directly. In particular, the configuration header should be the only place in the code that touches HAVE symbols.

The main “trick” here which allows for all of the different configuration “modes” is the use of two “kinds” of symbol: HAVE symbols and USE symbols. HAVE symbols are exclusively the interface for the user or build system, and USE symbols are the opposite: exclusively for use in the code and never by the user or build system. This way, use of the configuration header is mandatory for any code that needs configuration.

The USE symbols are defined to 0 or 1 unconditionally, and code must check them with #if, not with #ifdef. This prevents mistakes, since both forgetting to include the configuration header, and misspelling a symbol, will be caught by compiler warnings. Tools like include-what-you-use can also enforce direct inclusion more strictly.

From the command line, basic usage is typical: define symbols like HAVE_SOMETHING to enable features. For complete control over the configuration, define MYLIB_NO_DEFAULT_CONFIG, in which case all features must be explicitly enabled. This is mainly useful for build systems, so that all features can be checked for and only those that are found used in the code. It's also useful for avoiding issues with strange compilers or platforms that aren't supported by the checks.

I think this design covers all of the above requirements, and while the header itself can get a bit verbose, it's relatively straightforward and, more importantly, usage of it is simple and resilient to mistakes.

There is one thing here that isn't caught by tooling though: misspelling a HAVE variable will silently not work. This is a concession to the simple case of just defining a few relevant HAVE symbols on the command line, and to keep command lines from the build system as terse as possible. It is however possible to modify this pattern a bit to catch this potential mistake as well: require all known HAVE variables to be defined to 1 or 0, and check those with #if as well in the configuration header itself. This adds a couple of lines per check to the boilerplate, for example:

// POSIX.1-2001, Windows: fileno()
#  ifndef HAVE_FILENO
#    if defined(_WIN32) || defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L
#      define HAVE_FILENO 1
#    else
#      define HAVE_FILENO 0
#    endif
#  endif

// [snip]

#if HAVE_FILENO
#  define USE_FILENO 1
#else
#  define USE_FILENO 0
#endif

This way, compiler warnings will catch any mistakes in the build system (because, for example, HAVE_FILENO isn't defined), ensuring that everything is explicitly either enabled or disabled. I'm not sure which style to use. Potential silent errors in the build system are pretty bad, but at the same time, I don't want to sacrifice the ability of the code to be easily compiled “manually”. It's probably possible to have both, but I'm not sure how painful the boilerplate cost would be. I did have the stricter version for a while, but the extremely verbose compiler command lines were pretty annoying, so I removed it. Now, as I write this, I'm second guessing myself, but so it goes.

Questions for another day, I suppose. One of the things about programming side quests is that they usually never end.

C++ Bindings

2023-01-22T23:46:00-05:00

For some C libraries, I'd like to include “official” C++ bindings to make life easier for people using them from C++ (which in the audio world, is most). However, that's not something I know a good pattern for, in terms of project organization, installation, versioning, and so on. Figuring one out is a trickier problem than it may seem at first.

In the - in this case literally - “C and C++” world, there is a notorious lack of consistent conventions and best practices in some areas, and this seems to be one of them. So, I suppose I will have to suss out the “best” (and least weird) way myself. The “best” way should:

Provide “official” C++ bindings which are developed, maintained, and shipped with the underlying C library.
Avoid having the C++ wrapper be locked to the same version as the C library (which is a strict semver reflection of the ABI).

Rationale: It must be possible to develop the C++ bindings, including make breaking changes, while the C library version (and therefore the ABI) stays the same. Otherwise, it would be nearly impossible to change them, because that'd require changing the version... but the underlying C API version needs to break as infrequently as possible.
Isolate the bindings (and “C++ stuff”) from the underlying C library as much as possible. Ensure that builds on systems without a C++ toolchain work (this isn't uncommon on minimal or embedded systems which much of this software is appropriate for use on).
Avoid making a completely separate new project (repository, test and releasing infrastructure, and so on) if at all possible. The maintenance burden would be far too high, and the bindings would be prone to rot.
Use a simple and predictable naming scheme that works with any “main” project name.

Poking around repositories and tinkering a little bit, the best practices I can come up with (for the sort of libraries I'm thinking about anyway), is:

Develop and release bindings as a sub-project within the “main” project.

This is only a “project” in the build system sense. The bindings are maintained in the same git repository, and released in the same archive, as the C library.
Name the bindings sub-project by appending a cpp suffix, for example, mylib-cpp. This scheme is... well, not uncommon (for example, in the Debian repositories), and can easily be applied to any name, including libraries that already have multi-word names.

Following meson requirements, this means the sub-project lives at a path like subprojects/mylib-cpp in the repository.
Install a separate “package” (for example via pkg-config) for the bindings, which depends on the one for the underlying C library. The major version is appended to both, for example, mylib-cpp-1 might depend on mylib-1.
Keep the C++ bindings themselves as light as possible, and header-only. This avoids link-time issues, making C++ API compatibility a compile-time issue only.
Give the bindings package a separate version number and let it increase as necessary. This version is not aligned with that of the underlying C library in any meaningful way. Technically, a given version of the bindings depends on some version of the C library, but in practice, this is always simply the version it's shipped with.

A strange consequence of this scheme is that the version of the C++ bindings can only drift ever further away, so in the future even major versions may not correspond at all. This is a bit weird, but is the only way to make everything work and be properly versioned. Effectively, the version of the bindings is just an implementation detail, something developers deal with in configuration scripts. From the perspective of packagers or users, there is just one version of the library, the version of the underlying C library - the C++ bindings just may break sometimes, even within a major version of the project as a whole.

I can't think of any concrete reason why this could be a problem: the urge to have shiny “4.0.0” type version bumps across everything at the same time smells like... marketing, frankly, not engineering. It does make parallel installation of different major versions more difficult, though. Packagers can split up the installation and make separate packages if they really want to. “Upstream” (me) officially doesn't care about parallel installation of different major versions of the C++ bindings.

All that said, ideally they happen to stay relatively aligned anyway.
Make sure there is a simple and obvious option to disable C++ entirely, leaving a C library package with the broadest compatibility possible.

The short, vibes-based description of all that is something like: there is a stable and strictly versioned C library with every effort put into long-term source and binary compatibility, as always... and then there's a C++ bindings sub-project that tags along with it but is otherwise independent. The bindings are more volatile, but it's C++, so they're going to be volatile no matter what you do anyway. The bindings project is universally named by tacking a -cpp or _cpp on the end as appropriate in every context: include directories, package names, and so on.

So, an installation might look something like this:

include/dostuff-1/dostuff.h
include/dostuff-cpp-4/dostuff.hpp
lib/libdostuff-1.so
lib/libdostuff-1.so.1
lib/libdostuff-1.so.1.2.4
lib/pkgconfig/dostuff-1.pc
lib/pkgconfig/dostuff-cpp-4.pc

In the source code, the bindings and any supporting C++ code is entirely contained within the subproject, except for a minimal skeleton to handle compile time options and so on. This can be more work than a single heterogeneous project in some ways, less work in others, but overall I think it has more maintenance benefits. Importantly, it keeps any new issues or volatility as far away from the C library as possible, making it easy to see if a change could possibly break the ABI or the C library at all, for example.

This scheme may be extended to other languages if that's appropriate. The naming scheme for Python is like python-dostuff. It probably makes more sense to maintain Cython wrappers as separate projects maintained in the Python way (sigh...), but the whole point of a naming scheme is to have space for things in case you need them. In reality, language bindings are usually done independently by other people in separate projects (Rust folks will use Cargo in a separate repository, and so on).

All of this is, obviously, a massively over-thought bikeshed, but adding multiple programming languages and multiple versioning and compatibility schemes/philosophies to a project is a bit tricky. I can't just copy from an existing best-practice pattern I've been honing for years like I can with straight C libraries. This approach seems like it shouldn't cause too much trouble, though.

That said, I'm just making this up as I go along and have no experience maintaining anything quite like this (only more or less homogeneous C or C++ libraries), so feedback is, as always, welcome. I may revise this post if anything turns out to be a mistake, so it can ultimately serve as a reference for the next person trying to figure out how to do “C family” source code releases right.

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]

I Was Told The Crowd Would Have Funding

2022-10-15T17:52:00-04:00

I am, like many an obsessive nerd before me, terrible at self-promotion and living a healthy and sustainable life in general. However, as I sit here sick, burnt-out, and slowly going broke while I desperately dump what little energy I have into boring software that mostly benefits other people, it occurs to me that it might be smart to set up the usual channels for people to support this work, and mention them here (despite how embarrassing it is to do so).

It's pretty well-known these days how brutal and thankless it can be to maintain Open Source infrastructure. While I enjoy what I do around here in a way, truth be told, I'm not sure I can do it much longer. In an ideal sense, my grand plan (as described in some earlier posts) is to get the foundation solid and increase the LV2 “bus factor” so I can return to building user-facing things and tackle some new problems which tends to be more rewarding. Realistically, though, I may just be cleaning things up and minimizing the maintenance overhead so that I can hand them off or simply abandon them without feeling too bad about it. Time will tell, but if any of this helped at all with surviving the ever-skyrocketing cost of living... well, it certainly wouldn't hurt my motivation.

So! In addition to the old direct donation and subscription links on my support page, I've set up Github Sponsor and Patreon accounts. If you're reading this, presumably you know about the various projects I author, maintain, or contribute to. If you use or benefit from any of that and can spare a few bucks, I'd appreciate any support. Every little bit really does help.

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

Patchage 1.0.10

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

Patchage 1.0.10 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

Add German translation
Add Korean translation from Junghee Lee
Add i18n support
Replace boost with standard C++17 facilities
Upgrade to fmt 9.0.0

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

Meson Features and Packaging

2022-08-16T15:42:00-04:00

Recently, I have been porting all of the software I maintain to meson. For the most part, this has been a nice improvement. Meson strives to be a generally sensible and coherent build system that addresses the needs of both upstream developers and packagers, and it shows. It isn't perfect (like all software), but it's a pretty big improvement over what came before in many ways.

One disagreement has come up, however, and I think it - at best - betrays a misunderstanding of meson feature options, and - at worst - threatens to effectively destroy their utility entirely for no good reason. This disagreement originates from arch-meson, which adds --auto-features=enabled by default. This isn't technically wrong, but it's problematic at scale. To explain why, I first need to explain how meson feature options work.

Meson feature options are a better solution to the --enable-this and --disable-that style options of autoconf and similar. They make all the possible states of a feature clear and explicit. Those states are:

disabled, which unconditionally disables the feature.
auto, which enables the feature if possible (typically if dependencies are found).
enabled, which unconditionally enables the feature.

The default value for an option can be any of the three, and is given by the developer in the option definition. This is a better system because there are three states with clear meanings. They allow the builder to:

Ensure that a feature is definitely not included.
Ask that a feature be included if possible.
Ensure that a feature is definitely included (failing to configure otherwise).

Each of these states (and desires) are distinct and, importantly, their definitions are not conditional. There is no “unless” in the definition of disabled or enabled, and adding one would destroy their utility. It's not “enabled unless someone feels like it's fine to disable”, it's just “enabled”.

Concretely, for enabled in particular, this means that, as a builder of whatever meson project, you can:

meson setup build -Dsomething=enabled

Then, you know that if configuration succeeded, the something feature is enabled. This is important. It is also the only way to reliably/mechanically ensure that a build contains a feature. “Destroying” it (as something meson users can generally expect) would therefore mean that there there is no way to ensure that a build contains a feature in general. Surely everyone - especially packagers - can agree that's bad.

Hopefully that's a decent enough explanation of why meson feature options are a good, coherent, and reliable system.

What's the problem then? Well, there is that convenience option, --auto-features=enabled, which enables all features for convenience. This allows the builder to override the developer-chosen defaults, and force the build script to be explicit about all non-enabled features. This is, again, not technically wrong, and is indeed convenient at times.

The problem is more of a social one. Because Arch chose to make this the default (unlike most other distributions, as far as I can tell), people have apparently adopted the mentality that --auto-features=enabled not building is an upstream bug. It isn't. The shorthand --auto-features is just that - a shorthand for enabling all features. It is equivalent to explicitly enabling every feature independently, so doing so is quite literally asking for the build to fail if any feature is not present.

Where this gets weird is when features seem unlikely, or even impossible, to build on a given system. The bug filed against my project was about Cocoa on Linux. I get it, Cocoa is mostly a MacOS thing, and is almost certainly unavailable elsewhere, but my argument is that this doesn't matter at all. Even if it were literally impossible for Cocoa to exist on top of, say, FreeBSD somewhere (which it isn't, and cross-compiling is a thing anyway), it still wouldn't matter. A similar case can be made for optional dependencies that are not publicly available at all (something I have done in the past). Feature options working as expected in general is much more important than any of this subjective case-specific thinking.

“This doesn't work for me, so the package should not build when this feature is enabled” is not a good argument, regardless of why it doesn't work. It doesn't matter if you imagine a feature “can't” be built on some system (anyone who has been in this game long enough should be able to see where that slippery slope leads...). The power of feature options depend on the states meaning just what they say, and making enabled sometimes effectively equivalent to auto destroys that power. There's not really any point in using features at that point, you might as well just use a boolean flag.

Put another way, the proposed “fix” here would make it so that:

meson setup build -Dsomething=enabled

Can successfully configure, but without the something feature being included. Et voila, we've made the feature states effectively meaningless. That would be a bug, and letting this mentality take over would resign us back to manually wading through logs to see if what we asked for actually happened.

It's also worth noting that feature options are deeply integrated all over the place in meson, for example, you can pass them to as “required” parameters and the right thing will happen. Diluting the meaning of enabled would cause deeper problems than the builder-visible ones explained here. What does it even mean for a feature to be enabled, except not actually enabled, when that feature status is being used to dictate that another dependency is required? Everything falls apart. The feature option system, when used as intended, is designed well, but messing around with the meaning of enabled like this ruins it. I don't think it's hyperbole to say it “destroys” the whole thing: it turns a sensible and coherent system into some confused boolean, which is both objectively less powerful, and, well... confusing.

This may seem trivial when you're zoomed in to a single project or handful of options, but globally it is a much bigger deal than it might seem at first. Even in my relatively tidy third-party source directory, there's nearly a thousand meson options. I can't imagine how many there are globally. The basic way that features work can't depend on the builder understanding details about every single option, that would be a complete disaster. It is crucial that disabled and enabled mean exactly what they say, always.

I have never seen this problem come up from a user configuring the project themselves. Presumably, people realize that explicitly requesting a potentially failed build, then complaining that it did what they ask, is... rather silly. This gets obscured when a tool (arch-meson) does it automatically, but remains just as silly. It makes no difference from the perspective of a meson package or its maintainer: by enabling all features, the builder has explicitly requested ignoring the defaults and failing to build if any feature was not present.

Yet, here we are, with upstream developers getting “bug” reports for feature options working exactly how they are supposed to work. This, unfortunately, means that Arch is putting toxic pressure on the meson ecosystem, pushing upstream developers to make things objectively worse.

I don't know what the solution to that is, and I'm not an Arch developer (though I'm typing this on an Arch-derived distribution and have nothing in particular against it). Breaking all the existing packages that use arch-meson is probably not going to happen, but perhaps improving the documentation would be good enough.

All I know is that --auto-features=enabled not building is very definitely not a bug. Quite the opposite, that is literally the whole point of feature options. If there's something out there that's leading people to thinking that enabled features not building is a bug, then it is misleading people in a bad way, and needs to be fixed.

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

Raul 2.0.0

2022-08-13T22:40:00-04:00

Raul 2.0.0 has been released. Raul (Realtime Audio Utility Library) is a header-only C++ utility library for real-time audio applications.

Changes:

Add INSTALL.md file
Add managed_ptr for automatic real-time safe garbage collection
Fix semaphore with initial count on Darwin
Implement Semaphore for Windows
Improve RingBuffer
Improve test suite
Make namespace name lowercase
Remove OSC and RDF library dependent code
Remove TimeSlice and TimeStamp
Remove URI class
Remove boost dependency
Remove features now provided by C++11
Remove glib dependency
Remove remaining library code, now header only
Remove several questionable classes
Switch to meson build system
Update license to GPL3+

Patchage 1.0.8

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

Patchage 1.0.8 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

Switch to C++17 and modernize code
Switch to meson build system

Ganv 1.8.2

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

Ganv 1.8.2 has been released. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). For more information, see http://drobilla.net/software/ganv.

Changes:

Switch to meson build system

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

Patchage 1.0.6

2022-05-27T03:08:00-04:00

Patchage 1.0.6 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

Fix ALSA sequencer port subscriptions
Fix crash on client disconnection
Fix initial display with no configuration file
Fix various minor bugs
Rework code architecture to be more decoupled and data-driven
Save "human names" setting in configuration
Show latency in toolbar with 2 decimal places
Switch to C++14

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

Ganv 1.8.0

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

Ganv 1.8.0 has been released. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). For more information, see http://drobilla.net/software/ganv.

Changes:

Expand canvas automatically to fit nodes
Fix various compiler warnings

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

Patchage 1.0.4

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

Patchage 1.0.4 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

Add NSMicrophoneUsageDescription for MacOS 10.15 Catalina
Add command line option to print version
Fix making and breaking connections with Jack DBus
Fix sample rate with Jack DBus
Fix unstable module positions
Improve man page
Remove Jack session support
Remove flaky DSP load meter

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

Patchage 1.0.2

2020-04-09T12:29:00-04:00

Patchage 1.0.2 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

Add support for exporting canvas as PDF
Bring back Jack buffer size selector
Configure based on compiler target OS for cross-compilation
Don't install 512x512 icons
Fix compilation with Jack DBus
Order ports deterministically
Restore messages pane visibility and height
Save window size and position when closed via window manager
Style messages pane to match canvas
Support Jack CV and OSC via metadata
Upgrade to waf 2.0.19

Ganv 1.6.0

2020-04-09T11:45:00-04:00

Ganv 1.6.0 has been released. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). For more information, see http://drobilla.net/software/ganv.

Changes:

Add API to specify module port order.
Add support for PDF and PS export.
Add support for beveled box corners.
Add support for edges that do not constrain the layout.
Dampen sprung layout energy over time to prevent oscillation.
Distinguish edge color from port color slighly.
Fix compilation with --no-fdgl (patch from Vlad Glagolev).
Fix crash when destroying canvas.
Fix port position on modules with embedded widgets.
Fix positioning of embedded widgets when changing layout.
Fix size of vertical flow modules.
Fix unexpected node jumping when dragging new connections.
Fix various minor visual alignment/sizing issues.
Highlight connected edges on port hover.
Improve appearance of graphs with circle nodes.
Improve text rendering at high zoom.
Improve update performance.
Preserve selection for quickly making several connections.
Upgrade to waf 2.0.19

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.

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

Ganv 1.4.2

2014-08-08T22:24:00-04:00

Ganv 1.4.2 has been released. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). For more information, see http://drobilla.net/software/ganv.

Changes:

Fix bug where edges would not update when nodes are moved after the canvas is cleared (fix stuck connections in Patchage after refresh).
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

Patchage 1.0.0

2014-04-28T03:46:00-04:00

Patchage 1.0.0 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

Allow removing connections by selecting their handle and pressing delete
Fix font configuration on OSX
Integrate with Mac menu bar on OSX
Make port colours configurable
Remove LASH support and simplify UI
Remove Raul dependency
Support for DOT export for rendering with GraphViz
Support port pretty names via new Jack metadata API
Switch from FlowCanvas to Ganv (much improved looks and performance)
Use Mac style key bindings on OSX
Use XDG_CONFIG_HOME instead of ~/.patchagerc

Ganv 1.4.0

2014-04-28T03:44:00-04:00

Ganv 1.4.0 has been released. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). For more information, see http://drobilla.net/software/ganv.

Changes:

Add Connection::set_curved()
Add ability to select connections by their handles, either individually or in groups with rect select.
Add ability to select connections directly
Add font size API
Adjust padding and placement to precisely fit text
Begin using library and pkg-config names suitable for parallel installation. This version of flowcanvas is flowcanvas-1 and is NOT compatible with previous versions
Clean up API and improve documentation.
Clean up API/ABI by hiding private implementations.
Dramatically increase performance by rendering text manually rather than using the truly awful Gnome::Canvas::Text.
Fix lingering handle when deleting connections
Further slight improvements in memory consumption and alignment.
Improve scalability to graphs with many connections (eliminate linear connection searches and redundant connection collections).
Remove use of boost smart pointers. Adding and removing from containers (e.g. Canvas, Module) is now done automatically.
Size empty ports in font based units so they look right when zoomed
Switch to GPLv3+
Use system theme font size by default

Pretty names in Patchage via Jack Metadata

2014-04-09T21:26:00-04:00

The much-awaited (by me, at least) Jack metadata API has arrived. This will allow us to easily achieve many new things with minimal/nonexistent API friction. One of the simplest and most obvious is pretty names for Jack clients and ports, so I've chosen this as the first thing to tackle (as part of a drive to get Patchage polished up for a much overdue release).

Unfortunately, as far as I can tell, there is a chicken & egg scenario here since nothing is setting this metadata yet. So, I've made Jalv and Ingen both set pretty names for their ports. In the case of Jalv, the “pretty name” is the label given in the plugin data (distinct from the LV2 “symbol” which is restricted and unique).

Firing up Jalv with the Tal Dub III plugin (LV2 port courtesy KXStudio), we can see the port symbols, which are a bit awkward for end users with their prefixes and underscores. Conflating strong identifiers with human-readable labels is a serious design error I learned of the hard way, but that's a discussion for another time...

Enable “Human Names” in the view menu, or press C-h, and voilà, we see the pretty names set in Jack metadata (if present) instead.

The metadata API is very simple to use for ports, though there seems to be a hole in the API which makes it difficult to get the UUID for your client to set metadata (I want a simple jack_client_uuid, like jack_port_uuid, but it seems you have to get a string UUID and parse it to a jack_uuid_t, clunky enough that I just didn't bother). In any case, I am happy to see a low-friction mechanism in Jack which apps can use to share metadata towards making a better user experience.

It will be interesting to see what sort of information proves useful and becomes established/standard. For those of us of a mad scientist bent who live in a nest of patch cables, a CV tag seems like another obvious simple step, but for everyone, a big step is finally having meaningful port grouping and channel roles. I have always liked to joke that Jack (like LADSPA) doesn't really even do stereo, but with metadata, we can mark up stereo, 5.1, Ambisonics, etc., and other clients will be able to make sense of the channel assignments without resorting to dirty kludges based on guessing from names. All without changing the ABI one bit. Good stuff.

Labeled MIDI controller values in Ardour

2014-01-06T17:09:00-05:00

A while ago, I implemented MIDI patch, controller, and note name support for Ardour.

There was one thing missing from that work: labelled controller values. This is particularly useful for controllers that don't represent a continuous numeric parameter, but instead have a set of specific values. For example, the Moog Minitaur supports CC #86 to control the LFO sync clock division, but it's not obvious how a 0-127 number maps to a clock division. From the manual, we can learn that 61-67 is “1/4”, 68-73 is “1/8 Dot”, and so on.

Translate that information into standard MIDINameDocument format, and a few hours of hacking later... voila, Ardour displays something sensible when hovering over an automation point instead of a meaningless number.

If you want to add support for your MIDI device or program, my .midnam documents for the Moog Minitaur, MF-104M, and MF-108M, included in the Ardour distribution all contain examples of labelled values. It should be relatively obvious how to copy and modify these for other devices.

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

Interactive Force-Directed Graph Layout in Ingen

2013-12-20T00:51:00-05:00

GraphViz has, unfortunately, broken reverse compatibility of their library API, which has been nagging as a maintenance headache for FlowCanvas and its successor Ganv for a while now. It would be nice to just get rid of that dependency altogether...

Meanwhile, I had to write some force-directed graph layout (FDGL) code for another project...

... You can probably see where this is going. In the spirit of it theoretically being a holiday (there are no holidays in practice in grad school), I spent some time implementing live FDGL in Ganv, and recorded a video of interactive layout in Ingen to show progress.

One nice thing about using live FDGL in a program like Ingen is that the user can customize the layout in an intuitive tactile way, since objects behave physical laws. This video demonstrates some manual rearranging of a patch, and a total reconfiguration by switching the signal flow direction. Manual tweaking of the layout like this was not possible with the previous GraphViz-based layout code.

It took quite a bit of tweaking to get the physics working well, so layouts looked good but the patch didn't explode if there are disconnected components. It's still not quite ideal, but usable.

This is implemented at the Ganv level and thus works in Ingen (as shown), Patchage, and Machina. I'm still not confident enough in this implementation to enable it by default and/or drop Graphviz quite yet, but the adventurous who follow svn, ./waf configure --debug --fdgl. If you're hit by the graphviz breakage (and I still haven't fixed the check...), add --no-graphviz to work around the problem.

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