VST 3.0...when??

Discuss VST stuff here!
johnghadimi
Posts: 39
Joined: 13 Dec 2016

16 Feb 2018

Hi;

Has there been any word from Props on when they would start supporting the VST 3.0 format? Would love not having to go to Ableton or Reaper to get access to those instruments. Honestly not expecting any 32bit VST support, but at least give us VST 3.0. Please. :)

J.

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

16 Feb 2018

What are the benefits?

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

johnghadimi wrote:
16 Feb 2018
Hi;

Has there been any word from Props on when they would start supporting the VST 3.0 format? Would love not having to go to Ableton or Reaper to get access to those instruments. Honestly not expecting any 32bit VST support, but at least give us VST 3.0. Please. :)

J.
They haven't even fully supported VST 2 yet (no MIDI fx), so I wouldn't hold your breath.
miscend wrote:
16 Feb 2018
What are the benefits?
Over VST 2, VST 3 has:
  • Audio Inputs for VST Instruments
  • Multiple MIDI inputs/outputs
  • Optional SKI (Steinberg Kernel Interface) integration
  • Note expression, which provides extensive articulation information in individual note events in a polyphonic arrangement. This supports performance flexibility and a more natural playing feel.
VST 3 came out 10 years ago, BTW. Also, the SDK for VST 2 stopped being supported by Steinberg almost 5 years ago. :(
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
  • Audio Inputs for VST Instruments
From a technical point of view, VST2 does support audio inputs for instruments.
The interface for instruments is basically the same as for effects, instruments simply report a different plugin category.
There's no reason why a DAW should not be able to route audio input into a VSTi.

(on a side note: I also keep reading that for side chaining you need VST3, which is certainly not true (or may only be true b/c of DAW limitations)).
EnochLight wrote:
17 Feb 2018
  • Note expression, which provides extensive articulation information in individual note events in a polyphonic arrangement. This supports performance flexibility and a more natural playing feel.
VST2 supports MPE, which accomplishes a very similar thing (the way HW synths do it). The only drawback is that you are limited to 16 voices (which still is plenty, IMHO).

I for one find the VST3 interface kind of over-engineered (for starters, VST2 uses a simple "C" interface, VST3 is C++), and it's not a surprise that most plugin+host devs were/are not overly keen to support it.

But yeah, sooner or later PH will have to support VST3 but I'd also like Reason to fully support VST2 first (there are still import features missing, e.g. support for all MIDI messages and CC types, multitimbrality/MPE, ..).

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

bsp wrote:
17 Feb 2018
EnochLight wrote:
17 Feb 2018
  • Audio Inputs for VST Instruments
From a technical point of view, VST2 does support audio inputs for instruments.
The interface for instruments is basically the same as for effects, instruments simply report a different plugin category.
There's no reason why a DAW should not be able to route audio input into a VSTi.

(on a side note: I also keep reading that for side chaining you need VST3, which is certainly not true (or may only be true b/c of DAW limitations)).
EnochLight wrote:
17 Feb 2018
  • Note expression, which provides extensive articulation information in individual note events in a polyphonic arrangement. This supports performance flexibility and a more natural playing feel.
VST2 supports MPE, which accomplishes a very similar thing (the way HW synths do it). The only drawback is that you are limited to 16 voices (which still is plenty, IMHO).
These things were never a part of the original VST 2 spec, though. VST 3 is what "officially" added proper support.
bsp wrote:
17 Feb 2018
I for one find the VST3 interface kind of over-engineered (for starters, VST2 uses a simple "C" interface, VST3 is C++), and it's not a surprise that most plugin+host devs were/are not overly keen to support it.
Well, VST/VST2 was essentially written in the mid/late 90's, so moving to C++ was inevitable I would imagine. Not surprised VST 3 is still experiencing some pushback, though the VST 2 SDK is no longer supported so... I would imagine it's just a matter of time before devs have to move to VST 3? Though it's literally been years since VST SDK 2 hasn't been supported.. :lol: *shrugs*
bsp wrote:
17 Feb 2018
But yeah, sooner or later PH will have to support VST3 but I'd also like Reason to fully support VST2 first (there are still import features missing, e.g. support for all MIDI messages and CC types, multitimbrality/MPE, ..).
I really only want full VST 2 support in Reason, as well as the VST performance to be fixed in general. There's few VST I use that are only available as VST 3 currently (though I agree that's bound to change as the years go on)...

