I’m wondering if for Audulus 4, we could build filters without needing to think about how they are discretized?
So the filters would be built with integrators instead of unit delays. Could still have delays of course 
I think this would involve pretty aggressive supersampling, or actually doing some sort of solve every sample.
Heckman’s article was very interesting. and he makes a good point, at least as far as linear equations are concerned. The biggest issue I see with the more general non-linear case is that, although I’m sure methods exist to solve the equations iteratively, I would be concerned that it might be difficult to do so in real time with a manageable CPU load. I would think that some mechanism to selectively provide aggressive oversampling would allow us to use simpler delay based models without introducing objectionable aliasing or other artifacts. After all how close do we really need to get?
I was thinking of supersampling nodes within a feedback loop only (at least 4x, maybe more). There’s no need to supersample feed-forward nodes (supersampling could still be done within a single node, like a distortion).
Of course the feedback loops with unit delays are evaluated single-sample, which adds to the overhead. Filters could get rather expensive, but that might be the best we can do.
I think that makes the small case for keeping an optomized filter node for instances where the exact character of the resonant filter is less important.
Some interesting replies to my questions over here: https://www.kvraudio.com/forum/viewtopic.php?f=33&t=516916
It certainly sounds like it’s possible, at least in theory, although it would appear to be fairly computationally expensive. Still it might be worth investigating. As @robertsyrett points out, for the majority of Audulus users, a few well chosen pre-built filter nodes would probably be sufficient. I will typically use the low-pass or high pass node when I need a filter with moderate slope and the bi-quad for general purpose filtering where I’m not looking to emulate a ladder or SVF. iT would be nice if the filter nodes were a little more user friendly (i.e. cutoff frequency rather than alpha and maybe a set of bi-quad based nodes rather than the raw bi-quad implementation). So long as efficiency doesn’t suffer I think it’s fine to have the more complex designs included in the module library, but I wonder if you might not have more opportunity for optimization if the more common types (ladder, SVF, APF etc.) were nodes rather than modules. Even with an engineering background, I find filter construction to be one of the more challenging aspects of programming in Audulus and I think many users would be happy to trade the ability to modify a filter design for a few more CPU cycles. I’m not suggesting that you eliminate the lower level nodes, but consider a larger library of prebuilt filter types.
Arrgh! Matrix math again. You think you’re safe and then this. I guess I should have saved my textbooks. At some point it all becomes just so much techno-babble. I vaguely remember solving matrices, but I guess I didn’t pay enough attention that day. In my defense, computers were coal fired when I was studying this and numerical methods were in their infancy. Still, it’s frustrating to read a post and realize that though it makes a sort of sense, actually implementing it would require re-learning a lot better left forgotten. Kind of like Zavalishin’s paper.
Haha!
Yeah, it’s a bit tricky, but I understand it in general terms. He’s describing the standard method for solving systems of nonlinear equations. The tricky part is doing as much as you can of the linear part ahead of time so the nonlinear solve you have to do while processing audio is minimal.
It seems like something that will take me a month or more to implement, so it’s best kept for after 4.0. After all, this is icing on the cake, as folks can build filters right now in 3.x.
Actually I’m pretty pleased with the filters that have been implemented in 3.x. The last round of optimizations for the z-1 node and processing in general really made a big difference. I’m assuming the newer engine will be in the next version of the AU.
I have vague recollections of matrix math from the BC Calculus AP course I took in high school and had pretty much the same reaction. Although I’m glad that @taylor somehow found a forum populated with people who could provide an effective answer.
I know that @stschoen was basically reiterating my point, but I think he states it most eloquently when he says ,
I definitely enjoy challenging myself with the module construction, so I’m pretty happy that there is a z-1 node and looking forward to trying the biquad implementation of the z-2 node that @Kah described. But most of the time, if the filter isn’t the main point of the patch, the dsp and effect nodes are perfectly suitable.
It definitely would be! I think z-1 avoidance would actually be having your cake and eating it too, as it would provide the amenity of using block diagrams to recreate VA designs with the optimizations of a specifically coded plug-in. 
I agree that providing some pre-built filters would be best for most users, and that would be a good thing to have!
On a language design level though, I think it would be cool if Audulus could express all sorts of filters, with maximal elegance.