I've been porting a PD patch running on my Mac over to Bela - the patch is for an electronic viola I'm designing. It's a pretty extensive patch and can get CPU intensive. There are many times where the Bela's CPU overloads, usually when running simultaneous processing (signal processing, synthesizers, etc & each viola string has it's own signal chain) and/or various FFT processing algorithms (esp when getting to larger block sizes (256, 512, 1024, 2048 ...) which I need for the sonic qualities I'm going for). I'm considering everything I can do to optimize the patch. A few questions on ideas I'm looking in to:

I'm seeing that several of the PD objects I use are not listed as being supported by Heavy (https://github.com/CarloCattano/hvcc/blob/master/docs/14.Supported_vanilla_objects.md):
||
cputime
expr
Netsend
Netreceive
Textfile

Bang~
Block~
Expr~
rfft~
rifft~
Switch~
tabreceive~
vline~

The patch still runs, however. Is it just that these objects are not compiled to run with lower level optimization? Any suggestions?

Also, I remember reading that expr / expr~ aren't CPU friendly - is it suggested to instead use the normal PD + - * / objects instead?

Something simple, like using * instead of / for math? Helpful?

A few things I have done:
-implemented switch~ all over the patch to turn things off not in use & help out the Bela.
-followed the suggestion (https://forum.bela.io/d/490-underrun-detected-errors) to distribute cpu load across different audio callback when possible

Any thoughts on previous questions and/or ways to optimize this PD patch? Thank you 🙂

    violapwr The patch still runs, however. Is it just that these objects are not compiled to run with lower level optimization?

    those objects will be ignored by heavy and will not be in the patch. There is an almost drop-in replacement hv.vline in heavylib. bang~ is easily emulated. most of [expr~] and [expr] should be rewritable using basic operators. [cputime] you probably don't actually need ... [netsend] and [netreceive] can be implemented relatively easily in the C++ wrapper. I guess textfile as well.

    The real problem for you - it would seem - is that, in general, anything that relates to blocks is not implemented by Heavy. [block~] and [switch~] for instance, but also all the fft stuff. There is no easy way around it, unless you are willing to reimplement them in C++ and use "fake" output and input channels in your patch to communicate with the C++ wrapper. While the FFT DSP itself can be done using the Bela's Fft library, you' d have to implement threads communicating with each other, unless you accept the latency due to the larger blocksizes needed to perform the FFT in the audio thread.

    If the above sounds like a daunting task, it's because it is.

    In the first place, you should probably try to scale back the amount of CPU usage of your patch. Given how at the moment you are getting a lot of dropouts, you don't actually know where you stand in terms of CPU usage on Bela. Put this file in your project alongside _main.pd: https://gist.github.com/giuliomoro/990f430a464a60f88b1f8e9c1ce30005. Run the project . It won't actually generate any audio but it will print an estimate of the average CPU time. What value do you get?

        thanks for the detailed response giuliomoro - although my C/C++ skills are about 15 years rusty, perhaps the route to go is re-work the patch in C/C++?

        And this is the result of the test:

        It took 3.487752 seconds of CPU time to run 10.000000 seconds of audio (estimated CPU usage: 39.9%)

        That said, I do have the patch set that none of the CPU intensive stuff is running at the beginning; it only gets switched on as the user enables various functions. The benefit is that, as long as the user doesn't trigger the CPU intensive functions (FFTs with large block sizes, oversampling for anti-aliasing, having 4 simultaneous signal chains running (1 for each viola string)) there is a lot of functionality that works just fine.

        Thanks again