HI Eratu,
remember i am not support :-) God help the guy i do support..
however i have not heard of anyone not happy with VE Pro. i see a lot of it
and yes Play now works...

Clint Swank


This is a very relevant topic for me, since I'm about to get my first computer with more than 4GB RAM (8, to be specific).  So, if someone could recap for me:  If I install W7 64 bit, and use Sonar 32 bit, I can only access 3,5GB RAM from Sonar, but I'll have all the 32 bit plugs, but if I use Sonar 64 bit, I get all 8 GB, but I'll have to use BitBridge (or something) to use those plugs, except Waves (which I have) which doesn't work at all, right?  

Will Windows processes other than Sonar (32 bit) access the unused 4 GB, and is there any benefit to that?  I.e. Will background functions intrude less on Sonar's operation?  Should I just install both Sonar 32 and 64 and see which works better? 

It's as simple as this:

Inside an x64 OS, you can basically have as much RAM as you want (there are limitations, but those are mostly irrelevant now due to most people's budget issues going above 16GB RAM -- EDIT: I believe Win 7 x64 Home Premium goes up to 16GB, but Win 7 x64 Pro goes up to 192 GB RAM ).

Each separate program you run is allocated its own memory space.

A 32-bit application can access up to a full 4GB *in theory* but in practice, you generally won't experience a blissful full 4GB... it all depends on the developer. In the real world, I've noticed stability issues with a variety of 32-bit apps (including DAW apps) that approach 3-3.5 GB. I doubt some of those apps were well-tested > 2GB to be honest, due to the way that Windows XP allocated memory for apps.

Anyway, under an x64 OS, every single separate 32-bit application that runs in its own process does indeed get up to a theoretical 4GB.

This is where the problems come in for 32-bit DAW apps... a VST plugin is essentially a DLL that is loaded as part of the host's process... in other words, Sonar 32-bit AND all of its plugins that it directly calls, are all running inside the same 4GB boundary, even if your computer running Win 7 x64 has far more RAM.

Now, Sonar x64 does not have that limitation. It can access the full amount of RAM in the system. However, it can only call x64 plugins.

So, that's where bridges come into play. There are four bridges out there -- Cakewalk's BitBridge (good), Steinberg's VST Bridge (sucks), Reaper's Bridge (good) and jBridge (also good). VE Pro can also be used like a bridge, but it's way more than that.

They all work slightly differently, but the basic idea is that a bridge will have two components: a separate host/wrapper for the 32-bit plugin you want to use, and then a method by which the that host/wrapper communicates with your 64-bit DAW.

In the case of Bitbridge, it spawns separate BitBridge servers, and then communicates with Sonar via some fancy-schmancy inter-process communication, making it more or less transparent to you. But what's actually happening is that a SEPARATE host program (the BitBridge server) is running along side your Sonar x64 as a SEPARATE process... and it's communicating via some magic glue that passes the audio/MIDI data streams behind the scenes. The key point of this is that each BitBridge server that is running has ITS OWN memory space -- again, it is a separate 32-bit process.

So what that means is that Sonar x64 -- which can access as much RAM is it wants to -- connects to each 32-bit BitBridge server instance, which can each access up to 4GB per server instance, since each one is a separate process. They do not share each other's memory -- they just have to request memory from the OS. Each BitBridge server can host many plugins... up to the limit of 4GB. In practice, this is not a problem since Sonar actually will spawn more BitBridge servers as needed, so you'll never run out of memory for Bridged plugins, up to the limit of your physical system.

Hope that makes sense.

Sonar's BitBridge is very well executed and mature, but it's not perfect. You may find issues later on with it. So I'd suggest you invest in jBridge as well, which uses a slightly different method and may work better in the situations where BitBridge is flaky.

jBridge is different than BitBridge in that it creates a SEPARATE process for EACH plugin instance (which may or may not be an advantage, depending on how you look at it). It also has the very cool feature that it will bridge 32-32, 32-64, 64-32 and 64-64... meaning, the following:

You could theoretically run Sonar 32-bit, and then use jBridge to host plugins OUTSIDE the main Sonar process and memory space. Meaning that on a 64-bit OS, jBridge would actually allow you to use as much memory as you have for your DAW, even with 32-bit plugs and 32-bit Sonar, in 4GB chunks for each 32-bit process. How does it do that? Well, because each jBridged plugin gets its OWN process and memory, and are NOT loaded directly into Sonar.... only the jBridge wrapper-connector (for lack of a better term) is, which connects to the separately spawned, independent jBridge micro-host process. Hope that makes sense.

As to whether or not you should choose to install 32-bit or 64-bit Sonar (or both) on Win 7 x64, there's no harm in installing both. Your DAW's ecosystem may be very different than mine, and you may have 100% success either way.

The theory is that if you have all x64-native plugins, you don't need to every worry about BitBridge, and this should be better than running 32-bit Sonar. However, this may or may not really be true... depending on what plugins you're using, etc.

My current theory is that as of right now, x64 DAW apps and plugins are just still not as well tested as 32-bit... so complex projects may reveal a degree of instability like I'm experiencing.

Either way, I'd suggest you avoid using bridges if possible, unless you've thoroughly tested your plugins and DAW apps for 100% stability with those combinations of apps/plugs.

Good luck!

I remember going from Win98 to WinXP and keeping my old Win98 machine for things that did not like XP. At the time it sounded like a good plan but in reality, I was always quick to find a replacement for that program that wanted to stay on W98.

Now I have a banging Win7-64 machine on the way and I've considered keeping my WinXP DAW running for programs that don't like Win7-64. The truth is, I most likely will not use it. Why repeat history? If Sonar instruments and effects, NI, Play and UA work under W7x64 I am more than covered. I expect the positive differences in speed to be great enough that I will never have any desire to go back for any reason. Most likely I will format my WinXP machine after a few weeks and make it a backup Win7-64 DAW.

If one of my hardware synths breaks my projects don't stop. I find another keyboard that I like and move on. I now have the same attitude with VSTi's. There is always something else to use...

eratu

jcschild


HI Eratu,
remember i am not support :-) God help the guy i do support..
however i have not heard of anyone not happy with VE Pro. i see a lot of it
and yes Play now works...

