A little more certainty not to end up in live latency hell (ERM Multiclock and Effects on Master Channel)

Share your favorite Ableton Live tips, tricks, and techniques.
Post Reply
charlybeck
Posts: 114
Joined: Sat Sep 18, 2010 1:42 pm

A little more certainty not to end up in live latency hell (ERM Multiclock and Effects on Master Channel)

Post by charlybeck » Sun Mar 19, 2023 4:09 am

After several hours of empirical experimentation and fiddling around, I've come to a realization, which I would like to share with you here, so that others don't end up - like me - in Ableton latency hell; or at least with less probability. ;-)

In projects with ERM multiclock (1) sync via the ERM VST plugin(2): do not use plugins with latencies on the master channel!!!!!!!!!! Never ever, not even once - not even if you delete them again!

For one thing, this can't work causally (for plugins with latencies) the way erm has it in his manual and a normal user doesn't know which plugins have latencies. The additional problem:

You can shoot yourself a Live Set that the sync does not work cleanly at all, even after you have removed the plugin from the master channel again. (This is definitely a live bug in 11.2.10) Eventually the LiveSet will recover from the incvonsistent state but not by reloading or restarting live. (Maybe try a rain dance XD).

Technical background:

If my observations are correct. It seems like Ableton saves the latencies at each position in the AudioGraph with in the Live Set and updates it very optimized. However, there seems to be a bug buried somewhere in this optimization. (Latency is believed to be a VST parameter like any other, which would be the design flaw: because plugin latency is fundamentally different from other parameters by use case. It has to be calculated and updated at runtime and should not (!) be saved in a document and has increased performance requirements, must not be mappable to any gui elements, etc.

(3)If I would design an audio application, I would provide multichannel by default and the latency would be part of the audio stream. You would have to measure how this works PErformance-wise, but this would definitely make it safer and more robust and minimize the rate of software bugs.

The reason why the setup (2) Can not work with plugins with latency in the master chain is that at the position where the erm-audio-syncstream is generated by the erm midi plugin is way before the plugins in the master chain. The latency can not be known at this position in the audio-graph. (unless its calculated back-but this makes only sense in this special use case (2) ) Therefor the midi clock signal generated by erm multicluck can not recognize this latency from the master channel.

(4) Theoretically (just tested (5)) if you use one of the stereo Channels for the erm sync signal you may route this signal together with the music signal on the only other stereo channel thorugh the master section. Then the erm signal should be correctly delayed so that the generated midi clock signal again contains the latency of the master channel plugins. This would be a replicaa of concept (3). Of course only, if mixing your track in mono is enough for you. ;-)

(5): I just tested it and doing so it was not possible to leave live in a inconsitent state. In any case sync was restored properly after stoping and restarting playback. You can add latency plugins to the (mono) music channel. The latency will be reflected in the end of the audio fx rack where sync channel and mastered music channel is mixed together again. Of course you shouldnt add audio fx to the erm sync signal. ;-)

(1) https://www.e-rm.de/multiclock/
(2) https://www.elektronauts.com/t/soloing- ... gin/143613
(3) see above
(4) see above
(5) see above

charlybeck
Posts: 114
Joined: Sat Sep 18, 2010 1:42 pm

Re: A little more certainty not to end up in live latency hell (ERM Multiclock and Effects on Master Channel)

Post by charlybeck » Mon Apr 10, 2023 10:37 pm

I have reproduced an error in ableton live and in Presonus Studio One. Both DAWs show the same problem which i guess is based on a design problem in the vst specification.

I wanted to verify this bug once more in ableton, but did not find the time to do it. So i will describe the steps to reproduce and request you kindly to reproduce and verify this problem.

Preparation:
- Measurement: You need a setup where you can measure the actual output latency of ableton live. I can describe you how i did it in detail, once you request this info.
- Install Fab Filter EQ v3 or any vst plugin which can produce a high or a low latency based on a VST-setting.

1. Measure the latency A

2. Draw Plugin onto (master) channel.

3. Switch the plugin to a mode producing high latency. (In FabEQ switch to PhaseLinear.Max Mode)

4. Measure the latency B

5. Switch the plugin back to low latency mode

6. Measure Latency C

6. Delete the plugin from the channel

7. Measure latency D

This is TC1.

Now reproduce this testcase a second time by skipping step 5. (this is called TC2)

Expected Result:
- The latency of all MEasures A-C shall correspond to the same results among both testcases.
C1: TC1.A == TC2.A
C2: TC1.B == TC2.B
C3: TC1.C == TC2.C
C4: TC1.D == TC2.D
C5: TC2.D == TC2.A

Actual Result:
C5 will fail.
Others may fail (Unsure)

The actual failure of the test indicates an update problem within of the lateny in the audio graph.
- The latency is correctly updated when the actual latency changes uppon a vst parameter change
- the latency is not correctly update when the actual latency changes uppon deletion of the plugin instance.

Please try to reproduce this error and kindly keep me informed.

Note that in my setup the problems arising from these issues and the unpredictable recovering of the correct latency is very distressing because it forces me to frequently remeasure the latency to keep my instruments run in sync. This interrupts my workflow and destroys the creative flow.

Post Reply