That's only a theoretical advantage, as most devs have implemented the same for VST2.Mataya wrote: ↑29 Nov 2022No CPU wastes
Perhaps, the biggest improvement of the VST3 plug-in is that it doesn’t waste CPU resources and only works when it detects the presence of an audio signal, unlike VST2, which remains active at all times. For users, this means an opportunity to use a bigger number of plug-ins without overloading the system.
This can be an advantage (especially Waves is cluttering the plugin list for VST2 with all their different stereo/mono/mono-to-stereo versions of the same plugin. Still I wonder if they really don't do this for the VST3 versions, as the different versions also feature slightly different UIs and if VST3 would have a way to handle this natively.Mataya wrote: ↑29 Nov 2022The second big improvement is that the VST3 plug-in format is designed to be adaptive, meaning it can be used with multiple inputs/outputs. Whereas with VST2, you’d have to install at least a few separate versions of plug-ins to maintain both surround and sound processing, VST3 can be automatically adapted to channel routing, thus minimizing the wastage of resources.
Wide Variety of Control
With the rather basic MIDI implementation that Reason has, I highly doubt that we will see any implementation of this in Reason in the near future.Mataya wrote: ↑29 Nov 2022A dedicated event handler bus is another highlight of the VST3 plugins. Not only does it give users control over the traditional MIDI messages, but it also allows for the use of modulation messages and future-proves the plug-in by making it adaptable to new control methods that may soon be introduced to the industry. In addition to that, users can take advantage of an advanced control at a note level and apply a specific effect not to the entire chord but to a specific note through associating it with a unique identifier.
Multiple inputs and outputs support
That's cool, but I suspect we'll possibly not see this in Reason as well.
So basically something we've had with REs from the very beginning. And I suspect that the developer has to actively take advantage of this and not just use a slim wrapper to get all plugin formats from the same DSP/GUI code. But in the long run after devs have dropped VST2 support this could become the standard.Mataya wrote: ↑29 Nov 2022User-friendly search
While in most cases users don’t pay much attention to the search option, it’s the feature that can make using the plug-in a lot more convenient. In the battle between VST2 vs VST3, VST3 wins again. Unlike the VST2 plugin throwing at users hundreds of automation parameters to scroll through, it comes with a user-friendly search filter that allows you to categorize all parameters by categories and helps keep the whole process streamlined and organized.
Sidechaining is also possible with VST2 if a dev chooses to implement it. The only problem here is the lack of a specified standard or reference implementation provided in the SDK. So a few different ways have been used for this in VST2 land which can then lead to incompatibility with different hosts.
So in general VST3 offers a rather boring improvement over VST2 by extending the standard with a lot more specification, but of course it comes at the cost of higher complexity and most has been possible before in VST2 as well. In comparison more modern formats like CLAP or RE offer some bigger and more useful advantages over VST3 and I for sure would not mind Reason to also implement CLAP hosting and extending the RE SDK either, after improving the internal MIDI implementation with e.g. per note events and MPE, etc.