it’s been told in another thread that cubase automation is dependent on the Latency card, and that if i change the latency (buffer) the automation will have different results! is that true? hope not
you can check this threads:
Thank you
Although I haven’t tested it for a while, automation drifts randomly and the drift increases as you increase the sound device’s buffer size. We keep asking for it to become sample accurate!!
In practice I’ve never noticed it but then I don’t automate anything that demands high accuracy particularly.
Mike.
is that true? hope not
Yes it’s true.
yeah depends on your latency settings, set it to its lowest before bouncing… the best you can do at the minute i think.
At 48K sample rate, a single sample is 2/100 of a millisecond. What is to be gained by sample accurate automation?
Let’s say automation is now accurate to 1ms, just as an example, since it’s not even that accurate. Increasing to sample accuracy will require 50 times the data rate to achieve. Add up lots of automation on a 200 track mix and you are placing a much greater load on the CPU. Then people begin to say “Why is Cubase slowing down so much on my large mixes?”
Why? Seriously, why sample accurate? To what end? If I exported a mix with sample accurate automation versus 1ms accuracy could you spot which was which? I sooo doubt it. For what it’s worth, automation data is already interpolated and the amount of data is reduced(averaged) for a reason. Tracking and reproducing every increment of level change at sample accuracy in a high track count mix on a 100 minute film project would have your CPU bogged down and present challenges to the system on getting everything you want done at the same time.
So please, Steinberg, do not implement sample accurate automation. Thank you.
Make it consistent (no drift) and also compensate for sound card latency? Yes.
Sample accurate? No.
that’s sample occurate, no?
No. Different issues.
Drift is likely the result of lower prioritisation in the real time threading, relative to other tasks deemed more vital, yielding slightly inconsistent results on playback. Think about the pref in your Audio Device labeled “Audio Priority - Normal/Boost”. Cubase has to have a heirarchy of what matters most in realtime and some things have to give. Automation capture/playback is one of those, apparently.
Latency compensation for automation is no different in principle than for plugins. Simply automatic, user transparent, adjustment for the variable processing time for audio throughput based on a number of variables, mostly plugins. In this case, it seems that a change in buffer size of the soundcard does not produce a corollary change in the playback timing of automation data, creating an offset relative to the initial accuracy. That also means that as the max latency in the plugin paths increases as plugins are added, that is not accounted for in automation playback either. That factor probably goes unnoticed by most testers.
“Sample accurate” only refers to the frequency (or granularity) of automation recording and playback. Drift and Latency could both be perfect or flawed independently of the frequency (and therefore the amount of data) of capture of automation data. If Drift and Latency are both corrected, timing interval of the automation data capture would be adequate at much less than the full audio sample rate.
We don’t need an automation data point for every audio sample. We just need the automation data to be accurately compensated for latency variables and also 100% consistent in playback timing. Just 1% of the sample rate at 48K would give you 2ms accuracy. Sample rate is not the issue. Latency Compensation and Drift are.
Exactly. In my youth (so very long ago, sigh) I used to design tests to see how well integrated circuits performed relative to their specs. One of the hardest things for folks to get their heads around is the difference between resolution/precision and accuracy. If you have a watch that displays time to 1/10th of a second, that doesn’t mean the accuracy of the watch is 0.1 of a second. The watch could be off by several hours (the accuracy) while still displaying time down to 0.1 seconds (the precision). For automation we need good accuracy with adequate precision.
so this afirmation is not correct, right?
“if you change your sound card buffer size, ALL your automation will now occur in a slightly different place”
and what’s told in Automation playback delayed based on latency? - #71 by r.u.sirius - Cubase - Steinberg Forums is not an issue any more?
Me feels reliefed 
Cubase automation is not “fixed”. The automation in Cubase can be inaccurate and does NOT compensate for changes in buffer settings on the soundcard.
The point “raino” and I are making is that the problem is not the data capture/playback rate (“sample accurate”). The problem is inconsistency (Drift) due to low priority scheduling and latency offsets due to failure to include PDC in the automation system.
The short answer to the original question is YES the automation timing is dependant on the latency setting. The automation actually occurs earlier than it should. The higher your buffer setting, the earlier it happens. In addition to this, there is also a small degree of variation as to exactly how early it will be as the project plays.
I usually run a very high buffer setting and yes, it is audible (which is what prompted me to do some tests). Most of the time it’s not an issue but if you have a prominent sound in your mix with drastic/instantaneous automation changes then it is sometimes audible. A partial solution is to set your buffers to the lowest possible setting when you export your final mix. Even if the project won’t play at this setting, you can still export it without a problem (although it might take a while). This pretty much cures any timing issues (You would have to have ridiculously good ears to hear any timing inaccuracies when you export with a buffer setting of 32 samples!).
The key word in ‘sample accurate’ is ACCURATE. I doubt if many people really feel the need to have automation resolution down to the single sample level but the inaccuracy of Cubase automation is an issue for some people (myself included).
Also the term “sample accurate” is a bit of a misnomer. When folks use the term they are using it to describe the precision of the automation and not really the accuracy.
Imagine we have automation that has a data point at every sample point. Then the precision of your automation would be the same as your sample rate. Now if you playback and read that automation and each automation data point is located exactly where it was when the automation was written (i.e the automation data point occurs at exactly the same time as the sample data point that was playing at the time of writing the automation). If that occurs then your accuracy will be 100%. But lets imagine that the automation data point occurs a full second after (or before) its corresponding sample data point. In that case the accuracy sucks even though your precision is still at the sample rate.
Here’s a second scenario. Your automation only has one data point for every 1,000 samples - so it a thousand times less precise. But if each automation data point occurs exactly at the same time as its corresponding sample data point, then it too has an accuracy of 100% even though the precision is different. And likewise if it is late or early by a second the accuracy is just as bad as in the first scenario.
Now in the real world you can never get 100% accurate, so the real issue is how off can you be before you can hear the difference. If the automation data point is late by 10, 20, or 30 sample data points it is still so close you can’t hear the difference. But as you increase that number you eventually will be able to hear that difference. That is the number that is important - lets call it the significant delay (and it could be a positive or negative value). It describes how inaccurate it can be before it matters. I don’t know what that amount is, but I’m sure it has been studied and expect Steinberg to have read the material (but who knows).
If the inaccuracy is less than this significant delay it will sound like it is 100% accurate even though it isn’t. Additionally there is also the issue of drift. If this delay was consistently off by a constant amount the software could compensate for it. But if it is sometimes drifts off by 2,000 samples and other times by 10,000 that can cause a whole new layer of problems because some automation data points delay might be less than the significant delay and others greater than it. When that happens your automation will never sound consistent, it will vary on different playbacks.
Finally the reason you might not want sample precise automation data is it is going to generate a lot of unnecessary data points. Processing these in turn will consume more of your computing resources, most of it wasted. This in turn leads to lower track, plug-in counts, etc. because you run out of resources sooner. Increasing the precision beyond what is needed can actually reduce the accuracy because of processing delays that occur because of the excess computing load.
ok so i forget about the term sample accurate , i ment this in the original post "inconsistency (Drift) due to low priority scheduling and latency offsets " so this is an issue cubase has and apps like flstudio don’t?
Yes!
so is there a request for that?
There’s no perfect DAW - given FLS’s lousy Plugin Delay Compensation I’d rather than sightly flaky automation! - perhaps the clunky PDC is why FLS’s automation keeps track?
no idea! i am missing automation precision specially in the Y axis, i just can’t get some kind of stuff done, because of Cubase Automation. example: takes to long for simply put the line at 0 db. imagine complex automation …
So it is a limitation for my Creativity…
Maybe you already know this but for extreme precision on the Y axis, the best thing to do is highlight the automation point and type in the numerical value in the info line at the top of the arrange page.
Necro bump but this topic is spot on to what i am experiencing in PRO8, and i am wanting to ask if anyone has seen any improvements in pro9.
Automation is very hit and miss… but it gets really bad when latent plugins are in the mix… cubase sometimes compensates the automation then doesn’t on the second pass and so on. Or it compensates a different value. I have watched and listened to plugin automation on the exact same track just playing it from the start a number of times, and the automation timing is out by a random variable each time.
I love cubase but because of this I had to go to Pro Tools for now, as 99% of the plugins I use are UAD… i have UAD stuff everywhere and the automation is really bad… With PT i did dozens of tests and it’s tight and compensates for latent plugins… It can be a bit out once the PDC reaches it’s limit, ie a really massive delay linear phase type plugin, but i don’t want to automate those anyway. The problem with cubase is, automating NON latent stuff around the very latent plugin also has timing issues.
I guess asio guard would make it even worse, but on mac, asio guard is essential.
Would love to hear of any changes in this regard… cheers!
This issue has been a huge headache for for me too and there is no improvement in 9.5.
I really want to write modulation for filters using automation to achieve some interesting sounds in synths but this is impossible due to automation events being played back differently every single time. You write events right on the grid and when you bounce them you see that they randomly hit late or early, with differences up to a couple of milliseconds. Maybe not much, but there is another variation. Each time that i play back the entire automation will be offset a much larger amount of time on top of the random inconsistent hits. For instance I press play/rec and the entire automation plays 15 milliseconds late, but then I hit stop and play/rec again and this time its 2 milliseconds early across the whole track sequence.
I work with a buffer of 64 samples and it is no way near enough accurate to do what i want. Because of this I’m not expecting that 32 sample buffer will help my cause either. I just don’t understand how automation can be this inaccurate, it’s almost useless for anything else than slow ramps.
If anyone has any ideas on what I could do to work around this then feel free to share.