Fix the sync issues now !! yes or no ?

[3phase]

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

there is an absolute number of clockticks in a musical piece..therefore a tempo map that says go to tempo 140 on clock tick 14678 will happen on that absolute position independent from the tempochanges the individual devices will have performed up to that point

[3phase]

@ NIS

you know what is funny with you ableton support guys.. you allways hit the ignore button or drop support cases when somebody says something that is beyond your ability to understand..

thats actually damaging the company.. ok..you are user support and not company support..

[[nis]]

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

Isn't this exactly what I wrote above? Didn't I say, "the current implementation of Live's slave behaviour can indeed be improved"? Didn't I even say that I have voted in your poll to give this a little more priority?

[[nis]]

@ NIS

you know what is funny with you ableton support guys.. you allways hit the ignore button or drop support cases when somebody says something that is beyond your ability to understand..

thats actually damaging the company.. ok..you are user support and not company support..

I'm perfectly fine with hitting the ignore button if someone is not willing to cooperate with me when discussing/troubleshooting a problem. My time is limited, so is yours. I know that you're way more clever than most of your posts. You should not waste your time on cursing, but rather concentrate on a rational and meaningful discussion. Anything else is just a waste of time.

Btw, I stated this before: out of ten thousands of users, you are one of 3 or 4 people which have been rejected from Support staff (not only by me, but by a whole team of tech guys). We haven't done this without a reason.

[Coupe70]

Nico, thanks a lot for explaining !
It's nice to know a bit more about what's under
the hood - makes it much easier to understand
and much more efficient to discuss.

I tend to agree with 3phase in two points:

1) A solid sync at steady tempo is absolutely essential,
smooth tempo changes would be a nice bonus.

2) I don't know much about algorythms, but from what I
understood there must be a better way to deal with
midi clock. I imagine something like a beatcounter:

It's a bit shaky at the first few taps, but gets better
and better by taking the average of e.g. the last 60 seconds.
So it's very precise after 60 seconds while Live's tempo
is still jumping around like at the beginning.
If there occurs a tap that is too far off to be jitter (or
a restart of the clock) it will suppose that there is a tempo
change going on and will recalculate the tempo.

And when Live's tempo is jumping around...is it supposing
that the master is jittering and tries to follow ? But most
likely it's not the master itself, but only the transmitted
master CLOCK, isn't it ? So following the jittering clock
would mean getting out of sync with the stable master...

Hm, just thoughts, I'm not an expert...

[3phase]

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.


Best,
Nico

thats not really advanced thinking regarding the problem and acts from a position like ther wouldnt have been any answers towards this kind of problems during the development of musical sequencers at all.

as said before.. Roger Linn was in the 80s far beyond that point.. An akai mpc 60 or 3000 syncs much better to external clock.. and has a behaviour wher it syncs imideatly.. starts imideatly.. adjust the tempo within the first 16th not..and than gets a at least 1 bar smoothing switched to the process..
so after the initial and really imideate start it gets very slow on tempochanges.. but vrey musical sounding with them..ok..its drums.. so no elastic audio.. but we dont need to use repitch when we want tempochanges...


so to develop start something new and better we start with Roger Linn´s design and expand upon that instead acting like caveman that worship clockjitter.

Thats a bit a regular abeton problem that you sometimes tend to reinvent the wheel.. but as long its not perfectly round..its no wheel.. at least not a good one.. see midi editor and alike...


BAck to topic:.

its no contradiction to calculate tempos between ticks and quarter notes..and whole bars, the complete song ..and interpretate all this info to get to the musical most likely and usefull result..

the common denominator of the distance between clicks that happen between an self adjustable window ..an algo that analyzes the jitter profile of the sytem and is able to seperate between jitter and tempocanges than...

The most likely absolute tempo. how often do we need to correct that assumption of the correct tempo? how many tempo changes within one bar are probably intended by the user?


we analyze the distance of the expected incoming clock position with its real occurance over the entire song length and set this in relation to the musical one..

and so on and so on..

ther are lots of possebilitys to get to better results here..

To find the best way needs some research but just plain first minut brainstorming shows so much more options that you declare here..

sorry..not good enough.. not personal..just your approach that the problem only can be solved with the compromize decission how many bars are taken into consderation to evaluate the tempo is not really 2010 style...

i really think that is a too primitiv aproach to deal with the problem.

At least copy Roger Linns last century algo when you cant come up with something better.

[3phase]

@ NIS

you know what is funny with you ableton support guys.. you allways hit the ignore button or drop support cases when somebody says something that is beyond your ability to understand..

thats actually damaging the company.. ok..you are user support and not company support..

