easyeffects
easyeffects copied to clipboard
wwmm
Non-bell filters get reset to bell filters in the equalizer when the number of equalizer bands is changed
EasyEffects Version
6.2.4
What package are you using?
Arch (easyeffects)
Distribution
Arch Linux
Describe the bug
I am on KDE Plasma (5.24.4 as of writing) but the issue existed for much longer than that ( at least since the transition to from pulseeffects to easyeffects, possibly earlier). If an equalizer band is added or removed from the equalizer any non-bell filters are changed to bell which may cause the sound to become unpleasant or at worst cause long lasting hearing damage.
Expected Behavior
All filters should retain their type regardless of how many are added or removed
Debug Log
Debug Log
Paste your log here
Additional Information
No response
All filters should retain their type regardless of how many are added or removed
That is not doable. When the number of bands is reduced we have to set the hidden bands to Off so they do not process audio. Once the number of bands is increased and the bands previously hidden are visible again we have to do something. In the past I just let them in the Off state. But users requested them to be in an active state. As tracking the last used active state is not practical and may not even make sense in many situations for now bands are set to Bell when visible again.
Honestly I do not think this problem will ever have a great solution. All approaches tried so far seem to make someone unhappy.
I think a good compromise is to have a toggle on the behavior somewhere in config files or in GUI. This way it would solve the issue for people like me who changed the number of bands and wondered why their audio sounds bad at the minor inconvenience of having to manually set the now shown bands, while default behavior can remain as is for the users that requested that new filters be active.
I think a good compromise is to have a toggle on the behavior somewhere in config files or in GUI
Maybe some toggle in the equalizer window. I will try to remember to see this in the future.
We could remove off from enum bandtype and add a bool bandenabled.
If bandenabled is set true, we set the filter type looking at bandtype. Otherwise bandtype is ignored and filter type off is set.
The downside is that we loose the full bind between bandtype key and plugin filter type, because every time we have to check first bandenabled and then, eventually, the bandtype.
The downside is that we loose the full bind between bandtype key and plugin filter type, because every time we have to check first bandenabled and then, eventually, the bandtype.
Yes. I do not think it is worth the complication this will add. If the LSP plugin we are using had a separate control for the band on/off switch it would be the way to go. But as things are right now we would have to synchronize two controls so that the one from the LSP plugin has the right value.