LIVE 9 : PDC IMPROVED OR NOT ?

[sporkles]

[crumhorn]

Is this the right place for the Ableton Christmas Pantomime ?

[pencilrocket]

what is anti-fanboys? Should I become fanboy?

[theophilus]

dare i bump this?

anyways, there are 2 more experiments i wanted to verify for myself (this is not really new information, it's already been mentioned, but means i have to recant something). anyways, i was under the impression that if you use 0-latency plugs, you wouldn't see an issue. and i've been somewhat focusing on audio PDC (which is mostly OK) and not really automation PDC, much to akshara's chagrin

anyways... there is no more workaround for this. using zero-latency plugs does NOT avoid the issue. basically, as someone has mentioned in regards to M4L, you incur a plugin delay for every plugin in the chain. this means that if you have 4 plugins in the chain, and the last one is a time-synced event, it will be off the grid, even if every plugin in the chain is zero-latency. reducing the plugin buffer helps but you can't completely eliminate the effect.

i posted something to the live 9 thread (a picture of this) which i won't repost here (yet), in that i've exaggerated the problem a little by using 515 bpm, but it's not difficult to reproduce, and clearly shows the issue - at that high bpm, adding 8 zero-latency IIEQ Pro effects caused the track to be almost a full beat out of sync (my buffer was set to 256). there are weird results too... reducing the audio buffer to 128 reduced the effect by more than half, to about a quarter of a beat (at 515bpm no less). So, the effect might be small enough not to bother you, but it is definitely there.

i don't think appears with internal devices; live 9 decided to make my audio devices disappear when i wanted to try it but i had already thrown simple delay in on a track, for a very high audio buffer (whatever the highest is) which showed an issue right away with iieq, and there was no delay at all with that one, so i wouldn't expect any for 8 of them either.

this also means that if during mixdown you turn your audio buffer to high values to reduce CPU, you could be making the problem worse and see issues where you didn't before.

so this is pretty bad.

[simpli.cissimus]

dare i bump this?

anyways, there are 2 more experiments i wanted to verify for myself (this is not really new information, it's already been mentioned, but means i have to recant something). anyways, i was under the impression that if you use 0-latency plugs, you wouldn't see an issue. and i've been somewhat focusing on audio PDC (which is mostly OK) and not really automation PDC, much to akshara's chagrin

anyways... there is no more workaround for this. using zero-latency plugs does NOT avoid the issue. basically, as someone has mentioned in regards to M4L, you incur a plugin delay for every plugin in the chain. this means that if you have 4 plugins in the chain, and the last one is a time-synced event, it will be off the grid, even if every plugin in the chain is zero-latency. reducing the plugin buffer helps but you can't completely eliminate the effect.

i posted something to the live 9 thread (a picture of this) which i won't repost here (yet), in that i've exaggerated the problem a little by using 515 bpm, but it's not difficult to reproduce, and clearly shows the issue - at that high bpm, adding 8 zero-latency IIEQ Pro effects caused the track to be almost a full beat out of sync (my buffer was set to 256). there are weird results too... reducing the audio buffer to 128 reduced the effect by more than half, to about a quarter of a beat (at 515bpm no less). So, the effect might be small enough not to bother you, but it is definitely there.

i don't think appears with internal devices; live 9 decided to make my audio devices disappear when i wanted to try it but i had already thrown simple delay in on a track, for a very high audio buffer (whatever the highest is) which showed an issue right away with iieq, and there was no delay at all with that one, so i wouldn't expect any for 8 of them either.

this also means that if during mixdown you turn your audio buffer to high values to reduce CPU, you could be making the problem worse and see issues where you didn't before.

so this is pretty bad.

That's why I have so many problems, as <I used to have big buffer to be able to load more effects.
It just shows me how much worse the PDC problem is then some people want to admit.
I must laugh when someone says he never had this problem with Live...

The PDC now includes inconstancy in being unreliable ! Very amusing...

[RCUS]

hi, i would like, ableton or people who have some informations about that, takes 1 min to enlighten me (us) please !


THANKS

WHAT. THE. FUCK. ABLETON?

You see that post above? Started on October 25, 2012. "petit nuage" was asking very, VERY nicely. It is now DECEMBER 14th and we're 49 PAGES deep and NOT ONE WORD?

All we want to know is:
1) is PDC fixed?
2) if not, are you working on it?
3) if it's not fixable in Live, what do we do to compensate, to nail it 100%, in very specific terms. I dont care if it's 300 pages long to describe, I want a step by step white paper FROM ABLETON explaining ALL the best practices, down to the tiniest detail.

