woodslanding

I'm running max 5.1.9 on windows. I know max 5 is not 64 bit (max 6 ish't either, correct?) but isn't there a way to allocate more memory to 32 bit apps? I can't track it down....

I'm loading quite a few vsts and therefore running out of memory. But I have 8 gb in my machine...

I'm running max 5.1.9 on windows.  I know max 5 is not 64 bit (max 6 ish't either, correct?) but isn't there a way to allocate more memory to 32 bit apps?  I can't track it down....

I'm loading quite a few vsts and therefore running out of memory.  But I have 8 gb in my machine...

allocating-more-memory-to-max

Okay, I've done more reading, and it looks like a 32-bit app running in a 64-bit windows OS will be allocated up to 4 GB of RAM, as long as the app is LARGE_ADDRESS_AWARE

So, I'm wondering--Is Max 5 not large address aware? Is Max 6?

So, I'm wondering--Is Max 5 not large address aware?  Is Max 6?


How do you know that Max 5 is not large address aware?

On a mac I manage to smoothly run patches which allocate 3.6 gb in memory, including the program (if you go higher it will become tricky, say 3.7=tricky, 3.8= dangereous, 3.9=about to crash).

How do you know that Max 5 is not large address aware?
On a mac I manage to smoothly run patches which allocate 3.6 gb in memory, including the program (if you go higher it will become tricky, say 3.7=tricky, 3.8= dangereous, 3.9=about to crash).
I don't know how it will behave on a pc.


On my PC it is crashing at 1 GB! I am running Windows 7 64-Bit with 8 GB RAM

Is there some flag I need to set when starting MAX?

On my PC it is crashing at 1 GB!  I am running Windows 7 64-Bit with 8 GB RAM

Is there some flag I need to set when starting MAX?


1 gb of what? how do you check the memory usage?

Don't look at the current used physical memory, you need the total of reserved memory for that program, the virtual memory usage of the entire process. (I know it took me some time to know where to look at, but that's on the mac, I don't know it for windows)

keep in mind that for example audiofiles take up twice as much space when they are loaded (16->32 bit conversion)

no argument to set.
1 gb of what? how do you check the memory usage?
Don't look at the current used physical memory, you need the total of reserved memory for that program, the virtual memory usage of the entire process.  (I know it took me some time to know where to look at, but that's on the mac, I don't know it for windows)
keep in mind that for example audiofiles take up twice as much space when they are loaded (16->32 bit conversion)


How do you allocate, Timo? In max preferences? Thanks

no, I don't allocate myself, I check how much memory is allocated using the following patch:

you need the [shell] external to run this 

https://cycling74.com/tools/bernstein-shell/,

you need the [shell] external to run this https://cycling74.com/tools/bernstein-shell/, and sorry, it's mac only


Works with Max 6 also? Thanks again.(MAC ok ;>)

