H e l p w i t h IIR implementation ** from sample based to buffer?

Hello fellow Jucers!
i am very new to all this…
i manged to build my first VST with Juce
(something like a 4 way crossover - with HighPass and LowPass filters setting the limits for each band-)
I have used the tick method of biquad so i guess i am using a sample by sample approach (correct?) and i end up with 98% CPU when the .dll is loaded in cubase

this is from my processBlock:

1L = (filterL4->dbGain)*(filterL4->tick(filterL2->tick(filterL3->tick((filterL1->tick(leftChannel[i];

i believe that the main reason for increased CPU in cubase is the tick

any ideas how to get through that?

I thought of using the IIR filter of juce to implement the HPF and LPF and deal with this problem
and get the results in buffers but since i am very new to all that i have no clue how to do it…

any help, ideas, or examples would be extremely appreciated!!!

You’re going to have to post more code than that. 4 biquads should consume nowhere near 98% of CPU whether or not you’re using sample or buffer based processing.

You can format code by indenting by four spaces or copy-pasting to gist.github.com and posting the link.

i have 80 biquads at the end… (4 for each band * 10 bands * 2 channels…) and then i add them all together :
leftChannel[i] = 1L+2L+3L+4L+5L+6L+7L+8L+9L+10L

Not quite sure what you’re trying to achieve there! Have you considered using bandpass filters?

So you have a 10-band 8th order crossover and are adding up all the outputs? If the filters are designed correctly you should get the input.

And we can’t tell you anything about your performance problems unless you post the code that implements the filtering.


Don’t know, if that solves the issue, but some notes:

1.) You may rely that the host will call prepareToPlay() when the sampleRate changes, hence you may move that code into prepareToPlay.

// I think because you are not setting fs = getSampleRate(), when all filters are updated, you update them at each call.
EDIT: forget that, it is at the top, sorry…

2.) You iterate the samples and process both channels inside. That makes the processor jumping between the two buffers. The caching can work much better, when you process all samples of one channel and afterwards all samples of the other channel.


You only copied the contents from one file in gist (Biquad.cpp, Biquad.h, Filter.h).

That massive if statement is unnecessary. Sample rate changes will cause a call to prepareForPlay().

I feel like this is partly a case of running before walking. Have you tested a single 8th-order filter and verified it has the correct output? After that, you can test two 8th-order filters in a 2-way crossover and verify they have a flat combined frequency response. Then you can combine your two 8th-order filters into one “band” object and test it, etc.

Well i have tested
2 bands -> performance : 22%
4 bands -> performance : 51%
7 bands -> performance : 89%
10 bands -> performance : 98%

my pluginprocessor file:

what am i doing wrong? am i not allowed to use that many filters? how else can i implement that???

Profile your code to find out what is causing problems.


As your CPU creeps up with filter count, something is wrong with how you’re calling the filtering functions, or the filtering

Am I missing something? You haven’t posted the tick method, right?

@chrisdubwise created a second thread and got it there solved:

For the records, the tick method is STK’s IIRFilter::processSampleRaw(), afaik