-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issue #3339 by not clearing filter history on control change #3343
Fix issue #3339 by not clearing filter history on control change #3343
Conversation
Do not clear the filter histories when the crossover control has changed, e.g. via automation. Add a new method CrossoverEQEffect::clearFilterHistories that's called whenever the filter histories need to be cleared, e.g. after loading a crossover EQ. It would be beneficial to also call this method when the effect is enabled again after being disabled but it seems there is no was to find out that this event has happened. One could implement it in the process method by storing the current state in a member and comparing it to the state at the time of the last process call but this is something that should be provided by the framework.
Testing this with an Automation Track. It solves the problem when I use Linear and Cubic Hermite progression but creates new glitches on Discrete progression. |
Interestingly it's only on a positive flank, when the automation jumps from a lower to a higher value, that I get a glitch. |
I think that the pops are created because the parameter changes are not smoothed at all. So instead of interpreting the incoming parameter value directly they'd need to go through a simple 1 pole low pass like the one described here: However, that might be a more general problem and is something for another issue. So I propose to merge my changes as a first improvement and perhaps add a new issue that describes the problem and that might also be used to investigate whether similar problems show up in other areas as well. |
Sounds good to me. 👍 Any guess as to why I only see this on a rising signal? I've seen pops before but have never noticed this behaviour. It could simply be that I just haven't thought about it but since the behaviour is systematic it could be that we do something wrong here. It works the same way with an LFO square wave. |
Merge? |
@zonkmachine, I'd say let's merge it. It's not perfect but already better than before. |
Will you open this new issue? Close #3339 ? |
Thanks for the merge and the creation of the new issue, @zonkmachine! |
…MMS#3343) Do not clear the filter histories when the crossover control has changed, e.g. via automation. Add a new method CrossoverEQEffect::clearFilterHistories that's called whenever the filter histories need to be cleared, e.g. after loading a crossover EQ. It would be beneficial to also call this method when the effect is enabled again after being disabled but it seems there is no was to find out that this event has happened. One could implement it in the process method by storing the current state in a member and comparing it to the state at the time of the last process call but this is something that should be provided by the framework.
Do not clear the filter histories when the crossover control has changed,
e.g. via automation.
Add a new method CrossoverEQEffect::clearFilterHistories that's called
whenever the filter histories need to be cleared, e.g. after loading a
crossover EQ. It would be beneficial to also call this method when the
effect is enabled again after being disabled but it seems there is no
was to find out that this event has happened. One could implement it in
the process method by storing the current state in a member and
comparing it to the state at the time of the last process call but this
is something that should be provided by the framework.