I’m trying to read the coefficients of a IIR peak filter, this way:
filterIIR.coefficients = *juce::dsp::IIR::Coefficients::makePeakFilter(getSampleRate(), 700, 1.0f, 1.0);
float c1Value = filterIIR.coefficients.get()->getRawCoefficients()[0]; // i.e. it should be C1
C1 (i.e. first value in the returned object) can be 1 only if alphaTimesA is 0 (since its 1 + alphaTimesA). But alphaTimesA can’t be 0 with gain 1 and freq 700.
The short answer is because the coefficients are normalised.
The function you linked is called internally here and the result is passed into the Coefficients constructor, which calls asignImpl() on itself which divides all the coefficients by the a0 coefficient.
For a peak filter, a0 and b0 are the same, so the first coefficient you read back was 1.0, instead of its original, non-normalised value.
Oh I see now, miss that ctor logic inside, thanks.
Not sure about this:
for (size_t i = 0; i < Num; ++i)
if (i != a0Index)
coefficients.add (values[i] * a0Inv);
if a0 = b0, here it just “skip” the b0 valorization, but in fact it is set (i.e. I got a value, 1.04978 in this specific case). but clearQuick should set to 0, so where this value come from? at filterIIR.coefficients.get()->getRawCoefficients()[3] ?
Also, what’s the difference between a0 != NumericType() and a0 != 0.0?
Practically there’s no difference, but since NumericType could be a float or double, comparing against 0.0 could throw a warning when using float. Although, NumericType() assumes that the compiler will initialise to 0.0 which, IIRC, isn’t guarenteed. Personally I’d have done:
