Live Midi Sync Restrictions explained!

[evoid]

hey guys,

i'm also very interested in this topic, has for i use live Live, with almost no playback (with a complex set of max sequencers, wiimotes, and lemur). on top of that, i play with another musician and sync with his gear trough midi clock.

i don't know a lot of technical stuff about OSC, but wouldn't it provide a better solution for the syncing problems?

[dom]

First thing to do in case of timing problems would be going through the midi fact sheet you can find in the manual, considering the given tips there.
Before releasing Live 7 we did extensive midi timing, syncing and jitter tests and came up with this fact sheet in order to educate about this topic.

If you still encounter Midi timing problems don't hesitate and send us a detailed description of your setup and your settings to support@ableton.com

As long as the midi drivers and the external gear behaves correctly, you can sync external gear to Live as tight as the midi clock specification allows - but it's the nature of midi that it introduces jitter - so phase cancellation is obviously not possible (the same applies to MTC, there's also jitter involved and the midi specification already reveals that sample accurate syncing using MTC is NOT possible, again contrary to Timur's guesswork in this thread).

Even if i repeat myself and some people still doubt it: There's no value rounding being done regarding the receiving or sending Midi clock messages from/to the midi drivers in our engine at all, as a slave Live constantly calculates the tempo from the incoming midi clock and adjusts to it - the tempo field showing only full decimal values is only a GUI thing and a specification decision in order to avoid confusion for the user - due to the midi jitter and the engine constantly using the exact calculated tempo, the position after the decimal point would flicker constantly. This leads to the different tempo display readings in Timur's screenshot if you compare the tempo fields of Live being master and being slave.

However, while fiddling around with Timur's test setup i found one real technical issue: While being slaved Live uses the exact calculated tempo from the received midi clock while showing a rounded value in the gui, as i already explained - but regarding the VST hosting it seems to send the display value over to the VST protocol and therefore to synced VSTs (as in his kontakt screenshot) instead of the real engine tempo.

If this is really the case in the code, it is obviously wrong and means if you slave Live to a midi clock running at a tempo that's not a full decimal value and use a VST in this slaved instance of Live that syncs its tempo to the host, you would get wrong timing in the plugin compared to the slaved host it is running in and the midi master.

This would clearly be a bug and we will investigate this now.
Even if the initial presumptions were wrong, thanks still go out to Timur for sending me on the right track for finding this issue.

Cheers,
Dom

[Lo-Fi Massahkah]

And by Timur, you mean Crash?

.m

[Crash]

If you still encounter Midi timing problems don't hesitate and send us a detailed description of your setup and your settings to support@ableton.com

Yes, please do that. But in case that all you get back from support is "Sorry, we cannot reproduce this here!" then you come back to this thread and learn about some of the culprits and hopefully some workarounds.

As long as the midi drivers and the external gear behaves correctly, you can sync external gear to Live as tight as the midi clock specification allows

That's what I said in my original post, Live delivers a stable Master Midi Clock upto your systems capabilities (at least on XP), any timing problems are likely caused by other factors!

But I can even go further now and will reveal how much driver implementation of a single interface can affect performance of all interfaces on the system. That's expert information that cannot be found in the dumped down Midi Fact Sheet (which is great for beginners though). I will post the results in one of my next posts and modify the original post accordingly.

- but it's the nature of midi that it introduces jitter - so phase cancellation is obviously not possible (the same applies to MTC, there's also jitter involved and the midi specification already reveals that sample accurate syncing using MTC is NOT possible

For you it might not be possible, for me it is. Maybe that's what separates the men from the boys. I can provide audio files that prove that.

Now, where are we wrong? I can tell you, I was using a Master Midi Clock signal created by Midi Ox running its signal in different tests both through virtual Midi ports and physical loopback Midi ports back to two instances of Live running on the same PC, both being slaved to the very same Midi port and thus receiving the very same completely identical signal, no difference in jitter, latency or whatever! !!! !!!!!!