I'm perfectly fine with hitting the ignore button if someone is not willing to cooperate with me when discussing/troubleshooting a problem. My time is limited, so is yours. I know that you're way more clever than most of your posts. You should not waste your time on cursing, but rather concentrate on a rational and meaningful discussion. Anything else is just a waste of time.

Btw, I stated this before: out of ten thousands of users, you are one of 3 or 4 people which have been rejected from Support staff (not only by me, but by a whole team of tech guys). We haven't done this without a reason.

yes..rejected by suport stuff because claiming unreproducaable midi crash bugs month before anybody else..

now how smart is that..

sorry..use your ignore button as you like but that dont makes live a better software

[broc]

But slaving Live to MTC seems a bit unreliable.

Can you describe this in detail?

Ok, after some more testing I have to take it back.
On different runs there are variations during the settling phase, but that's normal I think.
So with Logic as master I'm always getting perfect sync after about 2 bars.

[White_Rabbit]

where is this ignore button [nis]?

Has anyone besides 3phase come up with a workaround to the sync issues? I've only been in the position of being effected by this a few times (I work in the box), but would looping a clip that is sending out midi note/CC to an external devices tap tempo work? or maybe I don't fully understand the issue

[3phase]

But slaving Live to MTC seems a bit unreliable.

Can you describe this in detail?

Ok, after some more testing I have to take it back.
On different runs there are variations during the settling phase, but that's normal I think.
So with Logic as master I'm always getting perfect sync after about 2 bars.

no no..it works unreliable... depends on the offset settngs in relation to tempo..dont works with session view propperly.. only with arrange..

and ther is no timcode output what clealry seperates live from a daw

[[nis]]

2) I don't know much about algorythms, but from what I
understood there must be a better way to deal with
midi clock. I imagine something like a beatcounter:

Unfortunately it's not enough to feed the slave with a nice looking tempo. Lets's assume the beatcounter algorithm would calculate a tempo of 120.05 BPM (which wouldn't be very bad), then the slave would run fine for a short time, but then it would drift away. Even if it was possible to transmit a 100% accurate tempo information to the slave, they would still drift away, because your sample rates aren't running in sync either. You have to permanently resync the slave's transport to stay in sync, which is not so trivial.

Best,
Nico

[luddy]

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

Hi,

Thanks for responding, this is an interesting discussion.

No, actually tempo maps are *less* relevant for MTC sync. As I'm sure you know, MTC is simply linear timecode. It is very common for example to sync a tape drive to a DAW using LTC. A tape drive obviously has no notion of "tempo map". The same is true for syncing a DAW to film, which also has no notion of bars and beats. The DAW has the tempo map notion, but the other MTC-synched devices need not.

To accomplish sync by MIDI clock, however, the master and slave must agree on all tempo changes. As I say, ordinarily this is done by having identical tempo maps on slave and master. If you do not have identical tempo maps, then the slave will be "surprised" by the change in time between successive clock tick messages, and will have to understand that a tempo change has occurred after it has actually occurred. At a bare minimum, it would be 1/24 of a quarter note before the slave could possibly become aware that a tempo change has occurred. If an accurate tempo map is present in the slave, then it will know on its own to expect the clock ticks to arrive at a different rate beginning with the first downbeat of a tempo change.

In Live, however, there is no rigid notion of "tempo map" because the tempo can be controlled very dynamically. What I'm saying is that I don't see how it can possibly be that Live can be expected, in its role as MIDI Clock Slave, to lock up immediately to a tempo change. I believe that you have already said the same thing when you wrote earlier that to steady the clock would require a longer window of resolution, at the expense of poor response to tempo changes. This problem simply doesn't occur at all in an environment where tempo maps are fixed and identical on master and slave.

MTC sync for Live would simply mean that the transports are moving at the same rate, irrespective of their respective tempo maps. It would have to be independently guaranteed by the users of master and slave that they agree on tempo and bar/beat boundaries if that is what is desired from the sync.

-Luddy

[3phase]

2) I don't know much about algorythms, but from what I
understood there must be a better way to deal with
midi clock. I imagine something like a beatcounter:

