wrong assumptions ahead. I was writing that from some developers point of view. Also, VST3 is not really about new technology since it based on 1993's tech -> COM. In comparison VST2 is simply dynamic library with a C interface.

You're not
You can code any VST3 plugin to not give a damn about disabling when there's no input.

Not really. Well yeah, it's not a separate feature. But the real problem is some hosts not allowing to do proper or flexible audio routing.

VST2 allows you to process actual MIDI messages, while VST3 abstracts this away. Makes MIDI learning based on received MIDI messages rather complicated.

 

Last edited: Feb 11, 2019

What's your DAW?

I remember having read on KVR that, he actually had someone write the Diva VST2 to VST3 and it was not a properly done job that's why he re-wrote the VST-3.

There's no problem with the VST 3 design, but some developers (as big as U-HE) would want to bash out at technology not their own lack of skills; but apparently as of Jan 2019, they support VST-3. So, welcome to the dark side. hahha.

 

@Blue U-he VST 3 problems are entirely down to u-he, he paid someone to port vst2 which communicates to the outside world in an entirely different way than vst3 and the port was crap, its only now that Urs has had time to revisit vst3 and do it properly. It’s also very funny that you failed to post the latest update from Urs as detailed below.... It also means that there is nothing fundamentaly wrong with vst3 just u-he's old versions of them....

"Update Jan 10 2019:

Most of our stuff has transitioned to to stable VST3: Diva, Zebra (+TDZ 6 Zebralette), Repro, Hive, Satin, Presswerk, Colour Copy, Twangström. The remaining payware - ACE, Bazille, Uhbik, MFM and Filterscape - should follow later this year and free/magware (other than Zebralette) depend on, well, schedules..."

As for midi controllers: Yes VST3 did not initially support midi controller learn, there are some at Steinberg that wanted to get rid of midi altogether in VST as who the hell wants a 40 year old code and 8 bit controller info (128 steps) if you do a filter sweep recorded via midi controller info you will hear stepping, for years we complained about this, then automation lanes came along with hugely improved resolution and the world was a better place, but because some wanted midi back its being added into the vst3 protocol as next version. If you want someone to blame, blame the midi association that’s taken almost 40 years to update the midi protocol.

So, both points you have raised are completely irrelevant and frankly misleading.

 

Last edited: Feb 11, 2019

Man,I've posted something I read months ago on KVR.And for this comment I've searched it with Google some minutes,I haven't read all the discussion again.
If I've forgotten to cite something of this discussion it wasn't intentionally.Relax.

I use S1 and I know that i had many problems with vst3.Since I've deleted all my vst3 2 months ago,no problem at all.

 

Last edited: Feb 11, 2019

Apologies my tone was off as well.just got back from work on first day back after 2 month illness

Thread here https://www.kvraudio.com/forum/viewtopic.php?f=31&t=398532&sid=c8922bbaf28a74b3064e1e8ef0f7b20f

actually quite a interesting thread but a bit long, while reading remember Urs very busy building company and thought he had paid for a decent port, he personally knew nothing about vst3. To think Urs knew nothing about about an audio subject is a bit like renouncing god but indeed he did not, things have changed, and u-he is perfect once more.

Sorry to here of your vst3 problems but think problem is in the implemention of some DAWs will be intresting to see how it works out for Ableton users and how they fair.

 

When it comes to C++ programming there're very few things you can't do. But the context matters. we're not talking about how it's programmed but what it offers. You can write a C89 library that is revolutionary for what it does.

I know for a fact that VST3 at least make it easier to add that feature.
Another option: everyone else's wrong...

 

Last edited: Feb 11, 2019

https://www.sweetwater.com/insync/vst-2-4-vs-vst-3-0-who-cares-you-do/
Check this link.

MYTH: VST3 isn’t that different from VST 2.4. It’s just hype; there are no real improvements.

VST3 is a ground-up redo of VST 2.4 and is essentially a new platform.

So now that we’ve busted a few myths, let’s look at some unique VST3 advantages.

• Sample accurate automation. The manufacturer has to implement this, but it’s a significant change compared to VST 2.4.
• Hierarchical plug-in and automation parameter categorization. Some consider plug-in categorization (fig. 3) a drawback, because they can’t organize plug-ins the way they like (although most hosts provide some kind of plug-in manager, in which case it doesn’t matter). But when you want to automate parameters, VST3 plug-ins can make life a whole lot easier if the manufacturer took advantage of the parameter categorization options. Grouping all filter automation parameters under a “Filter” category is waaaay better than a huge list of automation parameters with a seemingly random arrangement.

Figure 3: Cubase 9.5 has a sophisticated VST plug-in manager. Note how in the Category, some plug-ins have been categorized as to the type of effect (e.g., Dynamics, Modulation). Highlighting a plug-in shows information about sidechaining, type of I/O, file path, and more.

