bug? max crash

moze's icon
Max Patch
Copy patch and select New From Clipboard in Max.

hello,
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.

moze's icon
Max Patch
Copy patch and select New From Clipboard in Max.

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

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

Dave Holton's icon

Hi,

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

-Dave

seejayjames's icon

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

moze's icon

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

1652.buffers.maxpat.zip
zip
seejayjames's icon

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

moze's icon

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

Dave Holton's icon

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.

-Dave

seejayjames's icon

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

moze's icon

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

Dave Holton's icon

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

moze's icon

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

Emmanuel Jourdan's icon

do you have an example to reproduce?

moze's icon
Max Patch
Copy patch and select New From Clipboard in Max.

ok, Emmanuel,

Emmanuel Jourdan's icon

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

moze's icon

not problem