I found a problem when using “LiveMTC for MacOS”.The tempo of Live will affect the accuracy of MTC. When tempo was 120, MTC was relatively stable. However, other tempos will cause synchronization errors of subsequent devices, and the time code jitter is visible to the naked eye.
I’m having the same issue with warped audio in Ableton. The MTC code generated is very off based on tempo. For example, the teplate I use defaults to 120bpm. I start dropping in my arrangement View tracks. For multiple songs I add space in between. The first song starts at 145 bpm (MTC starts and plays correct time). Next song is a measure after the end of the first song. Between those songs time skips then once it hits the next song, warped at 60bpm, the timing skips back in time creating issues with my lighting console.
Is there some better way to play audio at different BPMs and get consistent MTC output with LiveMTC in Ableton?
Hi Jeremys,
Welcome to the forum!
Would you be able to let us know what software you are syncing to Live with LiveMTC? It would be great to be able to reproduce the issue.
Also I am not sure I understand how you expect that the tracks you have in Arrangement View and how they are warped would affect the MTC output.
Best,
Mattijs
Hi Matt,
Here’s a brief video on the issue I’m having with LiveMTC and Ableton Live 11:
Each of the songs are warped with a warp Leader. As you can see from the BPMs a song will have a specific BPM (like 171 BPM) then, when there is a space, the BPM defaults to the set BPM. The next song will be 87 BPM, etc.
When LiveMTC reads the songs BPM it seems to get confused with what the MTC should read, skipping all over the place for each song.
I’m using a USB Midi connection to a Chamsys QuickQ20 lighting board.
Thanks for the clear reply Jeremy!
I understand now that when you say warping you refer to changing Live’s tempo. Instead we usually use “warping” to specifically indicate Live’s ability to change the tempo of audio clips while retaining their pitch. Anyway, thanks to your video I think I now understand your situation 
Unfortunately we can’t support sets with changing tempos since we can’t get information about the previous tempo settings from Live. All we can do is calculate the current time in hours/minutes/seconds based on the current tempo and the current beats, and we need to assume the current tempo was the same since the set started playing. So changing the tempo while playing will indeed result in a jump in the time code.
There is one workaround that might work for your case (I haven’t tested this though): to compensate for the time differences caused by tempo changes with the MTC plugin’s automation. You could adjust the time offset for every track so that its beginning is at the exact time assumed in the lighting desk.
This is of course not ideal since whenever you change something about your set, you have to carefully adjust the automation to match.
Hopefully at least this explains what you are seeing.
Hi,
Seems like this thread was closed but I am having a similar issue. Using the workaround method kind of fixes it but you can only adjust within 60 frames/seconds/minutes/hours and there are no negative values. This means that with enough tempo changes the timecode can skip past where it’s supposed to be and there is no way of getting it to “rewind,” so to speak. Is there another workaround for this? The only thing I can think of is organizing the set in a way where the bpm for the songs are always ascending in so you can always use a positive offset. (or vice versa, haven’t tested yet). Is there a coding based solution for this or is this application done with updates? Or is there a way to generate mtc that is not dependent on the BPM? I tried using clipSMPTE but it doesn’t seem to work with my rig (unless I buy a 350$ piece of hardware). Maybe a max for live device that converts LTC to MTC and still uses the same bridge application to make it usable with other software? (I’m using Obsidian ONYX) I don’t really know the best way forward from here so any suggestions would be helpful.