Once again, great stuff @linclelinkpart5 - thanks for the PR!

I wonder if we should allow for alternatives to the BiQuad filter to be used too? Then again, we might be better off waiting until this is requested, at which point we can maybe add a Filter trait or something along these lines. I'm happy to merge this as is in the meantime.

Before we merge, could you update the action in .github/workflow to add a step for auto-publishing the dasp_filter crate? It makes it a bit easier for contributors to get new versions published, as we just have to merge a PR that changes the version.

Edit: Also if you could update the CHANGELOG that would be very helpful.

@mitchmindtree Certainly! I'll go ahead and make the change to .github/workflow and update CHANGELOG. I'm assuming I can add the changes to the "Unreleased" section?

As for the general concept of filtering, I need to do a bit more research to see what other kinds of useful types of digital filters there are. As far as I was able to tell, using biquads was the magic ticket: they're flexible enough to do single pole (or what I guess would be called "uniquad", but I've never come across that term) filters, and any filters of higher orders can be represented as a series of biquad filters. In fact, it's recommended!

A feature that I'd love to tackle once this lands in master would be to allow nicer constructors for the Coefficients struct. For instance, a constructor that given the correct args, will produce the coefficients for a highpass/lowpass/shelf/etc filter. All of these types can be represented in the biquad form.

Are there any updates on this? Looks good 👀