Push for LV2 on KVR

Hi all,

There is currently a discussion on KVR between VST developers, angered by Steinberg’s recent VST2/VST3 license changes, who are seriously discussing opting for an open plug-in standard, either new or LV2 (Mixbus was named as a LV2 compatible host). Among these developers, some well-known names like U-he, discoDSP, Tone2, Auburn Sounds, etc.

As a musician, I feel like opting for LV2, even if it means improving it, rather than inventing a new standard would serve the community better.

Perhaps the Ardour team will be interested in weighing in?

Well this is a kick in the nuts: VST2 plug-ins - DSP and Plug-in Development Forum - KVR Audio

2 Likes

Ardour already supports LV2, VST2 and VST3, so everyone’s covered aren’t they? As a musician, you can opt for what you want - as a plug-in developer I think “Yet another new plug-in SDK ™” is exactly what is not required - especially given that the VST3 license is much more amenable to Linux / open source, and the issue with VST2 is, AFAIK old news?
From a (commercial) independent developer’s perspective I see it like this - another new format makes people less likely to buy a plug-in unless it supports the new format - even if they don’t need it to (because future proofing, perceived value add etc). At the same time each new format adds exponentially to the amount of testing, hardware required, debugging and development resources etc, and requires many man-hours of development, often for no reward because by definition a new format won’t initially be widely supported by host applications, but, as mentioned, no one will buy a plug-in until it supports the new format. (I believe this could in part be the reason there was relatively cautious uptake of VST3 in the first place…)

English is not my first language and I misspoke. Let me rephrase it:

As a musician, I feel that the community would be better served if these developers, who can’t stand Steinberg and their bad practices anymore, chose LV2 rather than inventing a new standard.

The reasons are exactly the ones you mention.

I know that Ardour supports LV2, VST2 & VST3 as does Mixbus which is derived from it. VST2 is no longer licensed. VST3 is problematic because it does not support MIDI in a right and complete way. Steinberg doesn’t care. This is one of the main reasons why these developers would prefer another format. On the other hand LV2 is aligned with Ardour’s values and ideals.

On reflection, it is more the LV2 team, if there is one, that could be interested in weighing in. So I probably chose the wrong forum.

The LV2 team is at best two people, for whom it is not a full time job (or even a job at all).

LV2 is essentially finished as a plugin specification - it was built to be extensible, and that’s where “the action” takes place: new plugin extensions, supported by various combinations of plugins and hosts. The core just works, and there’s nothing more to do than promote it.

Which could be difficult. For some reason, a rather alarmingly high percentage of people who encounter LV2 are confused by it, even though it’s no more complex than VST2 (and arguably a bit simpler than VST3).

2 Likes

I can’t imagine why…

Oh yes, that - and the .ttl files would be my guess… :slight_smile: - the core is not that different from any other plug-in API - LV2 doesn’t really (need to) offer anything new in that respect, what is often a source of confusion is understanding what extensions are likely to be supported in which hosts, which ones are no longer supported etc and which ones should or could be used by a plug-in for maximum platform, OS (and host) agnostic support.

I think VST3 actually offers a more easily approachable extensible format - unfortunately, something of a political issue seems to have broken out over licensing, which seems to have upset some users and developers. I’m fed up with the politics, as a developer I just want to make some software people can (enjoy) using - and just when I thought things were finally converging on something of a viable platform for Linux audio (so, maybe next year will be the year of the Linux (audio) desktop…) :slight_smile:

I think that the manner of arrival of Vital more or less establishes that the convergence you want is already here. It may not look the way you want it to, but in all practical senses, it’s already here.

That and DecentSampler and the continuing improvements in sfizz to cement the sample library side of things.

When I told the creator of DecentSampler and of the “WinterVoices” choir sample that I was using it inside VCV Rack on Linux, they were both blown away, not by the Linux part, but by the fact that such a thing was even possible at all.

More and more plugin developers are using tools that can spit out VST3 or LV2, and so the basic story is getting close to “it all just works”.

I’d be the first to admit there’s a ton of good reasons for that, though I’m working on it. Currently I’m focused on the host stack, because it’s far too much of a pain to implement a new LV2 host right now (though this includes far better validation tools and whatnot which of course helps plugin authors). I wrote a few articles vaguely around this a while ago:

