Snapshot~ Dysfunction

zion's icon

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

Christopher Biggs's icon

I have the same issue. Snapshot~ regularly stops working. Number~ right outlet or peakamp~ work.

Phivos-Angelos Kollias's icon

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...

Jean-Francois Charles's icon

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?

Phivos-Angelos Kollias's icon

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.

Jean-Francois Charles's icon

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.

Christopher Biggs's icon

I think there is a bug.

Phivos-Angelos Kollias's icon

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 :)

dimbels's icon

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.

Roman Thilenius's icon


if you dont need scheduler accuracy, qmetro might work in many situations?

dimbels's icon

unfortunately I want to reference an sfplay playback position.

Jean-Francois Charles's icon

What sampling interval are you using?
I have found [snapshot~] very reliable over the years, and I suspect [number~] to be equivalent.

dimbels's icon

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.

dimbels's icon

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!

Max Patch
Copy patch and select New From Clipboard in Max.

Roman Thilenius's icon


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.

Phivos-Angelos Kollias's icon

@DIMBELS as stated above, I solved the issue using number~ right outlet.

Phivos-Angelos Kollias's icon

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.

Phivos-Angelos Kollias's icon

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.

pdelges's icon

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.

Jean-Francois Charles's icon

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

Roman Thilenius's icon


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!

Roman Thilenius's icon


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?

Roman Thilenius's icon


average~? but i have used that extensively and not found any problems.

it might be using a completly different technique internally, like buffers?

Phivos-Angelos Kollias's icon

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.

Jean-Francois Charles's icon

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).

Roman Thilenius's icon


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

Roman Thilenius's icon


peakamp~. etwas zum naschen, etwas zum spielen, UND schokolade. © 1998-2020

pdelges's icon

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.

Max Patch
Copy patch and select New From Clipboard in Max.

Jean-Francois Charles's icon

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.

Roman Thilenius's icon

and if you filter out denormal data at their audio outlets?

pdelges's icon

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.

Jean-Francois Charles's icon

Patrick, since it's a clearly reproducible problem, I would suggest you send your support info (Max -> About Max -> Copy Support Information) along with your post, including your patch, to support @ cycling74... I think they are going to have a look.

Philippe Montemont's icon

Hello All, working here on a simple audio file reader with sfplay~ and snapshot~ , replaced later by number~ . My times displays stop working after a certain amount of time, yes around 15 minutes. My conclusion is that the bug is into sfplay~ !
Best,
-Philippe

Jean-Francois Charles's icon

Hi there,
The bug is in both snapshot~ and number~.
A fun thing to try: wait 15 more minutes; does snapshot~ (or number~) restart?

Philippe Montemont's icon

Hello,

I am afraid they don’t… I use my player for theater, shows are about 1 hour and 40 minutes long and I didn’t see my counters ( elapsed and remaining times ) restart. But I do not watch them at all times 😊 …

Best,

-Philippe

Phivos-Angelos Kollias's icon

Really frustrating to hear more and more people have the same issue and that there is still not a solution for such a fundamental function (that is turning audio information into numbers)...

Philippe Montemont's icon

Really, indeed!! getting tired of Max....
-P

pdelges's icon

I sent a bug report to c74.

Source Audio's icon