yup, works with max 6 (that's why I check the maxversion of the patch, since the process name has changed in max 6)

max5 on windows or mac, 32 or 64 bit, up to 2gb ram usage.

max6.0.2 or later on windows 64-bit, up to 4gb ram usage, but on mac, 32 or 64, still only 2gb ram usage.

max5 on windows or mac, 32 or 64 bit, up to 2gb ram usage.
max6.0.2 or later on windows 64-bit, up to 4gb ram usage, but on mac, 32 or 64, still only 2gb ram usage.


nope... this is not true (at least not what i have experienced), I use patches above 3.5gb memory use in max 5 on a mac which work fine

of course it also depends on what memory indicator you look at

Hmmm. Well, I wonder why I'm getting the message "the application is out of memory and may become unstable" when the taskmanager shows the Max application using 1.15 GB of ram. I should have at least another gig available.

I'm running 4 instances of Kontakt, and 3 of reaktor. I can run 25 instances of Kontakt in Reaper. That's where I stopped adding tracks, not the limit per se.... I know samples take up ram, but only one instance of Kontakt loads samples, about 300mb worth according to Kontakt's UI.

I am not loading any samples into Reaktor.

Hmmm.  Well, I wonder why I'm getting the message "the application is out of memory and may become unstable"  when the taskmanager shows the Max application using 1.15 GB of ram.  I should have at least another gig available.

I'm running 4 instances of Kontakt, and 3 of reaktor.  I can run 25 instances of Kontakt in Reaper.  That's where I stopped adding tracks, not the limit per se....  I know samples take up ram, but only one instance of Kontakt loads samples, about 300mb worth according to Kontakt's UI.  

I am not loading any samples into Reaktor.


I experienced the same kind of problem here.

Test patch was the following : create a dozen of buffers and load them with some 300Mb soundfiles.

When reaching about 2 or 2.5Gb memory usage (as measured by OSX activity monitor), a message is kindly send to the max window to warn about memory limit : "buffer~: u809000206: out of memory reading my_3000mb_soudnfile.wav"

If at this point, on starts to instantiate savagely graphical user interface (say a swatch for example), on eventually gets a crash.

Tests were made with Max5.1.9 and Max6.0.8 on the following systems :

- imac Intel Core i5 3.6 GHz - OSX 10.6.8 - RAM 8Go 1333 Mhz DDR3

- macbook pro 2.8Ghz Core 2 Duo - OSX 10.7.2 - 4Gb RAM

- macbook pro Core-i7 - OSX 10.8.2 - 8Gb RAM

- how to avoid the crash ? ( something like preventing a user from creating more interface and warning him/her with a message in max console would be utterly great — just like the buffer~ does)

- how to overcome this (pretty smal) memory limitation ?

Warning : pasted below is *not* a Max5 patcher, but the crash report, just to spare viewport... is there any markup for that ?

----------begin_max5_patcher----------
Process:         MaxMSP [26561]
Path:            /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
Identifier:      com.cycling74.MaxMSP
Version:         5.1.9 [48561] (5.1.9)
Code Type:       X86 (Native)
Parent Process:  launchd [135]

Date/Time:       2013-01-24 16:18:47.149 +0100
OS Version:      Mac OS X 10.7.4 (11E53)
Report Version:  9

Interval Since Last Report:          153872 sec
Crashes Since Last Report:           2
Per-App Interval Since Last Report:  48272 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      0F2C64B1-8900-4E3B-8C0A-ED6C8440917A

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000654

VM Regions Near 0x654:
--> __PAGEZERO             0000000000000000-0000000000001000 [    4K] ---/--- SM=NUL  /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
    __TEXT                 0000000000001000-000000000046b000 [ 4520K] rwx/rwx SM=COW  /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP

Application Specific Information:
objc[26561]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.cycling74.MaxMSP              0x00389628 void juce::EdgeTable::iterate >(juce::SolidColourEdgeTableRenderer&, int, int, int, int, int) const + 664
1   com.cycling74.MaxMSP              0x003823a8 juce::LowLevelGraphicsSoftwareRenderer::clippedFillPathWithColour(int, int, int, int, juce::Path const&, juce::AffineTransform const&, juce::Colour const&, juce::EdgeTable::OversamplingLevel) + 1800
2   com.cycling74.MaxMSP              0x00382452 juce::LowLevelGraphicsSoftwareRenderer::fillPathWithColour(juce::Path const&, juce::AffineTransform const&, juce::Colour const&, juce::EdgeTable::OversamplingLevel) + 114
3   com.cycling74.MaxMSP              0x0031d975 juce::SolidColourBrush::paintPath(juce::LowLevelGraphicsContext&, juce::Path const&, juce::AffineTransform const&) + 65
4   com.cycling74.MaxMSP              0x00320060 juce::Graphics::fillPath(juce::Path const&, juce::AffineTransform const&) const + 108
5   com.cycling74.MaxMSP              0x00146667 jgraphics_fill_preserve + 181
6   com.cycling74.MaxMSP              0x00146684 jgraphics_fill + 18
7   com.cycling74.MaxMSP              0x0010bcf1 BoxComponent::paint(juce::Graphics&, juce::AffineTransform const&) + 877
8   com.cycling74.MaxMSP              0x001d8a2d ZoomableComponent::paint(juce::Graphics&) + 43
9   com.cycling74.MaxMSP              0x002f8147 juce::Component::paintEntireComponent(juce::Graphics&) + 555
10  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
11  com.cycling74.MaxMSP              0x001bd2f0 PatcherLayerComponent::paintEntireComponent(juce::Graphics&) + 80
12  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
13  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
14  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
15  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
16  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
17  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
18  com.cycling74.MaxMSP              0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
19  com.cycling74.MaxMSP              0x00390a50 juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 48
20  com.cycling74.MaxMSP              0x002dabce juce::HIViewComponentPeer::RepaintManager::paint(CGContext*, int, int, int, int) + 862
21  com.cycling74.MaxMSP              0x002db0d3 juce::HIViewComponentPeer::hiViewDraw(OpaqueEventRef*) + 619
22  com.cycling74.MaxMSP              0x002db2c7 juce::HIViewComponentPeer::hiViewEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 425
23  com.apple.HIToolbox               0x927c5dec _InvokeEventHandlerUPP(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, long (*)(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)) + 36
24  com.apple.HIToolbox               0x926414f3 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1602
25  com.apple.HIToolbox               0x92640970 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 482
26  com.apple.HIToolbox               0x92640788 SendEventToEventTargetWithOptions + 75
27  com.apple.HIToolbox               0x92661224 HIView::SendDraw(short, OpaqueGrafPtr*, __HIShape const*, CGContext*) + 478
28  com.apple.HIToolbox               0x926efd7f HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 755
29  com.apple.HIToolbox               0x926f0071 HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 1509
30  com.apple.HIToolbox               0x926f0071 HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 1509
31  com.apple.HIToolbox               0x926f1023 HIView::DrawComposited(short, OpaqueGrafPtr*, __HIShape const*, unsigned long, HIView*, CGContext*) + 1227
32  com.apple.HIToolbox               0x926f116b HIView::Draw(short, OpaqueGrafPtr*, unsigned long) + 81
33  com.apple.HIToolbox               0x926f1533 HIView::Render(unsigned long, CGContext*) + 45
34  com.apple.HIToolbox               0x9265107b _ZL17FlushWindowObjectP10WindowDataPPvh + 736
35  com.apple.HIToolbox               0x92650b79 _ZL15FlushAllBuffersP19__CFRunLoopObservermPv + 241
36  com.apple.CoreFoundation          0x9cafe0ce __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
37  com.apple.CoreFoundation          0x9cafe00d __CFRunLoopDoObservers + 413
38  com.apple.CoreFoundation          0x9cad01bc CFRunLoopRunSpecific + 300
39  com.apple.CoreFoundation          0x9cad0088 CFRunLoopRunInMode + 120
40  com.apple.HIToolbox               0x9263b723 RunCurrentEventLoopInMode + 318
41  com.apple.HIToolbox               0x926429b6 ReceiveNextEventCommon + 168
42  com.apple.HIToolbox               0x927d8af0 ReceiveNextEventInMode + 67
43  com.apple.HIToolbox               0x927d8b88 ReceiveNextEvent + 72
44  com.cycling74.MaxMSP              0x002d375a juce::juce_dispatchNextMessageOnSystemQueue(bool, bool) + 554
45  com.cycling74.MaxMSP              0x002dd3df juce::MessageManager::dispatchNextMessage(bool, bool*, bool) + 79
46  com.cycling74.MaxMSP              0x002dd49e juce::MessageManager::runDispatchLoop() + 42
47  com.cycling74.MaxMSP              0x002dbdf9 juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) + 605
48  com.cycling74.MaxMSP              0x002dbed3 juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) + 125
49  com.cycling74.MaxMSP              0x001e5032 main + 76
50  com.cycling74.MaxMSP              0x000059fe _start + 216
51  com.cycling74.MaxMSP              0x00005925 start + 41
-----------end_max5_patcher-----------


