Can anyone clarify if there is a limit to the size of a MAX patch. I am having problems when I add large subpatches (with 300 inlets/outlets) to an already large patch. Especially when groing over 50 Mb.
I am just adding additional information on the problem:
System: i7-950 processor, 6 Gb RAM, wINDOWS 7 64-bit.
The problem I am having is that I reach a point when I add an additional subpatch (200-300 inlets) and MAX crahses in the following situations:
1. When changing from presentation to normal mode.
2. When turning audio ON using a dac~.
I do nto know if this is related, but this seems to occur when the additional patch is part of a 'pattrstorage' system (i.e., it includes an 'autopattr' object). The subpatch added normally has a large number of objects associated with the 'pattrstorage' system. They are named automatically by 'autopattr' (autoname flag is 1).
And here is a ZIP with the project. There is one external that will only react if it has a P5 essential reality glove. If the glove is not connected, the patch still works (it will only post a message that there is no glove and will not react if one turns the glove capture ON - so do not turn it on - but nothing else).
Thanks for the reply. In fact, I have already reduced the size of the patches (there used to be subpatches with 900-1000 connections). Everythign has been working without problems with large inlet/outlet patches (quite a few of them) until one day this issue appeared, which makes me think that I have reached MAX's capacity. The problem did not appear with a new subpatch but with a copy of one of the subpatches already working. In fact these are very simple interface subpatches, but because of the type of application, reducing sizes would yield endless dialog boxes for the user.
Another possibility that i am investigating is that, since I have been using 'aoutpttr' with autoname on, copying patches has yielded objects with the same scripting names. I am now erradicating all the scripting names to see if this solves the problem.
I followed your suggestion and made subpatches much smaller but this does not make a difference: if the size of the main patch is less than 50 Mb it works and if it is larger (e.g. by duplicating a large subpatch - not necessarily with many inlets/outlets) MAX crahses.
I have now contacted support and hope that they can come with a solution.
hello, I have the same problem with one patch (patch for Live Electronic), he have 1.2 Mo and he work, one time when I change something inside, the patch has 52Mo and MAX crash... Impossible to open on MAX7, possible on MAX6 but long for getting. I test on different MAC (i7, recents machines) and I have the same problem... Same thing for MAX6 and MAX7. Solution?
MacBook pro 15' Retina i7 2,5 Ghz, 16 Go ram, SSD 512, (2016). OSX Sierra 10.12.1
MacBook pro 15' i7 2Ghz, 16 Go ram, SSD 256 (2011), OSX El Capitan 10.11.6
I had a big patch that made Max crashed sometime at startup, particularly when I had a couple of other big softwares open. So, I made the patch with only one [loadbang] that would defer/delay the load of initial values, something like spraying the loads on a few seconds, and my patch opened more smoothly.
hello, thank, no it's not this case (loadbang's), the pb is a big size, the patch as 1.2 Mo and at one moment he change...for 52Mo or 102Mo... and crash MAX7 (also MAX6 but not regularly). After it's impossible to open patch... where is the problem who make this ??