Fix the sync issues now !! yes or no ?

[Machinesworking]

MIDI clock sync doesn't make sense with on-the-fly tempo changes and tempo nudging etc., they should forget about this once and for all. Some other kind of proprietary sync over a dedicated network channel or something might be able to lock the tempos together, but MIDI clock per se is never going to accomplish this.

I rarely nudge tempos and would really like Live to be able to sync my Evolver with Beat Clock, since the sequencer doesn't sync via MTC.
Understand you concerns as well, just don't be knocking solid Beat Clock sync!

[luddy]

I rarely nudge tempos and would really like Live to be able to sync my Evolver with Beat Clock, since the sequencer doesn't sync via MTC.
Understand you concerns as well, just don't be knocking solid Beat Clock sync!

Doesn't Live work as a MIDI clock master already for this case? Or maybe you mean using the evolver as a MIDI clock master and Live as slave?

-Luddy

[Machinesworking]

I rarely nudge tempos and would really like Live to be able to sync my Evolver with Beat Clock, since the sequencer doesn't sync via MTC.
Understand you concerns as well, just don't be knocking solid Beat Clock sync!

Doesn't Live work as a MIDI clock master already for this case? Or maybe you mean using the evolver as a MIDI clock master and Live as slave?

-Luddy

No, it doesn't work. Like I already said a few times, Live as master and the Evolver drifts and gets odd note doubling. Digital Performer as Master and the Evolver syncs perfectly.
I'm not the only one to experience this.

[Coupe70]

MTC or SMPTE/LTC are the standards for synching DAWs and/or other transports like film or tape. If Live could just support this on both input and output side it would already give it a good capability

Well, SMPTE is nothing but a special audio signal.
You can put it on any audio track and route it to a
seperate output. Google came up with these files:
http://trevor.ucsd.edu/soundscape.html

I feel like there also was a special VST plugin
that generated SMPTE or some sort of timecode,
but I can't remember...

[theque]

so in summary, if you want to sync two computers running live it will most likely be bad and ableton may or may not do anything about it

[[nis]]

Hi all,

I'll try to answer some questions here.

Concerning Live as slave...well, I'm not sure I understood...
Does it work as it should ? If it can't be done
better (like as clock master) please say so. If it
does not work as it should...fix it, it's an
official feature, isn't it ?

Concerning the possible changes you mentioned:
Is it a bigger change or something you could offer
as option in the betas so people could try it out ?

The current implementation of the slave behaviour is a compromise between being able to react to tempo changes from the master and being able to stay in sync with a clock that runs at a steady tempo. We currently measure and recalculate the tempo every 48 clock ticks, which corresponds to halve a bar. An average MIDI interface will cause jitter of approx. 5 ms (some interfaces are even worse). If the first and last measured clock tick has a deviation of 5 ms each (worst case scenario), the tempo calculation would have to deal with a 10 ms error. Note: this only refers to jitter on the slaved computer. There may be additional jitter on the master!

At 120 BPM (and a time signature of 4/4), a 1/2 bar corresponds to exactly 1000 ms. If your clock has the aforementioned jitter problems (max. error of 10 ms), a total time of 1010 ms would result in a tempo of 121.2 BPM. As you can see, the current tempo calculation method would yield to an error of at least +/- 1.2 BPM, perhaps twice as much if the master computer's interface causes similar jitter values.

Now let's assume Live would calculate the tempo less often, say every 5 bars (10 times less often): 5 bars at 120 BPM last 10000 ms. With the same jitter problems that I mentioned above, the worst case scenario would be 10010 ms, resulting in a calculated tempo of 120.12 BPM. That's a lot better, isn't it? The problem is that Live would need at least 5 bars to detect a tempo change from the master. This is also problematic when you just set a tempo on the master and hit 'play'. You'd get a completely wrong tempo in Live during the first 5 bars.

A possible solution could be a 2nd algorithm which can detect such tempo changes and updates the tempo more often at playback start and after any detected tempo changes, but less often when it is close to the real tempo.

