As the value of the Q parameter in each of the three middle bands in the Curve device increases, the bandwidth of the EQ points increase as well. This is wrong. Q is inversely proportional to bandwidth. Compare Q behaviour in Curve with Q behaviour in Graphic-EQ (they behave in opposite ways), which has a correct implementation, or to any other professional EQ that has a Q parameter.
Comments (11)
Ouch! I'm totally stumped why I didn't notice that?! (this explains why my formant filters didn't work at all)
The fastest solution I can think of, would just display the inverse value but the automation will have to be inverted too ... which isn't possible because the automation can only be linear.
Maybe another compatibility switch?
Thanks for reporting!
Given all the problems that Curve has (wrong Q, NaN values on parameter reset, minimally developed interface, lack of labels, etc.) it seems that it was put together very quickly and with little testing. These solutions/patches seem like band-aids on a hasty design and, to be honest, a compatibility switch between right and wrong behaviour feels a bit absurd. If the problems are corrected in the code and a well defined mapping can be established between current values (and by extension automations) and corrected ones, maybe projects using Curve could be automatically corrected by a script.
I agree that the situation is rather unsatisfying. The automation cannot be fixed at the moment I guess. A linear increase of the bandwidth (1/Q) would have to yield a curve after remapping. That's currently unsupported.
The NaN-issue isn't specific to Curve - the underlying problem is more generic.
I don't want that switch either - it's a plan C - plans A and B are still missing :)
There will be a major rework of the audio engine soon where I'll address some of the general value-range issues.
Bumping this. When doing sound design and comparing the results of different ways to EQ and filter sound to find the best one for a particular situation, it would be great that Q values would work the same everywhere. Right now Curve's Q goes from 0,01 (narrow) to 10 (wide), Graphical EQ goes from 100% (narrow) to 0% (wide). Different ranges and opposite directions. Also, the Bandwith parameter of the Slope and Parametric EQ pedals, which is equivalent to Q, could also be unified with them. Slope's is bipolar (-500 to 0 to 500, no units) and Parametric EQ's is unipolar from 0% to 100%. It would be great if a standard would be applied everywhere. Usually a high Q value means a narrow band and a low Q value a wide band.
References:
https://en.wikipedia.org/wiki/Q_factor
https://en.wikipedia.org/wiki/Band-pass_filter
I'm finding several problems with how Curve is implemented. Another one is that the slopes of the filters (HPF on the left and LPF on the right) seem to be straight. Usually filter slopes have a smooth decay that looks like a parabola. This is so because a filter attenuates by octave and frequency isn't a linear magnitude. The result of this implementation is that the filter doesn't attenuate frequencies beyond the cutoff point as soon as it should and too much of them pass through. I think I can even hear this in that the filter doesn't sound as "clean" as it should.
Maybe I'm getting you wrong, but Curve looks exactly as expected to me: https://en.wikipedia.org/wiki/Low-pass_filter#/media/File:Butterworth_response.svg
Did you confuse axis scales? (linear vs. log)
Sorry, yes, you're right. Ignore this comment. I was comparing the filters in Curve to those of some other EQ plugins that seem to have a curved slope, not a straight one. Perhaps they are using a different Q factor that changes the initial slope and this confused me. I'll delete the above because it's not relevant.
Wouldn't delete it - maybe others find that discussion insightful.
OK.
Yes, it's only the Q value. That's why I didn't change the topic title or text and wanted to actually delete this filters comment because it's wrong and a different thing.