Max and live stuck when saving a device

    Oct 19 2016 | 3:25 pm
    I have to force quit both apps. This happens since I upgraded to version 9.7 and Max 7.3 Any similar cases ?
    MBP 2,3 ghz I7 16Go SSD+HD 10.8.5

    • Oct 19 2016 | 5:08 pm
      Sometimes it happens for me too, especially with a device that contains [live.step].
    • Oct 19 2016 | 6:12 pm
      yupp i see that too. since longer than Live 9/Max 7 already. but i couldn't reliably reproduce up to now. recently my suspicion goes to the Live parameter system (especially when pattr system is involved). There seem to be cases where Max updates the Live parameters while saving...
    • Oct 19 2016 | 6:45 pm
      Please give Max 7.3.1 a whirl, as these problems might be fixed with this release:
      Let us know if you are still having problems.
    • Oct 19 2016 | 8:07 pm
      I've just seen it and going to try. That happened to me even with the simplest patches containing just a few objects.
    • Oct 19 2016 | 11:08 pm
      @BEN BRAKEN: In my case it's still happening (with Max 7.3.1). Live crashes (and max freezes) occasionally when saving a device. The crash log looks like this:
      Common in all crashes is the line: WiresPrivate::mfl_device_blob_changed(WiresPrivate::_mfl_device*, symbol*, long, atom*, atom*)
      Thread 0 Crashed:: Dispatch queue:
      0              	0x0000000101c723c8 0x100000000 + 29828040
      1              	0x0000000101c92977 0x100000000 + 29960567
      2   com.cycling74.patcher         	0x000000011b74f91d WiresPrivate::mfl_device_blob_changed(WiresPrivate::_mfl_device*, symbol*, long, atom*, atom*) + 142
      3   com.cycling74.MaxPlugLib      	0x00000001250d5ff4 object_method_imp + 352
      4   com.cycling74.MaxPlugLib      	0x0000000125210c2e param_hub_blobchanged_qfn + 77
      5   com.cycling74.MaxPlugLib      	0x00000001250b6eb0 sched_dequeue + 198
      6   com.cycling74.MaxPlugLib      	0x00000001251e0d95 MainThreadEventHandler::invoke() + 101
      7   com.cycling74.MaxPlugLib      	0x000000012532a290 juce::InternalTimerThread::callTimers() + 176
      8   com.cycling74.MaxPlugLib      	0x0000000125329289 juce::MessageManager::deliverMessage(juce::Message*) + 55
      9   com.cycling74.MaxPlugLib      	0x000000012540e20f juce::AppDelegateRedirector::runLoopCallback() + 99
      10      	0x00007fff8c266881 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
      11      	0x00007fff8c245fbc __CFRunLoopDoSources0 + 556
      12      	0x00007fff8c2454df __CFRunLoopRun + 927
      13      	0x00007fff8c244ed8 CFRunLoopRunSpecific + 296
      14           	0x00007fff8bcf4935 RunCurrentEventLoopInMode + 235
      15           	0x00007fff8bcf476f ReceiveNextEventCommon + 432
      16           	0x00007fff8bcf45af _BlockUntilNextEventMatchingListInModeWithFilter + 71
      17              	0x00007fffa06e8df6 _DPSNextEvent + 1067
      18              	0x00007fffa06e8226 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
      19              	0x00007fffa06dcd80 -[NSApplication run] + 682
      20              	0x0000000100bd438b 0x100000000 + 12403595
      21              	0x00000001002bb709 0x100000000 + 2864905
      22              	0x0000000100001934 0x100000000 + 6452
      And the crashes disappear when I remove my pattrhub/autopattr/preset combination.
      The patch has some (4) bpathers containing live.ui object and autopattr all loading the same patch. This mean that the Long Names/Parameter Names names are identical and automatically index (parameterName[1]) by Max/Live. Could that be the reason?
      I also observed two curious things: * Sometimes after opening the device the autopattr object appears in the pattshub-storage window, sometimes not. * Sometime the indentation of the parameters inside the bpatchers disappear in the storage window - all parameters show on top level.
    • Oct 19 2016 | 11:18 pm
      @JAN, could you drop a note to support with an example patch? Also, is this the same crash as before? There were some changes to blob parameters for Max 7.3.1. Hopefully it is a quick fix!
    • Oct 20 2016 | 8:30 am
      Anecdotally, this looks like something different than the memory leak which was fixed for Max 7.3.1. This looks more like a bug we recently spent some time on which was reliably triggered by laying on the Save keyboard shortcut. We're still working with Ableton on a resolution for that, but it is on our radar.
      In any case, if you have an example device to send to support, that would be great.
    • Oct 20 2016 | 10:22 am
      @Jeremy @Ben : I'll send you something later today. I'll try to narrow it down before. Hopefully I will find sequence of steps that can reliably reproduce the issue. Right now it is quite unpredictable. I have some suspects that may be involved (e.g. combination of preset recalling/interpolating, having changed a parameter in the inspector plus Cmd+S).
      Indeed it occurred before and after 7.3.1
    • Oct 20 2016 | 4:47 pm
      It seems Max tries to save the device as a project (I accidentally found a zero ko project folder named like my device) when you try to save it. Is that normal behavior ? Then Max is stuck with the beachball and I have to force quit.
    • Oct 20 2016 | 4:56 pm
      Same happens to me sometimes when I save a m4l device. Fortunately the crash happens after saving. So I never lose progress but have to restart Live + M4L often after saving. But I can say it also happens with devices without pattr or preset or live.step. btw: on win 7
    • Oct 20 2016 | 5:06 pm
      The device is saved in the selected destination, but it's a "huge" 7.7 Mo considering it just contains a plugsync~object and a few number boxes... I can't open it again.
    • Oct 20 2016 | 5:21 pm
      Please put the corrupt device on Dropbox or something and send a link to support, please.
    • Oct 21 2016 | 2:52 pm
      Jeremy : done. Mentioned this thread...
    • Oct 21 2016 | 5:13 pm
      Same with 7.3.1 here. I've worked on a new device and Max seems to totally dislike the save command... Both apps crashed again, and but the device seems to be saved again with a "huge" filesize of 8 Mo... If I reload it and hit the edit button, max crashes. It seems really serious : I can't edit and save devices anymore. Please help !
    • Oct 25 2016 | 8:27 am
      It seems temperamental. Once I could rebuild the same simple device using [plugsync~] that had got corrupted in another attempt and I could save it regularly, re-open it, and its size is a normal 12 ko. But then I tried to construct another device based on the Four LFO patch by G. Taylor and Max crashed when saving, but I could find the saved corrupted device which is again more than 8 Mo...
    • Oct 26 2016 | 9:28 am
      Jeremy, any news ? I've got other corrupted files weighing almost the same size (from 5 to 8 Mo for very simple devices) of various failed attempts. I'm in the process of reinstalling Max and Live. First time such mess happens for me...
    • Oct 26 2016 | 9:38 am
      Sorry, I've been out sick the last couple of days. I'll take a look at the device this afternoon.
    • Oct 28 2016 | 9:44 am
      News boyz and girlz : Jeremy is investigating about a weird bug that has created about 12000 snapshots in my document folder and led to try to write them with each new device, hence the file size increase. According to C74, this is due to "poor design decision", they're working a a fix and probably a "rich design decision". After re-installing Max and Live everything seems back to normal.
    • Oct 28 2016 | 10:03 am
      Well, the "poor design decision" language wasn't an official statement, just my opinion about how the design causes what happens in this pathological case. In any case, the situation which led to the propagation of thousands of snapshots has been fixed and will be in a future update.
    • Oct 28 2016 | 12:10 pm
      Yeah, excuse me Jeremy for this lack of accuracy. Such a pathological case indeed ! First time I was stuck like this since I started with Max. Do you mean that it could happen again while waiting for the upd ?
    • Nov 29 2016 | 1:07 am
      Same here. I was wondering if the udp receive and send objects are the guilty ones. Do you guys use theses? The crash doesn't seem to happen when there's no such objects in the patch.
    • Nov 30 2016 | 4:18 pm
      No udp objects involved here.