DSP Robotics Support

Spogg wrote:The disadvantage of Look-ahead is that it must create latency, which means it’s unsuitable for live use.

Not necessarily: A small latency up to 10 ms is perfectly acceptable. (For comparison: sound needs 10 ms to travel a distance of 3 m.)

drag the track forward in time to compensate for the latency.

Or use the delay compensation prim!

martinvicanek wrote:

Spogg wrote:The disadvantage of Look-ahead is that it must create latency, which means it’s unsuitable for live use.

Not necessarily: A small latency up to 10 ms is perfectly acceptable. (For comparison: sound needs 10 ms to travel a distance of 3 m.)

drag the track forward in time to compensate for the latency.

Or use the delay compensation prim!

Would a compressor work correctly with just 10mS for the side chain to react correctly though?

I never properly understood the use of the delay compensation prim. Does it cause the DAW to move all other tracks to align or just the track with the compressor in it? Also, is it the case that all DAWs read that prim’s notification?

This is where my lack of production experience lets me down…

Cheers

Spogg

"without techtalk" doesn't mean without .fsm, isn't?


you may base on this, adding bells and whistles like :

- a delay line in the audio signal path (this way the gain reduction can happen, synchronous with the peak)

- a 4th-order Bessel lowpass filter in db domain, after the lin2db module (beware of the very small Fr - it is better to rely on State Variable 2nd-order LPF blocks instead of Direct Form I or II LPF blocks - sorry this is indeed techtalk)

- substituting the RMS detector by a peak detector that's embedding ballistics (attack time, decay time)

Have a nice day

Spogg wrote:Look-ahead is actually a misnomer in a way. It should really be called something like Act-later.

I should have known that a time-travelling Vulcan would nit-pick at our lazy human temporal semantics!

Spogg wrote:Would a compressor work correctly with just 10mS for the side chain to react correctly though?

It all depends what frequencies you're trying to control - but it certainly could contribute to the "wobbly" compression I mentioned earlier for bass-heavy instruments. The integration time for an RMS-detector ideally needs to be long enough to capture several cycles, just as when choosing an FFT size. And as steph_tsf's schematic shows (thanks!), we'd normally be using an approximation with exponential decay rather than a sliding window; so the integration time is measured by an arbitrary convention in practice (e.g. how quickly an impulse decays by so-many dB, or something like that).

Spogg wrote:I never properly understood the use of the delay compensation prim. Does it cause the DAW to move all other tracks to align or just the track with the compressor in it? Also, is it the case that all DAWs read that prim’s notification?

More "it depends", I'm afraid! Once the necessary delays are calculated, you could either add delays to the other channels to line them up, or you could "pre-read" the audio by shifting the audio file playback pointers for the "laziest" channels backwards (likely a bit of both, given the complex routings we're allowed these days). The situation with different DAWs is much like for PPQ/Tempo signals; some manage it better than others. For example; Reaper implements it very well, even PPQ/Tempo seems to be compensated correctly, whereas this doesn't seem to work for FL at all well - as I've discovered with some of my attempts at sample-accurate tempo sync'.

Of course, whatever strategy is used, you can't do anything about round-trip latency for live playing; and while 10ms isn't much delay, this would be added to the latency of soundcard buffers, so could still tip things over the edge for some players. I seem to have become so used to it (maybe from years of band practices in huge old Victorian mills) that too little latency can throw me a bit when I'm playing my bass!

However, this may be moot, as compressing a live monitor feed during recording is usually best avoided anyway - it can interfere with the perceptual feedback-loop which allows an experienced performer to control their own dynamics at source.

trogluddite wrote:Of course, whatever strategy is used, you can't do anything about round-trip latency for live playing; and while 10ms isn't much delay, this would be added to the latency of soundcard buffers, so could still tip things over the edge for some players. I seem to have become so used to it (maybe from years of band practices in huge old Victorian mills) that too little latency can throw me a bit when I'm playing my bass!

