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

[Guillaume Piolat]

well, i mean, if those things change at runtime. for example, when the user adds a new eq-band and the plugin therefore gets a few more parameters. i think, it's a somewhat complicated way to communicate such changes to the host via a generated string in some weird format. but hey - at least, it's possible at all - which wasn't the case in vst2 (if i'm not mistaken)

Yes: you would implement the extension https://lv2plug.in/doc/html/group__dynmanifest.html
Some important extension made core: UI, URID, Presets...

[S0lo]

A simple solution would be a VST3-to-VST2 adapter. So instead of delivering a VST2 plug-in, those developers could license an adapter which exposes their VST3-plug-ins as VST2 ("Plug-In XY now comes with VST2 adapter by Z, because we don't do VST2 anymore"), much like 32Lives. However, that model is doomed because whoever builds such an adapter will also lose their option to do so soon.

IIRC Previous versions of VST3 actually contained a compile time VST3 to VST2 adapter/wrapper!!, before Steinberg removed it. The thing is this only solves half of the problem. The other half being that years of legacy code would still have to be ported to VST3. This is more complicated by the fact that VSTGUI 4 (which comes with VST3) is NOT compatible with VSTGUI 3 (which comes with VST 2).

What I would have wished for in addition, is the opposite. An adapter/wrapper from VST2 to VST3. With VSTGUI porting included. I believe these two, two way adapters would have solved 90+% of the issues we have today. Legacy VST 2 code would still compile as it is and produce VST3 binary (And VST2 binary without the adapter if they signed the license). While new comers and other capable developers may choose to begin from scratch with VST3 and produce VST3 binary (and VST2 binary with the first adapter if they signed the license)

[Urs]

What I would have wished for in addition, is the opposite. An adapter/wrapper from VST2 to VST3.

Or, something as simple as step-by-step guide about porting VST2 to VST3.

[Urs]

We actually had LV2 alphas/betas back then when abique started our Linux port. Not sure how stable they were, but they surely weren't as overly complex looking as the other formats.

[Markus Krause]

What I would have wished for in addition, is the opposite. An adapter/wrapper from VST2 to VST3. With VSTGUI porting included. I believe these two, two way adapters would have solved 90+% of the issues we have today. Legacy VST 2 code would still compile as it is and produce VST3 binary (And VST2 binary without the adapter if they signed the license). While new comers and other capable developers may choose to begin from scratch with VST3 and produce VST3 binary (and VST2 binary with the first adapter if they signed the license)

This!

[macunix]