And guess what? If both instances receive a Midi Clock signal instead of MTC they cannot ever sync but keep drifting around each other. That's OK, it's probably just a few samples, but it happens eventhough they receive the same clock and should calculate the same value just like with the MTC clock. One just needs to know that and work with it.

again contrary to Timur's guesswork in this thread).

I seriously ask you to stop calling my hours of trial-and-error work with dozends of setup combinations, faithful documentation with Screenshots, Videos and Audiofiles and workload of writing this down for the community "guesswork", "fiction" or whatever.

Just because you are too ignorant, unknowledeable or simply stubborn to reproduce any of my findings doesn't mean you have any idea of what I'm talking about. I've thrown so many valuable informations at you during the course of the last years and all you can do is ignore the evidence and stupidly repeat the same stupid nonsense everytime some complicated matter comes up. This is really getting on my nerves, I have never encounted a supposed technology expert who has so few arguments in his arsenal to positively and creatively backup his standpoint instead of just calling every complicated matter off.

And believe me, I have had conversations with various tech experts of very different fields. These people had the knowledge and very potent arguments of a scholar in their field to reveal my own half-knowledge status when we were discussing their specific field of expertise. I don't see anything close to that coming from you, just dumped down polemics.

Gdmnt, I mostly know what I'm doing here and want serious discussions with people who care to understand the material I am providing and either help proving errors in my own findings or errors in the application. You ain't providing any of these, so either stay out of my threads and help some noobs or go home or start taking this serious and giving us something useful to talk about.

Even if i repeat myself and some people still doubt it: There's no value rounding being done regarding the receiving or sending Midi clock messages from/to the midi drivers in our engine at all, as a slave Live constantly calculates the tempo from the incoming midi clock and adjusts to it

Stop repeating, start explaining! I posted an audio example that clearly shows how two instances of Live produce serious phasing sounds only when non-full BPM rates are used (like 127.5 BPM in the example). The audio sample was created using Session View AUDIO CLIPS (NOT, NOT, NOT a Plugin!!!!) running in "Repitch" Warp mode. How can phasing sounds happen only at values inbetween full BPM rates if what you say is true? The very obvious phasing stops instantly once a full BPM value is send from the Master (like 127, 126, 125, whatever).

This would clearly be a bug and we will investigate this now.
Even if the initial presumptions were wrong, thanks still go out to Timur for sending me on the right track for finding this issue.

There was nothing wrong with the "initial presumptions":

While Live definetively uses BPM rounded to full digits for VST plugins it seemingly uses different values for playback of clips and maybe even for its own internal plugins.

If that is true, that VST plugins use a fixed tempo via VST clock while Live internally uses slightly drifting Midi tempo then synced VST plugins (like synced Delays) might get into drifting troubles within their respective Live hosts, too. I did not check that though.

If you'd spend half the time carefully reading the informations and reproduction instructions I am sending you then you could save yourself alot repeating: "We cannot reproduce this here!" Well, at least this time you could reproduce an issue that literally jumped at your face. Jsschrst

To all the other readers: Sorry for the many bold and underlined passages but sometimes you need to HAMMER things into some people's head until they realize what you are trying to tell them. I guess Ableton would prefer just lots of jaddajadda kids as customers, would make their Live easier (pun intended)!

[8O]

Timur/Crash - jeez, seriously, take a chill pill, relax... Try to put this all into perspective, it's not worth getting so furious about - it's only midi. Have a beer, take it easy...

[Crash]

Believe me, I'm very chilled about the flaws in Live as long as they are just somehow, anyhow handled. Even if that only means that someone says "Hey, we know this is a drawback, we cannot do it better right now. Please try to work with it the way it is."

What is really getting on my nerves after the many months of dealing with Ableton is the ever recuring "Everything is great! No errors here! This is not the issue you were searching for! Go on! Go on!".

