Midi Sync Showdown! My mind is COMPLETELY changed...

TL:DR I don’t think under 1MS matters unless you’re trying to hit 2 same sounds at the same time, ask “does it sound good?” Good! Now hit record ❤

Thanks for that awesome video Ricky, nice come back from the last one :)) This is a complex subject, but let me give my professional opinion. * What you are comparing is (A) the MIDI clock generated by Ableton and (B) the clock/pulses generated by the multiclock VST plugin. -> For now let's ignore any additional latency/jitter created by the multiclock device, by the playing device (digitakt), or by the audio interface (we can assume they are very low). * I'm sorry to say, but the MRCC has nothing to do with any of this - it just forwards the clock generated by Ableton (and I'm sure it does it well) * What we want is precision between (A) or (B) and the DAW timing, which is the timing the analog audio is being sampled by the audio interface * Let's look at (A): on your computer, it runs in a different thread/priority than the audio stuff, so as soon as your CPU gets busy, it won't be called "in time" and that will create jitter and latency. On top of that it is transfered over USB-MIDI, which does not have the highest priority either - so also extra jitter if the USB bus is busy (lots of USB devices for example, big data transfers, for example) * Let's look at (B): it runs in a VST plugin, which is processed not only real time with the other audio stuff, but more importantly the generated audio pulses are in perfect time with the other audio coming out of your DAW. So inherently the audio pulses you send to the multiclock are in perfect time with the other audio coming out of the DAW. Any jitter/latency using the setup (B) is therefore from the stuff we ignored, i.e. within the multiclock itself, or from the playing device, or from the audio interface. Now will OSes and DAWs get better so that nobody will need this kind of complex setup anymore? Yes I bloody hope so, and U-SYNC is the first step towards it. Simon

So many years and this is still a problem…

Hey Ricky, been watching your videos on the MultiClock that I also heavily use. Love your channel and your approach! The power of the Multiclock, is being able to shift things in time with knobs until it "feels right" and then hitting record. To me it s priceless just for that! Every plugin you add, also EQ s being changed to Linear phase etc will affect the timing of everything including the Multiclock as Abletons internal latency will be affected. Just setting it once and expecting it to stay in sync is not achievable IMO. Often I check it s tight and then adjust by feel so the groove feels better than 100% on grid, very often do this on bass synths and toms. Don't sell it, you will regret it!

I highly appreciate your further research (and extensive video production) on this topic. Let‘s hear for the real Pros..

Thank you, Ricky, for the information you provided. I have also been researching for a few years how to optimally synchronize onboard devices with the computer, and I have come to the realization that latency cannot be completely "overcome," but different approaches can be used, as you mentioned as well. In your specific case, I believe the drift is caused by the computer itself and not by the multiclock, because of software record input monitoring enabled. For an optimal "latency-free" and rec.overdub experience, I would recommend an onboard mixer with direct monitoring on each channel to avoid internal processing as possible. Regarding browsing presets using with the multiclock, I have sorted it out by installing VSL Server on the computer and offloading all my plugins from the DAW process, thus eliminating any processing that could affect the out clock from the DAW , and I can say that it works really well. Zero drift and phase issues with live tracking and overdub recording. Best regards, Robert Trifunovic

Gotta go old school on sync; workstation is master clock, all midi and audio clips consolidated into long sections (especially in Live), use automation over patch changes, use lots of pre roll, render or dump all midi parts to audio and immediately edit for sync. Abandon all illusions about MIDI - only audio recordings are ‘real’ and in sync. Put video on separate MIDI TC slave system. Finally, use tempo sync’d delays as a reference only. Once you know what you want delays to do, set times manually or with automation and let them free run. I hear that recording the cowbell from an 808 onto track 23 of a Studer ATR can drive the arpeggiator of a Juno 101 pretty well…

Device jitter, and small variable clock offset, is something that will always exist with the midi protocol. The midi message bytes are sent serially and received using a buffer which is then processed by the microprocessor in the device. That thing runs at its own clock rate. So a midi clock message will never be processed instantly when it arrives. The receiving device still has to figure out that it received a clock message and act accordingly. In other words, the Multiclock can sort of transmit the clock message in sync with a sample, but nothing can interpret that with sample accuracy because of how the midi protocol works. I think the accuracy might also get worse if you send additional midi messages like CC over the same port.

And THIS is why I'm dawless now when it comes to loop-based, synced music that requires a great groove to work. What a disaster.

Most desktop computer operating systems are technically not real-time OSes so they will always be affected by CPU. A real-time OS (RTOS) is designed to work within hard constraints and so can guarantee specific response times. I think a dedicated hardware clock with a RTOS would be best but I dont know which of the hardware devices out there are designed that way. Someone mentioned Midronome but I've never used it.

I’ve been using Ableton live since version four and I will tell you that you have undertaken a fool’s quest. Ableton and external hardware synchronization has always been an epic nightmare. I gave up on caring and I use Ableton has basically either all software in the box or controlling hardware out of the box, but as soon as I try to get the two to work together and line up, everything goes to shit. The only answer for me has been that I record and timing after. It’s not all Ableton’s fault, either. It depends on what your synchronizing to it, and how that device handles clock changes. Midi, also being a serial protocol, does not help. Regardless of what your sequencers internal timing may be, midi is limited to 24 pulse per quarter note timing resolution, which was great in 1982, but just doesn’t work today. Midi 2.0 can’t come fast enough.

Here is my setup with the Multiclock in ableton that has been rock solid for me: I turn off all external midi sync in ableton because you want the devices to get the sync from the multiclock and not ableton via usb. Then use an external audio effect on the channel you have your multiclock plugin or audio pulse running through to route the audio to the multiclock. I find this keeps the latency compensation better when running plugins. You can then run one of your midi outs on the multiclock into the midi in on the MRCC to clock your outputs on the MRCC.

Another great video Ricky! I got the MRCC after your last video and it’s amazing to have such a flexible MIDI patch bay and especially have the four virtual MIDI in and outs. Game changer for me. But about MIDI jitter - I genuinely believe this to be an ableton problem. I’ve done something similar to this in Logic and it was bang on but yeah, Ableton always did weird stuff. Not even just clock, but even just MIDI sequencing notes. Funny thing however is that Elektron Overbridge seems to always be locked-in for me regardless of DAW. Perhaps you could talk to some people and start building some ideas for an Elektron sync box? 😅

The main issue with those sub-10ms changes is 2-fold: 1. Phase issues. If you are somehow trying to double up the same sound, which is not especially likely in this context, the phase can be totally off and thin things out. 2. More importantly, we CAN hear the substantive difference in transient response if say 2 percussive elements are clocked separately and continuously overlapping, you can have a subtle shifting of where a really really tight flam is happening. in a majority of cases i don't think this will really cause an issue, in some it could even be pleasant, but in certain situations it could certainly be heard, and in some it might be undesirable. I think the worst case scenario would be DJing, if you were to have similar parts overlapping poorly, could sound really shit.

This was PTSD of trying to get two kick drums to align across devices. The phasing in and out was an interesting resulting sound, but also soul crushing. It's stuff like this that drive people to the dark arts of eurorack drums.

Thanks for going to all the trouble to clearly and methodically document everything! I have been doing similar, but I'm so much less familiar with Ableton, so I can't pin down how much of rhe variation is something I changed on one track without realizing it

Interesting analysis of MIDI clock with the two devices and your DAW. It's hard to image that a half millisecond would be noticed. With MIDI keyboard latency, somewhere between 5-10 milliseconds I can start to notice a lag. That said, if you take a song at 120 BPM, you get 500 milliseconds per quarter note (two notes per second). I use Logic, which has a default MIDI PPQ resolution of 960 (I believe Ableton is the same?). So for each quarter note occurring every 500 milliseconds, there are 960 sub-divisions the DAW is using, to determine accurate MIDI clock timing. .500/960 = .000521 per MIDI clock sub-division, or roughly a half millisecond. So the actual (DAW) clock data used to determine MIDI timing, is only accurate best case, to a half millisecond (at 120 BPM -- clearly this will change based on the song's tempo). It doesn't seem to me, you are going to be more accurate than the clock frequency. And as you demonstrated, when the CPU in the DAW is heavily loaded, other CPU threads may delay the processing of the DAW/MDI clock. I like your comment about missing the forest by focusing on the trees -- this analysis is great, but I suspect if one doesn't heavily load the DAW's CPU while recording with MIDI clock, any minor variance + or - half millisecond, would be small enough to not be noticed. BTW, I ended up getting an MRCC 880 after seeing your video last week -- didn't realize this device was available. Really a nice MIDI router/merger/spitter -- thx for the tip!

