For our live setup we will need to sync two Laptops and probably a couple of hardware via Midi. Because lots of people complained about Live being unstable and drifting with Midi Sync I took some time to dig deeper into the subject.
Hopefully Ableton will change the Midi Sync behavior of Live at some point. But until then you should at least know what restrictions to deal with, so here is a detailed guide about the culprits of Live Midi Sync.
All tests so far were done on a Windows XP Desktop PC and partly with a Vista Laptop PC. Once I get my Macbook Pro I will do some more tests with two Macbooks.
The results are about the same for both MME and DirectMusic, with the exception that DirectMusic can drag Live down to being unuseable if you use alot of Midi bandwidth unless you increase Audio Buffer size. Something similiar can happen with MME, if one MME driver performs badly then the whole MME engine is dragged down affecting all MME ports/drivers alike. Midi allows upto 3125 bytes/s per port, Live (currently) cannot handle that much neither on a single port nor the sum of all ports when using DirectMusic without major blackouts of the audio-engine. Wether this is a restriction of Live or of DirectMusic (and its implementation in the OS) I cannot tell.
Since pure Midi Sync doesn't even get close to that limit it doesn't matter for these results.
1. Live as Master Sync Output is stable!
With a good Midi interface Live (or any other Midi Master on the same PC) is capable of keeping Midi Sync stable, with drifts smaller than 0.10 BPM as long as (CPU) load remains below 80%. It is still useable until around 90% and then quickly drifts down to lower bpm because it cannot upkeep the constant Midi stream.
Eventhough tempo might drop Midi Sync should still be stable with external synced gear though, even if Live's CPU meter increases well over 100%. Anyone experiencing problems with Live as Master Output Midi Sync most likely suffers from bad drivers, a bad Midi interface, short load spikes originating from some other problem source or you saturate Midi bandwidth by sending too much additional Midi data along the line.
Also keep in mind that if you want to sync two different machines that each comes with other Audio and Midi Latencies. You need to use Sync Delay in order to get them into Sync and most of the times it can never be perfect. Which leads us to the next point...
2. Live as Slave Sync Input is only useable with restrictions!
When Live is running as Slave to another Midi Sync Master it does some very rough rounding on the incoming Midi Sync signal/values. Live rounds any Sync value to full BPM! Value below x.5 are rounded down to the next full digit, values above x.5 are rounded up. I.e. 127.4 BPM is rounded down to 127.00 BPM, 127.5 BPM is rounded up to 128.00 BPM.
Whatever strange algorithm is used for that rounding it has two major drawbacks.
a) Live is unable to perfectly sync to other Midi gear because it drifts too little.
Every Master Midi clock drifts a little, some are more stable than other (and costs more accordingly). Especially Midi clocks running on computers will drift more once the system load increases.
That's not much of a problem as long as the Slave clock drifts along and thus keeps in sync and pace with the Master. But Live's Slave clock does not drift along, it keeps running at full BPM values while the original clock does not. Because of that Live's clock appears to be drifting compared to the original clock, but in reality it's the other way around.
Here is a screenshot demonstrating how Live's Slave clock differs from all other Midi clocks in the system.
The Live instance on the lower right is the Master Midi Clock and runs at 127.50 BPM, its corresponding NI Kontakt plugin runs at the same clock via VST host clock.
The Live instance on the upper right is a Midi Sync Slave whose clock keeps jumping between 128 and 127 BPM (small drifts force Live to jump between rounding up and down!), it's corresponding Kontakt plugin runs at the same speed as the Live Sync Slave via VST host clock.
The Kore 2 instance at the left side is another Midi Sync Slave. Its clock is displayed as being rounded to 127.5 BPM with only one digit after the decimal-point, but internally it keeps precision at least upto the second digit and so its corresponding Kontakt plugin runs at 127.49 BPM via VST host clock.
Also listen to the audio example below for a demonstration how this audibly affects two Live instances supposed to be running in Sync!
b) Live adds additional Midi Sync input latency to the Sync clock.
Because of this you have use use the Midi Sync Delay setting in Live's Preferences in order to sync Live to other Midi gear. But more important: The Midi Sync Delay necessary to sync two instances of Live changes with tempo!
You need to chose negative values (i.e. -17 ms for around 120 BPM) on the Midi Slave instance of Live (or use positive values on the Midi Master instance if you are syncing two instances of Live instead of syncing Live to other gear). The definitive values depends on your rig, your interface, your drivers and probably other factors, but even if all of these are the same the delay still is mandatory.
You may reach a Delay time of 0 ms when tempo increases over 240 BPM, but most people likely ain't gonna use such high tempi, and it wouldn't be good neither because drifting gets worse with higher tempo (starting as low as 0.01 BPM at tempi below 100 BPM but increasing towards 1 BPM when going towards 240 BPM tempo). So be aware that finding one correct Midi delay value is not possible when running Live as a Midi Sync Slave because of these tempo-dependent Midi Sync Delay times.
-*-
Here is an Inversion test demonstrating how two instances of Live can be delay shifted near to being synced, but also how rounding affects the Slave instance badly and how small drifts always keep happening (likely on the Slave instance).
Both instances play the same audio-clip and Impulse drum-pattern through the same audio-interface (digitally mixed via Fireface mixer), but one is the inversion of the other. If both ran in sync they should cancel each other to silence, instead you can hear them drifting around each other.
The clip begins playing at 128.00 BPM with both instances set to 0 ms Midi Sync Delay. Then the Slave instance is set to -16.5 ms Midi Sync Delay which nearly cancels their audio-clips. But with each loop the audio cancellation drift apart so that sometimes they cancel better and sometimes they don't cancel much at all.
At around 43 seconds the Master is set to 127.5 BPM leading to a phaser like sound. Then it's set to 127 BPM and later back to 128 BPM.
MIDI_sync_Live.mp3 - 1.40MB
-*-
c) Live's final internally used values remain unpredictable and somewhat random!
While Live definetively uses BPM rounded to full digits for VST plugins it seemingly uses different values for playback of clips and maybe even for its own internal plugins.
If that is true, that VST plugins use a fixed tempo via VST clock while Live internally uses slightly drifting Midi tempo then synced VST plugins (like synced Delays) might get into drifting troubles within their respective Live hosts, too. I did not check that though.
When two instances of Live running on the same PC through the same audio-interface with both receiving the same external Midi Sync signal they cannot be synced without drifting around each other!
Whatever algorithm/mechanism is used to round incoming Sync timings it leads to different results on different instances.
-*-
Here is another audio file demonstrating how two instances of Live are synced to the same external source while running through the same audio-interface (digitally mixed via Fireface mixer). Eventhough both are started by the external Midi Master at the same time and both display the same Slave clock speed they do not cancel, but drift around each other.
MIDI_sync_MidiOX.mp3 - 1.68MB
-*-
I gotta go to work, will try this later.
For the technically inclined: 31250 kps / 10 (1 start-bit + 8 data bits + 1 stop bit) = 3125 bytes/s data ~ 520 notes on+off/s ~ 65 notes per 1/16th at 120 BPM. One (1) Note On needs roughly 1 ms, so a three note chord needs about 3 ms until all three notes are played/heard.
