![]() The latency of all MEasures A-C shall correspond to the same results among both testcases. Now reproduce this testcase a second time by skipping step 5. Switch the plugin back to low latency mode (In FabEQ switch to PhaseLinear.Max Mode)ĥ. Switch the plugin to a mode producing high latency. Install Fab Filter EQ v3 or any vst plugin which can produce a high or a low latency based on a VST-setting.ģ. I can describe you how i did it in detail, once you request this info. Measurement: You need a setup where you can measure the actual output latency of ableton live. So i will describe the steps to reproduce and request you kindly to reproduce and verify this problem. I wanted to verify this bug once more in ableton, but did not find the time to do it. Both DAWs show the same problem which i guess is based on a design problem in the vst specification. I have reproduced an error in ableton live and in Presonus Studio One. Of course you shouldnt add audio fx to the erm sync signal. The latency will be reflected in the end of the audio fx rack where sync channel and mastered music channel is mixed together again. You can add latency plugins to the (mono) music channel. In any case sync was restored properly after stoping and restarting playback. (5): I just tested it and doing so it was not possible to leave live in a inconsitent state. Of course only, if mixing your track in mono is enough for you. Then the erm signal should be correctly delayed so that the generated midi clock signal again contains the latency of the master channel plugins. (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. ![]() (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. The latency can not be known at this position in the audio-graph. 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. 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. (3)If I would design an audio application, I would provide multichannel by default and the latency would be part of the audio stream. ![]() 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. (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. However, there seems to be a bug buried somewhere in this optimization. It seems like Ableton saves the latencies at each position in the AudioGraph with in the Live Set and updates it very optimized. (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. 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. 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!įor 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. ![]() 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. ![]()
0 Comments
Leave a Reply. |