Bitwig vs Ableton - PDC Test (Video)

[kb420]

The limitations of your DAW and in this case PDC are not flaws: they’re features. Instead of fighting with them, accept them. a lot of great records were made with 24 tracks or less, and a load of other limitations we never have to think about. I think ableton is a really powerful mixing tool and the “limitations” it has can help someone find creative ways to make a better mix.

Yeah, it's getting to be a lot more like Sonar's forums. No doubt about it.

[clydesdale]

Angstrom,

Add a Utility and then duplicate your track. On the second track delete the compressors and invert the phase (make it a null test). With the Auto Pan disabled on both tracks I get zero output as expected so there's no inherent delay on a look ahead compressor. If I enable both Auto Pan effects I hear artifacts which demonstrates the sync delay like your original example. Now change the Auto Pan devices to Ping Pong Delays. The output goes to zero again. Why don't I get the same delay problem with a different sync'd device if it's actually a delay compensation issue that we're trying to demonstrate? I was able to offset the Auto Pan on track 2 by 86.4 degrees to once again cancel out the two tracks (29.8 degrees per compressor). Any thoughts?

sync-example-alt.als

The video was specific to automation delay which everyone seems to agree is incorrectly compensated.

[Angstrom]

Your ping-pong delays will phase cancel because they aren't beat-synced, IE it's not a buffer-shuffler playing back buffer chunks in sync to timecode. A delay is simply a looping buffer with its length set to an appropriate size for the sample rate & bpm.

Think of a delay like one of those flat travelators they have in airports. If there are two of them next to each other, rolling at the same speed, it doesn't matter if their position is out of sync. You can step on either at any time. Think of two menstepping onto these two travelators at the same instant - they will exit the end of the travelators at the same instant. regardless of the relative looping floor positions.

Now think of a buffer shuffler type effect (a synced audio effect), as an escalator, there are rising steps which are fixed in relation to each other. You must place your foot on the flat part of the step. If two escalators running at the same speed, but with steps misaligned, the men exiting the two escalator exits will not 'phase cancel'

I am boring myself now. And I hate this metaphor.

[TTOZ]

For that reason, I am personally not bothered at all about PDC. I just don't need it, and (if I understand it correctly) Live's own approach to timing is very much linked to their approach to latency in a performance situation.

This is a misunderstanding of the problem.It is not in any way a benefit to live performers, or some sort of "DAW thing". The issue stated very simply is :

In Ableton Live, any "synced devices" can go out of sync with the music

That is, if you use anything like beat repeat, or any Max4Live device which has any kind of beat, sync, or timing facility. Regardless of whether you are on stage or in a studio.

Here is a very simple example for you.
>>>DOWNLOAD THE EXAMPLE FILE<<< (26kb .als)

In this example an open hi-hat plays on the beat, and an Autopan is set to 16th notes. The autopan is a "synced" effect, it should be in sync with the time of the song.
Play the set, it sounds correct.

There are 3 (de-activated) compressors before the autopan. Turn the Macro dial marked "turn me", this will alter the look-ahead value of the compressors, adding latency to the chain.

Notice that the autopan (synced) effect goes out of time. Notice that the compressors are off, and that this is not a very extreme example.



Can you hear this?
Do you think that out of time effects are good for a live performer? Do you think this is just a DAW thing?

Consider what would happen if you were using a more complex set, perhaps using a few Max4Live synced effects or VST instruments, a BeatRepeat, a glitch plugin. Consider what layers of this effect might sound like.

Consider the variety of automation and various timing events affected by this.

Hopefully this clarifies the issue.

Fantastic post

[Machinesworking]

OK another way the old school DAWs kick Live's ass. There's nothing new to Live 9 in that .als file you posted Angstrom, but because you made it in Live 9.1 I can't open it in Live 8 Suite 64 bit version! DP8 can save a Project as an older version all the way back to Digital Performer 3. MOTU decided being able to work with people who haven't upgraded was more important to their customers than surreptitiously goading them into upgrading.

[clydesdale]

Your ping-pong delays will phase cancel because they aren't beat-synced, IE it's not a buffer-shuffler playing back buffer chunks in sync to timecode. A delay is simply a looping buffer with its length set to an appropriate size for the sample rate & bpm.

What you're saying is Sync for Auto Pan is different than Sync for Ping Pong. In the case of PPD it's just a calculated number and not intended to sync to the metronome.

