Hey folks, I’m getting to the point with a dual mono limiter project (that is a small part of a bigger synth project) that I can start getting some beta testers! And for all the noobs out there, if you’re interested in learning how I wrote this, the bigger synth project will be documented in a course that teaches C++, Juce and Audio programming from scratch with zero prior programming experience required.
If you’re interested in checking out the limiter or want to learn how to write it, let me know via the link in the description here:
it’s a peak limiter and just kinda makes sure stuff never goes over 0 dbFS. Apple’s own AUPeakLimiter has an attack knob, so I’m not really sure it’s wrong for a limiter to have an attack knob.
In the AUPeakLimiter the Attack Time is working as a lookahead time, you can hear this by quickly changing the attack time, it creates some glitches even with no gain reduction. That’s the delay line.
I’d say as long as it really never goes over 0dBFS, you can call it a limiter. Implementing real lookahead limiting is not trivial. Most people on the internet think it’s just delaying the signal where gain reduction is applied without delaying the sidechain signal. However, in that way transients are clearly missed. In fact, it comes down to delaying both, with an additional time-reverse filtering of the gain reduction. So basically the attack time in AUPeakLimiter is more of a time-reverse release time
Just one for Ambisonics: https://git.iem.at/audioplugins/IEMPluginSuite/tree/master/OmniCompressor
The compressor class (in the resources directory in the repository) uses a peak level detector, so with Attack set to 0 it acts as a limiter. The class writes the gain reduction for each sample to an AudioBuffer (or float array) which is then time-reverse filtered by the LookAheadGainReduction class.
I am wondering, how that would be the case:
The measuring finds the transient being over the threshold, you go back in time thanks to your delay, and the attack phase ends exactly at the found sample applying the necessary reduction.
The only thing you have to make sure, that you adapt the reduction, since the next exceeding sample will most likely exceed the value even more…
Yes that’s how it’s done.
However, most algorithms or suggestions to implement lookahead I have seen on the internet don’t line up that attack phase. They just delay the signal… So in that case, the gain-reduction will set in too early, and the transient will come in while the limiter is already in release mode.
That’s why you have to do that time-reverse filtering, which isn’t exactly a filter, you can rather see it as a one sided filter, it basically just checks whether a gain-ramp has to be applied or not. My LookAheadGainReduction class exactly does this.
What you see is that the signal is attenuated shortly (5ms, linear) before the impulse comes in. Right after the impulse you see the release curve (exponential).
you can see it ramping down before the spike, and ramping back up after it.
@danielrudrich Why exactly did you hijack this thread? You don’t even know how I went about implementing the gain reduction or look-ahead. So why even come at me with the “I bet you did what everyone else on the internet thinks you need to do” vibe?
I did not mean to offend you in any way or criticize your implementation. If I communicated with that vibe, I am very sorry! I guess I should have posted this to the other thread here on the forum with the discussion about lookaheads and not use this one. Just thought this might be interesting for everyone who’d like to get some information about this topic.
