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

[Music Engineer]

LV2 has this split between DSP and GUI too and they point out two other advantages:

-the code for the GUI needs to be loaded into RAM only when the user actually opens the GUI
-a plugin can have multiple different GUIs (not simultaneously, i suppose, but still)

[lkjb]

I understand the separate DSP/UI approach to be thought for more hardware-dependant usage, with SoundGrid or AAX/DSP being good examples. Especially with SoundGrid I think DSP and UI are separated and only communicate via network. SoundGrid runs on a Linux machine, no idea about Avid consoles but Windows Remote Desktop is certainly no alternative. Especially if you only want to display a single plugin.

Steinberg was bought by Yamaha in 2004. When they worked on VST3 (introduced with Cubase 4 in 2006) they might have had console support in mind.

Also, I don't get why GUI/DSP separation is stated as such an issue with VST3. There's SingleComponentEffect which makes all the separation stuff unnecessary. I built ReFine at first based on the VST3 SDK and had no unexpected issues there. According to the good, bad and ugly of LV2, LV2 also uses a split DSP/UI approach but no one seems to care here.

The very successful Rack Extensions also use separate UI/DSP where the UI even has to be written with another language (LUA).

While for "normal" Win/macOS DAWs a single component approach is probably the best option there are certainly use cases where a split might be useful. As of now there doesn't exist a big market, though.

Re XML: I like XML but I mostly use JUCE's XML parser and start struggling as soon as I try to use XML for example in Java. So my use case for XML is probably a bit like JSON with more words.

[x42]

I guess many developers are afraid that switching too a reverse engineered version of VST2 still exposes them to legal threats or other forms of sanctions from Steinberg.

I have received a DMCA notice for https://github.com/x42/lv2vst in June 2018 via github and defended it.

However vestige is just a basic abstract interface, mainly useful for writing hosts. It is not a drop-in replacement that is generally useful for plugin authors. As opposed to the interface, I expect an SDK with implementation could be legally challenged.

Furthermore vestige.h is GPL licensed (it came to be for LMMS), and the original author was not available for comment when I contacted him in 2018, so asking him to re-license it more liberally is likely not an option either.

[Urs]

LV2 has this split between DSP and GUI too and they point out two other advantages:

-the code for the GUI needs to be loaded into RAM only when the user actually opens the GUI
-a plugin can have multiple different GUIs (not simultaneously, i suppose, but still)

Ok, on Linux I guess the "code for the GUI" means large libraries and stuff. But in my world, "the big thing" of UIs are the bitmap assets, which we don't load unless the editor is actually shown. I never thought of code size as a concern in an environment full of samples, wavetables and what not.

Also, we do multiple different GUIs without any separation at all. I don't even know why those two things would be connected in anyway.

Anyhow, I totally get how it's a "good to have" in theory, but practically, with the visual feedback people expect these days, 60Hz large animated waveform views on high resolution displays and stuff, I'd consider enforcing separation a design flaw.

[x42]

While I am a huge fan of LV2, I don't think it's the answer to the problem that is being discussed here.

It is "yet another plugin SDK". For devs it means more development, more testing, more resources, more support issues, but no new value [1].

However If it turns out that a new SDK is needed, it is the obvious choice. LV2 is mature, liberally licensed, hosts exists and it's relatively painless to port existing VST2 plugins. https://gitlab.com/lv2/lv2kit is nearing completion, too.

--

[1] There are few nice things LV2 can do which other standards cannot. e.g. additional inline-UIs. but those are LV2 specific and the same plugin in other formats won't have them. Hard to say if those features add value.

[Urs]

Also, I don't get why GUI/DSP separation is stated as such an issue with VST3.

IIRC the main issue was that sending or requesting data was asynchronous. Our UIs weren't guaranteed to receive the information on the process it needed, when it needed it. That's because, due to the modular nature of our codebase, much of the information about a plug-in exists at runtime, not at compile time, i.e. it's built up programmatically.

[Music Engineer]

It is "yet another plugin SDK". For devs it means more development, more testing, more resources, more support issues, but no new value

well, as i wrote already in another comment: i don't really see it as just "yet another plugin format". at the moment, it's the only available viable non-proprietary format unencumbered by licensing restrictions. this is an important unique selling point for me

[No_Use]

Furthermore vestige.h is GPL licensed (it came to be for LMMS), and the original author was not available for comment when I contacted him in 2018, so asking him to re-license it more liberally is likely not an option either.

There's a follow-up project to the vestige project, it's also GPL though.
https://git.iem.at/zmoelnig/FST

[x42]

Ok, on Linux I guess the "code for the GUI" means large libraries and stuff.

