bug? max crash

    Jan 09 2011 | 10:37 am
    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.

    • Jan 09 2011 | 11:31 am
      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
    • Jan 10 2011 | 11:12 pm
      Could you send this in to support, with the patch as a zipped attachment? Thanks
    • 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,
    • 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