https://drobilla.net/2019/11/11/lv2-the-good-bad-and-ugly.html
https://drobilla.net/2019/11/13/cleaning-up-the-lv2-extension-mess.html

Ultimately the goal there is to have a single “lv2kit” with everyone one needs to develop and host LV2 plugins, and have it all be… well, good. Probably also including good idiomatic modern C++ bindings, since this is a huge barrier for everyone outside of our little niche here. A significantly bigger one than the Turtle thing, to be honest.

After that I think some time needs to be spent on the spec itself, clarifying things that are already there, adding some new features to cover a few things that are still missing, ensuring that all of the implementations out there are actually doing things correctly and interoperating nicely, and so on.

That said, I don’t know if LV2 as it currently stands is a particularly good candidate for a widely accepted standard for a bunch of reasons. Of course, as Paul mentioned, all of that is an absolutely massive amount of mostly thankless work, and it’s pretty much just myself driving it. In a perfect world where there was more time and resources available, I think it would probably be a good idea to break some things in order to simplify and clean them up, and remove a bunch of superfluous or confusing gunk that has accumulated over the years in the anarchic process that formed LV2. We’ve certainly learned a lot as a community over that time and could do a much better job now, but… frankly I doubt that’s a very realistic thing to achieve. We definitely missed a big opportunity with all the VST3 wannabe-expats, but oh well. Such is life.

I’m also trying to do some work around the project itself to increase the bus factor and encourage more community participation in things like documentation, but again… it’s all a ton of work, and I’m not sure all of that is the best use of my time even if I am willing to do it.

Anyway, onwards and upwards. In the grand scheme of things, I still think it’s best to simply charge forward, making things work (or work nicely) that didn’t before. At some point we can perhaps worry more about making things pretty and pushing more for “outsiders” to adopt it and so on, but personally I don’t think that’s the most important thing at the moment. As mentioned above, most authors use some kind of framework or another that abstracts the API itself away anyway. Ultimately, LV2 is a somewhat organically grown “worse is better” project (which is why it actually exists, and actually “solved” the problem to some extent). People often wish for a prescriptive spec where everything in there is very strictly specified and standardized with hard rules for absolutely everything dictated before the functionality is available for people to work with at all, but… it just isn’t. We could turn it into one, which quite some work, and probably with some breakage if we want to do it nicely, but that’s not what LV2 is. At this point, the “official” specs probably should be that, but it wouldn’t have been possible to build the thing initially that way, so… here we are. It works, but it is a bit of a mess. That’s better than nothing, though, which was the realistic alternative (see GMPI, for example).

There’s 87432890432 forum posts or whatever over the years that say things like “what is often a source of confusion is understanding what extensions are likely to be supported in which hosts, which ones are no longer supported etc and which ones should or could be used by a plug-in for maximum platform, OS (and host) agnostic support”, which is fair enough, but… well… all it takes to solve that problem is for someone to actually do the homework and write it down… :wink:

1 Like

@drobilla: so what would be the best way forward for me as a developer if I decided to invest the time (also a fairly thankless task…) in porting some plug-ins to LV2?. What would be your recommended “hello gain.lv2” for example (and does one exist). I’m quite sure I could bend the rest of my code to fit - I just need to exchange parameter values and launch an X11 UI, but, even the former seems to be “well we do it like this except when we don’t and, maybe we won’t in future, perhaps” :slight_smile: So, should I just find a plug-in that seems to work in Reaper and Ardour and just use that for - inspiration - and hope I don’t have to rewrite it all again in a few months time? I’m just trying to make things people can use - with the minimum of complication, and, make the best use of my time.

You… er… already have, as far as I know?

The “official” examples are at plugins · master · LV2 / lv2 · GitLab, eg-amp seems the closest to what you’re talking about, although none of them make an X11UI at present. Parameters are indeed in flux, but the old LADSPA-style control ports will work fine enough if you don’t need anything fancy and want them to work everywhere.

