Native EQ IN/OUT gain sliders affect dry signals

[Hey-Holokin]

At full dry, the EQ will continue to output the equalized signal at the volume specified on the out slider, alongside the original dry audio.

System Details: Windows 10, LMMS 1.2.0 rc2

[BaraMGB]

Is this fixed by #3520?

[Hey-Holokin]

@BaraMGB I believe I discovered the issue after the fact of that pull request.

[PhysSong]

Confirmed with latest master. Input gain and output gain are applied to dry signal.
I think it is not hard to fix, @curlymorphic?

[curlymorphic]

System Details: Windows 10, LMMS 1.2.0 rc2

The pull request to fix this bug was merged on 02 may 2017, so would not have been present in the build under test.

Would someone please test this in RC3.

[PhysSong]

I changed the title because #3505 is partially fixed by #3520. However, Dry signals are still affected by IN/OUT gain sliders.

[zonkmachine]

Isn't the reason that the gain is done by letting a separate function accessing the buffer?

lmms/plugins/Eq/EqEffect.h

Line 45 in 3745bfb

inline void gain( sampleFrame * buf, const fpp_t frames, float scale, sampleFrame * peak )

https://github.com/LMMS/lmms/blob/master/plugins/Eq/EqEffect.cpp#L176
https://github.com/LMMS/lmms/blob/master/plugins/Eq/EqEffect.cpp#L272

[DomClark]

Shouldn't we handle all the dry/wet stuff in Effect, outside the call to processAudioBuffer, rather then leaving it to each individual effect to implement? The noise control on the flanger also doesn't interact properly with the dry/wet control, and these mistakes could easily be avoided while making the code a bit cleaner.

[he29-net]

Shouldn't we handle all the dry/wet stuff in Effect, outside the call to processAudioBuffer, rather then leaving it to each individual effect to implement?

How would you deal with unknown signal latency of the effect? Say you feed in a 1 kHz sine wave, the effect does something with the signal and then produces output 0.5 ms later. When you mix the dry and wet signals (which are now exactly opposite phase), I imagine they would mostly cancel each other out.

[DomClark]

How would you deal with unknown signal latency of the effect?

Make it known. virtual f_cnt_t latency(); 😉

If anything, latency compensation for dry/wet is a reason in favour of, not against, handling this in Effect. Surely you wouldn't want to repeat the code for that in every effect with non-zero latency? We'll need a single piece of code that can handle different latencies anyway for the various third-party plugin APIs we support.