LV2 from developers’ standpoint

When it comes to designing and implementing APIs, hell is often on the verge of breaking loose. LV2, the free API for virtual instruments and audio effects, is no different.

In the first part of the article we spoke to Dave Robillard, the principal developer of LV2, discussed the future of the API and additionally spoke to Louigi Verona, one of the actual end-users. But what does it look like for developers of hosts and plug-ins who are kinda in the middle?

Today we are talking to Rui Nuno Capela, lead developer of Qtractor, and Mike Start, founder of linuxDSP.

From a plug-in developer’s perspective: Mike Start, linuxDSP

Mike Start is the founder and lead software developer for linuxDSP. Prior to starting this business he was a software / hardware design engineer for over twenty years at Solid State Logic (SSL), one of the world’s top pro-audio companies, including involvement with the development team for SSL’s ‘Duende’ plug-ins / DSP hardware.

Mike founded linuxDSP after creating some Linux plug-ins for his own use. The reason for writing them, in his own words, was disappointment at the lack of high quality processing on an operating system which he thought could be much better suited to high quality, stable audio processing than some other operating systems.

The company is a small business consisting of Mike himself and a few other developers / audio professionals who mainly contribute to software testing and design.

Mike, do you think LV2 has particular compelling technical advantages over competing proprietary APIs?

No, and that’s not a criticism of LV2. Politics aside (e.g. open vs. closed standards or APIs etc.), on a technical level, in my opinion LV2 is no better or worse than any of the other APIs I’ve become familiar with.

There are issues with e.g. VST which are annoying, and there are issues with LV2 as well, none of them present real problems, they are just different.

How difficult is it to simultaneously maintain both VST plug-ins, LV2 plug-ins and JACK clients?

My plug-ins are structured such that VST and LV2 are actually quite similar. Fundamentally, the plug-in consists of an editor (GUI) and the DSP code and a mechanism for passing data to and from the host to the plug-in.

Only a small part of the editor code is actually concerned with communicating with the host, and that is similar enough to allow a fairly universal approach (I actually create a VST compatible editor API and then wrap the LV2 API around it when required)

Likewise, only a small part of the DSP is concerned with passing parameters and data to / from the host, making it possible to share a lot of common functionality.

For JACK clients, it’s then possible to create a standard, standalone ‘micro-host’ application which just runs the (LV2) GUI and DSP code for a single plug-in, and handles passing data to / from JACK.

Last year you submitted code for native Linux VST support in Ardour. What was the drive behind this decision?

Native linux VST support for Ardour had been requested on several occasions by many users, as there are already some commercial plugins from other developers available as linux VSTs.

As Ardour was the only (or one of very few) linux DAWs not to support linuxVSTs, it made sense to add that functionality, and is consistent with our stated aim to support open source projects if possible (linuxDSP software contains no GPL’d code, but we are aware that it is indirectly dependent on many open-source host applications)

Adding VST support was intended to broaden the choice for users (and developers), rather than indicate a preference for any particular plug-in standard.

LV2 allows creating custom UIs which some plug-in developers like yourself use to create skeuomorphic UIs. But usability experts tend to criticize that approach lately pointing out that even with touch interfaces a hardware-looking handle provides a different kind of interaction. What’s your own view on the subject?

It depends upon the nature of the plug-in. For example, if you are creating a genuine hardware emulation such as the linuxDSP PEQ-2A Pultec EQ then I think it makes complete sense to make it look as well as sound like the original (and we have added innovative features to make the physical ‘feel’ of the controls match that of real hardware too)

Almost all users who are used to using real hardware say that having the UI look like the hardware enables them to instinctively find and adjust the controls in a way that generic widget interfaces do not.

Equally, where we have a more abstract plug-in (not based on real hardware) such as the 10 band graphical EQ, it makes sense to present the user with e.g. a graph that can be manipulated in real time. Its much more intuitive than, for example, thirty generic slider controls.

I’m sure we’ll see continued innovation in UI design as technology advances, but I think there is room for both hardware look-a-like and more generic UIs.

From a host developer’s perspective: Rui Nuno Capela, Qtractor

Rui is mostly know as the author of a handful of applications, ranging from editors of hardware synth patches to Qtractor, an audio and MIDI sequencer. If you are Linux-based musician, even if you don’t use Qtractor, you most likely use QjackCtl.

Qtractor is one of the few Linux hosts that supports both LADSPA, DSSI, native VST and LV2. Given the “obsolete” status of LADSPA and DSSI, which of the other two, native VST and LV2, gets more developer attention in your project?

DSSI might be naively called “obsolete” but it has been here for more than a half a decade already and delivers much of what LV2 doesn’t (or just failed yet).

One should think that the so-called DSSI’s “obsolescence” is mostly derived by the fact Ardour3 never came to the bits with it. In short: the MIDI part of Ardour3 was developed by one single coder extraordinaire who is by coincidence the very same as of most LV2 stuff nowadays :)

DSSI got overlooked or just ditched by Ardour3 devs. That decision just made stronger the feeling that DSSI is an outcast and deprecated plug-in spec. But truth is that DSSI delivers since years ago when LV2 is still promising :)

DSSI hosting has been implemented in Qtractor as natural evolution follow-up of LADSPA. Then came native VST which is a big different beast, but tremendously interesting for the MIDI instrument parts of the story (VSTi). And it delivers.

Too bad some emerging JUCE plugins didn’t play well enough on x11 back then. But things are a lot better now, thanks to Filipe Coelho (aka falktx, of kxstudio fame). Even Ardour3 has native VST support now, thanks to the linuxdsp.org.uk as I’ve been told.

