Fix the sync issues now !! yes or no ?

[broc]

@Machinesworking

To check the timing of Live as MIDI clock master please try this.

Route MIDI clock output from Live to IAC and observe it with the Midi Monitor app.
Set Live's tempo to 125 BPM. This means that the clock intervals will be exactly 20ms.

For me the monitor shows that Live sends the clock with perfect timing.

[3phase]

@Machinesworking

To check the timing of Live as MIDI clock master please try this.

Route MIDI clock output from Live to IAC and observe it with the Midi Monitor app.
Set Live's tempo to 125 BPM. This means that the clock intervals will be exactly 20ms.

For me the monitor shows that Live sends the clock with perfect timing.

the timing is ok.. but when the evolver dont gets it mabe something else is going wrong..


are you sending midiclock in pattern or in song mode?

and is the clock drifting, wobbeling or just out of time? ther is no scenario in live wher you can run midi clock without offset delays.. thats different to the other daw´s

so dependent on the audio latency , external synth and interfaces, the clock needs to be pushed usually at least 5 to 10 ms early..sometimes even 20 ms...

[Machinesworking]

Aren't you making it very easy for yourself? "Logic and DP run fine, so it must be Ableton's fault". Even if there would be some weird interaction going on between Live and your MIDI drivers (which I seriously doubt), the only way to find out more is to isolate the problem until you have found the culprit. Have you actually tried what I suggested?

this is getting silly, I'm not trying to argue with you, and I'm not some amateur who doesn't systematically test for problems. I'm also not lying when I say Live is the only DAW on my machine that has issues with being the master beat clock sync for the Evolver. Seriously why say I'm making it easy on myself???? that's just rude. You still refuse to address that Live is the only DAW with issues, and say rude things in response.. I'm not trying to make this personal and I hope you're not taking it that way. It's just that you keep on side stepping the fact that other DAWs are not having this issue, which IMO very heavily suggests Live has issues with something on my laptop that may very well be Live's issue, otherwise, why would other DAWs not have issues?? Yes, I plan on removing all drivers and testing with the RME only. My hunch is Live and Automap are to blame, but it's only a hunch. Automap has never been the most stable app under Leopard, sometimes it needs a force quit etc.

Ok, if you don't trust me, would you trust 3phase, the starter of this thread, who once wrote:

Point is if Live has sync issues due to a set up that both DP and Logic have ZERO issues with, then whether under optimum conditions in a lab Live syncs better than Logic is absolutely irrelevant. Real world VS labs kind sir.

Anyway...whatever it is that's bugging your MIDI clock, the only way to find out what it is, is to isolate it from the source. Try it with the simplest possible setup first and if that works, go a step further.

Yeah I know basic bug finding routines. I'm loath to do it, but I'm about to upgrade to Snow Leopard so it's a good time to mess with the system.

Sorry, but I don't refuse to look at a problem with Live, but as I mentioned before, we have revisited Live's MIDI clock code several times and found no serious issues. So what do you expect us to do now in your case? Go ahead and spend $5000 on the same MBP model that you have, a Poly Evolver, all of the controllers and interfaces that you use, trying to reproduce your problem, just to find out that there's a wrong setting somewhere in your system?

How about first of all explaining to me what this "wrong setting" could be?? I'm all for changing a preference in something to solve the issue, that would be wonderful, but I'm very skeptical, as I have a hard time imagining that Digital Performer and Logic somehow magically are not affected by a "setting", yet Live is?? It really does seem like a conflict with some MIDI device in my system, and that's not beyond rational thinking. A specific DAW can have issues with a specific driver or plug in etc. happens all the time as you well know. Also, really? Ableton don't try to test with different configurations before release? That's how you're reading there, not cool. I would hope with Apples limited product line you at least have alpha testers with my configuration?? It's not Like the Evolver is an an arcane piece of kit? I would hope that Ableton could afford something a painter making less than 25K a year could, otherwise I'm definitely making sure to keep current with Digital Performer!

Just as an idea why I think it's a MIDI driver issue: I have Korg, MOTU, RME, NI MIDI drivers and Novation Automap, plus two USB hubs and four hard drives connected. a Logitech mouse as well.
I'm almost willing to bet it's not RME, but all the other drivers are so so IMO.

[Machinesworking]

@Machinesworking

To check the timing of Live as MIDI clock master please try this.

Route MIDI clock output from Live to IAC and observe it with the Midi Monitor app.
Set Live's tempo to 125 BPM. This means that the clock intervals will be exactly 20ms.

