Snapshot~ Dysfunction
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
I have the same issue. Snapshot~ regularly stops working. Number~ right outlet or peakamp~ work.
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...
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?
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.
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.
I think there is a bug.
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 :)
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.
if you dont need scheduler accuracy, qmetro might work in many situations?
unfortunately I want to reference an sfplay playback position.
What sampling interval are you using?
I have found [snapshot~] very reliable over the years, and I suspect [number~] to be equivalent.
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.
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!
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.
@DIMBELS as stated above, I solved the issue using number~ right outlet.
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.
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.
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.
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
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!
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?
average~? but i have used that extensively and not found any problems.
it might be using a completly different technique internally, like buffers?
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.
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).
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
peakamp~. etwas zum naschen, etwas zum spielen, UND schokolade. © 1998-2020
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.
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.
and if you filter out denormal data at their audio outlets?
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.
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.
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
Hi there,
The bug is in both snapshot~ and number~.
A fun thing to try: wait 15 more minutes; does snapshot~ (or number~) restart?
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
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)...
Really, indeed!! getting tired of Max....
-P
I sent a bug report to c74.
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)
Thank you @Source Audio for your suggestion
Is this different from number~ ?
Did you test it long enough?
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 .
to rephrase my question, is meter~ doing a more reliable job than number~ in Max 8 ?
Phivos, if I have a chance to do so I'll test meter~ tomorrow on my sensible - Dante based - system.
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.
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
The current fix for snapshot~ is to bang it externally, for instance with a metro or a qmetro. That is reliable.
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;
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.
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…
really happy we have figured out some more reliable solutions. The community self-organises around a common goal!
@Roman Thilenius your solution looks good I will try it.
@ pdelges
can you please rephrase? seems to be a typo that doesn't make clear your point
Oopps, sorry. I corrected my post. I meant of course that meter~ doesn't stop.
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.
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
havent seen it with meter either. why does meter work for some people and for others not?
In my case (Dante driver), I don't notice any difference with Max8.1.6 :-(
p
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.
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...
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.
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.
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
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.
We should keep hammering cycling 74 with bug reports. I still cannot believe this is still an issue...
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.
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.
"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. ;)
@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!
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.
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.
This is great news! Snapshot~ finally is fixed! Thank you Alex and Cycling74! there is still hope in this planet
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.
the joke that it would be fixed now is older than the bug itself.
use metro or qmetro and be happy.
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…
oh, sigmund, that one is not on my radar at all.
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
I resent a bug report ;-)
p
you still have that email from 1999 in your "sent" box?
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 ;-)
https://web.archive.org/web/19980212053116/http://www.opcode.com/support/
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…
@PDELGES Happy to investigate, do you have a patch we can try? Please drop a note to Support , thanks!
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.
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?
I believe it is fixed.