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

[mr.ardour]

Open Source is really cool in certain ways, it provides a bit of a "democracy" so to speak, and there is just so much code out there now and it has definitely fostered interaction and new ideas to emerge, all cool stuff. but in terms of developing a "standard" so to speak...I personally think the open democracy aspect can become mob rule with a lot of disagreement and chaos as to how it should be done, leading to splintering side versions or at the very least it stalls for a long time while the mob argues about how it should be done, etc..

That's not what happened with the internet RFCs. It's not what happened or continues to happen with the W3C RFCs. It's not what happened with everything about Linux, the most widely used operating system in the world, and thus a de facto standard that inherited from the more committee-led POSIX process.

I'll tell what I see in the audio software community: with a few notable exceptions, almost nobody in this little niche does open source development, and only a few more have any familiarity with Linux. By contrast, those of us (like me) who have been writing audio software primarily for Linux have been forced to familiarize ourselves with the processes and state of play (ever changing) on Windows and macOS, because our preferred platform isn't popular enough among desktop & laptop users for us to really be able to make a living with general purpose software. So whereas we have to understand Windows and macOS so that we can create fully cross-platform software, most audio software developers (not all, just most) really don't have much familiarity with this "other world".

With that as the background, it's extremely frustrating to read comments like

it stalls for a long time while the mob argues about how it should be done

and

personally think the open democracy aspect can become mob rule with a lot of disagreement and chaos

There is no mob rule in the open source world. People do disagree, and if they can't resolve the disagreement, sometimes but exceedingly rarely, a project will fork. There's very little chaos. The closest I can think of is the crazy diversity of Linux distributions, which is only slightly more crazy than the number of DAWs in 2021 But it's still not chaos (in either case): potential users can make informed choices, and there are (in either case) "the big players" which will generally be a good choice for almost anyone.

What the open source world does tend to lack is good marketing. When I implemented JACK back in 2001 it was (and in most ways still is) way ahead of anything to come out of closed source audio software processes, with a nod to Ableton Link for that One Excellent Idea That JACK Forgot). But none of the people interested in JACK were interested in productizing it (just like with LV2), with the result that the the domain of inter-application audio has become somewhat crowded with other, mostly less capable systems, but all of them more user-friendly and "productized" than JACK has ever (and likely will ever) be.

So the problems with open source processes and development don't tend to technical, or sociological; they tend to be that the end up with technically awesome stuff that nobody knows about or can use.

Anyway, I don't know the right solution, I am skeptical that the two biggest DAW's in the world, arguably. (logicPro and cubase) would let hell freeze over before adopting LV2 or any other open source plugin protocol to take over VST or AU.

Given that Logic doesn't support VST, that's likely an accurate assessment. And given that the developers of Cubase control the VST spec, that part is likely accurate also.

All plugin developers need to be able to target those hosts for their plugins, if care about selling it anyway.

That's already been addressed via adapter plugins.

I don't have any hope whatever that the LV2 open source democracy will be able to solidify it into a simple, concise, consistent and reliable protocol which would be stable enough, as a protocol, for big DAW players to consider adding it. We're talking mainly today about: Apple, Steinberg, PreSonus, MOTU, Ableton. Everything else is small time

You don't even mention ProTools, and apparently think Reaper is small time? I've never seen a DP user in the wild, and for every one I see on youtube, I see 10 real life Reaper users. Reaper already supports LV2 (and Justin is even helping to work out some details of various extensions)

Back when we went through the GMPI process, the same objections that you're raising were raised to that as well: ProTools won't use it, Steinberg and Apple won't play along. The consensus among the participants in that process was that we all have to ignore that, and do what we believe is necessary. History will reveal how that turns out.

[S0lo]

If you're only a plugin author, not a host author, the reasons for this might not be clear, but they've been "discovered" over and over again during the last 20-30 years. The model in which the GUI has its own "special" access to the DSP causes lots of problems for hosts (different problems in different hosts, different problems at different times, different problems in different workflows).

Yes, I've never coded a host so I can't speak for that. But before I go further. Let me ask this:

Would these problems still occur, had the plugins followed a correct and well defined protocol/standard of how to access DSP and GUI through the none separated single model?

In other words, would a plugin coded by a guru developer who really knows what he is doing, still create these problems?

[mystran]

Finally, the default (not recommended) method with LV2 and VST and AU APIs is that the DSP and UI run in the same process, with only host-mediated interaction.

As far as I'm concerned there is no DSP or UI. There is only a plugin. It can process audio and it can temporarily attach itself to a window, but it's a single object (as far as the host is concerned, at least).

[Dewdman42]

@mr.ardour, Yea protools deserves a nod too. Reaper already supports lv2 I thought?

All I can say is you’ve had twenty years to come up with a universally accepted plugin protocol and the open source crew hasn’t done it.

Put aside your open source elite programmer mindset, that has not gotten us to where we need to be.

[OBSOLETE160530]

[DELETED]

[mr.ardour]

@mr.ardour, Yea protools deserves a nod too. Reaper already supports lv2 I thought?

That was my point.