To answer your initial questions:

"Does it work as it should?"
Probably yes, but it could work better.

"Is it a bigger change or something you could offer
as option in the betas so people could try it out ?"

It would be relatively "easy" to provide an option which lets you change the tempo update interval, but this is not a complete solution. Slaving Live would feel way more broken than it is right now. We'd rather implement the 2nd algorithm before we offer such an option.

Live as a slave, slaved by other live computers : kind of work. with a bug with losing one beat at bar 1024 (but that happened only when the master was provided by a live 6).

This is a limitation of the SPP (Song Position Pointer). It only has a maximum resolution of 1024 (bars). We used to ignore this in older Live versions, which lead to errors in CoreMidi and in some hardware devices which can't handle higher SPP numbers (the sync would simply stop after 1024 bars). Now we stick to the limitation of the MIDI spec. The result: when starting the master at bar 1025, the slave will start at bar 1.

And crashes if transport stops while recording a clip (don't know if it is fixed).

I'm not 100% sure (I'm at home right now, so I can't check), but I think it should be fixed.

Nico,
How does Live do as an MTC slave and master?

Well, MTC could be a solution for syncing to non-changing tempi, but you need to sync your audio interfaces via wordclock as well, otherwise they would drift away.

I know this would leave a bunch of problems open for folks who want to set tempos on the fly on the master and have the slave follow it, but that is something that no MIDI clock synchronization I've ever heard of accomodates.

Why not? MIDI clock per se is perfectly fine for tempo changes as long as it runs stable.

But slaving Live to MTC seems a bit unreliable.

Can you describe this in detail?

Also, it would be nice to have MTC output.

Agreed.

Not my experience at all. Syncing a Poly Evolver to Live, Live randomly syncs, and generally is only good for about 4 seconds or so, then it drifts, doubles etc.

I was dealing with your case and I have to say that I don't have a clue why this happens on your machine. The doubling is very strange in particular, as it usually means that your clock messages are doubled somewhere in your MIDI device chain. Also, the problems that you are describing are quite dramatic. This can't be explained with a slightly instable clock, which makes we wonder if there really is a conflict / setup problem on your machine. This was certainly also the reason why I asked these "simple questions". Not to annoy you, but rather to isolate the problem a bit.

I'm not sure if there's enough time and space to discuss your particular issue in this thread again, but you might try to detach all external devices from your computer except for 1 good interface (try the RME), reset Live's preferences to the defaults and give it another shot. It probably also makes sense to try a different piece of gear which you sync to Live (if you have one or can borrow one from a friend), just to see if that works any better.

Either way, I'm a little ticked at your claim that it syncs better than all other DAWs on OSX, in my direct experience, that's far from the truth, I've recorded the audio from Live and DP and seen how far off Live gets, and personally I find it a little disrespectful that you say this in total disregard to my own already stated experience. Whether I have some setting wrong or Live has an issue with Korg, RME, MOTU, NI or Novation drivers on my system, it's still an issue, and it's still being addressed like it doesn't exist at all. Seriously WTF? are we all lying in your minds?

Absolutely not. Why should I lie about something? This wouldn't make Live's clock better or worse. When you take a look at the sync topics in this forum, it is pretty obvious that some of you have sync problems, but:
1. A lot of these problems *may* not be Live's fault at all.
2. If there are any faults in Live, we need to be able to replicate them here first. Anytime we have investigated the whole sync topic all over again (and that was a dozen times), we were not able to measure an unnaturally high jitter on Live's own clock, nor could we find any serious sync problems with the hardware we tested and/or the fluctuations have been within an expected and acceptible limit. And yes, this was tested on different computers, with different interfaces and slaved gear.

Don't get me wrong. I'm not trying to refuse the wish/need to have a better MIDI clock, but we can only improve things if we find real problems in our code. Rest assured that we will continue to review and rethink our code and fix problems if we find them.

Maybe you should explain under which conditions the measurements were done, in particular CPU load and UI actions.
In my experience Live seems more sensitive to such 'real life' parameters than eg. Logic.

In our latest tests on Mac OS X, we sent the MIDI clock directly through a Python extension into the "RtMidi" library and then used a self-programmed tool to readout the jitter from there. In other words, we measured the direct clock output, i.e. before it gets to your actual MIDI interface. Under "normal" workloads, the average tempo of Live's clock was never worse than 0.004 BPM. Things started to get bad when the CPU load exceeded 75-80% (in Live's CPU meter), but that's to be expected. In comparison, another DAW (which I'm not going to name here) showed an average tempo of 0.079 BPM in the exact same test scenario. This was the worst candidate in our test.

