Comments on: Live Music Makers Ask: How Can We Get in Sync?

By: insilico

insilico — Mon, 14 Dec 2009 05:54:01 +0000

im in an electronic band and we’ve been trying to sort out sync issues ever since we started jamming.

we bought a midi splitter/thru box (1 in 8 out)
we run a drum machine as master (boss dr rhythm)sending midi clock and then 3 laptops as slave.

this setup is ok, but if a computer crashes then we have to restart the drum machine so that it sends another midi clock start signal.

we’ve also tried midi syncing using software midi clocks as master, but same problem prevails.

at the moment we just sync manually. (1,2,3 GO!) and use the nudge tempo buttons in ableton to sync.

another problem when using ableton as a slave is the audio buffer. because ableton is tracking the tempo to the moment, there is little time for the buffer, so effects play out of time or stutter and our synths wiggout when trying to play arps.

we’re also running 2 pc’s and a mac so we dont have the option to use the specy midi + LAN capabilities built into osx.

By: Bjorn Vayner

Bjorn Vayner — Mon, 16 Nov 2009 19:33:08 +0000

Has anything come off a result of this topic yet?
It has mostly been nodding and shaking fists, with a bit of OSC geekery. But has anybody gotten scientific about the actual problem yet?

I’ll join the testing as soon as I get my second rig. Which is a lame excuse, I know.
But there are so many factors, its a bit unfair to generalize it all. There’s PDC, Audio interface delays, MIDI interface delays, MIDI Drivers, Virtual MIDI Ports, MIDI over TCP.
Do MIDI Sync signals get priority over audio signals?

How do you account for all these details and come up with reliable tests and results?

I often hear phrases like “My old Atari could sync like a…”. Which makes perfect sense. It didn’t have anything else to process. And correct me if I’m wrong, but even when it did sound it was still using chips to do so.
My point is, it makes sense that the only task the software needed to perform worked flawlessly.
And I guess there weren’t too many background processes.
How many processes are running on a computer even when you do nothing?

Sorry to come off a little ranty, but I’ve watched this topic being discussed for years. Only to see the discussion die down just like its doing now.
My last syncing venture was trying to sync up Live and a mc-909 many years ago. Ever since then I’ve always opted for an external clock.

I’m getting my second rig soon and will probably try to figure it out, out loud.
So hopefully this topic is still going.
But in the interest of understanding the problem, we could use some facts. Generalizations just wont do. You can say software X syncs better than software Y, but can you prove it?

- How do you measure the latency of a USB/Firewire MIDI interface? Which may or may not also be sending audio over the same cable at the same time.

- How do you measure the latency between 2 computers, their collective PDC and jitter?

The only reliable method I can see is to record in a latency free hardware multitrack recorder. Because recording on a computer may skew the results. But I’m not sure how exactly you would perform the test.
I could be way out my league with this stuff, although I do enjoy geeking out.

Sorry for the lengthy post. But its one of those topics I feel we should not have to discuss in 2009. Where’s my damn jetpack?

By: dj mosquito

dj mosquito — Mon, 16 Nov 2009 14:35:20 +0000

@Amos: you are right that we don’t need as tight a sync with our style. that i know, however when reading about the number of machines, etc that many people are trying to sync, its been an issue on at least some level for years and not isolated to just newer software. i will say that i find cubase to be a far better program for avoiding many of the sync issues, but the point here is directed at the problems in live. MTC is about the only way you stand a chance and you’re locked in with one bpm.

i still think a lot of people are relying more and more on their equipment to handle things we as musicians are suppose to be capable of doing.

By: Gideon Kiers

Gideon Kiers — Sun, 15 Nov 2009 19:47:27 +0000

Ok here we go.

Ableton Live v. 7.0.2 has a stable slave midi clock.
It has been the only version I have found so far that has a stable clock on the receiving end.

I’ve been working on a band project for a couple of years now, in which the 6 members all use Ableton Live. We have 4 or 5 laptops running Live, one of which acts as Midi Clock host.

The ‘master’ laptop runs a ± 60 minute arrangement, with quite a few BPM changes. The other laptops use the Midi Clock sync from the master for BPM as well as song position. There is no way we could do this with only BPM (osc) or only song position (MTC).

We have tried about all soundcards and midi interfaces on the market. In about all hardware configurations, including clean os installs, network solutions, etc. etc.

