VST3 is the future for new plugins

[abacab]

We knew this was coming for years...

VST 2 coming to an end

https://www.steinberg.net/en/newsandevents/news/newsdetail/article/vst-2-coming-to-an-end-4727.html

... and this recently from the developers of the free and open source Surge Synth.

Quote

VST2 is not free and open source software, and Steinberg, the copyright owner of the VST2 code, is no longer making licenses available to developers. With the Surge 1.7 family we are moving to having binary distributions of only Free and Open Source software, so are no longer distributing a VST2.

Obviously your old VST2 plugins will continue to work, and developers wishing to create commercially licensed software that already have a Steinberg VST license can still do so. But this will exclude new developers and those wishing to go down the open source road.

 Opinions? ?

[Bapu]

yay?

[marcL]

IMHO it is a shame that so many really good plugins are more and more disused, because the fxxxing Steinbergs always change the concept. I have a long list of disadvantages for VST3 compared to VST2, maybe there are a few technical advantages, too. But I am sure that the advantages do not outweigh the disadvantages, especially for the users (audio engineers, musicians). Like that, for years many of us have to deal with 3 to 4 plugin versions at the same time (32-bit vst2/3, 64-bit vst2/3) caused by the Steinfrog's dictatorship. I know, there are those ones that conjure not to use 32-bit anymore! But if you use additional hosts like SoundForge 11 or Audacity, ... ?

In my first sentence I mentioned good plugins and I know a couple of extraordinary, exquisite 32-bit plugins (most free). Even me do not use them anymore to avoid the organisational trouble. Though it is a pity, because I like more and more the plugins that have a simple, straightforward authorization and most of them are old ones (but there are some exceptional developers also nowadays).  Why do I speak of authorization? A week ago one of my systems failed and until today I am fighting with authorization and other recovery!

I guess it will be the 2nd huge loss of plugin resources for us when VST2 is goes away, not all plugins will be updated to VST3 (especially the free ones and the ones of small manufacturer). ?

[Robert Bone]

Well, existing VST2 plugins will continue to work, for years, and while I am saddened by some 32-bit plugins I loved, mostly freeware,  that just either do not run, or are unstable in 64-bit hosts (even with Bit-Bridge or J-Bridge), I am actually enjoying a very stable environment, with 64-bit VST 2 AND VST 3 running in Windows 10. (for many years now).

Cakewalk by Bandlab, by default, hides VST 2 plugins that have a VST 3 version, and things work quite well for me.  Yes, somtimes some company's VST 3 plugin(s) don't work right, and we all have to revert to the VST 2 versions, until they patch the issues, but that doesn't happen too often.

For any 32-bit VST 2 plugins I still want to use, I place those in a J-Bridge Candidates folder, then run J-Bridge, outside of CbB, with J-Bridge configured to put the resulting wrapped plugin into a J-Bridged Plugins folder that lives in my C:\\Program Files (x86)\VST32  folder for 32-bit plugins, and ONLY that J-Bridged Plugins folder, from my 32-bit plugins, gets added to the search path for VST 2 plugins. 

This is a simple management approach, that lets me use ONLY those 32-bit plugins I have both bridged with J-Bridge, and have tested,  Additionally, with the CbB Preferences > File > Initialization File parameter added, called VSTPlugInNameFormat, I can control how the Browser Pane plugin names are displayed. 

Here is the documentation blurb on its values and results:

Per the help guide, the Cakewalk.ini can be configured with the below setting to determine how plugin names are displayed. 
 
VSTPlugInNameFormat=
<0 - 3>
Integer
0
This variable specifies how VST plug-in names are formatted in the Browser, FX Rack context menus, and anywhere else VST plug-in names are displayed. The values are as follows:
0 = VST Name
1 = DLL Name
2 = VST Name (DLL Name)
3 = DLL Name (VST Name)

I currently use the '0' setting, so it displays plugins using the VST name, which also shows the J-Bridged 32-bit plugins as, for example:

 

This way, I always know if I am about to insert a J-Bridged 32-bit plugin.

Also, in the above screenshot, all of the goldish colored plugins are VST2 plugins, while the Crromaphone plugin is a VST3 plugin.

And, if ever not sure, clicking once on a plugin, results in a display of that plugin's type VST2 OR VST3) appearing at the bottom of the list of plugins in the Browser Pane.

Bob Bone

 

[msmcleod]