in Max 6 / snow leopard, both snapshot~ and number~
run 24 hours without hickup...
Till that gets fixed, at least for sfplay~ time display
anything that converts signal to float output would do the job.
even this : (won't let you down after 15 minutes)

Max Patch
Copy patch and select New From Clipboard in Max.

Phivos-Angelos Kollias's icon

Thank you @Source Audio for your suggestion
Is this different from number~ ?
Did you test it long enough?

Source Audio's icon

does it not look enough different from number ?
meter~ never stoped working for me.
it is a cheap way to convert signal to float, also for level measurement.
dividing audio length to 0 - 1 and expanding again does the work.
Again : both snapshot~ and meter~ work on max 6 without problem
at least in most cases, that bug must have been introduced in Max 7 .

Phivos-Angelos Kollias's icon

to rephrase my question, is meter~ doing a more reliable job than number~ in Max 8 ?

pdelges's icon

Phivos, if I have a chance to do so I'll test meter~ tomorrow on my sensible - Dante based - system.

Source Audio's icon

It is just a fix for snapshot and number drops in that particular case - time display for sfplay.
If you have no problem with meter, just keep using it, it is simpler
to use and needs nothing else.
If meter bugs you, than test this patch for as long as you want to find the answer to your question.
I have no time to run max 8 for that long to do the testing.

Philippe Montemont's icon

Thank you for the "meter trick". I still have four shows in the next four days. I am going to modify my patch and let you know the result.
Best
-Philippe

Jean-Francois Charles's icon

The current fix for snapshot~ is to bang it externally, for instance with a metro or a qmetro. That is reliable.

Roman Thilenius's icon



to fix your existing patches, save as [snapworx~]


#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 25 142 88 9109513 prepend offset;
#N comlet signal values as float;
#P outlet 199 217 15 0;
#P newex 410 80 148 9109513 if $f1<5. then 5. else $f1;
#P newex 579 122 148 9109513 if $f1<5. then 100. else $f1;
#P newex 579 80 87 9109513 f #1;
#P newex 579 40 87 9109513 loadbang;
#P newex 280 122 32 9109513 t 1;
#P newex 230 122 32 9109513 t 0;
#P newex 333 142 87 9109513 metro 100;
#N comlet interval clock in ms;
#P inlet 410 40 15 0;
#N comlet signal in \, bang reports signal value;
#P inlet 25 40 15 0;
#P newex 25 102 188 9109513 route bang 0 1 stop start offset;
#P newex 199 162 87 9109513 snapshot~;
#P connect 8 0 9 0;
#P connect 7 0 8 0;
#P connect 10 0 4 1;
#P connect 9 0 4 1;
#P connect 3 0 10 0;
#P connect 5 0 4 0;
#P connect 6 0 4 0;
#P connect 1 2 6 0;
#P connect 1 4 6 0;
#P connect 1 1 5 0;
#P connect 1 3 5 0;
#P connect 0 0 11 0;
#P connect 4 0 0 0;
#P connect 12 0 0 0;
#P connect 1 0 0 0;
#P connect 1 6 0 0;
#P lcolor 6;
#P connect 1 5 12 0;
#P connect 2 0 1 0;
#P window clipboard copycount 13;

Roman Thilenius's icon


note that it is not giving 100% the same output.

neither metro nor qmetro (or metro-->defer) are giving you exactly the same clocking then what it inside the external.

what comes very, very close to the output of the external is to use metro when overdrive is off, 90% of the values then differ for 0. :)

i have chosen to use metro, so it will output different values depending whether overdrive is on or not.

but that should not at all matter for daily use. the internal stuff in the external is last but not least also never "accurate", and that is naturally for this application.

pdelges's icon

meter~ doesn't stop working on my test setup (I didn't try for long, but it was still running after snapshot~ & number~ stopped).
c74 are aware of the problem, and are working on improvements…

Phivos-Angelos Kollias's icon

really happy we have figured out some more reliable solutions. The community self-organises around a common goal!

Phivos-Angelos Kollias's icon

@Roman Thilenius your solution looks good I will try it.

Phivos-Angelos Kollias's icon

@ pdelges
can you please rephrase? seems to be a typo that doesn't make clear your point

pdelges's icon

Oopps, sorry. I corrected my post. I meant of course that meter~ doesn't stop.

Phivos-Angelos Kollias's icon

after several problems I had with snapshot the previous year, I replaced it with meter~ and did the job for me. It also has a rate of reporting the data, as snapshot has.
But feels risky if people reported having problems also with this object. As Jean-Francois Charles, pointed out initially, snapshot works with external triggering, thus it seems to me that the problem is the internal triggering mechanism.

