chrislos

for a larger media production I need to sync my live set in arrangement view. 

I've managed to decode an incoming ltc signal to an hh:mm:ss:ff smpte format.

The only task my sync-function has to deliver is to observe if the smpte stream has jumped to a new position in the timeline or has stopped. If it smpte starts playing on a new position I will hook up my Ableton Session on the same timeline-point but from there I will use my own Ableton clock since it just seems not possible to sync anything beyond that properly.

So far so good. I'm fine with that in this particular project.

Now I realized that live LOM only has ONE option to jump within the timeline:

[set current_song_time] which is measured in BEATS.

I think a jump in beats is fairly inaccurate, right?

Has anybody found a better solution for that? Since plugsync~ is capable of counting in ticks I hope there might be a better option. In the worst case I will jump in beat-measurements... but thats just *arghhhh*

for a larger media production I need to sync my live set in arrangement view. 
I've managed to decode an incoming ltc signal to an hh:mm:ss:ff smpte format.

So far so good. I'm fine with that in this particular project.

Now I realized that live LOM only has ONE option to jump within the timeline:
[set current_song_time] which is measured in BEATS.

I think a jump in beats is fairly inaccurate, right?

Has anybody found a better solution for that? Since plugsync~ is capable of counting in ticks I hope there might be a better option. In the worst case I will jump in beat-measurements... but thats just *arghhhh*

hey folks,
for a larger media production I need to sync my live set in arrangement view. 
I've managed to decode an incoming ltc signal to a

current_song_time-only-in-beats

The beats measurement aceppts floating point inupt. So it is more precise indeed.

EDIT: 
I guess it's sloved.  
The beats measurement aceppts floating point inupt. So it is more precise indeed.

current_song_time only in beats