• The VST3 SDK is free technology that is available to any developer. Thanks, Steinberg/Yamaha. Enough said.
• Dynamic I/O allocation. VST 2.4 plug-ins used to have a fixed number of inputs and outputs, but that’s no longer the case — VST3 plug-ins have the potential to adapt to the channel configuration into which they’re inserted. Put the plug-in on a stereo bus, and it’s stereo. Insert it in a surround bus, and it’s surround. You can also create audio buses, which makes cross-modulation and vocoder applications easy to do. But again, it’s up to the manufacturer to implement these features.
• Instrument output bus cleanup. In a related development, instruments with multiple outputs can take up a lot of unneeded mixer channels. With VST3, you can disable unused outputs yet re-enable them later if needed.
• Window resizing. This is certainly welcome, given that monitors have a wider variety of resolutions than when VST was introduced back in 1996 (and for perspective, “Macarena” was the #1 song of the year. Just sayin’).
• With virtual instruments, there’s support for multiple MIDI ports you can switch on the fly. And who doesn’t like multiple MIDI ports?
• It’s a lot easier to do a search and find your plug-ins. VST3 plug-ins have the .vst3 suffix instead of a generic suffix.
• Plug-ins can have a dedicated “event bus.” Although at present this is designed for MIDI control input, there’s no reason why it couldn’t accommodate some future standard that’s not MIDI-based.
• VSTXML for remote controllers. No, a cat didn’t walk across my keyboard. VSTXML is a protocol that simplifies creating remote controllers for audio and MIDI software application. It can even display non-editable parameters, like metering.
• Multilingual design. All user-facing character strings are in Unicode format, which allows displaying characters in any language (включая русский — which means, “including Russian”) to facilitate localization.
• Better handling of MIDI events. This assists upcoming expansions to the MIDI spec. As one example, a particular note could be associated with bend so only that note reacts to pitch bend — think MIDI pedal steel. An instrument can also have more than one MIDI input and/or output.

 

Indeed. VST3 provides a clean way to implement it properly. Nevertheless, no force to do. That's my point in this regard, nothing else. Sorry for any confusion.

That's only half of the story, though. VST3 SDK is dual licensed.

(1) "Free technology" means GPLv3 version of VST3 SDK. GPLv3 is not suitable for basically any commercial plugin. "If you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code."

(2) On other hand, proprietary license contract "entitles Steinberg to terminate this agreement with a 36 months written notice" anytime. In such a case it seems like a developer would no longer be allowed to develop, update or distribute any VST3 plugins. Apparently not even their existing ones.

EDIT References:

Spoiler

https://sdk.steinberg.net/viewtopic.php?f=4&t=282
https://www.gnu.org/licenses/gpl-3.0.txt
https://www.steinberg.net/vst3sdk

This could have made it into VST2 easily.
Nothing special would be required for supporting a .vst2 suffix.

 

Last edited: Feb 12, 2019

I meant something like this

https://drive.google.com/open?id=1pofzDAQ9E9PgIAIyCh2ZCEhV3DUzzWhR

In the first case you have no benefit from the additional cpu power before and after the smaller part

 

Yeah, that's the case with most programming technologies nowadays. At least now we can have powerful tools as long we don't make money. The moment we want we're f*ed.

For instance, lately I've been playing with the incredible Juce plugin framework (GPL edition). Basically compiling examples and stuff, with the powerful Visual Studio 2017 IDE/Compiler (Community Edition, very roughly GPL). You can even add the fastest FFT/convolution/matrix crunching math library, Intel Performance Primitives (CE edition again, not a joke).

All these have in common that for free you get them as powerful (or almost) as the commercial ones. GPL-like license. The moment you make money they got you by the balls, and nowadays you only can pay with subscription models, very uneasy for my old-school taste

PS: almost forgot the one useful thig I wanted to say. Steinberg no longer distributes the VST2 SDK since a few months ago. Legally speaking you'll have more license problems now if you try to develop VST2 plugins.

I tried to compile a JUCE plugin example, a MIDI arpeggiator. Didn't work on the DAW. I turns out VST3 MIDI effects have problems even in very advanced libraries like JUCE.

After googling, the solution is (drumroll...): to download the latest VST2 SDK. Which, of course, isn't available in Steinberg site anymore, I had to resort to one of these archive.net sites to grab it. Compiled with the "discontinued" VST2 technology and worked like a charm...

Edited: typos, reworked and repacked

 

Last edited: Feb 13, 2019

I did a test today with last u-he Hive version downloaded from sister site, i rendered the audio from the same notes from vst3 and vst2, and (don't ask me why) audio is slightly different, on vst3 it sounds a little more open than vst2, even waveforms are slightly different, and they shows tiny differences on spectrum and lufs on SPL HawkEye, i recorded at 48/24 in Ableton 10.1, i'm on win 10 1803, i suggest you to try it yourself and let me know replying on this post

 

Check if both versions are set to exactly the same quality, especially if there's a setting for a different quality during rendering. VST3 might have got notified you're rendering and switched to higher quality while VST2 did not.

 

Nope, no quality settings on last version of Hive (hope i'm not wrong), i know that other u-he vsts like diva and repro have quality settings, if you have both version (vst2 and vst3) of an instrument you can try too if you want, maybe there's something else under the hood, i don't know, but the difference is there and i don't know why. Just try with any instrument if you want, i'm curious .

 

That's the only reasonable explanation apart from bugs.
There's no valid reason to let a VST2 plugin output worse quality than a VST3 one. Usually both versions usually share the same codebase.

The only technical reason I could think of are VST2 plugins not implementing processDoubleReplacing() or bad implementation of such 64 bit processing by internally calling processReplacing() and converting 32 bit values to 64 bit ones. But it would really surprise me if u-he plugins did so. Might also be DAW's fault calling normal replacing instead of double (= 64 bit) one.

To put it simple, VST2 and VST3 are just API specs. There's no magic or anything relevant to "how something sounds" involved. They just define what a host (e.g. your DAW) has to do, to get some sound out of them.