LIVE 9 : PDC IMPROVED OR NOT ?

[su]

fwiw , I wanted to commend the folks who have stuck with this topic. There's a lot of wisdom on this thread, much of it heartfelt. That really comes through. great examples on the previous page alone = merges and rtcardinal

This is hard stuff to describe in text, but many good insights have been put on the table. Yes, there's been some personal attacks along the way (I was one of the contributors myself), but that's the internetz. Gotta read with crapfilter=on.

*edited for accuracy*

[rtcardinal]

I guess it at least goes to show people are passionate about their craft, even if there are a few cuts, scratches, and soggy diapers along the way.

[shadiradio]

My writing partner and I actually run into this issue a lot in our tracks. We sometimes have many orchestral tracks (joy that 64-bit is now supported) with automation for dynamics and timing, and as the project continues and more devices are added to chains, the timing of things starts to feel wrong. He would always look at me like, "what's going on?" or "are we just crazy?" because we'd have to manually adjust the midi notes and shift them for it to sound on time again. I have to apologize to him on behalf of the software. He usually asks why aren't we just using other software that doesn't have this problem, and I'm finding it harder to give him a good reason. I still want to stay with Live because of the rest of the beautiful workflow, and that's why I'm passionate about them fixing this.

[glitchrock-buddha]

My writing partner and I actually run into this issue a lot in our tracks. We sometimes have many orchestral tracks (joy that 64-bit is now supported) with automation for dynamics and timing, and as the project continues and more devices are added to chains, the timing of things starts to feel wrong. He would always look at me like, "what's going on?" or "are we just crazy?" because we'd have to manually adjust the midi notes and shift them for it to sound on time again. I have to apologize to him on behalf of the software. He usually asks why aren't we just using other software that doesn't have this problem, and I'm finding it harder to give him a good reason. I still want to stay with Live because of the rest of the beautiful workflow, and that's why I'm passionate about them fixing this.

One thing you could do if you do a lot of volume automation is to automate a utility early in the chain instead of automating the mixer channel's level. Since the level is the last thing to get the audio signal for that track, it will get timing problems if you add many plug-ins with latency.

[shadiradio]

One thing you could do if you do a lot of volume automation is to automate a utility early in the chain instead of automating the mixer channel's level. Since the level is the last thing to get the audio signal for that track, it will get timing problems if you add many plug-ins with latency.

