Mlrv mlrV

Comments and changes to this ticket

• 

  galapagoose December 7th, 2008 @ 10:30 AM

  i have occasionally found this too, but have been unable to reliably reproduce the bug. OSX 10.5.5 MaxMSP5.0.5 on a 256. the problem is with MaxMSP - not the surrounding softwares.

  can you post exactly what windows is telling you when the crash occurs? on mac all it will tell you is 'segmentation fault' which i have had no luck tracking down on the C'74 forums.

  if the problem is with [groove~] then i know where to look for the problems- just hoping the problem is not with the object itself.

• You flagged this item as spam.
  

  agargara December 7th, 2008 @ 10:54 AM

  It gives me the generic Windows error ("MaxMSP has encountered a problem and needs to close") and the "error signature is":

  AppName: maxrt.exe AppVer: 5.0.3.35596 ModName: groove~.mxe ModVer: 5.0.3.35596 Offset: 000024c6

  Then there's an unhelpful text file with more "details" about the error. (attached)

  • cb19_appcompat.txt 16.8 KB
• 

  galapagoose December 9th, 2008 @ 03:00 PM

  • State changed from “new” to “open”

  hey all.

  does anyone here have maxmsp full version (even 30 day trial?) i'm trying to force mlrV to crash yet after 18 minutes of the most intense button mashing all i have is a perfectly functioning patch and very sore wrists / fingers.

  as agargara suggested (and the folks on the cycling'74 forum tended to agree with) it is groove~ that is causing the problem. the suggestion from that forum was to send out all the data that is sent to groove~ out over a network and see what data it is that crashes max.

  i have made it happen once today but there was nothing unusual about the data i got - just seemed like a random crash. if i could get as many people as possible to run the attached udpreceiver in Max (full version) and play mlrV is maxRuntime then, when it crashes, copy all the data in the max window (in fullversion) and paste into a text editor - then attach it to this thread.

  that way i will be able to see if there is a pattern with the crashes rather than having to slam my monome for 12 hours to make it crash twice.

  thanks guys and i am really hoping we can sort this out! this bug has been my biggest fear every time i've gone on stage w/ mlr (though thankfully it has only ever happened at home).

  t.g

  • udpreceiver.maxpat 1.2 KB

• You flagged this item as spam.
  

  agargara December 9th, 2008 @ 03:12 PM

  Not sure if this is helpful or even meaningful, but here's something I've noticed:

  Sometimes Max seems to crash more often than others. That is, sometimes I will try to reproduce the bug and it will take two hours before it freezes. Other times it will freeze five minutes after I open it every time, and will consistently do this for a while. This behavior makes me think it might be related to something else running on my computer but I haven't noticed any patterns yet.

• You flagged this item as spam.
  

  Eimhin December 10th, 2008 @ 02:36 AM

  Have the crashes occured in Windows XP only? I've had mlrV crash on me many times as well. Usually when I am pressing a lot of pads on the same row. I'll copy the text next time it happens.

• 

  galapagoose December 10th, 2008 @ 10:53 AM

  agargara - i too have found that after one crash it is likely to happen again in short succession. i don't really know what to read from this, but maybe i need to be more open minded...

  yes, the bug does occur on windows and mac.

  however, this doesn't necessarily mean that it is the SAME bug.

  in my investigations as to what was causing the crash though (including artificially slamming mlrV with 4000 button presses per second and it not crashing) i realised about twice as much data is being bussed around the program than is necessary.

  as such, the new rev.2 i am posting up now is much more efficient and should have less likelihood of overloading groove~

  download it and tell me if you're still having the same problems. t.g

• You flagged this item as spam.
  

  agargara December 10th, 2008 @ 01:00 PM

  Cool! I'm glad that some good has come out of this problem. Unfortunately the optimized version crashed the same way just 5 minutes after I loaded it and started playing around. :/

• You flagged this item as spam.
  

  agargara December 10th, 2008 @ 01:49 PM

  I've started to notice that certain samples crash all the time while other samples don't...at first I thought it had something to do with sample rate or bit rate but that doesn't seem to be the case...I'll try to investigate this further.

• 

  % December 11th, 2008 @ 04:05 AM

  crashed for me too last night in the middle of some rapid pressin' - right after i started playing on a new row. i'll check into my sample rates...

• You flagged this item as spam.
  

  Tomasz February 18th, 2009 @ 07:22 AM

  Not a fix but a potential workaround: I pushed a change to github that adds an option to turn of multi-press looping. http://github.com/bitbutter/mlrv...

  A couple of folk on the monome forum reported that turning this off seems to have stopped the freezing/crashing. YMMV.

• 

  galapagoose September 23rd, 2009 @ 09:48 PM

  • State changed from “open” to “resolved”
  • Assigned user set to “galapagoose”

  this has been fixed in the newest version [18.9.9]

  NOTE:: it requires the use of a Max External to avoid the inherent instability of the [groove~] object

  http://post.monome.org/comments.php?DiscussionID=5764