Fix the sync issues now !! yes or no ?

[3phase]

dejittering is a must..

and i am sure that ableton is building a common denominator on every 48 messurements..

everything else would be really stupid.. because you loose reaction time on tempochanges but still have the same thruput of jitter.. only your tempo display looks better..

that would be really monkey style.. no way..

or?

[Machinesworking]

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.

Christ Nico, here we go again. How on gods green earth is it not Live's fault if with the exact same machine under the exact same conditions DP and Logic which I also own run beat clock just fine? If there's any solid indication in my mind that it's either Live, or some extremely touchy setting you must implement in Live it's the simple FACT that DP and Logic sync the Evolver with no real issues. If Logic and DP can both run sync on my machine, then it's Live that has issues with some device or another etc. That still doesn't make Live the king of stability when it comes to sync, period, no matter what optimal conditions you guys run Live's clock (through Python? are you kidding?), too many other people have drift, and saying it's not Live when other DAWs simply do not have this problem on my system indicates IMO that at least one of these are true:

1. Live has issues with some driver or another that other DAWs do not have. - Live's problem with a touch of the other manufacturer maybe.
2. Live has issues with settings in it's preferences that are not normal- IE I have 5 devices set up as control surfaces. - Live's problem
3. Live has issues with the MTP/AV arguably the best MIDI interface made.
4. Live has issues Some actual piece of hardware that other DAWs do not have. - Live's problem

This would be so much more frustrating and annoying if I only owned Live, and I would believe you that it's obviously something wrong with my system not Live, but having Logic and DP around proves that it's not "me", it's Live. I simply cannot buy that Live has a stable Beat Clock Sync, if anything it's touchy as hell, as it's obviously not able to surmount an issue that DP and Logic can, period. In this case you keep on refusing to look for a problem with Live, even though I'm able to verify that sync is capable with my system, I'm not happy about that. It's almost funny how you keep ignoring that little nugget, that Live is the only DAW on my system incapable of syncing the Evolver. What exactly explains this to you? What exactly do Logic and Digital Performer implement in their Sync that Live does not?

[Coupe70]

Maschinesworking, you could also use http://midiclock.com/
and try it as another clock source for your Evolver.
http://www.midiox.com/ can generate midi clock, too.
If all these work and Live doesn't...well...


As I understand it Live as slave is not very good at
syncing to a jittery clock, but a jittery clock is
nothing special when using hardware midi interfaces.
Is that correct ?
So if for example http://midiclock.com/ can do it better
and is able to generate a jitterfree clock from a
jittery clock, can you send this stable clock to
Live via MidiYoke (without hardware interface) and
Live will run smooth ?

[3phase]

Maschinesworking, you could also use http://midiclock.com/
and try it as another clock source for your Evolver.
http://www.midiox.com/ can generate midi clock, too.
If all these work and Live doesn't...well...


As I understand it Live as slave is not very good at
syncing to a jittery clock, but a jittery clock is
nothing special when using hardware midi interfaces.
Is that correct ?
So if for example http://midiclock.com/ can do it better
and is able to generate a jitterfree clock from a
jittery clock, can you send this stable clock to
Live via MidiYoke (without hardware interface) and
Live will run smooth ?

you dont understand.. live is not good on a 100% stable clock.. it cant calculate the source tempo of the master properly and is jumping around with its tempo all the time waht usually dont sounds good at all


and ther are big problems with external start commands to


and ther are new problems that the own live clock has atsrted to glitch when using plug in sound generators..

and ther is no timecode output

and its not workng propperly on timecode input..

its actually pretty messed up.. and like with the stability of L8 they just dont realize.. ignore..
think its user errors.. act stupid and arrogant..again..
introducing the bridge now.. wher live is suposed to sync with timecode records??

sorry..thats a rather offensiv kind of ignorance.. gettimg the own syncability via midi getting worse and worse but installing new features only a handfull lamo dj´s will see beneficial instead doing first things first...


of cause they wont answer my question how theire clock sync works...

what is a pitty..because i would like to know..

on the one hand i dont thinl that they are so stupid that they really only measure twice.

the probably evaluate the tempo twice but measure any clock tick how such algorythms usually work... since decades..

