What plugin-format do you prefer?

[TheMaestro]

I hate standalone versions. I need access to my DAW's features.
Reaper takes about 1.5 seconds to fire up and be ready, and another 3 seconds to find and fire the VST.

[fedexnman]

I chose VST 2 64 to be honest most plug-ins are not VST 3 yet so I didn't chose that option .

[BONES]

Why does it matter if the plugins work OK now?

Because of, let's say, performance and features.

How does that work? Computers get faster so a high-CPU plugin today will barely trouble your CPU in a few years time. And if a plugin has all the features you need today, it will still have all those features in 50 years time. After all, it's not like there has been a whole lot of innovation in the last 50 years, given that we still covet Minimoog emulations as much as we do anything new and different. And how long do you need to have any particular plugin for before you feel you've got your money's worth from it? It's very likely you ill have stopped using it long before it is actually obsolete.

I hate standalone versions. I need access to my DAW's features.
Reaper takes about 1.5 seconds to fire up and be ready, and another 3 seconds to find and fire the VST.

If that's true, you must choose pretty krap plugins because I only require my host when it comes time to put an instrument into an arrangement. If things were otherwise, how would anyone ever use hardware synths?

[jamcat]

When I just want to play piano for enjoyment I open up the standalone of Pianoteq.
Don't really do that with synths, though.

[Teksonik]

I chose VST 2 64 Bit mainly out of habit but have no problem with VST3 plugins other than the mandatory install location (in the Program Files folders).

[LeVzi]

If I just want to play a synth I don't need a standalone, you can use Tone2's nanohost and run the DLL in that ? That's how i've done it since that piece of software came out. Makes the need for a separate standalone app redundant imo.

And surely apart from existing plugins, all dev's should be looking to move to VST3 ? Before you know it, VST4 will be around and moving to that will be the norm.

[Markus Krause]

This is a valid point. VST3 is here for longer than a decade, but VST 2.4 is still the most popular plugin-format. Once VST4 is available the VST3 format will be neglected quickly - most likely more quickly than 2.4.
We plan to support VST3 in the future, but it is not because it is technically necessary or has significant advantages from the feature-set. The true reason is that potential customers could think that the products are 'outdated' when VST 2.4 is used, because of Steinberg's marketing-campaign against 2.4.

[WatchTheGuitar]

I hope in a (putative or really on its way?) VST4 there's going to be some way to link to MIDI 2.0 so it could understand a program change message that passes the actual name of the bank and preset you want on the given synth rather than a couple of 7 bit values.
If the MIDI is readable to more than spods like me then there's a higher chance more DAWs will include proper MIDI event editors rather than the crippled automation tools we're forced to rely in within most of them these days.

[jamcat]

Legit question: why would we need some as of yet undefined VST4 instead of just an update to the VST3 spec to incorporate new features in the future?

I think with VST2, the way certain things were handled (such as automation resolution and I/O handling) precluded changing it without breaking existing software, and changing the .dll to .vst3 was also not possible within the existing VST2 spec.

But what about VST3? Would the additions people want to see really break the way VST3 fundamentally works, necessitating a new VST4 spec?

[Gone soft]

Whatever is most stable of 64-bit VST2 or VST3, which I've noted varies.

[pixel85]

VST3
- It installs in one always the same folder: no fuss with installers that install a plugin in some random folder (not to mention those that doesn't even have the option to choose destination)
- Dynamic I/O: easier work with multi-output plugins like Kontakt
- Audio In for Instruments (unfortunately not as popular as it should be)
- A plugin is automatically disabled when doesn't process any sound (saving CPU!)

As a developer i need to give some comments on this.

The fixed directory can be an advantage for simplicity, but is a real problem when you need to format c: because of a windows reinstall. That's why many users prefer to have the choice.

Audio in for synths is also possible with VST2. We do this with filterbank and the vocoder of warmverb

Dynamic I/O sadly still crashes some hosts. It is a pretty 'dangerous' feature

Disabling the VST when no sound is processed is also possible with VST2. It is possible with any plugin-format with low effort. We do this for Electra, Gladiator and many other products

I would expect that now majority of people who treat music production seriously do C Partition backup image regularly? I'm coming from times where I was doing fresh install every few months because it was enough for older Windows to be clogged and messed up so I know the feeling
But just few second ago I read another "I installed new plugin but I can't see it in my X daw" and the solution was to search C Partition for .dll. - in the past I approached situations where manual plugin relocation caused authorisation to fail which was even more "fun" because the only option than was to keep another folder for just one plugin
Beside that keeping .dll on another location is very often pointless because with fresh install its necessary to install and register majority of commercial plugins.
I know, it's not easy for developer to maintain several formats and standards for one product and I'm aware that no single solution is perfect.

About disabling in VST2: unfortunately it's not common. Nothing better than CPU hungry Reverb being active all the time on Aux even when used only in one section of the track It's sad that producers of huge plugin libraries like Komplete are still far behind in catching up with (not even that) modern (anymore) standards.

I also hope that VST4 will help to handle this mess with different formats.

[Markus Krause]

Legit question: why would we need some as of yet undefined VST4 instead of just an update to the VST3 spec to incorporate new features in the future?

I think with VST2, the way certain things were handled (such as automation resolution and I/O handling) precluded changing it without breaking existing software, and changing the .dll to .vst3 was also not possible within the existing VST2 spec.

But what about VST3? Would the additions people want to see really break the way VST3 fundamentally works, necessitating a new VST4 spec?

The structure of VST2.4 was based on Midi. For VST3 Steinberg made a bad decision. They dropped Midi, but included other mostly useless features which made the plugin-format very complicated to handle. The basic structure of VST3 is not designed to handle Midi. That's why architechture of VST3 format needs a complete redesign to handle Midi 2.0 in a reasonable way.
Unlike VST3 the VST 2.4 format is already able to handle Midi 2.0 properly.
My guess is that Steinberg is already working on VST4, which is closer to 2.4 and which comes with Midi 2.0 support

[jamcat]

Legit question: why would we need some as of yet undefined VST4 instead of just an update to the VST3 spec to incorporate new features in the future?

I think with VST2, the way certain things were handled (such as automation resolution and I/O handling) precluded changing it without breaking existing software, and changing the .dll to .vst3 was also not possible within the existing VST2 spec.

But what about VST3? Would the additions people want to see really break the way VST3 fundamentally works, necessitating a new VST4 spec?

The structure of VST2.4 was based on Midi. For VST3 Steinberg made a bad decision. They dropped Midi, but included other mostly useless features which made the plugin-format very complicated to handle. The basic structure of VST3 is not designed to handle Midi. That's why architechture of VST3 format needs a complete redesign to handle Midi 2.0 in a reasonable way.
Unlike VST3 the VST 2.4 format is already able to handle Midi 2.0 properly.
My guess is that Steinberg is already working on VST4, which is closer to 2.4 and which comes with Midi 2.0 support

You're talking MIDI CC vs pure floating-point DAW automation, correct?

[SamDi]

Here my choice and my subjective reason:

-AU: mandatory for Logic X
-VST 2 64 Bit: It‘s more stable than VST 3 on Ableton Live. VST 3 there crashes all the time
-VST 3: It‘s the future...

[Markus Krause]

VST3 has been added to Ableton not long ago. If you experience problems you should contact them and keep Ableton up-to-date. I am sure they will fix the problems soon.