dhjdhjdhj

While it appears that the scheduling issues I encountered in earlier versions of Max 6 are solved in 6.0.5, I've run into a new problem. It's clearly timing related because I can't control exactly WHEN it will happen but I can pretty confidently make it happen in reasonably short order by sending a lot of OSC data from my Eigenharp Alpha into Max 6 (I don't believe the problem is with the OSC stuff though).

While Max 5 behaves perfectly fine, Max 6 will crash within 5 to 15 seconds of my just sliding my hand over multiple keys of the eigenharp.

I'm wondering if someone can tell from the stack trace what might be going on. For example, what object might jbox_updatetextfield_safe be referring to?

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

0 com.cycling74.Max     0x0000d5a4 atombuf_totext_flags + 322

1 com.cycling74.Max     0x001250a5 jbox_updatetextfield_safe + 159

2 com.cycling74.MaxAPI     0x02af7a9d jbox_updatetextfield_safe + 45

3 com.cycling74.message     0x0e7e6565 jmessage_qfn + 25

4 com.cycling74.Max     0x00030084 sched_dequeue + 256

5 com.cycling74.Max     0x00017cb4 max_tick + 81

6 com.cycling74.Max     0x00311bd7 juce::InternalTimerThread::callTimers() + 133

7 com.cycling74.Max     0x0031197e non-virtual thunk to juce::InternalTimerThread::handleMessage(juce::Message const&) + 20

8 com.cycling74.Max     0x00310575 juce::MessageManager::deliverMessage(juce::Message*) + 137

9 com.cycling74.Max     0x0042dafe juce::AppDelegateRedirector::runLoopCallback() + 116

10 com.apple.CoreFoundation     0x9123e13f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15

11 com.apple.CoreFoundation     0x9123daf6 __CFRunLoopDoSources0 + 246

12 com.apple.CoreFoundation     0x912679c8 __CFRunLoopRun + 1112

13 com.apple.CoreFoundation     0x912671dc CFRunLoopRunSpecific + 332

14 com.apple.CoreFoundation     0x91267088 CFRunLoopRunInMode + 120

15 com.apple.HIToolbox     0x98c29723 RunCurrentEventLoopInMode + 318

16 com.apple.HIToolbox     0x98c30a8b ReceiveNextEventCommon + 381

17 com.apple.HIToolbox     0x98c308fa BlockUntilNextEventMatchingListInMode + 88

18 com.apple.AppKit     0x9a9850d8 _DPSNextEvent + 678

19 com.apple.AppKit     0x9a984942 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113

20 com.apple.AppKit     0x9a980cb1 -[NSApplication run] + 911

21 com.cycling74.Max     0x004189c7 juce::MessageManager::runDispatchLoop() + 731

22 com.cycling74.Max     0x002a8896 juce::JUCEApplication::main(juce::StringArray const&) + 68

23 com.cycling74.Max     0x002a89b9 juce::JUCEApplication::main(int, char const**) + 73

24 com.cycling74.Max     0x0000ad0b _start + 209

25 com.cycling74.Max     0x0000ac39 start + 41

I'm wondering if someone can tell from the stack trace what might be going on. For example, what object might jbox_updatetextfield_safe be referring to? 

---------------
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.cycling74.Max             	0x0000d5a4 atombuf_totext_flags + 322
1   com.cycling74.Max             	0x001250a5 jbox_updatetextfield_safe + 159
2   com.cycling74.MaxAPI          	0x02af7a9d jbox_updatetextfield_safe + 45
3   com.cycling74.message         	0x0e7e6565 jmessage_qfn + 25
4   com.cycling74.Max             	0x00030084 sched_dequeue + 256
5   com.cycling74.Max             	0x00017cb4 max_tick + 81
6   com.cycling74.Max             	0x00311bd7 juce::InternalTimerThread::callTimers() + 133
7   com.cycling74.Max             	0x0031197e non-virtual thunk to juce::InternalTimerThread::handleMessage(juce::Message const&) + 20
8   com.cycling74.Max             	0x00310575 juce::MessageManager::deliverMessage(juce::Message*) + 137
9   com.cycling74.Max             	0x0042dafe juce::AppDelegateRedirector::runLoopCallback() + 116
10  com.apple.CoreFoundation      	0x9123e13f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
11  com.apple.CoreFoundation      	0x9123daf6 __CFRunLoopDoSources0 + 246
12  com.apple.CoreFoundation      	0x912679c8 __CFRunLoopRun + 1112
13  com.apple.CoreFoundation      	0x912671dc CFRunLoopRunSpecific + 332
14  com.apple.CoreFoundation      	0x91267088 CFRunLoopRunInMode + 120
15  com.apple.HIToolbox           	0x98c29723 RunCurrentEventLoopInMode + 318
16  com.apple.HIToolbox           	0x98c30a8b ReceiveNextEventCommon + 381
17  com.apple.HIToolbox           	0x98c308fa BlockUntilNextEventMatchingListInMode + 88
18  com.apple.AppKit              	0x9a9850d8 _DPSNextEvent + 678
19  com.apple.AppKit              	0x9a984942 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
20  com.apple.AppKit              	0x9a980cb1 -[NSApplication run] + 911
21  com.cycling74.Max             	0x004189c7 juce::MessageManager::runDispatchLoop() + 731
22  com.cycling74.Max             	0x002a8896 juce::JUCEApplication::main(juce::StringArray const&) + 68
23  com.cycling74.Max             	0x002a89b9 juce::JUCEApplication::main(int, char const**) + 73
24  com.cycling74.Max             	0x0000ad0b _start + 209
25  com.cycling74.Max             	0x0000ac39 start + 41


crash-in-latest-max-6-0-5-but-works-fine-in-max-5

Well, that's a good question (and the support team queried this as well). The problem is that my 'patch' contains many sub patchers and abstractions and this use of a message box is not something I tend to use other than accidentally. So it's going to be a headache to find it.

Anyone know of good tools for finding particularly configured objects in a nested folder?

Well, that's a good question (and the support team queried this as well). The problem is that my 'patch' contains many sub patchers and abstractions and this use of a message box is not something I tend to use other than accidentally. So it's going to be a headache to find it.
Anyone know of good tools for finding particularly configured objects in a nested folder?


If I knew which .maxpat file to open, this would not be an issue. The problem is that my system is made up of (at this point) hundreds of abstractions and other patchers so it's almost literally looking for a needle in a haystack.

I could do a recursive grep but the problem there is that I would get every single 'message' object in my environment.

So I really need a better mechanism for searching that recognizes connections as well.

Speaking of better mechanisms, what I would kill for is a visual "diff" so that I can compare different versions of max objects that are checked into my version control system.

All the 'diff' systems for comparing different versions of a file are text based. But it's almost impossible to use them with max patchers because, when you make even a minor change, the objects get reordered in the file and so the textual changes look huge to a diff tool.

So it would be extremely useful to have a tool that can visually display two versions of a patcher, highlighting the areas that are different. Non-trivial but probably a very interesting project (any grad students out there looking for a project?)

Yeah, I shouldn't have mentioned 'diff' --- that's a red herring in terms of my problem. I don't know how Shark would help me --- we already believe it's a messagebox (an object supplied by Cycling74) that's causing the issue --- the question is finding WHICH message box in a large number of patchers and abstractions is responsible.

Crash in latest Max 6.0.5 but works fine in Max 5