Comments by Mamat

Yes, you’re right to point that out.

TLC is not meant to be a magic fix for every internal PDC issue in Live. Since it relies on the latency reported by Live and the plugins, it mainly works as a track/group alignment tool: it finds the slowest track inside a compensation group and delays the faster tracks to match it.

The reason I made this patch is that I often use Ableton Live as a live plugin server, with external sources passing through Live in real time. In that context, I need to keep the overall latency as low as possible, so I cannot simply rely on Live’s global delay compensation in the usual way, because it affects the whole set/session. I wanted something more detailed and selective, where I can decide which tracks should be compensated together and which ones should stay as low-latency as possible.

So yes, if the issue is an internal timing/PDC problem inside a single plugin chain, for example a rhythmic effect or sidechain device placed after a high-latency plugin, TLC may not fully solve that.

That said, I think a more advanced version could probably be made by using something like TH Latency Measure.amxd, or a similar measurement system, to measure the real delay between tracks instead of only relying on reported latency. In theory, it could also help measure delay inside a chain. I’m a bit worried that this could become heavier or more complex, especially for live use, but it could definitely be an interesting direction for a future version.

So for now, TLC is mostly a selective track/group compensation tool for live plugin-server workflows, not a complete replacement for Live’s internal PDC system. Feedback and tests are very welcome.