srsly? 49 pages? no, srsly?

Gerhard, bro, I met you personally in LA a couple years ago when you guys played basketball against the dudes from Serato. You were a nice guy and all, love the product, but I paid for this program and I make money off this program.

We deserve an answer.

[simpli.cissimus]

WHAT. THE. FUCK. ABLETON?

You see that post above? Started on October 25, 2012. "petit nuage" was asking very, VERY nicely. It is now DECEMBER 14th and we're 49 PAGES deep and NOT ONE WORD?

All we want to know is:
1) is PDC fixed?
2) if not, are you working on it?
3) if it's not fixable in Live, what do we do to compensate, to nail it 100%, in very specific terms. I dont care if it's 300 pages long to describe, I want a step by step white paper FROM ABLETON explaining ALL the best practices, down to the tiniest detail.

srsly? 49 pages? no, srsly?

Gerhard, bro, I met you personally in LA a couple years ago when you guys played basketball against the dudes from Serato. You were a nice guy and all, love the product, but I paid for this program and I make money off this program.

We deserve an answer.

I can sum it up for you !

1st. No PDC isn't fixed !
2nd. Live 9 PDC isn't fixed too !
3rd. Live 9 PDC won't be fixed on release date and it comes worse,
as some people like hoffmann2k don't expect a full PDC until Live 10 !


What can you do to avoid problems with PDC ?
Were told to avoid automation on tracks with effects that have latency as the PDC for automation doesn't work.
Means you do something and bounce it, then check the wave, correct timing by hand and hope for the best.


Till the last post of theophilus we all thought that the audio engines PDC is working correctly,
but now we have a report that it doesn't !
Means even if you have effects on audio that do not have latency, you'll get latency when using higher buffer.
If you work professionally, then I assume you work with many tracks and also lots of effects.
You also use higher buffer to compensate the amount of effects to make them work in real time.

This whole thing makes Live unusable for such serious production and I recommend you to use Live for creation only !!!
Use another DAW like Logic, StudioOne etc... !



I think that Ableton never did know what was wrong with PDC, as they never came up on their own opening or
discovering flaws them self. There was always a user who found those things. Never Ableton !!!
All they did, was to correct the manual and add notes what doesn't work.

Looks like the guy who programmed PDC wasn't payed enough,
made it a real mess, left Ableton and went to Bitwig.

[theophilus]

Till the last post of theophilus we all thought that the audio engines PDC is working correctly,
but now we have a report that it doesn't !
Means even if you have effects on audio that do not have latency, you'll get latency when using higher buffer.
If you work professionally, then I assume you work with many tracks and also lots of effects.
You also use higher buffer to compensate the amount of effects to make them work in real time.

hold on... i think that maybe i was misintepreted. the audio side of PDC is still perfect - even with the shifts, Live sums the tracks perfectly.

however... i had previously thought that as long as you use zero-latency effects, you could do automation & tempo-based effects at the end of a chain. after a long chain, the audio stream is still compensated, but even 'zero-latency' effects cause midi clock & automation to be out of sync. not completely unusable - not everyone is using loads of automation, i guess - but that's part of the point of using something like Live, so not being able to use automation is still a pretty large drawback. if you don't use automation, you can do almost anything in live and it will work just fine. i suppose for some live performers, this could be true. as soon as you introduce any automation at all, you will start seeing weirdness i think.

