Can Overbridge act as a Multiclock substitute?

Hi everyone,

Apologies in advance as I know sync topics are fairly tedious, but totally bamboozled by what I’m finding here, and think I’ve landed on a solution that some other Overbridge users may benefit from (albeit am expecting I’m missing something obvious…)

TLDR
Dealing with latency issues, bought a Multiclock which didn’t solve them. Ended up clocking everything via AR midi out, synced via Overbridge, with some offsets for devices streaming audio through audio interface. It’s performing better than the Multiclock at what I thought the Multiclock was going to fix for me…

Longer version
Background
My situation:

  • Use Ableton live, AR MK2, DFAM and a mono synth.
  • Was previously clocking DFAM using CV tools at the end of my master track in Ableton, using AR MK2 with OB and mono synth using external instruments.
  • This setup worked totally fine for me, all latency compensated, everything on grid no matter what I threw at my Ableton setup. I monitored through Ableton and have been able to put latency heavy (Pro-L2) plugins on my master track without any issues at all in this setup.
  • I wanted to sequence the mono synth and DFAM in more fun ways so I bought a Torso T1 and this is where the fun started with sync issues and latency…

I’ve since come to understand External Instrument in Live will compensate notes for latency, but not clocks, so the Torso is being messed up by all those latency heavy plugins I had on my master. I can workaround this for the Torso by removing those plugins. Not wanting to compromise I ended up getting a deal on a Multiclock under the belief this would sort my issue but sadly not so…

I’m fairly sure I have configured the Multiclock correctly. It’s syncing to my DAWs tempo, starting after a bar as expected. I am able to get things in time playing with offsets and the like but if I add a latency inducing plugin then I need to resync, which wasn’t what I was expecting. In addition through the Multiclock I’m finding that the first note received is early relative to the rest of the notes, despite the Multiclock starting at a 1 bar delay - I wasn’t expecting this. I understand part of the benefit of the Multiclock is eliminating jitter and offsetting multiple devices but none of that was what I needed, I just wanted to eliminate the latency issue.

I started this post looking for help with the following questions:

  1. Is it expected behaviour that a latency inducing plugin on the master track will cause the Multiclock synced devices to fall out of sync with my DAW when recording in?
  2. Is it expected that I have the first note arriving early relative to the others?
  3. The big question - if the answer to 1 is yes, why is Overbridge the only approach I can find that seems totally immune to this issue - whatever I throw at my project it is always locked in sync and dynamically updating.

Solution?
Typing this out has helped me quite a bit as it got me thinking. Now I’m trying to clock my Torso from the Rytm, with the belief/hope that Overbridge will deal with all of the latency compensation for me. The only residual issue is that Overbridge audio and the audio running through my interface suffer different latency amounts. My understanding is that this should be a fixed offset, and I can allow for this via the External Instrument.

I’ve just been trying this and it’s solid (+/- 2ms which I’m happy to live with). I’ve tried this with buffer size ranging from 32 samples to 1024 samples, and thrown a bunch of latency inducing plugins on multiple tracks. I’ve power cycled my whole setup and tried again, still good.

Conclusion
This almost feels too good to be true given I’ve never read of people using Overbridge for this purpose. In addition Multiclock is always lauded as the holy grail of fixing sync issues, it seems very difficult for me to believe that this doesn’t deal with latency inducing plugins as I’d have thought this very commonplace. I’m almost sure I’m being an idiot and misunderstanding something here.

What am I missing?!

I just want to focus on this one part. You are saying that you have it working, but then when you add a new plugin that creates some latency, and you need to resync. In this case, “resync” means adjusting the latency setting in multiclock, right? Not simply restarting.

If that’s the case, I do understand why. I believe it’s because latency compensation that happens outside of the DAW for clock signals is a bit of sleight-of-hand. What you perceive as negative latency compensation is actually positive latency compensation and it’s the 1 bar pre-roll that you mention which makes it all come together.

Why does that any of that matter? I took the time to explain it in a blog post of my own, so I’ll start by just sharing that and if you have other questions let me know (the title mentions changing projects, but the technical details are still relevant): Why Latency Compensation Must Be Adjusted Between Projects – JMK Music Pedals

