Forums > MaxMSP

bug? max crash

Jan 09 2011 | 10:37 am

If somebody can say to me why this patch crash max when I save it?
It is the patch which allows me to choose the number of song which I record in buffers.

-- Pasted Max Patch, click to expand. --

Jan 09 2011 | 11:31 am

The crash appears when I connect it red box message
very strange!

-- Pasted Max Patch, click to expand. --

It is necessary to record it first time so that the loadbang sends a number

Jan 10 2011 | 11:12 pm


Could you send this in to support, with the patch as a zipped attachment?


Jan 10 2011 | 11:55 pm

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

Jan 11 2011 | 7:50 am

I am hampered by my bad English, helped by a translator…..
Thank you for your help
I was able to solved the problem by removing message box (now, I have to reload buffers in every use) and I have to remove the umenu of control
Who allowed me to see if I deleted correctly items superfluous.
I am interested to understand " you’ re duplicating number streams which should not be necessary. " Seejayjames.
I put the patch in zip, dave

Jan 11 2011 | 1:19 pm

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

Jan 11 2011 | 8:55 pm

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.
I am going to try to understand how it works
difficile tout ça

Jan 12 2011 | 12:49 am

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

Sorry for the inconvenience.


Jan 12 2011 | 1:21 am

interesting! glad you were able to track it down. so [umenu] was the culprit after all.

Jan 12 2011 | 7:58 am

Thanks to all, I’m going to wait for the correction

Jan 14 2011 | 12:30 am

Please find the updated umenu object on the incremental updates page. It also includes support for items with > 255 characters.

Jan 14 2011 | 7:41 am

Thank you dave,
It’s OK, that works
Can be a small bug : when we want delete several times, umenu jams

Jan 14 2011 | 5:58 pm

do you have an example to reproduce?

Jan 14 2011 | 6:56 pm

ok, Emmanuel,

-- Pasted Max Patch, click to expand. --

Jan 14 2011 | 10:04 pm

Thanks for the clear example. The incremental page has been updated.

Jan 15 2011 | 7:27 am

not problem

Viewing 16 posts - 1 through 16 (of 16 total)

Forums > MaxMSP