You should have no problems getting it to work. Or maybe TDF2 version would be more suitable, it should be slightly faster. Either way, I’d expect CMSIS version to have better performance due to block based processing. The only advantage from not using that I can think of is that resulting code is portable.
i.e. the a coeffs have opposite signs and the a0 column of 1.0s are removed
This brings up a questions though - I’m doing block processing using the 48 that is hard coded in all the daisy setup files. This is good as @antisvin points out it should reduce overhead. However libdaisy requires all DSP functions to be single sample based. What is the reason for this? I’d like to include this stuff as part of libdaisy eventually, but I’m reluctant to move to single sample calls for this.
You obviously was going to say DaisySP rather than libDaisy. Well there are cases when per sample processing is required - typically if you DSP graph contains feedback loops. Other than that, it makes little sense as the only choice to me.
I was asking about the same thing considering ways to add SIMD NEON intrinsics and was told that ideally all DaisySP objects would contain both block and sample based processing methods. I don’t think that anyone is actively working on this. But you could try opening an issue/PR in guthub, it would likely be accepted upstream if you add an extra method similarly like how it’s done for FIR: DaisySP/Source/Filters/fir.h at master · electro-smith/DaisySP · GitHub
They’ll obviously want the same ProcessBlock function to work even if it doesn’t run on ARM so a generic implementation would also be required, you can see how it’s done in fir.h with USE_ARM_DSP / arm preprocessor variables. Not sure if they’ll want separate classes like it was done for FIR or just a few checks. Either way, it makes more sense to discuss DaisySP contributions in github rather than here.
That’s a very nice example - thank you. Is it yours? I’m just getting started in C++ world, so I think it’ll take me a while to grok the templates etc, but I will study it and see if I can create something similar for the biquads.
Here is another version of the code with pot control. This is an acoustic guitar tonestack programmed for the terrarium interface (this time it uses the petal library and terrarium.h).
Hi @Cuki79 I’ve been using the iir.h file, updated it to use df2T instead and written a generic implementation based on the one ARM uses for non M-7 cores. My intention is to make a pull request to the DaisySP github repo, using an MIT license, if you’re ok with that. Here’s the link