drobilla.net - Software

Jalv 1.8.2

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

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

Changes:

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

Lilv 0.28.0

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

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

Changes:

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

Serd 0.32.10

2026-06-08T21:08:00-04:00

Serd 0.32.10 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Address new warnings in clang-tidy 22
Fix writing quotes at the end of long literals

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

Sord 0.16.22

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

Sord 0.16.22 has been released. Sord is a lightweight C library for storing RDF statements in memory.

Changes:

Add clang nullability annotations
Address new warnings in clang and clang-tidy 21
Make more API functions tolerate NULL

Serd 0.32.8

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

Serd 0.32.8 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Avoid use of snprintf() when writing
Fix unbounded reader stack growth when reading NQuads
Improve reader error handling
Relax nullability of SerdNode buffer field
Release reader stack memory on read error
Strengthen handling of corrupt UTF-8 input
Support writing all escapes in Turtle and TriG prefixed names

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

Sord 0.16.20

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

Sord 0.16.20 has been released. Sord is a lightweight C library for storing RDF statements in memory.

Changes:

Add header warnings test
Add missing const qualifiers to API
Avoid over-use of yielding meson options
Update man pages

Serd 0.32.6

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

Serd 0.32.6 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Avoid over-use of yielding meson options
Drop graphs when writing Turtle output
Eliminate recursion in the writer
Fix handling of bad predicates in anonymous blank nodes
Fix handling of some invalid EOF cases in lax mode
Fix indentation of named objects after anonymous objects
Fix indentation when ending anonymous nodes with many objects
Fix invalid characters in error messages
Fix reading numbers with no space before the final dot
Fix reading prefix names that start with "true." or "false."
Refuse to write incoherent statements
Remove project and version number from man page OS field
Write a blank line between statements and Turtle/TriG directives

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

Sphinxygen 1.0.12

2025-11-12T15:59:00-05:00

Sphinxygen 1.0.12 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

Changes:

Fix documentation for C++ namespaces
Fix documentation for C++ template functions
Improve formatting of macro initializers

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

Sord 0.16.18

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

Sord 0.16.18 has been released. Sord is a lightweight C library for storing RDF statements in memory.

Changes:

Add option to install tool man pages
Enable clang nullability checks
Fix build as C with MSVC
Fix library current_version on MacOS
Replace more platform-specific code with use of zix

Serd 0.32.4

2025-01-19T00:17:00-05:00

Serd 0.32.4 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Clean up enum declarations
Fix library current_version on MacOS
Fix overly permissive parsing of syntax names on the command line
Fix parsing NQuads lines with no space before the final dot
Fix reading chunks from files without trailing newlines
Fix rewriting special literals when datatype URIs are prefixed names
Gracefully handle errors while writing the end of anonymous nodes
Improve test suite coverage
Simplify some character classification and comparison code
Support reading lone lists in lax mode
Treat out of range unicode characters as errors
Write blank lines between graphs and statements in TriG

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

Sphinxygen 1.0.10

2025-01-18T22:27:00-05:00

Sphinxygen 1.0.10 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

Changes:

Add missing meson_options.txt to distribution archive

Sphinxygen 1.0.8

2025-01-18T22:13:00-05:00

Sphinxygen 1.0.8 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

Changes:

Add option for installing executable script

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

Sphinxygen 1.0.6

2025-01-12T23:43:00-05:00

Sphinxygen 1.0.6 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

Changes:

Include macro replacement text in documentation
Place defines and types before functions

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

Serd 0.32.2

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

Serd 0.32.2 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Enable clang nullability checks
Fix writing empty list objects within blank nodes

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

Sord 0.16.16

2023-10-22T19:59:00-04:00

Sord 0.16.16 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

Allow SORD_API to be defined by the user
Fix command line help interface of sord_validate
Fix dependencies in pkg-config file
Override pkg-config dependency within meson
Port sord_validate to pcre2
Switch to external zix dependency

Serd 0.32.0

2023-10-22T19:36:00-04:00

Serd 0.32.0 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Add Windows path separator support to serd_node_new_file_uri()
Add long "help" and "version" options to serdi
Add options to disable html or singlehtml documentation
Add serd_reader_skip_until_byte() to public API
Allow SERD_API to be defined by the user
Avoid creating test files in the current directory
Avoid using ASCII grave as a quote
Check for POSIX features with the build system
Clean up and improve test suite
Clean up code
Fix crash when trying to read chunks without starting
Fix hang when skipping an error at EOF when lax parsing
Fix incorrect parsing of strange quote escape patterns
Fix possible hang when writing nested Turtle lists
Fix potential memory leaks when a write is aborted
Fix relative URI creation
Gracefully handle bad characters in Turtle blank node syntax
Gracefully handle bad characters in Turtle datatype syntax
Improve TriG pretty-printing and remove trailing newlines
Improve pretty-printing of lists and inline subjects
Improve serdi man page
Improve writer error handling
Make URI writing stricter by default
Make serd_reader_read_chunk() work with NQuads
Override pkg-config dependency within meson
Remove junk files from documentation install
Remove support for writing Turtle named inline nodes extension
Replace duplicated dox_to_sphinx script with sphinxygen dependency
Test header for warnings more strictly
Update standard test suites

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.

