[Free Dsp] Lookahead Limiter (true peak)

[ustk]

@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

[griffinboy]

@ustk

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

[orange]

@griffinboy Is there a fix for the latency that the lookahead limiter introduces?

Delay compensation must be a static value.

[griffinboy]

@orange

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?

@Christoph-Hart ?

[orange]

@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.

[griffinboy]

@orange

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.

[ustk]

@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

[griffinboy]

@ustk

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.

[ustk]

@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;

[griffinboy]

@ustk

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.

[ustk]

@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...