this is how costly the filter in my synth is right now.

these are nanoseconds per sample measurements on a single 2.2 GHz i7 core, with 5 keys held down.

the baseline measurement just has 2 oscillators running per voice, with the filter disabled.

full unison means playing 8 voices per key held down, so 40 in total for 5 keys, meaning 80 oscillators and 40 filters running simultaneously.

K-LUT is a lookup table that saves time by avoiding expensive calls to tanf() and exp2f(). you can see how using the K-LUT cuts the total computation time in half in unison mode.

for reference, the synth takes about 160 ns per sample when it's idle.

where it says "with clamping" is particularly revealing though. all i'm doing there is limiting a single number in the computation to a maximum value to avoid a buffer overflow in the K-LUT.

as you can see, that alone causes a 34% increase in computation time. why? because it causes branching. a check has to be performed.

if there was dedicated hardware for clamping like you might find on a DSP or a GPU, that operation would have virtually no cost.

there's one "dumb" trick i have up my sleeve for saving a lot of computation time: routing the oscillators to a submix per key in unison mode, and then running a single filter on that submix. that would cut down on the number of filters i'd need to compute.

now, the good thing about it is that even with 40 voices, 6829 ns is pretty far away from 20833 ns - the theoretical maximum time i can spend on computing a single output sample at 48 kHz. so i'm using 1/3 of the capacity of a 2.2 GHz i7 core. in theory, this could just barely run if the CPU was clocked at 733 MHz.

the target CPU is a 550 MHz ARM processor though, so i need more headroom.

@lore -O3 fuck it.

@AmpBenzScientist this is already compiled with optimisation enabled. it's can't perform magic.