forestkelley

I’ve done some testing and have arrived at some specifics. The synopsis is that parameter automation in Logic (such as automating the gain on a plugin) is off when another plugin that requires latency (such as iZotope’s de-click) is on that track. However, it is not off when that same latency plugin is on a summing track (i.e., if a track has gain automation on it, and its summing track has a latency plugin on it, the track’s automation will be accurate). An important caveat is that this doesn’t affect a track’s volume fader automation at all. Track volume automation is accurate and isn’t negatively affected in any case. For cases where there is latency in the program, when I bounce, the region designated to be bounced, the “cycle range,” is offset, moved forward in time (to the left, presumably by the latency duration). The bounce starts with silence for this area which is to the left of the cycle range (i.e., when Logic compensates for latency, it starts playing not at the cycle start but by x milliseconds prior, and this prior region is included in the bounce and is silent. However, the bounce is still the same duration as the cycle range. Therefore, the end of the cycle range is missing/cut off by the same latency duration. Gain automation seems to be accurate when there are no plugins that require latency on that specific track (though the bounce is still offset by the latency created by other tracks as described above), but as soon as a plugin using latency is added to the track (such as iZotope’s de-click), the automation is off, set right by the latency amount. Again, an important-seeming note: this issue doesn’t happen with regular track fader volume automation. Fader volume automation is accurate whether their is a latency plug-in on the track or not. However, if the de-click plugin is placed on the summing stack (instead of the specific track), the gain automation is accurate. Meaning, that Logic is probably handling latency properly when these plugins are on the summing track but not on an individual track. Interestingly, iZotope seems to be aware of this issue as this (https://support.izotope.com/hc/en-us/articles/360033886113-Latency-and-Delay-Compensation) page seems to suggest that some “hosts” may not be properly set up to handle their latency. Further, the issue seems to be squarely in Logic’s camp and not on the iZotope side since you can see the suggested latency offset for each of their plugins by opening the plug-in preferences. Of course, keeping all latency plug-ins on the summing track may work in some cases, but it isn’t a great solution for a number of reasons. I for one, need to use the de-click on my individual track so that these clicks won’t affect the compressors on that track.

I’m dealing with the automation latency bug. It doesn’t happen with a track’s volume, but does with a gain plugin (both stereo and dual mono). I’m using a lot of Izotope plugins including the Rx de-click which adds a lot of latency. The automation delay seems to correlate precisely with the latency duration (about 3 seconds). I am also using summing stacks for groups of tracks with plugins on both the individual tracks and the sum track. I’m not sure if that makes a difference with the issue (I may test tomorrow).

I’m dealing with the automation latency bug. It doesn’t happen with a track’s volume, but does with a gain plugin (both stereo and dual mono). I’m using a lot of Izotope plugins including the Rx de-click which adds a lot of latency. The automation delay seems to correlate precisely with the latency duration (about 3 seconds). I am also using summing stacks for groups of tracks with plugins on both the individual tracks and the sum track. I’m not sure if that makes a difference with the issue (I may test tomorrow).

I'm having the same issue. I'm using iZotope Rx and automation on Logic's gain plugin happens about three seconds after it was drawn. I've also tried the various latency settings including Sample Accurate Automation. I am working in a summing stack. I haven't tried it on a non-summed track.

Logic gain automation is inaccurate. It's happening late/right by some latency duration (about three seconds in my case). I've seen similar issues in related forums that are years old (including /viewtopic.php?t=138619&start=20 one), but I haven't found any solutions. My track volume automation works just fine. But you can see in the screenshot that the gain reduction in bounced track E happens far after the automation in track F. I assume this has to do with latency as others have suggested. I'm using logic Version 10.6.0 on a Mac with Catalina 10.15.5. I am using the iZotope Rx plugins and they require some latency. I did try to change the I/O Buffer Size and the Process Buffer Range settings, but it didn't help. I have tried taking the whole gain down to make sure I have the plug-in on the right track and that I'm working with the correct R/L channel when using the Dual Mono version. I want to use the Dual Mono Gain plugin so that I can automate the R/L channels separately. That's one reason why I can't simply automate the Volume. Is this a continuing bug? Is there a solution? Thanks! ----------------------------------------- UPDATE: Note: I'm going to add the following information to the thread that follows as it seems to be related to my issue and has recent posts: viewtopic.php?t=157206 I’ve done some testing and have arrived at some specifics. The synopsis is that parameter automation in Logic (such as automating the gain on a plugin) is off when another plugin that requires latency (such as iZotope’s de-click) is on that track. However, it is not off when that same latency plugin is on a summing track (i.e., if a track has gain automation on it, and its summing track has a latency plugin on it, the track’s automation will be accurate). An important caveat is that this doesn’t affect a track’s volume fader automation at all. Track volume automation is accurate and isn’t negatively affected in any case. For cases where there is latency in the program, when I bounce, the region designated to be bounced, the “cycle range,” is offset, moved forward in time (to the left, presumably by the latency duration). The bounce starts with silence for this area which is to the left of the cycle range (i.e., when Logic compensates for latency, it starts playing not at the cycle start but by x milliseconds prior, and this prior region is included in the bounce and is silent. However, the bounce is still the same duration as the cycle range. Therefore, the end of the cycle range is missing/cut off by the same latency duration. Gain automation seems to be accurate when there are no plugins that require latency on that specific track (though the bounce is still offset by the latency created by other tracks as described above), but as soon as a plugin using latency is added to the track (such as iZotope’s de-click), the automation is off, set right by the latency amount. Again, an important-seeming note: this issue doesn’t happen with regular track fader volume automation. Fader volume automation is accurate whether their is a latency plug-in on the track or not. However, if the de-click plugin is placed on the summing stack (instead of the specific track), the gain automation is accurate. Meaning, that Logic is probably handling latency properly when these plugins are on the summing track but not on an individual track. Interestingly, iZotope seems to be aware of this issue as this (https://support.izotope.com/hc/en-us/articles/360033886113-Latency-and-Delay-Compensation) page seems to suggest that some “hosts” may not be properly set up to handle their latency. Further, the issue seems to be squarely in Logic’s camp and not on the iZotope side since you can see the suggested latency offset for each of their plugins by opening the plug-in preferences. Of course, keeping all latency plug-ins on the summing track may work in some cases, but it isn’t a great solution for a number of reasons. I for one, need to use the de-click on my individual track so that these clicks won’t affect the compressors on that track.