Fluid.ampfeature~ stops working sometimes?

[rodrigo.constanzo]

I’ve been experiencing this issue somewhat rarely where the onset detection in my patches stops working (all other audio carries on), and it’s been very tricky to track down since recompiling the DSP chain resets the problem (so adding scope~s and such ends up fixing things before I can find out where the problem is happening).

BUT

Last night I managed to be able to narrow it down to, I believe, fluid.ampfeature~. Here’s a video showing the problem (pardon the shitty audio as it’s just a laptop screencapture):

Audio Freeze?

In the vid you can see that the signal coming out of fluid.ampfeature~ completely stops (and Max playback continues). I didn’t have a number~ box connected, but that scope is going from 2-20 so it likely dropped to 0 when it died(?). You can also see the CPU drop when this happens. When I delete/undo the live.scope~ you can see the audio start up again.

If you listen closely you can hear a little ‘click’ when the audio freezes as well.

Coincidentally in this video the freeze seems to happen right as the audio comes to the end of the loop, but this is just chance as it happened many other times and seemingly randomly.

This is on my (slower) laptop, but I have also experienced the same issue on my (M2) desktop this morning, but much much more rarely (it’s happened once this morning while testing the same patch but having a hard time reproducing).

This is on version 1.0.6+sha.e748875.core.sha.f694a366 (on both machines), with the desktop being Max 8.5.6 on OS 13.4.1, and the laptop on 8.5.5 and I don’t remember the OS but it’s a maybe OS11 or thereabouts).

One thing that occured to me is that it could somehow be the internal filter blowing up as that sort of click followed by silence reminds me of that. Trying to see if I can get it to reproduce now to then set @highpassfreq to 0 to bypass it (according to the docs).

/////////////////////////////////////////////////////////////////////////////////////////////

Does this point to anything?
Is there anything else I can try and do to “capture” the problem? (since it’s not crashing or producing a crash report, that’s about as far as I know how to look).
I’ll see if I can get it to reproduce consistently again and see if the @highpassfilter bypassing removes the problem (potentially pointing at a blown up filter being the issue?

[tremblap]

@rodrigo.constanzo

see if the @highpassfilter bypassing removes the problem

that is a first good hypothesis since you can’t bypass it. So you must put a super low freq to the highpass and that might be the reason?

I can also send a Test build which could ‘crash on assert’ if there is something nasty happening under the hood (these ‘crashes’ are meant to exist when we run code with specific conditions and are removed for production)

[rodrigo.constanzo]

Just tried the same patch on my laptop and after running it for 10min I couldn’t get it to reproduce, which is frustrating as last night it was happening after running it for no more than 30-60 seconds.

Max was running a bit more sluggish then too, so maybe having more windows/ram gobbled up by browser stuff somehow impacts things?

@tremblap

that is a first good hypothesis since you can’t bypass it. So you must put a super low freq to the highpass and that might be the reason?

You can’t bypass it?

The reference says setting it to 0 bypasses it:

As a point of reference I generally run the highpass really high (2k) and had it set to that when it was freezing yesterday. You can make out the attributes in the vid above (though the cable covers it a bit).

[rodrigo.constanzo]

Ok, an update!

Got it to reproduce on my (M2) destop.

When the ‘click’ happens and it stops output, it spits out a nan not a zero, so hopefully that points to something.

AND setting @highpassfreq 0 has no impact as it can still freeze/crash.

Here’s a vid example where it starts off already crashed (I started screen capture once I saw it happen):

audio freeze2

You can also see how little time it takes to crash again, this is how it was happening yesterday, and again today.

Also, in this version what you see on the screen is the whole patch, the previous video was inside the abstraction. (The UI thing on the bottom is just a sampler player, playing back a random sample on trigger input).

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Actually on watching the video it looks like the crashes here happen on the repeat of the playback loop in both cases. That seems a bit suspicious.

Here’s the very start of that file (tiny fragment of silence):

And the end has a fade to zero:

So there is a sharp/pure silence (~38 samples) right when the loop repeats.

I made a little thing that can manually insert 38sample silences into the audio going into fluid.ampfeature~ but that seemed to have no effect (even clicking it dozens of times):

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Ok, testing a bit more I noticed that sometimes the playlist~ object is actually producing that click sound we hear, and only on the repeat of the sample.

I recorded a bit of the playlist~ and fluid.ampfeature~ output and got this at the moment that it crashed:

Sadly I only captured it with the default sfrecord~ settings so those are just -1.0s in the audio playback. Trying to reproduce it now recording at float32 to see if it’s a nan or something weird that playlist~ is putting out.

[rodrigo.constanzo]

AAAnd it looks like playlist~ can sometimes send a nan.

Managed to capture the audio recording at float32.

Looks like this in Audacity this time:

But if I load it into Max and try and use fluid.waveform~ to view it, it crashes Max.

crash.zip (50.9 KB)

But if I just do it the old-fashioned way and peek~ to my destination I see this:

So it seems like the error is originating in playlist~. I don’t know if that’s something that fluid.ampfeature~ should be robust against (other objects seem to have no issue with it, other than the audible click), but will report to c74.

[tremblap]

@rodrigo.constanzo

You can’t bypass it?

that’ll teach me to reply from memory- yes you can sorry!

@rodrigo.constanzo

So it seems like the error is originating in playlist~. I don’t know if that’s something that fluid.ampfeature~ should be robust against

NaNs are evil. But yes we should be careful about them in a running agerage like this so I reckon we should do a bug report. it is never good.

[rodrigo.constanzo]

I’ll make a git issue for this.

Should it go in core or Max?

edit:
I put it here, it can be moved if needed.

[tremblap]

thanks I moved it to core (it is the underlying algo)

[rodrigo.constanzo]

Cool. I thought that may be the case but given the Max-specificity of playlist~ I went there first.

Felt like a detective this morning chasing that down!

Also found out that Logic (or perhaps Kontakt in this case by misreporting offset) adds silence to the start of a bounced file even if you select the start directly on a region.

[tremblap]

this fixes it. it might have a (infinitely small) cost but can you test it you own rigorous way please @rodrigo.constanzo ?

rt-amp.zip (245.7 KB)

[rodrigo.constanzo]

I’ve actually not experienced the issue since these last posts (I guess c74 fixed whatever was NaN-ing in playlist~, but will test it out with @weefuzzy’s NaN-nator examples.

edit:

Cool as far as I can tell, this is not breaking now. Single NaNs don’t impact anything (including the envelope followers) and the stream of NaNs just pull the follower output to zero (which is the intended/fine behavior here).

[tremblap]

my nan-tor example in the gitrepo is also cute - but I’m sure @weefuzzy’s is cleverer!

In all cases that is sorted for all env and include infinities and nans, all of which were Supabad™ for envelopes…