We’ve bin having some problems with the Nuendo 7 (32 bit and 64 bit) volume automation.
When we use our Mackie mixer to write volume automation, Nuendo sometimes changes the value of the starting point our the writing curve after you’ve released the fader. The variations are between 0.2dB and 1dB. (please note this only happens when you fade slowly e.g. 5dB rise/drop in 10 seconds, and not when you fade fast e.g. 15dB rise/drop in 2 seconds)
Although these are small value differences, you don’t hear them unless you play back the part you’ve just faded. Which means that what you mixed while listening and fading, will be slightly different than what Nuendo saves in the volume automation!! (since the volume automation isn’t the same as when you listened to it when mixing).
As you can see in the pictures I added, the first volume automation goes from 0dB to -15db; I keep it there for a few seconds, and then I put it back up to 0dB.
On the second pass (after stopping and starting playback) I did the same fader movement on the Mackie, but now after the -15dB drop, staying there a few seconds, and rising to 0dB; the -15dB starting point is changed for -15dB to -14dB after releasing the fader at 0dB!!
Does the same happen when you automate directly in the Nuendo Mixer?
That would rule out a communication error between the controller and the application.
I would search the forum for a similar issue with what I believe was the Mackie controller. I believe it reported a slight drift (at or below 1dB) as well.
Additionally, does this happen every time at the same point (release and not “grab” fader)? And is it only after having doen a first pass? I’ve had issues with other controllers too upon “capture” and “release” of the fader, and my hunch was that it had to do with the actual touch functionality of the controller “glitching”. I could even see how it could be a problem if the fader engages the motor as soon as it detects you letting go of the fader, and even if it’s just a minor move it could send a different value while then very briefly detecting your touch before detecting a 2nd release, thereby writing an erroneous value in the app (after “smoothing” the value/location in the DAW).
I tried your suggestion but It also happens when I use the Nuendo mixer with the mouse. So it’s not a communication error with the mackie and Nuendo…
I’ll look for the Mackie controller issue on the forum, but the problem is that I can’t reproduce the problem in Nuendo 6.5. So for now it looks like it’s a Nuendo 7 issue…
-Take any channel, and put it in read/write.
-Put the automation mode on latch and turn the “write automation to end” on.
-Move the fader (on your console, or in the Nuendo mixer) down to -15db in about 4 seconds and then release the fader.
-Stop playback (check what value you have on the volume track)
-Start playback, and move the fader back up to 0dB in about 4 seconds.
-After you’ve released the fader at 0dB, you will see that Nuendo changes the value of the starting point before you started putting the volume back up to 0dB.
The weird thing is that Nuendo doesn’t do this when you fade it very fast (e.g. 15dB movement in 1 second).
Please let me know if you also have the same results, or where the problem could be!
After we experimented with several Reduction Levels in the Automation panel (you can access it via the gear logo on the bottom left of the automation panel), we came to find that at a 10% reduction level, the automation values kept mostly the same.
I set the reduction level low because I did automation that reduced way too far, but I didn’t investigate it further. I now tested again.
5%:
As I stated in my previous post.
50%:
After I drop the fader to the target negative value and release the fader (this is in “latch”) the value will remain for as long as the track is playing. As soon as I hit stop it is actually the break point at the point of fader release that changes. In my first test;
fade to -15.00 dBFS
release fader and let it continue to roll - fader reads -15.
stop playback - automation “curve” changes;
a: The breakpoint where I let go now reads -14 !!!
b: It then fades gradually to the next breakpoint where I pressed stop, which reads -15.
This surely can’t be right!??!?
Same problem with 20% reduction, gone at 10%.
I suggest you mark this “ISSUE” asap. It’s a pretty big difference and seemingly.