I actually prefer to do the JBridging all within CbB rather than use JBridger.  There's only a handful of 32 bit plugins that work better with BitBridge (and if IIRC, they're the old Cakewalk ones), so nearly all my 32 bit plugins are JBridged by setting the "Use JBridge Wrapper" flag within plugin properties.

There's one advantage in doing this... when using JBridger, it assigns a new unique plugin DLL and a new Id for the wrapper, which is different from the original plugin id. 

If you use the built in JBridge wrapper in CbB, the old plugin id retained. That way, if you swap back to BitBridge, or even manage to get a 64 bit version of the plugin at a later date, CbB will recognise it as being the same plugin and load it normally whether it's BitBridged, JBridged or 64 bit native.

 

[marcL]

10 hours ago, Robert Bone said:

Well, existing VST2 plugins will continue to work, for years,

Generally that is true, but if VST2 is no longer an "active" plugin variant, then its support in DAWs and Audio Editors will become more and more outdated. The focus will go to VST3. We have seen this already in the last 2 years, also with plugin manufacturers. The positve is that it will come a day when most of the current plugins are VST3 (but then there is probably VST4 ?), but as said then it will be up to you to handle old VST2's (32 and 64-bit).

One thing that I really dislike with VST3 is that most installers do not allow to choose the VST3 subdirectory path/structure and so it gets a bit chaotic in the folder. Okay, you can move them manually (with almost all plugins except XLN Audio's and Celemony's), but this is really a step backwards! Also preset handling gets more and more diverse, because many manufacturers invented their own "exotic" way. I guess caused by the lack in the VST3 specification and the double effort for VST2/3 and other formats.

The other thing is that if you use older DAWs, Editors that are 32-bit or don't support VST3, then you have to install the same plugins in 3 versions and this is awkward IMO.

[abacab]

Ableton finally added VST3 support to Live (10.1 build).

The only plugin host that I use without any VST3 support yet is Akai VIP. Come on Akai...

As far as I know, only VST2 plug-ins and virtual instruments are currently compatible with Reason 11, but ironically the Reason Rack plugin is VST3 only... but coming from a company that lacked any VST support for years not surprising...

There are probably others...

[Starise]

This might be a good time for all DAW makers to unify over a new standard and tell Steinberg to take a hike.

We did it with midi and vsti instrument shells why can't we do it with plugins? Develop a free easily ported standard that all  plug in makers can adopt and stop paying licensing fees to Steinberg. There really is no reason why this couldn't be done. I mean, The  plugins in the Pro Channel inside of Cakewalk are nothing but re written vsts. This was done 10 years ago?  Think outside of the box. Go bigger.

All you need for this to happen is-

A. A new standard that doesn't infringe on vst3 copyright.

B. Widespread adoption by DAW and plugin writers.

I'm not a programmer or I would be tempted to give it a shot.  Someone needs to roll the ball here. You could start out with a bunch of free plugins in the new standard to get people interested/started. 

[abacab]

20 minutes ago, Starise said:

This might be a good time for all DAW makers to unify over a new standard and tell Steinberg to take a hike.

We did it with midi and vsti instrument shells why can't we do it with plugins? Develop a free easily ported standard that all  plug in makers can adopt and stop paying licensing fees to Steinberg. There really is no reason why this couldn't be done. I mean, The  plugins in the Pro Channel inside of Cakewalk are nothing but re written vsts. This was done 10 years ago?  Think outside of the box. Go bigger.

All you need for this to happen is-

A. A new standard that doesn't infringe on vst3 copyright.

B. Widespread adoption by DAW and plugin writers.

I'm not a programmer or I would be tempted to give it a shot.  Someone needs to roll the ball here. You could start out with a bunch of free plugins in the new standard to get people interested/started. 

 

I believe VST3 is GPL. That is why the Surge devs have turned to it for their free open source license.

 

Quote

 

Here you can find the new License for the VST 3 SDK

https://sdk.steinberg.net/viewtopic.php?f=4&t=282

 

 

Quote

 

https://en.wikipedia.org/wiki/GNU_General_Public_License

The GNU General Public License (GNU GPL or GPL) is a series of widely used free software licenses that guarantee end users the freedom to run, study, share, and modify the software. The licenses were originally written by Richard Stallman, former head of the Free Software Foundation (FSF), for the GNU Project, and grant the recipients of a computer program the rights of the Free Software Definition.

 

 

Edited July 31, 2020 by abacab

[Starise]

UPDATE- You edited your reply that answered my question 

 

Edited July 31, 2020 by Starise

