Ableton Forum

yup most people aren't aware of that cause they use low latency vsts and aren't focused on tightness of music.
and they add vsts slowly, so they don't catch the mix slowly but surely increment messy shuffle and end up totally out of sync
compared to original modulations, but it's clearly noticeable if you use advanced routings and lot of vsts or just simply use a linear phase EQ or high latency big buffer vst.

i was suspecting live compressor in 10ms would behave the same but no, it behave correctly, i just tested.
this is real good news cause that mean they CAN already offset audio+related controls correctly.

my conclusions are Live internal devices correctly reports latency to mod/aut/sync, but absolutely not any 3rd party VSTs.
this doesn't mean internal are free of problems, because even if you use native devices, if they are after a vst, they will fatally end up being out of sync, wich personally happen and is clearly noticeable in every liveset i do from years and start to piss me off.I sometimes end up to a point i need to manually shift my automations to limit audiofuck, disablig grid, and it's total non workable nonsense imo, especially when they claim the contrary...
so.. in live we draw instead of tweaking knobs, and manually shift when we add pluggz. what a cool basic workflow.
PDC is imaginary , it's not working at all. they know it from years, no need to report.

so abes, add this one to autom to session years old flaws you should fix to get a descent pro standing,
by waiting don't try to claim live is tight, cause certainly it is not...neither try to sell us ADC or 3rdparty concepts.

oh, and any fanboy that claim the contrary is welcome to do the test by themself and report their results..
http://rapidshare.com/files/443477011/P ... roject.rar

Thanks Tone Deft. I think it's very important that this thread stays on topic. I don't want to see the issue get lost in a sea of general complaints about Live's sound quality.

I don't have a problem with Live's summing and it's not what is being questioned. Live's summing is a very different issue. It's subjective, much harder to test and is susceptible to bias.

On the other hand the sync issue is an actual fault with Live. It's easy to reproduce. It's easy to see how it ends up ruining your production. And Ableton have lied about it in the manual.

fx23 wrote:yup most people aren't aware of that cause they use low latency vsts and aren't focused on tightness of music.
and they add vsts slowly, so they don't catch the mix slowly but surely increment messy shuffle and end up totally out of sync
compared to original modulations, but it's clearly noticeable if you use advanced routings and lot of vsts or just simply use a linear phase EQ or high latency big buffer vst.

Thanks for you input fx23. I hope people are reading this thread and are starting to see how big this problem is. It's likely that people who are new to Live won't notice it in their production. Unfortunately you don't until you get in deeper, your chains get more complex and your track count increases.

I'm thinking it's the main reason why people feel that their production in Live just doesn't sound any good. All their tracks containing 'clock reliant' plugins are slightly out of time and the result is poor, but it's not bad enough to make it obvious what the problem is.

ninox_rufa wrote:I'm thinking it's the main reason why people feel that their production in Live just doesn't sound any good.

hey now, my shit sounds good. I don't use third party plug ins for Mastering though, I get the sound tight on recording.

I should post the new stuff, been lazy.

+1

fx23 wrote:i was suspecting live compressor in 10ms would behave the same but no, it behave correctly, i just tested.
this is real good news cause that mean they CAN already offset audio+related controls correctly.

my conclusions are Live internal devices correctly reports latency to mod/aut/sync, but absolutely not any 3rd party VSTs.
this doesn't mean internal are free of problems, because even if you use native devices, if they are after a vst, they will fatally end up being out of sync,

OK - now this *is* getting wierd and need to clarify something.

Today Ive done some tests with Live plugins and 3rd party VSTs and observed the following:

1. Automation of a device thats later in a chain that a non-zero latency plugin today allways have the wrong automation timing according to the latency of the plugins preceding it. This applies to both live and VST plugins.

