LV2 1.0 released, what’s next?

If you are a musician considering a switch to Linux, one of the questions you are likely to ask is what plugins there are to use.

The situation with VSTs built for Windows is pretty much the same — your mileage may vary. Support for native VST on Linux keeps getting better. But what about native free APIs for Linux?

Last week David Robillard announced availability of LV2 1.0, the first officially stable release of the free API for creating virtual instruments and audio effects.

LV2 is a successor of both LADSPA (audio effects) and DSSI (instruments) with some backwards compatibility. The scope of the API more or less equals to the sum of LADSPA and DSSI, not in the last place thanks to its modular design.

That makes it possible to create compressors, reverbs, pitch correctors, synths, samplers, MIDI FX plug-ins etc. Currently there are some 100 to 200 free LV2 plug-ins, some existing commercial ones (linuxDSP) and some planned commercial ones (Loomer). The API is supported by major Linux hosts such as Ardour and Qtractor.

But here is a question: after 6 years of development is LV2 self-sufficient? Are musicians happy with the available selection of plug-ins? What about plug-in and host developers? Is there room for improvements? What could be the next big thing?

In the quest for the ultimate truth (or its close approximation) LGW interviewed several influential people in the Linux audio ecosystem. The interview revealed some controversy.

Since the topic is quite large for a single article, we are splitting it into three sections. In this part we are talking to Dave Robillard, creator of LV2, and Louigi Verona, a live performing musician. The next sections will cover LV2 from developers’ perspective and feature most interesting plug-in bundles.

First person point of view: David Robillard, LV2

David is the lead developer of LV2 specifications and many of the related infrastructure projects. In 2006 and 2007 he also did two successful Google Summer of Code projects to implement MIDI tracks in Ardour, a free DAW for Linux and Mac. He is also the primary developer of all things LV2 in Ardour.

David, are you satisfied with the pace of LV2 adoption by developers of hosts and plug-ins?

Well, these things take time, and you just get used to that fact. It would certainly be nice if more people were involved in progressing / maintaining LV2 as a whole, but there is only so much time and ability to go around.

I am, on one hand, amazed when I see time stamps on LV2 stuff from over 5 years again. It doesn’t seem like we’ve come very far for that long.

On the other hand, when I first got in to audio development, all we had was LADSPA. Now, I have a plug-in interface with which (for example) I can build a modular synth that uses exclusively standard plug-ins to process any kind of data, and the modular synth itself can be one of those plug-ins, where the UI communicates with the engine entirely through the plug-in API which is network transparent.

Finally! That is awesome. Being able to drop such a plug-in in to a mixer strip in Ardour has long been a fantasy of mine, and I’m happy to report that with this release all the requisite functionality is there.

Adoption is progressing at a decent pace, depending on how you look at it. Within the LAD realm, LV2 is quite widely adopted. Outside that, clearly it’s not yet actively taking over VST and AU and friends. I generally take an “if you build it, they will come” position on this, and have spent lots of time lately improving things that are barriers to adoption (documentation, dependencies, performance).

I also hear about various people’s LV2-based experiments on a regular basis, which suggests there’s a lot of activity going on out there that isn’t public or widely known yet. The nature of plug-in APIs means that a little bit of work can increase adoption in great leaps. For example, recently “falktx” has made a wrapper for the JUCE API and ported several high-quality plug-ins, fancy UIs and all.

It’s taken quite a bit of time to get this far, and it will take more time to get further, but that’s okay. It has taken this long for me to really piece together in my head how all this stuff needs to fit together anyway — there have been many, many unpublished failures along the way (and a few published ones).

Not all the work is done by myself, of course, I just curate it all. Every once in a while someone pops up and works on an extension to scratch their itch, which is exactly how LV2 is supposed to work.

I have always maintained the only way we can really get this API is to grow it — nobody could sit down and write it from a blank slate. I think the ever-improving state of LV2, hiccups and all, vindicates that position.

I’d rather have good things in a few years than crap now. Hopefully I can manage to not get hit by a bus before it’s done :)

With LV2 1.0.0 released what do you consider to be the next primary objectives for the project?

The new release contains a lot of new functionality which increases the power of the “official spec” greatly. In particular, there is now a communication mechanism plug-ins can use which is capable of doing just about anything (for example, UIs can interact with the plug-in via an interface much more expressive than a few numeric controls). This has been needed for some time. A state saving interface is also a big leap.

I think for the next while, the main global goal is to get these things implemented in more / all hosts so that plug-ins can use them. While, as always, some minor things here and there will need to be tweaked, I think the evolution of the LV2 ecosystem will not require any significant work on the specification itself for some time.

As for specific goals, naturally I have my own pet projects, but others have different ones. LV2 itself has always been about enabling developers to do what they want, and since the specification has become a lot more powerful, I’m sure we’ll see plenty of new plug-ins that would not have been possible previously.

Increased adoption of LV2 itself is another objective. To this end, in the past few years my implementation “stack” (the lilv library and its dependencies) has dropped a great deal of dependencies, and become very portable (tested on all major platforms).

