I’ve been setting up my Analog 4 MK2 and I am using OverBridge to trigger pattern changes using midi notes in Cubase. My interface is an RME HDSPe AIO, both the RME and Overbridge plugin are set to 64 samples and I’m using a sample rate of 48K:
How many passes have you recorded? Maybe what you see is jitter, so sometimes it’s a bit early, sometimes late, sometimes pretty much on point.
How was the analog recording synced to the DAW?
I use Bitwig, not Cubase but I would assume the concepts are similar…
What I gather from this image is that the Cubase plugin latency compensation is doing it’s job and aligning the audio from the OB plugin, but in the process is pulling the direct from RME interface audio back in time as well. Does this happen when there is no OB plugin loaded?
I would look at what there is is in Cubase settings for the equivalent of a recording offset setting and try adjusting that + - 12 ms either way and see what happens. Or perhaps there is a way to do this on a per track level?
In Bitwig, to align multiple slight variations in timings from external hardware, I have set up groups of tracks as my inputs, and using the time shift tool on those groups, I then route my audio from those tracks to the tracks that I directly record. A bit clunky but it works well for ensuring all sources are printed as precisely on grid as is possible, despite minor jitter and such.
I would consider in most cases, any more than 1.5ms of jitter to be excessive and indicative of a problem with synch, or just poor timing within a particular device.
Just want to call attention to what NRain pointed out here:
I see by way of google search that for VST latency compensation, cubase (by default) adjusts the positioning of all tracks simultaneously.
“Cubase’s delay compensation automatically adjusts playback timing to account for delays introduced by VST plugins, ensuring all tracks remain synchronized even with varying plugin latencies. This feature is enabled by default and works throughout the entire audio path.”
"Cubase calculates the total latency introduced by all active plugins on each track. It then adjusts the playback of other tracks to match the track with the highest latency, keeping all tracks synchronized. "
So just looking at this from an outside perspective, it sounds as though one of the tracks (maybe OB) has a very high latency and part of the compensatory action pulled the track with the lowest latency back on the timeline to before the event itself.
I don’t have any cubase experience, so you’ll have to figure out on your own whether or not this is what’s actually going on. I would expect it to be implemented in the virtual positioning of the playhead (per track) rather than the actual positions of audio events on the timeline, but it is behaving in a way that makes it difficult to rule out the compensation behavior as the culprit.
I will be interested to hear the results, it’s always good to understand how these problems occur.
Check out this feature in particular:
Constrain Delay Compensation:
This feature allows users to minimize the latency introduced by Cubase’s delay compensation while maintaining the sound of the mix. It disables VST plugins that introduce high latency for certain tracks during real-time recording or playback.
I think it may allow you to get a more realistic look at how much the timing is being impacted by the compensatory feature because you can compare recordings with it disabled against the ones you’ve already done.
yeah super weird, seems like a cubase thing though, check this out:
Similar, I think.
I’m reading stuff on google about there being ASIO latency compensation settings as well as recording latency compensation settings. Is the -600 sample offset part of the recording latency settings or are you doing that manually?
I assume you did it by the same method described in that first post that I linked:
"Navigate to Studio => Studio Setup => Audio System => Record Shift
Over there, you have to enter negative figure of some sort - don’t be afraid of using crazy figures here, e.g. -2550 samples (which is exactly what worked on my end)."
For midi events recording early I found something about the audio and midi timestamps potentially having an impact, so not sure how it would effect you specifically but if you’re using the option called “use system timestamp” might be worth seeing if it also has the reverse effect, somehow, dependent on settings?
Interesting, I’ll do some experiments and report back the results.