I made some LV2s about ten years ago - its possible I did revisit it again more recently than I recall, but I don’t have any official releases of current (desktop) plug-ins in LV2 at the moment (and, I assumed many things would or could have changed in the meantime - which is why I was looking for an example of the current state of the art).
At the moment it feels like on the one hand we have some users saying “we want more LV2 support in applications - and plugins”, on the other, a host application developer who says “LV2 is done” and the inventor of LV2 saying “Well…, its not quite ready for primetime yet…” - so I’ll take a look at some examples, but I’m a bit hesitant - if there was an official LV2 SDK, with examples, documentation, resources, license, etc then I would be more inclined to consider it as a possibility - until then it might be something I’ll follow with interest or experiment with, but I’m reluctant to commit development resources to.

Well, It Depends™. The spec (more or less) doesn’t break in general, so whatever worked then will work now, especially from a plugin point of view. Like I said, there’s a lot of work going on to make it easier, but that is currently mostly focused on hosts. There is now Pugl, for example, which is slated to become part of LV2Kit and deal with the lowest layer of the X11 (or MacOS, or Windows) UI problem in a more “official”, centralized, well-tested, etc way. Ultimately, though, that’s just a support library and you’re free to make a UI however (which is a good and necessary thing here in reality). That’s just how things go: the UI situation, for example, has been a mess for ages (mostly starting out with the massively problematic “just use Gtk or whatever”), and it’s slowly becoming less so by consolidating all the lessons people have learned into a single place so bug fixes and features and whatnot can accumulate for everyone to take advantage of. This is a tedious and slow organic process, but that’s also why LV2 exists unlike so many other pipe dreams. I personally get frustrated at the mess because I’m somewhat neurotic about software quality, but that doesn’t mean I don’t think plugins should implement LV2. It’s important to take a step back sometimes and realize that what we have here is a whole lot better than nothing (the proven alternative in reality). Maybe parameters or whatever kind of suck thus far. Whatever, we can make ones that suck less then. Onwards and upwards. For all of its faults, LV2 evolves a whole lot better than VST does.

if there was an official LV2 SDK, with examples, documentation, resources, license, etc then I would be more inclined to consider it as a possibility

Well, that’s good to hear, and why I’m making it (aside from the “license” thing anyway, everything is and has more or less always been ISC). It’s called “lv2kit” and there has been a lot of progress there… but few people seem to really recognize how much actual effort all of that stuff takes. There is indeed a chicken & egg problem with some of the tech itself, but just the documentation part alone is probably the better part of a year of work, for example (this is essentially like writing an entire full-size textbook, and then some). It’s easy to wish for everything to be done and perfect before investing at all, but I (or anyone else contributing to LV2 itself) have to actually decide on the implicit “or” behind all those mentioned things. Which one would you do? These are not easy choices to make, especially when you have to weigh the desires of so many different kinds of developers in the process (some of which are relatively silent and don’t participate in discussions like this at all). Many of them are even at odds with each other. For example, the host support chicken & egg problem is a big one, and nobody will really care much regardless until at least some of the big commercial DAWs support it. Yet many in the current niche community are at best not interested - more often actively hostile to - much of the stuff that would need to happen for that (easy vendoring of all the support libs, better documentation for “outsiders”, C++, IDEs, and so on, for example). Do you do that, then? Try to make things shiny for hypothetical new adopters instead of improve functionality and whatnot for existing ones? Meanwhile everything else rots…

Sometimes people even wish for things they definitely do not actually want. The official LV2 GUI toolkit is probably the best example of that. They may think they want some perfect fantasy version of such a thing, but very definitely do not want the reality of one enforced LV2 toolkit getting in their way, particularly when there is no real reason to ram such a thing down everyone’s throats.

Documentation? I (or whoever) could spend a whole year writing the best software documentation the world has ever seen, for example, but how smart of a decision would that be? How much of a blocker is that for people really?

All of which to say: software in general is hard, but software that dictates the interactions between hundreds of different players who all need to get along and can easily blame that software for everything is a whole lot harder than that. Concretely, these sort of decisions are why I’m not directly working on Ardour right now at all. How long does that make sense to do? 6 months? A year? 2 years? 5? 10? Forever?

Anyway, to more directly answer your question, I think both myself and Paul are right at the same time. Sure, the basic idea is mostly done, and people are free to build on LV2 to do more or less whatever they want to do with plugins. It could be better, certainly, but mostly in a superficial sense.
In general, my recommendation for adoption is the same as it’s always been: if you’re willing to collaborate with other hosts and plugins to get things done that aren’t thoroughly established yet, hop on board. Nothing’s perfect - least of all VST - but people seem to get on just fine. If not, well, don’t.

