Ableton Forum

Everything quantizes fine to my metro (metro 16n @quantize 16n @active 1) when I'm inside editing an device but when I go out of edit mode it seems like something goes slightly off the beats? have anyone got the same problem?

For sync'ing with Live's transport you need the [transport] object. Something like this

<pre><code>
----------begin_max5_patcher----------
365.3ocuT1rbBBCEEdc3oHSVaaM.B0tpsuFcb5DgnFGHgBWZs0w28le.s5fN
hN0Mjjy8BmS9fvZODYpZEuhfeB+FFgV6gPVIi.pYMhjyVkjwprsQj7uTSWRF
3JA7UfUFvSYx4sxyTRnR7C2ThN79gMxELHYgPN+8RdB3LkFDoKi8oOZFBM8h
MywSZtGYctPlwAq6zFQQp0TcPtiFS10opFNrUmD7cA2YHwlysOdSRkrbaQxK
kBVF9UUVJwTcimm4xfqiLOfo9CuXvPGaQRPvoAieGfIrmfQHgaIWfRlrpPUB
8mMgTKMhbC9w8mMi5lMiOEaFrcXVlhcjIc00sjp4bnToQiD+7G0LIn4oaEKA
DepmewzNv2gYZ+ocz+8QTaujLg7v+kY2NF88IYkptLo0s1OHvwasLkWABICD
J4eaRehBuaauPjlxs0agWtHsPoe62DB7jNeud1YJZO6NRlFcayT34jo3qHS5
Ea79ELoWK1.
-----------end_max5_patcher-----------
</code></pre>

If you stop and start the transport things should line up again. Timing and other aspects of performance are not strictly defined while crossing from Live to the editor or vice versa.

-A

In my experience, switching from/to the editor causes a little hiccup but always seems to re-sync itself afterwards.
(when using the method as shown in the patch)

ok, hmm, I have narrowed down the problem, only occurs when cpu is under stress, so it might be a bug. if I load up my machine in an empty liveset it seeams fine, but when I add more stuff to stress the cpu it gets out of sync. If I turn delay compensation off in live it syncs fine... but then everything else is out of sync.... I want to note that there are more going on in my patch than just a metro and a transport. have max for live some issues with not utilizing the delay compensation ?

fuadvonloop wrote:ok, hmm, I have narrowed down the problem, only occurs when cpu is under stress, so it might be a bug. if I load up my machine in an empty liveset it seeams fine, but when I add more stuff to stress the cpu it gets out of sync. If I turn delay compensation off in live it syncs fine... but then everything else is out of sync.... I want to note that there are more going on in my patch than just a metro and a transport. have max for live some issues with not utilizing the delay compensation ?

Is it even technically possible for a Max device to compensate for its own delay?

note, the out of sync only occurs when out of edit mode with delay compensation on... so it might not be anything to do with metro after all it might be a bug ?

edit: it is a bug, if I add another track and put any live device on that track it jumps in sync, very weird.

pukunui wrote:Timing and other aspects of performance are not strictly defined while crossing from Live to the editor or vice versa.

Well, in this case it's hard to talk about "bugs".

I think the issue is that the sync info Max is given isn't delay compensated correctly... if there are effects before the M4L device that create latency, then M4L's sync will be off (e.g with phasor~ @frequency 0 1 0 bars.beats.units @lock 1). I hope this is fixed in Live 9...

rbrown46 wrote:I think the issue is that the sync info Max is given isn't delay compensated correctly... if there are effects before the M4L device that create latency, then M4L's sync will be off (e.g with phasor~ @frequency 0 1 0 bars.beats.units @lock 1). I hope this is fixed in Live 9...

I can confirm this behavior. If you have multiple effects on a track that create latency, delay compensation tries to ensure that the *first* device will be in sync with other tracks. But subsequent devices on the same track don't get "correct" sync info, i.e. adapted to their individual latency.

hoffman2k wrote:Is it even technically possible for a Max device to compensate for its own delay?

Not in general, but in some cases the delay is known to the system.
For example, M4L midi effects by design induce latency proportional to the audio buffer size.
This can be compensated (and is actually done).

There might be another factor. Somewhere in the bug forum I read that Live's compensation memory can get corrupted if you change a lot of devices. Reloading a set ensures the delays are calculated again.
If that is still the case, one could get different results if he works in a fresh set as opposed to a project thats been open for hours.

I'm not sure if that also applies to M4L devices, but I'll wager a guess and say they're both using the same compensation system.