2. Audio only tests through non-zero latency Live or VSTs plugins today were allways sync (despite that I know this is not allways the case, and since we have start to discuss this issue, I have realise that some of my beleifs about return track only falling out of sync when there is the possibility of a feedback loop are not true either - they can fall out just randomly.

I say 'today', because Im coming to the conclusion that actually this behaviour isnt consitent and so its quite possible that some aspect of this will change again when I next try it (on the same version with perhaps even the same set etc).

Ignoring the inconstency for a moment, then I guess its useful to clarify some things:
1. Can live ever get the audio path compensation correct for both Live plugins and 3rd party VSTs?
- I beleive the answer is yes.

2. Can live ever do correct compensation for automation that account for the audio path latency?
- My experience says no, but reading your post it suggests that it can - can you clarify this (in case I misread - late and tired)?

3. Can live place the play line in the correct place relative to what you are hearing?
- My experience again says no and that it doesnt even try to.

In case it makes any difference, in live preferences I have plugin buffer size set to use whatever the audio interface uses.

So item seems that both 1 and 2 are possible, but are inconsistent - ie buggy. Also worth highlighting that many of us have the same VSTs, ive tested with CamelSpace as that was mentioned. I dont have a licensed Pro-Q or Pro-l (just dead demos) but do have latest timeless, volcano, and Pro-C.

On and off I remember having issues with the relative timing of the sidechain signal (vs the through signal) into lives compressor, but at the time, didnt really think about it and have since got into the habit of nearly (but not allways) allways using it on 0ms look-ahead. Now I think about it, I am actually wondering if that is inconsitent as well - I do have some stuff in progress where I know I havent set it back to 0ms and they are OK. So it seems i/we need to work out a conclusive easy to observe test for that as well.

While at it - perhaps time to revisit the exact behaviour around return with and without pottential feedback loops (ie where aduio from a return directly or indirectly can be sent through the same send again).

If nothing else, it might save quite a bit of messing about just understanding the level of brokeness here - whether or not ableton ever acknowledge/fix it is an entirely different issue

Mmmmmmm to be honest ive been a bit fast and rude
well i have to apologize to the abes and i shut a bit my mouth
the concept is indeed virtual as
it seems no DAW on earth has such system from what i read.

no PT
no Cubase
no Logic
no pyramix
no DP
...
seem to have real full latency compensated automations yet

they all have same PDC false claims but when it comes to delayed automation all seems to fail or reach limits. (any user please condradict by a test if possible..)

WT.. we will need to adapt to this, at least maybe a sligth enlighting on how to try to avoid..

arf noooooo there must be a solution...my intutition tells me it mathematically is possible, it's organised delays and offsets, but what it implies technically is certainly huge for beeing not achieved yet in any daw..

Abes you can code that, say you can!

Tone Deft wrote:

ninox_rufa wrote:I'm thinking it's the main reason why people feel that their production in Live just doesn't sound any good.

hey now, my shit sounds good. I don't use third party plug ins for Mastering though, I get the sound tight on recording.

I should post the new stuff, been lazy.

Of course some people may not be significantly affected by the issue. I suppose I should say you'll be okay producing in Live as long as you:

1. Don't use third party plugins. Especially on long chains.
2. If you do use third party plugins make sure they're not the gating/stuttering/LFO type. If you do, make sure they're first in the effects chain. You'll still get sync problems but they might be slight enough to get away with it.
3. Don't write music with a quick tempo.
4. Don't record/draw in automation that creates sudden changes in sound. If you do, then slightly move all of it backwards to get it in time. Make sure the parameter you're automating is on a plugin that's close to front of the effects chain. Do not add or remove effects from in front of this plugin once your automation is in place. And under no circumstance should you change your buffer size because you'll have to adjust the automation in every single track.

So if these rules don't apply to you and you're confident you're not going to change your style of music then it's probably use Live.


The important thing is:

This problem will likely be affecting your production (not you specifically Tone, I just mean everyone in general). It's simply a question of how much. You may hear it straight away. You might not hear it until your track is near completion. Maybe it'll only be subtle enough that things just don't sound quiet right.

Every third party plugin you add to tracks (that have other 'clock reliant' plugins on them) will bring you one step closer to writing a song that is going to fail.

fx23 wrote:it seems no DAW on earth has such system from what i read.

no PT
no Cubase
no Logic
no pyramix
no DP
...
seem to have real full latency compensated automations yet

I tested CamelSpace in Logic over a year ago when I reported this problem to Ableton. In Logic I put half a dozen plugins in front of CS. The timing was perfect.

Regarding automation:
I didn't phase test delay compensation of automation in Logic. Even if it doesn't completely phase cancel it's still tight enough not to be noticeable in a track. There is definitely some sort of compensation occurring. Live's timing is out by a long way.

with all due respect, our opinions differ on this topic.

1. some plug ins have zero latency, Live could very well get the delay on some correct, others are hosed but if they are your ears should pick up on that so why use them?

2. disagree. I don't see the connection.

3. totally disagree. this is just audio, it's not a fast signal, it's not rocket science. tempo has nothing to do with how the audio is processed, it's just 48,000 samples of audio being processed regardless of the tempo. this is the year 2011, basic DAW DSP algorithms have been studied for decades.

4. disagree. but why would you record automation that doesn't sound right to begin with. see the last sentence in point #1.



not trying to argue, just showing the other side of the coin.

in an ideal world I could teleport into your studio, you could show me your issues as clear as day, I'd agree or vice versa, you hit up my studio. we can't do that so we sit here like the blind men describing the elephant to each other. another catch is that we all use Live in different ways. I believe some people don't get crashes because they just happen to avoid certain commands, same with third party plug ins.

even though I disagree, I accept your opinion and this could all lead to Live being a better product. I haven't tried to reproduce your bug but it sounds very plausible.

fx23 wrote:it seems no DAW on earth has such system from what i read.

Well I gues it does place a huge burden on automations - imagin 50 automated parameters, each needing delay compensation at sample rate, in addition to the audio delay buffer - thats alot of memory for compensation buffers.

A more efficient approach might be delay buffer that work considerably below audio sample rate, but are quantized to a compensated musical timing clock. Would mean auomations cannot be sample accurate except around musical timing incrments (for eg, beat etc).

Reminds me - allways thought it would be nice to apply swing to an automation

yeah i think it's Cpu not free, but the offset could be of same resolution of actual automations, with is far lower than sample accurate i feel. im not pretending it's easy, but i see it as a variable read index offset simple addition in terms of coding.
offsets would not constantly beeing computed, only when chain change.
the curves arrays have to be read anyway, so rolling the readindex doesn't seem cpu violent...
however the complex tracking of devices orders so each automation get an offset computation must be harder to deal with.
just though.

I would be happy with some more option in modulations as a pre workaround, like a manual roll/shift value to enter,
so keep drawing on sync grid. would help to 'semi solve' this issue.

Tone Deft wrote:in an ideal world I could teleport into your studio, you could show me your issues as clear as day, I'd agree or vice versa, you hit up my studio. we can't do that so we sit here like the blind men describing the elephant to each other. another catch is that we all use Live in different ways. I believe some people don't get crashes because they just happen to avoid certain commands, same with third party plug ins.

Absolutely. And at the end of the day it takes so long to type and explain something like this that compromise for detail has to be made because I'm sure none of us want to make a career out of this thread.

Tone Deft wrote:even though I disagree, I accept your opinion and this could all lead to Live being a better product. I haven't tried to reproduce your bug but it sounds very plausible.

Please do the simple test. Your reply to number 1 shows that you may not fully get the nature of the problem.

1. AFAIK Live gets the delay on all third party plugins perfectly. Which in itself is excellent. But this actually is what inadvertently leads to the problem. It has nothing to do with the latency of individual plugins per se. Live correctly adjusts the timing of the audio in the track, but it does not adjust the timing of the gating/stuttering/LFO etc by the same amount. The timing of the 'action' of these plugins is out of time with the audio. The action of these plugins occurs as if the total latency of the track is zero. Live's own plugins suffer this fate.

2. If you do the test I outlined in the first post you will see exactly what I mean.

3. You've overlooked a basic fact and I'd like to point out that you're verging on sounding a little condescending . It has everything to do with tempo. The length of a 16th note at 145BPM is much shorter than the length of a 16th note at 120BPM. Eg If a band is playing a slow song it doesn't sound so bad if they're timing is a little bit out. However, the faster they play the more they've got to be perfectly in time for it to sound good.

4. Let's say I have a utility plugin that's last in a chain which contains several third party plugins. I want the volume to go from -35dB to zero at the start of a bar. I draw in that automation snapped to the grid. Live will fail to replay that automation at the correct time. In fact it will occur earlier in time than it should. How much earlier will depend on the total latency of the plugin chain. It does not take many plugins in a chain at all for this to sound like sh*t.
Hence the same applies to recording your automation. You record it. It sounds good. Then you add/remove/reorder your plugin chain. Result is automation will no longer occur when you want it to.

ahhh thanks for the custom advice. I read and post at work so my attention isn't always focused. the forum is a break when I'm tired.

sorry to sound condescending, I agree. it's the years of discussing this stuff, many times people overthink audio. you sound like a total straight shooter, I look forward to your continued contributions and most importantly your patience!! LOL!

Tone Deft wrote:ahhh thanks for the custom advice. I read and post at work so my attention isn't always focused. the forum is a break when I'm tired.

sorry to sound condescending, I agree. it's the years of discussing this stuff, many times people overthink audio. you sound like a total straight shooter, I look forward to your continued contributions and most importantly your patience!! LOL!

Wish I could say the same. I've got a business now so posting eats into my time unfortunately. I do miss not getting paid for browsing the forum anymore

I hope Ableton get it sorted. I'm trying not to bash them too much in this thread. I choose Live for a reason. It's superior to Logic in so many ways but this one problem has surfaced and it's become a brick wall to production. I've invested thousands of hours in this software. If Ableton had been forthright about the limitation I would have stuck with Logic no matter how much I love Live.

ninox_rufa wrote:
I tested CamelSpace in Logic over a year ago when I reported this problem to Ableton. In Logic I put half a dozen plugins in front of CS. The timing was perfect.

Regarding automation:
I didn't phase test delay compensation of automation in Logic. Even if it doesn't completely phase cancel it's still tight enough not to be noticeable in a track. There is definitely some sort of compensation occurring. Live's timing is out by a long way.

ok i beleive you, arf don't wanna move to apple and logic . Abes save me
they seem to push some events toward to avoid delaying to much others but im really impressed if compensate all the stuff.
need to check, but i also read some reports of non-working automation compensation..so gonna try to test that.
for Cs that means that at least the vstcycletime keep sync all over the chain so all individual vsts reports latency corectly.
wich is already quite huge change in terms of results.

if logic manage we have more escuses to ask for that hehe