Well this is a kick in the nuts: VST2 plug-ins

[Urs]

I think it pretty much boils down to the learning curve of a format. Is it more like VST2 (open example project, build, go) or is it more like VST3 (“what is all this, where is MIDI?”)?

I am not a small 1-3 person plug-in developer anymore, but if I was, I’d ask myself: Is scanning all plug-ins in only 0.1s really worth having to learn, deal and debug some obscure looking file format? What advantage does this bring to the platforms that most VST developers work on? I can imagine that a lot of this - extensions, turtle, concurrent concepts - looks like baggage that is somehow related to Linux or the project history to many. There’s just a lot to take in, and there are not many answers to my questions out there.

I think what can’t be neglected is that many plug-in developers are just not interested in “going deep“ about a format, and LV2 might just have too many unknowns to successfully replace VST. Yes it’s already there, it can do everything that we need, but doesn’t it somehow suffer from the same kind of “being too much” that has slowed VST3?

I am super biased though, because we already had LV2 support once and never went through with it because of support concerns (“can’t estimate what is coming upon us... too many chances to crash... too risky”). Instead, we helped bring VST3 to Linux. That was years ago though and audio on Linux has come a long way. Things might be different now.

Nevertheless, while I’d be happy to give LV2 another try, we’re currently evaluating a different solution which we think has more potential to work out, but it doesn’t have a proper name yet. We’ll see.

[Blue Cat Audio]

I think it pretty much boils down to the learning curve of a format. Is it more like VST2 (open example project, build, go) or is it more like VST3 (“what is all this, where is MIDI?”)?

I am not a small 1-3 person plug-in developer anymore, but if I was, I’d ask myself: Is scanning all plug-ins in only 0.1s really worth having to learn, deal and debug some obscure looking file format? What advantage does this bring to the platforms that most VST developers work on? I can imagine that a lot of this - extensions, turtle, concurrent concepts - looks like baggage that is somehow related to Linux or the project history to many. There’s just a lot to take in, and there are not many answers to my questions out there.

I think what can’t be neglected is that many plug-in developers are just not interested in “going deep“ about a format, and LV2 might just have too many unknowns to successfully replace VST. Yes it’s already there, it can do everything that we need, but doesn’t it somehow suffer from the same kind of “being too much” that has slowed VST3?

I am super biased though, because we already had LV2 support once and never went through with it because of support concerns (“can’t estimate what is coming upon us... too many chances to crash... too risky”). Instead, we helped bring VST3 to Linux. That was years ago though and audio on Linux has come a long way. Things might be different now.

Nevertheless, while I’d be happy to give LV2 another try, we’re currently evaluating a different solution which we think has more potential to work out, but it doesn’t have a proper name yet. We’ll see.

A stupid-simple VST2-like API (cleaned up and better specified) would indeed probably have more chances to be adopted, and it would be more likely to be stable over time (because a similar API has been here for so many years, so we all know most of the issues related to it already). The success of VST as a de-facto "standard" when it all started is probably that it was a piece of cake to write a simple plug-in compared to other formats such as DirectX. Also it is straight C, so it is compatible with all possible languages, and can be read quickly without having to understand complex concepts.

Also, porting existing plug-ins, hosts and frameworks to such an API would also be quite simple. Starting from scratch is rarely a good idea.

[mystran]

I am not a small 1-3 person plug-in developer anymore, but if I was, I’d ask myself: Is scanning all plug-ins in only 0.1s really worth having to learn, deal and debug some obscure looking file format? What advantage does this bring to the platforms that most VST developers work on? I can imagine that a lot of this - extensions, turtle, concurrent concepts - looks like baggage that is somehow related to Linux or the project history to many. There’s just a lot to take in, and there are not many answers to my questions out there.

It also seems LV2 has some of the same issues that VST3 has, like insisting on the whole "plugin vs. UI separation" thing backwards: it expects you write a plugin and then provide an UI. It has a "strongly discouraged" extension (ie. instance access) for actually letting the two to communicate together in a reasonable fashion, which "plugins should not expect hosts to support" and the provided communication mechanism only talks about pushing around single floats or audio peak measurements?

This shows that whoever came up with the spec is totally disconnected from reality. Whole classes of interesting plugins are just not realistically separable in this way. [edit: And no, it is not acceptable for a commercial plugin to specify in some manifest that the host should ignore the plugin if it can't support whatever the plugin wants, because the bare minimum you need to be able to give you poor user is an error message that makes it reasonably clear what the issue is!] This doesn't mean separation as such is bad, but at least give me a stupid shared memory segment, because the last thing anyone wants to do is rely on a random host to do something sensible when it comes to pushing around non-trivial data.

[OBSOLETE160530]

[DELETED]

[Urs]

Which brings up the question whether the strict separation creates more crashes than it resolves - where do those crashes come from that make this separation so desirable in the first palce?

I am nearly a 100% certain - even though I did not write the code - that the reason we had a dodgy initial release of VST3 versions and a full on rewrite of the whole layer years later, because the UI separation thing caused more problems than necessary and it did not resolve the issue of very, very painful interpretation of documentation. It initially worked in exactly one host just fine, until more hosts came about and suddenly that one host changed the way it did things and broke it all. Vital information (e.g. what call was allowed in which thread and what order was expected) was hidden at the time, i.e. buried in non-obvious places.

What I'm saying is, any added complexity invites an exponential amount of bugs. Added complexity also makes documentation harder to find, and it requires to read the documentation with a bigger picture of the whole API.

Instead of adding complexity that "makes crashes easier to live with" I think it would be better to address the reason for crashes in the first place. And that IMHO is minimising complexity, making things utterly easy, and adding absolutely sound and clear documentation that is easy to find, with good examples for commonly used UI toolkits such as VSTGUI and JUCE.

LV2 has a good chance to take off still, if someone was gonna make a "cleaned up" Gain/Monosynth example project (or CMake, whatever) for VS/Xcode using VSTGUI and/or one of the other common libs which can put VST2 developers in the driver seat instead of sending them back to driving school first.

[Kott]

Maybe you find this useful:
VST3 implementation: https://github.com/ryukau/VSTPlugins
LV2/VST implementation with DPF: https://github.com/ryukau/LV2Plugins

I never did build LV2/DPF plugins on Windows (while on Linux it's easy as 1-2-3) I think falkTX can say how well is it ready or not

[OBSOLETE160530]

[DELETED]

[OBSOLETE160530]

[DELETED]

[hibrasil]

Don't think Jules is with JUCE anymore after the iLok buyout. He's now focused on SOUL.

Now iPlug might be a good thing to check out if Oli would be interested.

Poor Oli!

"We know you were out of the room, but we all voted and you're now adding LV2 support to iPlug2!"

I'm sure there's somebody who's interested enough to add it, however. Just a matter of finding them.

Significant work has been done on Linux/LV2 support for iPlug2.

https://github.com/iPlug2/iPlug2/tree/linux

We have had a couple of dedicated contributors, but I could really do with some more help from people who use Linux regularly and know the intricacies of getting plug-in UIs working nicely there. If anyone sees this and would like to help, please get in touch.

iPlug was originally built on top of VST2, and it would probably be very simple to add support for a new VST2-like format, I would do it, if such a thing emerges.

[Urs]

It is not just about the crashes and nasty things UIs can do.

I understand.

Those problems are of course less relevant on Win and macOS, even if latter had its grief inflicting transitions over the years.

I really don't know much about the odds of Linux development, all those different windowing systems and toolkits are nothing I can or wish to comprehend, and I too found it somewhat odd that our context menus need to open a different app.

Which reminds me that as I said earlier, what made the separation unbearable for us in VST3 was the asynchronous nature of the message system between UI and DSP, and - back then at least - its documentation. I don't mind separation if it's well done, if roles and responsibilities are clear, if redundancies are avoided and if real world examples (e.g. sample transfer) are still possible.

[OBSOLETE160530]

[DELETED]

[x42]

Which brings up the question whether the strict separation creates more crashes than it resolves - where do those crashes come from that make this separation so desirable in the first palce?

It's not usually crashes, at least not direct ones. Sharing memory between threads with different runtime priorities is hard, even for good programmers. Lock-free atomic operations, concurrency issues and interfering with a realtime threads from the outside are tricky, especially on macOS and Linux/X11 where there are thread semantics for the UI thread as well.

This is not something new plugin-dev should concern themselves about. Besides, clean code separation is generally preferable.

Another aspect is that one can have multiple UIs. The plugin could run headless on a pedalboard or embedded system eg. MOD, or ELK, or one could use a remote tablet to control desktop plugins.

[mystran]

I really don't know much about the odds of Linux development, all those different windowing systems and toolkits are nothing I can or wish to comprehend, and I too found it somewhat odd that our context menus need to open a different app.

This was more of an issue of LV2 being too liberal in what toolkit you could make plugin UIs out of.
Now everyone is pretty much in agreement that big toolkits like gtk and qt are a big no for UIs.
If they are used, they need to be statically linked.

Right. That's the state of things on other platforms too: use toolkits specifically designed to work in plugins. I've written some GUI code directly against X11 though, so I feel the pain of trying to work within an ecosystem where everything is built on the assumption that you're going to use some toolkit istead.

[mystran]

I cant comment on how VST3 does things, I do not know. On LV2 the async elements are very clear, due to obvious rules:
1. plugins can only access their port contents during run(), so DSP->UI messages must happen there.
2. if there is anything that is expensive to calculate and cant be done in RT but needs to be in sync with audio, the "worker" extension is there for that.
3. UIs receive events through the host in their main thread
4. UIs call into the host to send events to the DSP side, which will be received during next run()

The most obvious case where this is not ideal is when you want to display something like a spectrum analyzer for the audio in the GUI. If you have an analysis window of say 16k samples (and you might even want more than this) running at 44.1kHz then that's a bit under half a second: you don't really want to send this much data on every audio callback. On the other hand, you always want the latest 16k samples available for the GUI so sending just the new data over an unreliable transport doesn't work either (because if the GUI isn't running, we don't want to drop the new data, we want to drop the old data instead).

This is relatively simple to do with minimal copying using ring-buffers and some atomic ops. Wait-free and lock-free. If you get it wrong you'll get more visual glitches than you should, no big deal [edit: meaning "it doesn't crash" even though obviously such glitches should be fixed]. How do I implement this using the standard LV2 core functionality?

[OBSOLETE160530]

[DELETED]