Unfortunately it's not enough to feed the slave with a nice looking tempo. Lets's assume the beatcounter algorithm would calculate a tempo of 120.05 BPM (which wouldn't be very bad), then the slave would run fine for a short time, but then it would drift away. Even if it was possible to transmit a 100% accurate tempo information to the slave, they would still drift away, because your sample rates aren't running in sync either. You have to permanently resync the slave's transport to stay in sync, which is not so trivial.

Best,
Nico

nobody said its trival..but possible and it was possible 3 years ago aswell.. or 5 years ago..

will you ever get up and face the not so trival task to resync? maybe every 4 bars but within that 4 bars
the tempo stays unchanged? except the tempochenge dedetection realizes a continous change that is above the jitter window the jitter profiler has stablished?

Many sync experiments have shown that a slight drift sounds much better than a wobeling timing..

its better to let it drift for a while than changing the tempo multiple times within one bar..

especially when the resyncing is done shortly before the one ofa new bar that sounds rather groovy

people that do modular synthesis do this all the time even with pretty huge tempo derivations..



or an learn ability.. live memorizes the sync tempo results from the previous run.. and cerates an own tempo map that aproximates most likely tempo start end end results ( no 122,98876 bpm for example.. just estimate its 123 ...) and brings this into the sync equation on the next runs..therfore operates with much higher resitance towards changes than in the first runs

when the projekt has run a certain amount of times it just sticks to the learned tempo and only resyncs slightly when necessary in the above mentioned fashion any 8 or 16 bars. the user has to reset the tempo interpreter to allow quick tempochanges again...

or like in the old mpc..the user can set a manual start tempo and the initial calculation stays on that..

might be even beneficial to force the sequencer to stick to the set tempo even when the master is not matching or precise.. so your ableton runs on 120 regardless wjat the master is doing..
resulting in little jumps at any definable resync point.. you can press the recalculate button and than its holding this tempo with smaler or no jumps at the resync points..

Thats more a worst case free syny szenario..buts more musical..

much more musical than random jittering and an allways fluctuating tempo

its not necessary to handle this on the trival level as its done now.

Ableton is really not very creative regarding the matter..

And therfore we users need to pressure them to do somethng better than a most primitiv implementation..

its bad that the real DAW´s all have the politics or bad ideology that the DAW is the main clock source of the studio..
true in the studio in most cases..but not on stage or for laptop bands..

its a live thing theese clocking..

but.. because the big DAW´s never went to the problem and solved it, there is no one that has showed little ableton how to do it wright and so they assume it cant be done or is to tricky for them..

the are not even able to question themself in this regard.. ableton is clearly the wrong name somehow..

doitlaterton maybe, or cantfixitton or inferiorton, or bugleton, fiaton

whatever..

the statements of the ableton representiv shows that we cant expect working sync with ableton anywhere soon and the tendency is clearly that it even getss problematic now as master..

unusableton !! thats the name

[3phase]

just to mention one more rare sync tactic..

having a sync point at every bar.. adjusting the tempo 4 times within that bar.. shortly before the next quarter..
having the fixed tendency having the first quarter faster..the second slower.. or was it the other way around?

this is called pushpull timing and overrides the typical jitterish fluctuations within the bar with a higher derivation within the quarters but trys to be exact on the next one.. even when it fails in this aproach the meta groove will overide all tiering sub jitter fx and the result will sound very groovy and tight even when beeing evrything else than precise..

thats a tactic how to deal with very bad internal process timings and rather for drummachines than for daw´s where we actualy would like to have no brown henke dither even in external clock sync..

what is actualy only possible with the tactics mentioned in the earlier posting wher you lock the tempo and life with the litlle resync jumps at the syncpoints..

not trival indeed..

i would say that there defently has to be more sync options like there are more than one dither option..

but while we dont hear much or nothing from floating point dither options.. we well have a huge benefit from the sync options

especially because sync options are not really part of the song date ..they can be updated or additional tactics could be implemented without screwing with the content.

something like a sync algorythm plug in.. how to deal with incoming clocks..

i showed that there defently more possebilitys than just calculating the tempo two times within a bar where you know that this have to lead to wrong results..
especialy when they just calculate the tempo on the half bar..

so measuring the distance between first and tick 48 ??

no way.. they cant be so primitiv.. the equation is to measure the distance between each tick and building the common denominator of the first 47 measurements...

everything else is bullshit

i am afraid to say.. when i look at the jumping bpm counter...
it looks like the bullshit implemtation...

QUESTION TO ABLETON:

have you done the bullshit and mathematically not coreect implementation?

Than you allready would have a great improovement by adding the 2 or 3 lines of code that build a common denominator on 47 measurements..

on many systems the result of the eqaution probably would be the desired tempo..

but ok.. maybe the internal process jitter is so bad that the wright implementation with the denominator gives such bad results allready...

but do you build a denominator of the the tempo result between each clocktick or just do it in half bar jumps wher you actually measure more or less the jitter of the last incomming clock .?

at least the the last error of the last incoming clock will dominate the result.. all others are ignored when you only measure over the complete half bar distance.. so only on rare ocasions you will hit the wright tempo.. only when the last clock arrives unjittred..

is it now like that?

[Domlnlc]

+1