I have been using Nuendo for some time now over the past years, as per composition however I have noticed some interesting (and strange) behavior in relation to the application, namely the differences between part-based automation and lane-based automation.
Some questions I have are as follows:
Why does automation per part, i.e. “lane” not appear inside a part that is editable?
also:
Why does the lane sometimes turn red, as if to record something when only read-mode is selected and I am using a mouse?
In relation to the latter, this is very annoying as prior automation points, are removed, as well as snap-mode not working consistently.
In addition, why does fader-based automation, not work when in cycle-mode?
These issues give the impression in relation to automation, that the program is either half-baked or built for some other purpose, than simply drawing point-to-point and I would love for these issues to be addressed in a future update.
If anyone can verify, whether there is bug, please add to the list and comment.
When using the mouse, on a Fader and cycling back to the start, the volume shoots back up to zero even while I am holding the mouse button.
Therefore this is a method I have since abandoned (but wished to have noted) as it is too tiresome to use, and as I say, it appears to not be fit for purpose, in addition to inconsistent snap and lack of editing support in the Key Editor etc
This is not to mention, the Defacto record “bug” I am experiencing in relation to simply wanting to point-and-click automation points in a lane. What that does is create additional unwanted automation points, and deletes other meticulously entered automation nodes.
I did not change any defaults and I do not use any terminator nodes. I was simply clicking and holding the fader, with write mode engaged, which is as stated, a method I no longer use. I am now only using the mouse to define automation points, but this is problematic as it creates/deletes new/old nodes and as well, snap does not seem to work as well as it might otherwise with respect to other interactive objects such as Tempo nodes.
I have removed MIDI based automation from within the Key Editor of most parts in a project and I am hopeful that editing of automation data can be carried out, in a more open-ended manner, both from within the Key Editor (feature request I suppose) and within the “lanes” because I have a great amount of data to replace across many and varied instrument parts in quite a few projects.
This is all in addition, to other automation discrepancies/limitations, such as there being no MIDI CC automation available for Instrument Tracks, via Lanes.
Ok. But it’s working though, it’s just not working the way you would like it to work, right? To me it doesn’t seem ‘incorrect’ that it jumps back. The issue really is that once you reach the end of the cycle range the system punches out of automation record and that to me makes some amount of sense. If you start at zero and ride levels up and down throughout the loop and then end at -29dB then the beginning would drop to -29 when you loop back if it worked the way you wanted it to, right (still holding the fader)?
Aside from all the other issues raised by this post, what essentially may be considered a more traditional way of working, e.g., starting from the beginning of a song, or other point in a piece of music, to then commence automating, is to my way of thinking, not so akin to rehearsing a fade so is there anything you would propose in this situation?
Don’t understand.
All of the options are there.
To end, to start, to loop, latch, trim, touch, virgin territories …
Still not sure what you want to do.
-Write in real time: move fader automation => automation is written as long as you move the fader. Snaps back to starting point when you let loose of fader.
-Preview: Select range (to start, to end, loop, …), Hit “preview”, write/re-write automation. When happy: hit “Punch” => automation is written.
Yeah, I’m also not really sure what you want to ultimately accomplish. I understand what you’re saying is happening but I don’t understand what you want to do, and how you want to do it.
We understand that. But you can turn off cycle before reaching that point.
What we were asking now is what it is you want to accomplish here. Like, why do you need to continue writing as you loop back from the second cycle point to the first? What is the ultimate goal? Perhaps we can find a different way to do it.
Basically, I need to be able rehearse automations, while in Cycle Mode and have at least the last iteration remain active.
How that might work, I don’t know because it is as you say, at a different level when coming back to the first Marker, or Cycle point in the song.
There were other points made in this thread in respect to automation, which I am hoping can somehow be addressed by the wonderful and all-thinking devs.
Ok, so I’m guessing what you want is not a static line throughout the cycle range, but automation that varies within the range, correct? If that’s the case then I understand what you’re saying, but it’s also practically arguably useless a lot of the time since automation would overwrite the values at the beginning of the cycle when it loops back.
Really your best bet here is to just lift your finger/cursor off the fader when it loops back and re-touch it to enable automation again. Yes, you wouldn’t be writing automation exactly when it loops back, but you could do it pretty quickly after if you’re using a controller with touch enabled.
So basically it looks to me as if your workflow quite frankly isn’t good.
And if you are talking about writing a static line/value throughout the cycle range then what Fredo wrote is the way to go.
What is the difference between “trying” an automation line until it’s “right” and then commiting the result and writing automation 'till you get it right?
You can enable the automation history so if you screw up, you can always go back to your starting point.
Or, if it really is so complicated that it is barely do-able with a fader, then just design it by mouse.
Well I meant there is a difference between using preview with “fill to loop” and not doing that. If you use it you end up with a line between the in and out points. Think for example of you looping a section where a bicycle is moving front distant left across the screen to your right, but also wobbling back and forth because the rider was drunk. You wouldn’t want a straight line then but instead a sound that moves back and forth. If you don’t use preview/fill but instead only touch you end up with automation that moves within the cycle according to how you moved the fader.
I thought the latter is what the OP wanted and there’s no way to do that without it dropping out of the write pass as it loops back - i.e. the writing isn’t continuous as it loops so the user has to let go of the fader and re-touch it to get it to write again within the cycle range.
Does the setting ‘Continue writing on transport jump’ not achieve this?
Just did a quick test and wobbled my channel volume up and down during a loop and with this setting activated you can keep writing over your previous pass for as long as you like, until you stop/let go of the fader. I can see how it would be useful, but not ever missed it myself
It sort of works but you still get a different “problem” because when it returns to the beginning of the loop it will read that value. So really the only difference is that you don’t have to let go and re-touch the fader with “continue writing…” on, but you do have to move the fader at/after the return in order to get a new value read.
So if you start with the fader at zero and after four seconds move it down within the loop range to for example -20dB and hold it there while it loops back the automation will actually not write when it returns, and if you wait for a second and then continue to move the fader you’ll get an instantaneous drop from zero to -20dB when it starts writing again.
This is essentially what it looks like after it returns before I move the fader again:
And here is after I’ve moved the fader:
The fact that I can do the above and basically use undo/redo to show you those images shows that it is in a way not ‘technically’ a case where it is continuing to write, but instead starts a new automation pass when it loops back.
Hope that was clear.
That’s what it seems I must do and am doing; however, I have to either click on the screen area adjacent to an automation lane, or else click on the lane itself before creating an automation node and if not, I get multiple automation points being created near each other which must be removed, or else prior automation points are deleted, surely this isn’t desired behavior.
