As some do already know, Live is provided since V5 with an Automatic Plugin Delay Compensation System
All VSTs introduces more or less process latency. this system tracks latency introduced by the VSTs and shift/delay all other audio tracks so that all the stuff keep in sync in terms of audio content. however, it won't compensate for the 'associated to this audio' controls curves. this means that modulations, automations and global clock timing info will not be proportionally shifted of same amount of time, they will remain to their absolute on grid original position, while audio has been delayed from that same reference grid. So a new offset/drift appears beetween the curves and audio results, affecting sound. the more there are VSTs latencies and PDC process increase, the more resulting audio will shift from the original synced on timing grid curves/clocks.
Now you might not have noticed it or felt drastic pb with it because in some cases it's not perceptible: in scenario A) user uses very few or very low latency VSTs and works in traditional linear way in arrange.
He recs a first automation. Result is ok even if slightly out of 'real' sync grid, because the user has adapted itself to the low latency while recing. for exemple, he will gate each beat, but as audio is slightly begind 1.1, 1.2, 1.3 ect, he will have reced by ears compensating, and the resulting will be wrote and applyed at 1.1.+ latency, 1.2.+ latency ect. So in fact it IS out of grid, but as it's offseted of same amount of audio latency, booth remain in sync and coherent in terms of audio results. the user can go on and rec more automations based on same way, result will sound coherent at the end.(but out or real sync reference)
but.. if the user decides later to add/rem a big latency VST in front of those automated devices, the VST will shift audio but not all the previously reced curves, so the relativity of curves compared to audio is out of original wanted sync results. there are no real solutions to compensate the pb, exect go in and shift all curves.
in scenario B) User works with high latency VSTs in session mode. As working in session, he can't rec automations/modulations to clips

To summ-up that means that if you've drawn/reced some sets of critical timmed modulation/ automations, ie an FX strong applied to a note Attack event, then you should avoid altering the chain with big latency VSTs (add or remove). if you add/rem a new big latency VST BEFORE the prevous controlled devices, the already drawn/reced automated curves will be out of sync. As well if you use a native live device after the VST, it's curves will be out of sync. Same goes for timing information of synced FX such as Autopan, beat reapeat, or any midi clocked VST (ie camel Space). Hope you understood.if want a repeatable test showing the pb, you can find one here:
http://rapidshare.com/files/443477011/P ... roject.rar
So, Ableton are aware of the pb from a long time and are working on it. It's not a real 'bug' but a lack of feature assiociated with PDC concept. By waiting you might want to try to understand under lines of this pb to find the best way to work around it. here are my few tips:
_ Try to avoid big latency VST placed at some place in the chain where some devices after it will need/had critical timing automations or timing clock info.
_ If still need a high latency VST flolowed by automated devices, consider render the insert point as Audio, then keep
activated only the rest of the chain that is after the bypassed then VST. this will remove all latencies and offsets.
_ so If need a high latency Vst, try to place it at the end of the chain.
_ If you often draw Lfo/gating type modulations, worth consider using/modulating Auto-Pan instead, wich has a build-in 'offset' setting that will allow you to manually roll and adapt to introduced latency later, otherwise if using volume or other automations you would have no other fixing choice than go back in eack curve, select them and shift them manually. few other live native devices have an ofset feature. use the offset if the chain has introduced new latency to re-align device reference clock.
it can provide a real easier 'maintenance' of the liveset-sync if you are deeply and often affected by the problem.
_ prevent for using any big latency VST in front of other VST that rely on synced clocks (ie CamalSpace).
_ globally avoid drasticlly alter chains latencies over time. (add/rem devices).
_ more generally avoid as much as possible latency inducing process with live by waiting all is compensated.
Hope it can helps some. Don't worry if you worked without never noticing it, if your ears were Ok with audio, then that means
audio is OK

Hope it helps