Diemo Schwarz

Wow, that's a BIG bug! I managed to get Max5.1.0 into a state where no connections could be made anymore, and then, in any loaded patch, almost all connections were lost (except a few and signal)!

Hide/Show Connections was not part of it, of course. After throwing away the preferences folder, everything is fine again, but it is still freaky!

How I got there? I was undoing/redoing in a subpatcher a lot, then suddenly no connections could be made anymore, so I saved and quit.

Wow, that's a BIG bug!  I managed to get Max5.1.0 into a state where no connections could be made anymore, and then, in any loaded patch, almost all connections were lost (except a few and signal)!

Hide/Show Connections was not part of it, of course.  After throwing away the preferences folder, everything is fine again, but it is still freaky!

How I got there?  I was undoing/redoing in a subpatcher a lot, then suddenly no connections could be made anymore, so I saved and quit.


argh-all-connections-lost

Now I discovered that the above bug has a consequence in the patch saved when Max was in connection limbo (attached for testing): Trying to de-encapsulate [p add-std] within [p sequence-descriptors] crashes:

0 com.cycling74.MaxMSP     0x00122e8a jbox_getobject(_jbox*) + 6

1 com.cycling74.MaxMSP     0x001afe89 PatcherComponent::menu_dodeencapsulate(object*, object*) + 651

2 com.cycling74.MaxMSP     0x001b09a7 PatcherComponent::menu_deencapsulate() + 295

3 com.cycling74.MaxMSP     0x000deb87 object_handlecommand + 79

4 com.cycling74.MaxMSP     0x001ca7a4 patcherview_command(_patcherview*, symbol*, long, atom*, atom*) + 142

5 com.cycling74.MaxMSP     0x000b70d7 object_method_typed + 127

6 com.cycling74.MaxMSP     0x0015d206 jmenu_command_process(_jcommand*, unsigned long, object*) + 526

7 com.cycling74.MaxMSP     0x0015d24c jmenu_process + 46

8 com.cycling74.MaxMSP     0x000df422 interface_process + 24

9 com.cycling74.MaxMSP     0x00012aa5 app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 169

10 com.apple.HIToolbox     0x92adc13d DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1181

Now I discovered that the above bug has a consequence in the patch saved when Max was in connection limbo (attached for testing):  Trying to de-encapsulate [p add-std] within [p sequence-descriptors] crashes:

Thread 0 Crashed:
0   com.cycling74.MaxMSP          	0x00122e8a jbox_getobject(_jbox*) + 6
1   com.cycling74.MaxMSP          	0x001afe89 PatcherComponent::menu_dodeencapsulate(object*, object*) + 651
2   com.cycling74.MaxMSP          	0x001b09a7 PatcherComponent::menu_deencapsulate() + 295
3   com.cycling74.MaxMSP          	0x000deb87 object_handlecommand + 79
4   com.cycling74.MaxMSP          	0x001ca7a4 patcherview_command(_patcherview*, symbol*, long, atom*, atom*) + 142
5   com.cycling74.MaxMSP          	0x000b70d7 object_method_typed + 127
6   com.cycling74.MaxMSP          	0x0015d206 jmenu_command_process(_jcommand*, unsigned long, object*) + 526
7   com.cycling74.MaxMSP          	0x0015d24c jmenu_process + 46
8   com.cycling74.MaxMSP          	0x000df422 interface_process + 24
9   com.cycling74.MaxMSP          	0x00012aa5 app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 169
10  com.apple.HIToolbox           	0x92adc13d DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1181


ARGH! All connections lost!!!