RAM limits, particularly when using a 32 bit OS are not graceful happenings, often they can cause the audio driver to freeze operation and thus put out large bursts of noise.
Oddly enough, I ran 4GB ram on a Mac system, Cubase 6, fairly big projects, Trilian, NeoSoul keys, Halion… really did not have a lot of problems, occasional would lose power and audio would start to screech, but it held itself together pretty good, considering Cubase is not known to be efficient on MacOS, it may not be as powerful, but it can run on close to nothing.
Upgraded 64 bit, C7… only a short time so far, but on a Mac there are no such performance increases. I can not say “Oh so glad I’m 64 bit!!!” It is not like that over here, it feels a little good to be up to date, but there is no wow factor from quadrupling the memory Cubase uses. Still load up DC8C, anything with oversampling, still 50% ASIO is used, just like 4GB ram 32 bit.
Overwhelmingly, the main advantage of x64 systems is the potential to have Lots of available RAM, period. I haven’t noticed any other benefit, CPU usage or any otherwise.
Mauri.
This is W7 info, but it might help to get an idea.
This is the key. Cubase 7 is huge once loaded, leaving very few memory for the plugins. Also, when loading or releasing plugins there are peaks of memory consumption that may go beyond the limit and break the application.
“Although my OS is 64 bit, I’m still running my programs as 32 bit… (besides access to greater ram, which I already have since my OS is 64 bit)”
I’m not sure this is an entirely accurate statement?
64 bit here (v6.5.3), no problems, good times. No 32 bit plugs though.
Might be a good point. But how often do you hit the application RAM limit for a 32 bit process?
I believe that it is accurate - before 64 bit plugins were widely available, a lot of folks in these forums took the route of a 64 bit OS but installing Cubase/Nuendo 32 bit so as to have both the ram and all the plugins. As for myself, all of my 6GB of ram shows up under Windows 7 - but I couldn’t tell you whether the program is really accessing all of it since I don’t use a lot of virtual instruments and so I don’t think that I really tax it all that much. However I don’t really have many hiccups to speak of and things seem to run quite smoothly.
Depends of the projects involved. I remember having a lot of problems with XP : the RAM management of it was crippled to a point where Cubase was crashing as soon as there was 1.4-1.5 Gb used. With Windows 7, things are better but, as I purchased BFD2 (ten months ago) which uses several Gb only for loading a complete kit, I decided to use Cubase 64 since : didn’t have the choice, actually.
I even extended the RAM installed from 8 to 16 Gb in the process, just to avoid any problem. BFD2 is well known for being a RAM hog, but still : I no longer imagine working with Cubase in its 32 bits format again.
Huh - that’s odd. Never had a problem with XP. When I had 2 GB RAM, I used to push it to where usage in the the TM was reading 1.95. Never a problem. Then, when I had 4 GB RAM, I used the 3 GB switch, and pushed my projects to 2.9 GB. Never a problem.
Cheers.
Are you sure of this ? Because the RAM management with XP was well known for being a mess. As an example, I don’t remember what was its name, but even a mathematical software editor was warning all XP users about this limitation around 1.5 Gb of use with its main product which was using big tables of data, and it was also recommending the /3Gb switch at this time. I also used this switch and it allowed me 1.7-1.8 Gb free, no better. Far from ideal, even 3 years ago…
“I believe that it is accurate - before 64 bit plugins were widely available, a lot of folks in these forums took the route of a 64 bit OS but installing Cubase/Nuendo 32 bit so as to have both the ram and all the plugins. As for myself, all of my 6GB of ram shows up under Windows 7 - but I couldn’t tell you whether the program is really accessing all of it since I don’t use a lot of virtual instruments and so I don’t think that I really tax it all that much. However I don’t really have many hiccups to speak of and things seem to run quite smoothly.”
Hmmm, I was always under the impression that a 32-bit app would never access the RAM beyond 4Gb regardless of the OS (of course, if your OS was 64-bit and so were any other apps, at least it wouldn’t be competing for space as much), otherwise what would be the purpose of a 64-bit app?
But hey, as long as it works for you right?
Yes, I am sure of this.
–edit–
As I re-read everything, let me add something that I might not have made clear - it wasn’t 2.9 GB all in the project. I used jbridge to take advantage of the extra RAM. So, the project by itself was about 1.5 GB, and the rest (about 1.4 GB) was loaded into jbridge.
But still - never any issues with stability.
Ok, I wasn’t using JBridge at this time so, I was limited to something between 1.5-1.8 Gb, no matter what I tried.
Let’s say I’m much more at ease with my present 64 bits setup. The only problem is that I still have few 32 bits plug-ins that I don’t want to drop and I no longer expect 64 bits versions for them, sadly…
A very clear explanation about 32 VS 64 bit technology here : 32-bit vs. 64-bit tutorial | MeldaProduction
I was hitting it fairly regularly with Kontakt, which meant I had to use DFD or similar technologies in other plugins.
The problem is if you have presets that load a selection of instruments that you would like to instance and yet the RAM limit is already or nearly reached; then you must freeze tracks and/or remove instruments.
Also, don’t forget VST3 processes audio in 64 bits rather than 32 bits, thus if you are using VST2 pluings in a 32 bit host even on a 64 bit platform, you are always restricted to maximum 4GB per process.
There is a confirmed bug only in the 64-bit version of Cubase with regards to the Sample Editor Ruler not updating when changing the grid:(more info here Sample Editor ruler not updating on definition manual adjust - Cubase - Steinberg Forums)
Until its fixed,
32-bit > 64- bit…
64 bits is generally always better than 32 bits and a good thing in terms of software, but a bad thing when it’s something you bought from Ikea.
32bit Windows programs on a 64bit version of the OS are only ever given a sub-4GB addressing-limit process space, in which all its executable code and direct-access memory must reside.
Now, programs like DAWs run their plugins and instruments with their data in their space as well, so that VSTis could overload a 32bit DAW.
jBridge works because each VST(I) instance it runs is outside the DAW process space, but includes a stub inside the DAW space, and uses inter-process communication to convey information between the two. VST(I) hosts like VEPRo also function like this, which is why they can be run even when the DAW is disconnected.
This separation allows jBridge to bridge between 32 and 64bit DAWs and plugins. 32bit VST(i)s can have their own process space up to the sub-4GB limit, easing the memory burden for 32bit DAWs.
However, inter-process communication is not as direct as that between programs and libraries (which is what a VST(I) .dll is), and some VST(I)s have been known to be a bit upset about not being in the same space as the DAW.
Cubase’s VSTBridge totally worked within the DAW’s process space, but limited to a maximum of 2GB, and worked to only allow 32bit VST(I) to work in 64bit Cubase. Unfortunately the 32-64bit addressing and register conversion processes (known as thunking) used had serious issues, leading to lots of compatibility problems. One of the problems with being in the same process space is that any execution failure by anything inside the space can bring down the whole space.
jBridge was largely successful because it isolated problems in VST(I)s so that they didn’t propagate into the DAW space and bring it down.
64bit DAWs and 64bit VST(i)s can coexist in the same process space up to the maximum free memory (after OS overhead), but the same intra-process one down-all down problem still exists, but is unlikely to be an issue as long as there is enough RAM. However, that RAM can theoretically be as much as about 10^19 (10 to 19th power = 10 billion billion), which none us could afford, even if we could get that much physically close enough to the processor to be of use.