It seems this topic was left unsolved...
I experienced the same kind of problem here. 

Test patch was the following : create a dozen of buffers and load them with some 300Mb soundfiles.
When reaching about 2 or 2.5Gb memory usage (as measured by OSX activity monitor), a message is kindly send to the max window to warn about memory limit : "buffer~: u809000206: out of memory reading my_3000mb_soudnfile.wav"

If at this point, on starts to instantiate savagely graphical user interface (say a swatch for example), on eventually gets a crash.
(See crash report at the end)

Tests were made with Max5.1.9 and Max6.0.8 on the following systems :
- imac Intel Core i5 3.6 GHz  - OSX 10.6.8 - RAM 8Go 1333 Mhz DDR3
- macbook pro 2.8Ghz Core 2 Duo - OSX 10.7.2 - 4Gb RAM
- macbook pro Core-i7 - OSX 10.8.2 - 8Gb RAM

The question are :
- how to avoid the crash ? ( something like preventing a user from creating more interface and warning him/her with a message in max console would be utterly great — just like the buffer~ does)
- how to overcome this (pretty smal) memory limitation ?

----------begin_max5_patcher----------
Process:         MaxMSP [26561]
Path:            /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
Identifier:      com.cycling74.MaxMSP
Version:         5.1.9 [48561] (5.1.9)
Code Type:       X86 (Native)
Parent Process:  launchd [135]

