Ableton Forum

I got a Live project running some arpeggiators and some m4l patches, none of them have to do with the arpeggiators.

Arpeggiators trigger some beat samples in racks.

I made a test with 120 bpm, arpeggiator "sync" at 16th up mode, No groove of course.
and with "time" at 125 ms; gate 50%
In each case when triggered the arpeggiator gets a delay when Midi clip loop starts again.

An equivalent 16th notes written pattern played after it made it even more obvious.
All the rest sounds in tempo, but arpeggiators are evidently out of time.
Anyone else?

Macbook Intel 2GHz 2 GB RAM
OSX 10.4.11
L 8.1.3
Max 5.1.4

tchüss


p.s. forgot to say, does NOT happen when no m4l patches are loaded

I was just trawling the forums for people having the same problem as me and found this thread.

I am indeed having issues with the live arpeggiator going out of sync by almost a full 16th note. The problem is not only with Max for Live though, it also occurs when you use 3rd party VST's with anything that needs host sync data. So I've noticed that the problem isn't only limited to the arpeggiator its with any plugin parameter on ones that come with live or 3rd party. Specifically parameters that need to be synced and that use lives clock to be in sync.

I think this all boils down to poor automatic delay compensation in live. I have experienced this problem with every live set I've created since day one of using Live (way back in version 7 as well). The audio itself is in sync but the MIDI clock that is sent to plugins for host sync seems off by a lot. It becomes worst and worst the more plugins or complex racks you add to a single track. Live's built in plugins do not cause this delay but most 3rd party ones do and M4L devices also do.

I think its even more noticeable if you add complex Max for Live devices to a track because I don't think they report delay compensation data to the host. I could be wrong on that last point but I have made a very complex device and when I add this as the first device on a track instantly any tempo synced plugins to the right of that device go out of sync by a big amount. The audio is in sync but like I say its just any tempo synced lfo or anything that needs host sync data to be correctly in sync. Maybe I just don't know how to report the delay compensation data to the host with M4L yet. But this still doesn't explain why it happens without Max For Live and just with a very complex track with a mix of 3rd party VST's and built in live plugins.

http://www.mediafire.com/file/tmnzii3mgew/Plugin Sync Test Project.zip

I've done a series of 4 controlled tests to demonstrate this problem and I've uploaded the live set to mediafire so you can see for yourself. In this test I have used the 3rd party plugin FuzzPlus2 which is a free VST from Audio Damage so you'll need that vst installed to see for yourself. I only used that plugin because its free but the same is occurring with many other 3rd party plugins. I've also used Max For Live in some tests so you'll need that, anything else I've used are Live plugins and samples I've collected and saved into the project. I've used the edit info feature with an empty rack on the master track as a sort of notepad so just hover the cursor over the macro dials for notes on each test.

I'll just talk about test 1 you can see the rest for yourself but test 1 shows the problem very accurately. We have 1 simpler playing a bass sound and 2 identical racks after that. In these racks left to right we have a chain of 2 autopans as I'm using as a sort of volume LFO rather than an actual pan, its kind of an alternative to using a pumping sidechain compressor. Then we have 2 x Fuzz plus VST's.

Test ones's first clip uses one of the LFO's in the first of the 2 racks and test ones second clip is using an LFO from the second rack which is further along in the chain. The second clips LFO is massively out of sync, this is clearly showing a problem with Live. Just becuase the second LFO we use is further along the tracks chain of plugins it becomes out of sync. The second autopan LFO is placed after the 2 Fuzzplus VST's. So clearly Live is not compensating enough for the delay of the VST's before this LFO.

Unfortunately there is no way to manually compensate for this using the track delay settings because its not the whole track or the audio that's out of sync. Its only the plugins that require host sync data that are placed further right in a tracks plugin chain.

I hope Ableton can explain why this is happening and hopefully offer a possible solution. We also really need this fixed for Live 9.

Mac Pro 8 x 2.8ghz
8GB of Physical RAM
Sound Card - TC Electronic Konnekt 48
OSX 10.6.3
Live 8.1.3
Max For Live 5.1.4

I should also add that I have my audio buffer set quite high (740ms) as I use a massive amount of plugins in each set. Also the amount it goes out of sync gets worst the higher you set the audio buffer in live preferences.

Jabbon wrote:I got a Live project running some arpeggiators and some m4l patches, none of them have to do with the arpeggiators.

Arpeggiators trigger some beat samples in racks.

I made a test with 120 bpm, arpeggiator "sync" at 16th up mode, No groove of course.
and with "time" at 125 ms; gate 50%
In each case when triggered the arpeggiator gets a delay when Midi clip loop starts again.

An equivalent 16th notes written pattern played after it made it even more obvious.
All the rest sounds in tempo, but arpeggiators are evidently out of time.
Anyone else?

Macbook Intel 2GHz 2 GB RAM
OSX 10.4.11
L 8.1.3
Max 5.1.4

tchüss


p.s. forgot to say, does NOT happen when no m4l patches are loaded

Your p.s. seems in contradiction with the first sentence.
Where exactly are the M4L devices loaded?
Do you get sync issues if you just load some M4L device on a completely independent track?

I'm assuming its some sort of M4L MIDI device he's using placed to the left of the arpaggiator on a track. At least that's why I get out of sync issues with plugins, as I've demonstrated.

