A way to increase Cubase 32-bit memory allocation?

Audio Plugin Hosts and other audio software applications discussion
RELATED
PRODUCTS

Post

Hey all,

I'm using Cubase 4 32-bit under Win7 64-bit OS. As I understand it, Cubase 4 32-bit can only access 2gb RAM, which includes all the memory that plugins running under it can access (barring special tricks).

Is there a way to expand the amount of memory the Cubase 32-bit process can use? Like, a configuration file entry or preferences setting? I would be totally fine with moving up to Cubase 8 32-bit if necessary, although I want to stay 32-bit.
A well-behaved signature.

Post

The 2GB limitation is not some arbitrary restriction that Steinberg put on Cubase. It's an architectural limitation on the max amount of addressable memory available to 32-bit processes on Windows, so upgrading to 32-bit Cubase 8 won't help.

You can use jBridge to work around this limitation by wrapping your 32-bit plugins on your 32-bit host- this works by distributing the RAM burden across multiple jBridge instances.

Of course, if you have jBridge and a 64-bit OS, you can also use it to wrap your 32-bit-only plugins on a 64-bit host that doesn't have the same RAM limits...

Post

The limit for 32-bit should be 4GB rather than 2GB. I've no idea what individual bits of software do though.
[W10-64, T5/6/7/W8/9/10/11/12/13, 32(to W8)&64 all, Spike],[W7-32, T5/6/7/W8, Gina16] everything underused.

Post

jabe wrote:The limit for 32-bit should be 4GB rather than 2GB. I've no idea what individual bits of software do though.
From the horses mouth.
Memory Limits for Windows and Windows Server Releases

Post

Thanks fellas!

I'm gonna try to set the flag mentioned in the article Ayorinde posted.
A well-behaved signature.

Post

JerGoertz wrote:Thanks fellas!

I'm gonna try to set the flag mentioned in the article Ayorinde posted.
I think that's a programming thing that has to be done when compiming the code for the executable. :(
Hope, for a change, to be wrong! :tu:

Post

32-bit apps on win64 can address 4gb (rather than 2gb) only if the executable has the 'large address aware' bit set. Sadly very few developers ever bothered to set that option (photoshop was one of the few that did from memory), but if you're feeling brave you can use a utility to set the bit on the app and test it (basically keep adding stuff in cubase till it either blows up or has >2gb allocated sucessfully)

https://www.techpowerup.com/forums/thre ... re.112556/

certainly worth a go - back when I was running 32-bit os with PAE (which again gets around the 32-bit 2gb app limit) it certainly worked for a few things

Post

A 32bit pointer can address 4GB of memory, yes.. but:
1) 1GB is not accessable to user-mode applications, but it is reserved for the kernel (Windows)
2) 32bit unsigned pointers can address 4GB, but 32bit signed pointer cannot - they can address 2GB

Because of 2), accessable memory for 32bit applications is restricted to 2GB by default.
There is a switch to increase this 2GB to 3GB (4GB total - 1GB of kernel space = 3GB).
You can also change this flag after compile, but the source code needs to be prepared for it.
i.e. it is quite common to do stuff like this:

Code: Select all

#define BUFFER_SIZE 32768
BOOL  IsPointerInsideBuffer(const BYTE *p, const BYTE *buffer) {
  return p >= buffer && p - buffer < BUFFER_SIZE;
}
Works perfectly fine with 2GB of address space.
It's a bug on 3GB: there can be a signed integer underflow. If the two pointers are more than 2GB apart, the result of the subtraction is a negative number.
So you can try to set the "large address aware" bit, to get 3GB instead of 2GB, but the application might just crash afterwards because the code is not prepared to handle it

Post

Of course, the other option is to find someone who will sell you v5 (or 6) which are 64 bit.

I don't have Cubase anymore (had 8 briefly), but I've heard 6/6.5 was the favorite version among a lot of users.

Post

As was mentioned you can do an .exe hack, but it's not nice and very unstable.

Best going 64 bit in the long run.
Don't trust those with words of weakness, they are the most aggressive

Post

LeVzi wrote:As was mentioned you can do an .exe hack, but it's not nice and very unstable.

Best going 64 bit in the long run.
Unstable? Either a program will work (see earlier post about pointers) or not - comes down to the compiler used (which in turn comes down to the age program mainly). Set the bit on the .exe, test the app with >2gb of memory load, if it works good, if it explodes unset the bit.

Both LAA apps (and PAE) were common on windows server - this is not some super esoteric 'hack'. It's just on consumer oriented apps few developers bothered to enable LAA at build time (even when the compiler they were using was perfectly fine doing so)

Post

LeVzi wrote:As was mentioned you can do an .exe hack, but it's not nice and very unstable.

Best going 64 bit in the long run.
Except that OP wants to stay 32bit. Favourite 32bit plugins?

Post

I think the process ram limit on a 64-bit OS, with a 32-bit process, is 4gb, not 2gb.

Not very much help though being that it's still easy enough to exceed 4gb with samplers. No personal clue why anyone needs x64 for mixing, unless they never commit anything to audio.

Post

LawrenceF wrote:I think the process ram limit on a 64-bit OS, with a 32-bit process, is 4gb, not 2gb.
It's 2GB by default and 4GB in certain (limited) circumstances. Take a look at the link Ayorinde posted earlier for more info.
LawrenceF wrote:No personal clue why anyone needs x64 for mixing, unless they never commit anything to audio.
I doubt anyone would switch to a 32-bit DAW specifically for mixing if they're already using 64-bit DAW for whatever reason.

Post

Ayorinde wrote:...
Except that OP wants to stay 32bit. Favourite 32bit plugins?
And he's paying the price for it. 64-bit doesn't mean he can't use his 32-bit plugins.

He just needs to find a copy of Cubase 6.5, then with jBridge he's set (or at least better off).

Post Reply

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”