I wonder... Are there any GUI/UX advantages in using VST 3?
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
These things were never a part of the original VST 2 spec, though. VST 3 is what "officially" added proper support.
Actually, they were. That's the nice thing about MIDI -- it's very flexible. MPE is just another way of using it, that's why it works in VST2 without any interface changes.

For aforementioned reasons, instrument audio input has always been part of the VST2 interface, too.

Re: my sidechain input comment: I just searched for VST compressors that support external side chain input: It's quite shocking that most don't support this. The Fabfilter Pro-C 2 does, so it's not a problem with the VST2 interface but just with lazy devs ;-) (currently trialing it, it's not exactly cheap).

EnochLight wrote:
17 Feb 2018
Well, VST/VST2 was essentially written in the mid/late 90's, so moving to C++ was inevitable I would imagine. Not surprised VST 3 is still experiencing some pushback, though the VST 2 SDK is no longer supported so... I would imagine it's just a matter of time before devs have to move to VST 3? Though it's literally been years since VST SDK 2 hasn't been supported.. :lol: *shrugs*
Well, good software does not really age and VST2 is just an interface, not actual program code. It's most likely going to be supported by DAWs for a long time to come since there are _a lot_ of VST2 plugins out there today
(and nobody needs Steinberg's support to use their interfaces, so it does not really mean anything when they say it's not supported any longer. I'm sure also Cubase will be able to load VST2s in the future).

I guess that the simplicity of the VST2 interface was a main reason for its success.
Besides, C++ is not a successor to C, so there's no reason to switch languages just to add a few (relatively minor) updates to an interface.
Why Steinberg, instead of "reinventing the wheel", did not simply extend the VST2 interface is beyond me.

EnochLight wrote:
17 Feb 2018
I really only want full VST 2 support in Reason, as well as the VST performance to be fixed in general. There's few VST I use that are only available as VST 3 currently (though I agree that's bound to change as the years go on)...

I wonder... Are there any GUI/UX advantages in using VST 3?
Unlike the RE SDK, UIs are not within the scope of the VST interface(s), so there are not any advantages (that I know of).

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

bsp wrote:
17 Feb 2018
EnochLight wrote:
17 Feb 2018
These things were never a part of the original VST 2 spec, though. VST 3 is what "officially" added proper support.
Actually, they were. That's the nice thing about MIDI -- it's very flexible. MPE is just another way of using it, that's why it works in VST2 without any interface changes.

For aforementioned reasons, instrument audio input has always been part of the VST2 interface, too.

Re: my sidechain input comment: I just searched for VST compressors that support external side chain input: It's quite shocking that most don't support this. The Fabfilter Pro-C 2 does, so it's not a problem with the VST2 interface but just with lazy devs ;-) (currently trialing it, it's not exactly cheap).
Strange, because that seems to run counter to what's being published here (though it's not the first time a Wiki has been wrong): :lol:

https://en.wikipedia.org/wiki/Virtual_S ... gy#History

Perhaps we're confusing VSTi (instrument) audio input with VST (effects) audio input... ?
bsp wrote:
17 Feb 2018
EnochLight wrote:
17 Feb 2018
Well, VST/VST2 was essentially written in the mid/late 90's, so moving to C++ was inevitable I would imagine. Not surprised VST 3 is still experiencing some pushback, though the VST 2 SDK is no longer supported so... I would imagine it's just a matter of time before devs have to move to VST 3? Though it's literally been years since VST SDK 2 hasn't been supported.. :lol: *shrugs*
Well, good software does not really age and VST2 is just an interface, not actual program code. It's most likely going to be supported by DAWs for a long time to come since there are _a lot_ of VST2 plugins out there today
(and nobody needs Steinberg's support to use their interfaces, so it does not really mean anything when they say it's not supported any longer. I'm sure also Cubase will be able to load VST2s in the future).


I guess that the simplicity of the VST2 interface was a main reason for its success.
Besides, C++ is not a successor to C, so there's no reason to switch languages just to add a few (relatively minor) updates to an interface.
Why Steinberg, instead of "reinventing the wheel", did not simply extend the VST2 interface is beyond me.
I'm aware the "spec" isn't actually program code, but the above begs the question: why introduce a VST 3 "spec" at all of this was already possible with VST 2?

¯\_(ツ)_/¯
bsp wrote:
17 Feb 2018
EnochLight wrote:
17 Feb 2018
I really only want full VST 2 support in Reason, as well as the VST performance to be fixed in general. There's few VST I use that are only available as VST 3 currently (though I agree that's bound to change as the years go on)...

