Why is delay compensation total ass?

[anstahc]

I built a patch in Max for Live and tested it on the same input a bunch of times and the recorded output ranged anywhere from 4 ms to 22 ms late. I can live with a few ms but 22 pretty much makes a sidechain compressor useless. Why is the delay different every time, and is there any way to fix this? My sessions are 96k / 96 sample buffer.

[anstahc]

Just an update if anybody else faces the same problem. The "wireless signal" send~/receive~ objects are pretty problematic. I thought I remember reading in the documentation that they add a 1 sample delay (a small fraction of 1 ms), but I've observed as much as 22 ms delay. Also the left and right channels are frequently out of sync (right as much as 4 ms behind the left). Avoid at all costs and use patchcords instead.

Also if you have anything in your patch tied to Live's transport, make sure it is queued at 1. 1. 1. before you click a record clip button for resampling. Even though you could be at some random time like 9. 2. 3. and it will automatically take you back to 1. 1. 1. when recording, somehow the automatic jump back to 1. 1. 1. induces some sort of delay.

[broc]

Here is the documentation about Max vs. M4L.

http://www.cycling74.com/docs/max5/vign ... tions.html

It says that send~/receive~ objects are not supported in M4L.

For perfect sync to Live's transport you can use the [plugsync~] object.
Timing of the Live API (eg. observers) is generally not accurate.

[anstahc]

Thanks for the response. It says send~/receive~ *between devices* is not supported, not send~/receive~ altogether. I was using them within the same device to keep things clean. I hadn't heard of plugsync before. It seems to do the same thing as transport but without the need for a metro to get it going. Thanks.