"j-bridged" plugins

[UpTilDawn]

I still use and have the need for SAW-32 and SAW-64, as well as 32 and 64 bit plugins - often in either SAW sessions.
Oftentimes, I'm finding that I have duplicate plugins in the list, either of which will open just fine, but have begun to clutter up the list. I won't weed the list out just yet, because I've already had to deal with "corrupted" settings in older sessions, when I've attempted to do so.

Given that, I'm wondering....

Is there a qualitative and/or functional difference between plugins that have been "jbridged", vs those that are "normal" in their respective host?

[mr_es335]

UpTilDawn,

I am not sure if this reply will be of any assistance or not, but in my recent discussions with various plug-in developers, the same three "things" were noted, namely 1) math development, 2) core development, and 3) UI development.

If this observation is true, then it would appear that it would be the "math development" that would ultimately determine, as you say, "...the qualitative and/or functional difference between plugins that have been 'jbridged' vs those that are 'normal' in their respective host"...?

It also might be interesting to note that the common term employed when transferring one digital format to another is the term "rendering".

Armed with this information, I would contact the developers and ask then the appropriate questions. Their responses just might be a "bit" interesting!

[Dave Labrecque]

My gut says there is no difference, quality- or other-wise. But you can check it yourself to see if there's a difference if not to determine which is "better." Do a null test. Identical tracks except for the plugin version in question. Build mix the two together with the phase on one flipped. See what you get.

For example many claim that doing this test with native vs. DSP versions of the UAD plugins yields a complete null in the output, indicating identical processing between the two versions.

[UpTilDawn]

Okay - understood about the sound quality aspect..... everything I've read/heard says that sound quality is not a factor when talking about the dif. between the 32 and 64 bit environment. So, I guess I should have defined my question better. So also, thanks for the reminders.

What I'm really trying to understand - in a very general sense - is whether a bridged 64 bit plugin is "better" to use in SAW32 than the same plugin in 32 bit version... when both are available in the list.

A second question would be the opposite - a bridged 32 bit plugin in SAW64 vs. the same plugin in 64 bit form.


I'm starting to get a glimmer of an idea about how the 32 bit applications can affect processing in the 64 bit environment (and thus why I should maybe not be so tied to wanting to use the old LE version of Photoshop in Win10/x64, even though it works much easier for my needs than newer versions, for instance... ha!). But I'm still trying to grasp if there's a qualitative/functional difference in SAW, when using a bridged version of a plugin - in general and not specific to any one manufacturer's product.

I'm wanting to figure out how best to organize the plugin lists in both 32 and 64 bit versions of SAW, while also doing the least damage to the old 32 bit sessions, as I slowly begin to archive them. This is especially concerning to me, since I am finding reasons to revisit older sessions these past couple of years.

[cgrafx]

Keep your 32-bit sessions and 64-bit sessions separate.

There is no reason to load all of your 32-bit and 64-bit VSTs in both versions of SAW Studio.

The 32-bit version of Saw Studio should really only have 32-bit VSTs/plugins

The 64-bit version of Saw Studio should only have 64-bit VSTs/plugins and any legacy 32-bit plugins that don't have a 64-bit equivalent.

Need to open an old session, open it in the version of Saw Studio that was used to create the session along with the plugins that were used to create the session.