Hi!
I do agree that we need a very good look at this now. How many filters do we want in the end? I was thinking that maybe these should be called LPF12, HPF12 and so on (second order so 12db/oct) and later we might also have LPF24 (24 db) and maybe even LPFMoog, LPF303 or LPFPHLin (phase linear) or whatever.
I had originally thought that LPF, HPF, BPF, and BRF should be expandable without breaking the api. For LPF (or whatever it should be called), we have so far .freq (cutoff) .Q (resonance) This is a 2nd order butterworth. In the future, if we want our 24db/oct filter, it might be cool to chuck 4 to: .order (filter order) Furthermore, there could be something to control the type: .type (butter, cheb1, cheb2, ellip, more) (Of course, it's worth remembering that we can already construct any of these higher order filter using building blocks such as BiQuad's and PoleZero's.) Now, I am not sure if this is the right factoring. But organizing it by function (low, high, etc.) seems slightly better than a monolithic FlexFilter type... Also, given this strategy, we hopefully should be able to add more filter types without inflating the namespace. Thoughts? If we want to go all out, someone could implement a chuck library for filter design, like the lovely matlab functions such as .buttord (great name; specs in, minimum butterworth order required out) as well as analog prototyping functions and bilinear transform?? It's probably pointless to try to duplicate matlab in any significant way, but the filter package is really fun and can be good for teaching in an audio driven manner. That would give us many different ways to approach filter and friends. now I am talking crazy... must be dreaming... zzz