Date/Time:       2013-01-24 16:18:47.149 +0100
OS Version:      Mac OS X 10.7.4 (11E53)
Report Version:  9

Interval Since Last Report:          153872 sec
Crashes Since Last Report:           2
Per-App Interval Since Last Report:  48272 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      0F2C64B1-8900-4E3B-8C0A-ED6C8440917A

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000654

VM Regions Near 0x654:
--> __PAGEZERO             0000000000000000-0000000000001000 [    4K] ---/--- SM=NUL  /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
    __TEXT                 0000000000001000-000000000046b000 [ 4520K] rwx/rwx SM=COW  /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP

Application Specific Information:
objc[26561]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.cycling74.MaxMSP          	0x00389628 void juce::EdgeTable::iterate >(juce::SolidColourEdgeTableRenderer&, int, int, int, int, int) const + 664
1   com.cycling74.MaxMSP          	0x003823a8 juce::LowLevelGraphicsSoftwareRenderer::clippedFillPathWithColour(int, int, int, int, juce::Path const&, juce::AffineTransform const&, juce::Colour const&, juce::EdgeTable::OversamplingLevel) + 1800
2   com.cycling74.MaxMSP          	0x00382452 juce::LowLevelGraphicsSoftwareRenderer::fillPathWithColour(juce::Path const&, juce::AffineTransform const&, juce::Colour const&, juce::EdgeTable::OversamplingLevel) + 114
3   com.cycling74.MaxMSP          	0x0031d975 juce::SolidColourBrush::paintPath(juce::LowLevelGraphicsContext&, juce::Path const&, juce::AffineTransform const&) + 65
4   com.cycling74.MaxMSP          	0x00320060 juce::Graphics::fillPath(juce::Path const&, juce::AffineTransform const&) const + 108
5   com.cycling74.MaxMSP          	0x00146667 jgraphics_fill_preserve + 181
6   com.cycling74.MaxMSP          	0x00146684 jgraphics_fill + 18
7   com.cycling74.MaxMSP          	0x0010bcf1 BoxComponent::paint(juce::Graphics&, juce::AffineTransform const&) + 877
8   com.cycling74.MaxMSP          	0x001d8a2d ZoomableComponent::paint(juce::Graphics&) + 43
9   com.cycling74.MaxMSP          	0x002f8147 juce::Component::paintEntireComponent(juce::Graphics&) + 555
10  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
11  com.cycling74.MaxMSP          	0x001bd2f0 PatcherLayerComponent::paintEntireComponent(juce::Graphics&) + 80
12  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
13  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
14  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
15  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
16  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
17  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
18  com.cycling74.MaxMSP          	0x002f8361 juce::Component::paintEntireComponent(juce::Graphics&) + 1093
19  com.cycling74.MaxMSP          	0x00390a50 juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 48
20  com.cycling74.MaxMSP          	0x002dabce juce::HIViewComponentPeer::RepaintManager::paint(CGContext*, int, int, int, int) + 862
21  com.cycling74.MaxMSP          	0x002db0d3 juce::HIViewComponentPeer::hiViewDraw(OpaqueEventRef*) + 619
22  com.cycling74.MaxMSP          	0x002db2c7 juce::HIViewComponentPeer::hiViewEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 425
23  com.apple.HIToolbox           	0x927c5dec _InvokeEventHandlerUPP(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, long (*)(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)) + 36
24  com.apple.HIToolbox           	0x926414f3 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1602
25  com.apple.HIToolbox           	0x92640970 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 482
26  com.apple.HIToolbox           	0x92640788 SendEventToEventTargetWithOptions + 75
27  com.apple.HIToolbox           	0x92661224 HIView::SendDraw(short, OpaqueGrafPtr*, __HIShape const*, CGContext*) + 478
28  com.apple.HIToolbox           	0x926efd7f HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 755
29  com.apple.HIToolbox           	0x926f0071 HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 1509
30  com.apple.HIToolbox           	0x926f0071 HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned long, HIView*, CGContext*, unsigned char, float) + 1509
31  com.apple.HIToolbox           	0x926f1023 HIView::DrawComposited(short, OpaqueGrafPtr*, __HIShape const*, unsigned long, HIView*, CGContext*) + 1227
32  com.apple.HIToolbox           	0x926f116b HIView::Draw(short, OpaqueGrafPtr*, unsigned long) + 81
33  com.apple.HIToolbox           	0x926f1533 HIView::Render(unsigned long, CGContext*) + 45
34  com.apple.HIToolbox           	0x9265107b _ZL17FlushWindowObjectP10WindowDataPPvh + 736
35  com.apple.HIToolbox           	0x92650b79 _ZL15FlushAllBuffersP19__CFRunLoopObservermPv + 241
36  com.apple.CoreFoundation      	0x9cafe0ce __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
37  com.apple.CoreFoundation      	0x9cafe00d __CFRunLoopDoObservers + 413
38  com.apple.CoreFoundation      	0x9cad01bc CFRunLoopRunSpecific + 300
39  com.apple.CoreFoundation      	0x9cad0088 CFRunLoopRunInMode + 120
40  com.apple.HIToolbox           	0x9263b723 RunCurrentEventLoopInMode + 318
41  com.apple.HIToolbox           	0x926429b6 ReceiveNextEventCommon + 168
42  com.apple.HIToolbox           	0x927d8af0 ReceiveNextEventInMode + 67
43  com.apple.HIToolbox           	0x927d8b88 ReceiveNextEvent + 72
44  com.cycling74.MaxMSP          	0x002d375a juce::juce_dispatchNextMessageOnSystemQueue(bool, bool) + 554
45  com.cycling74.MaxMSP          	0x002dd3df juce::MessageManager::dispatchNextMessage(bool, bool*, bool) + 79
46  com.cycling74.MaxMSP          	0x002dd49e juce::MessageManager::runDispatchLoop() + 42
47  com.cycling74.MaxMSP          	0x002dbdf9 juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) + 605
48  com.cycling74.MaxMSP          	0x002dbed3 juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) + 125
49  com.cycling74.MaxMSP          	0x001e5032 main + 76
50  com.cycling74.MaxMSP          	0x000059fe _start + 216
51  com.cycling74.MaxMSP          	0x00005925 start + 41
-----------end_max5_patcher-----------


