Automation playback delayed based on latency?

i’m almost wishing i had not discovered it… i thought of a way of automating a mute event using a plugin locked to tempo using an lfo so that the sound cuts out directly on bar… … i’m going to test out how well that works.

doesnt exactly help with everything else! :frowning:

Is this a Cubase-specific issue or do other hosts also have this problem? I heard Logic doesn’t do sample accurate automation? What hosts don’t have this problem?

well I never knew this, explains a few things!

–1 !

Cubase has been doing audio long enough to be competent at it. This is the 21st century, there really is no excuse!

I always wondered if this was happening but never got round to testing. My issue is that when my computer is straining under the weight of a track with lots going on I often have to take the latency down to ease the pressure. This has obviously been throwing everything out! That’s surely not right…

Stumbled across this thread - that’s shocking indeed :open_mouth:

I’ve realized already that writing automations in projects including high latency plugins won’t give me a realtime experience while writing. That’s why I control/refine the results in another listen-only pass. But this definately shouldn’t change with soundcard latencies and not at all on export. That’s nothing but ridiculous!

Just re-checked it myself with mute/volume/eq automation @ 48 samples vs. 1024 samples. I get the same results as Xtigma. Very obvious and clearly visible with mute, hardly visible with volume/eq, but the two exports don’t null out.

Feels like 1999 :imp: This has to be fixed ASAP. A current DAW should compensate for stuff like that automatically. I actually assumed it already would… the issue explains some moments where the eyes fool the ears.

I hope Steinberg fixes this. I don’t want to be thinking about latencies and delays. If there is delay compensation, it must work for all data on tracks.
Anybody got any reply from Steinberg on this issue?

A request for latency compensation for automation should be posted asap in the suggestions section of the forums.

@ Xtigma
Since you were the one to find out, the honour should be yours. :mrgreen:

Edit: Lack of latency compensation during bouncing would even rather seem to be a bug and not a missing feature.

would you consider it a ‘feature request’ or a bug ? :slight_smile:

Steinberg promoted bug 15166 to a feature in 2010. So a feature request would fit the companies route.

There is a bit of a grey area as far as, should this be a feature request or a bug, first i’ll explain the ‘issue’ and repro steps

ISSUE
any automation written will play back (and bounce down!) differently based on the latency of the project

Reproduction steps

  1. open new project, add an audio track, set your audio latency to it’s lowest value
  2. add an audio event (noise… music anything)
  3. automate a mute event on this channel
  4. bounce (export) the section around the mute event
  5. change audio latency to something higher, like 16ms
  6. bounce (export) the section around the mute event
  7. import both new audio channels into the project and it will look something like this…

this was quite concerning to myself and the majority of users that have seen this photo and reproduced these steps, most users felt there was something ‘wrong’ with the automation sync but couldnt quite put their finger on what it was… this should make the ‘issue’ a lot clearer.

I beleive this to be a significant ‘issue’ because it means your project mixdown will sound different based on the latency set.

the latency should not affect the playback of the track (in my opinion)

it seems that most people diddnt know this happened… personally I have had a suspicion for a while, this is why I have been compensating my automation, but by ear.

decided to post as a bug,

that previous feature request was for sample accurate automation (which is what we want) but what we really want is for automation to be latency independent.

might technically be a feature but i’ll post as a bug for now

Clearly this is broken.

this has to be adressed with priority!!!

I agree.

Not broken but by design.

im not sure why you would say it’s by design, there’s no possible scenario where this could be seen as a positive thing

Not by design, not broken, more likely… just overlooked :confused:

I’m saying that something would need to be programmed in a similar manner to how MIDI delay compensation was created.

Basically the DAW has become “too big for its’ boots” and now requires re-design in some critical areas, ie not just in the mixer department but also in relation to “core functions” not those the end user might be familiar with but what actual processes the system undergoes.

yes agreed… i dont think this would be an easy fix! it’s probbly a soundengine thing

Yes. So now we must rail against an empire who have taken our money and given little in return bar the most stable DAW on the planet, even for .0.0 releases (if you can handle removing preference every other day) :confused: :sunglasses: