Dynamical pipo~ processing and CPU load

[sirnotto]

Hi!

A colleague and I are currently building a patch that is meant to take a large number of descriptors from the real time audio input and use this dynamically. In the patch there should be an option to activate or deactivate which descriptors are being channeled to the rest of the patch. Most of the descriptors are from ircamdescriptors, but also from yin and descr.

We are wondering what could be the most economic way of doing this in terms of CPU load.

One way we have tried is to have one pipo~ per descriptor, and gate the signal being fed to each one (off if the descriptor is not chosen). However, this didn’t seem to make a difference in the CPU load, even when there is no signal into all the pipos, the CPU is at the same level. So it seems pipo is doing something even with no input?

Another option is to dynamically add or take away descriptors from one pipo object (e.g. only one pipo~ ircamdescriptor object but activating/deactivating descriptor arguments through message triggers). However, we haven’t tried this yet because this will make the output vary and we’re not sure how to route date from the descriptors when the output is changing all the time (though I’m sure there is a workaround for this).

A third option is to use poly~ objects, and have one pipo~ process in each poly~ patch. This would mean that processing would stop if the poly~ patch is switched off (controlled by which descriptors are activated). This actually seems to make a difference, but it seems like a very cumbersome workaround to have a poly~ patch for each descriptor.

What would be the best approach?

Notto

[schwarz]

Hi Notto,

@sirnotto

One way we have tried is to have one pipo~ per descriptor,

ircamdescriptor shares the heavy fft processing between all descriptors, it would be wasteful to do that all over again for each descriptor.

@sirnotto

and gate the signal being fed to each one (off if the descriptor is not chosen). However, this didn’t seem to make a difference in the CPU load, even when there is no signal into all the pipos, the CPU is at the same level. So it seems pipo is doing something even with no input?

well, in Max DSP there is no such thing as “no input”, it is silence, but will still be processed…
However, since MuBu 1.9.14 pipo~ has an attribute @active to enable/disable processing.

@sirnotto

Another option is to dynamically add or take away descriptors from one pipo object (e.g. only one pipo~ ircamdescriptor

that would work, but beware that changing the @ircamdescriptor.descriptors list may be costly.
You can query the column names for routing.

HTH, Diemo

[sirnotto]

Thanks, Diemo! It sounds like @active is what might be the best option.

Best,
Notto

[berntisak]

Hi Diemo and thanks for the tips!

Im working with @sirnotto on this and it looks like @active might not solve our issue anyway since it will turn of all the processing and we just want turn off specific descriptors. Am I right to assume that the overhead from the fft if we do separate objects per descriptors would be much higher than letting letting all descriptors be calculated all the time?

I dont think we’ll be changing the descriptors in real time though - just want a dynamic system where its easy to reuse the same code with different subsets of descriptors, so maybe changing the descriptor list is the best way to go?

[schwarz]

Hi Bernt,

@berntisak

Am I right to assume that the overhead from the fft if we do separate objects per descriptors would be much higher than letting letting all descriptors be calculated all the time?

Yes! To give you more grips on performance details: there is one more (common) processing step for each of the big groups of Spectral, Perceptual, Harmonic descriptors, which is added internally when one of them is used.
So indeed, changing the descriptors list is easiest for ircamdescriptors, just don’t do it in between notes, wait for the end of a phrase or movement at least.
For yin, descr, etc., just switch it on if needed.

[berntisak]

Changing the descriptor list worked great for us! Its more of a per project or session thing anyway, so not something which get spammed during performance. We also found that pipo needed to be deactivated while changing the descriptor list otherwise Max would crash quite frequently. I wanted to upload our patch to show how we solved it in case someone else would be interested but I got the error message “Sorry, new users can not upload attachments.”