1

I've been working on a synthesizer built with Pd and running it on a BeagleBone Black. For this, I've written a number of abstractions and two externals. Right now the synth is monophonic and uses 100% CPU when started, causing many audible clicks and artifacts. After about 5 seconds, it "stabilizes" down to 75% CPU and the latency and sound is pretty good.

Now, I need to make the synth polyphonic so CPU time has to be freed for the additional voices. For this, I'm thinking about building Pd with debug symbols and running my patch through a profiler such as Callgrind/KCacheGrind to try to figure out where most CPU consumption is happening and optimizing around that.

Can anyone share any techniques or tips used to optimize Pd patches and externals? Are there any tools specific for Pd for this kind of task? Any reason why my approach would or would not work?

umläute
  • 28,885
  • 9
  • 68
  • 122
Rafael Vega
  • 4,575
  • 4
  • 32
  • 50

2 Answers2

1

your patch seems to be heavy to execute. It mean that you're doing lot of calculation any time when you run your synthesizer. What kind of synthesizer it is ?

Often a way to reduce calculation cost, it's to fix value, calculated first, once for all. (for example if you always use the same value, it could be interesting to read it on an array instead of calculate it any time). You can tell us more about the architecture of your program, may be we will be able to help you more specifically.

Good luck !

Dadep
  • 2,796
  • 5
  • 27
  • 40
0

using full fledged profiler-tools is of course an option. the main downside is, that they will considerably slow down the system, so you might need a fully automated test-case (rather than relying on the real-time nature of the environment).

as for in-patch profiling, the best Pd offers is the [realtime] object which you can use to measure the time needed (wall clock time, not logical time which should be zero) to execute a specific operation in message domain. However, this is not usable for signal objects!!

Here's an example to profile the full execution of a subtree (within the [pd complicated] subpatch) and of a few select objects (within the [pd complex] subpatch)

Profiling patch

From your description, it seems that your patch spends a lot of time during initialisation (maxing out the CPU, so it takes a while to drop below 100%), which most likely indicates problems in the message domain.

As for the signal domain, typical problems involve reblocking to small block-sizes ([block~ 1]), and computing unused voices (turn them off with [switch~] if they adding to the signal output).

Community
  • 1
  • 1
umläute
  • 28,885
  • 9
  • 68
  • 122