bug? max crash
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.
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
Hi,
Could you send this in to support, with the patch as a zipped attachment?
Thanks
-Dave
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
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
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.
I am going to try to understand how it works
difficile tout ça
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
interesting! glad you were able to track it down. so [umenu] was the culprit after all.
Thanks to all, I’m going to wait for the correction
Please find the updated umenu object on the incremental updates page. It also includes support for items with > 255 characters.
Thank you dave,
It’s OK, that works
Can be a small bug : when we want delete several times, umenu jams
do you have an example to reproduce?
ok, Emmanuel,
Thanks for the clear example. The incremental page has been updated.
not problem