Does a VST3->VST2 Jbridge style wrapper exist?

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?

VST 2 Discontinued – Steinberg Support

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.

1 Like

My personal approach is to drag my heels on buying anything from them.

2 Likes

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.

1 Like

:+1: Go for it Phil! :clap: :wink:

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).

  1. Max of 4 outputs in Steinberg hosts.
  2. Issues getting the sidechain stuff working.
  3. 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.

1 Like

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? :thinking:); 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?

When used on 3rd order Ambisonics track, I have 16 I/O with Bidule.

1 Like

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.

1 Like

But then, there are only so-and-so many people whose first language is (profane) English, most others couldn’t care less. :wink:

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

1 Like