Heavy CPU use on Granular Delay Patch

mrnavigator5000

Hello!

I'm currently working on a 4 voice delay and pitch shifter for a Bela Mini based on Johannes Kriedler's live granular synthesis patches: http://www.pd-tutorial.com/english/ch03s07.html#id430983

The PD patch can be found here along with more information: https://github.com/mrnotneb/BelaLiveGranular

I've managed to get it working, but have run into some complications:

The patch runs at around 50-60% CPU, which I think might be a bit much. The patch has audio crackle/distortion and sometimes drops out if there's too much input coming in (am using a stereo electret mic pair as an input)
I'm getting the line expr: divided by zero detected in the Bela IDE, which I think might be a feature of Johannes Kriedler's original patch.
I was getting Underrun detected: 1 Block Dropped in the IDE till I increased block size to 128.

I'd love some advice on the following:

How much CPU is too much? I've tried compiling it in Heavy to make it less CPU intense but unfortunately the expr object is unsupported.
Is there a way of making this patch more efficient?
What are the consequences/trade offs, if any, for increasing block size?

Thanks!

giuliomoro

mrnavigator5000 How much CPU is too much?

you should be able to get to about 98% * before you hear crackles IF the cpu load is split evenly across audio callbacks.

* this requires setting the --high-performance-mode command line option in the project settings. When running in this mode with high CPU usage, the IDE will most likely become unresponsive while the program is running and so in order to stop the running program you have to press the button on the cape.

mrnavigator5000 I was getting Underrun detected: 1 Block Dropped in the IDE till I increased block size to 128.

this could well be a symptom that the CPU load is not spread evenly across audio callbacks.

mrnavigator5000 Is there a way of making this patch more efficient?

removing the expr object is often a way to optimise a patch. In this case it would be even better as it would allow it to build wit heavy.

mrnavigator5000 What are the consequences/trade offs, if any, for increasing block size?

it increases latency, reduces some of the CPU overhead (i.e.: frees up some more CPU % for your code to run) and it allows to spread the CPU load more evenly.

giuliomoro

giuliomoro removing the expr object is often a way to optimise a patch

actually it's [expr~] that tends to be more of a CPU time sink, unless you call [expr] very often.

alexmich

giuliomoro actually it's [expr~] that tends to be more of a CPU time sink

Does it mean that doing the same computation using individual operators (such as [*~] , [+~], [/~], etc) and whatever else to do the conditional statements instead of [expr~] would have a chance to reduce the CPU load?

giuliomoro

You kind of are calling it frequently (about 160 times per second if I am right...) . It seems that you could reduce the number of times it gets called to one quarter of that if you were to do the following. Instead of sending to v1w and v1p to [expr (pow(2, ($f2/12)) -1) * (44100/$f1)], you should:

process the messages through expr before you [send ] them .
do not use [t b f] for the right inlet. As both the right and left inlets are going to receive messages regularly (at the same logical time), you are currently processing them twice with the same values. Remove the [t b f] and they will just be processed once.

mrnavigator5000

Hi Giulio,

Thanks so much for the comprehensive answer - that's really helpful to know. Looking forward to trying out some of these recommendations!

I was wondering (and perhaps this is quite a basic question), what does it mean for CPU load to be spread evenly across audio callbacks? Anyway to keep an eye out for whether patches are doing so?

giuliomoro

yes, a pretty big chance I think.