I would like someone to help me understand how Cubase utilizes PC resources, particularly RAM: I have loaded a total of about 400MB of samples, 4 instances of Kontakt 5, 4 instances of Ozone reverb, and one instance of Altiverb: fine, if I check the resource manager, Cubase uses 1300MB, what is it doing that makes the consumption skyrocket to a value that is triple the loaded samples? Plugins are heavy, there's no doubt, but I have noticed that if I load a sample, the RAM usage increases proportionally much more than the weight of the sample itself, I don't know if I managed to explain myself: I load a 20MB sample and the consumption increases by 100MB.... why...? Maybe I have some settings configured incorrectly?
I use Cubase 5 at 32-bit on Windows 7 64-bit, I have set the Kontakt preload buffer size to 18 kb, is it perhaps too low?
Ok, thanks everyone, very interesting reads. I have jbridge but I use it rarely because it significantly slows down plugin loading; furthermore, jbridge itself weighs a ton. Just now, as I am finding my definitive orchestral template (or almost), I realize that one cannot operate satisfactorily at 32-bit. I will switch to a 64-bit version and maybe increase the RAM to 16 GB, since I already have Kontakt and various 64-bit plugins; it's just Cubase that I don't have in 64-bit...
Frank, I used Process Explorer but I can't figure out how to see if something is wrong; basically, it seems similar to the task manager, just more colorful....
Process explorer should provide the process tree and dependencies even graphically, so if there is some 32-bit process that is logically opened under a 64-bit application without going through wow... maybe there is some problem. In the sense that 32-bit applications cannot address more than 4GB of RAM... if they do, it means they aren't actually running at 32-bit. Something is acting as a bridge, which is why I imagine DiesIrae asked you about Jbridge, which obviously should be installed in 32-bit to avoid problems.
If the DAW is 32-bit, the bridge is useless... An audio bridge uses 32-bit processes inside 64-bit applications. The opposite could not work, especially in a context where performance is needed. In the end, all DAWs have now shifted to 64-bit since, at the moment, there are libraries that, for a single instrument alone, easily gobble up a couple of GB of RAM. If you are composing for an orchestra, once you have loaded the strings and some woodwinds/brass, you are already set.
A DAW is worth as much as another, but I remind you—as I had already told you privately—that the standard is Pro Tools; there is no doubt about that, it enters any serious recording studio here in Italy, it's the only one... In America, you might more often find Logic. In any case, Logic introduced 64-bit from version 9.1.6 onwards, while Pro Tools did so from version 11.
JBridge works because it also allows the opposite, that is, using 64-bit applications in a 32-bit host; in fact, in Cubase but also in Finale (both 32-bit), I can load 64-bit Kontakt via jBridge, although loading is much slower, but it does work and I can overcome the RAM usage limitation typical of 32-bit software, because jBridge creates a new .exe file that does not burden the host but appears as a standalone application in the task manager. Speaking of this template, I used jBridge only for the percussion, so as to stay within the 3 GB (which seems to be the maximum load supported by Cubase on my PC; it doesn't reach 4 GB...) with woodwinds, brass, and strings, plus another 500 MB with the percussion.
The only drawback, apart from the slow loading speed, is that you cannot have the same VST both "bridged" and non-bridged, so I had to bridge Kontakt 4 and leave version 5 at 32-bit; since many libraries are not read by Kontakt 4, I have to do a bit of sorting regarding what to put in 4 and what to put in 5... anyway, all this will be overcome by definitively switching to 64-bit, and I have also decided to increase the RAM to 16 GB.
The opposite could not work, especially in a context where performance is needed.
Using a 64-bit bridge for a 32-bit DAW implies that if you overload the bridge heavily, it must constantly erase and rewrite when importing into the DAW; that's why it is so slow. Normally, in fact, the bridge works correctly the other way around.
