It gets worse though:
I was saying earlier in the thread I started here that placing an automation point in the automation lane would solve the problem - however - during my last job on Nuendo I used a template in which I had created automation points by default to deal with this. I did something during the mix, and all of a sudden I saw a similar behavior but different. I couldn’t for the life of me figure out what I did wrong, because the automation points were clearly there.
Well, I just tried to break it again using automation points and I think I succeeded. This time I’m using a signal generator to illustrate part of the problem further. When watching playback keep an eye on both the fader and the meter showing the output of the track.
As you can see there are three different scenarios here;
-
After combining automation the fader moves, but the output level doesn’t move.
-
After then turning off trim neither moves.
-
Apparently combining after turning write off yields a different (correct?) result!
Now let’s add to that what Guillermo has to say about it:
I had a talk with the some of the product planners about this, and you are not going to like it; In other words > they just mentioned it works the way it supposed to work and what you do is not the way you should do it… > So I am going to be brutally honest with you,> it is not going to be “fixed” because there is nothing there to be fixed.
I will try to get a more elaborate reply and translate it to english, but that’s it > either you re-adapt your workflow or maybe look for something else > as this relationship doesn’t seem to be going the way you think it should be going.
Best regards,
GN
So again:
The “Version History” document states clearly that trim on slave tracks now works. So, how is it supposed to work?