Sphinxygen 1.0.4

2023-08-23T20:49:00-04:00

Sphinxygen 1.0.4 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

Changes:

Handle anonymous structs without the "@" placeholder

Sphinxygen 1.0.2

2023-02-27T16:09:00-05:00

Sphinxygen 1.0.2 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

Changes:

Add command line flags to print version
Fix links to documentation groups

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.

Sphinxygen 1.0.0

2022-12-08T15:36:00-05:00

Sphinxygen 1.0.0 has been released. Sphinxygen is a Python module/script that generates Sphinx markup to describe a C API, from an XML description extracted by Doxygen.

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

Sord 0.16.14

2022-09-09T03:07:00-04:00

Sord 0.16.14 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

Adopt REUSE machine-readable licensing standard
Allow programs to be used from subproject
Fix accidentally exposed internal zix symbols

Serd 0.30.16

2022-09-09T03:06:00-04:00

Serd 0.30.16 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Add SERD_STATIC to pkg-config Cflags for static-only builds
Adopt REUSE machine-readable licensing standard
Allow programs to be used from subproject
Fix spelling mistake in serdi man page

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

Sord 0.16.12

2022-07-17T21:22:00-04:00

Sord 0.16.12 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

Fix various warnings
Switch to meson build system

Serd 0.30.14

2022-07-10T16:58:00-04:00

Serd 0.30.14 has been released. Serd is a lightweight C library for working with RDF data.

Changes:

Fix memory consumption when reading documents
Switch to Meson build system
Update README and project metadata

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

Sord 0.16.10

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

Sord 0.16.10 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

Fix Windows build
Fix potential crash or incorrectness issue with GCC 10 again

Serd 0.30.12

2022-05-26T22:47:00-04:00

Serd 0.30.12 has been released. Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle, TriG, NTriples, and NQuads. Serd is suitable for performance-critical or resource-limited applications, such as serialising very large data sets or embedded systems.

Changes:

Fix warnings and build issues with clang 13 and VS 2019
Fix writing long literals with triple quotes
Improve documentation style
Support combining several BSD-style command line flags in serdi
Write statements with invalid URI characters in lax mode

Serd 0.30.10

2021-01-20T15:55:00-05:00

Serd 0.30.10 has been released. Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle, TriG, NTriples, and NQuads. Serd is suitable for performance-critical or resource-limited applications, such as serialising very large data sets or embedded systems.

Changes:

Add fallback configuration if documentation theme is unavailable
Fix SERD_DISABLE_DEPRECATED
Fix building for older MacOS versions on newer MacOS
Fix documentation installation directory

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

Sord 0.16.8

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

Sord 0.16.8 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

Clean up code
Fix potential undefined behavior
Fix potentially incorrect search results
Remove the need for a generated configuration header

Serd 0.30.8

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

Serd 0.30.8 has been released. Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle, TriG, NTriples, and NQuads. Serd is suitable for performance-critical or resource-limited applications, such as serialising very large data sets or embedded systems.

Changes:

Deprecate serd_uri_to_path()
Don't install API man pages
Fix potential memory error when serialising URIs
Move headers to an include directory
Refuse to write relative URI references to NTriples
Remove the need for a generated configuration header
Remove use of C character class functions that may use locale
Split up and reorganize unit tests
Use aligned allocation via C11 or Windows API where possible

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

Sord 0.16.6

2020-09-27T11:08:00-04:00

Sord 0.16.6 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

Fix potential crash or incorrectness issues with GCC 10
Fix various minor warnings and other code quality issues

Serd 0.30.6

2020-09-27T10:51:00-04:00

Serd 0.30.6 has been released. Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle, TriG, NTriples, and NQuads. Serd is suitable for performance-critical or resource-limited applications, such as serialising very large data sets or embedded systems.

Changes:

Fix various minor warnings and other code quality issues
Improve reader error handling
Make all free functions tolerant of NULL
Parse prefixed names more strictly

Serd 0.30.4

2020-04-26T16:04:00-04:00

Serd 0.30.4 has been released. Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle, TriG, NTriples, and NQuads. Serd is suitable for performance-critical or resource-limited applications, such as serialising very large data sets or embedded systems.

Changes:

Fix EOF handling while reading in bulk or from strings
Fix lax handling of string errors
Fix reading from a null-delimited socket

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

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

Sord 0.16.4

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

Sord 0.16.4 has been released. Sord is a lightweight C library for storing RDF statements in memory. For more information, see http://drobilla.net/software/sord.

Changes:

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

Serd 0.30.2

2019-10-20T22:28:00-04:00

Serd 0.30.2 has been released. Serd is a lightweight C library for RDF syntax which supports reading and writing Turtle, TriG, NTriples, and NQuads. Serd is suitable for performance-critical or resource-limited applications, such as serialising very large data sets or embedded systems.

Changes:

Fix GCC 4 build
Fix colliding blank nodes when parsing TriG
Fix missing parse error messages
Fix parsing "a" abbreviation without padding whitespace
Fix parsing TriG graphs with several squashed trailing dots
Fix resolving some URIs against base URIs with no trailing slash
Improve build system and CI integration
Improve documentation

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