Hmm, this is what I do... I always automate volume with a Utility plugin that is usually first in the chain (it's part of a general channel strip rack with some high/low pass filters, slight compression, etc). But good to know that I should make sure it's first in the chain. There's a lot of other automation in arrangement view for parts (hold/sustain pedal for piano passages, modulation/expression parameters for most orchestral samplers).

[glitchrock-buddha]

One thing you could do if you do a lot of volume automation is to automate a utility early in the chain instead of automating the mixer channel's level. Since the level is the last thing to get the audio signal for that track, it will get timing problems if you add many plug-ins with latency.

Hmm, this is what I do... I always automate volume with a Utility plugin that is usually first in the chain (it's part of a general channel strip rack with some high/low pass filters, slight compression, etc). But good to know that I should make sure it's first in the chain. There's a lot of other automation in arrangement view for parts (hold/sustain pedal for piano passages, modulation/expression parameters for most orchestral samplers).

Hmmm, not sure why it would go out of time then. If you're automating sampler parameters and such. Shouldn't matter.

[theophilus]

so, more analysis. it looks like even taking a send back into an audio track is completely compensated, as long as you disable the send loop. i will go back to the other earlier example and see if there's anything else i can try to mess it up.

first picture, same basic setup as the first example earlier, except take the send back into an audio track. the master completely gets trashed (master is the big pink one; wait one for the rest).

however... there is a potential loop here: the audio track can send back to A (even though it's off, at 0, right now) causing a loop which PDC can do nothing about. if you disable the send from that track, just to A, everything gets back in time (second picture). note that the big pink one looks fine now, no flanging visible (or audible).

in this case, the seven signals are: first the 2 tracks on the left, then the send (first in chain), then the master, then the audio track that I sent the send to (first in chain), then I added a reverberate (4096 sample latency, 100% dry) to the send and the audio track, and the last two are end of chain. The master added the right latency to line all these up at the end.

Some people seem to think I'm saying this is no issue. You can see major delays between the midi clocks and the audio - just because the audio is correctly in sync doesn't mean tempos etc. will be - a tempo-based effect would do horrible things to this track, and wouldn't do what you expect at all. All I am saying at all, is that ableton has already done most of the hard work here, and so if it's properly defined i think they should be able to fix it.

[theophilus]

one more picture...

so in this one, i needed a sidechain test. i used the vocoder for this purpose; again, 100% dry. it was sufficient - i duplicated the second track, everything in sync. add vocoder - everything in sync. change vocoder to point to the audio output from track 3 (where the send was routed back into an audio track) - complete trash again. it figured out there was a loop again. disable the send to A (where the loop was) and everything snaps back into sync. i can see where this would not be obvious at all though, in a complex enough set - would be nice if ableton had a track-level indicator that pdc was on or disabled for that track. then you could go track down what's making your set go completely to crap.

come on ableton, you're more than halfway there to getting the automation in sync too....

[ze2be]

Nice and helpfull discovery, theophilus!

[petit nuage]

big thanks theophilius for all your investigations !

Very interesting !!!


C'MON ABLETON hang on !!!

[Nokatus]

One thing you could do if you do a lot of volume automation is to automate a utility early in the chain instead of automating the mixer channel's level. Since the level is the last thing to get the audio signal for that track, it will get timing problems if you add many plug-ins with latency.

Hmmm, not sure why it would go out of time then. If you're automating sampler parameters and such. Shouldn't matter.

Edit: disregard this. I was wrong and stupid for not making sure myself before posting this. Goes to show that things one might be "absolutely sure of", to the point of writing shit in order to make others "understand the issue"... might not be so after all.

So yeah, sorry.

Contrary to what I wrote, plugin order effects this a great deal, not just the total PDC offset in relation to global project time. So automation will shift only if you place a high latency plugin into the chain before the one you're automating, not after.

------ Erroneous post below: ------------

That's because the delay caused by plugins is compensated, but automation isn't. It's important to understand this discrepancy, how it manifests, and why it's a potential inconvenience. It has no bearing on this particular issue where the automated plugin is placed in the chain: when you have plugins causing latency anywhere in a chain, automation will be off by the amount the whole chain has been compensated for.

So for example, if you have defined a gain automation curve for the Utility plugin, and later add a high-latency plugin anywhere in that chain, PDC will offset the audio of that channel accordingly (and compensate for the audio latency) but the automation information which is read according to the project time, along with the timeline, will now be at the wrong place because it has not been offset by the same amount. One way to think about it, when PDC compensates for latency: imagine moving an audio track on the timeline while all the automation curves stay in place. That's exactly what happens, effectively, with automation when you have a high-latency chain going.

Everything looks fine visually, but in order to get the automation back into the right place again, you will need to manually offset all of it so that it's actually visually in the wrong place on the timeline.

[theophilus]

That's because the delay caused by plugins is compensated, but automation isn't. It's important to understand this discrepancy, how it manifests, and why it's a potential inconvenience. It has no bearing on this particular issue where the automated plugin is placed in the chain: when you have plugins causing latency anywhere in a chain, automation will be off by the amount the whole chain has been compensated for.

So for example, if you have defined a gain automation curve for the Utility plugin, and later add a high-latency plugin anywhere in that chain, PDC will offset the audio of that channel accordingly (and compensate for the audio latency) but the automation information which is read according to the project time, along with the timeline, will now be at the wrong place because it has not been offset by the same amount. One way to think about it, when PDC compensates for latency: imagine moving an audio track on the timeline while all the automation curves stay in place. That's exactly what happens, effectively, with automation when you have a high-latency chain going.

i'll have to try this later, but based on how i understand the implementation, it should work. basically, any automation you do BEFORE a latency-inducing plugin should remain completely in time, no matter how much latency; any automation AFTER the latency-inducing plugin will be off by however many samples of latency it inserts, and this is additive ... if you have 3 latency-inducing plugins in your chain, all 3 of them see midi clock at different times relative to the audio (strictly speaking, they all see the same midi clock, but see 3 different latencies in the audio stream). haven't tried the case with latency-inducing synths yet (not sure which ones I have are high-latency... only one I saw in this thread was aalto, have to check 3dot's list if any are in there? i don't have aalto) so don't know exactly if they also have an issue or not.

[Nokatus]

i'll have to try this later, but based on how i understand the implementation, it should work. basically, any automation you do BEFORE a latency-inducing plugin should remain completely in time, no matter how much latency; any automation AFTER the latency-inducing plugin will be off by however many samples of latency it inserts, and this is additive ...

I have tested this before, and I'm fairly sure I reproduced the type of behavior I described. To be honest, in any case your comments are making me doubt the certainty of what I just said . If it's indeed as you say, I'll owe everyone an apology for writing what I just did. I'll test it myself, too, as soon as I have the chance.

Edit: rushed to test it right away. You're right, and I'm completely wrong. Apologies for being "certain" to the point of posting that before making fully sure myself. I'll edit my post accordingly. Realizing how plugin order actually effects automation shift, this also gives much more comfortable leeway when dealing with the issue. Thank you for the detailed info you have provided!

[glitchrock-buddha]

I've been doing my own tests to understand the issue as well and although it's been described a lot, I know it can still be confusing for people so I thought I'd post what I did to understand how it could affect me (and probably has unknowingly). It's good to have the waveforms showing exactly what's going on above, but some people might might still not get how it would affect things in a real use situation. Tempo set around 90 BPM.

-My test latency plug-in was reverberate, set to 4096 samples for obvious latency. Set to all dry so no change in sound. Think of this as the huge look ahead compressor.
-I loaded up percussive sample that lasted about a 1/16 note in a sampler and played it on the quarter notes of a 4/4 beat (1/5/9/13). Looks like x---x---x---x---
-I wrote in a clip envelope to mixer volume that allowed only the 1/16 notes at the 1/5/9/13 positions where the sound was playing. So the sound got through fine.
-Now I inserted reverberate on the track. The higher the latency I set, the more the sound would get cut off. This is because the actual audio was being delayed, so when it hit the volume envelope, the sound had less of a window in which to play until at 4096 sample latency, the sound was gone, because it didn't fit in that 1/16th note anymore. It was actually hitting the mixer level envelope around the second 1/16th note, after the volume closed.
-I did a similar test with effectrix and beat repeat (removed volume envelope first). I just used the looper to trigger 1/16th note repeats on the first note for a quarter note duration. So you'd hear the first note repeated three times, followed by the 5. Sounds like xxxxx---x---x---. Set it to full wet signal. When I placed the effect before reverberate, the first note repeated. When I moved it to after reverberate, the sound of the first note and it's repeats disappeared because it moved out of the 1/16th note signal that was to be repeated. Sounds like ----x---x---x---. So you don't hear the original note or repeats. This is exactly the same as using the mixer envelope. If I lessen the latency, then it will play and repeat part of the first note, but cut off.
-I moved the repeater plug-in to a send track, set the send pre so that I could send the full signal to the send without any dry signal. Same thing as above. The sound disappeared from the first note and no repeats.
-I also duplicated the track and removed reverberate. The overall sound was in sync with the delayed track and when I inserted the repeat plug-in or made a volume envelope, it functioned as expected even though it too was delayed to match the track with latency. That's because that track is delayed after the entire signal. Internally, the audio is hitting the grid based effects and modulation at the proper time.

So the lessons I take from this:
-Know your plug-ins latency. I check my plug latencies in Studio One because it displays what each plug-in reports. Most plug-ins have negligible latency. It's usually compressors and limiters that have significant latency. Any lookahead will introduce that much latency obviously.
-Always try to put latency causing plug-ins like compressors after a grid-based plug-in like beatrepeat or any effects that you write fast time dependent automation for. So it's not a problem on the Master or on sends (if the sends aren't sending back to a track).
-Beware of putting any grid-based plug-ins like beatrepeat on return tracks. The audio being sent to it will be delayed by the latency plug-in on a track. Consider return track simply later in the audio signal so same rule applies. Timing information will be off. Delays don't count because they just repeat the audio signal is received. But an effect like beat repeat takes the signal within a given part of it's grid, which is synced to the transport. Timing will be off if the audio within it is off.
-Try to stick to lower lookahead values if you want a grid based effect or automation of an effect after the compressor/limiter. This would be common in a drum rack for example where you might want individual compressors for single hits and then might have automation for effects after the drum rack, or a gater/repeater effect. In this case stick to no lookahead or 1ms or something. If you need to tame transients more severely, put a lookahead plug at the very end.

I don't know if that's helpful, but I figure it can't hurt since many people are still confused about it. Once you get your head around it, it's not bad to avoid it, but because live corrects the audio, people assume that automations are compensated and effects (which they should be!), so it can be hard to figure out what's causing timing problems if you're not careful with effect placement.

cheers

[H20nly]

there is another thread about sample rate 44.1 vs. 88.2... in that thread someone implied that VST latency can be reduced by using the higher sample rate. do any of you see that? and/or think that there is some merit to that?


oh and... nice sleuthing theophilus