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.