Mixing Windows and OS X together in this thread almost certainly isn't helping to re/solve the issue.

Although they're not very different on many levels their memory management policies, implementation and reporting are certainly divergent enough to warrant separate investigation.

Getting an accurate picture of memory usage in Windows (at least < 8) requires knowing where to look, what to look for, and then adding up some from these piles over here, subtract a bit from that pile over there . . . you get the idea. It's not as simple as looking in Task Manager.

The large_address_aware flag will net you 3GB of Virtual Address Space in 32bit Windows.

Right-click Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator.

At the command prompt, enter "bcdedit /set IncreaseUserVa 3072"

Right-click on Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator.

At the command prompt, enter "bcdedit /deletevalue IncreaseUserVa"

The large_address_aware flag will net you 3GB of Virtual Address Space in 32bit Windows. 

    Right-click Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator.
    At the command prompt, enter "bcdedit /set IncreaseUserVa 3072"
    Restart the computer.

    Right-click on Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator.
    At the command prompt, enter "bcdedit /deletevalue IncreaseUserVa"
    Restart the computer.


poly~ sounding_much_more_pompous_and_authoratative_than_i_meant_to

I thought the topic "Allocating more memory to MAX?" (not mentionning the window filesystem AFAICT) seemed like a related topic to the problem I raised in the last post... C74 fellows, please let me know if this is actually a completely unrelated issue preventing you from resolving this bug (!) as I do no mind so much starting a new thread... :)