Philippe Montemont's icon

Hello All, as I mentioned before, I tried the "meter trick" yesterday evening. Everything worked fine. Please note that I do not need really accurate timing ( theater). But nothing stopped working during the show. Thank you everybody for your help!
Best,
-Philippe

Roman Thilenius's icon


havent seen it with meter either. why does meter work for some people and for others not?

pdelges's icon

In my case (Dante driver), I don't notice any difference with Max8.1.6 :-(

p

Roman Thilenius's icon


meter~ has its own bugs of course; in max 4 it was calculating totally wrong values for the display.
also, in its inspector it said it had a lower limit of 20 ms reporting time, but in fact its 15 ms.

and i dont need to point out that it has some CPU overload because it is a GUI object.

Source Audio's icon

I would say quite few max objects had one or the other bug in the
numerous update history, starting from max 2 till today's version.
It makes no sense to go back and forth and compare what is - was or could be,
at least for me what counts is to get the stuff working now.
In max one usually gets choice of using several different objects for the same task.
I sometimes pick one in favour of the other, and can't allways say why really.
As long as it works I don't care.
Trouble starts when it doesn't. Than any workaround is welcome...

Roman Thilenius's icon


workarounds are easy to build when you´re experienced and when you know about the bug,

what remains a problem is when thousands of people stumble across the same bugs again and again since 20 years.

Dan Boothe's icon

I came across this thread as I was having the same problem with snapshot~ and also number~ grinding to a halt after a few minutes. In a compiled app the problem was even worse, with number~ not even working at time=0. YMMV, but I seem to have found success in both native Max and compiled apps by enabling both Scheduler Overdrive and Audio Interrupt. While it's hard not to be nervous that it will still stop eventually, so far so good.

pdelges's icon

Welcome!
I had problems with all possible settings of overdrive and SAI.
I wonder if this fzero~ issue it related to our issue. Both (and meter~) are "signal 2 message" objects

Roman Thilenius's icon

same here, have interrupt on all the time. maybe it is better but it is not gone. used to use metro after all the years.

Phivos-Angelos Kollias's icon

We should keep hammering cycling 74 with bug reports. I still cannot believe this is still an issue...

comaberlin georg klein's icon

Hi, just want report that I got the same problem: for my interactive installation running since 2017 I had to change audio interface (from RME to cheaper TASCAM) and then snapshot was stopping to work after one hour, half an hour.... Took me weeks to find out what's happening.
Thanks to Jean-Francois: With metro now it works again (Max 7) (but I do not need really accurate timing).
@C74: please fix it finally - it's incredible that this bug after years of complaining here is still an issue.

John Gibson's icon

A student here (on Windows 10) is noticing the same problem with snapshot~ stopping output after running < 10 minutes. He has also seen the same behavior with the right outlet of number~. Our workaround is to try to program his algorithm using straight audio signals, which is better anyway in his case. I guess the gold standard workaround is to trigger snapshot~ externally, which we will try. Thanks for all the suggestions in this thread; very helpful.

But why is this still unresolved after over three years of reports? This is a critical function for a real-time audio system.

Roman Thilenius's icon


"But why is this still unresolved after over three years of reports?"

25 years. it is 25 years now.

so it slowly gets pointless to ask for fixes, they never will come.

half the users have passed away in between, and the other half uses metro.

which is not a big deal, btw., and eventually you can even benefit from the situation and do some clever stuff with external clocks. ;)


Alex Van Gils's icon

@John — what version of Max is your student using? We introduced a fix to address this [snapshot~] and [number~] issue in Max 8.1.6, so if you are still seeing this in newer versions, we very much want to see it.

Could you send us a patch that demonstrates the issue with either object, along with your student's support information, to support@cycling74.com ?

To get the support information on Windows, they should navigate to Help > About Max > and then click "copy support information to clipboard."

