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!!
Can anyone explain what is happening here, and if anyone else is having these issues?
The guys from the Gooi & Vecht Studio
P.S. We also have Nuendo 6.5 in use, but we couldn’t reproduce the above issue there…
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).
That was poorly explained… sorry…
Thanks for thinking along!
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…
Any other idea’s?
Write a step-by-step guide to reproduce and I’ll check it here…
-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!
I tried those exact steps (obviously with different values) and I’m not seeing here on my computer. Specifically, I did two passes like this:
- Channel put into write, with automation set to “latch”
- Pressed play, decreased level, pressed stop.
- Located to the “lower” value, pressed play, after about a second or two raised level to close to zero.
- Pressed stop.
When stopping the level was the same as before writing that second pass up to about zero. I tried this three ways:
- without write-to-end, using software fader in inspector
- with write-to-end, using software fader in inspector
- with write-to-end using my Faderport.
I see no discrepancy here.
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.
Can you guys check what the settings are on your end?
Something seems wrong here.
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.
As I stated in my previous post.
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.
I forwarded it to Timo Wildenhain, so let’s hope it’s resolved in the maintenance update.