LV2 is much more of a lightweight dependency than it was when it first arrived, there has even been some mention of taking it into mobile and embedded spaces.

Do you think LV2 could be used for web apps? Should it? Is it ready for that?

Well, though all the data aspects are reusable, LV2 itself is fundamentally a C API. The audio processing side of things will probably always be low level C/C++ code, or something (like Faust) that compiles to it.

Of course, this doesn’t mean it can’t be used in a web context. The main area where that comes in is plug-in UIs. I do think doing plug-in UIs with web technology is a great idea, in particular to allow tablets and smart-phones to act as remote control surfaces.

The ultra portability (everything has a web browser) is also very appealing. That said, web technology is not the most appropriate choice for everything, but it is great for some things.

I would love to see it, but I don’t have the time to investigate that actively myself. A few people are interested in the idea though, so we’ll see. I know the NASPRO project has some ongoing work on UIs built with web technology, but I am not very familiar with the details.

Whether it “should” is not really important. Plugin UIs are by nature separate from the plug-ins they control, so it’s not anything everyone has to agree on, it’s just something anyone can do if they want. Nobody is forcing anyone to use a particular UI.

Personally I would like to see a move from heavyweight system toolkits (like Gtk and Qt) to something lighter and / or more portable, like perhaps GL or the browser stuff.

Regardless of the technology used, I would very much like to see more work done on host-generated UIs, i.e. UIs automatically generated from plug-ins with precisely defined controls in their data.

I have never been a fan of “big stupid pixmap” UI design and wish people cared more about usability and accessibility than pointless gloss. Unfortunately conventions in the audio software world carry a lot of weight.

What do you think about GPU-side audio processing? Do you see any future there?

GPUs can certainly be used to process audio at mind-bending speeds, but programming for them is very difficult. The world of GPGPU programming is still pretty new, unfortunately there is not yet one single API you can use that is the best choice on any reasonable machine.

I think the biggest problem with this would be latency. GPUs can achieve really high throughput, but you have to keep them fed with data, which is probably not possible in a Jack callback with a low buffer size.

It would certainly be useful for offline processing, but realizing this for real-time processing with many plug-ins would probably require a considerably different plug-in interface. It’s an interesting area, but realistically I don’t expect to see it any time soon.

Eventually every CPU in every machine will probably have something like a GPU processor and the API situation will calm down, and we’ll probably see more action in this area.

Musician’s perspective: Louigi Verona

Louigi switched to GNU/Linux in autumn 2009. Since then he actively writes and performs music using Linux audio software. Main apps in use: Qtractor, Rakarrack, Specimen, harmonySEQ, JACK Keyboard, PureData. Most used plug-ins: CALF Vintage Delay LV2, DJ EQ LV2, some of the Holap Plug-ins (LADSPA) and Nekobee DSSI.

Louigi, as a guy who composes electronic music you do a lot of experiments with various applications. Do you have particular favorite setups? What role are LV2 plugins playing there?

Most of my work is done within combinations of Qtractor, Rakarrack, Specimen and harmonySEQ. I do use LV2, namely CALF plug-ins, and I also like DJ EQ. I love the fact that they have the ability to have a default preset, as opposed to LADSPA where the plug-in would start up with default values.

The reason why my LV2 usage is still rather low is exactly because as an electronic musician I require sophisticated effects and there are almost none of those among LV2. And so Rakarrack plays a rather big role in my music production process. I would certainly be very happy if Rakarrack plug-ins were converted to LV2.

The JACK client course that had become mainstream contrary to plug-ins eventually led to a situation where musicians were forced to become some sort of 20th century switchboard operators, dealing with gazillions of connections. Today we have half a dozen of session managers to automate reconnection between apps. Do you think it helps, or is it just a new circle of hell? :)

I would say for the moment none of the solutions are fully satisfying. I’ve tried many of them, but each has a downside and eventually I could not fit any of them into my workflow. For me personally session management is not solved.

I do see the enthusiasm towards solving the problem. Hopefully, we are moving forward. So far I am using simple scripts and try to have productions which do not rely on session saving.

In terms of LV2, what do you find missing the most?

First of all, synthesizers. Apart from ZynAddSubFX and Phasex there is not much one can do to get complex electronic sounds. ZynAddSubFX, which is hailed as the best Linux synthesizer — and rightfully so! — is, unfortunately, just another good synthesizer by VST standards.

There are dozens of synths of that level on Windows. And if I analyze why do I have to boot up Windows at times — it is to get samples of VST synths.

Do you personally find the development pace in Linux audio world satisfying?

Sure. The speed with which things happen on Linux is very high. What I am concerned with is the direction. I want more to be done in the department of electronic music, sequenced music, which means session management and / or all-in-one sequencer. And, of course, lots and lots of plug-ins, both effects and synthesizers. I could be wrong, but I do see more of LV2 plug-in projects being started, and this is good!