Ableton Forum

Thank dom for public official aknowledge. Fix pdc and autom to session then live will shine and blow out any daw for a new decade. I pers apologise for my words.u know Who loves hate.
But personally i always called it a flaw, not a bug.
Good news if you think you can fix it.

LoopStationZebra wrote:Those claiming it was a bug may want to offer a mea culpa now.

please chill on the shit stirring, it's getting to be really annoying.


dom - class, thanks.

good thread, spot on ninox.

oh my.. peace and harmony.. everything is good again.. just one word that they know the problem gives hope..
halejula.. you see..its much better to comunicate problems than brushing them under the carpet...

But one question,
is it true that ableton allways stated that automation and screen display is not latency compensated?
i am just currious because there was so much discussion about that.. so one wonders that so many users wasnt aware of this old statements.
So when was this stted the first time and where?

and 99,9 % aware of all bugs and problems ???

ok.. this might be a bit overstated because i found at least 3 or 4 real bugs you wasnt aware off and problems? when i recall it wright i even called the absence of an utility plug in a problem at times where this was still absence...
So with your given 99,9% figure the total amount of bugs and problems must be something inbetween 3000 and 4000...

but ok.. well possible with a complex program that just adds layer after layer of new functionality...

Tone Deft wrote: please chill on the shit stirring, it's getting to be really annoying.

It's a joke, c'mon

I know, I know. I've done it too but this stuff gets to be contentious as it is. I'm totally being a hypocrite too.

it's just nice to see a bug explained, for users to agree and check it out and for it all to be confirmed.

personally, if it was a vapid "Live sounds like crap..." thread, whatever but there was some meat to this one.

Happy motherducking Friiiiiiidaaaaaaaaaayyyyyyyyyy!!!!!!!!!!!!

Tone Deft wrote:Happy motherducking Friiiiiiidaaaaaaaaaayyyyyyyyyy!!!!!!!!!!!!

In 15 minutes its saturday here, and then 3phaze shows up. Uh oh .. Haha. (your ok dude, I just need some sleep now )
Yeah, this thread was an eye opener in many ways. Thanks all, and also Dom for keeping it real.

Thankyou for the reply Dom. If I was going to get any response it is of the sort that I expected. Unfortunately it doesn't help my situation. I think the points I've raised need to be clear. I've said them already but after nine pages some of it is bound to get lost.

dom wrote:Therefore ninox_rufa is pretty spot on in the descriptions he posted in this thread and we also confirmed this to him via support emails months ago.

When I reported it 13 months ago I thought it was a 'bug' that was specific to third party gating. Ableton staff confirmed that it was a 'bug'. I accepted that I just had to work on other areas of production until it was fixed, which I expected could be a long time.

Due to the misleading statement in the manual I had no reason to suspect that the so called 'bug' I reported was actually a very important aspect of latency compensation that Ableton decided not to implement. Had I known, I would have understood it could potentially take several years to fix. I would have stopped using Live for production.

dom wrote:What it does not, is compensating automation or what the Live GUI is showing (moving meters etc.), just as we always stated.

Whilst it was frustrating to discover this aspect for myself it's not a major problem. Although automation compensation is a related topic it's clouded the issue. In retrospect it was best left out of this thread. I shouldn't have mentioned it in my first post. I think you are stretching the truth here though. It's not in the manual and that's the one place it really needs to be in order for you to make such a claim.

dom wrote:Live does not offer this feature yet, just as it does not offer automation compensation - and both are pretty huge points on the feature wishlist.

I don't see the polling issue as being on the same level as automation compensation or any other feature wish. Whilst no automation compensation is a disappointment it is not in direct contradiction with the manual like the polling issue is.

dom wrote:we folks here at ableton also still use live just as you all do and if there are shortcomings, then you can be 99,9% sure that we know of them and that they bother us, too. maybe even more, as we're sitting on this side of the screen.

I didn't know about it though which puts me in quiet a different situation.

dom wrote:What also already has been said is that as long as those delay compensation features are missing, we have to work on the manual in order to explain the situation better as it is confusing to the customer right now. And this came personally from the man who takes care of the manual, so we can trust this statement (viewtopic.php?f=1&t=129443).

I remember this thread well. It appeared around the same time I discovered there was no automation compensation. There have been quiet a few Live updates released since. Yet no change has been made to the manual.

It is not a case of explaining the situation better to alleviate confusion. It is a glaring omission.

The polling issue makes Live unsuitable for people producing a similar style of music to mine. I think they should be made aware of it before investing their time.

It has a dramatic effect on the quality of production. A huge number of plugins are affected by it, not just CS and Beat Repeat. By continuing to leave this out of the manual you are making claims about Live that simply are not the case.

dom wrote:But as always with Ableton products - we can't make any promises or announcements regarding the timeframe for this. Sorry for this.

I understand your reasons for doing so. Of course Ableton will prioritise keeping improvements secret over helping a customer that it's misled. I trust you understand the position it puts me in.

It is not a case of explaining the situation better to alleviate confusion. It is a glaring omission.

The polling issue makes Live unsuitable for people producing a similar style of music to mine. I think they should be made aware of it before investing their time.

