Thanks for the replies, Dan and Roy. A first order filter node with AudioParam inputs seems a likely future addition AFAIK.
Even with that though, having a way to apply a custom biquad without needing to decompose into multiple textbook filters is useful I think. And I agree that implementing this with AudioParams seems unnecessary and risky wrt stability. So I think the IIRFilterNode will still be useful as a basic building block for authors (and that is the kind of node that Web Audio should be providing). The discussion re extending BiquadFilterNode for this has passed but there is an elegance in the generality of IIRFilterNode. Daniel Minor writes: > In this case, my plan > was to import the blink IIRFilter as utility code as we've done in the > past, so I don't think supporting the IIRFilterNode will cost us much time > or effort and keeps us compatible with the spec. I wanted to think this through now because, once this is shipped, we can't take it back, so the cost is ongoing. When Gecko has used Blink or Webkit's implementation in the past, the WG has sometimes used this to argue that quirks in multiple existing implementations should be maintained even if not desirable. Sometimes we just live with the quirks. Other times the nodes have been deprecated and replaced, but we still need to continue to support the old nodes for backward compatibility. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