For me the monitor shows that Live sends the clock with perfect timing.

the timing is ok.. but when the evolver dont gets it mabe something else is going wrong..


are you sending midiclock in pattern or in song mode?

and is the clock drifting, wobbeling or just out of time? ther is no scenario in live wher you can run midi clock without offset delays.. thats different to the other daw´s

so dependent on the audio latency , external synth and interfaces, the clock needs to be pushed usually at least 5 to 10 ms early..sometimes even 20 ms...

The timing is drifting, and has doubled in the past. Seems like two different problems, a MIDI loop back to the Evolver making it play another note late, and the Evolver not getting a beat clock signal from Live. I've put Live in both pattern and song mode to test, no difference from what I recall. Yeah the beat being a certain amount of time late is no issue to me, you can compensate for that, it drifting and doubling is another story. I'm not working tomorrow so I'm going to go over this again. I hope it's not one of those annoying things where it now works fine months later, even though it was 100% reproducible in October... bleh. Though I've never had Live sync to the Evolver yet so...

[[nis]]

Machinesworking, my apologies for sounding rude. It really wasn't my intention to make you upset.

I'd propose to look at your case again in detail, if you're still willing to accept help from us. The biggest problem we have is that we don't sit in front of your computer, so we need to ask a lot of questions, try this, try that, etc., which is time-consuming and annoying for you. We could use TeamViewe (http://www.teamviewer.com) and look at this together. I'll send you an email about this.

How about first of all explaining to me what this "wrong setting" could be??

The "doubling" issue that you mentioned could be specific to the MTP AV. I used to have the serial port version of the MTP AV and as far as I can remember, sending MIDI clock to one single output port will mirror the clock on all other ports, except if you disable the "realtime" option for all other ports in the hardware settings. Thus, if you have the "SYNC" option activated on more than one MTP AV port, it will double/triple/quadruple/... the clock. I'm not sure if this has changed in the USB version of the MTP AV, though.

As far as the drift problem is concerned, I can think if several reasons, but they are probably not as easy to solve and may require some testing on your side. The first thing you need to check is if the clock output is stable. Broc has already suggested a good way to check this. If the clock is stable, then there is no apparent reason why the Evolver itself should drift away. Most MIDI devices can handle a slightly jittery clock, meaning that they can at least keep up with the timing and don't drift away, so I don't think that the Evolver is having a problem here, except if Live's clock output is REALLY bad on your machine (for whatever reason). So if the clock runs perfectly stable, then the drift might be caused by an incorrect (drifting) latency compensation in Live. This should usually not happen, but a known issue is that some harddrives can cause a steadily increasing latency on audio interfaces if they are running on the same firewire bus. The reason why you're not seeing this phenomenon in Logic or DP *might* be that their latency compensation just works completely different. Anyway...to check if this is really the problem here, run the "driver error compensation" lesson from Live's built-in tutorials, then wait a few minutes, repeat the test again and check if the re-recorded click sound is still aligned with the first beat. If it isn't, then you can at least be sure that something is not right with the audio interface's latency. Detach all external harddrives and repeat the test again.

These are just a few thoughts. I'm off to send you another email. Please get back to me and let me know if you need some assistance.

Best,
Nico

[3phase]

Hi NIS..

that you dont answer my question wether rounding is involved in your clock slave algo or not is pointing very much in the direction that the Abletons have´nt done theire homework regarding clocking and therfore cant achive a comprehensiv performance.

If this is the case please fix that imideatly because thats so easy that it really hurts that you dont even got that idea. especially on the base of the permanent user request for better clock syncing.

You can include max and serato but cant put 2 lines of code to have some dejittering on your tempo measurement? i still cant belive it really.. but your ignorance dont allows to draw another conclusion.

ABLETON

FIX IT NOW !!

[3phase]

@Machinesworking

To check the timing of Live as MIDI clock master please try this.

Route MIDI clock output from Live to IAC and observe it with the Midi Monitor app.
Set Live's tempo to 125 BPM. This means that the clock intervals will be exactly 20ms.

For me the monitor shows that Live sends the clock with perfect timing.

the timing is ok.. but when the evolver dont gets it mabe something else is going wrong..


are you sending midiclock in pattern or in song mode?

and is the clock drifting, wobbeling or just out of time? ther is no scenario in live wher you can run midi clock without offset delays.. thats different to the other daw´s

so dependent on the audio latency , external synth and interfaces, the clock needs to be pushed usually at least 5 to 10 ms early..sometimes even 20 ms...