And what right does DOM have to just come around to call my thread a figurative pile of shit without providing any useful argument to the discussion? He is actively trying to keep users from helping each other out where Ableton support repeatedly failed. The failure is bad enough, but preventing us from helping each other is

[dom]

again contrary to Timur's guesswork in this thread).

:x
I seriously ask you to stop calling my hours of trial-and-error work with dozends of setup combinations, faithful documentation with Screenshots, Videos and Audiofiles and workload of writing this down for the community "guesswork", "fiction" or whatever.

Sorry, but I never did that or intended to do so.
Please stick to the facts and what i wrote:
"Live's engine rounding incoming midi clock" and
"MTC is sample accurate" was what i declared as being "guesswork" and "fiction".

I also never questioned the quantity of your tests or how many hours you put into your hobby.
Far from that, i thanked you.

Besides that i find your post pretty offensive and to be honest i'm personally not very interested in discussions about your personal tests and assumptions and try to concentrate on correcting false statements that may confuse new users not being familiar with your personality.


Good night, sleep tight!
Dom

[Poster]

@ Timur

what made you decide to buy Live?

you were testing the beta and demo to the fullest,
ordered it while you knew about a lot of personal issues..
you even had the ordered package on hold at the post-office..
so all in all a well thought out decission no?

so what's Live offering you?
why do you use it?

[Crash]

@Poster

You miss the point of this thread. Here I am working with what Live has got and trying to help other people with their Midi Sync problems. Besides that not every bug/issue I report about affects me personally. I often just happen to stumble upon them and then report them, so that support/development can work on them and so that other users know about the pits before they fall into them.

Besides, this is not just some "hobby" of mine. I'm getting paid for playing live (and paying taxes) and I don't want any of this sh*t to happen while I'm on stage. Because of that I'm doing all these tests to better know Live and my whole setup inside out and to prevent many problems before they happen.

Unfortunately Ableton Support calls my thoroughly worked out results "Fiction" and "Guesswork" instead of providing own arguments. Fortunately I currently don't need to Midi Sync Live as Slave to other gear. There are some other issues which I really want to be looked into and possibly fixed and the whole summed up problem buildup (including DOM's attitude in this thread) has lead me to believe that Ableton Support isn't worth my money. On the other hand the unique features of Live's Session View still is, but I really hope that some competition for that comes around the corner someday, because I begin to curse the consequences of that "uniqueness".

Anyway, this is no Bugs & Problems thread, because I don't expect these issues to be solved/fixed, this is a "know the culprits and find workarounds" Tips & Tricks thread. If you don't find any valuable informations in here, don't waste your time reading.

[Poster]

@Poster
You miss the point of this thread.

hmm.. I don't think so..

sorry to hijack your thread.. please continue.. cheers..

[Crash]

Now back to the point:

We had mixed results, under some conditions it worked great, under others it was horrible (drift, going out of sync etc.). This might be related to circumstances where we have a huge amount of midi-data coming in (osculator/wiimote/IAC-driver with midi-loopbacks and reacTIVision).

Yes, huge amounts of incoming data seems to be a problem for Live. The following screenshot was made with the Master instance of Live sending out four (4) fully loaded Midi ports of data (12.500 bytes/s) via MME on Windows.

The sending is no problem for Live per se, it can send as much as the driver(model) permits (like upto 16 full blowing ports over MidiYoke). But receiving doesn't work that well if lots of Midi data is coming in. Can you guess the error in the following picture?

But if the sync comes in on a different port, then it shouldn't matter so much, or?

In theory no, in practice, see the above picture. This depends on the driver model being used. MME behaves different on Windows than DirectMusic and I expect Mac's Core Midi to behave different to both of these. On Windows with MME one single Midi port driver can drag down the whole MME subsystem, that's not a fault of Live!

You can do some tests on your own:

1. Run both instances of Live in Sync via a dedicated Midi port at 120 BPM.

2. Create a Midi Track in the Master instance that play five (5) simultanous 1/16 notes in a 0/0/1 loop and send that out via IAC to the Slave instance. This corresponds to 240 Bytes/s (~13% Midi load per one port).