A couple of hours on a 19th-century pipe organ will make you a lot more tolerant of latency. DAMHIKT

deraudrl wrote:

trogluddite wrote:Of course, whatever strategy is used, you can't do anything about round-trip latency for live playing; and while 10ms isn't much delay, this would be added to the latency of soundcard buffers, so could still tip things over the edge for some players. I seem to have become so used to it (maybe from years of band practices in huge old Victorian mills) that too little latency can throw me a bit when I'm playing my bass!

A couple of hours on a 19th-century pipe organ will make you a lot more tolerant of latency. DAMHIKT

This, or watching me trying to play piano by sheet...

tulamide wrote: This, or watching me trying to play piano by sheet...

Yes indeed! I gave up trying when I was practicing for grade 3 piano when I was 11. My latency could be measured in minutes!

Going back to Look-ahead…

If I changed the attack time wouldn’t I have to change the delay time so stuff still lined up? In a DAW track with such a compressor already loaded, would the DAW read the delay compensation prim dynamically or would it only check it out while loading it?

Cheers

Spogg

Spogg wrote:Going back to Look-ahead…

If I changed the attack time wouldn’t I have to change the delay time so stuff still lined up?
Spogg

No. A Compressor's ATTACK, Release, Threshold, Makeup parameters have no affect on the 'timing' of the Audio. They are, basically, 'envelope' shapers on the audio stream.

Look-ahead may likely require that a plugin has a built-in buffer [latency] sized to handle the Range/Amount of looking ahead.

do that help ? [its very late ... or early morning here

RJHollins wrote:

Spogg wrote:Going back to Look-ahead…

If I changed the attack time wouldn’t I have to change the delay time so stuff still lined up?
Spogg

No. A Compressor's ATTACK, Release, Threshold, Makeup parameters have no affect on the 'timing' of the Audio. They are, basically, 'envelope' shapers on the audio stream.

Look-ahead may likely require that a plugin has a built-in buffer [latency] sized to handle the Range/Amount of looking ahead.

Something doesn’t add up in my poor old brain. If Attack doesn’t make a difference to the set delay time, what delay time should I set? If I change the attack time from 10mS to 20mS wouldn’t the evaluated control signal be correct and valid after 20mS rather than 10mS?

Cheers

Spogg

Spogg wrote:

RJHollins wrote:

Spogg wrote:Going back to Look-ahead…

If I changed the attack time wouldn’t I have to change the delay time so stuff still lined up?
Spogg

No. A Compressor's ATTACK, Release, Threshold, Makeup parameters have no affect on the 'timing' of the Audio. They are, basically, 'envelope' shapers on the audio stream.

Look-ahead may likely require that a plugin has a built-in buffer [latency] sized to handle the Range/Amount of looking ahead.

Something doesn’t add up in my poor old brain. If Attack doesn’t make a difference to the set delay time, what delay time should I set? If I change the attack time from 10mS to 20mS wouldn’t the evaluated control signal be correct and valid after 20mS rather than 10mS?

Cheers

Spogg

I imagine it being very difficult to think in so many dimensions and time periods, poor Vulcan!
Here you seem to mix things up.
As RJ explained, there's an audio stream, and that one is consecutive, wether you work on it or not. That'S why you have to make sure that everything you do fits in the short timespan, the asio buffer gives you. That's all there is to it.

When look-ahead is involved it means that you need a bigger buffer than the one provided by asio. The way to do it is to to delay the audio stream by some samples. That doesn't influence the paragraph above. It's just doing its thing delayed by a few samples, that's all. All you need to do is to delay for the amount of the max value of your look-ahead mechanic. Say, 1000 samples. And use delay compensation set to the same amount. That's all. Whatever attack or decay times you set in above paragraph didn't influence the stream of audio samples. So why do you think it would, when a one time delay of samples is introduced?