[Free Dsp] Lookahead Limiter (true peak)
-
@griffinboy Cool stuffs!
But I never fully understood the meaning of true peak in the context of a dynamic effect.
The minimal attack time here is 1ms. So this means during this time the signal could reach any value, right? So why true peak if this exceeding part can't be cut? An I mixing things in my head?Can't help pressing F5 in the forum...
-
Haha it took me a long time to understand.
True peak is needed because the waveform later down the line (when converted to analog) can have peaks inbetween the digital samples, that are higher than those found in the samples. True peak detection uses oversampling or interpolation to predict the in-between peaks. In a limiter, this means the compressor can detect and reduce peaks that might cause distortion or clip after converted to analog, even if the digital samples look safe. True Peak causes the limiter to create a different gain reduction response, to catch these invisible peaks, which does affect the sound. Some people don't like the sound that this imposes.
As for lookahead, we use latency to give the limiter a head start to begin reducing the gain before a transient arrives.
We need to do this because, in a limiter, we smooth the gain reduction, to avoid distortion that we'd get if we yanked the signal down hard. But this smoothing adds extra time for the limiter to reach full reduction after detecting a transient , so we have to start reducing gain before the transient arrives.Don't be fooled by attack time here... In this design, when you add more attack time, we also add more lookahead, so we still end up grabbing the peaks correctly (peaks don't escape the attack), but rather the smoothing curve is changed during the attack phase, which will affect the groove.
-
This post is deleted! -
@griffinboy Oh I get it now! I understand how true peak is working and the signal in-between sample can reach different values once upsampled or converted back to analog.
Those peaks are then read to set the appropriate reduction, it makes sense. But then only in a lookahead algorithm, right? Otherwise they'll just pass through...
So it's simple in the end, it's just my mind trying to make everything more complex, the story of my life
-
well yes, you're only meant to upsample the detection signal not the real signal (I think? But I may be wrong actually). But I haven't tried using hise oversampling in c++ yet so I was lazy and just said to wrap the whole node in oversampling, which is bad for performance, but I'll look at doing it properly at somepoint lol. It was only whipped up in a day to help another user
-
@griffinboy Is there a fix for the latency that the lookahead limiter introduces?
Delay compensation must be a static value.
-
Good point. I'm not sure how hise measures this. Because there is a function for it, but idk if it will count custom nodes, or whether I have to do something in my nodes for this?
-
@griffinboy Normally, a declaration is made with using
Engine.setLatencySamples()so that the DAW knows how much is the the latency of the plugin on init.You measure the latency produced by the plugin empirically and use that value. And this value is a couple of samples normally. But the lookahead limiter also changes according to the latency attack value, and the latency is high, right? The stock limiter in Hise is like this too.
-
Ah I get your point! Indeed. Perhaps I should've released this with a fixed attack - I'm not sure anyone really needs to change it all that much.
It's fixed in many limiter plugins, and software like pro-l uses the attack parameter for a different purpose anyway.
I'm not sure there's an easy way to make sure the latency compensation is right with what I released. Thanks for bringing it up.
I guess the safest way at the moment would be to assume max latency, or leave the attack fixed. I've included a warning in my original post now.
I wonder how other plugins solve this. This is essentially an issue of variable lookahead time.
-
@griffinboy said in [Free Dsp] Lookahead Limiter (true peak):
well yes, you're only meant to upsample the detection signal not the real signal
If so, then I think the detection signal will be delayed in regards to the real signal because of the oversampling. Resulting in compression not applied at the exact moment (probably a few samples later) but I might be wrong.
What I know is that in the plugin I am actually releasing, I had to compensate some branched signal for the ones that are using oversampling, otherwise they do not arrive in phase at the end of the chain. The issue might be less problematic in a compressor since you don't blend the two signals, but...
@orange is right, this is how one would set the latency, emprirical measures and report with that function.
A static latency is better, but I still change mine in regards with the OS factor which does not happen at a "tweak the knobs" level. So for an attack knob, it should be fixed IMHO -
It wouldn't be hard to map the oversampled reduction to the lower sample rate original signal. I'll probably revisit this at somepoint and do it.
-
@griffinboy said in [Free Dsp] Lookahead Limiter (true peak):
I wonder how other plugins solve this. This is essentially an issue of variable lookahead time.
probably just something like
MAX_LOOKAHEAD = 48000; Engine.setLatencySamples(MAX_LOOKAHEAD); delayCompensation = MAX_LOOKAHEAD - attackTime; -
hmm maybe I should ask for Hise support for variable host latency.
But I think this subject is fiddly enough, Christoph has already done plenty of work trying to get latency to be consistent in the hosts. -
@griffinboy For what I understand, it's not Hise to support latency, be it variable or not. Hise just reports what you want, so if you want it to be variable, technically, you should be able to do it.
But the DAW might not like it... It doesn't seem to be something "normal" to report a continuously changing value, but I can't refer to anything else than my own perfectible thoughts...