It also seems to me like the filesystem settings are not the only place where to improve/fix this issue. Max could maybe prevent crash to occur by scanning memory ressources (whatever way you get them depending on platform) and warn the user accordingly, preferably in a "platform-independant" way... as I expect as much as possible that Max behaviour remains the same whatever system I decide to use.

Thanks for the info concerning window platform, that is precious. If anyone know an equivalent alternative for OSX, or even just a clear explanation about what is happening (and how to prevent the crash, which are eventually my main concern) this would be super welcome.

It also seems to me like the filesystem settings are not the only place where to improve/fix this issue. Max could maybe prevent crash to occur by scanning memory ressources (whatever way you get them depending on platform) and warn the user accordingly, preferably in a "platform-independant" way... as I expect as much as possible that Max behaviour remains the same whatever system I decide to use. 

Thanks for the info concerning window platform, that is precious. If anyone know an equivalent alternative for OSX, or even just a clear explanation about what is happening (and how to prevent the crash, which are eventually my main concern) this would be super welcome.


or just wait a couple months until Max 6.1 is out, which is 64-bit.

i would be very pleased if this release fix the crash issue indeed... not sure the fact that it is 64bit will ensure that though :)

Will the 64-bit version of Max (OS X version) be able to handle 32-bit VSTs?

ok dhjdhjdhj, my turn to tell you that your post may be slightly off topic ... :)

FWIW, I think you may find the answer to your question 

 on how much memory should be available in 64bit:

64-bit computing shatters the 4 GB barrier of 32-bit computing by enabling applications to address a theoretical 16 billion gigabytes of memory, or 16 exabytes."

Still, this does not prevent my Max from crashing ...

Maybe any "official" statement from C74 on this memory topic soon ?

FWIW, I think you may find the answer to your question here. 

And by the way, I found some "official" apple statement on how much memory should be available in 64bit:

Still, this does not prevent my Max from crashing ...
Maybe any "official" statement from C74 on this memory topic soon ?


Hey Vincent - I wasn't telling you your post was off-topic, my post wasn't aimed at you at all. I will tell you that the "filesystem"* (on OS X or Windows) has nothing to do with anything though! ;)

* HFS+ and NTFS respectively. Not related to virtual addressing or physical memory.

I was just trying to point out that when it comes to this subject, it's not always wise to treat Windows and OS X interchangeably. They even handle the 32bit / 64bit differently (from each other).

That blurb on the Apple Developer page reads like breathless marketing fluff - "OMG 64BIT FASTAR!!!". I thought they limited that sort of guff to the hordes?

64bit won't fix memory leaks, but the machine should stay up a bit longer. :D

agreed with the marketing smell of apple statement, thats why apple says a *theoretical* 16 billion gigabytes... and why I said *should* be available :)

About memory leaks mysteries, I bet we'll soon discover it is related to some quantum mechanics anti-matter unsolvable equation.

agreed with the marketing smell of apple statement, thats why apple says a *theoretical* 16 billion gigabytes...  and why I said *should* be available :)
About memory leaks mysteries, I bet we'll soon discover it is related to some quantum mechanics anti-matter unsolvable equation.


With something as extensible as Max, memory leaks could reside in 3rd-party externals.

The Apple blurb is about as non-technical a take on the whole 64bit thing as I've seen in many a year - and this is probably fine for a lot of the intended audience there (developers) as they ought to be able to smell it for what it is. My problem with the preceeding statement is that it seems Apple know full well that many non-technical people are ending up there . . . at the very least it's a likely landing-page for those just starting out, perhaps their first hobbyist ObjC or iApp project.

So, nothing like starting people out on the (technically correct but fundamentally meaningless) good foot eh?

All of this is fairly off-topic now I think so I'll quit here.

Wow! That would be so amazing that I actually can't believe that it would happen. Is there some (un)official statement about a 64 bit version of Max 6.1? I've never heard about that before...

in the example I first mentionned, I used only buffer~ and swatch, which are native Max object.

So the issue seems to dwell in C74 hands...

 With something as extensible as Max, memory leaks could reside in 3rd-party externals. 

in the example I first mentionned, I used only buffer~ and swatch, which are native Max object.
So the issue seems to dwell in C74 hands...


True, but I am speaking to the point broadly - not specifically addressing your issue.

