compressors.lib meter issues

[Yoann-Le-Borgne]

Hi!
I'm playing a lot with components of compressors.lib and encountered issues (even managed to fix some and sent a PR) but this time I can't figure a solution.
Each *N_chan component has an embeded meter and I can't figure a way to have as many maters as I have channels.

The provided meter definition uses references to undefined variables and functions like maxGR or meter_group() (1) so I tried with a simple meter definition:
meter = _ <: attach(_,abs : ba.linear2db : vbargraph("Meter %i[unit:dB]",-96,12));
hoping that I would have Meter 1, Meter 2, etc. but I realized that locality of the variable i (as defined in compressors.lib line 218) prevents it.

I then tried explicit substitution with no luck.
After some time I decided to stop and ask here if anyone had a solution for this case.
If there is none I'm willing to work on a way to add simple separate metering for each channel. (2)

In the meantime I'm trying to add sidechain versions for each component of the *N-chan collection and will share that in a PR.

Regards,
Yoann

(1) After some search I found this issue from 2018 where those were defined
(2) without reusing definitions in the issue mentioned above that would add a significant amount of code and loss of flexibility imho

[Yoann-Le-Borgne]

Hi again!

I've worked around compressors.lib and can share that work if you are interested but except two minors changes everything else introduces backward compatiblity issues along new features.
Here is a list of what can be sent via PRs:

• hardening peak_compression_gain_mono and RMS_compression_gain_mono with boolean logic for the prePost parameter
• simplification and light refactoring of most of the functions to improve readability
• lookahead delay parameter for all compressors/limiters (breaks backward compatibility)
• sidechain versions of FFcompressor_N_chan and RMS_FFcompressor_N_chan
• metering handled outside of each function by providing dedicated outputs (breaks backward compatibility)
• merged peak_compression_gain_mono/N_chan and RMS_compression_gain_mono/N_chan into compression_gain_mono/N_chan that allows to switch from one mode to another with a single boolean parameter (breaks backward compatibility)

Here is an example of feedforward compressor with lookahead delay, sidechain compression and peak/RMS capabilities:
SC_LAD_FFcompressor_N_chan(strength,thresh,att,rel,knee,prePost,link,meter,N,sidechain,lookahead,mode) = si.bus(N*(1+(sidechain == 1))) <: par(i,N,de.fdelay(ba.sec2samp(0.02),lookahead)),compression_gain_N_chan(strength,thresh,att,rel,knee,prePost,link,N,mode) : ro.interleave(N,2) : par(i,N,_,(_<:_,_):_*_,_) : ro.interleave(2,N);
with two new parameter:

• sidechain is a boolean with 0 for using input signal for gain reduction and 1 for using an independant source for gain reduction (doubles the input number)
• lookahead is the delay (in samples) applied to the compressed signal with an arbitrary max value of 20ms
• mode is a boolean with 0 for peak compression and 1 for RMS compression

Any advices/comments?
Regards,
Yoann

[sletz]

"backward compatiblity issues" is a real problem. Do you think you could separate the PR in:

• simplification and light refactoring of most of the functions to improve readability
• from new versions (with different names) of the functions you have improved?

[Yoann-Le-Borgne]

Sure, I can do that.
For the second point, what naming convention should I use? Something along SC_LAD_originalFunction with SC for sidechain when applicable and LAD for look ahead? Uppercase or lowercase or a mix of both?
Also, should I change

// Author: Bart Brouns
// License: GPLv3

into

// Original author: Bart Brouns
// Modified by Yoann Le Borgne
// License: GPLv3

While copying/modifying/extending the documentation?

[sletz]

I would say "yes" and "yes", but I guess @magnetophon can commend also.

[magnetophon]

Thanks for your work @Yo-L-B!
A few questions:

• lookahead delay parameter for all compressors/limiters (breaks backward compatibility)

I experimented with delaying the GR once, and wasn't impressed with the results.
Have you found this functionality useful while mixing?
My tests where very long ago, so maybe I should try it again.
A real lookahead can be built using ba.slidingMin.
(Coincidentally, I have been trying to write the perfect limiter for a few years on and off. I recently started again)

• metering handled outside of each function by providing dedicated outputs (breaks backward compatibility)

Great! That seems like the best way to do it.
@sletz Since this code was broken before, maybe this fix is worth loosing backwards compatibility for?

• merged peak_compression_gain_mono/N_chan and RMS_compression_gain_mono/N_chan into compression_gain_mono/N_chan that allows to switch from one mode to another with a single boolean parameter (breaks backward compatibility)

Doesn't that double the CPU-usage?

[Yoann-Le-Borgne]

Hi @magnetophon !

I experimented with delaying the GR once, and wasn't impressed with the results. Have you found this functionality useful while mixing?

I'm not delaying the GR but the signal to which GR is applied. This anticipates sharp peaks, keeps them under control and at the same time doesn't denaturates them too much.

Doesn't that double the CPU-usage?

I haven't done performance benchmarks and I'm not at ease with c/c++ but from what I understand of Faust inner working, peak and RMS will be computed at the same time whether you use one or the other. As they differ only by abs vs ba.slidingRMS and share a vast portion of code, wouldn't/couldn't that be optimized one way or another by the compiler?

Regards,
Yoann