Not quite. Most plugin Linux UIs in the last 6-7 years just use simple openGL canvas and render on RGB[A] textures. Cross-platform UI development is converging more and more (thanks to openGL, vulkan, metal and respective abstractions thereof).

The "big" toolkits (gtk, qt) do not offer anything relevant for plugin UI development and are problematic in various ways, but that is an entirely different story.

I'd consider enforcing separation a design flaw.

Note that you do not have to separate LV2 UIs and DSP. They can co-exist in the same .dll .so .dylib and also share memory (https://lv2plug.in/ns/ext/instance-access).

[Music Engineer]

Note that you do not have to separate LV2 UIs and DSP. They can co-exist in the same .dll .so .dylib and also share memory (https://lv2plug.in/ns/ext/instance-access).

ok - nice. good to know. so, you can have the separation, if you want it, but it's optional. sounds like the best of both worlds to me.

[Urs]

[S0lo]

A vst2 to vst3 wrapper?.

If that's what you mean, I've got one and so have others.

The way it works is that it presents a vst2 plugin to the host and then it loads a vst3 plugin and the vst2 opcodes are translated to vst3 calls.

Translation between vst2 and vst3 and vice versa is not that hard because as I said in my previous post there are enough vst2/vst3 core similarities to do it at least in a vst2 sort of way.

Yes thats exactly what I meant. EDIT: Actually I meant the opposite. ie. VST2 code compiles to VST3 binary. And the opcodes are translated. The host is presented with a VST3 plugin.

Sure I know the concept but I never got to doing it. Every time I delve into VST3 a bit, after half an hour I quit and say to my self "I don't wanna wast time on this".

Did you get to wrap VSTGUI too? to me thats seams a bigger obstacle. It's about 9 to 10 times larger than VST 2 and I use it extensively.

[lorcan]

I don't know the guts and gizzards of TDM plug-ins, but native AAX plug-ins are still guaranteed to run UI in the same process as their (native) DSP part. UAD plug-ins still have a native DSP part which passes audio and data back and forth to their external DSP. They manage just fine without the separation of UI and (native) DSP part of a plug-in spec.

AAX Native does have an option for 'monolithic' which forgoes the separation, but the recommended approach is to use SetCustomData()/ GetCustomData(), which essentially costs a memcpy.
UAD hides it from you by doing a copy to/from DSP under the hood. Well it's a bit more elaborate than that but can't say more as all this stuff is under NDA.

I even think that there's a reason that the vast majority of plug-ins shares data between UI and (native) DSP part. It is the complexity of the separation that developers would rather avoid. If you wanted to keep the number of plug-ins very low for a given format, you just need to enforce the strict separation of UI and (native) DSP part. I believe it's the single most effective way to make a plug-in format unsuccessful.

AAX/AU/VST3 all recommend or enforce this separation, those formats are hardly 'unsuccessful'.

Really I don't understand what all the fuss is about, there's quite a lot of resources out there explaining why should hold a lock, copy data and release immediately, or use lock-free stuff etc.
Of course sprinkling mutexes everywhere might work, but it will hurt performance.
And as a last resort VST3 has had a single-component effect option (no separation) for some time now.

As for Rosetta, I think it would be awesome luck to find a plug-in that has its UI ported to Apple Silicon while the DSP part is left behind on Intel, or vice versa.

I don't know the internals of Logic Pro X, I was talking about them using separate processes for ARM/Rosetta plugins. I believe the UI is not necessarily running in the same process as the DSP also.

As for dummy plug-ins, I might not quite understand what you mean.

A plug-in which just acts as a graphical interface to some remote DSP. Something akin to what Avid did that with their Carbon audio interface. You can instantiate an HDX plugin for low-latency live tracking on the DSP, then move it to host/native at a flick of a switch, thus freeing resources for the next track take.

[mr.ardour]

The value of XML has nothing to do with the actual format. It's simplythat it's an extremely well defined specification, with extremely clear semantics and syntax, and with very mature libraries for parsing it, and the ability to put pretty much whatever you want in the file without breaking the format.

JSON overlaps this feature set substantially, but in terms of the code that actually uses whatever was in the JSON or XML file, there's really not going to be much difference.

We use XML in Ardour (and thus Mixbus) not because we love it or think that it's awesome. We use it because it gets the job done, it never breaks (for the wrong reasons), and we don't have think about it. JSON would probably buy us the same features, mostly.

[mr.ardour]

Today it would be weird to do that since everything moves towards sandboxing.

Not Ardour !

I fully explain why Ardour will never (well, never is a long time, but ...) implement plugin sandboxing here: https://ardour.org/plugins-in-process.html

Disagreement with the rationale laid out here is fine, but I see a lot of people who don't seem to actually understand the issues surrounding this matter.