Live Midi Sync Restrictions explained!

Share your Ableton Live secrets here
Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Live Midi Sync Restrictions explained!

Post by Crash » Fri Oct 10, 2008 1:31 pm

[Live 7.0.9/.11b on Windows XP]

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.

ImageImage

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

-*-
Last edited by Crash on Mon Oct 13, 2008 10:45 pm, edited 5 times in total.

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Fri Oct 10, 2008 2:08 pm

One addition: You can perfectly sync several instances of Live to external Midi Timecode (MTC) downto a single sample!

That means that in a cancellation/inversion test two instances can cancel each other out to complete silence without drifting around each other.

Unfortunately Live can only receive MTC, not send it. Also when using MTC you need to find other means of controlling Tempo, like Midi CC, because Tempo is not part of MTC.

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Fri Oct 10, 2008 2:20 pm

Another addition. Most of the "drifts" explained and demonstrated here are just around few samples long. So it shouldn't really affect you much in the short run.

Live and other Midi gear might drift apart in the long run though. One workaround to get both back together is either hitting Stop/Play or using Rew/FF, because these make the Master send a definitive song-position to the Slave(s) and thus help get both back in line.

dom
Posts: 936
Joined: Fri Jan 07, 2005 9:24 am
Location: Ableton Headquarters
Contact:

Re: Live Midi Sync Restrictions explained!

Post by dom » Fri Oct 10, 2008 2:47 pm

An offical word regarding this:
We can't confirm your findings and esp....
Crash wrote: Live rounds any Sync value to full BPM!
... this i can totally deny technically.
This claim, again, is total fiction of yours.

Cheers,
Dom
ableton support team
support@ableton.com

opuswerk
Posts: 89
Joined: Sat Nov 03, 2007 12:00 pm
Location: Geneva / Berlin
Contact:

Post by opuswerk » Fri Oct 10, 2008 3:48 pm

I can confirm the rounding. We also tried to get two computers to sync with live. Both recent MacBooks were syncing using midi over LAN. There was no drift, but every note was being brought back in the grid. Meaning a note slightly delay and playing on the 32th would be brought back to the nearest 16th. This eventually killing the carefully crafted groove of our midi clips patterns. The only solution seems to be to use an external midi clock using smtpe but we have not been able to test this.
Live is rounding midi values somewhere.
Forthcoming:
[AR02] 1883 EP (wax)
[CSF027] Mamacass EP (wax)

Opusspace
Opuscloud

Superchibisan
Posts: 593
Joined: Thu Jun 10, 2004 7:25 pm

Post by Superchibisan » Fri Oct 10, 2008 4:18 pm

get a midi master clock... simple solution!

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Re: Live Midi Sync Restrictions explained!

Post by Crash » Sat Oct 11, 2008 7:36 am

dom wrote:An offical word regarding this:
We can't confirm your findings and esp....
Crash wrote: Live rounds any Sync value to full BPM!
... this i can totally deny technically.
This claim, again, is total fiction of yours.

Cheers,
Dom
Dom,

can you explain why on the screenshot the Slave instance of Live rounded 127.50 BPM to 128.00 BPM (in reality it kept switching between 127.00 and 128.00)? Can you explain why the hosted VST plugin (Kontakt) that is capable of displaying BPM downto the second digit after the decimal-point shows the same rounded tempo?

Can you explain why in the audio example there is serious and very audible phasing going on between the Master and Slave instance of Live once the Master instance is switched to 127.50 BPM while there is no phasing at 127.00 and 128.00 BPM?

Did you just post here to ridicule me or to provide detailed information on the subject? I spend hours testing our own setup and writing a documentation in order to support other users with their Midi setups. You spend seconds providing nothing but a "no" without giving any valuable informations.

Please leave educated comments on the subject and explain the results found on the screenshots and audio files or stop spamming this thread. :!:
Last edited by Crash on Sat Oct 11, 2008 8:16 am, edited 4 times in total.

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Sat Oct 11, 2008 7:44 am

Superchibisan wrote:get a midi master clock... simple solution!
Only a simple solution if you keep tempo at straight full values.

Live screws up as a Midi Slave whenever your superb master does one of the following:

- Change tempo while playback is running (Live changes tempo in big steps while other Midi Slave gear might change progressional in a bezier curve style, think of Live's behavior like rough quantization).

- Pauses in between songs ain't long enough for tempo changes reach their destination values on all Midi gear (same reason as above, Live might already have reached the new tempo in big steps while other gear is still progressively closing in to the new tempo).

- Use tempi that are not on full digits (like 127.5 BPM in the example, Live as a Slave is seemingly not able to use that tempo while your other gear does).

Like with any sophisticated gear you need to know what's going on with your stuff, there is no simple one-button-push solutions.

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Sat Oct 11, 2008 8:55 am

Changed hint about "Midi Sync Delay" when syncing two instances of Live. It turned out that finding the right value is depending on the chosen song-tempo. Yes, that means there is no single correct value for your rig if you change tempi during a set.

The slower the tempo the higher you need to set the difference between both instances, the higher the tempo the lower you need to set the difference.

For example: If both instances run at a tempo of 120 BPM and you get them in sync with a Midi Sync Delay of -17 ms on the Slave's side then you might need to set it to -20 ms for 90 BPM, but only - 13 ms for 150 BPM (made up values, you need to find your own).

Maybe we could derive a formula, but I doubt that's of much use, because no one wants to keep changing those values with every song of a live set.

Tone Deft
Posts: 23907
Joined: Mon Oct 02, 2006 5:19 pm
Location: SF, CA

Post by Tone Deft » Sat Oct 11, 2008 6:28 pm

midi is a 32kbps standard, dunno where you get ~3kbps. ??

simple test of mine that fails
Live 7.09, mpc1k, both metronomes on (very light load), Live as master
~20 seconds they burp.

computer to computer I've had success, mpc as master is OK, Live as slave = fail. maybe higher sample rates load the system down, dunno.


I'm very intrigued by your findings, glad the ol' pain in the ass is back ;) I gotta go to work, will try this later.

might I request shorter posts? it makes everything so much easier.

glad you also saw the delay changed with bpm, that scares me and pisses me off, even if/when you get synced up it changes with bpm.
:evil:

I don't depend on this feature but goddamn this sucks.
"Obsession is a great substitute for talent." - Steve Martin on learning the banjo

Dell Inspiron 15 7000, Live 10.1, Win10 Home, Edirol UA101, APC40, Remote SL, SPD-SX, mic, POD500HDX, JX305, Nova
soundcloud.com/tone-deft

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Sat Oct 11, 2008 9:23 pm

Tone Deft wrote:midi is a 32kbps standard, dunno where you get ~3kbps. ??
I said 3125 Bytes per second, buddy, and that's pure data transfer with overhead already substracted. :P 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.

Live + MME can do that per each single port, Live + DirectMusic cannot deal with that without major audio glitching even when spread over several ports (on my setup). I guess Midi bandwidth is still just too much for our modern multicore computers of today. Do you think they knew that back in the 80s when Midi was conceinved? I mean, they had those really big supercomputers back then, maybe they build 'em just for Midi? ;) :lol:

Hell, I'm glad Ableton Support told me Midi is a serial protocol when I reported the DirectMusic issues. I think I never understood the "per second" part before, not. :lol: Unfortunately they still don't understand the issues, so we have to workaround them. :?
simple test of mine that fails
Live 7.09, mpc1k, both metronomes on (very light load), Live as master
~20 seconds they burp.
I have read the MPC story so often now that I begin to wonder wether it's a MPC Slave problem? What happens if you only run Live as a Master Sync Clock to the MPC without any load in Live (pure clock for the MPC)? If you are on PC you can also try Midi OX as Clock Master to get Live out of the equation.
maybe higher sample rates load the system down, dunno.
I will try 96k sample-rates again and report back, but I'd really wonder if that was the culprit, except if spikes go over 80 - 90%.
I'm very intrigued by your findings, glad the ol' pain in the ass is back ;) I gotta go to work, will try this later.
One of the reasons I care to post this stuff again is that several people told me that they miss my technical posts. But you can forget about my findings. DOM already told us they are all made up. I'm a loser. :roll: :lol:
might I request shorter posts? it makes everything so much easier.
Not on the Tips & Tricks and not on the Bugs and Problems, this is where I go into every aspect and detail. I'm also writing this stuff up for myself. Helps getting everything sorted in the ole brain and reducing/concentrating it to the essence afterwards. You wanna gain from the process, you need to read all the way through. :P ;)
glad you also saw the delay changed with bpm, that scares me and pisses me off, even if/when you get synced up it changes with bpm.
I may be able to find a method/rule behind it (like x ms per yz BPM), but that wont help much for playing a whole set with changing tempi live. This is a serious bug, but since it's a complicated one it makes little sense to hope for a fix (or even reproduction). This is why I posted in the Tips & Tricks, so that other users at least know about the limitation and can work(around) it.
I don't depend on this feature but goddamn this sucks.
We wont use Live as a Midi Sync Slave for playing live unless this is fixed and probaly we wont do even then. We will use Live as Master on the first laptop and Kore 2 (plug plugins) as Slave on the second one because Kore seems to be more (timing) stable as Midi Slave and VST host.

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Sun Oct 12, 2008 8:11 am

