Bela mini's processing power in Pure Data?

Ffen · 14 Feb

Hi all! im working on a project right now that im pretty sure the bela mini multichannel will be perfect for, but im a little concerned about processing power.

I will be using it to run a pure data patch consisting of an 8 in, 8 out audio mixer, with 3 band eq per channel (using 2 lop and 2 hip objects per channel), plus a 4 channel looper (using 4 30 second long tables and tabread/tabwrite) and 5 oneshot drum sample playbacks (using tabread).

I know its hard to tell without running the actual patch, but does this sound like its within the belas capabilities? A block size of 64 would be fine but id rather not go below 44.1khz. I just dont want to spend £180 on something that doesn't end up having enough power to do the specific thing im buying it for, and I have a feeling ill be asking too much of it.

Any insight would be welcome!

giuliomoro · 14 Feb

So we are talking something like this but with controls?

_main.pd

5kB

This runs with about 31% CPU on Bela Mini. It will be a handful percent more on the multichannel version, but it seems you are very well within the capabilities.

Ffen · 14 Feb

giuliomoro wow yea honestly not far from this- just lots more internal sends/returns for the various audio routing (fairly inexpensive I assume) and some math stuff to translate some encoder increment/decrement encoder messages into useable number. What block size is this patch running at?

Another question- I'm planning on running this on a bela for the audio, while simultaneously running the same patch on a laptop to provide a visual UI for controlling the bela patch. Do the patches both need to be totally identical, or can I delete things like vu meters in the bela version of the patch to save CPU, and still get the 'remote control' functionality?

I do think I'm going to go ahead and get a bela, just to try the patch out on, then get a multichannel expander if the patch seems to run happily.

Ffen · 15 Feb

fen oh I will also add there is an [osc~] and 8 [expr~ tanh($v1)] in the mix too.

But I think I have decided that either way I will get a bela with multichannel anyway. If the full patch doesn't run I can pare it down, and if that's still too much it will just be a looper and drum sampler and I will buy an external mixer!

giuliomoro · 15 Feb

expr~ is always expensive because of how it's implemented and an accurate tanhf() called at audio rate is expensive. You can achieve pretty similar results with a table lookup: populate a single lookup table with a tanh and then use [tabread4~] to read through it for cheap any time you need it .

Ffen · 15 Feb

giuliomoro oh interesting! I'm using them for a post-gain soft clipping limiter on the inputs right now so they're pretty much constantly used, but I can live without them if it's the difference between being able to run it or not.

giuliomoro · 15 Feb

When doing table lookup it's just the cost of one additional tabread4~ each, so not much at all.

Ffen · 15 Feb

giuliomoro ohh that makes sense! I'll definitely look into implementing that! I'm not super clear on how I'm process my audio through it though? Do you have an example?

Oh wait I get it, its just a case of plugging the audio into the table.and getting it modified by the function out! Genius

giuliomoro · 15 Feb

something like this. The table gets populated at startup using expr~'s tanh, then the subpatch is switched off so expr~ stops consuming CPU (alternatively, you could do it once on the host and then save the array content). To read from the lookup table you need to resize your audio signal from -1 to 1 to the length of the lookup table.

main.pd

40kB

Ffen · 15 Feb

giuliomoro thanks so much for the help!