Re: Directly setting biquad coefficients

One way to deal with this that might eliminate issues about which parameters are the canonical parameters (and which are automatable), would be to consider the coefficient-driven biquad to be a completely new node type with a different name, and leave the current one as-is. 

The reason why? It seems weird from an API perspective to me to have coefficient parameters that are not fully automatable as AudioParams. I’m hearing some folks say there are no use cases, but others saying that automation of coefficients is useful and important.

It also seems a bit troubling to allow the automation of alternate sets of parameters (both Q/Freq and coefficients) that can be [sometimes] derived from each other. What if someone tries to automate both?

Finally, I wonder whether this entire thing is a v1 priority, although it does seem a shame to hide the actual coefficients from users.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"

On Oct 8, 2014, at 12:03 PM, Norbert Schnell <Norbert.Schnell@ircam.fr> wrote:

> Whoopee!!! Great idea (in meantime we didn’t dare asking again :-).
> 
> On 08 Oct 2014, at 17:22, Raymond Toy <rtoy@google.com> wrote:
>> Chris and I were discussing the possibility of allowing a user to set the coefficients of a biquad filter directly, as mentioned in https://github.com/WebAudio/web-audio-api/issues/323
>> 
>> This ability makes it possible to have a first-order filter, which isn't possible now. This also makes it easier to create higher-order filters from biquads where you've decomposed the filter into a set of biquads with the coefficients. No need to convert each biquad into a lowpass, bandpass, and highpass filter with appropriate frrequency and Q values.
>> 
>> We think this is a good idea, but were not sure on exactly how to expose this.
>> Should we have setCoefficients(b0,b1,b2,a1,a2) create a "custom" filter type?
>> This would preclude any kind of automation.
>> The values of frequency, Q, gain would be undefined (in some way) for this filter type.
>> Should the individual coefficients be exposed as audioparams?
>> We couldn't come up with an actual use-case where any one would want, say, a linear ramp for, say, coefficient a1
>> Some possibly interesting filtering affects might be possible.
>> Thoughts?
> 
> I clearly would vote for the second (the audio parameters).
> For many time variant filters it makes sense to update the coefficients with a more sophisticated algorithm on one rate (e.g. every few milliseconds) and add linear transitions between successive sets of coefficients in audio rate to generate smooth filters.
> 
> N.
> 
> _____________________
> N o r b e r t   S c h n e l l
> { Sound Music Movement } Interaction
> IRCAM – Centre Pompidou
>