All I can say is you’ve had twenty years to come up with a universally accepted plugin protocol and the open source crew hasn’t done it.

Universal acceptance was never a stated or implicit goal with LV2. And as for "come up with a plugin standard that's used outside of the primary product of the company that defines it", well, that we've managed to pull off. Partly because LV2 is the product of a company, and partly because it has been adopted by a number of hosts.

And in doing what's already happened with LV2, we're much further down that road than anything that has emerged from the closed source world of audio software. The "industry sanctioned" effort from 15-17 years ago fell apart before it even got its feet on the ground.

So there's that.

[OBSOLETE160530]

[DELETED]

[mystran]

Finally, the default (not recommended) method with LV2 and VST and AU APIs is that the DSP and UI run in the same process, with only host-mediated interaction.

As far as I'm concerned there is no DSP or UI. There is only a plugin. It can process audio and it can temporarily attach itself to a window, but it's a single object (as far as the host is concerned, at least).

LV2 makes a clear distinction between UI and DSP. They can be single object/binary but also can very well be separate binaries or even completely separate bundles.

LV2 can do whatever it wants. I'm not going to do two separate heap allocs.

[mr.ardour]

Finally, the default (not recommended) method with LV2 and VST and AU APIs is that the DSP and UI run in the same process, with only host-mediated interaction.

As far as I'm concerned there is no DSP or UI. There is only a plugin. It can process audio and it can temporarily attach itself to a window, but it's a single object (as far as the host is concerned, at least).

The thing is, that's just not true in any meaningful technical sense. The host can refuse to ever open your UI. The user can refuse to ever open your UI (ie. use a host provided one instead). The host could load the plugin in two separate processes and create its own communication channel between the two of them. These things are already possible (i.e. implemented by some host, somewhere). And the plugin has no control over them in any way.

[OBSOLETE160530]

[DELETED]

[mr.ardour]

Would these problems still occur, had the plugins followed a correct and well defined protocol/standard of how to access DSP and GUI through the none separated single model?

What we've noticed over the years of developing Ardour & Mixbus is that plugins that come out of companies/organizations/processes/developers who have really "systematized" their development all tend to Just Work (TM). Once you can load one Waves plugin, you can load and run them all (for example). U-he's fabulous instruments ... they just work, all the time. Etc. etc.

The problems tend to show up in two places:

First, relatively new developers or developers that only ever create one or three plugins. This has become less of an issue as more and more people use JUCE, iPlug, DPF etc. to take care of the boilerplate. But people who insist on hand-rolling everything tend to take a while to get things right in all the details.

It is important to note that this is also caused by the lack of clear instructions/SDK's/APIs for host implementation. How many times will we read "well, the plugin works in host X" when dealing with a bug report from users? Logic has taken some fairly loose interpretations of the AU "spec" that are certainly within the range of the reasonable, but you won't find them written down anywhere. I don't blame plugin developers creating an AU from saying "it works in Logic" but I really think we should able to "do better" than that.

Second, sometimes there can be fundamental technology that is solid that gets combined with something new. I won't mention any names, but for example when one excellent plugin development company allowed an effort to port its plugins to Linux, the GUI implementation was (and to some extent still is) pretty wacky. The fundamental DSP side is totally solid, and the GUI itself is similar, but the graft of some new technology took some time to get worked out (some might argue it still needs work, but that's not relevant.

In summary, I would say that in general, you're probably right. But we frequently have read things even in this thread about how wonderful it is that "anyone can write a plugin", and it is often (though not exclusively) this sort of development pathway that ends up giving is headaches inside the host.

[Dewdman42]

There is only so much a couple of developers on their free time can do

exactly!

[ladron]

If you're only a plugin author, not a host author, the reasons for this might not be clear, but they've been "discovered" over and over again during the last 20-30 years. The model in which the GUI has its own "special" access to the DSP causes lots of problems for hosts (different problems in different hosts, different problems at different times, different problems in different workflows).

I'm guessing that most, if not all of these issues were caused by direct write access from UI->DSP. I would also guess that most of the time when you really need the UI to have direct access to DSP data it could be read-only (ie: cases like level meters and visualizing live waveform/spectrum data). At least that has been my experience.

Direct read access, but only indirect write access might be a good compromise.

[mr.ardour]

Direct read access, but only indirect write access might be a good compromise.

I don't know of any portable technology/APIs that could ensure this within the scope of a process. You can mark pages read-only, if the UI & DSP are in the same process, that means the DSP can't write them either.

[ladron]

Direct read access, but only indirect write access might be a good compromise.

I don't know of any portable technology/APIs that could ensure this within the scope of a process. You can mark pages read-only, if the UI & DSP are in the same process, that means the DSP can't write them either.

Yeah, I guess enforcement is a problem. It could perhaps be encouraged by having the contract with the host be that the direct connection is not guaranteed and the plugin still needs to function without it.

In my case, I have DSP code that is sometimes in-process with the UI and sometimes on a completely separate device. When a direct connection between the UI and DSP is not possible, certain features (like an oscilloscope) are not available.