Strange syncing issue over 1025 bars

[galo]

My current setup is running two laptops, the master is running live 7.0.18 (osx10.5. and the slave is running live 8.1.3 (osx 10.6) synced via midi cable. My issue is when manipulating items in the arrangement view, I am unable to jump directly to any bar over 1025.1.1 without the slave arrangement position restarting to 0. I did some searching and found out that a bug did exist in earlier versions of 7 but seemingly this has been addressed already.

Can anyone help?

[[nis]]

Hi,

When using MIDI clock, syncing the start positions between the master and the slave is achieved with so called Song Position Pointer (SPP) messages. SPP messages have a maximum resolution of 1024. That's why the slave will start at bar 1 when the master starts at 1025. There's no way to avoid this (at least when using MIDI clock sync).

Best,
Nico

[Noise Coalition]

Hi,

When using MIDI clock, syncing the start positions between the master and the slave is achieved with so called Song Position Pointer (SPP) messages. SPP messages have a maximum resolution of 1024. That's why the slave will start at bar 1 when the master starts at 1025. There's no way to avoid this (at least when using MIDI clock sync).

Best,
Nico

Hi, is there a way to work around this issue? I'm currently using Live 8.2.5 and still am running into this issue. I need to be able to create longer sets than 1025 bars and be able to keep syncing two computers' timelines. Thanks!

Change logs said this should have been fix in 7.0.7b1 but I'm still experiencing this issue:

Sending of MIDI Song Position Pointer message beyond bar 1025 would lead to incorrect behavior and different behavior on Mac OS X and Windows.

System Specs for both computers:
Macbook Pro (Non unibody)
Live 8.2.5
OSX 10.6.8

Jason

[chapelier fou]

Hi,

When using MIDI clock, syncing the start positions between the master and the slave is achieved with so called Song Position Pointer (SPP) messages. SPP messages have a maximum resolution of 1024. That's why the slave will start at bar 1 when the master starts at 1025. There's no way to avoid this (at least when using MIDI clock sync).

Best,
Nico

Someone at ableton told me it's been solved after version 6...

[Noise Coalition]

Very strange.. I'm running 8.2.5 and the problem is reproducible every time. It's driving me nuts! Is there a os x update that I need to run or something?

[Noise Coalition]

Ok I've confirmed it isn't a wireless midi sync issue. I just synced the two computers and hard-wired the interfaces and it still resets the slave computer to 0 after bar 1025. Anyone have any insight to this problem?

[chapelier fou]

Ok. Sorry. The problem at 1024 and live 6 was it was missing on beat on slaved computer. Sorry i just remembered that.

[Noise Coalition]

Got an answer from Ableton tech support:

You can solve the issue you report by disabling the Song Position Pointer on the MIDI clock master.

If the master is another instance of Live, enable PATTERN mode in this instance's MIDI output port.

This solution avoids Song Position Pointer back-jumps on the slaved computer. It is not possible to jump to any bars in the set of the slaved computer - this is because the Song Position Pointer is not being sent. The technical reason is the limited MIDI data resolution: Two data-bytes encode 128*128 = 16384 values which can address as a maximum 1024 (4/4) bars.

This still does not allow me to jump around in the set and have the slave computer follow. Still investigating this...

[Noise Coalition]

Response from Ableton support. Don't know why I didn't think of solution #1

In pattern mode the slave always starts at 1.1.1.

There's two work arounds:
1. You could raise the tempo in Live (x2 or x4) and then shorten the clips accordingly (/2 /4).
2. You could work in Session View on the slave and trigger everything in scenes which is the recommended way to play live anyway.