Tone Deft wrote:computer to computer I've had success, mpc as master is OK, Live as slave = fail. maybe higher sample rates load the system down, dunno.
I just did some extreme tests with sample-rates upto 192 kHz and Live's CPU meter going towards 200% and higher. While the audio crackled badly and playback seriously slowed down the Korg 01/W (Sequencer part of it, btw) and Live kept sync. I tested both the Midi ports of the Fireface that was running the audio stream and the USB driven Remote SL ports.

So CPU spikes/overload may lead to slowdown, but then everything will slow down and stay in sync. The only reproduceable and reliable way to get the two out of sync is to switch Midi ports on/off or switch port type (MME/DM) during playback. At one poing I even had them stay in sync (albeit slowed down) when switching the Audio engine back on into 300+% overload and Live seemed to be hanging (in reality it just took minutes for my poor overload system to get this going). Only when the audio engine finally kicked in Midi Sync was lost.

Switching sample-rates and audio buffers/latency is no problem whatsoever, if Live chokes the synced 01/w chokes just the same and stays in sync.

You say your MPC hickups after about 20 seconds. Does it regain sync afterwards or does is it shifted in timing towards Live from there on?

Crash
Posts: 805
Joined: Fri Sep 19, 2008 4:06 pm
Location: Nowhereland

Post by Crash » Sun Oct 12, 2008 2:01 pm

Some of you might find this interesting:

Using Midi Yoke as Output can cause unstable Midi timings. Here's is a quote of a report I posted on another forum.
I noticed that using Midi Yoke (2) as output for the Tranzport control and for Midi Sync leads to stability and performance problems when Live is pushed to high load.

The stability problem shows easily by loading Tarekith' Performance Test and then exiting NKlive. Live will hang at once and until NKlive is restarted. Seemingly the Midi Yoke 2 Output connection gets stuck in some loop.

The performance problem shows when using Midi Sync output. Live's performance gets worse and Midi Sync on all outputs (software + hardware) gets choppy as soon as any software gets synced via Midi Yoke.

I got around this problem by replacing the Midi Yoke 2 output with the freeware LoopBe1.
Just to mention. You can easily test wether Midi Yoke Output 2 makes troubles with Live on your system or not by loading Tarekith' Performance Test Set:

http://www.ableton.com/forum/viewtopic. ... mance+test

Load the Set, start playback and then exit NKlive. On my system that instantly hangs Live. Once NKlive is reloaded Live goes on as if nothing had happened.

You can also use that Set to check Midi Sync stability. Route Midi Yoke Output 2 Sync to some external app and make that app sync to external Sync. Then copy the tracks in Live until your PC is running hard near 100% CPU load during playback and watch the BPM of your external app jump around.

Generally Midi Yoke is running well and stable, but Output from Live is dangerous. I also made Live crash on several occassions (even on a clean Vista installation) by simply turning off a Midi Yoke output port.
LoopBe1 is a free app with only one virtual port, you can mix it with Midi Yoke on the same system without problem. LoopBe30 offers 30 ports and costs a few bucks (16,90 Euro / 19.95 $).

theque
Posts: 614
Joined: Mon May 30, 2005 11:47 am
Location: adelaide
Contact:

Re: Live Midi Sync Restrictions explained!

Post by theque » Mon Oct 13, 2008 7:17 am

dom wrote:An offical word regarding this:
We can't confirm your findings and esp....
Crash wrote: Live rounds any Sync value to full BPM!
... this i can totally deny technically.
This claim, again, is total fiction of yours.

Cheers,
Dom
cheers for the input dom. is there any light you can shed on this topic as it has been discussed a lot here recently. it would be good to get the facts straight on this one.

pepezabala
Posts: 3499
Joined: Mon Jun 07, 2004 4:29 pm
Location: In Berlin, finally

Post by pepezabala » Mon Oct 13, 2008 7:48 am

hi all,

I am also vry interested in this topic as we are doing livesets with two synced macbooks. We had mixed results, under some conditions it worked great, under others it was horrible (drift, going out of sync etc.). This might be related to circumstances where we have a huge amount of midi-data coming in (osculator/wiimote/IAC-driver with midi-loopbacks and reacTIVision). But if the sync comes in on a different port, then it shouldn't matter so much, or?

In the end we have learned to avoid stuff that doesn't work and have a lot of songs now where one of the two computers is doing mostly all playback while the other is doing live input (keybords, voice, guitar, triggering non synced samples etc.). Which is a little bit sad, because if sync works and is tight it's really great. And when each of your songs has a different tempo syncing by ear is quite tedious .... (but then again it's something that any dj-kid does all the time ..."beat matching", hehe, so why don't we?)

Epecially interesting is the find that the midi-delay compensation is different at different tempi. Our various songs go from 68bpm up to 150 bpm...

Post Reply