1 Like

In my experience lattency with Overbridge is an issue. Not only it adds a lot of lattency directly from the plugin (often more than 20ms for most boxes), but the compensation is not consistent between sessions. Sometimes I would open my session and everything will be dead on grid, and the next it would be a few ms behind.

I couldn’t live with that so now use an Usamo and never had issues since

I just want to focus on this one part. You are saying that you have it working, but then when you add a new plugin that creates some latency, and you need to resync. In this case, “resync” means adjusting the latency setting in multiclock, right? Not simply restarting.

What I meant here is that if I get the multiclock synced and everything working okay, and then I stick a plugin with 20ms of latency on the master track, the recorded input from the synth synced with the Multiclock is now 20ms late. So to get everything back on grid I’d have to offset the Multiclock track by the same amount.

I thought the whole point of the Multiclock with the pre-roll is that I wouldn’t have to do this, and Overbridge manages to compensate for this accurately in my setup.

Right, I had assumed correctly. You wanted to know if you were missing anything, and I don’t think you are. The results you had using external latency compensation are to be expected.

The actual point of the pre-roll is to convert the positive external latency into negative latency. The reasons for which are explained in the blog post I shared, as well as why adjustments to that latency need to be made when conditions in the DAW change. Just filling in some technical detail is all.

Thanks for clarifying.

I’m quite surprised. Perhaps biased by my own use case, but for all the people I’ve seen raving about the Multiclock I haven’t ever seen this limitation noted.

I’m feeling even mores like for my use case the best thing is to use my overbridge synced Rytm as a clock source. I can route two mono synths back into Ableton using the L and R audio ins and anything else just needs to be offset using external instrument. Surprised OB doesn’t get more praise in this area to be honest. Is there any other solution that works so well for dealing with plugin latency around midi clocks?

I have seen it come up once in a while, it’s just not an everyday sort of thread. (it’s the reason I wrote the blog post)

Regarding what other users experience, it depends on use case and workflow. I suspect that a good number of users do not try to do the things that highlight the fact that external negative latency compensation will need to be adjusted, or if they do they just make the adjustment. (everyone runs into it switching between projects that have different BPM).

One thing people do try, and this is very dependent on DAW features, is having the multiclock plugin or sync track negatively offset in the DAW itself. That’ll put out 1 stream of negatively offset pulses. Then in the multiclock hardware, positively shift the pulses instead of negatively shifting them. Because the external clock is no longer having to “time travel” to get ahead of the source, it shouldn’t need a pre-roll and it won’t be as susceptible to adjustments that throw off an external negative offset, unless, of course the audio interface latency itself changes.

I didn’t want to throw all that out there at once, and frankly, if you have found a method that is good for your workflow, I see no reason why you shouldn’t stick to it and promote it where you want. Just don’t be surprised to find out this isn’t a one-size-fits-all solution.

Latency is a broad and deviously complex topic. I didn’t “dare” to mention audio buffer settings and latency because the assumption with the article is that the reader has already determined that the source of the latency develops external to the DAW/Audio Interface, and that’s why they are using an external sync box for their real-time monitoring.

If the source of the latency is more attributed to interface audio buffers, or if the nature of the workflow can be altered, like doing external real-time monitoring instead of monitoring signals back through a DAW, or whatever the case may be, then an external sync box may not be the solution that’s most fitting (or the most important). In some cases though, it is. Devil is in the details.

Thank you for all of your helpful replies. It’s much appreciated. Was aware about running the multiclock track with a negative offset and setting it to positive mode from my research, just didn’t get that it was still impacted by plug-in latency.

Also point take around avoiding the issues in the first place and if nothing else that’s been a learning experience for me from all of this that I’ve needlessly had around 170ms of latency on my master channel that I can easily workaround. Seems like starting from a base of a smaller issue is a good starting point regardless. But notable that this hasn’t caused me issues ever before because Overbridge just handles it, as does Ableton for midi notes outbound. It’s just the Ableton clock outbound which has brought this issue.

Thanks again for all the input into my questions