[abacab]

1 minute ago, Starise said:

Not sure what GPL is?  The implication is it is free. This may be true, however Steinberg seem to be controlling how long the code is relevant. It might be similar to Cakewalk being free but one day they come along and say, "We have improved our program, in order to use it though you can't use any older versions." 

Money must be involved here in some way. Why would Steinberg give it away to their competition for free?

Steinberg VST 3

Please see my comments edited above. Have added a link to the Steinberg VST3 license which clearly establishes it as a GPL licensed technology. Also a link to the GPL description at Wikipedia.

Sorry for any confusion I may have caused.

[Starise]

Thanks abacab.  I'm just not quite sure what the love is for Steinberg designed software over other potential alternatives? One man is responsible for both ASIO and VST development.

While I think plugin makers need a standard, I don't quite understand why everyone adopted Steinberg software into their DAWs? Yes it is free. Is that the only reason? 

Is it really that no one else wanted to attempt it? Because it was easier to take a free tool that works? I think if it were a non profit entity that oversees it I would feel more comfortable about it. 

The bottom line for many is simply the inconvenience of planned obsolescence. Eventually VST 2 will become obsolete since VST 3 is built on another system. I would like to see a more backwards compatible system where one shell can house several different designs and not be phased out .  Software has been based on upgrade paths for profitablity  and not because it could not have been more backwards compatible. Plugin designers are not making money if they have to redesign their plugins every 5 years because the wrapper was changed. I like to see improvements as an  option. Am I overly opinionated? Probably....but I know what I want and I suspect many others aren't happy with the eventual end of VST2.

Look at 26:20 on this video. Before that he says GPL ok for a "university".  Sounds like the rest need to get a license.

 

Edited July 31, 2020 by Starise

[Jim Fogle]

Of course there are other plugin specifications beside VST.  AVID has AAX, Apple has AU and Linux has LSP.  To my knowledge LSP is the only plugin specification that is truly open source.  More information is available here:  https://lsp-plug.in/

[abacab]

2 hours ago, Jim Fogle said:

Of course there are other plugin specifications beside VST.  AVID has AAX, Apple has AU and Linux has LSP.  To my knowledge LSP is the only plugin specification that is truly open source.  More information is available here:  https://lsp-plug.in/

Of course, but those formats are of little interest to Cakewalk users using Cakewalk, since it has no support for AAX or AU, etc.

Cakewalk being the assumed scope of this particular forum, "Cakewalk Products > Instruments & Effects ... ?

[abacab]

On 7/31/2020 at 11:01 AM, Starise said:

Thanks abacab.  I'm just not quite sure what the love is for Steinberg designed software over other potential alternatives? One man is responsible for both ASIO and VST development.

While I think plugin makers need a standard, I don't quite understand why everyone adopted Steinberg software into their DAWs? Yes it is free. Is that the only reason? 

Is it really that no one else wanted to attempt it? Because it was easier to take a free tool that works? I think if it were a non profit entity that oversees it I would feel more comfortable about it. 

The bottom line for many is simply the inconvenience of planned obsolescence. Eventually VST 2 will become obsolete since VST 3 is built on another system. I would like to see a more backwards compatible system where one shell can house several different designs and not be phased out .  Software has been based on upgrade paths for profitablity  and not because it could not have been more backwards compatible. Plugin designers are not making money if they have to redesign their plugins every 5 years because the wrapper was changed. I like to see improvements as an  option. Am I overly opinionated? Probably....but I know what I want and I suspect many others aren't happy with the eventual end of VST2.

Look at 26:20 on this video. Before that he says GPL ok for a "university".  Sounds like the rest need to get a license.

 

Thanks for that video, it was very informative!

Well. the first point is that without questioning why or how Steinberg ended up in this role, VST is a current standard 20+ years in the making. Plus they are now fully owned by Yamaha, so they do have some industry weight behind them.

I'm not opposed in any way to a workable plugin standard that is controlled by a non-profit org, such as MIDI.org has done with the MIDI spec.

But those standards are decades in the making by the very nature of the concepts of a standard. You need ALL of the equipment and/or software manufacturers to sign up for said "standard". Otherwise we are back in the wild without a standard, and with each manufacturer releasing their own. And efficiency by committee is not the fast track by any means!

Edited August 1, 2020 by abacab

[Jim Fogle]

@abacab, excuse me for not understanding the conversation was only limited to Cakewalk.  @Starise's comment,

Quote