Alternatively, not to put too find a point on it, but there is of course a third option. I try to support other free and open projects because they pay back in kind (e.g. with code). Commercial proprietary developers who aren’t willing to do so may pay in cash instead. It’s pretty easy to make things happen across the whole ecosystem and be standardized pretty quickly if you want… it’s just not free :wink:

2 Likes

Yes - I’m an independent developer, so, I do all my documentation, plug-in manuals (not as well as I would like), I write the code, I do graphical stuff, maintain the website(s) and all the admin that goes on behind that - I even fix the hardware too… often for surprisingly little income - I completely get what a massive amount of work all that ‘making it into a product’ is - and I guess the same is true in respect of SDK documentation and development too. I’m not complaining about that - its “what I do” - I can’t imagine not being involved in audio software development at some level, and I’ve been fortunate enough to work with some of the best in the industry over the last 30 years or so. More than anyone, I understand that software developers need to earn a living, and while I have contributed to open source projects in the past, in fact even to Ardour, unfortunately I’m not in a position to commercially sponsor LV2 development.
In respect of everything else you mention - basically I can’t disagree - it would be nice if there was an official SDK - but I understand why there isn’t yet (and that’s not a criticism). I might be tempted to experiment with LV2 a bit more, but I’m still reluctant to put significant time into any official plug-in ports at present

2 Likes

Sure. To be clear that wasn’t directed particularly at you and wasn’t a criticism, I’m just sort of generally complaining :slight_smile: Big threads of a ton of mostly proprietary developers complaining that they weren’t given enough for free as in the original topic here can be… frustrating. Libraries and SDKs are so much worse than libraries and SDKs. At least with plugins you have something to offer to users, and hopefully get support for. With SDKs or whatever other developer-facing things pretty much all you get is a constant firehose of criticism (constructive on a good day, and most days aren’t). Nobody cares unless it’s in their way. Even if I did absolutely everything mentioned here, better than any of them have ever been done in the history of software (which clearly isn’t happening), it would still be that way. It’s just the nature of such things. Aside from how this psychologically would grind anyone into dust over time, it makes it unbelievably hard to figure out what to do.

But anyway, on the concrete side of things, I’ve decided that the SDK thing is the most important thing to do (along side various factors like better integrated documentation and removing some crap and so on), and it’s getting there. Big version 2 of all the things should surely be out this year (I hope, but even accounting for my current semi-homeless state and this general pandemic nightmare, I think that’s a realistic conservative estimate, ideally much sooner). Most of the heavy lifting is done at this point. Because compatibility is such a factor and this is the first time I’m breaking any APIs (just host ones though), I’m trying to take my time and be careful (since we’re probably going to have to live with it for another 10 years), but also not get stuck in a rabbit hole of perfectionism forever.

At the very least, this should make it a whole lot easier to move the actual spec forward, since everything will live in one place and have a lot better infrastructure for testing and validation and so on. Probably including making broken plugins just not load whatsoever to force people to deal with issues. Then maybe we can get on with attacking some of the pie in the sky ideas that float around. I find that sort of thing a lot more exciting than “VST except open and less crap”, though this admittedly causes some friction with people who want just that. We can do better.

Even if LV2 is not perfect (but what is?), I have the impression from reading all of you that it is still largely good enough. In addition, the developers on the KVR thread (since joined by MuTools, Blue Cat Audio, Surge Synth Team, lkjb, SocaLabs, lmdsp, etc.) could help move the roadmap forward.

LV2 is bound to be saner than the over-engineered, bug-filled and MIDI-hostile mess that is VST3 (as many describe it). The problem is Steinberg. Those calling the shots at this company today have no idea what they’re doing regarding software and do not care. They can’t be trusted.

I happen to produce music with Cubase since its version 2 on Atari (it was in 1990, yes I’m an old geezer). An over-engineered, bug-filled mess is an apt description of what this program has become over the years (not yet MIDI-hostile but it will be eventually, through regressions and misunderstandings). I have a good idea why, but that’s beside the point. In any case, I saw with my own eyes that they are willing to answer “won’t fix” in Jira to obvious, easy to reproduce, bugs that affect core functionality.