I wonder... Are there any GUI/UX advantages in using VST 3?
Unlike the RE SDK, UIs are not within the scope of the VST interface(s), so there are not any advantages (that I know of).
Thanks!
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

17 Feb 2018

I remember they used to recommend learning C syntax first before picking up C++. C++ modernised C by bringing in newer object oriented programming concepts. I dunno if it is still the same today.

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
Strange, because that seems to run counter to what's being published here (though it's not the first time a Wiki has been wrong): :lol:

https://en.wikipedia.org/wiki/Virtual_S ... gy#History

Perhaps we're confusing VSTi (instrument) audio input with VST (effects) audio input... ?
Nope, we're talking about the same thing.

To elaborate: each VST2 plugin (regardless of whether it is an effect or an instrument) has a processing function:
void VSTPluginProcessReplacingFloat32(VSTPlugin *vstPlugin,
float **inputs,
float **outputs,
VstInt32 sampleFrames
)

The "AEffect" structure that describes a plugin (again, either effect or instrument) has these two fields:
VstInt32 numInputs; ///< number of audio inputs
VstInt32 numOutputs; ///< number of audio outputs

Then there are a couple of functions that allow you to query the details for each input and output (both effect+instrument), e.g. effGetInputProperties and effGetOutputProperties.

Therefore, both instruments and effects can have (an arbitrary number of) audio inputs and outputs.

I can't really say if there are any VSTis out there that use audio inputs. The VSTis I have that support audio input (e.g. XILS 4) come with a dedicated "fx" version of the plugin.
I can only imagine that they did this because some mainstream DAWs do not support instrument audio input, even though the VST interface does.

EnochLight wrote:
17 Feb 2018
I'm aware the "spec" isn't actually program code, but the above begs the question: why introduce a VST 3 "spec" at all of this was already possible with VST 2?

¯\_(ツ)_/¯
Good question !
I really can't think of any good reason (..and any VST3-only features could have been implemented as extensions to the VST2 interface).

Besides, choosing C++ for a plugin interface is a very bad idea, unless you have complete control over both the plugin host + plugin builds (e.g. open source software).
The reason for that is that while "C" binary linkage is very well defined/standardized, C++ linkage and its name mangling schemes are not. They are actually compiler dependent which means that you may not be able to dynamically load a C++ plugin compiled with compiler X in a plugin host that's been compiled with compiler Y.
Needless to say, when you try to load a C++ plugin in a non-C++ plugin host you'll be in for a treat..

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

bsp wrote:
17 Feb 2018
EnochLight wrote:
17 Feb 2018
Strange, because that seems to run counter to what's being published here (though it's not the first time a Wiki has been wrong): :lol:

https://en.wikipedia.org/wiki/Virtual_S ... gy#History

Perhaps we're confusing VSTi (instrument) audio input with VST (effects) audio input... ?
Nope, we're talking about the same thing.

To elaborate: each VST2 plugin (regardless of whether it is an effect or an instrument) has a processing function:
void VSTPluginProcessReplacingFloat32(VSTPlugin *vstPlugin,
float **inputs,
float **outputs,
VstInt32 sampleFrames
)

The "AEffect" structure that describes a plugin (again, either effect or instrument) has these two fields:
VstInt32 numInputs; ///< number of audio inputs
VstInt32 numOutputs; ///< number of audio outputs

Then there are a couple of functions that allow you to query the details for each input and output (both effect+instrument), e.g. effGetInputProperties and effGetOutputProperties.

Therefore, both instruments and effects can have (an arbitrary number of) audio inputs and outputs.

I can't really say if there are any VSTis out there that use audio inputs. The VSTis I have that support audio input (e.g. XILS 4) come with a dedicated "fx" version of the plugin.
I can only imagine that they did this because mainstream DAWs do not support instrument audio input, even though the VST interface does.

EnochLight wrote:
17 Feb 2018
I'm aware the "spec" isn't actually program code, but the above begs the question: why introduce a VST 3 "spec" at all of this was already possible with VST 2?

¯\_(ツ)_/¯
Good question !
I really can't think of any good reason (..and any VST3-only features could have been implemented as extensions to the VST2 interface).

