If you are using a 64 bit DAW and have 32 bit plug-ins loaded in your set using jbridge, what happens when one of these plug-ins are finally released in 64 bit format? Specifically on a mac. Typically the VST simply gets updated with the same name. So all those instances you have loaded in your projects, will they automatically be recognized as now being 64 bit? When you remove jbridge once you no longer need it, will your projects still be able to open the VSTs that were loaded as 32 bit but have since become 64 bit?

Just remove the bridged version from the "PluginsBridgedFor64bitVSTHosts" folder.
I have found the compatibility of bridged vs native versions surprisingly transparent.

Cool. And when you do this, your hosts are able to load the new 64 bit VST with settings intact?

For me this has been flawless. Some things to remember tho... If possibkle keep seperate plugin folders for 32bit, 64bit and jBridge 64bit plugins... and try not to append your plugs with "(64bit)" or "(x64)" etc, as this can sometimes lead to 'missing plugins'.

that's good to know i wondered the same thing. I honestly presumed it WOULDN'T work!

I'll bet it doesn't work with AUs. That is, if Jbridge even supports AUs.

jbrdige doesn't support au's it is vst only. If he made a vst to au 64 bit wrapper he'd be a rich man

And if he made it a Win VST to AU wrapper, he'd be an incredibly rich man.
I know that won't happen, but seriously, how much would that be worth to you? 100? 200?

I don't agree fully as said that it's transparent.

The x64 version will have a differnt VST id, and projects store this id with the track it's loaded on.

So I found that you have to store preset used for the plugins separately to disk, to load these setting in new plugin.

When going x64 with Sonar I experienced this. Old project load but plugin missing and to load x64 version of plugin you need the settings for it.

So don't remove any x86 version until you have saved settings to disk. Hopefully vendor has made x86 version presets compatible with x64 version.

Anyway, one thing to consider.

That's only true on the PC though maybe? Mac 64 bit plug-ins are usually the same name and ID.

Hi!

They can ( or should be able to ) be replaced with a ( future 64bit ) native version of the plugin you're bridging. Neither jBridge / jBridgeM changes the plugin's unique ID ( nor any data that it saves/loads ). And, the ID is usually the same between 32bit and 64bit versions of the same plugin ( don't know every plugin out there of course, but it seems to be that way with the ones I use ).

However, please be aware that I have no control over the way the VST host uniquely identifies a plugin, it can rely on other stuff besides the ID such as the dll's name, the plugin's full path, the vendor's name, etc.

But, to avoid any concerns, do this simple test:

- Save a project with the bridged plugin you're using.
- change that bridged plugin for the native plugin again ( do the proper re-scanning if needed, etc ).
- Try to load the project you saved with the bridged version.

If your VST host recognizes it as the same plugin, you can rest assured that it will work with future versions of that plugin that won't require any bridging.

Hope this helps!

ps: let me get jBridgeM into v1.0 and I'll see what I can do regarding AU's. Still stepping unknown land here.

Wow, that would be awesome!
Would that eventually give you the "building blocks" to bridge also from VST to AU (I know there are already certain software for that, but not while also bridging between 32-bit and 64-bit) and vice versa (I know of nothing that can convert AU into VST.. best we can do is load it into a shell such as Plogue Bidule, MetaPlugin or similar?)

Hi!

It could be possible as well, but in the case of AU to/from VST bridging, I don't think that forward-compatibility with future versions of the plugins that were bridged could be assured, because in that case not only we would be bridging a specification between 32bit and 64bit architectures, but also converting one into another one... You'd probably always need the bridge there.

( Unless the host was somehow aware of it and could communicate with the bridge if it needed to later extract the original data from the adapted plugin )