Good to hear... yeah, it's very tempting to go that direction... it will be a big change in the way I work, though... for good and ill. I love the idea of offloading all the memory-hungry VIs to VE Pro... especially onto another, external machine... but that will require a change in how I do plugin automation, work with the interfaces, etc... as you well know.

why not just run VE Pro on the same system (as well as off load)
you get 3 licences
 
 

Either way, I'd suggest you avoid using bridges if possible, unless you've thoroughly tested your plugins and DAW apps for 100% stability with those combinations of apps/plugs. Good luck!

 
 
Wow! My head is still spinning. Now I know why I didn't go X64. So VE Pro handles this scenario differently than the other bridges?

Crg
 
Wow! My head is still spinning. Now I know why I didn't go X64. So VE Pro handles this scenario differently than the other bridges?

VE Pro handles things a little differently, yes... but the basic principle of hosting the plugins in a separate process is similar.

VE Pro has a server component that isn't JUST a hosting server that communicates with the DAW... it's a full hosting environment with a very nice mixer, and you can essentially set up an entire virtual rack of synths that sit outside of whatever DAW you're using.

Then, you load a separate VE Pro plugin into your DAW, which essentially sets up pipes to connect to the various VE Pro servers you've created. Those data pipes can access separate VE Pro servers that are running locally on the same machine, or -- SO COOL -- over the network. :)

The only things transmitted to and from the VE Pro server are MIDI and Audio data. The DAW doesn't actually SEE the plugins themselves, other than as MIDI ports and data streams. So in that sense, VE Pro is very different than the bridges, because the bridges try to transparently wrap (using the the term "wrap" here loosely) the plugins, so that the DAW host sees them as native plugins.

So, just think of VE Pro as a massive outboard mixer/rack of VI goodness that's wired into your DAW with virtual MIDI and audio cables.

Think of the bridges as wrappers around each plugin to make the DAW see the bridged plugins as native plugins (but in reality, they aren't).

When Windows 7 came out, I installed the 64 bit version on one hard drive and the 32 bit version on the other. Some of my programs didn't work right with the 64 bit version and I tried the 32 bit version and everything, I mean everything works perfectly with it, NO problems to report at all, solid as a rock.

My next upgrade will be to a Windows 7-32 bit on a SSD drive, some time in the next few months, if the prices come down as expected. 

Well, I just went over to W7 x64 yesterday.  I loaded both Sonar x64 and x32, and so far the I like 32 bit a lot better.  My new laptop (HP 8730w, Core 2 quad X9300, 8 gig RAM) isn't breaking a sweat on just the available 4gig RAM,and using 64 I lost a lot of plugs (Waves in particular), and had some clicks and pops as well.(I'm not sure that I trust the Zoom 64 bit driver, either.)  Sonar 32 is smooth as glass on this rig. I'm getting Vienna Ensemble Pro soon--we'll see if that clears some things up, but for now  32's working fine.

i meant win7 64... not Sonar 64

dive into VE PRo.. i think you may be pleased.