The timing is drifting, and has doubled in the past. Seems like two different problems, a MIDI loop back to the Evolver making it play another note late, and the Evolver not getting a beat clock signal from Live. I've put Live in both pattern and song mode to test, no difference from what I recall. Yeah the beat being a certain amount of time late is no issue to me, you can compensate for that, it drifting and doubling is another story. I'm not working tomorrow so I'm going to go over this again. I hope it's not one of those annoying things where it now works fine months later, even though it was 100% reproducible in October... bleh. Though I've never had Live sync to the Evolver yet so...

Is there any evolver editor open when the problem occurs?

any midi monitor on lives clock and any audio representation look perfectly normal..

there are just single bits running that give the clock.. at least it looks like.. when it would be 2 bit instead of one the midi monitors and oscilloscope can be easily fooled..

you would need to watch the clcok in an oscilloscope and measure its pulsewidth and compare that to the logic clock..

Lives midi output seems to dont be very acuate regarding the midi protocol while dave smith was probably involved in the design of the midi protocol...

However. it looks more likely that you have another problem there ..i ve a mopho here that just syncs fine... via rme fireface midi on apple...

[[nis]]

Sure there is rounding involved, anything else wouldn't make sense.

As I mentioned a couple of times before, I'm sure that the slave algorithm can be improved and I'll do my best to give this as much priority as I can, but I'm not the one who decides this.

Best,
Nico

[broc]

Sure there is rounding involved, anything else wouldn't make sense.

As I mentioned a couple of times before, I'm sure that the slave algorithm can be improved and I'll do my best to give this as much priority as I can, but I'm not the one who decides this.

Best,
Nico

Just wanted to add that when using the avarage of 48 intervals, with my Max patch I'm getting fluctuation less than 0.001 BPM (!).

Here are the results for the first 5 bars (with Live as clock master @125 BPM).

print: 125.000000
print: 124.999855
print: 125.000237
print: 124.999878
print: 125.000130
print: 125.000481
print: 124.999931
print: 124.999596
print: 124.999954
print: 125.000069

Maybe you could show this to the developers for reference.
And for anybody interested, here is also the Max patch.

<pre><code>
----------begin_max5_patcher----------
467.3oc0V9sajBBEF+Z8ofP1KmNEPwwz6180noogQYlxFDLHS5rSSe2qf5tS
+OqwRRuABeb3jO9IbvGRSfa0G4cPvUfqAIIOjlj3kbBIiiSfMriURVmOLXCu
qismCWMLmkez50OIqjblYRukYqtSn1eqgWYGxeAZMZE.SwttbhePwZD3lwkr
SqrchSbWzXWrCxhZe90a+8E37ozqNzHTRt06IxYIPwZ7I.9SifIA+RKqOaM5
C1oEgGUGjr+okO3RHDbialGSScMqBDKJ988N7UTo0HT1OfIXhmFYnLemuEW9
eAkMuISvygInkaiyO1Z.DJBs9xerC+4DfTPcca1LCBTrbDHNmJNIAM7ZASE.
WHdhPKlAWnK2sEx6xkUKOa1azGZA4keNcvkktth4buI+6HcrhFtI.tP80Zyn
yfKYQfK6jZlcwgSGW1CB.InSNH+CPzxYPHRDHzVlZ+hCHiUDPImgJwj4TIFG
gJwtGTeFT79CJEpW9iL9snS+4jpSevTMkswumf+sKq4c8XhYEZ0Ywzeq.f+a
L2Ipq49omfPintU2asQK7Ne0VZGghlivA3HRTcTQ.NZSTcDM.GUDUGkEfixi
pixCvQz3dxN+KFR8CdL8ITC6T7M
-----------end_max5_patcher-----------
</code></pre>

[slirak]

live had a good clock output,,but now its glitching when you cahnge the track selection on screen..

You obviously didn't read my post in the other thread, so I'm writing it again: The track selection glitch that you experienced is certainly caused by MIDI feedback (status update) messages which Live needs to send out to remote ports. I assume that you have the "remote" option enabled on a MIDI port where you also send the clock, thus resulting in lots of MIDI traffic which is messing up your clock timing. Have you check this already?

when i give up on remote feedback it will work? i will try that ..thnx

i need remote from my main midi ports.. why is there a lot of traffic when i dont touch anything and just change the track selection?

and why is that new?

and why can any controler action interupt the realtime clock?
that is not conform with the midi standard..any non real time message has to wait when the realtime message occurs.. only sysex comunication is allowed to interupt that.