@ adam siska, it has been very publically released as part of the Live9 Beta program, which is why i thought it was fine to mention it. Max will be 64 bit because Live will be 64 bit.

@ vincent etc, i think it is you who hijacked this topic. for your unrelated issue you should start a new topic.

@ dhjblahblah, my perception is that i am almost 100% sure that no, there will be no magical 32/64 bit bridge for vst~ etc. but i could be wrong. there is none in Live9 either.

@  dhjblahblah, my perception is that i am almost 100% sure that no, there will be no magical 32/64 bit bridge for vst~ etc. but i could be wrong. there is none in Live9 either.


@ pid re: The Great Thread Hijack Of '13 . . .

Vincent - just reread your first post in this topic. You deliberately exhausted the physical RAM in your machine and you're blaming the software for instability? No offence pal, but PEBKAC. :P

Graphical glitching is probably the most common symptom of out-of-resources issues (which is not limited to just RAM, but for instance things like GDI Resources on Windows - I know little about the specifics of OS X' architecture at that level).

Oooof! Nearly hijacked vincent's newly created topic with Crazy Talk - but his concerns got me thinking about ways to alleviate VAS and physical RAM usage under 32bit Windows and I believe I may have a solution.

Or a hack - but let's not let semantic niggles get between us and moar gigabytes.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366796%28v=vs.85%29.aspx

http://www.bcastell.com/tech-articles/enabling-more-than-4-gb-of-ram-under-windows-7-32-bit/

As these things go, that looks relatively benign. I would think the only potential limiter to (ab)using PAE for the purpose might be that perennial fly in the ointment - drivers.

So if anything in the toolchain is likely to keep you stuck on 32bit for a while - have at it.

Address Windowing Extensions (AWE)
Physical Address Extensions (PAE)

So if anything in the toolchain is likely to keep you stuck on 32bit for a while - have at it.


You'll just have to use Max 6.1 in 64 bits mode. Max is currently a 32 bits app, therefore you can't use more than 2/3 GB of RAM. The real limit is hard to say because of 

: if you open a patcher with some big buffer, remove some objects, do other stuff and try to reinstantiate the buffer~, you can't be certain that there still going to be enough 

You'll just have to use Max 6.1 in 64 bits mode. Max is currently a 32 bits app, therefore you can't use more than 2/3 GB of RAM. The real limit is hard to say because of memory fragmentation: if you open a patcher with some big buffer, remove some objects, do other stuff and try to reinstantiate the buffer~, you can't be certain that there still going to be enough continuous memory to hold those buffer~.


I was going to ask if Max handled its own garbage collection or relied on that supplied by the OS actually.

 blocks of VAS or RAM may be hard to come by in the Max environment once it's been up and in-use for a while in the manner you specified.

However, the methods I started to outline above should help, to wit:

If your BIOS and chipset support extra RAM above 4GB - PAE allows you to make use of this RAM . . . each process on the machine is still constrained to 2-3GB of VAS but this will be backed by more physical RAM.

The other part of the technique is to spin some of your Max project out to Standalones so they run in a different process . . . if your project is amenable.

So, to recap . . . PAE (with the AWE) can allow you to use more than 4GB of RAM, the per-process VAS limits remain but are vastly alleviated by being backed by a larger pool of RAM. Spin more processes to grab more VAS.

But yes, contiguous blocks of VAS or RAM may be hard to come by in the Max environment once it's been up and in-use for a while in the manner you specified.

I should add, for those who didn't click through this link:

This requires busting out a hex editor and modifying your Windows kernel. It's not particularly hard (step by step instructions), and the method to booting this modified kernel is clean, selectable and immediately reversible - therefore pretty safe to experiment with.

I believe you should end up with 4GB of address space per process, not the default 2GB as per the usual split, or 3GB with the switch thrown - but I'm unsure about this point without digging into it further.

One application in 32 bit systems can take only up to 2GB for one process.

This info You can see in Procexp - alternative task manager 

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

In the top of table - right click -> select columns -> Virtual size

And NOW You can see the moment of crashing Yours application if reached 2048K !!!

Hi to ALL !
One application in 32 bit systems can take only up to 2GB for one process.
This info You can see in Procexp - alternative task manager http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
In the top of table - right click -> select columns -> Virtual size
And NOW You can see the moment of crashing Yours application if reached 2048K !!!
