< Back to IRCAM Forum

Pipo~ slice:yin reports “processing load too heavy” and pitch tracking becomes unstable

MuBu
#1

Hello,

I am using the latest version of the MuBu package with Max 9.1.1 on macOS Sequoia running on an Apple M3 Max.

I use PiPo~ for real-time pitch tracking of a monophonic theremin signal.

My PiPo~ object is:

pipo~ slice:yin @slice.size 1024 @slice.hop 128

After running correctly for some time, the Max console starts displaying the following warning repeatedly:

pipo~: “slice:yin” audio or pipo processing load too heavy, skipped 2064 output frames since last warning (2341 total, reporting every 1000)

When this happens, pitch tracking becomes unreliable, as if the analysis can no longer keep up.

What is particularly surprising is that I did not change anything in my patch. I simply opened another Max patch window, and the warning immediately stopped. Pitch tracking became stable again without restarting the DSP or modifying the patch. This behavior seems quite strange.

My audio settings are:

  • Max 9.1.1
  • macOS Sequoia
  • Apple M3 Max (36 GB RAM)
  • RME Fireface UCX II
  • Sample Rate: 44.1 kHz
  • I/O Vector Size: 512
  • Signal Vector Size: 64
  • Overdrive: On
  • Scheduler in Audio Interrupt: Off

Could you please explain what exactly triggers this warning?

I would like to know:

  • What does “processing load too heavy” actually mean in this context?
  • Does “skipped output frames” mean that some pitch analyses are simply discarded?
  • Is this due to CPU load, audio scheduling, or a limitation of the YIN implementation?
  • Why would simply opening another Max patch window apparently solve the problem?
  • Are there recommended settings for reliable, continuous real-time pitch tracking with slice:yin?

If needed, I can also provide a minimal test patch.

Thank you very much for your help.

Best regards,

Claudio

#2

Hi Claudio, thanks for your detailed report.

  • What does “processing load too heavy” actually mean in this context?

This means that the downstream patch’s processing is too heavy to keep up with the rate of messages, and the internal buffer from audio thread to timer thread gets full.
Pipo is probably too honest here to output a message, while the Max scheduler sometimes simply drops messages silently.

  • Does “skipped output frames” mean that some pitch analyses are simply discarded?

yes, but unfortunately it is the newest frames (thus the unreliability/lag). We’re thinking about an option to discard the oldest frames in this case.

  • Is this due to CPU load, audio scheduling, or a limitation of the YIN implementation?

CPU load of the patch behind pipo~

  • Why would simply opening another Max patch window apparently solve the problem?

this is because Max will stop audio for some time while the new patch loads, giving pipo~ a chance to flush the buffer. There is also a reset message to pipo~.

  • Are there recommended settings for reliable, continuous real-time pitch tracking with slice:yin?

either increase your hopsize, or put a speedlim behind pipo~

We’d still be curious to see your test patch.

HTH, best

#3

Hi Diemo,

Thank you very much for your detailed explanation. It really helped me understand what was happening.

I’ve already made a couple of changes to my patch:

  • I added a message “active” so that PiPo~ is only enabled when I actually need pitch tracking.
  • I also changed the settings from:

pipo~ slice:yin @slice.size 1024 @slice.hop 128

to

pipo~ slice:yin @slice.size 1024 @slice.hop 256

It’s a bit of a gamble, but I’m going to test it during my last performance later today and see how it behaves under real conditions.

Thanks again for your help. I’ll let you know how it goes.

Best,

Claudio