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.
Hey all,
Just to make sure the technical limitation that prevents us from implementing this is well-understood, here is a bit more explanation:
The current Live API does not have a method to query the current song time in seconds as seen in the time ruler below the arrangement in Live.
The Live API only has a way to query the current beats, so what LiveMTC does is multiply the current beats with the inverse of the current BPM/60 to get the current time in seconds. Of course, when the tempo changes half-way through the set, this results in a different number than the accumulation of actual seconds played.
There is an entry in the Live API called get_current_smpte_song_time, but this has the same flaw as when calculating the time as we do: it jumps when the tempo is changed. This is discussed for example here: get_current_smpte_song_time - Max For Live Forum | Cycling '74.
We know that our feature request to report the current time in seconds as shown in Live’s time ruler has been registered by Ableton but it hasn’t received a high enough priority yet. If you are up for it, it would be helpful if you were to file this request with Ableton as well. The more users get in touch about this, the higher the chance this will be implemented and that we can extend LiveMTC to work with tempo changes.
Thanks in advance!
1 Like
Just to be complete: filing a support request at Ableton can be done via their support form, where you can select Technical Support from the dropdown.
Here is an example of how this form could be filled in:
Submit a request – Ableton.pdf (68.0 KB)
It’s using the following text:
Please add a way to query the current playback time in seconds
To output MTC from Live, I use the LiveMTC tool (
showsync.com/livemtc). However it does not work correctly when I change the tempo of the set, because the Live API doesn’t allow LiveMTC to query the current playback time in seconds as shown in the Live timeline, under the arrangement. See the related forum thread for more information:cycling74.com/forums/get_current_smpte_song_timeIt would be great if support for this could be added to the Live API.