note that with a small enough buffer, the effects can be fairly small... but they are always there, and with larger buffers they are glaring.

with internal live effects, i don't see any latency at all, so that's the only workaround apparently.

with pictures (and done in live 8 this time, so i can post pictures here):

this is a picture of a long chain with zero-latency internal effects - EQ8 and compressor (set up so it isn't actually doing anything, 4 pairs of those. i'm running at a crazy high BPM because it's easier to see offset into the bar instead of samples, and at that high bpm even a small sample offset shows up as a large offset into a bar - at the high bpms i was using, a beat is about 60-80 samples). this was at a plugin buffer of 2048. note that the master is way off (but still mixed correctly) because of the volume shaper VSTs plugged into the end of each channel:


this one, i backed the plugin buffer back to 128 ('as audio buffer') and replaced the long chain of eq8 & compressor with IIEQ, a zero-latency vst eq effect, on the second channel. the first channel did not go out of sync, but the second channel was quite out of sync. you can see the results here:


increasing my audio buffer to 256 increases this effect even further, as you'd expect:


one weird thing is that the magnitude of this effect is a little strange - as i noted, the pictures show us running at 673 bpm. if i did the math right, 673 bpm = 71 samples or so per beat. Even 128 samples is way more than that, yet the effect we're seeing appears to be smaller. could be we are delaying, say, a beat and a half - which is even worse. but if you go smaller (to 64 and then 32), the effect is half, and then half again, which if we were going a beat and a half, i'd expect 64 to be delayed almost a whole beat and look worse than 64, and it doesn't (didn't take that picture, and can't do it now.. have to do that later), it looks about half as bad as the 128 picture. makes no sense.

[simpli.cissimus]

.. O.K., it's half worse then expected !

[fx23]

@theophilius: mmm what math did ya use?
for me there is 44100 samples per second, so 44100*60 per minute
so beat duration in sample is (44100*60)/BPM
(44100*60)/673 = 3931,65 samples per beat @ 673bpm.. not 71 samples

edit: seeing your last picture i think grid displays a pulse per sixteenth and not beat right? so a 16th @ 673bpm is roughly 1000 samples
the start offset we see is roughly a quarter of that = 256 samples = the buffer, so seem coherent, ne?

re edit oh no it might be displaying a beat, but as i re-read you chained 4x... ok it's equivalent count is right

[theophilus]

@theophilius: mmm what math did ya use?

apparently i was going non-euclidean for the day good catch, and of course you are right. that makes everything make more sense.
so, at the high BPMs i was using, a beat would be 3931 samples like you said, so a plugin buffer of 2048 (for the first picture) should delay
the master about half a beat, and it does. everything finally looks right.

so, the absolute values of the issue are smaller, but still an issue...

[fx23]

sure, 32 sample are enough to be perceived on tighness imo, even at descent bpm

[RCUS]

thanks for responding guys.

is the delay static? so like say you have +25ms of delay caused by PDC. if I were to bounce then manually adjust with Lives channel delay -25ms, is that the idea for a fix?

I can deal with delay, timing adjustments are part of the mixing process. what I can't deal with is an entire track that flexes forward and backwards in time at random, when I need it tightly synced.

thanks again to Ableton for responding....

[petit nuage]

for a postive speculation, i hope that if ableton doesnt tell anything about it, its because it may become their secret marketing weapon to kill others competitors on the starting line ....maybe... again ..even in communication... TIMING IS FUNDAMENTAL ...

[simpli.cissimus]

I don't know why you ask for a comment from Ableton.

If they say it doesn't work, they hurt them self.
If they say it works but it doesn't, then even more.
If they say we work on it, but can't figure it out soon, then they look incompetent.
If they say we won't fix it soon, they also hurt their market and sell less.

Whatever they say, they won't look good !

The only way they can keep their reputation, is to stay quiet, fix PDC and release it.
...and that is all I ask and like them to do.
Stay quiet and fix that thing !!!
But also for Live8..., or offer better upgrade prices because of this miserable 3-year-bugfest.