Back to your example, if three compressors cause a phase shift error of 86.4 degrees (verifiable in the provided .als) on a device running at 16th notes and 120bpm (quarter notes) that would be 1 / 120 * 4 seconds of error or 2.08 milliseconds sync error for the Auto Pan caused by the compressor in 10ms look ahead mode. Is that sync error essentially latency between the audio input at the Auto Pan and the Auto Pan device's sync timecode reference?

[beatz01]

Geez all i wanted was to make some music, now i have to be a math professor and i always sucked at math...

Can i have the 80s back please ? I think a Tascam 4 track will be enough.

Thanks.

[tone61]

For that reason, I am personally not bothered at all about PDC. I just don't need it, and (if I understand it correctly) Live's own approach to timing is very much linked to their approach to latency in a performance situation.

This is a misunderstanding of the problem.It is not in any way a benefit to live performers, or some sort of "DAW thing". The issue stated very simply is :

In Ableton Live, any "synced devices" can go out of sync with the music

That is, if you use anything like beat repeat, or any Max4Live device which has any kind of beat, sync, or timing facility. Regardless of whether you are on stage or in a studio.

Here is a very simple example for you.
>>>DOWNLOAD THE EXAMPLE FILE<<< (26kb .als)

In this example an open hi-hat plays on the beat, and an Autopan is set to 16th notes. The autopan is a "synced" effect, it should be in sync with the time of the song.
Play the set, it sounds correct.

There are 3 (de-activated) compressors before the autopan. Turn the Macro dial marked "turn me", this will alter the look-ahead value of the compressors, adding latency to the chain.

Notice that the autopan (synced) effect goes out of time. Notice that the compressors are off, and that this is not a very extreme example.



Can you hear this?
Do you think that out of time effects are good for a live performer? Do you think this is just a DAW thing?

Consider what would happen if you were using a more complex set, perhaps using a few Max4Live synced effects or VST instruments, a BeatRepeat, a glitch plugin. Consider what layers of this effect might sound like.

Consider the variety of automation and various timing events affected by this.

Hopefully this clarifies the issue.

I noticed how the sound changes when I turn the TurnMe-knob.

But then I added Live's Arpeggiator/Bach 16th.adv in front of the Instrument Rack.
Now the sound stays almost the same in all TurnMe-knob's values. Why?

[TabSel]

For that reason, I am personally not bothered at all about PDC. I just don't need it, and (if I understand it correctly) Live's own approach to timing is very much linked to their approach to latency in a performance situation.

This is a misunderstanding of the problem.It is not in any way a benefit to live performers, or some sort of "DAW thing". The issue stated very simply is :

In Ableton Live, any "synced devices" can go out of sync with the music

That is, if you use anything like beat repeat, or any Max4Live device which has any kind of beat, sync, or timing facility. Regardless of whether you are on stage or in a studio.

Here is a very simple example for you.
>>>DOWNLOAD THE EXAMPLE FILE<<< (26kb .als)

In this example an open hi-hat plays on the beat, and an Autopan is set to 16th notes. The autopan is a "synced" effect, it should be in sync with the time of the song.
Play the set, it sounds correct.

There are 3 (de-activated) compressors before the autopan. Turn the Macro dial marked "turn me", this will alter the look-ahead value of the compressors, adding latency to the chain.

Notice that the autopan (synced) effect goes out of time. Notice that the compressors are off, and that this is not a very extreme example.



Can you hear this?
Do you think that out of time effects are good for a live performer? Do you think this is just a DAW thing?

Consider what would happen if you were using a more complex set, perhaps using a few Max4Live synced effects or VST instruments, a BeatRepeat, a glitch plugin. Consider what layers of this effect might sound like.

Consider the variety of automation and various timing events affected by this.

Hopefully this clarifies the issue.

I noticed how the sound changes when I turn the TurnMe-knob.

But then I added Live's Arpeggiator/Bach 16th.adv in front of the Instrument Rack.
Now the sound stays almost the same in all TurnMe-knob's values. Why?

Because Ableton decided to fully compensate their native devices, but NOT plugins.

BTW, I don't want to have the sound stay ALMOST the same, I want the sound to stay EXACTLY the same (timing wise).

[Angstrom]

