Understanding lookahead

[SMS]

I think I get the idea, but why is there a control for the amount of lookahead in a limiter? I've always assumed it looks ahead so it knows when it's going to need to react but it still will react only when it's needed, in other words, the lookahead doesn't change when it reacts, just tells it what it's going to have to do to when the time comes. Why not just set it to the maximum?

Thanks

Bill

[Robert Randolph]

I think I get the idea, but why is there a control for the amount of lookahead in a limiter? I've always assumed it looks ahead so it knows when it's going to need to react but it still will react only when it's needed, in other words, the lookahead doesn't change when it reacts, just tells it what it's going to have to do to when the time comes. Why not just set it to the maximum?

Thanks

Bill

You understand the use.

The reason why you may not set the maximum is that it will delay ALL signals ending up going through that bus. This means that any realtime monitoring is delayed, moving controls (say a fader) is delayed, realtime automation movements are delayed etc...

So if none of that matters to you, then the only exception now would be that you're going for a specific sound where limiting the lookahead is a critical part.

[SMS]

Thanks for the reply. Next question is then, how to determine how much lookahead is needed and what determines when I would need more or get away with less?

[magicd]

The MW Limiter shares many functions of the Waves L1 Ultramaximizer. To the best of my knowledge the L1 has a fixed lookahead of 20 ms. We thought we'd add a bit of flexibility with the MW Limiter and make the lookahead variable up to 20 ms.

I personally always set the lookahead to maximum. I use the MW Limiter as the last plug-in in my mix chain and I try to keep it's gain reduction to no more than 4 dB. I'm using the limiter to give me "gentle" insurance that my output doesn't peak.

I think the main reason you'd set the lookahead lower would be if you were monitoring through the plug-in in real time and you needed to reduce latency. Lowering lookahead would also mean a more aggressive response when the limiter was kicked in.

Dave

[Phil O]

Dave, if you're still watching this thread there's something that's always bothered me about lookahead plugins. Why (for playback) should a lookahead plugin cause any delay? DP doesn't need to look at a soundbite in real time. Does it? I would think it can look all the way to the end of the file (if need be) before the playback even starts. For example, lets say you want 20 ms lookahead. Why can't the plugin just look at the data that's in the sound file 20 ms after the current time. Does that make sense? So what's really going on?

(a very confused) Phil

[stubbsonic]

It looks like there is a misunderstanding here.

Lookahead could be described as side chaining with an earlier copy of the track.

Say you you are compressing a snare track. The snare will break the threshold and the compressor will reduce the gain. Now say you want it to start reducing the gain before the snare ACTUALLY breaks the threshold. You set the look-ahead to 5 ms. The compressor will begin to reduce gain 5 ms before the snare actually breaks the threshold. This is similar to making a copy of the snare track, slipping it 5 ms early and using that early copy as a side-chain input.

If I understand it correctly, look-aheads are factored into the latency compensation, so as the playback is buffering it is working out how much to delay all other tracks to keep them in sync.

If you are setting lookaheads to maximum, you are causing the compressors to operate based on that much time before the transients-- and you should be hearing this effect. You should rather adjust the lookahead as carefully as you adjust the threshold & ratio.

You can use the combined attack time and lookahead (along with release) to give the compressor quite a bit of flavor & texture.

[Robert Randolph]

Dave, if you're still watching this thread there's something that's always bothered me about lookahead plugins. Why (for playback) should a lookahead plugin cause any delay? DP doesn't need to look at a soundbite in real time. Does it? I would think it can look all the way to the end of the file (if need be) before the playback even starts. For example, lets say you want 20 ms lookahead. Why can't the plugin just look at the data that's in the sound file 20 ms after the current time. Does that make sense? So what's really going on?

(a very confused) Phil

Not every plugin goes on a channel that is connected to a single disk-based audio stream.

What if it is on an aux? The second plugin in the chain? A softsynth? Lots and lots of examples...

[Phil O]

Not every plugin goes on a channel that is connected to a single disk-based audio stream.

What if it is on an aux? The second plugin in the chain? A softsynth? Lots and lots of examples...

Good point, but the same can be said for latency compensation, right? How about this - do plugins that have lookahead capability report said lookahead to the latency compensation mechanism? Wouldn't that be the simplest way to handle this? Or am I totally missing something fundamental here?

Phil

[Phil O]

Well I answered my own question. Two identical tracks (with one inverted) null, right? When a MW Limiter is placed on one track (with its lookahead set to a non-zero value) it nulls with Automatic Plug-in Latency Compensation turned on, but does not null with compensation turned off. So the MW Limiter must report the lookahead to the compensation engine. I guess the delay introduced by lookahead is only an issue in situations where latency compensation isn't applicable. I guess Magic Dave already said that, but I didn't fully understand what he was saying at the time. Thanks, Robert, for pointing me in that direction.

I also found this in the Getting Started Guide:

The amount of the delay depends on the plug- in, and the delay is usually unavoidable, due to the nature of the plug-in itself. For example, a look-ahead peak limiter must delay the signal by the amount of the look-ahead in order to do its job (usually several milliseconds).

To the OP:

I think I get the idea, but why is there a control for the amount of lookahead in a limiter? ...Why not just set it to the maximum?

I think Dave's answer is the best (no big surprise there ).

I think the main reason you'd set the lookahead lower would be if you were monitoring through the plug-in in real time and you needed to reduce latency. Lowering lookahead would also mean a more aggressive response when the limiter was kicked in.

For situations where Latency Compensation is doing it's thing and you're not looking for that "more aggressive" response, it looks like setting it to maximum makes sense.

Phil

[stubbsonic]

I'm going to dig in my heals, a little.

There are perhaps two separate concerns-- (1) the sound & behavior of the compressor/limiter, and (2) the need to manage latency for realtime monitoring for tracking. If we dispense with the second-- because we are mixing and not tracking-- then we can focus our attention on what lookahead does, sonically.

There are reasons why you might like to have the compressor behave in a "traditional" fashion. I.e., part of the transient is preserved as it approaches the threshold, and as the attack time transpires. This will give you a familiar compression sound on percussion tracks for example, or hard-strum guitars, etc.

If you set the lookahead to 5ms and set the attack time to 2 ms, you are essentially "carving out" the transient. The compressor starts reducing gain 5ms before the threshold is broken, and is at full ratio 3ms before the threshold is broken (rather than "on it's way to full ratio" during the transient). You also have to consider the release portion as well. When the signal then drops below threshold, the lookahead will cause the gain to come up BEFORE the signal goes below threshold. This is probably a hair-splitting distinction, but with very fast release time is, you might hear something slightly different about the tails of percussive hits.

Obviously, we're not talking about huge amounts of time. If we were, for example, a lookahead of 2000ms would cause the compressor to behave in a way that was unrelated to the source material. Because a lookahead is typically in very small increments, you can be adjusting the sounds a bit like an envelope generator in some situations.

[Phil O]

Thank you, Jon. It's starting to become clearer now. I missed your point in your first post. Please do continue to dig your heels in.

[terrybritton]

That was an excellent illustration, Jon!
I had never thought of it that way myself, as having transient shaping capabilities. That point just slipped past me somehow!

Terry

[bayswater]

Phil, I think is still something to your original point.

Aside from live input, there is nothing going on in DP that can't be determined in advance of playback, and if you have a little silence at the start of a sequence, it can be determined well in advance. In that situation there is no need for look ahead to increase latency if the code has been written to deal with it. We already have pre-gen which covers similar ground.

[Robert Randolph]

Phil, I think is still something to your original point.

Aside from live input, there is nothing going on in DP that can't be determined in advance of playback, and if you have a little silence at the start of a sequence, it can be determined well in advance. In that situation there is no need for look ahead to increase latency if the code has been written to deal with it. We already have pre-gen which covers similar ground.

There's only 1 scenario where it's useful though: if you have a single track with 1 plug-in that's being fed straight from disk streamed audio.

Now if you add another plug-in, you have to recalculate the entire look-ahead for every single parameter change (this is why having a GUI open turns off pre-gen).

If you are being fed by multiple tracks (like an Aux), then you have to recalculate every track for any change to every track (pre-gen turned off here too!).

If you have any VI's, it's not possible on any pathway including that VI

If you have any live audio input, you can't look ahead. (hardware inserts for instance)

Etc... there's more examples.

Despite all of these limitations, the proposed solution simply uses extra CPU and memory to avoid a problem that doesn't really exist. If you simply use one of the other delay compensation methods there's none of these limitations nor is there extra cpu/memory overhead.

One of the more common delay compensation methods is to start playing the delayed track early by the amount of delay compensation needed. This is basically the method being suggested, except all changes to the track are delayed by that amount and it doesn't solve issues with delay compensation on non-track busses.

[bayswater]

Now if you add another plug-in, you have to recalculate the entire look-ahead for every single parameter change (this is why having a GUI open turns off pre-gen).

Which has to happen with latency compensation for every change in plugins anyway.

If you are being fed by multiple tracks (like an Aux), then you have to recalculate every track for any change to every track (pre-gen turned off here too!).

If you have any VI's, it's not possible on any pathway including that VI

Why not? What's happening in a VI that can't be done earlier? What's not 100% determined beforehand?

If you have any live audio input, you can't look ahead. (hardware inserts for instance)

Yes, I already mentioned that.

I agree it's probably not practical to do this because at the very least you'd have to have different processing for live and sequenced tracks which would probably require a change to the VST and AU specs.

Interesting though. I had always assumed look ahead was just there so the audio engine would know a peak was coming, not so it could actually suppress the attack before it happens. It that done to simulate the poor transient response of some analog equipment?