LV2 was the last and it’s still struggling to get it all right. At least from a user experience point of view. Some things work but some others don’t. Some plug-in GUIs work, some others crash the whole show — especially the ones based on GTKmm or following the (IMHO) deprecated LV2-c++-tools framework, broken in that sense while plug-in authors should have read the danger warnings from its own author’s letter. But yay, it’s a free world :)

Problem is, developers around here may be counted by fingers on one hand. OK, maybe two hands. Some are what some might call eggheads — like me :) I’m just a kind privileged old one perhaps. I fear my digressions will scare the younger.

Incidentally, this guy called jeffh has been spitting a flood of brand new plugins, both audio-fx and MIDI instruments. His stance just brings us what I’ve just said. Being a formerly VST/Windows plug-in developer (allegedly) he finds LV2 damningly incomplete and still half-baked (in his own words). DSSI got it to the point and it’s a finished spec, even though it’s been called a “disposable instrument soft-synth” plug-in specification.

As a host developer, what further improvements are you particularly interested in with regards to LV2?

I’ve been interested in LV2 to cover all DSSI and VSTi features in this order. It hasn’t come close yet. But to be specific, MIDI bank / program addressable instrument presets (supported by both DSSI and VSTi) is a long whined one :)

Also, DSSI through a configure dictionary and VST through blob chunks have been supporting internal plug-in state serialization for years. LV2 state extension is just lifting off this very moment, and Qtractor has been doing some if not all the incarnations of LV2 extensions through it: there was this LV2 save / restore, then that LV2 persist other, ultimately leading to the LV2 state one which is the last one available. Let’s see if it stands still for much longer :)

As you can see, LV2 has been plagued with too many iterations to do the right thing and still, we’re nowhere much near what DSSI and VSTi has been delivering years ago. Both have been quite stable specs while LV2 has just seen its first consolidated release (a few days ago.)

There are some other features that are present on the VST spec side, which are of particular interest for the more sophisticated of plug-in authors or designs. Well, DSSI won’t comply with it anyway, that’s granted, because it’s a closed / finished spec though.

So chalk that one off from DSSI. I’m talking about support for those plug-ins that have sequencing and editing features of their own. Like a DAW inside a DAW, or a sequencer inside a sequencer or a cross between the two.

We’ll have to figure out how all this and several other things get to get worked out by the LV2 extensions and paraphernalia. From a developer’s point of view, be that either a host or plug-in developer, you’ll be amazed by the sheer complexity on putting up the barest and simplest of things using the LV2 programming spec. I’m of course exaggerating here, but the LV2 learning curve is quite steep if not dang vertical.

That said, I really have great expectations about lilv. I hope it makes all the heavy work of abstraction from the raw tyrant LV2 spec :)

What about recent changes in LV2 and the lv2_atom interface in particular?

This lv2_atom is a dang new incompatible MIDI data transport for hosts and plug-ins. Although internally similar to the old/current lv2_event infrastructure, it’s more like a brand new lv3 interface, if you ask me.

The recent mda-lv2 release uses this lv2_atom(ized) thing. That said, all the MIDI instrument plug-ins in that new mda-lv2 suite will be just useless in Qtractor. They won’t work and there will be no simple hack to work around that. So sorry. The audio effects ones will play nice though. I don’t have much time to spare on doing the overhaul that the new lv2_atom(izing) interface requires.

Do you think some sort of internal API for virtual instruments would make sense in Qtractor, or are you already happy with existing APIs?

In one word: no. That would start another plug-in spec war, so to speak. May I remind you that Qtractor was originally cranked up to drive external / outboard hardware. Plug-ins come after that, but nevertheless, you see, in the beginning it was this marvelous JACK and ALSA world, when every standalone application would matter as a “plug-in” itself through interconnected audio and MIDI I/O ports.

The “plug-in” model, formerly designed by the Steinberg, Cubase and VST people back then in the late 90s, have always been a model that fits great on the so-called “monolith” kind.

JACK ought to make things a bit different, like in UNIX spell, let each application do its job done well and such visionary thoughts of independence and self-determination. And quite frankly, the cornerstone to JACK was, and still is, its astonishingly simple API approach.

In comparison to that, LV2 host or plug-in development is the most insane nightmare. A nightmare that could be avoided if there where enough code examples, tutorials, intelligible and aggregated information to do the job.

I may speak for myself, as an old-fart, a decades old software engineer of sorts (was once a Cobol programmer, you can start laughing now :) or at least a seasoned Linux audio developer by this terms and time. But quite frankly, writing down a LV2 plug-in without resorting to the dreaded cut & paste anti-pattern has been a severe hindrance. All hail to lilv which will save us all from the LV2 hell :)

You have a great contact to your user base. What kind of plug-ins do you see in demand most?

What people ask for are plug-ins that work and behave as their authors fully desire. At least as fully as VSTi’s worked on the late decade, for crying out loud.

People love to use and show off their above average, sophisticated plug-ins, which IR-LV2 is one for instance. Too bad it does not play well on Qtractor just because its author went the fast lane and hacked it around the LV2 spec to the bone. Besides it’s relying on GTKmm which is a big no-no for a Qt4 host like Qtractor — it crashes on close; if it were crafted on pure GTK+, it would be a lot nicer.

However, the good news is about all this being open source and some guys / gals even not being such experienced in programming at all, but primarily musicians who hear the potential of such pieces of software, have been driving forks of their own. Can you believe that? Might only happen on this side of the free / open source world, I’m sure :)