VST 3.0...when??
-
- Posts: 39
- Joined: 13 Dec 2016
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.
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.
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
They haven't even fully supported VST 2 yet (no MIDI fx), so I wouldn't hold your breath.johnghadimi wrote: ↑16 Feb 2018Hi;
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.
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.
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
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)).
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).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.
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, ..).
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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 2018From 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)).
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).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.
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.. *shrugs*
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
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.EnochLight wrote: ↑17 Feb 2018These things were never a part of the original VST 2 spec, though. VST 3 is what "officially" added proper support.
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).
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 todayEnochLight wrote: ↑17 Feb 2018Well, 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.. *shrugs*
(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.
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).EnochLight wrote: ↑17 Feb 2018I 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?
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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):bsp wrote: ↑17 Feb 2018Actually, 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.EnochLight wrote: ↑17 Feb 2018These things were never a part of the original VST 2 spec, though. VST 3 is what "officially" added proper support.
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).
https://en.wikipedia.org/wiki/Virtual_S ... gy#History
Perhaps we're confusing VSTi (instrument) audio input with VST (effects) audio input... ?
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 2018Well, 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 todayEnochLight wrote: ↑17 Feb 2018Well, 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.. *shrugs*
(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.
¯\_(ツ)_/¯
Thanks!bsp wrote: ↑17 Feb 2018Unlike the RE SDK, UIs are not within the scope of the VST interface(s), so there are not any advantages (that I know of).EnochLight wrote: ↑17 Feb 2018I 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
Nope, we're talking about the same thing.EnochLight wrote: ↑17 Feb 2018Strange, because that seems to run counter to what's being published here (though it's not the first time a Wiki has been wrong):
https://en.wikipedia.org/wiki/Virtual_S ... gy#History
Perhaps we're confusing VSTi (instrument) audio input with VST (effects) audio input... ?
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.
Good question !EnochLight wrote: ↑17 Feb 2018I'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?
¯\_(ツ)_/¯
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..
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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?bsp wrote: ↑17 Feb 2018Nope, we're talking about the same thing.EnochLight wrote: ↑17 Feb 2018Strange, because that seems to run counter to what's being published here (though it's not the first time a Wiki has been wrong):
https://en.wikipedia.org/wiki/Virtual_S ... gy#History
Perhaps we're confusing VSTi (instrument) audio input with VST (effects) audio input... ?
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 !EnochLight wrote: ↑17 Feb 2018I'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?
¯\_(ツ)_/¯
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..
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
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
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.EnochLight wrote: ↑17 Feb 2018But 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?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..
How about this:
https://www.steinberg.net/en/company/te ... /vst3.html
- 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
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
Because Steinberg.
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
EnochLight wrote: ↑17 Feb 2018I find it hard to believe that Steinberg would just change to C++... what.. just for the hell of it?
How about this:
https://www.steinberg.net/en/company/te ... /vst3.html
- 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
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)
exactly my thoughts.
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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 2018I'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++).
- "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)
Agreed. Like I said, Steinberg.
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
To add to this topic, Maschine by Native Instruments does not support VST3 either... so hard to imagine Reason would...
Yan
Yan
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.
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.
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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.
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
ok, let me rephrase that: how many / which plugins are available _only_ in VST3 format ?EnochLight wrote: ↑17 Feb 2018Um.. except for the most of all major PC DAW manufactures adopting it part... sure.
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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.
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
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.htmlEnochLight wrote: ↑17 Feb 2018I 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.
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.
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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
ok, good to know (and thanks for the input, @joeyluck).EnochLight wrote: ↑17 Feb 2018I 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.
EnochLight wrote: ↑17 Feb 2018Well, 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.
- EnochLight
- Moderator
- Posts: 8407
- Joined: 17 Jan 2015
- Location: Imladris
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.bsp wrote: ↑17 Feb 2018As 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.
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
Well, they basically did the right thing.EnochLight wrote: ↑17 Feb 2018And 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.bsp wrote: ↑17 Feb 2018As 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.
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 ?
-
- Information
-
Who is online
Users browsing this forum: No registered users and 11 guests