The issue has a dramatic effect on the quality of production. A huge number of plugins are affected by it, not just CS and Beat Repeat. By continuing to leave this out of the manual you are making claims about Live that simply are not the case.

LOL It's funny that he quotes a post from over half a year ago stating that they will put it in the manual right away, as if its proof that they are "jumping right on it". Like you said. It's still not there, after many updates.

I mean delays in writing code are justified. I understand that. But delays in writing... writing? No excuse.

ninox_rufa wrote:
The polling issue makes Live unsuitable for people producing a similar style of music to mine. I think they should be made aware of it before investing their time.

What style of music do you produce?

I'm not sure how Ableton runs (or really even how big they are), but with many "small" software companies, the people writing the manuals are the people programming. So for the manual to be rewritten, it would take time away from adding features, fixing bugs, etc...I do understand your point though.

EDIT: I'm not blindly defending Ableton by the way - I'm just letting you know that there may be viable reasons why the manual hasn't been fixed.

Are you joking? The guy who actually writes the manual took the time to post in the thread and specifically said "it needs to be in the manual". In the time it took him to write multiple detailed posts on this forum about the issue, he could have actually updated the manual!

Your excuse is ridiculous.

Thanks to Ninox

#1 for bringing this problem to light... again. Some of were not aware of this issue. (just dont use beat repeat/ lfos etc).

#2 - for correcting my post about possible workarounds (that do not work - oops sry)

Anyway... good to have this info

There are work arounds for all of this, but they are a bit horrible.

Bounce the audio after a non-zero latency plugin where you need tightly synced processing following it.
But as a work around it allmost equivalent to saying bounce the audio and work in something that can do tight sync (cubase for eg and I guess logic etc).

Thanks arafel. I don't want to seem like I'm out to correct your post again but I think it's important to highlight that the polling issue (or whatever we want to call it) seems to have never been raised before. The post by nopattern was informative but I couldn't see that he mentioned it anywhere.

dazzer wrote:What style of music do you produce?

Psychedelic (don't like to use the word psytrance anymore ). I suppose I'd describe it as something like a cross between Shpongle and Zen Mechanics but not as intense. I'm a long way from releasing tracks though (you might have picked up on that somewhere in this thread ).

Though I think you'll run into the polling problem in slow tempo music if you're using fast gates/stutters or LFO's with square waves or steep curves.

khazul wrote:There are work arounds for all of this, but they are a bit horrible.
Bounce the audio after a non-zero latency plugin where you need tightly synced processing following it.

Sorry that's one workaround singular and while it's technically doable it's so far from being feasible that I could not call it workaround.

ninox_rufa wrote:Sorry that's one workaround singular and while it's technically doable it's so far from being feasible that I could not call it workaround.

OK - yes - one workaround that can be applied to any of these problems, or each problemm has a workaround and so there are many? - Point of view


But still better than ending up with audiably out of sync effects and sidechains etc?

This isnt something that is going to get fixed for a long time. (Quite likely for reasons Ive speculated in an earlier post - ie needing a major redesign of core aspects fo live).

I would still vote for some mechanism in Live thatt helped users to work with the limitations, for example - a means to see the actual current latency through any native or third party plugin.
Or even a means to see the latency from source to output of a particular plugin, so when people hit this without realised that is going an and stop wasting time try to fix thing in the wrong way, they are instead given the information to help them undertand it (assuming they are able to from such information), and then make the decision to split chains and bounce audio etc.

The obvious thing being to add a plugin info dialog to the the right click menu for a plugin, or even to display it in the helper text at the left side as you hover over it the title bar area in the effects chain.

For example:
Live Compressor
Plugin latency: 440 (10ms) (Compensated)
Source to input latency: 44 (1ms) (Compensated)
Source to sidechain latency 440 (10ms) (Not Compensated)

Something like that would tell you you are never going to get your sidechain compressor to work as intended without bouncing for eg instead of messing around for ages. (I have never actually tested if cross tracks rotes like sidechains are compensated, but am aware of wierdness at times, so guess it now needs testing).

Or pehaps even bettter - export a complete plugin chains report as an HTML file or whatever?

I know, still nasty, but its more of a headache having to load up cubase or perform some kind of latency detector routing test to understand why something doesnt sound right.
From my perpective, this thread and the test we have done means I now understand a possible reason why I have about 30+ half done tracks that just sound wierd and unfixable and so got abandoned - now I can go revist them and maybe sort some of them out, so its still a small step forward, even if it tellme it might be worth the pain of trying to unravel them and recreate them in cubase instead (notte to self - dont use live plugins, even the really good ones in case this becomes a regular activity).

Khazul wrote:But still better than ending up with audiably out of sync effects and sidechains etc?

This isnt something that is going to get fixed for a long time. (Quite likely for reasons Ive speculated in an earlier post - ie needing a major redesign of core aspects fo live).

No way. It's just not feasible. There's a multitude of reasons why. What if you want to make effect changes to two different plugins at the same time?
You'd end up with hundreds, possibly thousands of audio files for a project. Imagine trying to manage it.

I don't think it's a major redesign. I think it's something they've planned to implement for a while. They've no doubt mapped out improvements they plan to make several versions ahead. It certainly won't take a long time if they've been working on it already. That's part of my point. They know where they're up to.