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_soundfile.wav"
If at this point, one starts to instantiate some graphical user interfaces (say a swatch for example), one 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 small) memory limitation ?
Some more info on the context :
The example I gave with many buffers instanciation was an *example patch*, meant for C74 and anyone to reproduce the problem.
We have a real more complex patch in which we had trouble to find where the issue (crash) was, and please note that I am not exhausting the memory with an evil pleasure —viciously watchin the RAM-meter— in a non-debugging usual day :) ...
The buffers are instanciated automatically in a sound bank, and loading 2Gb of sound is something which happens pretty quickly when working on a whole music set. Now we have also some instruments (including GUI elements like swatch, which I took as an example in the test patch) that are also loadable dynamically (in poly~ object). Max5 also introduced a new patch format which is also much more memory-consuming than it was in Max4.x, and you can also easily reach more than 100mb of patchers.
We tried to avoid memory consumption by separating GUI from the audio/video processing algorithms, and followed some other performance enhancement rules
like the usefull ones Rob Ramirez mentionned in a recent post on the jitter list, but still face both low memory limit *and* the lack of low memory notification to prevent the crash.
One solution is to scan the max window to look for "out of memory" message kindly posted by buffer~ object, but one will not be warned from low memory caused by other objects.
I guess there should be ways to ask the system directly with the help of java/c object (shell ?), which would be helpful to warn the user that loading more sound/patch/whatever might be risky.
If anyone has ideas on how to circumvent crash in this context, I would be very glad to hear !