Check out the [poly] object.

motorcycle.zip - 7kb

inspired by @lead's mumble and gremlins

edit: updated .zip to include pip~

I'm working on a patch that automatically generates and connects many voices to a [ poly ] object. It's still a work in progress while I decide how best to get parameters into the voices.

Enjoy the prototype at your peril:

auto-poly.zip - 3kb

tong~.pd - 4kb

tong~ is a damped harmonic motion oscillator built using only 4 of the cheapest audio atoms. It treats the real part of a cpole~ filter as velocity and the imaginary part as displacement. Initial excitation is provided by a 1 sample pulse optionally scaled by velocity. The parameters of the cpole~ establish the angular velocity and decay of the system.

bang the first inlet to generate a 'tong'
send 1..127 to first inlet for different velocity hits
send list [freq, vel] to set freq per-hit
other inlets set frequency in Hz, decay halflife in ms

The left outlet is very 'clicky', with a discontinuity at the start, think of this as velocity. Useful for control.

The right outlet is softer, no discontinuities. Think of this as displacement. It still clicks at the start due to the discontinuity in the first derivative. Useful for audio.

All questions and ideas for improvements welcome!

@whale-av Thanks for those links, that's interesting stuff.

Audio can be responsible for maxing your CPU if you do daft things like massively parallel saturation with bob~s on an old raspberry pi.

You're right, pd does indeed optimise away unconnected audio atoms, so my arrays are fully connected in one big chain like this:

I'm fairly convinced my methodology is sound enough that these results will reflect how various atoms contribute to the CPU use of a patch in practice. There may be some clever atoms that deactivate if they detect zero audio, but I've not noticed any behaviour like that. There are also effects like pipelining, caching etc. I'm assuming they won't be huge factors.

I have yet to look at expr~ and vexpr~, they'll take a bit more work to analyse.

I've been roughly measuring the performance of pd's audio atoms by creating large arrays of them in a subpatch and monitoring overall CPU usage. I'll post the measurement patch if there's demand.

bob~ 168.00
vline~ 80.00
bonk~ 50.00
sigmund~ 43.00
line~ 21.50
pow~ 19.25
mtof~ 14.50
exp~ 10.50
vcf~ 8.25
log~ 7.00
framp~ 7.00
sqrt~ 5.50
q8_sqrt~ 5.50
rsqrt~ 5.25
q8_rsqrt~ 5.25
rfft~ 5.00
tabread4~ 5.00
osc~ 3.50
cos~ 3.50
bp~ 3.50
tabread~ 2.50
rpole~ 2.25
lop~ 2.22
phasor~ 2.00
tabosc4~ 2.00
/~ 1.67
ftom~ 1.63
rzero~ 1.25
abs~ 1.06
clip~ 1.00
threshold~ 1.00
vsnapshot~ 1.00
tabwrite~ 0.88
hip~ 0.72
+~ 0.61
*~ 0.61
-~ 0.61
snapshot~ 0.50