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

[EvilDragon]

As long as it's an option it's good. A bit of performance loss is often preferable to losing project state if a plugin crashes the whole host while misbehaving.

[mr.ardour]

Can't we ask / persuade the MMA to setup a music plugin format, just like they created MIDI?

We already tried this in the early 2000's. It was called GMPI (General Music Plugin Interface). I am suprised it has not been mentioned here so far.

The effort to define GMPI was started by Ron Kuper (then at Cakewalk), who convinced the MMA to "sponsor" the effort. There was an initial meeting at NAAM (Anaheim). (Almost) everybody was at the initial meeting. Steinberg refused to allow consideration of VST becoming the basis for GMPI, insisting that they must retain control (Arne was in the room). That was a real possibility for a little while. Apple sent one of the lead AudioUnit devs, who said "we did all this over the last few years, and AU is the result, and we're absolutely not doing it again." Digi didn't show up, the only notable name in the DAW/plugin world not to attend. Hey, even I was there!

The specification was finally finished after months of mailing list activity, then the MMA said "great, now we're doing an implementation behind closed doors", and everybody ran screaming from the room. GMPI was never heard of again. Please do not ask the MMA to do this again.

LV2 was created with many elements of the GMPI specification in mind. It did not follow every detail, but definitely captured a lot of the consensus from that period (see here for a complete review of this: https://lv2plug.in/gmpi.html

[mr.ardour]

As long as it's an option it's good. A bit of performance loss is often preferable to losing project state if a plugin crashes the whole host while misbehaving.

I respect the disagreement, but I continue to disagree. The engineering of correct sandboxes is hideously complex, and it exists overwhelmingly to deal with a single problem: plugins that crash. There are inter-application audio routing solutions (such as JACK and other similar systems) that can be used without requiring this sort of engineering in the host (which just sees a regular in-process plugin).

Also, we're not talking about performance loss. The issue is the impossibility of scaling this idea to large scale sessions.

[milkmiruku]

https://github.com/lv2/lv2/wiki

https://gitlab.com/lv2/lv2/-/tree/master/lv2/core etc.

Justin Frankel came into #lv2 and #lad on freenode and negotiated a proposal for a new non-core LV2 extension for an interactive inline display not too long ago https://github.com/justinfrankel/reaper ... embed_ui.h

[ghettosynth]

We already tried this in the early 2000's. It was called GMPI (General Music Plugin Interface). I am suprised it has not been mentioned here so far.

Interesting story.

[milkmiruku]

https://lv2plug.in/gmpi.html

Edit; missed the link at the end of the post above!

[FigBug]

https://lv2plug.in/gmpi.html

Plugins must not be expected to support dynamic sample rates. The sample rate must be set very early in the life of the plugin and not changed.

All looks sensible except this. Does that mean if the user changes their sample rate, you need to reload all the plugins?

[milkmiruku]

Idk, one could try asking in #lv2. I've also been advised by falktx that page is a bit out of date.

Edit: link to webchat on https://libreav.org/

[Urs]

I think I made a mistake. What I'm really going on about is synchronous vs. asynchronous data transfer. By dissing "separation" I was being too general when in fact I only dislike asynchronous models of passing complex data between UI and DSP.

Please let me rephrase:

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

With the exception of VST3, data can be passed synchronously in these formats without the UI calling in to the native DSP part directly. In VST3, from what I understand, one can not. For that reason I assume that vast majority draw the single component option in VST3, essentially making it a non-separated format in most cases, due to a design choice.

Both AU and the remaining format have a pull model, something like getDataBlobNow( int BlobID, void* datPtr) which returns the requested data from the DSP part to the UI immediately. VST3 afaik has a model akin to requestDataBlob() upon which, some time later something may call hereIsYourDataBlob( void* ptr ).

Furthermore, correct me if I'm wrong - I wrote our AU layer almost two decades ago - if you call getProperty() in the UI, the current content of the allocated memory is copied to the AU when it's supposed to fill the memory. The same principle apparently works in our other layer that we're NDA'd about. I forgot what we used that for, but I'm sure it worked. Not sure if we still do that and if it does. In VST3 to my best knowledge this isn't possible, and it informed my view on the hurdles of plug-in design.

Hence, sorry if I wasn't clear enough. Separation between UI and DSP itself isn't the issue IMHO and should be enforced by API design. However, adding the complexity of handling asynchronous transfer of data blobs is very difficult for plug-ins which have more complex parameters than just float and int, e.g. which rely on runtime evaluation to create their UI dynamically.

[macunix]

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.

I don't think separate GUI/Processor features are the problem, it's how Steinberg used COM to implement it (and other things) that leads to bloat and poor documentation etc etc.

[macunix]

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.

It's probably possible but I think Steinberg wouldn't like it.

[mr.ardour]

https://lv2plug.in/gmpi.html

Plugins must not be expected to support dynamic sample rates. The sample rate must be set very early in the life of the plugin and not changed.

All looks sensible except this. Does that mean if the user changes their sample rate, you need to reload all the plugins?

Not reload. Reinstantiate. Totally different things. You don't unload/load the shared object(s) corresponding to the plugin (DLLs). You call a "teardown" method on the existing plugins, and then an "instantiate" method to recreate them all, with the same state as before (except for the new sample rate).

Real world workflows do not involve frequent sample rate changes.

[Markus Krause]

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.

I agree with Urs. It is badly designed. It is getting an issue with

- more complex plugins
- plugins with animated realtime-displays like waveforms
- plugins that come with an own preset-manager

Steinberg says 'it is not an issue' because there is a single-component example in the SDK (v3.7) but

- the single-component example of the SDK does not support VST 2.4
- the single-component example of the SDK does not work as AU (no audio output)
- the single-component example of the SDK is completely messy and very difficult to understand. I needed one month to sort, fix and rewrite the code to build an own empty project from it

I also agree with the the point where Urs said "Steinberg made VST3 so complicated to slow down plugin-development of this format intentionally". And they got a reason for this: They want to sell they own plugins

[fese]

I also agree with the the point where Urs said "Steinberg made VST3 so complicated to slow down plugin-development of this format intentionally". And they got a reason for this: They want to sell they own plugins

“never attribute to malice that which is adequately explained by stupidity”
https://en.m.wikipedia.org/wiki/Hanlon%27s_razor

Anyone who has ever written code, hands up who really honestly can say that he has never programmed/designed something that was more complex than necessary for the task at hand, for whatever reason (“what if in the future...”, “I learned this cool new technology...”, “look what a brilliant programmer I am”).

[Blue Cat Audio]

Separation between UI and DSP itself isn't the issue IMHO and should be enforced by API design.

I would tend to disagree with you here. I think a plug-in API should be only a communication protocol between a host application and a plug-in component (I=Interface).

While GUI/DSP separation is a good practice, it may not make sense for all cases, or at least be implemented differently depending on what the plug-in is doing. All attempts so far to try to enforce a structure by a plug-in API resulted in monsters such as VST3 (and there are other cases I cannot talk about here because of NDAs). It always causes way too many problems for both hosts and plug-ins, just because most of them will not fit into the box (you cannot make it flexible enough), and enforcing a structure also adds way too many constraints on both sides.

A communication protocol such as a plug-in API should remain simple, with as few data structures and functions as possible, and be as much language agnostic as possible. If you have to read the entire documentation just to write a very simple plug-in, and make assumptions or guesses in which order/threads functions may or may not be called to avoid crashes or undefined behavior, then it sounds like a failure to me.

A protocol defines how two components should communicate with each other (precisely), but not how they should be implemented (at all).

What drives me nuts is that an audio plug-in remains a fairly simple concept compared to many other computer systems/software. And yet most APIs are an incredible mess that can be interpreted in so many ways that you won't find 2 manufacturers that understood them the same way!