Snapshot~ Dysfunction


    Jan 14 2018 | 1:04 am
    Hello, After a few minutes of using the [snapshot~] it stops working or samples in a random manners, only if I shut the program and restart it, or disconnect [snapshot~] from its wires and undo it, or delete it and then undo it back it returns to work properly. (The problem goes just the same with the [number~] which release its values as a floats from it's right outlet) .
    Please help, thanks in advance. Zion

    • Aug 13 2019 | 8:17 pm
      I have the same issue. Snapshot~ regularly stops working. Number~ right outlet or peakamp~ work.
    • Oct 02 2019 | 3:14 pm
      I have a similar problem that has cost me many sleepless nights. just found out in a sub-sub-sub-patch that snapshot works when and if it wants...
    • Oct 02 2019 | 4:39 pm
      Do you have problems with snapshot~ with automatic reporting, or when banging it? If it's with "automatic" periodical reporting, which time interval do you use? Do you have simultaneous heavy Max processing? Are you working with Overdrive On?
    • Oct 02 2019 | 8:20 pm
      Hey Jean-Francois, longtime no see! I was using automatic reporting at 1ms. I changed it to 10ms but didn't help. Not sure if I have heavy max processing but there are several amplitude tracking mechanisms that used snapshot~. Yes, I am working with Overdrive On. I have changed it to number~ using the right output and seems like the problem is gone.
    • Oct 02 2019 | 9:02 pm
      Phivos, good to hear from you! Yes, the default sampling interval for [number~] is 100 ms (check the Inspector). If it's good for your application, then try [snapshot~] with an interval of 100 ms, or drive yourself the bangs to [snapshot~] with a [metro 100] for instance. Logically, at the same sampling interval, [snapshot~] should work as well as [number~]! (It might be even a little better on the CPU since it doesn't have a UI to update). I'd be curious to know if there is a bug somewhere.
    • Oct 02 2019 | 9:04 pm
      I think there is a bug.
    • Oct 03 2019 | 12:22 pm
      Hey Jean-François! It seems like the number~ solution works fine so I will not risk another sleepless night with snapshot~ ever again... Thanks for your suggestions :)
    • Dec 04 2019 | 2:02 pm
      I also ran into issues with snapshot~ and following your suggestions I just switched to using number~ in a subpatcher. Shame that such a basic and important function appears to be unreliable right now.
    • Dec 04 2019 | 2:51 pm
      if you dont need scheduler accuracy, qmetro might work in many situations?
    • Dec 04 2019 | 2:53 pm
      unfortunately I want to reference an sfplay playback position.
    • Dec 04 2019 | 6:56 pm
      What sampling interval are you using? I have found [snapshot~] very reliable over the years, and I suspect [number~] to be equivalent.
    • Dec 04 2019 | 7:12 pm
      i had snapshot~set to 100 but number~is not running reliably either for some reason. I have to reconnect the patch cord from the sfplay~ every now and then for it to keep reporting the play position. Could this be an issue with the buffer rate? I have it on 60000 on a file with 275mb and a length of 17:20 minutes. This is really a problem for my application.
    • Dec 04 2019 | 7:15 pm
      this is an example part of my patch and represents what I am working with. Along to this file I am running 5 others of the same size without set buffer size or playback position outlets. Any help would be super appreciated!
    • Dec 04 2019 | 8:07 pm
      this doesnt solve the original problem (i had issues with snapshot 20 years ago so this isnt even a new issue) but of course you could do a lot of things which doesnt require to do that with audio signals at all. for example you could create a custom playbar object which triggers a data rate clocker. this would even generate a more accurate output than the attempt with snapshot because it is independet from the audio vectorsize.
    • Dec 09 2019 | 4:07 pm
      @DIMBELS as stated above, I solved the issue using number~ right outlet.
    • Dec 09 2019 | 4:08 pm
      btw, I have reported the bug already to the Max developing team and I was hoping that it would have been already resolved. Kind of surprised it still persists.
    • Dec 09 2019 | 4:10 pm
      In addition, I am surprised that there is such an issue on a such a fundamental object. It has cost me many unstable days of an interactive installation during a festival. Unfortunately, has made me question the reliability of MaxMSP all along, considering the circumstances of the negative exposure.
    • Jul 30 2020 | 11:19 am
      Testing a patch using [snapshot~ 20] on another machine than the one I usually use (same Max version, same scheduler settings, same OS X.14), I discovered that this pesky snapshot~ stopped after ±15 minutes. Systematically, with or wirthout overdrive, 10 times in a row. With Max7, it stops too, also after ±15 minutes.
      I fist slows down its output rate then stops until I restart the DSP chain.
      The only difference between both setup is the chosen soundcard : snapshot~ stops when I select Dante Virtual Soundcard (latest version), but not with a MOTU or RME driver. Nor with BlackHole.
      Like Roman, I had issues with snapshot~ since years with other soundcards, but it's the first time I have it dysfunctioning with a reproductible pattern. I may try to send a bug report, but Kollias did it already, and probaly many other users in ther past.
    • Jul 30 2020 | 3:22 pm
      If it's reproductible, I hope you send a bug report. Not sure c74 are looking at this, but they would certainly appreciate a clear bug report. If you can reproduce with a simple patch, you could also share here: maybe other users could try on their systems (I would...) J-F
    • Jul 30 2020 | 5:02 pm
      for my part i have long given up on everthing but finding workarounds; all my peakamp~ objects use external metros since a decade, and now they work.*) my main issue always was that peakamp~ in max4 simply stops working after 2-3 or so DSP restarts have happened. when i noticed that it does the same thing in max5, i have made a decision. but it is interesting that it happens in both of these objects and across 20 years of max application on 3 different operating systems - whereas, if anything, then the audio IO driver could make a difference for some of us. this should almost lead the developer to the exact problem, me thinks. *) i´ve learned that in my 25 years of political activities: if you want something to be done, do it on your own. i mean i dont even care if something is buggy or if it is maybe my fault? there is a problem, i fix it!
    • Jul 30 2020 | 5:06 pm
      which other objects beside these two have an internal clock type of thing which does something with the audio in while also having an audio out?
    • Jul 30 2020 | 5:14 pm
      average~? but i have used that extensively and not found any problems. it might be using a completly different technique internally, like buffers?
    • Jul 30 2020 | 8:35 pm
      Yes, I did a bug report hopping one day that we all be free of this bug. However, for me Snapshot~ is dead, as I cannot rely on an object that cannot be 100% accurate and that during an installation, where I ll be resting home, someone may call me to fix it (happened already). number~ does the job, although it looks rather amateurish and not sure how optimised it is in terms of CPU.
    • Jul 30 2020 | 8:43 pm
      Patrick, when your snapshot~ dies, does it still respond to a bang? I'm using snapshot~ also only with external triggering indeed, like what Roman mentions with peakamp~. I might even use most often [qmetro] to trigger my snapshot~. With that, I have not encountered any problem (patch running for hours).
    • Jul 30 2020 | 9:27 pm
      peakamp reports at DSP ON which it shouldnt: https://cycling74.com/forums/peakamp-behavior multiple peakamps in the same patch behave differently: https://cycling74.com/forums/max-5-0-5-problems peakamp keeps reporting after audio has been turned off in poly https://cycling74.com/forums/peakamp-inside-of-poly even spambots have problems with peakamp: https://cycling74.com/forums/peakamp-in-g5 :D
    • Jul 30 2020 | 9:34 pm
      peakamp~. etwas zum naschen, etwas zum spielen, UND schokolade. © 1998-2020
    • Jul 31 2020 | 9:47 am
      JF, snapshot~ still responds to a bang. And of course a metro is a good (hopefully) workaround. Here is the patch (it's just a snapshot~…). [snapshot~ 20] and [number~] (also set to 20) will both stop systematically after ±16 minutes on my recent Mac mini, under latests X.14, with the latest Max (but also with the latest Max7), using the latest Audinate DVS driver as output. It will sometimes stop, later, with other audio drivers (even Apple's own Mac mini speaker). It didn't stop yet with and older laptop, under X.12 and an older DVS driver.
    • Jul 31 2020 | 7:15 pm
      Interesting, very clear and simple test patch indeed. On a 2015 laptop with OSX 10.14, no problem for more than 5 hours on the Built-in output. But as you say, it is linked to some interaction between Max and the driver.
    • Jul 31 2020 | 7:44 pm
      and if you filter out denormal data at their audio outlets?
    • Aug 03 2020 | 6:41 am
      I had similar problems in the past with other msp objects sending non-audio values, like years ago Jehan's analysis tools, or more recently some of ej's zsa objects.