[
I noticed how the sound changes when I turn the TurnMe-knob.

But then I added Live's Arpeggiator/Bach 16th.adv in front of the Instrument Rack.
Now the sound stays almost the same in all TurnMe-knob's values. Why?

The arpegiator sits at the start of the processing chain, still in the MIDI realm. The issues is with devices which handle audio - many devices (both Ableton and 3rd party) require a small amount of time to process audio. Ableton uses PDC to keep all the audio streams in time, so when they all arrive at the output together they are all in sync. So a compressor wit a lookahead of 10ms must make the audio wait 10 ms to do its magic. So that this track is not now 10ms out of time Ableton will delay all the other tracks 10ms, so now the tracks are all in sync again. This is done for both Native and 3rd party devices and the audio part as described works well.

Where the issue arrises is when the events system must act on a device within that latent chain. So lets say we want to turn a dial in that compressor with 10ms lookahead, so we set automation on a switch to happen on the beat of 8:1:1 . The problem is that this event should really happen at 8:1:1 +10 milliseconds. Because the audio stream is offset by that amount. It would seem obvious that Ableton ought to "compensate" the events system too, right? Just a simple offset of any timing critical events by the amount of latency of the track. But the problem arrises (I think) because racks can contain streams with different latency offsets, so Ableton need to fix the system so that any automation of any paramater can be aligned with its parent device. Which is tricky.

So, the reason you dont hear any issues with an arpeggiator is because its prior to the PDC on the audio stream. The reason a lookahead compressor reveals the offset in automation / event timing, is because the compressor is in the audio stream. It incurs latency in order to look-ahead, and while the audio latency is handled well, the event latency within that stream is not.

Tl;dr PDC is complicated to explain, so imagine how hard it is to fix.

[tone61]

So, the reason you dont hear any issues with an arpeggiator is because its prior to the PDC on the audio stream. The reason a lookahead compressor reveals the offset in automation / event timing, is because the compressor is in the audio stream. It incurs latency in order to look-ahead, and while the audio latency is handled well, the event latency within that stream is not.

First, thanks for your very clear explanation.

But in my case I could hear the issue caused by compressor. Once I added the arp effect, then this issue almost disappeared.
That was my question: if the problem was clearly audible first, why did the midi effect fix it (let's say 90%)?

[Angstrom]

Interesting, but I couldn't really say. I try to only dedicate a very small part of the week to this stuff.

I should say too that I am just another dude on the internet and in no way should anything I say be taken as gospel. It may one day come to light that that synchronised events are actually offset due to a malevolent elf infestation. I am not privvy to any direct information on the subject. I'm just another guy an the internet with half-informed opinions.

[clydesdale]

Using Angstrom's example:

Auto Pan at 120 bpm 1/16th note sync

Effect : Sync phase delay

Compressor (10ms lookahead) : 28.8 deg
Gate (10ms lookahead) : 28.8 deg
Reverb : 0.48 deg
Amp : 15.36 deg
Cabinet : 15.36 deg
Corpus : 19.2 deg
Limiter : 7.68 deg

These were the only devices that caused any sync mismatch. The sync variance is dependent on bpm, sync note and lookahead value. Assuming an M4L device doesn't cause further sync errors it might be possible to create a device that automatically adjusts the offset to compensate. If theose values are static you could do it manually pretty easily. I'm not sure if computer CPU plays any role in the error either.

I tested a few other sync'd devices, the only one as of yet that has the same problem is the Auto Filter.

[deva]

So, the reason you dont hear any issues with an arpeggiator is because its prior to the PDC on the audio stream. The reason a lookahead compressor reveals the offset in automation / event timing, is because the compressor is in the audio stream. It incurs latency in order to look-ahead, and while the audio latency is handled well, the event latency within that stream is not.

First, thanks for your very clear explanation.

But in my case I could hear the issue caused by compressor. Once I added the arp effect, then this issue almost disappeared.
That was my question: if the problem was clearly audible first, why did the midi effect fix it (let's say 90%)?

It may be because each time the arp is creating a new note, it is resetting the device that has note sync so there is not time to hear that it is off...

[Will The Weirdo]

I love live for creative work but the PDC issue forces pro mixing work to be done in another DAW. I dump out to mix, not really an issue, just takes more time. I like Bitwig coming into the picture, competition forces everyone to stay working hard or loose your business. I'm really hoping to see Ableton take Bitwig's best ideas and integrate them into Live 10... with fixed PDC.
FWIW, I also love my Push, so I for one am glad they made it.