I found some time today to make Ingen‘s support for running as an LV2 more solid. I have posted about this before, but it now works at RT appropriate buffer sizes, and several other bugs have been fixed. Here’s the obligatory contrived screenshot:
People are sometimes confused about how Ingen works as an LV2 (I need to write proper documentation One of These Days): you don’t load an “Ingen” plugin so much (it wouldn’t do anything), as you save an Ingen graph as an LV2 plugin. The idea is that Ingen is a tool for visually building plugins. Since LV2 does not support dynamically adding ports, it’s easiest to do your building as a Jack app, so the basic work flow is something like:
- Run Ingen as a Jack app:
- Build a graph, adding ports, plugins, etc.
- Save the graph to somewhere in your
~/.lv2 (which happens to be the default directory of the save dialog for this reason).
- Voila, your graph should now show up in any LV2 host (its URI will simply be its local filesystem path, unless you explicitly set a stable one). You can check with
There is no export or compilation involved, Ingen’s native format is LV2 compatible (graphs are always saved in the same format). If you saved a graph elsewhere you can simply copy it to
~/.lv2 to use it as a plugin, though for now you may have to create or fix the symlink to the engine binary manually to do this.
Note that you can edit the graph while it’s running as an LV2 plugin, including adding new nodes and connections, you just can’t add top-level ports because the host doesn’t know about them. There is still some work to be done polishing this up to be ready for prime-time, but for the brave, it’s more or less good to go.
Lilv 0.16.0 is out. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications.
This release fixes many bugs and adds several convenient functions to the API. Upgrading is recommended.
- Add lilv_world_ask() for easily checking if a statement exists
- Add lilv_world_get() and lilv_port_get() for easily getting one value
- Add lilv_nodes_merge()
- Make lilv_plugin_get_port_by_designation() return a const pointer
- Require a URI for lilv_state_to_string() and fail gracefully otherwise
- Fail gracefully when lilv_state_new_from_string() is called on NULL
- Make state loading functions fall back to lv2:default for port values, so a plugin description can be loaded as default state
- Ignore state ports with no value instead of printing an error
- Support atom:supports in lilv_port_supports_event()
- Add va_list variant of lilv_plugin_get_num_ports_of_class()
- Fix several plugin functions that failed to load data if called first
- Correctly depend on serd at build time (fix compilation in odd cases)
- Disable timestamps in HTML documentation for reproducible build
- lilvmm.hpp: Support varargs for Plugin::get_num_ports_of_class()
- lilvmm.hpp: Add several missing methods
- Update to waf 1.7.8 and autowaf r90 (install docs to versioned directory)
Sratom 0.4.2 is out. Sratom is a small C library for serialising LV2 atoms to/from Turtle.
This releases fixes a few minor bugs and memory leaks, and shrinks the code slightly by making of the new sord_get() function.
- Fix serialisation of nested tuples
- Fix memory leaks
- Use new sord API to clean up and shrink code
- Disable timestamps in HTML documentation for reproducible build
- Update to waf 1.7.9 and autowaf r90 (install docs to versioned directory)
Sord 0.12.0 is out. Sord is a lightweight C library for storing RDF statements in memory.
- Add sord_get() for easily getting single property values
- sord_validate: Pass type check when range is xsd:anyURI and value is a URI
- sord_validate: Support any subClassOf rdf:Property, not just baked-in ones
- sordmm.hpp: Add convenient constructors for decimal and integer literals
- sordmm.hpp: Add Node::to_serd_node()
- sordmm.hpp: Don’t automatically add RDF namespace prefix to world
- Update to waf 1.7.9 and autowaf r90 (install docs to versioned directory)
Today I implemented better UI generation for LV2 plugin controls in Jalv, particularly grouping controls under headings which makes a big difference. Unfortunately few plugins group their controls currently, but hopefully more host support will provide the incentive to do so.
- Added a spinbutton to slider controls for precisely setting values numerically
- Much more efficient layout to pack more controls on the screen at once
- Support for named scale points (“ticks”) on non-enumeration ports
Here is the UI generated for Amsynth (after I added the necessary metadata):
Still pretty utilitarian, but much more usable, which is the important thing. Of course, this plugin is quite large, and has a pretty good custom UI, but I happened to be polishing up its metadata anyway and the controls group nicely so I used it as my test case.
Maybe some day this code will get smarter and evolve into a library that can be used by other Gtk hosts. Better group layout is the obvious “next level” advancement, a flat linear list of controls is pretty limited. Unfortunately there’s no stock Gtk container which can do text-like reflow, which would be ideal. Perhaps a simpler scheme based on a maximum reasonable width for a controller would do, where the table will expand to have more columns if the window is wide enough for several.
Most of the metadata required to generate a good UI is also useful for other purposes, for example groups make building a decent menu of many controls feasible (e.g. to add automation lanes in Ardour), and some types of host UIs like a modular patcher inherently need to generate their own “UI” of sorts.
Good metadata is not at odds with custom UIs, they each have their uses, but it is important to remove the burden of custom UIs for simple plugins with just a few controls that really don’t need them. It’s a waste of that most precious of all resources – developer time – to have to code UIs for a few sliders and toggles. Hopefully better host generated UIs and support for more advanced controls like file selectors free up developers to spend more time making useful plugins and less time wrestling with GUI toolkits.
It is, after all, all about the sound.
Ardour has supported displaying MIDI patch names loaded from a MIDINameDocument (or “midnam” file) for a while, though only patches, and even that was pretty flaky. Since this has become an itch for me and it’s time for Ardour MIDI to reach release quality, I took some time to give it a serious overhaul. In this case, a picture or two is indeed worth a thousand words:
The note names are mainly useful for doing percussion. Several of the bundled midnam files have note names defined, and I have added one for General MIDI drums, which more or less corresponds to a lot of instruments, including Hydrogen.
Controller names, to my surprise, were not present in any of the existing midnam files at all. I wanted to sequence a hardware synth (the Moog Minitaur) without constantly referring to the manual and trying to remember which CC is which, so I wrote a new midnam file for the device and implemented support in Ardour. I am very disappointed to learn that there is no ability to group controllers, which really is the best way to do things, so I may embrace and extend (in a completely backwards compatible way) the format in the future to provide a better interface.
The quality of midnam files scattered around the ‘net is atrocious. The MMA actually hosts a DTD for it, but most files use the wrong DOCTYPE (usually with a broken link), among other problems. I fixed and cleaned up all the bundled ones in Ardour, validated them against the DTD, and left a README in that directory about how to do so. Hopefully this, along with incentive added by these features, encourages the community to grow a nice set of quality midnam files.
So, MIDI name support in Ardour is now in pretty good shape. Now we just need to add the corresponding LV2 support…
In the past few years of hammering on my repository while moulding Ingen into the modular of my dreams, my poor little generative sequencer Machina was often left to rot. That’s a shame, because it’s a fun tool to play with if you’re into generative gadgets and pretty graphs.
So, I spent the weekend working on turning Machina back into a usable app. It’s come a very long way in two days, from a mess that doesn’t even compile to most functionality working pretty well:
Aside from rewriting a lot of the code, testing, and fixing things that were broken, I’ve changed the conceptual model a bit. There is now always just one start node for a machine. This tends to create more manageable structures, especially when recording several takes into the same machine.
Step recording has also been significantly improved. You can build machines entirely in the UI, but this is pretty tedious. It’s much more effective to record, or step record if you want regular timing and no delays in-between notes. The above pictured machine was created by step recording MIDI, though I have tweaked the edge probabilities with the mouse. You can also import a MIDI file, which is an easy way to get a big machine to work with.
Hopefully I can find the time to turn this into an LV2 plugin and release it, but for now it is an unreleased Jack application. Give it a try if you’re feeling adventurous, I would appreciate any feedback.
LV2 has been slowly but surely moving towards message-based control to overcome the limitations of static ports. The required low level facilities have been available for a while now, but the lack of a standard way to document message-based parameters and host UI support has been a sticking point. One particularly pressing need is file parameters. The current sample example has a stop-gap UI to enable sample loading, but parameters really should be host controllable and simple plugins should not need a custom UI to be usable. Today I did some work towards resolving that situation.
Here is ConvoLV2 running in Jalv:
Note this is the built-in UI generated by Jalv and not a custom plugin UI. Unlike traditional LADSPA style controls, the impulse parameter is not a port, but is set by sending a message to an event port. The plugin lists parameters with the new patch:writable property, so the host knows which controls to display (or which parameters it can automatically set). Parameters are described as normal RDF properties, so any existing property can be used, or plugins can define them as needed in their data files (don’t let the “RDF” scare you, the description of a Property is as simple as LV2 ports). One nice advantage of this over ports is that a project can describe a parameter once and use it in many plugins, without having to describe the parameter every time. This really adds up when you have hundreds of plugins with, say, an identical gain parameter.
These conventions will be established in the next LV2 release (1.4.0), and the sampler example will serve as a test case. When host support becomes established, we can also move towards using messages for numeric parameters, which will finally allow for dynamic parameters, control ramps, and so on.
I have been working on the control protocol aspect of Ingen, towards a few goals:
- Working GUI communicating with the server via a socket
- Decent Python bindings for socket interface
- Ingen as an LV2 plugin
The Python bindings got fleshed out to support a script for loading AMS patches into Ingen I have been working on (very preliminary, but in the repository and installed as ‘ingenams’). The socket interface is now sensibly synchronous, e.g. you send a command, and recv on the socket to get the response, which will include a status as well as whatever patch updates happened as a result of the command. I am happy with this route to language bindings, it’s much more pleasant than a mess of direct bindings (e.g. via swig) and being protocol controlled has many other advantages. The Python interface is implemented purely in Python, it should be simple to do the same in any language that can use sockets.
The Ingen GUI can communicate with the engine via the same protocol, so you can build patches over the network (e.g. if Ingen is running on a headless machine as part of an audio rig). It can also run in the same process and use direct function calls for maximum performance.
The Ingen protocol uses the LV2 Patch vocabulary to describe changes. For the socket interface, this is represented entirely in Turtle. When running as an LV2 plugin, Ingen uses conceptually the same protocol, except in a binary format using LV2 atoms. This is a nice example of the benefits of having things defined in a good abstract model which can be encoded in many ways. For example, it would be relatively simple to implement control via JSON for a browser-based Ingen UI, which seems like the best way to go for separate control panels, but that’s a topic for another day.
Since Ingen control can be expressed as atoms, it can run as an LV2 plugin with a full patcher UI and communicate only via LV2 ports. The UI is embeddable, and there is no memory sharing between engine and UI or hidden communication, everything is host managed. Here is a screenshot of Ingen running in Ardour 3. The MIDI in Ardour is played through an Ingen synth plugin, and the output has been recorded to the audio track. The patch can be manipulated live while running in Ardour, except for top level ports.
I have been working on getting accurate transport information provided to LV2 plugins. Until now, there was the ability to specially designate e.g. BPM control ports, but this has limitations, the most obvious being that it is is limited to conveying simple numeric values at the start of a cycle.
In general, things are headed in an event-based direction, and this is no exception. The LV2 Time extension defines all the properties needed to describe a transport position/speed/tempo/meter and the LV2 Atom extension defines a dictionary type that can be used to send several properties at once in a single event. The host sends updates whenever the transport has changed in a way the plugin can not anticipate (anything but rolling along at the same speed/tempo/meter). Since events are time stamped, this makes it possible to give plugins a sample accurate tempo map, even when there are changes in the middle of a cycle.
There is a new example plugin in the LV2 repository, eg-metro, which is a simple metronome that follows this scheme. If the host implements the above, the metronome will click in sync with the host transport.
I have implemented this in Jalv (which uses Jack transport), Ardour 3, and Ingen (via a new internal “Time” block). Ardour will send an update at the start of the cycle if a relocate has happened, and one on the exact sample of any meter or tempo change within the cycle. Due to the limitations of Jack transport, Jalv and Ingen will only send updates at the start of a cycle. The metronome should tick correctly when loaded in Jalv or Ingen when there is a Jack transport master active (I have tested with Ardour), and when loaded directly in Ardour.
This functionality is pretty important for many musical plugins, so hopefully other host authors implement it as well. Depending on feedback (and available time) I may document the above rules as a feature and add it to the time extension, and release LV2 1.2.2. I think a well-defined way to achieve this is worthy of a point release, and it will get the news out there to implementers.