On Wed, 4 Sep 2024 21:08:50 +0200 ichthyo <p...@ichthyostega.de> wrote:
Just off the top of my head... I'd say, the only sane approach would be to have a separate AnalogFilter component set aside only for rendering the EQ responses. Because, /any/ attempt at using the actual filter components while synth computations are ongoing will just lead us into a situation which is complex and difficult to understand.
On 04.09.24 23:07, Will Godfrey wrote:
This is very much along the lines I've been thinking for some time. Apart from anything else, we don't have the memory constraints that Paul had when he first implemented this in Zyn.
This solution is implemented now on my guiconnect branch. Since the EQ is the one maintaining those interpolated values, it seems adequate to maintain these transient temporary filter objects also as an implementation detail of the EQ. However, there is a twist: we certainly do not want to perform repeated memory allocations, just for generating transient filter objects. Rather, I have created an »inline storage holder« object within the implementation of EQ. This helper class FilterSnapshot cotains a chunk of uninitialised storage, which is large enough to hold an AnalogFilter object. Such an object is then "placement-constructed" into this buffer. Doing so is very fast, since it boils down just to some assignments and then the recomputation of the filter coefficients. Moreover, since I have implemented it as an nested (inner) class within EQ, the implementation can directly access the FilterParams, where the current "target values" can be retrieved. As far as I can see, all those jumping and hysterese effects are now gone, and the response curves seem to be plausible now. -- Hermann PS: I took the opportunity to switch the complete family of filter and parameter objects over to be non-copyable. This allowed me then to change a lot of SynthEngine* into SynthEngine&, which must be bound initially, can not be NULL and can never be switched or manipulated, removing lots of possible pitfalls and complexities. _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
