you definitely have some redundant elements in there, when you use an [uzi] to a [counter] you're duplicating number streams which should not be necessary. As far as the crash, this is just a guess, but you do try and clear all your buffer~ objects at once with [receive c]. This might be botching things up.
I tweaked some things in the subpatch, then tried to save and also got a crash. XP, 5.1.6
Only that if you need to count up a bunch of sequential numbers, you can do it with just [uzi] and use arguments to [uzi] for an offset, or use a [+] object after it to get the number stream you want. You were running numbers from the [uzi] through [counter] which isn't needed---[counter] is better-suited to do things like count repeatedly in a range, go up and down, etc. [uzi] will give you a stream of indices as fast as possible.
I also noticed in the earlier patch that you were loading a ton of buffer~ objects using [uzi]. This is probably much too fast to perform well, and can cause problems. Try [deferlow] before read-heavy operations like reading into [buffer~], or use some [delay] objects. Also for clearing a [buffer~] you can try "clearlow" rather than "clear". There's a reason it exists as an option :)
Thank you seejayjames, I modified the patch, it is simpler, works better,
Now, it is my main patch which crash when I do not load all buffers, I look
Vanilla béchamel, I'm not still very successful with the sound, I am young with max and newborn child with msp, I see that the poly would avoid me multiplying buffers, but I do not know if it would avoid me the crash of max.
Looking into this we found a bug wherein sending a delete message to an empty umenu and then filling the menu will lead to a crash when saving the patch or accessing the umenu's inspector.
In this case you'll need disable loadbangs when launching (hold shift-command on Mac, shift-control on PC), so you can make the necessary edits to workaround the issue (for starters, disconnect the subpatcher from umenu).