3. Open a receiving Midi port in the Slave instance of Live.

4. Create an Impulse Midi Track in the Slave instance and make it receive the Midi Data from the Master instance (this is not necessary, but helps to get an idea of receiving data).

5. Put a looped Audio clip into the Slave instance of Live and set Warp method to Repitch. Make sure the original Warp tempo is set to 120 BPM.

6. Start Playback on the Master instance of Live.

7. Duplicate the 5-note Midi track in the Master instance. If you use Arrangement for the Midi clip you can keep playback running. If you use Session then Stop and Start playback after duplicating the track.

8. Thirteen (13) of those 5-note Midi tracks correspond to full load on a single physical Midi port of 3120 Bytes/s.

9. Keep duplicating Midi tracks. If IAC is limited to physical Midi bandwidth it may stop the port as a form of "feedback detection". If IAC doesn't care for that you can go on duplicating.

10. The bandwidth of four (4) full blown Midi ports is reached at 52 Midi tracks, but since I used 240 BPM in my screenshot you either need to use faster tempo, too, or keep duplicating Midi tracks. As soon as your Slave instance of Live starts drifting you will notice because of the repitched Audio clip.

11. The above was a pure theoretical test that tries to bring some method into the whole process. Replace the Master set with your own Set (the one with the "huge" amounts of data) and see how the Slave behaves.

[Crash]

sorry to hijack your thread.. please continue.. cheers..

Sorry, I edited my last post adressed to you just before you answered.

[Poster]

(including DOM's attitude in this thread)

Dom is one of the most polite Abes I know.. and has been in this thread..

just learn to accept that your analyses are not 'the' truth by default, or are immediatly granted as true..

anyway..
all I wanted to know is why you bought Live while you knew it has many flaws (from your p.o.v.)..

[Crash]

(including DOM's attitude in this thread)

Dom is one of the most polite Abes I know.. and has been in this thread..

Generally I do agree with that (although some suggestions are not so polite anymore). This is not my problem with Support. Ignorance of evidence and lack of results is.

just learn to accept that your analyses are not 'the' truth by default, or are immediatly granted as true..

Well, no problem with that. Could you then please explain what I could have done wrong to produce the results (screenshots, audiofiles)? If Live slaves correctly to non-full digit BPM, can you explain why repitched audio clips only phase on non-full digit BPM but not on full digit BPM?

all I wanted to know is why you bought Live while you knew it has many flaws (from your p.o.v.)..

1. My bandmate used it already so I had to catch up.
2. I had more trust in support and development to work on the flaws once they are provided with enough informations.
3. There are not any seriously competing products on the market that offer the non-linear concepts of working in Session View without a timeline.

[Crash]

Here is a little trick to get Live back into Sync with another Sequencer/Live instance:

Live sends absolute "Song Position" informations out over Midi whenever you hit Play and whenever you change the "Arrangement Position" field manually.

That means whenever you notice Live and another Sequencer/Live running out of Sync you can try to get them back by sending an absolute Song Position to the slaved Sequencer/Live. The best way to do that would be to (stop the song and) hit Play. But sometimes you want to keep your set running without interruption, how can that be done?


1. Set Quantisation to 1/32 (alternatively to Off, but the result may be slightly different).

2. Click on the "1/16th" part of the Arrangement Position field to activate it.

3. Hit and release "Cursor Up" on your keyboard quickly, this will "fast forward" your set by 1/32th max.


Depending on how well timed you hit the key you may not audibly hear any jump/interruption at all. I advice to wait until shortly before the end of a full beat/loop cycle, because it sounds more natural then.

Eventhough a single hit of the key/ff will send a Song Position out it may be necessary to do it more than once in order to get badly out of Sync instances back to Sync. The best way would still be to stop the playback and restart. The latter is especially wise during breaks in between songs if you can afford some seconds of silence.