I am aware that developers are caught between a rock and a hard place. On the one hand consumers who only take out their wallets for shiny new things, on the other hand big tech and the general IT industry who only think of subjecting the world to their agenda.

This is why we need more standards that are open, stable and universal, as we have with the piano keyboard, traditional scores and MIDI. Hopefully with LV2 too!

1 Like

When I added VST3 support to Ardour I found VST3 concepts rather well thought out.

The VST3 spec addresses many issues that LV2 has nicely (e.g. timestamped parameter automation, variable I/O). MIDI isn’t too bad either, it is just completely different to what VST2 does and relies on the host to map control messages. It’s not a mess, it’s just rather different.

As far as I know, the problem that many have with VST3/MIDI is that they do want keep doing things like VST2, and also remain in control (not delegate CC mapping to the host). The same persons will likely also complain that LV2 doesn’t handle MIDI like VST2 does.

At one point I seriously considered jumping ship and writing VST3 plugins instead of LV2. I actually still am, except I do not like large parts of implementation of VST3 spec (UTF-16, COM protocol, C++ API, async controller,…). The VST3 SDK is indeed a mess, but one does not have to use that.

Generally I agree - I’ve not had too many issues with it. And fundamentally, VST3 seems more Linux friendly than VST2, with a more flexible license in regard to open source - its just a shame that the whole VST2 legacy / developer licensing thing has become entangled with it, and it appears, been handled a little clumsily.
I can appreciate why Steinberg would want to move away from VST2 and shift the ecosystem to VST3, but seeing as how the VST2 SDK hasn’t really (officially) changed much in at least the last decade - I would have thought the better approach would have just been to officially stop maintaining it and just let it gradually fade away through natural, rather than forced obsolescence.
Otherwise there could be a risk of (presumably) trying to protect the value in their IP, by alienating the only people who actually care about it - which would be ironic. Hopefully sanity will prevail - it could just be that this issue has simply been rather hastily or ill thought out.

Just to clarify, I was speaking from a technical point of view.
Regarding licensing and politics I’m very much rooted in the LV2 camp.

1 Like

Please don’t take this the wrong way, but I would like to respectfully point out that OverToneDSP and x42 plug-ins are rather aimed at sound engineers. Therefore, it is possible that you do not take MIDI seriously enough :wink:

From what I understand, VST3 does not respect the serial nature of MIDI that we rely on (for example for composing with continuous controllers — think klangfarbenmelodie but with a single instrument as in acid house, techno and its derivatives — but not only — more examples are given on KVR, things like articulations for virtual orchestra). VST3 does not allow to create MIDI generators (Arne from Steinberg is adamant that VST3 is not going to support MIDI plug-ins). VST3 does not support MIDI Program Change (so much for changing patch with generic MIDI hardware). I wouldn’t be surprised if note-off velocity, poly aftertouch and SysEx are also unsupported.

Furthermore, one cannot rely on the hosts to implement MIDI correctly, unfortunately. The big old ones, Cubase, Logic, DP pretty much do (though among other things they never bothered to think about a practical implementation of CC pairs to get double precision), but none of the newer ones, including Live (without Max For Live), Studio One or Bitwig do it more than superficially (I read somewhere that many new MIDI features were planned in Ardour; I’m looking forward to it!).

This is despite the fact that sales of MIDI hardware are booming and exciting new MIDI instruments have been appearing continuously for the last ten years (even a company like Arturia, which started out in software, has taken to it in a big way).

x42 MIDI Filter Collection , x42 setBfree - ToneWheel Organ, not to mention Ardour’s ACE-fluidsynth plugin, and a coupe of others.

I am also to blame for VST3 support in Ardour incl. MIDI handling. But yes, I’m yet to listen to a song that uses MIDI synths that I do like :stuck_out_tongue_winking_eye:

This is wrong. The entire MIDI vocabulary is mapped, including Program Changes, Notes messages (incl. note-off velocity), Polyphonic Key Pressure, Channel Pressure, Control Changes and Pitch Bend. It’s just that they are not sent as raw binary MIDI messages to the plugin (but neither does LV2). Program Changes are directly mapped to presets for example.

MIDI output is also possible for VST3 plugins, and VST3 plugins can both receive and produce SySEX as well. That is part of the VST3 spec.

1 Like