Understanding lookahead
Moderator: James Steele
Forum rules
This forum is for most discussion related to the use and optimization of Digital Performer [MacOS] and plug-ins as well as tips and techniques. It is NOT for troubleshooting technical issues, complaints, feature requests, or "Comparative DAW 101."
This forum is for most discussion related to the use and optimization of Digital Performer [MacOS] and plug-ins as well as tips and techniques. It is NOT for troubleshooting technical issues, complaints, feature requests, or "Comparative DAW 101."
- SMS
- Posts: 332
- Joined: Mon Dec 13, 2004 10:01 pm
- Primary DAW OS: MacOS
- Location: San Francisco and Monterey
- Contact:
Understanding lookahead
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
Thanks
Bill
MOTU user since Performer™ 1.22 on 128k floppy
DP 11.23
MacBook Pro 14” 2023 M2 max 12 core
64 Gb RAM
4TB SSD
OS 14.0 Sonoma
UAD Apollo 8
828 mk3 Hybrid
MIDI Express XT
DP 11.23
MacBook Pro 14” 2023 M2 max 12 core
64 Gb RAM
4TB SSD
OS 14.0 Sonoma
UAD Apollo 8
828 mk3 Hybrid
MIDI Express XT
- Robert Randolph
- Posts: 877
- Joined: Tue Apr 29, 2014 6:50 am
- Primary DAW OS: MacOS
- Location: St. Petersburg, Florida
Re: Understanding lookahead
You understand the use.SMS wrote: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
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
- Posts: 332
- Joined: Mon Dec 13, 2004 10:01 pm
- Primary DAW OS: MacOS
- Location: San Francisco and Monterey
- Contact:
Re: Understanding lookahead
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?
MOTU user since Performer™ 1.22 on 128k floppy
DP 11.23
MacBook Pro 14” 2023 M2 max 12 core
64 Gb RAM
4TB SSD
OS 14.0 Sonoma
UAD Apollo 8
828 mk3 Hybrid
MIDI Express XT
DP 11.23
MacBook Pro 14” 2023 M2 max 12 core
64 Gb RAM
4TB SSD
OS 14.0 Sonoma
UAD Apollo 8
828 mk3 Hybrid
MIDI Express XT
Re: Understanding lookahead
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
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
Re: Understanding lookahead
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
(a very confused) Phil
DP 11.23, 2020 M1 Mac Mini [9,1] (16 Gig RAM), Mac Pro 3GHz 8 core [6,1] (16 Gig RAM), OS 14.3.1/11.6.2, Lynx Aurora (n) 8tb, MOTU 8pre-es, MOTU M6, MOTU 828, Apogee Rosetta 800, UAD-2 Satellite, a truckload of outboard gear and plug-ins, and a partridge in a pear tree.
- stubbsonic
- Posts: 4648
- Joined: Fri Dec 22, 2006 12:56 pm
- Primary DAW OS: MacOS
- Contact:
Re: Understanding lookahead
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.
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.
M1 MBP; OS 12, FF800, DP 11.3, Kontakt 7, Reaktor 6, PC3K7, K2661S, iPad6, Godin XTSA, Two Ibanez 5 string basses (1 fretted, 1 fretless), FM3, SY-1000, etc.
http://www.jonstubbsmusic.com
http://www.jonstubbsmusic.com
- Robert Randolph
- Posts: 877
- Joined: Tue Apr 29, 2014 6:50 am
- Primary DAW OS: MacOS
- Location: St. Petersburg, Florida
Re: Understanding lookahead
Not every plugin goes on a channel that is connected to a single disk-based audio stream.Phil O wrote: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
What if it is on an aux? The second plugin in the chain? A softsynth? Lots and lots of examples...
Re: Understanding lookahead
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?Robert Randolph wrote: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
DP 11.23, 2020 M1 Mac Mini [9,1] (16 Gig RAM), Mac Pro 3GHz 8 core [6,1] (16 Gig RAM), OS 14.3.1/11.6.2, Lynx Aurora (n) 8tb, MOTU 8pre-es, MOTU M6, MOTU 828, Apogee Rosetta 800, UAD-2 Satellite, a truckload of outboard gear and plug-ins, and a partridge in a pear tree.
Re: Understanding lookahead
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:
Phil
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 Dave's answer is the best (no big surprise there ).SMS wrote: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?
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.magicd wrote: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.
Phil
DP 11.23, 2020 M1 Mac Mini [9,1] (16 Gig RAM), Mac Pro 3GHz 8 core [6,1] (16 Gig RAM), OS 14.3.1/11.6.2, Lynx Aurora (n) 8tb, MOTU 8pre-es, MOTU M6, MOTU 828, Apogee Rosetta 800, UAD-2 Satellite, a truckload of outboard gear and plug-ins, and a partridge in a pear tree.
- stubbsonic
- Posts: 4648
- Joined: Fri Dec 22, 2006 12:56 pm
- Primary DAW OS: MacOS
- Contact:
Re: Understanding lookahead
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.
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.
M1 MBP; OS 12, FF800, DP 11.3, Kontakt 7, Reaktor 6, PC3K7, K2661S, iPad6, Godin XTSA, Two Ibanez 5 string basses (1 fretted, 1 fretless), FM3, SY-1000, etc.
http://www.jonstubbsmusic.com
http://www.jonstubbsmusic.com
Re: Understanding lookahead
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.
DP 11.23, 2020 M1 Mac Mini [9,1] (16 Gig RAM), Mac Pro 3GHz 8 core [6,1] (16 Gig RAM), OS 14.3.1/11.6.2, Lynx Aurora (n) 8tb, MOTU 8pre-es, MOTU M6, MOTU 828, Apogee Rosetta 800, UAD-2 Satellite, a truckload of outboard gear and plug-ins, and a partridge in a pear tree.
- terrybritton
- Posts: 1117
- Joined: Thu Jun 04, 2015 8:45 am
- Primary DAW OS: Windows
- Location: Elizabeth City, NC
- Contact:
Re: Understanding lookahead
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
I had never thought of it that way myself, as having transient shaping capabilities. That point just slipped past me somehow!
Terry
Computer: Sweetwater CS400v7 Intel Core i7-10700K CPU @ 3.80GHz | 64Gigs RAM | Windows 11 Pro x64 |
MOTU 828 mk3 hybrid
DAWs & Live: MOTU Digital Performer 11.31 | Cantabile Performer 4
Keyboard Synths: Kawai K5000s, Korg Wavestation
Controllers: NI Komplete Kontrol S-88 Mk3 & S-49 Mk2; Maschine Mk3 & JAM;
Akai MPK249 & 225, Alesis QX49, Behringer BCF2000 & FCB1010
Rack Modules: Ensoniq ESQm, Yamaha TX81Z, Wavestation SR
Tutorials: https://youtube.com/@CreatorsMediaTools
MOTU 828 mk3 hybrid
DAWs & Live: MOTU Digital Performer 11.31 | Cantabile Performer 4
Keyboard Synths: Kawai K5000s, Korg Wavestation
Controllers: NI Komplete Kontrol S-88 Mk3 & S-49 Mk2; Maschine Mk3 & JAM;
Akai MPK249 & 225, Alesis QX49, Behringer BCF2000 & FCB1010
Rack Modules: Ensoniq ESQm, Yamaha TX81Z, Wavestation SR
Tutorials: https://youtube.com/@CreatorsMediaTools
Re: Understanding lookahead
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.
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.
2018 Mini i7 32G 10.14.6, DP 11.3, Mixbus 9, Logic 10.5, Scarlett 18i8
- Robert Randolph
- Posts: 877
- Joined: Tue Apr 29, 2014 6:50 am
- Primary DAW OS: MacOS
- Location: St. Petersburg, Florida
Re: Understanding lookahead
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.bayswater wrote: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.
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.
Re: Understanding lookahead
Yes, I already mentioned that.Robert Randolph wrote:Which has to happen with latency compensation for every change in plugins anyway.bayswater wrote: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).Robert Randolph wrote: 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!).Why not? What's happening in a VI that can't be done earlier? What's not 100% determined beforehand?Robert Randolph wrote: If you have any VI's, it's not possible on any pathway including that VIRobert Randolph wrote: If you have any live audio input, you can't look ahead. (hardware inserts for instance)
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?
2018 Mini i7 32G 10.14.6, DP 11.3, Mixbus 9, Logic 10.5, Scarlett 18i8