The automation fades in/out around automation nodes, and if you use large buffers like 2048 you would see that the length of the fade increases greatly. The classic automation (not sample accurate) is indeed based on the buffer size. Really ? The audio has 300 samples of fade and you say it is sample accurate ? I wonder if this is related to buffering. It looks entirely sample accurate except for the beginning and/or end. That’s a huge design flaw actually, VCA should be sample accurate too. It seems that it (the sample accurate automation) has only been implemented for audio tracks (Audio, Group, FX and Instrument) and not for the VCA, and since the VCA position is always being read in real time before the audio track fader, it applies its own automation law (because of the Link being active, it is the VCA that takes control the audio track, even if the VCA isn’t automated). In any case, when a VCA is assigned to the Track, it indeed breaks the “sample accurate” automation, but it doesn’t look like an actual bug to me. If you disable Read automation and enable it again then the bug will no longer occur on next render. Your strange results on the blue track are due to another bug, when you set the Link to None after doing a render with the VCA Link active, and the automation being read on the audio Track, the render will still (and wrongly) take the buffer parameter into account, although there is no smooth fade, it ends abruptly (as shown on your image).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |