jonat8han

I've been using max/msp for my live music years & years - finally added a synchronized video/jitter component on a separate machine, receiving messages wirelessly with udpsend/receive. It works brilliantly, and I'm quite pleased, but occasionally I get a crash. I can't seem to recreate exact circumstances that cause the crash - sometimes it happens quite quickly during a show, sometimes not at all, sometimes 30-40 minutes in ... it's seemingly arbitrary.

I'm currently on a tour, and hadn't noticed these crashes before I left - it's hard to troubleshoot on the road, and it's really hard to effectively gather data *during* a performance :-)

The crash log is the same every time, so I'm wondering if anyone has seen anything like this & if there are any common pitfalls I should be avoiding? As I said, I'm new to jitter, so I may be missing some eccentricities!

There's no audio running in my patch, if that helps/matters.

One of the (many) crashlogs is attached as a file.

THanks - I appreciate your time & any help you can give!

I've been using max/msp for my live music years & years - finally added a synchronized video/jitter component on a separate machine, receiving messages wirelessly with udpsend/receive.  It works brilliantly, and I'm quite pleased, but occasionally I get a crash.  I can't seem to recreate exact circumstances that cause the crash - sometimes it happens quite quickly during a show, sometimes not at all, sometimes 30-40 minutes in ... it's seemingly arbitrary.

The crash log is the same every time, so I'm wondering if anyone has seen anything like this & if there are any common pitfalls I should be avoiding?  As I said, I'm new to jitter, so I may be missing some eccentricities!

There's no audio running in my patch, if that helps/matters.  

new-to-jitter-old-to-max-having-some-crashes-help

Are you getting a decent frame rate and such, is the machine struggling before it crashes? Can't really tell much from a crash log personally, but patch might help if you don't mind posting.

The machine doesn't seem to be struggling, but like I said I'm usually performing & not looking at the screen when it crashes, so it's hard to say for sure. It usually seems to sit @ about 85% of the CPU (according to iStat Menus) while running, using about 150mb of ram. Frame rate seems to hover between 18-24, but again, I can't speak for when it actually crashes, as I have my attention in other places.

I'm a little hesitant to attach my patch, but here it is ... it's kind of a mess & won't do anything without the controlling audio patch on the other computer.

Basically it accepts a bunch of incoming messages over UDP, and uses them to apply some simplistic video effects to quicktime movies it pulls at random from a series of folders - which folder it pulls from is determined by the running time of the performance (also sent from the audio machine).

The machine doesn't seem to be struggling, but like I said I'm usually performing & not looking at the screen when it crashes, so it's hard to say for sure.  It usually seems to sit @ about 85% of the CPU (according to iStat Menus) while running, using about 150mb of ram.  Frame rate seems to hover between 18-24, but again, I can't speak for when it actually crashes, as I have my attention in other places.

Sorry, make that around 65% of the CPU, 160mb of RAM (used by Max) and framerates of 16-20 approx, but hovering around 18.

1) Your jit.qt.movie objects are set to play video files at dimensions 853 x 480. Is this size correct, and is it the native resolution of your files? I ask because I have experienced Quicktime problems with files whose dimensions are NOT a multiple of 4. (Can't say definitely that this is causing you problems, but there it is.)

2) Is it possible that there could be some condition that causes your audio controller patch to send out too many messages too quickly -- more than the video patch is comfortable handling?

Problems like this one are indeed painful. Much testing is advised...

Yes - the 853x480 size is correct - that's the SD resolution standard that keeps clips in the 16x9 ratio.

It's entirely possible that conditions arise that cause the audio controller patch to send a lot of messages very quickly, yes ... but how quickly could possibly be *too* quickly? If the network can handle it, shouldn't the udpreceive object? Is there an elegant way to limit my network traffic?

To further complicate things, at tonight's virtually unattended show, the video ran flawlessly for several hours ...

It's entirely possible that conditions arise that cause the audio controller patch to send a lot of messages very quickly, yes ... but how quickly could possibly be *too* quickly?  If the network can handle it, shouldn't the udpreceive object?  Is there an elegant way to limit my network traffic?

To further complicate things, at tonight's virtually unattended show, the video ran flawlessly for several hours ...


After a few days of running without incident - had a crash the other night. Seems slightly different to me. Crashlog is attached ... any further ideas?

After a few days of running without incident - had a crash the other night. Seems slightly different to me.  Crashlog is attached ... any further ideas?


I don't *think* so ... like i said, Max is only using about 160mb of memory running the patch typically, and it's the only thing open ... I have 4gb in the machine. It crashed again tonight - attaching that crashlog. The last couple of crashes have started with

0 libSystem.B.dylib     0x95d02a34 pthread_mutex_lock + 24

any further ideas? Thanks for all your help ... I'm pretty baffled ...

I don't *think* so ... like i said, Max is only using about 160mb of memory running the patch typically, and it's the only thing open ... I have 4gb in the machine.  It crashed again tonight - attaching that crashlog.  The last couple of crashes have started with

0   libSystem.B.dylib             	0x95d02a34 pthread_mutex_lock + 24

any further ideas?  Thanks for all your help ... I'm pretty baffled ...


It would appear you are crashing with your use of coll from multiple threads during the process of merging. I'm going to investigate further this crash to try and prevent it. However, in the meantime, you can test by disabling overdrive. Let us know if that solves your issues. If it does, and you need overdrive on for other reasons, you'll want to do things like add a deferlow to the output of udpreceive, and change your metro usage to qmetro or metro @defer 1.

ah, so the bjorklund stuff is the culprit? I might just cut that out until I have time to look at it a little better ... I actually didn't make that, but stole it from a friend.

But first I'll try with overdrive off and see if I get any crashes ... I only have two more shows on this tour, but we'll see. No crashes last night (with overdrive on)

ah, so the bjorklund stuff is the culprit?  I might just cut that out until I have time to look at it a little better ... I actually didn't make that, but stole it from a friend.

But first I'll try with overdrive off and see if I get any crashes ... I only have two more shows on this tour, but we'll see.  No crashes last night (with overdrive on)

New to Jitter, old to Max - having some crashes - help?