Nothing works. The fluctuating BPM results in VST/AU effects glitching, totall Sync loss, warped clips running bezerk, live 8’s looper recording out of sync, etc. etc.

The only solution we’ve recently discovered that works is reverting back to Live 7.0.2 for the receiving laptops. It seems that version does very nice rounding off of the incoming BPM.

It seems strange that Ableton has ‘forgotten’ this version exists. When I recently called support, they acknowledged the fluctuating BPM but said it was expected behaviour, due to flaws in the MIDI protocol. Not because of any issue with Live (sic!). Any trouble with third-party plugins should be referred to those 3rd party developers, not Ableton. Any problems arrising from the sync issues with Ableton software should be posted as a bug on the Abe forum.

Of course this response is completely rediculous, but it is the situation at the moment…

By: Kassen

Kassen — Sat, 14 Nov 2009 00:28:29 +0000

Owen; I mostly set delays using a gesture. I detect the speed of the -manual- gesture, then base the delay time on that, not on the bpm.

I recognise the importance of shared clocks but I’m at least as interested in working towards a instrument/interface that wouldn’t benefit from one.

By: Owen Vallis

Owen Vallis — Fri, 13 Nov 2009 20:47:37 +0000

Oh, and to address the myriad of comments saying that sync is not an issue :P This issue also effects your plug-ins. Any slave computer that has its BPM wandering slightly back and forth, while using a delay effect, will have bizarre pitch artifacts at the very least, or un-interpolated nastiness at the worst.

By: Owen Vallis

Owen Vallis — Fri, 13 Nov 2009 20:39:21 +0000

Just a note. After some experiments it looks like we can’t even get stable sync internally. This is not a fault of Ableton btw. It seems to be very difficult to get a continues, uninterrupted clock source to gauge the Midi Clock messages against. There seems to be ~ + or – 1.5 BPM variance when sending a locally created Midi Clock source (from say Chuck or openframeworks) over IAC into Live.
In addition to worrying about network timing issues we should also solve for the local timing problems. Very hard indeed. Interesting side note, an engineer was telling me the other day that a lot of astronomers have abandoned Windows as a viable clock source. Sort of makes sense as a chip can only do one thing at a time so I imagine the clock must be a low priority thread, constantly being interrupted. Maybe a clock “buffer” similar to how audio deals with this type of thing? Or even querying an audio buffer as a clock source? fun times :)

By: Mark Pauley

Mark Pauley — Fri, 13 Nov 2009 19:57:07 +0000

And Peter, you made a mistake about TCP vs. UDP. UDP is packet based, which is why we all use UDP for time-critical applications. If the slave misses a UDP packet, one could just assume that the tempo hasn’t changed, the next time you receive a UDP packet containing the absolute timestamp, then the DAW can lock to that. A simple method for determining latency is just sending a UDP packet, waiting for a response UDP packet and dividing the round trip time by two. Then we know that we need to pre-delay the outbound timecode stream by that latency, and the machine which receives the timecode just acts upon it as if said timecode were the truth. This is assuming of course that UDP packet handling is simple, real-time (as in lives in a ‘real-time’ thread) and predictable (goes along with the real-time thread part).

I really think that sync is the main problem yet to be solved in electronic music. We have the technology, we just need to build a workable model that is easy for both hardware and software manufacturers to adopt… which is why OSC (which can be sent over TCP/IP, UDP, USB, Firewire or serial) is possibly our great hope. Some of those interfaces actually have pretty stable latency characteristics… some (like every one of the networking interfaces) do not.

Once people adopt a good scheme for OSC sync and we have hardware that converts from OSC sync to MIDI sync and DIN sync, then I can jam in peace.

By: Mark Pauley

Mark Pauley — Fri, 13 Nov 2009 19:28:42 +0000

I’ve been talking about this for a long time. This is something that needs to be built into the operating systems and gear. The harsh reality is that we need to work with MIDI sync, and we need something else, that’s beyond MIDI to really solve the MIDI sync issues between two computers. I think the problem is pretty easy to solve if we can assume a LAN connection.

Check my post from around a year ago: http://www.unsaturated.net/?p=84

By: Amos

Amos — Fri, 13 Nov 2009 19:04:48 +0000

sorry for triple-comment: last footnote was to dj mosquito, not zevinhill. end of transmission….