Crashes in mlr 2.51++!

  • I'm pretty sure myself or another person has asked a similar question like this, but I don't think a resolution has come yet. Here and there Max 5 crashes in MLR while playing, even when i'm not button mashing. It happens I say about 20% of the time that I open up max. It does this with 2.27, 2.51, and others (but not in mlrv).

    The error message that I get is something about the xgroove.mxe file, in the error log.

    I would prefer to keep using 2.51++ for its incorporation of 2 monomes, but 2.51++ does not work in the crash-less max 4.6.3.

    What's the best course of action i should take to prevent embarrassment when playing live?

    Windows Vista
    3GB RAM
    Max 5.1.5 Runtime (the latest version)
    tested with mlr 2.51++, 2.27 and 2.27 jmelnyk edit

  • did you install xgroove? maybe you installed it in the wrong place or used the mac version of xgroove?

    the instructions for xgroove are in mlrv package i think.

    not sure if this will solve the issue

  • i think it will probably be groove~ that is crashing max (not xgroove~) as mlr2.51 is based on the internal max object. in terms of minimising crashes i haven't found a solution that could be reliably tested but this is because despite many hours of intense testing of groove~ i couldn't make it crash repeatedly under any circumstance. it truly does seem random.

    on the plus side, there is a little surprise for you around the corner... it's just a short stroll but sometimes the shortest trips are the hardest. cryptic enough?

  • i can't offer you a solution, but i can let you know that i share your pain.

    a hackjob of mlr_cyst that i had running in mlr5 crashed on me live a month or two back and it pretty much convinced me that mlr in max5 just isn't reliable enough for live performances.

    @trent, how have you boiled it down to groove~? do you have other groove~-based patches that crash in max5? not disputing, just curious..

  • to be honest i never found max4 (4.6.3) to be any more stable than max5, but i do remember early on in the mlrv development spending a couple of days trying to locate the problem. everytime max would crash the log would always have a reference to groove~ so i naturally assumed it to be the problem.

    as a result i set up a number of test patches to simulate 'button mashing' by sending 1000s of random position points to a groove~ object every second. i then did the same while changing loop points and playback speed to which max didn't have any issues.

    the only aspect of sample slicing that i didn't incorporate in the testing (which in hindsight seems the most likely culprit) is sending this data whilst jumping back and forth between a number of different buffer~ objects. if i were to take a guess at the problem, i would say it's connected to selecting loop points in groove~ that lie outside the size of the buffer~ that is currently referenced.

    somehow groove~ is corrupting some entry in RAM and causing max to crash.


    all this being said, i haven't tried other patches that use groove~ extensively and can't find any patch to reproduce the crash (to this date noone has been able to reliably reproduce the crash). so theoretically it could be some other action in mlr that causes the memory instability and groove~ is just the trigger to make it all fall apart — my only issue with this is that mlr generally doesn't do much of anything other than send a bunch of control data to groove~ and have audio playback.

    could the issue lie in the tempo patch? i don't think so because mlrv uses a different approach to time-management (metric based) but still has the crash issue (when not using xgroove~).

  • i've been using a version something like 2.51.1+ which i have had no problems with crashes as i did in the others. it's not the first link. it's about half way down the page. there's a reworked verison for the 64 and 128 but if you use the original in there it works fine for me.

  • Ok, I went through warming up for my bar show that I have later on tonight, I was able to make Max crash in mlr on command within 5 minutes 3 times. I did this by taking my drum track and triggering it like real drums (k-h-h-h-s-h-h-h) and I started to hear little clips in the audio until it finally bugged out.

    I'm going to restart my computer and try this again (I usually shut my lid after every time I use it and only restart it when I need to play a gig)

    Here is the error log from the last 2 crashes

    1366 x 768 - 159K
  • hey aaron,

    could you try and load the standard mlr2.27 version and only load your drum sample, then start slicing it on one row and see if you can make it crash.

    if you can, would you please post (or email) that drum sample and i'll see if i can reproduce the crash on my computer. from there if we can make it happen, it's just a matter of breaking down the mlr patch to a simple enough state where we can post it on the cycling forum / to the c74 themselves as a way to cause groove~ to crash....

  • i think you may have been onto something with the changing buffers thing... i'm going to test that tomorrow and see what happens.

  • hi @NO SIR E
    did you fix this problem?
    i'm having same problem..
    could you tell me how to fix this if you solved this problem.

    im using
    mlr 2.6.1 aux
    max runtime 5.1.9
    monome 256 with serialOSC
    macbook pro retina 10.8.5
    2,6 ghz intel core i7
    16GB memory 1600 MHz DDR3
    i didnt use audio interface yet..

    thank you.

  • hi @hiko - i know it's probably not quite what you want to hear but mlrv avoids this crash by using an external object for the sample playback mechanism. if you're unable to find a solution, you could try that out!

  • sorry for late.
    thank you @galapagoose.
    I've tried mlrv. it works great with out crash but somehow pattern recording didnt work and i could not save few mapping parameters .(oct+ &- and reverse).

    now mlr works 90% fine :)after re-install my macbook expect one action still makes mlr and max crash though...
    i will avoid that action.

    i have a gig this friday and it will be my first gig with monome:)
    wish me luck.

  • best of luck!