what are you sending there?
.

Not sure what gear you have, but I had a similar issue when I used the MIDI interface of a Novation Remote SL controller to connect to external gear.

It seems that Novation's Automap server is transmitting and receiving a lot of status updates all the time, even if you don't touch anything on the controller. I guess it has to, in order to correctly reflect any parameter changes in the host. And this constant chattering made external MIDI timing extremely jittery. I'm even talking about plain note on/off messages here. The timing was all over the place.

The extent of the problem actually varied with different Live sets, different Live versions (this was a couple of years ago, so it must've been with L7 or even L6) and different versions of the Automap software. Even though a combination of a specific Live version (L7.??) and a specific Automap version (2.?) made things a lot worse, the problem wasn't confined to Live. Other VST hosts had similar issues. Turning off the Automap server ALWAYS stopped the timing issues.

Now I wanted my Automap server, so I got myself a $20 "MIDI cable" for my external gear. Problem gone.

I don't sync to external gear nowadays, so I really can't say anything about sync issues with L8. But my experience does prove that too much status updates on a MIDI port can make it sweat if it's not up to the job.

It would be interesting to know if Ableton could recommend any MIDI interfaces known to handle this situation well.

[3phase]

Sure there is rounding involved, anything else wouldn't make sense.

As I mentioned a couple of times before, I'm sure that the slave algorithm can be improved and I'll do my best to give this as much priority as I can, but I'm not the one who decides this.

Best,
Nico

Just wanted to add that when using the avarage of 48 intervals, with my Max patch I'm getting fluctuation less than 0.001 BPM (!).

Here are the results for the first 5 bars (with Live as clock master @125 BPM).

print: 125.000000
print: 124.999855
print: 125.000237
print: 124.999878
print: 125.000130
print: 125.000481
print: 124.999931
print: 124.999596
print: 124.999954
print: 125.000069

Maybe you could show this to the developers for reference.
And for anybody interested, here is also the Max patch.

<pre><code>
----------begin_max5_patcher----------
467.3oc0V9sajBBEF+Z8ofP1KmNEPwwz6180noogQYlxFDLHS5rSSe2qf5tS
+OqwRRuABeb3jO9IbvGRSfa0G4cPvUfqAIIOjlj3kbBIiiSfMriURVmOLXCu
qismCWMLmkez50OIqjblYRukYqtSn1eqgWYGxeAZMZE.SwttbhePwZD3lwkr
SqrchSbWzXWrCxhZe90a+8E37ozqNzHTRt06IxYIPwZ7I.9SifIA+RKqOaM5
C1oEgGUGjr+okO3RHDbialGSScMqBDKJ988N7UTo0HT1OfIXhmFYnLemuEW9
eAkMuISvygInkaiyO1Z.DJBs9xerC+4DfTPcca1LCBTrbDHNmJNIAM7ZASE.
WHdhPKlAWnK2sEx6xkUKOa1azGZA4keNcvkktth4buI+6HcrhFtI.tP80Zyn
yfKYQfK6jZlcwgSGW1CB.InSNH+CPzxYPHRDHzVlZ+hCHiUDPImgJwj4TIFG
gJwtGTeFT79CJEpW9iL9snS+4jpSevTMkswumf+sKq4c8XhYEZ0Ywzeq.f+a
L2Ipq49omfPintU2asQK7Ne0VZGghlivA3HRTcTQ.NZSTcDM.GUDUGkEfixi
pixCvQz3dxN+KFR8CdL8ITC6T7M
-----------end_max5_patcher-----------
</code></pre>

PS.
Nevertheless I think that slaving DAWs to midi clock is questionable (as luddy has pointed out).

with correct rounding to the last two digits.. ( not truncation) this would give 125.00 bpm constantly ..
as wished

but.. i gues your patch is feed by the internal clock within ableton ? or is it fed from the midi ports?

nis states ther is rounding involved because it dont makes sense otherwise...

so the abketon problem is burried deeper in the structure..

however.. when the actual rounding bring such bad result the amount of measurements has to be risen..

the natur of dither is that it has a random disrtribution..everything else is drift...

so with a big enough analisation window and propper rounding you get the correct bpm reading...

however... in case of incoming clocks that sit on something like 125.0001 bpm you need a corection algorithm that resyncs form time to time in usefull musical intervals

from my experiance and tests i would says that the positional error that is allowed has an absolute maximum of 2 ms...

the real suitable error window is rather 1 ms.. at that point the correction should start and reallign the slave to the incoming clock ticks.. so it has some time to react in usefull rhytmical intervals..

the goal is to have as long passages on constant tempo as possible

in the moment we have a positional error on incoming clock position on steady tempos of up to 5 ms within any single bar..

thats really not especially good.. in general the brain interprets suffen rhimical jumps rather as groove as it would do with random wobbeling around.. teh only thing ableton has achived yet is to reduce the jitter rate on external clock.. so its not so super nervous anymore.. as more nerveous a jitter gets as more ungroovy does it sound.. while a very slow jitter is sometimes sold as human factor..
in this regard sometimes a smaler evaluation window that does exact quarters can be better than a slightly bigger one..depends.. the tempo has to settle on the musical chunk.. so the new tempo should be set on before the next downbeat and not after..

But for the time beeing a longer count perioud would be a quick fix that would suit many users..

also... they could apply some kind of oversampling on the counting / tempo measurement process..

so you can combie a better statistic smoothing of the results with still quick reaction to tempochanges.. so the tempo will still start to follow after a half bar or even quarter bar, but needs a longer time to do that.. rubberband sytle.. i think this will sound musical correct..at least not nasty and gives the main purpose to keep the tempo a much better chance..

see it like ist is.. tempochanges are either slow rises and falls..or they occur in breaks..
when its a break it is allowed to sound a bit weard..

check with the old akai mpcs.. the rubberband tempo follow is actually nice when you are not so anal about tempo changes..

be anal about timing stability.. thats more fun )