As far as UI actions are concerned, we only tested switching views, triggering clips/scenes and changing the arranger loop whilst the clock was running (at least in this particular test).

Best,
Nico

[chapelier fou]

Wow. Thank you for this all.

[3phase]

so in summary, if you want to sync two computers running live it will most likely be bad and ableton may or may not do anything about it

when the two computers are macs it has been prooved by the competitors that this all can run perfect..

so at least 50% of the user base will benefit..


on the pc side i cant say wher the limits are.. but ...

logic 5.5 the ol logic from the last century.. has a far better midi clock timing and timecode reaction on windows pc than ableton live... seems that emagic has written the better midi drivers there or whatever

so.. there is room to improove on windows aswell

[theque]

nico, thanks for the excellent response.

[3phase]

Hi all,

I'll try to answer some questions here.

[
The current implementation of the slave behaviour is a compromise between being able to react to tempo changes from the master and being able to stay in sync with a clock that runs at a steady tempo.
Nico

thats a bad compromise..please reffer to software like natives instrument reaktor or hardware like the akai mpc 3000 how to do that wright..

you dont have to reinvent the wheel..just do it good..

and regarding the clocking there shouldnt be a compromize.. either you allow the software to follow jitter ..therfore its fast on tempo changes..or you want it to hold the timing.. as most people want it to do..like any normal band is working... then you can well have a whole bar or two to smooth the jitter and calcukate the source tempo..

there are a varity of thinkable algorythms to further improove that tempo calculation the slave has to do..

its a musical missconception that a timing slave has to be fast on the tempo change...

however when its improtant for some to have the option to be fast on tempo changes offer this as an option..because thats the minority use of clock syncing..

ther is also the possible to allow fast changes on large tempo jumps...
so the cases where you need a drastical fast jump are executed fast while small changes are executed slomo

its a mistake to evalute tempo between each click..music is organized in measures..

different tempo avaluations have to work together and adjust in locked loops.. there has to be one master algorythm that decides what to do like a conductor.. the slewrate of the dejittering dont has to be fixed with good musical programming.

The one needs to be wright.. the rest dont matters so much..as you can see easily when retriggering clips on the one which have a wrong tempo..
we experiance that as groove when the 0ne is wright...

this random jittering around a clock is a pretty retard implementation..

please be a bit more clever about it.

your tempo sync is like your search in the browser ..really smart.. in the obvious situation on a 100% stable clock between wordclocked instances where an infant could see that 120 bpm is the tempo you want to go your sequencer jumps between 122 und 118 all the time.. sorry.. thats not syncing..thats guessing..

please use arteficial intelligence


and allow miditimecode output

and fix the glitches of the masterclock on screen operations

[luddy]

I know this would leave a bunch of problems open for folks who want to set tempos on the fly on the master and have the slave follow it, but that is something that no MIDI clock synchronization I've ever heard of accomodates.

Why not? MIDI clock per se is perfectly fine for tempo changes as long as it runs stable.

Hmm, let's be sure we are talking about the same thing.

In a "normal" master-slave sync using MIDI clock, the master and slave have identical tempo maps -- meaning that they have the same understanding of the bar structure, any associated tempo changes that occur on bars within that structure, and signature changes. With this shared map, then the slave's only job is to constantly monitor and adjust its own notion of "beat" with respect to the incoming clock signal. This means in particular that the slave can go through a tempo change with no glitch in its timing, because nothing special happens at the tempo change, only that the master's MIDI clock changes speed exactly in the same way that the slave's own internal MIDI clock changes speed.

With Live however, you slave the notion of tempo to the master. This means that the master can launch a scene that spontaneously changes the tempo without the slave knowing about this ahead of time. The slave needs several clock periods to know what the new tempo is -- this information is not embedded in a single clock message, it is the distance in time between successive messages that communicates it. So (unless I'm misunderstanding something fundamental, and that's possible of course ) it's really not realistic to expect the slave to work in the way that a 'normal' MIDI clock slave works.

As I say, maybe I misunderstand the problem...

-Luddy

[3phase]

I know this would leave a bunch of problems open for folks who want to set tempos on the fly on the master and have the slave follow it, but that is something that no MIDI clock synchronization I've ever heard of accomodates.

Why not? MIDI clock per se is perfectly fine for tempo changes as long as it runs stable.

Hmm, let's be sure we are talking about the same thing.

In a "normal" master-slave sync using MIDI clock, the master and slave have identical tempo maps -- meaning that they have the same understanding of the bar structure, any associated tempo changes that occur on bars within that structure, and signature changes. With this shared map, then the slave's only job is to constantly monitor and adjust its own notion of "beat" with respect to the incoming clock signal. This means in particular that the slave can go through a tempo change with no glitch in its timing, because nothing special happens at the tempo change, only that the master's MIDI clock changes speed exactly in the same way that the slave's own internal MIDI clock changes speed.

With Live however, you slave the notion of tempo to the master. This means that the master can launch a scene that spontaneously changes the tempo without the slave knowing about this ahead of time. The slave needs several clock periods to know what the new tempo is -- this information is not embedded in a single clock message, it is the distance in time between successive messages that communicates it. So (unless I'm misunderstanding something fundamental, and that's possible of course ) it's really not realistic to expect the slave to work in the way that a 'normal' MIDI clock slave works.

As I say, maybe I misunderstand the problem...

-Luddy

its defently need some arteficial inteligence algorythm..

the clock might be 100% stable..but the interupt szenario inside the computer is not...

therfore a stable clock arrives at the software as a jitterd one that in the most primitiv form of a syncalgorthm needs to be dejittred..

ableton says taht they calculate every half bar.. thats no dejittering at all.. so less than the most primitiv state.. and just statistically..with just 2 probes over one bar on a not dejittred clock
will havt to give a wrong result.. so ableton live catching the wright tempo for just half a bar is allmost pure accident.. random.

thats the most unsmart possible sync algorytm and the guys that implemented tha are either cluless, incompetent or just didint cared much about live beeing slave synced..

the later is probably the case.. and we have to admit.. ableton live is the only daw that ever cared to be clock or rewire slave at all..
thats absolutly great that the abletons are not such dicks that think teire mighty daw has to be the master..

but.. like all the others they avoided to put more work than the most necessary into the item..

so clock sync is on a low priority for many years now..

and this has to change ..because its easily possible to do it better

you dont need to have a algorythm on the most primitiv level.. it could be a little smarter..and this would allready help.. see the 1080´s machine akai mpc..
its totaly fine as clockslave.. dejitters incoming clocks with a variable rate ..

roger linn design on a little processor... he had the space there to involve a few more lines of code ...

Ableton could involve an even mucj more complex algorythm.. there is nothing more important than the timing of a sequencer.. so the most complex algorythms at the source of the internal program structure should take care of that..

not a primitive algo that is as it seems placed as a sub sub routine somewhere

[[nis]]

bla

Do you actually read my posts? I'm starting to wonder why I'm wasting my time on this.

If it's not so important to follow tempo changes, then what about adjusting the tempo at playback start? Imagine you set a tempo on your master and hit 'play', then your slave would need a long time until it catches up. I'm seeing a very disappointed 3phase cursing on this oh-so-clever not-tempo-change-considering algorithm.

this random jittering around a clock is a pretty retard implementation..

So then, where's your magic code which solves all problems? If it's so "easy" as you claim, why haven't you submitted your cleverly thought-out algorithms to some DAW manufacturer already?

please use arteficial intelligence

Sheesh!

I'm explaining a possible technical solution to this whole sync dilemma and all you have to contribute is...this?

Back to my ignore list.

[[nis]]

Hmm, let's be sure we are talking about the same thing.

In a "normal" master-slave sync using MIDI clock, the master and slave have identical tempo maps -- meaning that they have the same understanding of the bar structure, any associated tempo changes that occur on bars within that structure, and signature changes.

Not sure if I can follow. MIDI clock just transmits start/stop messages, the actual clock ticks (at a 24 ppqn resolution) and if supported, SPP messages (Song Position Pointer) which can tell the slave to start from / jump to a certain measure.

Tempo maps are more relevant for MTC sync.

Best,
Nico

[3phase]

bla

Do you actually read my posts? I'm starting to wonder why I'm wasting my time on this.

If it's not so important to follow tempo changes, then what about adjusting the tempo at playback start? Imagine you set a tempo on your master and hit 'play', then your slave would need a long time until it catches up. I'm seeing a very disappointed 3phase cursing on this oh-so-clever not-tempo-change-considering algorithm.

this random jittering around a clock is a pretty retard implementation..

So then, where's your magic code which solves all problems? If it's so "easy" as you claim, why haven't you submitted your algorithms to some DAW manufacturer already?

please use arteficial intelligence

Sheesh!

I'm explaining a possible technical solution to this whole sync dilemma and all you have to contribute is...this?

Back to my ignore list.

come on guy..i study sequencers since 1983...and have worked with the majority of hard and software seuqencers that have hit the planet in person.. i know about clocking problems not as a hobby..its usually a pain..

and if you cant imagine some smarter musical working algorythm than this is probably because you are probably no coder or musican ..

why havent i put such algorythms in a daw? i mailed ableton for many years now with my insights to how the others are doing it and that it would be extremly helpfull to do it a bit better. or even much better with some own ableton internal thinking about sycing..

but it happens to be that my duty free efforts was ignored..

there are people in the audioindustry that have payed me good portions of money just for a conceptional letter..see it as the free bug hunting we do for you..as gifts..

and make something out of them.. that your clock slave algo sucks is easy to see.

users complain about this for many years now. its a solveable problem..at least when you would allow to have selectable option..

but when you want to have it all in one setting you defenetly have to apply an arteficial intelligence algorythm..

its music.. and a musical timing needs interpretation.. so the algorythm has to be able to interpretate what is happening with the incoming clock

so when you dont have any on your own..arteficial intelligence helps

its so easy to filter random jitter from a wanted tempochange..


tssss... just while writing this here i construct an algo that can do it..

sorry man..its maybe not easy but a rather simple problem that needs to be solved here.
And thats defently not a big task for you genial coders at ableton..

I cant understand why people that are able to program in machine language can be so unpractical sometimes..

practical engineering and coding are 2 different things.. the system design should be done by engineers before the coders realize that in software..


but the coders alone? first they follow any incoming clock tick and wonder why its jittering..

than they smooth..that was the times where it was a short time good..but somebody complains that the reaction on tempo change is slow now..

than they remove the smooth and have a half bar aproximation ...

:-/ sorry.. not enough. thats running away from the problem with quick and primitiv one line of code fixes instead solving it once and for all.

A bit musical priority thinking and adjusting after the likeliness of tasks woukd help..

when the distance of 12 consequtive clockticks gets smaller between each tick..how much is the likeliness that we deal with a tempo change here?

when our clever algorytm than decides to reduce the slewrate to allow a faster tempo change..
we would have achived that reaction within an 8th note !!!

sorry man ..its defently possible to have a long smoothing that allows steady tempos to be stable and resonable fast reaction times on tempo changes when you just be a bit more clever about it..