Thank you!

John Gibson's icon

Roman, I'm warming to the external clock approach.

Alex Van Gils, thank you for your response. Good news! The student was using 8.1.0! I will try to get him to verify that the problem is gone for some version >= 8.1.6.

I tested this on my own computer, with 8.2.0 and a MOTU 1248 interface, using the very helpful test patch by @PDELGES above. All three legs of the test ran continuously for over 2 hours. I didn't verify the data, but our big problem was snapshot~ stopping unexpectedly.

Alex Van Gils's icon

Thank you, John—please do keep us updated, and send a patch and support information into support@cycling74.com if you or your student continues to have these issues, this is very helpful.

Phivos-Angelos Kollias's icon

This is great news! Snapshot~ finally is fixed! Thank you Alex and Cycling74! there is still hope in this planet

pdelges's icon

Phivos, I'l glad you sound so happy but I did some tests today and I'm afaraid I still have problems, this time with Max8.1.11 but also with Max8.2.2.
Again, this happens with the latest Audinate DVS driver.
I used the patch I posted here is july 2020, but this time I had to reduce snapshot~'s rate to 5ms.

As nowadays a big part of my Max usage is to play other peoples' patches (even sometimes people participating in this thread ;-), this becomes a huge problem.

Roman Thilenius's icon


the joke that it would be fixed now is older than the bug itself.

use metro or qmetro and be happy.

pdelges's icon

Of course there are workarounds for snapshot~, or yin~ (that also stops working after a while), but not for sigmund~ (it stops too after a while).
As I wrote, my concern is that when you open a patch you don't know you first have to analyse it to check wether it may use sensitive objects (and the list of those objects is unknown), then enventually find a workaround (and using yin~ with metro is not the same than usig sigmund~).
The idea behing using audio drivers is to abstract the audio interface from the software itself. Unfortunaltely it doesn't work with Max…

Roman Thilenius's icon


oh, sigmund, that one is not on my radar at all.

Phivos-Angelos Kollias's icon

I also have to attest that I just had a very unpleasant experience with snapshot again, naively thinking it was fixed.
It is a bizarre and sad matter the fact that a bug which is reportedly reported keep reappearing.

Also, it is rather strange that for reasons like that, people using open source like supercollider consider MaxMSP unreliable although it is a proprietary software...

rather frustrating, not to say more

pdelges's icon

I resent a bug report ;-)

p

Roman Thilenius's icon


you still have that email from 1999 in your "sent" box?

pdelges's icon

1999? Wasn't it still the Opcode ages? I don't remember wether Opcode had tech support for its customers.
Anyway, some of the dysfunctioning objects (like fzero~) didn't exist in 1999, so I had to write a new email ;-)

Rick's icon

https://web.archive.org/web/19980212053116/http://www.opcode.com/support/

pdelges's icon

I tried my snapshot~ test patch this morning. With DVS driver.

As usual, with Max8.1.11 all sensitive objects stopped working after 3'24".

With Max8.3, almost all MSP -> Max objects in my patch, even those not developed at cycling74 (like sigmund~ or yin~) are still working after more than an hour!!

Unfortunately fzero~ stopped after 55 minutes. Simply opening the "DSP Status" window was enough to restart it, but it stopped again a couple of minutes later.

I don't have time now to do extensive tests but I may be back on this topic in a couple of weeks…

Ben Bracken's icon

@PDELGES Happy to investigate, do you have a patch we can try? Please drop a note to Support , thanks!

pdelges's icon

It's always the same patch. I'll send it again to support later today.
It really seems to be related to the audio driver chosen, in my case Audinate's DVS.

pdelges's icon

I ran my snapshot~ etc. test patch with Max 8.3.2 during hours (with a 5ms period), with DVS and with the Mac's internal driver without any problems so far.
Is this bug finally fixed?

Jean-Francois Charles's icon

I believe it is fixed.