but than.. we are in germany..and germans ..even well ducated ones sometimes do very silly things.-.its genetic somehow...

so its ctually possible that we hae bad slave syncng for years just because a little brainbug...


that would be extremly silly in a way..
but.. easy to optimize...

when they have done it wright but what we have now the best a simple algo can bring.. they should abandon quick tempochanges.. or have them with a checkbox.. that would be also make things much better.. quick to implemet..could be ther in the next beta..

but they ignore the needs of the users.. serato bridge first.. somehow a scandal.
again

[[nis]]

Christ Nico, here we go again. How on gods green earth is it not Live's fault if with the exact same machine under the exact same conditions DP and Logic which I also own run beat clock just fine?

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?

I simply cannot buy that Live has a stable Beat Clock Sync

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

1) midi clock out of Live is very good on apple computers... close to the clock quality of an atari computer...
This wasnt all times like this..... but on actual systems we have clock jitter in the 0,1 ms range.. not 2 ms like in eralier times...

Live was much better than logic in this disziplin

-> http://forum.ableton.com/viewtopic.php?f=1&t=132639

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.

I'm afraid I can't do more for you than suggesting the things above.

In this case you keep on refusing to look for a problem with Live

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?

[3phase]

Christ Nico, here we go again. How on gods green earth is it not Live's fault if with the exact same machine under the exact same conditions DP and Logic which I also own run beat clock just fine?

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

now thats a show stopper..

is it possible that you tailor the program more and more towards the playback artist?

why not calling it replay than or mag.musimaker..


Ad that my question about the syncalgorythm is ignored states that you done it the silly way?

really ?
ableton at work

[Tone Deft]

be cool 3phase, name calling at Ableton won't help your cause. you've already ticked them off to the point where they openly say you're on the ignore list, yet here they are replying to you. be cool man.

[3phase]

be cool 3phase, name calling at Ableton won't help your cause. you've already ticked them off to the point where they openly say you're on the ignore list, yet here they are replying to you. be cool man.

when they really have done theire clock sync algo without rounding i havent even started calling them names... i still cant belive it.. but the reaktion points very much to it.. what a shame...

[[nis]]

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?

[[nis]]

Rounding what, calling who?

I'm out.

Ciao.

[3phase]

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?
.

[3phase]

Rounding what, calling who?

I'm out.

Ciao.

the question if your clock sync algo that measures the tempo twice the bar is using a rounding of the 47 possible mesurements one can do in a half bar or just measures the tempo with one measurement to calculate the time passed between the first and the 48th clock tick?

your statement just talks from mesuring tempo.

In a normal world you measure tempo by rounding the result of the distance between the single allready passed clockticks..

so ..have you done it this way?

or the unbelivable way ? wher you take all the jitter possible into the result and pass it along instead eliminating or reducing it mathematicaly..

[Mr-Bit]

This thread + Venetian Snares: My So-Called Life = entertainment!

[broc]

Seriously...

I've built a simple Max patch that receives MIDI clock and calculates tempo from it.
For this I'm using the average value of the last 4 clock intervals.
And for me the resulting tempo fluctuates only about 0.1 BPM.

So it seems in fact that Live does something basically wrong.

[3phase]

Seriously...

I've built a simple Max patch that receives MIDI clock and calculates tempo from it.
For this I'm using the average value of the last 4 clock intervals.
And for me the resulting tempo fluctuates only about 0.1 BPM.

So it seems in fact that Live does something basically wrong.

i really getting this idea also.. my clock measuring tools are quite simple reaktor patches and are very accurate..

i have no idea how horrible the process jitter inside ableton life really is.. i just measured how the clock gets disributed thru the core audio/midi system.. thats allwright..

but no idea what happens inside ableton live than...

in any case they need to improove it... but when this is all based on a very stupid unmathemtical implementation.. sorry.. the should feel ashamed and fix it over the weekend and dont let us wait any longer.. when you deal with clockjiter its the most normal thing to aply some rounding..thats the way its done since midiclcok exsistss..

so.. it actually cant be.. just strange that there is no clear statement that rounding is of cause involved on the two tempo measurements per bar...


if not please ad the little code that would allow the program to get a correct tempo reading at least once in while...