Seeing as Cubendo will drop VST2 on next release is anyone aware of a Jbridge type solution for the short /medium term as some plugin companies drag their heels on VST3 ?
I have not seen any statement to his effect, specifically.
Really? I thought I read this around C12 release time that it would be the last version to use VST2.
Whereâd you read that?
I was about to post this link I just refound - but yes- officially VST2 is on the wind down
From that page:
"Steinberg hosts continue to offer VST 2 compatibility. Users of Mac computers with Apple silicon can continue to use VST 2 plug-ins under Rosetta 2.
Moreover, within the next 24 months, Steinbergâs host applications and plug-ins across macOS and Windows will offer VST 3 compatibility only."
Are you on Mac? If not, donât worry, at least until 2024. Itâs a (warning) notice, thatâs all. You will still be able to use C12 (or previous versions if you have eLicenser licenses), and C12 can still host VST2 plugins without problems.
My personal approach is to drag my heels on buying anything from them.
I mean, to me it sounds like the next Nuendo or the one after it will likely not have VST2 based on that. The statement says âwithin the next 24 monthsâ so âsometime in the next 2 yearsâ and it was made at the beginning of the year, prior to the release of 12.
So, to me that says that 12.5/13 might not have it, since thatâll be somewhere in the in the next 12 months (historically new Cubase versions came out about once a year, around November/December) but it still could. However, the next version after that, 13/14 wonât have it.
A bridge like this is of interest since probably not all plugins will get updated. Most of my plugins are VST3 now, but not all, and it seems like some probably wonât make the move. While I wish companies would get on it, some just wonât. It seems like Avid is the only company with enough marketshare to just force a new plugin format whenever they want. VST3 has been out for over a decade and thereâs still tons that havenât bothered to change.
Just go for Blue Cat patchwork. DDMF also do one. And thereâs another huge release on the horizon that I canât mention exact details of.
Basically these are VST3 plugins that will give you a savable rack of VST2 & 3.
Go for it Phil!
Haha. Sorry for the teaser. NDA and all that.
Bidule seems to be working on it. The general release doesnât yet come in VST3, but there is a preliminary release that can do it to some degree, as well as introductory support for the new CLAP protocol. (Need to register Bidule to run the plugin variants, or get the latest releases).
Bidule can already bridge VST3 into a VST2 host really well (for both VST effect and VST instrument slots, and it does a whole lot more than simply bridge pluginsâŚhigh precision, and discrete processing compiles are available too).
Iâve had mixed results in Steinberg hosts (Cubase Pro 12 and Dorico 4) when hosting the current VST3 version (0.9781).
- Max of 4 outputs in Steinberg hosts.
- Issues getting the sidechain stuff working.
- General issues getting it to initialize and connected to the host as it should. Things I donât get with âother hostsââŚbut not so good in Steinberg hosts yet.
Iâm hoping (and pretty confident) that by the time VST2 is fully dropped in our Stenberg hosts, Plogue will have the VST3 version behaving as it should, and properly supporting as many inputs/outputs as you like (like the VST2 variant already does).
As a side note, Bidule is much more than a plugin chainer/bridge. While itâs not the most aesthetically pleasing thing to look atâŚitâs a very interesting host and instrument in its own right. I call it my âswiss army knife pluginâ. Super usefulâŚwedge features and abilities into a DAW all day long. One of my favorite things to use Bidule with Cubase for is those moments when I need to be able to throw in, or remove plugins while the transport is going without getting nasty glitches.
Ever wanted/needed to run a VST instrument in a VST effect slot, or vice verse? No problemâŚ
Use object oriented logic to host all the plugins you like inside an instance, and wire it all up as you wish (parallel, serial, some of both, whatever you want!). It has scads of monitoring and logic building tools to manipulate both MIDI and audio streams in real time. It provides filters, envelopes, bidules for mixing, gain-staging, playing/recording samples or D2D audio files, sequencers, arp engines, and a whole lot more. It can also be an OSC server, client, or both at the same time.
You can register any VST parameters inside Bidule with the main DAW. In essence, combine all the plugins you like into one âsuper pluginââŚregister VST parameters for the DAW as you like for automation (or electively set them up to run by MIDI events), etc.
Got stuff you want to automate with VST that doesnât register a VST parameter, but can be controlled via CC? No problem youâve got Param2CC bidules in there to convert that! Itâll also work the other way round. You can set up a CC2param bidule; then, link it to whatever VST paramter(s) you like). Want to link one remote control to MANY different parameters in the instance with independent scaling/max/min on each one? Stuff like that is a breeze inside a Bidule instance!
Wanna run some of this stuff with your iPad or Android device? OSC client/server has ya covered. Communicating among different instances is possible with some virtual MIDI ports, or over the OSC network.
If youâre into building effects and sounds that modulate based on math, random generators, etcâŚyou get tools for that as well, and they can be applied to both audio/sample streams, and/or to MIDI streams.
It might not look like much from that website, but itâs actually a powerhouse of a utility.
Just to clarify completely, that is not what they have said.
They said at the link above:
within the next 24 months, Steinbergâs host applications and plug-ins across macOS and Windows will offer VST 3 compatibility only.
Bidule is a superb application in its own right, but I think people are just looking for a simple solution that would enable them to continue using âgo-toâ plugins that wonât ever get upgraded to VST3. We had the same thing when Cubase went 64-bit-only (I think after C8.5?), and in the meantime there are solutions there too, Bluecat and DDMF were mentioned.
One problem that none of these solutions addresses, is for example Embracer: itâs a 32-bit plugin that came with Cubase SX that many got to love, but can no longer be used. Itâs not the fact that itâs 32-bit, or VST2, itâs the fact that when it loads, it checks whether the host is Cubase (or Nuendo) and refuses to work if itâs not. Thereâs nothing that any bridge technology can do to solve that (or is there? ); but maybe thatâs beside the point.
The bottom line is that Cubase will drop the ability to load VST2 at some point in the not too distant future, but as we can see, there is a market there for third-party products to fill this gap, so itâs not the end of the world.
Seriously, did nobody think of doing a search before coming up with that acronym?
Oh they probably did it on purpose. Something Iâve noticed about the open source community is they arenât just bad at naming, they take pride in choosing deliberately silly or stupid names. They never seem to consider how it can hurt adoption of their project.
But then, there are only so-and-so many people whose first language is (profane) English, most others couldnât care less.
I donât disagree at all. Iâve just found that itâs one of the few options out there to cross host/bridge different plugin protocols. For 32bit > 64bit, one would still need something like jBridge or X42 in tandem with Bidule.
It does provide a way to more easily âadaptâ older projects to work in different hosts with different plugin protocols.
Got an old project that was using the VST2 version with a bunch of other VST2 stuff hosted in that? Roll back if needed, save the bidule! Open in the new host. Load the bidule project. Back in business.
So, for now, thatâs what Iâve been doing with my newer projects. I just use Bidule VST2 and host anything that doesnât come in VST3 yet (or might never) inside bidule instancesâŚsave the bidule state(s) with the project. That way in the future hopfully I wouldnât have to âroll backâ and jump through hoops to use those projects again. All Iâd need to do is swap out the dead bidule VST2 instances for VST3 variants and reload their states.
Iâd found and tried a few things like X42. It can do VST2 host to VST3 plugins (32/64bit), but I had terrible luck trying it the other way around, and now that plugin is listed as âunsupportedâ. X42 was kind of interesting in that it provided some optional controller enhancements.
I donât know if Plogue would be interested in maintaining another app, but it stands to reason once they master VST3, they could rather easily release a âsimple bridgeâ based on the code and hard work theyâve already done for Bidule. Just strip out the fancy parts and only compile the bits they need into a kit thatâll make/install a wrapper and work in a similar way as jBridge.
Cool that these exist. I wasnât aware of them supporting VST2>VST3 already. Great news!
And thereâs Kushview Element. Single download: $5. https://kushview.net