it is also true in Pd so a core bug.
gnarly catch
Hi, there’s another thing I noticed recently: Very rarely my spectshape feature buffer chan 6 contains a -nan(inf) value which completely ruins the bufstats~ output.
Here I tracked it down to a single frame position in the feature buffer:
With any material at all?
what is in chan 6, is there only digital silence?
The other values in chan 6 are valid flatness values, only 1 or 2 frames have the -nan(inf). The thing is I can’t nail down the exact conditions when it happens. For example the files from yesterday which produced the nans reliably do pass without any problems today. So it is not related to the material but maybe to my hardware or Os (or time the patch is running), as nobody else of you came accross this.
I tried to match and replace the nans from the buf2list output but Max was not matching -nan(inf) as a symbol. But after duplicating the message box once, Max did match it. UTF8 related? I can’t tell, but I will report back if I have more useful infos on this.
Edit: What I can tell for sure is: it happened multiple times on different days and it’s always and only in chan 6 of the spectshape features.
I wonder if it’s an initialisation or repeated-run issue. Thanks for flagging it – I’ll see if I can chase it down.
It’ll be Max’s transcoding of a floating point NaN in the first instance (so almost impossible to catch in Max itself), and possibly become a symbol when you copy the message. By and large NaN-debugging in Max is a horror show.
2 Likes
I have a hypothesis, based on a smelly bit of code I found and your report of it being sporadic, but no luck yet getting to happen. If I’m right, then it’s going to happen probably only in release builds under heavier load.
Mind you, I haven’t checked on Windows yet, which IIRC is what you run?
because we just found out that the latest version was not the latest for a window that I don’t know, @11olsen can you check the version you are on by sending any [fluid.buf*] the version message
Running Win 10 on Intel i5 (no AVX if you remember). And: Fluid Corpus Manipulation Toolkit, version 1.0.0-TB2.beta3
AVX is a thing of the past now (between the new Macs not supporting it and the problems it caused for people with older processors, we took the decision to junk it from this release on).
My very simple-minded test patch doesn’t reproduce on Windows yet. What else is in your pipeline? Are there lots of other bits of processing? (My hypothesis is that this is a memory issue in release builds, so that something other than what we intend might be being read in spectralshape) .
Could it be a problem that i’m starting slicing and all feature extractors at once, all @blocking 0? Also I remember having many patcher windows opened when it happened. I will check my pc state next time
It could well be the type of bug that gets more likely once there’s a bunch of stuff going on in parallel. I’ve submitted a fix (for what I hope is the cause) for my colleagues to look at - thanks once I again for reporting.
1 Like