A way to increase Cubase 32-bit memory allocation?
-
- KVRAF
- 4344 posts since 20 Feb, 2004
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.
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.
-
UltimateOutsider UltimateOutsider https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=216800
- KVRian
- 824 posts since 5 Oct, 2009 from Portland, OR
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...
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...
-
- KVRAF
- 2464 posts since 9 Oct, 2008 from UK
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.
-
- KVRAF
- 3506 posts since 12 May, 2011
From the horses mouth.jabe wrote:The limit for 32-bit should be 4GB rather than 2GB. I've no idea what individual bits of software do though.
Memory Limits for Windows and Windows Server Releases
-
- KVRAF
- 3506 posts since 12 May, 2011
I think that's a programming thing that has to be done when compiming the code for the executable.JerGoertz wrote:Thanks fellas!
I'm gonna try to set the flag mentioned in the article Ayorinde posted.
Hope, for a change, to be wrong!
-
- KVRian
- 1062 posts since 3 Oct, 2011 from Christchurch, New Zealand
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
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
-
- KVRian
- 853 posts since 13 Mar, 2012
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:
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
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;
}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
~~ ॐ http://soundcloud.com/mfr ॐ ~~
-
- KVRAF
- 2312 posts since 9 Jun, 2002 from East of Santa Monica
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.
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.
- Banned
- 4491 posts since 8 Jul, 2008 from UK
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.
Best going 64 bit in the long run.
Don't trust those with words of weakness, they are the most aggressive
-
- KVRian
- 1062 posts since 3 Oct, 2011 from Christchurch, New Zealand
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.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.
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)
-
- KVRAF
- 3506 posts since 12 May, 2011
Except that OP wants to stay 32bit. Favourite 32bit plugins?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.
-
- KVRAF
- 6159 posts since 4 Dec, 2004
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.
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.
-
- KVRist
- 381 posts since 12 Jul, 2006
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:I think the process ram limit on a 64-bit OS, with a 32-bit process, is 4gb, not 2gb.
I doubt anyone would switch to a 32-bit DAW specifically for mixing if they're already using 64-bit DAW for whatever reason.LawrenceF wrote:No personal clue why anyone needs x64 for mixing, unless they never commit anything to audio.
-
- KVRAF
- 2312 posts since 9 Jun, 2002 from East of Santa Monica
And he's paying the price for it. 64-bit doesn't mean he can't use his 32-bit plugins.Ayorinde wrote:...
Except that OP wants to stay 32bit. Favourite 32bit plugins?
He just needs to find a copy of Cubase 6.5, then with jBridge he's set (or at least better off).
