Why is MaxMSP the crashiest (and most expensive) piece of software I own
Hi,
MaxMSP is one of the few pieces of commercial software I own and it is also the crashiest. I haven't experienced predictable crashes as others have, luckily, but it crashes often during regular UI interactions. For example, I try to add a button (ie: something that doesn't effect the operation of the running patch).. I click the button icon and CRASH. This is a good example of the kind of thing that causes it. It seems to be when I'm moving too fast.. the same thing happens in Sketchup: I'm clicking back and forth between tools and CRASH. Is this something to do with the MacOS? I think it's not a coincidence that both of those software packages are cross-platform and aren't written specifically for Cocoa? Anyway, is there some official way that I can report these events so maybe it can get more reliable in the future?
Thanks for any info,
Rob
Max 5, in my opinion seems to have a few more random crashes than 4.6 but Max 5 is relatively new. In a more general sense, I think thats what happens when you've got code(objects) not widely tested from a zillion people floating around in the same program.
It sounds like there's something else funky in your system. Always check the crash report to see what it was.
i *wish* they were reproducible. i routinely provide feedback to the authors of all the software i use, but in this case it's nothing that i can really be specific about. i'd say this might happen a couple times in a 3 hour span but, as anyone knows, that's more than enough to be frustrating. in a way, it's good because the workaround to this kind of flakiness is to save often. of course, the other side of it is that i don't have much trust in this tool and i don't have much useful info for the authors to fix the problem.
rob d wrote on Sat, 12 September 2009 14:55i'd say this might happen a couple times in a 3 hour span but, as anyone knows, that's more than enough to be frustrating............. i don't have much trust in this tool and i don't have much useful info for the authors to fix the problem.
That sounds like a lot more crashing than one should expect. Most of the crashes I experience are related to my own external development, and thereore occur in my own code (and are my fault), or sometimes in other 3rd party code. I do also experience crashes in cycling code, but these are rarer - tend to be reproducible, or involve patches with very heavy demands in which problems are difficult to trace.
Are you using any 3rd party externals or libraries? Are your crashes related to work on a particular patch, or a particular set of patches? Have you checked the crash logs (you can look at recent crashes using console)? Is there anything unusual about your system/setup?
Finally I'd add that random crashes that I experience are almost always when patching. I find max to be very reliable in performance - but I do heavily stress test my patches prior to use.
Hope you can perhaps get some improvement with this situation.
Regards
Alex
My two cents:
Me and Sarah (we're a duo) use the exact same patch i made, on pretty much identical white MacBooks, except I usually have the patch open in Max (5) and she always has it open in Runtime (5). Whenever mine is "doing too much thinking" i.e. too many parts open/unmuted, it can crash. Hers has NEVER crashed.
I have TOTALLY not tested this properly yet, but I'm going to start running mine in runtime and see what happens.
Is the problem editing / the ability to edit a patch while it's running?
n
i think so, i've often had max crash when editing with audio switched on
Yup, I agree with Alex here, the frequency which you describe is quite high. I regularly work entire days without crashes.
I feel it does depend mostly on:
- how intensive the patch is you're working on. Our older big patch (100mb) will crash more frequently than a small editor.
- how clean the patch is you're working on. Our newer big patch is much cleaner thanks to the approach, and hardly ever crashes, even when editing.
- Working with a lot of video and opengl seems to increase it, particularly on more difficult tasks like capturing and cutting up tracks.
- how much you are patching, copying stuff around, creating instances etc. When you do things faster crashes happen more often. This is less since Max5 (except for the slowdown when your copy buffer contains a lot).
- which externals you use.
I always look at the error messages. Mine are sometimes quicktime, some are videocard driver/opengl issues. Recently, I haven't really had many of these, and even less 'general' max crashes. Just looked in the console, 5 real crashes total in the last 20 days of work for me.
I'm just going to have to pay more attention to the circumstances when it happens. I don't use Max very frequently. I can say that the last time it happened, the patch that I was working on only had a few objects in it - I was just getting started. There may have been another one in the background, though, so I can't say for sure. Do most people stop their patches from running (CMD+.) when they're working on it? I mean is it common for you to go back and forth with CMD+./CMD+R frequently while working in Max?
Thanks,
Rob
You might have a look to objects like gate / switch in order to switch things on and off. Turning off the entire scheduler is unlikely to be the best approach.
rob d wrote on Mon, 14 September 2009 17:36re. Do most people stop their patches from running (CMD+.) when they're working on it? I mean is it common for you to go back and forth with CMD+./CMD+R frequently while working in Max?
most people use maxmsp mainly because it is an enviroment
where you can run the scheduler as well as the audio during
programming.
to me it seems somehow the main feature in it that you can
patch while sequencers and synths are running.
-110
Hi,
I remember having lots of crashes after upgrading from Max 4.6 to Max 5. When I check my crash logs of recent months however, I see only 4 crashes which are not related to testing and debugging my own externals. One of those 4 was directly after updating to Max 5.07, during the process of "harvesting metadata".
I have never been able to trace a specific object, function or condition where Max 5 crashes, but I seem to have developed a sense for actions which are better avoided. I use a pen tablet, so I can wildly move around with the cursor, pointing to objects in edit mode and see the object inspector flickering in it's hurry to show object attributes. That is a sure way to provoke a crash sooner or later, in my experience. Therefore I close the inspector when I do not need it. I also recall that inserting the cursor at the beginning of an instantiated object(or message?) box can be risky. That is the place where the tiny "open inspector" button pops up, and there have been a couple of times when this little i was the last thing that I saw just before a crash. In retrospect, virtually all Max5 crashes I experienced were somehow related to the object inspector.
Katja
MacBook 2 GHz OS 10.5 Max 5.07
Rob D, I never stop running my patch when I'm editing, only if it's really heavy and it bothers the speed of my editing. Apart from that, I just lock and unlock at will...
I also have occasional crashes only while patching. Completely independent on the size or complexity of the patch. But it is rare, the crash log seems to point to some juice code. But I can't really read them properly...
I guess we could send all of them to support, with a note that its probably not connected to a specific patch and such not reproducible. The action which seemed to have triggered it should be mentioned. Maybe there is a pattern which could give a hint...
So far performing is fine, and even my live coding session at NK in Berlin last month was fine...;-)
Stefan
"So far performing is fine, and even my live coding session at NK in Berlin last month was fine...;-)"
live coding with MSP? tell me more, im v. intrigued.. do you have any stuff online from the performance? iv tried a bit with supercollider but never got round the patch cord > audio clicks issue with max/MSP. that said, i haven't attempted it recently..
And our performance:
The musical quality is debatable, but certainly its fun...;-)
Stefan