[broc]

but.. i gues your patch is feed by the internal clock within ableton ? or is it fed from the midi ports?

Actually it's fed from IAC, i.e. midi port.

[3phase]

but.. i gues your patch is feed by the internal clock within ableton ? or is it fed from the midi ports?

Actually it's fed from IAC, i.e. midi port.

the iac is giving a clean clock.. at least in standard load scenarios.. the apple core midi is pretty good..

its really an interesting question why ableton live has to jump so much around on a steady clock and not just takes the tempo.. it should be easily possible to have the fluctuation only in the +/- 0.01 bpm window on a steady clock...

so clearly something is not done wright there....


I once had a little discussion with one of the developers here in the bug forum regarding the item..

the guy wasnt aware of the precission we have inside an apple computer theese days.. he said the best you get from the incoming clock is +/- 2ms jumps...

thats windows reality or earlier mac os reality too.. but gone on the apple side since at least 2 years now...

I guess.. the did an implementation based on the assuption that it wont get any better than 2ms jitter.. and so the program is still jumping around 2ms style even when this is toatly not necessary anymore...


However.. its defently cear that the clock thing is low on the too do list of ableton.. otherwise they would have checked by now that the 2ms jitter thing is not common reality anymore in midi land..

they just dont look into this kind of details at all..

so i would wish more people would vote in the poll.. i am very sure thats more than 10% of the user base that wish propper syncing..

[broc]

its really an interesting question why ableton live has to jump so much around on a steady clock and not just takes the tempo.. it should be easily possible to have the fluctuation only in the +/- 0.01 bpm window on a steady clock...

so clearly something is not done wright there....

Yes, seems quite obvious to me.
So let's hope this thread will trigger some improvement in the near future.

[3phase]

its really an interesting question why ableton live has to jump so much around on a steady clock and not just takes the tempo.. it should be easily possible to have the fluctuation only in the +/- 0.01 bpm window on a steady clock...

so clearly something is not done wright there....

Yes, seems quite obvious to me.
So let's hope this thread will trigger some improvement in the near future.

hope more people vote.. they must know that they suck regarding the syncing..
especially in a time where people start to jam again and bands and laptops dont exclude each other its a middle design crime to react so slowly to the demands of the user base...

what a stupid missconception that timecode records will open them an additional market, when they have prooven that you cant even sync 2 laptops that run ableton live with each other...

and waht a slap in the face of the user base when they succed with syncng to serato before they have even tried to fix theier midi sync issues..

issnt it much more likely that ableton users want to jam with other ableton users then that dj´s like to work with ableton live?
and that in times where many clubs dont even have record players anymore... what a futuristic aproach..

i really say safe the vinyl.. but saving the vinyl equals to get rid of ableton acts... somehow,..

can´t really understand that weard serato marriage.. but ok.. its theier thing.. but please first things first..

please vote to show them that they have waited to long to touch the sync problems..

we need at least 40 more to vote yes for quick fixes...