Besides, choosing C++ for a plugin interface is a very bad idea, unless you have complete control over both the plugin host + plugin builds (e.g. open source software).
The reason for that is that while "C" binary linkage is very well defined/standardized, C++ linkage and its name mangling schemes are not. They are actually compiler dependent which means that you may not be able to dynamically load a C++ plugin compiled with compiler X in a plugin host that's been compiled with compiler Y.
Needless to say, when you try to load a C++ plugin in a non-C++ plugin host you'll be in for a treat..
But clearly there must be a reason to use VST 3 over VST 2, else the new "spec" would not exist. I find it hard to believe that Steinberg would just change to C++... what.. just for the hell of it?

How about this:
  • Improved performance
  • Multiple dynamic I/Os
  • Activating/deactivating busses
  • Resizable edit windows
  • Sample-accurate automation
  • Logical parameter organization
  • Optional VST3/SKI combination
  • VSTXML for remote controllers
  • UTF16 for localized parameter naming
  • No MIDI restriction for parameter value transfers
  • Audio inputs for VST instruments
  • Multiple MIDI inputs/outputs
  • 64-bit audio processing
https://www.steinberg.net/en/company/te ... /vst3.html

Note: I'm not suggesting that C++ is required to obtain that above list. I'm merely pointing out that there are some definitive differences between VST3 and previous versions.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
miscend
Posts: 1955
Joined: 09 Feb 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
bsp wrote:
17 Feb 2018


Nope, we're talking about the same thing.

To elaborate: each VST2 plugin (regardless of whether it is an effect or an instrument) has a processing function:
void VSTPluginProcessReplacingFloat32(VSTPlugin *vstPlugin,
float **inputs,
float **outputs,
VstInt32 sampleFrames
)

The "AEffect" structure that describes a plugin (again, either effect or instrument) has these two fields:
VstInt32 numInputs; ///< number of audio inputs
VstInt32 numOutputs; ///< number of audio outputs

Then there are a couple of functions that allow you to query the details for each input and output (both effect+instrument), e.g. effGetInputProperties and effGetOutputProperties.

Therefore, both instruments and effects can have (an arbitrary number of) audio inputs and outputs.

I can't really say if there are any VSTis out there that use audio inputs. The VSTis I have that support audio input (e.g. XILS 4) come with a dedicated "fx" version of the plugin.
I can only imagine that they did this because mainstream DAWs do not support instrument audio input, even though the VST interface does.




Good question !
I really can't think of any good reason (..and any VST3-only features could have been implemented as extensions to the VST2 interface).

Besides, choosing C++ for a plugin interface is a very bad idea, unless you have complete control over both the plugin host + plugin builds (e.g. open source software).
The reason for that is that while "C" binary linkage is very well defined/standardized, C++ linkage and its name mangling schemes are not. They are actually compiler dependent which means that you may not be able to dynamically load a C++ plugin compiled with compiler X in a plugin host that's been compiled with compiler Y.
Needless to say, when you try to load a C++ plugin in a non-C++ plugin host you'll be in for a treat..
But clearly there must be a reason to use VST 3 over VST 2, else the new "spec" would not exist. I find it hard to believe that Steinberg would just change to C++... what.. just for the hell of it?