This might be a good time for all DAW makers to unify over a new standard and tell Steinberg to take a hike.

We did it with midi and vsti instrument shells why can't we do it with plugins? Develop a free easily ported standard that all  plug in makers can adopt and stop paying licensing fees to Steinberg. There really is no reason why this couldn't be done. I mean, The  plugins in the Pro Channel inside of Cakewalk are nothing but re written vsts. This was done 10 years ago?  Think outside of the box. Go bigger.

All you need for this to happen is-

A. A new standard that doesn't infringe on vst3 copyright.

B. Widespread adoption by DAW and plugin writers.

led me to assume the conversation reached beyond a single DAW.  My mistake.

[abacab]

1 hour ago, Jim Fogle said:

@abacab, excuse me for not understanding the conversation was only limited to Cakewalk.  @Starise's comment,

led me to assume the conversation reached beyond a single DAW.  My mistake.

No mistake. Just trying to reign it in a bit for the local audience, otherwise it could become  a global discussion. Thanks for your input!

[Starise]

I think it's the path of least resistance and not necessarily that an alternate solution that couldn't be reached. abacab, you are correct. I took the discussion to a broader application than Cakewalk. Hence why I said I think people could be "thinking outside the box". 

It is often this closed mentality thinking and " this is the way we've always done it"  that impedes progress. JMHO....oh yes I am opinionated. lol! This isn't politics or religion so I see nothing wrong with having thoughts on it.

I really wish I had the know how to do it. I would take a crack at it. I don't think getting multiple DAW software makers to  sign on would be so difficult. It isn't actually a plugin, it's a plugin interface. The real brains seem to come in making the actual plugins. Mr. Steinberg was a visionary who made VST 1.0 and handed the dev to someone else.  These things always start small. I mean, you can't start big. 

[abacab]

22 minutes ago, Starise said:

I think it's the path of least resistance and not necessarily that an alternate solution that couldn't be reached. abacab, you are correct. I took the discussion to a broader application than Cakewalk. Hence why I said I think people could be "thinking outside the box". 

It is often this closed mentality thinking and " this is the way we've always done it"  that impedes progress. JMHO....oh yes I am opinionated. lol! This isn't politics or religion so I see nothing wrong with having thoughts on it.

I really wish I had the know how to do it. I would take a crack at it. I don't think getting multiple DAW software makers to  sign on would be so difficult. It isn't actually a plugin, it's a plugin interface. The real brains seem to come in making the actual plugins. Mr. Steinberg was a visionary who made VST 1.0 and handed the dev to someone else.  These things always start small. I mean, you can't start big. 

A little broader question about standards. Why is MIDI.org in charge of the MIDI standards? We should probably have a better digital music interface considering it's taken several decades to get where we are.

And then there is this IEEE Standard Association  committee that decides how our Wi-Fi works (IEEE 802.11x), among a zillion other technical things: https://en.wikipedia.org/wiki/IEEE_Standards_Association

Sorry to ramble off topic, but in my opinion standards are the glue that holds the world together, and informs manufacturers that the products that they produce will be compatible with other manufacturers. We have entered an age of interconnected things. A lot of time and effort by experts in their respective fields must work together  to develop standards. So yes, I agree that the path of least resistance is probably what leads to a standard that is accepted by the majority. [/ramble off].

Final thoughts on plugin interfaces... why do we still have VST, AU, AAX, and others, rather than one for all?

Edited August 4, 2020 by abacab

[Starise]

You probably heard about the new MIDI 2.0 spec.? 

Maybe I mistakenly thought the spec worked pretty well up until now. MIDI.org has been making changes along the way . The spec allowed for some manufacturers to get creative with it. Both Yamaha and Roland adopted some factory specific commands back in the day. I think I like that MIDI.org are in charge of it because it establishes a  standard. Lots have cried that it was behind the times. I don't think it really is when you consider all of the possibilities that have been adopted since using it. Most people who use it never use it to the full potential. I mostly use it when playing sample libraries. 

This is exactly the kind of thing I believe would be helpful to the plugin industry. Call it PLUGIN.org or whatever.  If we had one wrapper that would play both older and more recent versions of plugins in the same wrapper lots of people would be happy. Or maybe just several wrappers that all work in any DAW. Not sure how MIDI.org gets their funding. Maybe a token contribution from members keeps them going? Another benefit is all members could have input into the process.

On the different specs for plugin wrappers. Just proprietary stuff I guess. Makes more work for the developers .