I've also had the same thing happen if I have a MIDI track with a M4L device with its MIDI output routed to another track. The track its routed to has No M4L devices but plugins like Live's arpeggiator and LFO's that require sync and they go out of sync as soon as you route MIDI to the track. But if you undo the routing of MIDI to that track then it goes back in sync. In other words the delay introduced from the M4L device is added to the second track its routed to and any device on the second track that uses host sync gets delayed.

Also the more M4L devices you add to a track the more the devices to the right in the chain suffer from out of sync issues.

For me this issue drastically reduces the scope of what can be achieved in Live. Hope we can find a solution.

Debrecini wrote:I'm assuming its some sort of M4L MIDI device he's using placed to the left of the arpaggiator on a track. At least that's why I get out of sync issues with plugins, as I've demonstrated.

I've also had the same thing happen if I have a MIDI track with a M4L device with its MIDI output routed to another track. The track its routed to has No M4L devices but plugins like Live's arpeggiator and LFO's that require sync and they go out of sync as soon as you route MIDI to the track. But if you undo the routing of MIDI to that track then it goes back in sync. In other words the delay introduced from the M4L device is added to the second track its routed to and any device on the second track that uses host sync gets delayed.

Also the more M4L devices you add to a track the more the devices to the right in the chain suffer from out of sync issues.

For me this issue drastically reduces the scope of what can be achieved in Live. Hope we can find a solution.

Ok, that's exactly my experience.

I did some measurements and found that M4L MIDI effects introduce a delay proportional to the audio buffer size.

So it seems to be a "feature" by design, unfortunately.

Oh dear... I hope someone out there has a solution for us and Ableton really needs to get on to this one.

I wonder if its possible to create a M4L device that compensates delay? After all there are VST's that have been released that do the same. http://www.voxengo.com/product/latencydelay/ that's one of them. But this only works if the whole tracks audio is out of sync and doesn't fix the issue we were discussing.

Yes, we are dealing with timing issues of MIDI devices on the same track.

For testing I made a patch generating a beat click with adjustable delay (attached below).

Load 2 instances of the device on the same track, with drum sticks as instrument (eg. operator preset 'Sidestick-808').
When playing you will notice that the beats from both devices are *not* in sync.
Now increase the delay parameter of the 2nd instance until the beats are matching.
For me this happens at about 12ms (@ audio buffer 512). Changing the buffer to 128 gives 4ms.

I just wonder why this delay compensation isn't done automatically?

<pre><code>
----------begin_max5_patcher----------
849.3oc6XErbaBCD8L9qPCmcckDX.2Ss82HSlLxfriZ.IJHbcZl7uWgDfwwP
LXmPxgdwxHsH812t5sq8SyrrWK1SysAeCbCvx5oYVV5oJmvp5YK6Dx9vXRt1
L6X1N5hHFI1dtY0cjLNIgd7h2ftsd8MBtbCITa.rZtThL7dFe6cYzPo4zwdK
W.mCbbbKGbMe5u.Bts5c3EILdLUpgApdixn4TtjHYBd64YQZ7HV+qu3X2bnY
JbJoY2Q4j0wz11q1bQgrd2wUyZlR9XJ0fQa64.6MwBhBy21ABZ6NZG.2myjS
1QitiHkYr0ER5gukWQ8UbeI8FWPEapmtd91tSM.qbliViwYRU7nkKC6vp76E
Yxln3NZrHjIezty8aGKmcL6cjAIhHU9hdUrxi6vBBmKp3qlirqiJVv29ZYVm
brLcJ.ryCMlwenbyx6iBJ2.QTuLDiuQzKREYQzr9dyBUDHu2WMOkRihYI8FY
jzzdwLcepfqR9zr8hdOb4i8G4SNSvJ4.qZV74YyNLn+74YyGn1Am9G0Mx56i
R5dMxsSXQL0Us1BF4r+ZxvZhlcoY34Xtd4Ue+ZN.EbNIiVRCd1cd8G1BHMIf
+HSk7A9oHNx9s0yU76E53N9PsiCGsiuraGG0mtGi2Rw6MjVFVwjwVIwckQ60
6MtRB9CrRRPvmuJInyVIIhFSNeYD3GPYj+WC4xpgfutZH8mWYR1gkY1uaEZR
YoT.b7xsXrVQwAZjcW855s3SUNPiTu8cQrsGR4q.2fKmSvPOSa6imSveRJB0
CuHyH77TkZ134Fj4Gwf7MCX+wSNNcSNqdMxYdyfoxRmeoKqlRZUcoOS.b4fu
+6BBWp3S8CjPoRZFftbx1TtG4cA2NGa6PqI7sSImoJzQunFjqtj555LjNjcN
kZB9n6PVB7tBA6kXsFUvnaPF494VbJg7.sLq.D.UTwUvPqzCqPiNy.4aOtNd
egTzXHKsspd23u7upR6XkyeLClKJxBqO2p+CHvAWKhlKY7lN8u4fCAPMFcOK
Jhxamrq9wZoBUbtBCl9TNIbNTHUV967X5Had2gzPPj6jBogRRSXbqLWx+bPB
OsAtkCglblVL4O.LEL8PBM.HMgYStCUYZ5nogjL4cEHR8vyy9GflOTd6
-----------end_max5_patcher-----------
</code></pre>