How about this:
  • Improved performance
    [*Multiple dynamic I/Os
    [*Activating/deactivating busses
    [*Resizable edit windows
    [*Sample-accurate automation
    [*Logical parameter organization
    [*Optional VST3/SKI combination
    [*VSTXML for remote controllers
    [*UTF16 for localized parameter naming
    [*No MIDI restriction for parameter value transfers
    [*Audio inputs for VST instruments
    [*Multiple MIDI inputs/outputs
    [*64-bit audio processing
https://www.steinberg.net/en/company/te ... /vst3.html
Why didn’t they handle it like Apple does with AU. They have quietly been adding more features to the existing AU SDK without breaking back compatibility or creating any inconveniences to end users. It makes no sense why VST 3 is not compatible with its predecessor.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

miscend wrote:
17 Feb 2018
Why didn’t they handle it like Apple does with AU. They have quietly been adding more features to the existing AU SDK without breaking back compatibility or creating any inconveniences to end users. It makes no sense why VST 3 is not compatible with its predecessor.
Because Steinberg. :lol: :lol: :lol:
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

kitekrazy
Posts: 1036
Joined: 19 Jan 2015

17 Feb 2018

I don't think Live has VST3 support yet.

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
I find it hard to believe that Steinberg would just change to C++... what.. just for the hell of it?

How about this:
  • Improved performance
  • Multiple dynamic I/Os
  • Activating/deactivating busses
  • Resizable edit windows
  • Sample-accurate automation
  • Logical parameter organization
  • Optional VST3/SKI combination
  • VSTXML for remote controllers
  • UTF16 for localized parameter naming
  • No MIDI restriction for parameter value transfers
  • Audio inputs for VST instruments
  • Multiple MIDI inputs/outputs
  • 64-bit audio processing
https://www.steinberg.net/en/company/te ... /vst3.html

Note: I'm not suggesting that C++ is required to obtain that above list. I'm merely pointing out that there are some definitive differences between VST3 and previous versions.
  • "improved performance" is more than unlikely, the performance is mostly determined by the host and the actual plugin code, not the interface.
  • "resizable edit windows" are definitely possible with VST2 (e.g. UVI Falcon)
  • "audio inputs for VST instruments" -- already discussed
  • "64-bit audio processing": already possible ("processDoubleReplacing" function)
I'm not saying that VST3 does not have any new features, just that there was no good reason to change the entire interface (including the move to C++).
miscend wrote:
17 Feb 2018
It makes no sense why VST 3 is not compatible with its predecessor.
exactly my thoughts.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

bsp wrote:
17 Feb 2018
  • "improved performance" is more than unlikely, the performance is mostly determined by the host and the actual plugin code, not the interface.
  • "resizable edit windows" are definitely possible with VST2 (e.g. UVI Falcon)
  • "audio inputs for VST instruments" -- already discussed
  • "64-bit audio processing": already possible ("processDoubleReplacing" function)
I'm not saying that VST3 does not have any new features, just that there was no good reason to change the entire interface (including the move to C++).
And yet, it was changed by Steinberg, and many - if not most - "premium" devs offer a VST3 version of their flagship products. So... there's that. ;) I can't imagine said devs doing both VST2 and VST3 versions of their products if every feature that can be done in VST3 can be done in VST2. I just wonder what the flagship feature is that warrants doing VST3. An enigma!
bsp wrote:
17 Feb 2018
miscend wrote:
17 Feb 2018
It makes no sense why VST 3 is not compatible with its predecessor.
exactly my thoughts.
Agreed. Like I said, Steinberg. :lol: :lol: :lol:
Last edited by EnochLight on 17 Feb 2018, edited 1 time in total.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
pongasoft
RE Developer
Posts: 478
Joined: 21 Apr 2016
Location: Las Vegas
Contact:

17 Feb 2018

To add to this topic, Maschine by Native Instruments does not support VST3 either... so hard to imagine Reason would...

Yan

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

VST3 has not been widely adopted during the past ten years and it looks like this is not going to change anytime soon.

It would be nice if Reason supported it but let's not forget that the hard part is adding all these fancy new features to Reason itself in the first place.

For example: note expression. Neither Reason nor its native Rack Extension format does support that feature, yet.

Sure, PH could add a VST3 loader but if that does not even support all the VST2 features, it's not particularly useful (except for the few plugins that are only available as VST3).

Just found a comment from one of the Steinberg people in their own forum. According to that, "the leading causes of crashes and other problems in Cubase is due to VST 2 plug-ins".
If I may add my own 2 cents:
the leading cause of crashes and other problems are bad programmers, not plugin interfaces.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

pongasoft wrote:
17 Feb 2018
To add to this topic, Maschine by Native Instruments does not support VST3 either... so hard to imagine Reason would...

Yan
While Maschine is popular, it's not like a traditional DAW, so I'm not sure I understand the comparison...

I'd say Reason is more akin to FL Studio, Studio One, Reaper, Bitwig, and Cubase - all of which support VST3. I don't think the latest version of Live does, though.
bsp wrote:
17 Feb 2018
VST3 has not been widely adopted during the past ten years and it looks like this is not going to change anytime soon.
Um.. except for the most of all major PC DAW manufactures adopting it part... sure. ;)
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
bsp wrote:
17 Feb 2018
VST3 has not been widely adopted during the past ten years and it looks like this is not going to change anytime soon.
Um.. except for the most of all major PC DAW manufactures adopting it part... sure. ;)
ok, let me rephrase that: how many / which plugins are available _only_ in VST3 format ?

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

bsp wrote:
17 Feb 2018
ok, let me rephrase that: how many / which plugins are available _only_ in VST3 format ?
I good portion of Roland Cloud's new plugins are only available in VST3 format, but most plugins are also available in VST 2 thankfully. I can imagine that this is one reason why Propellerhead chose to just support VST 2.x currently. Well, support it mostly. :lol:
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
joeyluck
Moderator
Posts: 11029
Joined: 15 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
bsp wrote:
17 Feb 2018
ok, let me rephrase that: how many / which plugins are available _only_ in VST3 format ?
I good portion of Roland Cloud's new plugins are only available in VST3 format, but most plugins are also available in VST 2 thankfully. I can imagine that this is one reason why Propellerhead chose to just support VST 2.x currently. Well, support it mostly. :lol:
The VST editor for my Motif Rack XS is VST3 only. And I didn't realize this until recently. And it's almost 9 years old! As of today! https://www.steinberg.net/en/newsandeve ... e-666.html

When Reason 9.5 introduced VST support, I went to go find the Motif Editor VST that I could finally use...
Only to discover that there never was a VST2 version. It's always been VST3 only.

So Steinberg/Yamaha had been making a push to transition since back then...and a little before perhaps as VST3 was released in 2008! Of course they would try with their own format.

But for someone like myself not having as much knowledge in VSTs, I was totally thrown to learn that VST3 was that old. Because it's not common and not that many developers have been adopting it. So I wondered myself what the benefits were, and what the barriers were to make VST3 plugins and add support to DAWs for VST3. Because if it's simple, I would think it would be done.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

joeyluck wrote:
17 Feb 2018
So I wondered myself what the benefits were, and what the barriers were to make VST3 plugins and add support to DAWs for VST3. Because if it's simple, I would think it would be done.
Well, as mentioned earlier - it has to be done in C++, which may throw a lot of devs off.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
bsp wrote:
17 Feb 2018
ok, let me rephrase that: how many / which plugins are available _only_ in VST3 format ?
I good portion of Roland Cloud's new plugins are only available in VST3 format, but most plugins are also available in VST 2 thankfully. I can imagine that this is one reason why Propellerhead chose to just support VST 2.x currently. Well, support it mostly. :lol:
ok, good to know (and thanks for the input, @joeyluck).
EnochLight wrote:
17 Feb 2018
joeyluck wrote:
17 Feb 2018
So I wondered myself what the benefits were, and what the barriers were to make VST3 plugins and add support to DAWs for VST3. Because if it's simple, I would think it would be done.
Well, as mentioned earlier - it has to be done in C++, which may throw a lot of devs off.

As a dev, you usually want an occam's razor solution.

Then you can add any kind of complexity (your own C++ wrapper etc) on top of that.

VST3 is not that. It looks like sth that's been extracted from a complex application like Cubase and declared to be the new plugin standard.

If Steinberg were really interested in stable VST plugins, they would've improved their documentation, and released an (open source, cross-platform) VST (C++) wrapper framework that deals with the common caveats of plugin development (threading, UIs).

Even the VST2 documentation is very sparse.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

17 Feb 2018

bsp wrote:
17 Feb 2018
As a dev, you usually want an occam's razor solution.

Then you can add any kind of complexity (your own C++ wrapper etc) on top of that.

VST3 is not that. It looks like sth that's been extracted from a complex application like Cubase and declared to be the new plugin standard.

If Steinberg were really interested in stable VST plugins, they would've improved their documentation, and released an (open source, cross-platform) VST (C++) wrapper framework that deals with the common caveats of plugin development (threading, UIs).

Even the VST2 documentation is very sparse.
And the irony - this was one of the reasons why Propellerhead chose to pursue their own plugin format that they had complete control over. But... at the end of the day, I'm glad they relented and opened Reason up to VST anyway.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

17 Feb 2018

EnochLight wrote:
17 Feb 2018
bsp wrote:
17 Feb 2018
As a dev, you usually want an occam's razor solution.

Then you can add any kind of complexity (your own C++ wrapper etc) on top of that.

VST3 is not that. It looks like sth that's been extracted from a complex application like Cubase and declared to be the new plugin standard.

If Steinberg were really interested in stable VST plugins, they would've improved their documentation, and released an (open source, cross-platform) VST (C++) wrapper framework that deals with the common caveats of plugin development (threading, UIs).

Even the VST2 documentation is very sparse.
And the irony - this was one of the reasons why Propellerhead chose to pursue their own plugin format that they had complete control over. But... at the end of the day, I'm glad they relented and opened Reason up to VST anyway.
Well, they basically did the right thing.

They just forgot to open their REs to the public.

The main advantage of VSTs is that you can use them any way you like (i.e. in any DAW).

The main advantage of REs is that it handles the "nasty" stuff (e.g. cross platform UIs).

btw: I dropped a mail to Mattias the other day, requesting a VST shell for REs. That would be mighty nice, don't you think ?

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 12 guests