It's as simple as this: Inside an x64 OS, you can basically have as much RAM as you want (there are limitations, but those are mostly irrelevant now due to most people's budget issues going above 16GB RAM -- EDIT: I believe Win 7 x64 Home Premium goes up to 16GB, but Win 7 x64 Pro goes up to 192 GB RAM ). Each separate program you run is allocated its own memory space. A 32-bit application can access up to a full 4GB *in theory* but in practice, you generally won't experience a blissful full 4GB... it all depends on the developer. In the real world, I've noticed stability issues with a variety of 32-bit apps (including DAW apps) that approach 3-3.5 GB. I doubt some of those apps were well-tested > 2GB to be honest, due to the way that Windows XP allocated memory for apps. Anyway, under an x64 OS, every single separate 32-bit application that runs in its own process does indeed get up to a theoretical 4GB. This is where the problems come in for 32-bit DAW apps... a VST plugin is essentially a DLL that is loaded as part of the host's process... in other words, Sonar 32-bit AND all of its plugins that it directly calls, are all running inside the same 4GB boundary, even if your computer running Win 7 x64 has far more RAM. Now, Sonar x64 does not have that limitation. It can access the full amount of RAM in the system. However, it can only call x64 plugins. So, that's where bridges come into play. There are four bridges out there -- Cakewalk's BitBridge (good), Steinberg's VST Bridge (sucks), Reaper's Bridge (good) and jBridge (also good). VE Pro can also be used like a bridge, but it's way more than that. They all work slightly differently, but the basic idea is that a bridge will have two components: a separate host/wrapper for the 32-bit plugin you want to use, and then a method by which the that host/wrapper communicates with your 64-bit DAW. In the case of Bitbridge, it spawns separate BitBridge servers, and then communicates with Sonar via some fancy-schmancy inter-process communication, making it more or less transparent to you. But what's actually happening is that a SEPARATE host program (the BitBridge server) is running along side your Sonar x64 as a SEPARATE process... and it's communicating via some magic glue that passes the audio/MIDI data streams behind the scenes. The key point of this is that each BitBridge server that is running has ITS OWN memory space -- again, it is a separate 32-bit process. So what that means is that Sonar x64 -- which can access as much RAM is it wants to -- connects to each 32-bit BitBridge server instance, which can each access up to 4GB per server instance, since each one is a separate process. They do not share each other's memory -- they just have to request memory from the OS. Each BitBridge server can host many plugins... up to the limit of 4GB. In practice, this is not a problem since Sonar actually will spawn more BitBridge servers as needed, so you'll never run out of memory for Bridged plugins, up to the limit of your physical system. Hope that makes sense. Sonar's BitBridge is very well executed and mature, but it's not perfect. You may find issues later on with it. So I'd suggest you invest in jBridge as well, which uses a slightly different method and may work better in the situations where BitBridge is flaky. jBridge is different than BitBridge in that it creates a SEPARATE process for EACH plugin instance (which may or may not be an advantage, depending on how you look at it). It also has the very cool feature that it will bridge 32-32, 32-64, 64-32 and 64-64... meaning, the following: You could theoretically run Sonar 32-bit, and then use jBridge to host plugins OUTSIDE the main Sonar process and memory space. Meaning that on a 64-bit OS, jBridge would actually allow you to use as much memory as you have for your DAW, even with 32-bit plugs and 32-bit Sonar, in 4GB chunks for each 32-bit process. How does it do that? Well, because each jBridged plugin gets its OWN process and memory, and are NOT loaded directly into Sonar.... only the jBridge wrapper-connector (for lack of a better term) is, which connects to the separately spawned, independent jBridge micro-host process. Hope that makes sense. As to whether or not you should choose to install 32-bit or 64-bit Sonar (or both) on Win 7 x64, there's no harm in installing both. Your DAW's ecosystem may be very different than mine, and you may have 100% success either way. The theory is that if you have all x64-native plugins, you don't need to every worry about BitBridge, and this should be better than running 32-bit Sonar. However, this may or may not really be true... depending on what plugins you're using, etc. My current theory is that as of right now, x64 DAW apps and plugins are just still not as well tested as 32-bit... so complex projects may reveal a degree of instability like I'm experiencing. Either way, I'd suggest you avoid using bridges if possible, unless you've thoroughly tested your plugins and DAW apps for 100% stability with those combinations of apps/plugs. Good luck!

This was incredibly helpful.  Thank you!

CPU and ALU 64 bit architectures are based on 2003 records buses.In direction were introduced into the arena team integrated personnel in the form of the x86-64 and 64 architectures.A bit PowerPC exchange for a 32 bit to 64 bit architecture is a fundamental change, as most operating systems should be fundamentally changed to take advantage of the new architecture.