r.a.fischman@keele.ac.uk

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.

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.
Thanks


does-max-crash-when-patches-get-too-big

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.

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).

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).

Actually, the ZIP file is >4Mb so it exceeds the allowed size. COuld nto include it.

I tried again and although receipt is ackknowledged, the ZIP file with the project files is not uploaded.

300 inlets sounds excessive but i do not make huge patches. Is there any way to isolate the problem. Possibly change your patch so it has better structure and is more modularized.

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.

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

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
MAX 6.1.10
MAX 7.3.1
(7/11/2016)


Is it opening smoothly when you disable [loadbang]s when opening?

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 ??

Do you use [coll] or any other objects that save something with the patch that could explain those changes of size?

And you are speaking about a patch, a .maxpat , not a collective or a standalone?

The patchs (differents) work normally and one time they change...

no coll,
.maxpat  yes
The patchs (differents) work normally and one time they change...


is it not the style problems ? do you use customs styles ? they tended to propagate too much in a previous Max 7 update, inside m4l device iirc. It should have been fixed since...

Philippe ML, you should go to your doc > Max7 > snapshots folder and see if it wasn't filled with thousands snapshots. This happened to me.

no it's not this case... m4l and snapshots are ok.

I'm waiting solution by Cycling74, strange problem...

hello,
no it's not this case... m4l and snapshots are ok.
I'm waiting solution by Cycling74, strange problem...
thank


Does MAX crash when patches get too big