Beam crashing Max redux

Beam for Max
1

hi guys,

did you get the email i sent you about this? My main patcher with added Beam works initially, but suddenly quits after 3-5 minutes of playing the sensors. I sent the full crash report by email as I thought it would be too long to post here.

Apart from suddenly quitting, it’s all working beautifully!

Thanks

David

2

Hi David,

Sorry for not getting back to you earlier!

I’ve been trying to reproduce the crash by making a patch to recreate the situation I can distill in the crash log, but I haven’t been able to reproduce. Neither in Max 8.5.6 nor Max 8.6.1.

What I can tell from the crash log is that it’s happening in Max’s code related to creating and deleting dictionaries from multiple threads. Of course, it could be that we’re doing something wrong but it’s not immediately clear what.

I’m wondering whether the crash can be avoided by disabling ‘Overdrive’, so that the scheduler shares the same thread as the main thread. Could you give that a try?

Thanks,
Hidde

3

Hi Hidde,

Will do. I have workshops for the next 2 weeks, so I can try that out after school finishes.
(FYI I’m not using dictionaries in any other part of my patch. Which I can email you if that would help, but it’s quite large!)

4

Hi David,

Let me know if it works when you’ve found the time! And yes, if you ok with it, email me the patch and I’ll try to get it running.

5

Should I use the firstcontact@ email?

6

You can use hidde@showsync.com!

7

Sending via Wetransfer. Good luck figuring the app out! If you get stuck, here’s the online manual for the pre-Beam version…

8

hi Hidde,

i ran the Beam version of my app for this afternoon’s sessions, with Overdrive off, and it didn’t crash at all.
As my patch is fairly (input) data intensive, presumably I am better off if Overdrive is on. So is there something that can be changed in Beam that will allow this? (Or is there something I’m doing in the patch that could be safely changed?)

9

Hi David,

That’s good to know. This means that it is indeed a multithreading issue which should get fixed either on Beam’s side, or on Max’s side. Another option is to find the right place in the patch to put a [defer] object. That should fix the issue too. I would prefer to find a fix for Beam though, of course.

Unfortunately, I haven’t been able to reproduce the issue locally for me so it’s difficult to work on a fix. I think the most practical next step is to do a screen share session where we try to isolate the issue. With a bit of luck this will give us the insights we need.

I’ll reach out to you via email.

Hidde