(e.g. VST3 is designed on the premises that MIDI would somehow "go away", but obviously MIDI hasn't died, to the contrary, MPE and MIDI 2 have come about)

Exactly. That is a major design-flaw.

Further design-flaw: It has been designed to run GUI and Audio on separate computers. This is completely senseless, doesn't work well for more complex plugins and wastes performance. It is an unnecessary limitation that complicates programming a lot and opens a can full of worms.

It also has a bad documentation, doesn't come with proper examples, has lots of bugs and is very messy. A massive number of sourcecodes are scattered all over the place.

As Urs said: Steinberg continuously ignores the problems.

My impression is that the responsible programmers are lazy and do not care about it at all - since Steinberg depends on them and they get their money

I don't know if anyone uses the GUI and Audio separation.

I assume that the GUI and Audio separation feature is the main reason why the COM and factory models were chosen which makes the VST3 SDK more complicated than it probably should be.

Steinberg recommends not to join the GUI and Audio components together but at least some Daw Hosts do as far as I know, confusing!.

IMO, how the GUI and Audio separation feature is implemented is basically useless for IPC (interprocess communication) where GUI and Audio separation might be useful.

Once the COM and factory stuff is peeled back, the actual VST3 code is laid out in a similar way to VST2 with a few more features added.

Daw Host and Plugin communication has basically the same needs no matter what the SDK format is, it needs to be fast.

The VST3 SDK has great chunks of hidden things and it takes ages to dig down to the roots and when it is, it turns out to be not that different to VST2.

The VST3 SDK is very very very poorly documented and not very clear.

[Urs]

I think UI and DSP separation was something to think about before, say, 2012. The idea was distributed computing to preserve CPU.

Today it would be weird to do that since everything moves towards sandboxing. Having one plug-in separated so that it runs in two separate sandboxes goes against sandboxing and is certainly prone to systemic bugs. Plug-In and its UI should run in the same environment, much like many hosts do already today when they sandbox plug-ins in their own processes.

If there is any need to distribute computation of plug-ins across many machines, there's no real need to separate the process from its UI either. If you need the UI, you run the plug-in locally. When you close the UI, the hosts stops local processing of the plug-in and transfers the state to an external renderer, where it continues.

[macunix]

A simple solution would be a VST3-to-VST2 adapter. So instead of delivering a VST2 plug-in, those developers could license an adapter which exposes their VST3-plug-ins as VST2 ("Plug-In XY now comes with VST2 adapter by Z, because we don't do VST2 anymore"), much like 32Lives. However, that model is doomed because whoever builds such an adapter will also lose their option to do so soon.

IIRC Previous versions of VST3 actually contained a compile time VST3 to VST2 adapter/wrapper!!, before Steinberg removed it. The thing is this only solves half of the problem. The other half being that years of legacy code would still have to be ported to VST3. This is more complicated by the fact that VSTGUI 4 (which comes with VST3) is NOT compatible with VSTGUI 3 (which comes with VST 2).

What I would have wished for in addition, is the opposite. An adapter/wrapper from VST2 to VST3. With VSTGUI porting included. I believe these two, two way adapters would have solved 90+% of the issues we have today. Legacy VST 2 code would still compile as it is and produce VST3 binary (And VST2 binary without the adapter if they signed the license). While new comers and other capable developers may choose to begin from scratch with VST3 and produce VST3 binary (and VST2 binary with the first adapter if they signed the license)

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.

[Markus Krause]

I don't know if anyone uses the GUI and Audio separation.

I assume that the GUI and Audio separation feature is the main reason why the COM and factory models were chosen which makes the VST3 SDK more complicated than it probably should be.

Steinberg recommends not to join the GUI and Audio components together but at least some Daw Hosts do as far as I know, confusing!.

I agree with you and URS. It may have been a nice feature in the year 2000. But times have changed since then. We got enough CPU power and distributing GUI and Audio across machines does not longer make sense at all.

I did do measurements across DAWs. None except Cubase separates GUI and Audio for VST3 at all.

[lorcan]

I did do measurements across DAWs. None except Cubase separates GUI and Audio for VST3 at all.

Sure .. ever heard of AAX DSP, UAD plug-ins or Waves Soundgrid for example ?
Also be prepared for a few surprises with an x86 build of a plug-in running inside Logic on Apple Silicon .
Audio/UI separation allows for other niceties such as exporting your plugin's UI on a touchscreen of some hardware control surface, or the other way round, a PC editor for some hardware like this.

[Markus Krause]

No sure what exactly you're referring to.

None of our customers has asked for such an application during the last 15 years. Instead we get a lot of requests for Midi-learn support - which isn't possible without dirty hacks on VST3.

control surfaces with Midi or Automation are around for decades. If you use USB or Midi or bluetooth or TCP/IP you don't need VST at all. You can send and receive any data you like across distributed devices. It also works fine with VST 2.4 - which doesn't have a separation between audio and GUI. Juce, which seems to be used by the majority of the plugins, also connects audio and GUI with a pointer to bypass the COM model of VST3.

[EvilDragon]

Just because your customers haven't asked for such an application, doesn't mean there isn't a whole other userbase directly depending on separate GUI/controller implementation (and indeed AAX DSP is probably the best example of that).


Personally, in broad general terms, abstracting the MIDI out of the equation makes sense in the grand scheme of things, but the way Steiny has done it is not as good as it could have been, since it completely neglects a number of important MIDI workflows and doesn't provide a suitable workaround.

[Obsolete187521]

[DELETED]

[KenjiDeVries]

I would like to offer my take as a musician on this.

The xml files used by UVI Falcon and UVI Workstation have saved my ass many times, allowing me to understand them and then edit the path of wav files that had changed location (better organisation, new hard drive, new computer… Many reasons).

The xml files used by Cubase have saved my ass many times, allowing me to understand and correct them to get what Cubase bugs prevented me from getting.

There's a lot of value in that. So unless there is another file standard that is also human readable and editable in a basic text editor, I vote for all my files to be in xml format!

+1. Easy human readable and extensible.

Further more, why would someone mess up preset XMLs on purpose? What's the benefit of making the parser go crazy?

[Music Engineer]

I would like to offer my take as a musician on this.

The xml files used by UVI Falcon and UVI Workstation have saved my ass many times, allowing me to understand them and then edit the path of wav files that had changed location (better organisation, new hard drive, new computer… Many reasons).

The xml files used by Cubase have saved my ass many times, allowing me to understand and correct them to get what Cubase bugs prevented me from getting.

There's a lot of value in that. So unless there is another file standard that is also human readable and editable in a basic text editor, I vote for all my files to be in xml format!

yes - from a usability perspective, i think, xml is totally fine. the issue seems to be with security - as in vulnerability to attacks when someone manages to inject a malicious xml file somewhere (and the parser implements no safeguards). perhaps i should be worried, if i had a preset sharing community or something like that. one other popular format to store state data is JSON - i don't know, if that's better in this regard. btw. long ago, i made a little tool to batch-process a bunch of xml files:

http://www.rs-met.com/misc.html

so maybe, if you have to edit a whole lot of xml files next time, you don't want to do it manually anymore. one could surely do the same things and much more with a little commandline script - but not everybody likes commandline interfaces (i certainly don't)

Further more, why would someone mess up preset XMLs on purpose? What's the benefit of making the parser go crazy?

none. but maybe some people just like to see world the world burn. i don't understand such a mindset either ...we have a word for that in german: "schadenfreude" - literally: "damage joy" or something. certainly one of of the more deplorable human behaviors