< Back to IRCAM Forum

Yin~ unresponsive after ~10 minutes

Max Sound Box
#1

yin~ (pitch analysis), version 6/2023 (19)
Max 8
Windows 11
48k sr, 128 io vector, 64 signal vector

I have a patch that is using yin, and it reliably works for around 10-12 minutes, at which point, yin~ becomes unresponsive to incoming signal.
Dsp and data processing continues in the rest of the patch, but yin remains unresponsive until I toggle audio processing off and on or add a dsp object (ie just create a new [cycle~] object.

Is there a message I can send to the yin~ object to reinitialize it? Or is this a known problem that has a solution? cycling dsp globally isn’t an option.

#2

Hi, two more questions:

  • what are your scheduler in overdrive/audio interrupt settings?
  • how complex is the rest of the patch, esp. what follows from yin’s output?
#3

I had this exact lockup issue with yin~ during extended sessions on Windows. Because creating a new DSP object temporarily revives it, it sounds like an internal buffer overflow or denormal float problem that only gets cleared when Max is forced to recompile the DSP chain. Since you can’t restart DSP globally, the cleanest workaround is to isolate the yin~ object inside a [poly~ 1] subpatch. This lets you send a mute 1 followed immediately by a mute 0 to that specific voice, which triggers a localized DSP reset without interrupting your main audio stream. You could also try sending a clear message directly to the object first to see if it flushes the history buffer, but the poly~ method is usually rock solid if you need a seamless background fix.

#4

I posted this question over on the cycling74 board as well.
Based on feedback there, I’ve switched to using flucoma’s [fluid.pitch~] object, which defaults to an fft version of the yin algorithm.
I had the rest of my patch tuned to to output of ircam’s yin~, so I would happily return to it if there was a way to make it stable on windows.

#5

Interesting!
I used to have in inside a poly~, but I took it out to make debugging the patch easier. That must by why I’m only encountering this problem now.

#6

Overdrive On, Interrupt Off.
The rest of the patch is pretty complicated and cpu intensive.
Though demanding, the rest of the patch is cpu stable after it has loaded up. Yin is the only object that creates cpu spikes.

#7

thanks for the details. The strange thing is that there is no buffering in yin~ (unlike pipo~). The output is scheduled via clock_fdelay(), and the analysis part is deterministic. What hop size do you use (third param, default 5ms)? A possible hypothesis is that if it is shorter than the time taken by the downstream patch, the scheduler gets overloaded. Try to double that time, and also adapt the min freq (2nd param) it will reduce the number of candidate pitches checked.
@lmoreau93 's denormals hypothesis could be checked by adding noise at some -100dB.

#8

my creation arguments are: [yin~ 3 60 10.]
I don’t have a lot of context to compare, but these seem like conservative values?
I am using yin to analyze voice input, so I don’t want to set the minimum frequency above 60 hz.

@schwartz I took your advice and tried 20 ms, and even 100 ms, but the time yin~ remained in operation never went above about 20 minutes. I also did previously test with
[noise~] → [*~ .000001] → [yin~]
and the results were unaffected.

I ended up following @lmoreau93’s advice and putting yin~ (back) in a poly~.
Interestingly,
“mute $1” → [thispoly~]
didn’t fix it, but force reloading the poly~ patcher via message seems to be working:
every time a message ends, I send message
“patchername yinpoly.maxpat” → [poly~].

I don’t know if the timing of the patchername operation is predictable, and it isn’t elegant, but it works for now. Happy to try any other suggestions, and thanks again for the ideas.

#9

Do you mean just these three objects, without the heavy patch behind it? Then we’d really have a problem on Windows. (Mac is fine, of course…)