I'm a bit late to the comment party, but as many other commenters have now suggested, there are a LOT of different choke points on both the computer running the DAW and all of the gear that you're plugging into. Trying to track down where these transient issues are happening on any given take is likely the path to insanity (although arguably still easier than troubleshooting a complex HDMI audio setup). Some concepts that might help provide a bit more context... first, even fast modern CPUs are still usually running one instruction at a time, which means the processor is rapidly jumping between dozens of tasks. It's not just your running programs but all of the OS services, and everything done over USB (audio interface included) requires a not-insignificant amount of processor overhead. Processing streams while individual apps and plugins are all greedy for high priority slices means that the more you listen for audio artifacts, the more you will absolutely hear them. This might actually be one of the most understated advantages DAWless setups have; the processors might be far less powerful, but they are not running a multitasking operating system. The second thing to keep in mind is that MIDI clock itself is a very janky thing. There's no concept of syncing to an atomic clock, and the speed a processor runs is directly influenced by the voltage it's receiving unless there's a clock running; does your MIDI gear have clock batteries that need to be replaced? Mine doesn't. So, everyone is doing their best but nobody actually can agree on how quickly time is flowing. When I was first learning the MIDI protocol as a developer, I was shocked to learn that there is no tempo message. Instead, you send timing "ticks" down the line at a rate of 48 messages per quarter note. That's right... time is defined in real-time based on the speed at which those ticks arrive. Your MIDI synth is just a hungry hippo for ticks. If you stop sending ticks, the music just stops. To me, this is wild. This is also why you see the tempo occasionally jump up or down by 0.1 when you assume it should be stable. What you're seeing is ticks arriving too quickly or too slowly, or not arriving at all. Now, the other elephant in the room is that MIDI works at 31.25k baud, and the timing messages are not given special priority. So, if you have a lot going on, that bandwidth can get eaten up. That's an area where the MRCC can really help, by defining subsets of devices to talk to each other. Still, just because MIDI can support a given speed under ideal conditions doesn't mean that the client device is powerful enough to receive them that quickly. Right now I am talking with the Hologram folks because Chroma Console literally shuts off if you send it too many messages too quickly. Which is not amazing, but this is the world we're in. I'm not intimately familiar with the audio clock but if there's software running on your laptop to interpret what it's sending, then all you're really doing is shifting the point of failure from MIDI to your CPU's ability to prioritize messages from your audio clock. TL;DR: I wouldn't pay extra for the audio sync thing, and I wouldn't do CPU intensive things while recording. And yes, if it sounds good...

Again he didn’t test multiple external sequencers. When I’ve used a usb midi hub with one piece of gear I could get it and Ableton synced after a little bit of tweaking. You would think that now I can do the same process with other gear and then I can run 3-4 external sequencers and they would be synced. But, it always fell apart. Now I use the multiclock and at the moment I have 5 pieces of gear all running their internal sequencers locked to Ableton. When I first got the multiclock I would also measure the latency and adjust it that way to get it super tight. Now if I add a new piece of gear I just dial it in by ear. Sometimes a few milliseconds here and there get those separate sequences grooving together. Plus I could always nudge later in Ableton, if need be, after I’m done jamming and recording.

I’m curious how the Akai MPC compares..Back in the the day the MPC was famous for it’s internal midi timing. There was this test of using all of it’s voices to trigger the same rimshot at the same moment. Still sounded like a flanged rimshot though; but way, way better then any midi sequencer in existence at the time….