Peak Controller Attack/Decay isn't a smooth curve

[ExperiBass]

System Information

EndeavourOS

LMMS Version(s)

12632e6b

Most Recent Working Version

No response

Bug Summary

This is the issue encountered in #1281 and #2534, I'm avoiding necroing them. As Unfa stated, the Atk/Dcy knobs seem to act more like buttons. Turning them both to 100% removes the clicking, at the cost of damping the audio being controlled. It's more noticable when the audio being used to control the controller is chaotic.
A reproducible project is attached.

Expected Behaviour

The knobs should have an effect at all values.

Steps To Reproduce

1. Load in two audio tracks; one to control the peak controller, and one to be controlled
2. put the peak controller on the furst track
3. bind the peak controller to the second tracks volume

Logs

No response

Screenshots / Minimum Reproducible Project

broken-peak-controller.zip

Please search the issue tracker for existing bug reports before submitting your own.

• [X] I have searched all existing issues and confirmed that this is not a duplicate.

[michaelgregorius]

Visual debugging

If I understand correctly what ultimately controls the volume levels is computed in PeakController::updateValueBuffer where the member m_valueBuffer of the parent class Controller is updated.

For debugging purposes the values of the buffer should be dumped into a raw audio file that can be opened and inspected with an audio editor, e.g. Audacity. I assume that it will look very crude and potentially with high frequency changes.

Does anybody know if there already exists a facility in LMMS for debugging purposes like these?

Observations in the code

The following things caught my eye when checking the code:

• The RMS value of the side chain signal is only computed once per whole frame in PeakControllerEffect::processAudioBuffer. This means that the reaction to changes in the audio signal is very slow, i.e. the "direction" can only change once per frame. Another consequence is that the result will be different if the number of frames is changed or differs for some reason. The result of the method is an updated value of m_lastSample which is evaluated in PeakController::updateValueBuffer.
• It's not really clear to me if PeakController::updateValueBuffer is called continuously because it seems to be called in the constructor of Controller (so only once), in float Controller::value( int offset ) and Controller::valueBuffer. This whole design seems quite unreliable. If updateValueBuffer is not called continuously then it wouldn't be a surprise that this leads to dropouts.

The "ideal" fix

An "ideal" fix for all these problems would be to implement flexible routing and sidechaining as a first class citizen in LMMS. See for example how it is done in Bitwig where using sidechain effects is straight forward and a breeze. If an effect has a sidechain input it will offer you a drop down list with all potential places in the signal chain/mixer that might be interesting to insert. This would obviously be a large undertaking though.

[michaelgregorius]

The peak controller definitively generates a broken and distorted signal. Here's how it looks for the attached project (click for full size):

And here the full file with the debug output: PeakControllerSignal.zip

Edit: better picture of the signal.