[Limiter] There is something wrong with `Gain` display

[LebedevRI]

EasyEffects Version

8.2.4

What package are you using?

Other (specify below)

Distribution

Debian GNU/Linux forky/sid

Describe the bug

Audio is playing, and in effect's native window, the applied Gain is 0,
yet in EE, Gain is stuck displaying some slight negative gain,
both textually, and graphically.

Expected Behavior

No response

Debug Log

No response

Additional Information

No response

[wwmm]

Do you mean the limiter gain level meter? It seems fine to me after forcing a negative threshold low enough to make the limiter to compress the signal. But have in mind the level displayed by easyeffects is not being updated at the same pace the one from LSP. EasyEffects meters update frequency are influenced by the level meter settings in the audio section of easyeffects preferences window.

[LebedevRI]

Do you mean the limiter gain level meter?

Yes, the one displayed to the left of Sidechain.

It seems fine to me after forcing a negative threshold low enough to make the limiter to compress the signal.

Here's a repro on my side: set threshold to -6.
Start playing some reasonable audio.
Change input gain for the effect to +36dB.
Limiting is happening.
Now change input gain for the effect to -36dB.
No limiting is happening, but the displayed Gain is stuck at ~-30.

But have in mind the level displayed by easyeffects is not being updated at the same pace the one from LSP. EasyEffects meters update frequency are influenced by the level meter settings in the audio section of easyeffects preferences window.

[wwmm]

Here's a repro on my side: set threshold to -6.
Start playing some reasonable audio.
Change input gain for the effect to +36dB.
Limiting is happening.
Now change input gain for the effect to -36dB.
No limiting is happening, but the displayed Gain is stuck at ~-30.

This made the bug happen here too. There was a flaw in the level meter code. As it may request QML several draws per second I tried to optimize it by avoiding redraws for values that were not "different enough" from the previous one. But depending on the situation it could get stuck in the same value.

I've updated our master branch with some changes. It seems fine now. Or at least the procedure above is not enough for me to see it getting stuck anymore.

[LebedevRI]

@wwmm thank you! I wonder if there are other indicators that use different base primitive that are also affected by this.

High-level showerthought: i wonder if such indicators should be using math model of a spring.
I did not check if they already do, or if it makes sense, though.

[wwmm]

I wonder if there are other indicators that use different base primitive that are also affected by this.

The horizontal meters like the ones used by the autogain and the bass enhancer plugins. I've applied the same fix to them although I did not see the same issue happening there.

High-level showerthought: i wonder if such indicators should be using math model of a spring.
I did not check if they already do, or if it makes sense, though.

I am not sure if a spring model is fine for this. At least not the way we physicists model springs 😄 . What I tried was doing the same Calf Studio meters do. The meters show the peak of the last "N seconds". The amount of seconds can be configured in EE preferences window. If the a higher values comes it updates immediately. Calf does that in a more fluid and visually pleasant way but what we have now is better than it used to be.

There is definitely room for improvement. But I am kinda out of creativity. And as the level meters can be updated quite often depending on the selected fps performance is something that should be kept in mind in whatever it is done to improve them.

In case anyone reading this is curious these are the level meters files

https://github.com/wwmm/easyeffects/blob/master/src/contents/ui/EeAudioLevel.qml
https://github.com/wwmm/easyeffects/blob/master/src/contents/ui/EeProgressBar.qml