In last month's Cubase workshop we looked at how to write automation data on a track. By default, Cubase writes automation data in a mode that's known as 'Touch Fader' in Cubase speak. This basically means that Cubase will write automation data (when in write mode) at any time you're touching the fader, even if you aren't actually moving the fader, overwriting any pre-existing automation data for the parameter being 'touched'. Obviously it's not actually possible to 'touch' an onscreen control, so if you're using a mouse, 'touch' means to click and hold an onscreen control without releasing the mouse button. However, if you're using a hardware control surface with Cubase that offers touch-sensitive controls, 'touch' literally means touch.
In Cubase SX and SL, Touch Fader automation is used in conjunction with the Automation Return Time setting, which is part of the Automation Mode toolbar on the Project window. If you can't see this setting, right-click on the Project window's toolbar and make sure Automation Mode is checked. The Automation Return Time (ART) is the time it takes from when you stop overwriting automation data for the value of the parameter to return to the value of the next Automation Event of that same parameter, and can be between one and 2000ms.
For example, say you have automation data written for volume that keeps the level roughly at 0dB and you overwrite this with a fade-out in one part of the track. If the ART setting is 1000ms and you release the fader at around -64dB, Cubase will automatically write automation data so that the channel smoothly returns to the level of the pre-existing automation data (from -64 to 0dB) over a period of a second. This prevents the volume suddenly jumping from -64dB to 0dB, which would happen if there was no ART feature, or if the ART was very short.
In Cubase SL (and SE), Touch Fader is the only way in which automation can be written, but Cubase SX users have four other modes available to them: Autolatch, X-Over, Overwrite, and Trim.
In Autolatch mode, as with Touch Fader, Automation Events are recorded (overwriting existing data) from the minute you 'touch' a parameter. However, in this mode Automation Events will continue to be recorded once you have released the parameter and until you stop the transport.
X-Over is similar to Autolatch mode, except that once the parameter you're automating is released, Cubase will stop recording Automation Events as soon as existing Events are encountered on the track.
Overwrite mode is again similar to Autolatch mode, with two exceptions: firstly, Overwrite mode only works with Volume Automation Events, and, secondly, Automation Events are recorded (overwriting existing data) the instant the transport is running, until you stop the transport.
Finally, Trim mode, like Overwrite, also only works with Volume Events; but rather than writing completely new Automation Events it allows you to proportionally adjust existing volume automation data. When you start the transport running in Trim mode, the volume fader moves to a central position where moving the fader up increases the level of all Volume Events relative to each other before the Project Cursor, and moving the fader down decreases the level of all Volume Events ahead of the Cursor.
Usefully, you can also use the Trim mode offline as well. With Write Automation enabled on a given track, selecting Trim mode and moving the volume fader for that track will trim all the Volume Automation Events on that track between the Left and Right Locators. The last part of that sentence is the most crucial, as it's easy to forget to set the Locators appropriately, although it is really neat to be able to trim certain sections of a track by setting the Locators to specific locations. To ensure you're trimming all the Automation Events on the track, right/Control-click in the Volume Automation track and choose 'Select All Events', followed by 'Transport / Locators to Selection', which will set the Locators to encompass all of the Volume Automation Events on the track.
Editing Automation Events In The Project Browser
In the examples discussed in last month's Cubase workshop, we were looking at automating parameters on audio-based tracks; but it's also possible to read, write and edit automation data for parameters on MIDI-based tracks in exactly the same way, via a track's [R] Read and [W] Write buttons, along with the Automation sub-tracks. The parameters that can be automated for MIDI-based tracks include Volume, Pan, Mute, the Send and Insert Enables (along with the controls for any MIDI Insert plug-ins you might be using), and most of the controls from the Track Parameters Section (including a global on/off toggle), such as Transpose, Velocity Shift, and the Random and Range settings.
Being able to automate some of these parameters might not seem especially useful at a first glance, but being able to automate pitch- and velocity-modulating parameters such as Transpose and Velocity Shift can lead to some interesting creative ideas. Back in the Cubase VST days, for example, I was once asked to hack together a makeshift transpose fader to add variation to some taiko samples. Because the taiko samples were laid out on the keyboard with a different (but similar drum) sound assigned to each pitch, you could take some very basic rhythmic patterns and move the transpose fader to create more complex, varying patterns. This would work especially well with fast, straight patterns, and is effective when there are random notes on the keyboard that have no sample assigned, so as to create gaps. Creating these types of effects is now much easier in Cubase SX with the ability to automate a track's Transpose parameter.
Standard MIDI Controllers can also be added as Automation Parameters, but this where things can get a little complicated because working with Controller data as Automation Events is completely separate to working with Controller data as MIDI Events in one of the editor windows, such as the Controller Lanes in the Key editor. This is a problem because both types of data can co-exist and produce conflicting results that are confusing for the user and for Cubase.
If you're not completely sure what I'm talking about, let's consider the Volume parameter as an example: when you move the volume fader on a MIDI track in Cubase, the program will send MIDI Controller 7 (Volume) data to the appropriate MIDI device. To save the conflict of two automation parameters producing the same data, you'll notice that Controller 7 isn't available from the Add Parameters window, since it's effectively the same as the track's Volume parameter. But what if you have Controller 7 data programmed in your MIDI Parts and you have recorded volume automation data on the MIDI Track as well?
Multiple Track Trickery
When you have multiple adjacent tracks in the Track List that you need to rename (such as after adding several MIDI tracks via the 'Add Multiple Tracks' command), renaming each one individually can be a real pain. Fortunately, there's a quicker way of carrying out this task: double-click the name of the first track you want to change and type in the new name as normal, but instead of pressing Return (or clicking outside the text field) to exit, you can simply press Tab to jump to the next track's name in the List, or press Shift-Tab to move to the previous track's name.
When you have finished renaming tracks, press Return or click outside the text field to exit as normal. The track that was selected when you started renaming tracks will still be the track that's selected in the Track List.
To take a worst-case scenario, imagine you have MIDI Controller 7 data recorded that represents a fade-out over two-bars. What would happen if you had Track Volume Automation Events in the same two-bar period that were performing a fade-in? On playback, the MIDI output of the track would contain both the MIDI Controller 7 fade-out data, and the Automation Events, which Cubase would also translate into MIDI Controller 7 data. Because we can have two sets of volume data represented in two completely different ways, that end up sending the same type of message to our MIDI device (be it an external or VST-based instrument), the result is completely garbled.
One easy solution is to only use one area of Cubase to work with MIDI Controller data: either work with this data as Automation Events or MIDI Events. However, the problem here is that if you choose Automation Events, you can only work with the data on the Project window, and if you choose MIDI Events you can work in one of the MIDI editor windows. Since both sets of tools have advantages and disadvantages, it's no wonder that users naturally gravitate towards mixing and matching to get the best of both worlds, which leads to the type of conflicts described earlier.
In terms of volume, one good approach is to think about how, in a musical sense, track-based automation is used compared to how MIDI Controllers are used. Track-based automation is intended, at the most basic level, to record the movements of Cubase's internal mixer. While MIDI Controllers can and have been used to remotely control mixers, they also have a second purpose, which is to provide articulation data for a MIDI instrument. By articulation data, I mean parameters such as modulation, or even volume in the dynamic sense, such as when you record MIDI Controllers to mimic the way someone would produce louder and softer tones while playing an instrument. In this case, we're talking about a performance and not a mix parameter.
The good news is that when the list of MIDI Controllers was drawn up, somebody was obviously thinking about this problem. One Controller often forgotten is Expression (despite the fact that most instruments, hard and soft, support it), which is basically a volume fader that sits before the regular MIDI Controller 7 volume fader. This means you can record your dynamic volume as Expression MIDI Controller data and leave Cubase's track-based volume control as a trim for the output of that channel. You can have two different types of volume data playing back at the same time without interfering with each other.
The above workaround is obviously only suitable for avoiding volume conflicts, and right now there isn't a really good workaround for other types of MIDI Controller data. On the plus side, though, a command called 'Extract MIDI Automation' was added in SX 3 that allows you to convert Controller data represented as MIDI Events in MIDI Parts into track-based Automation Events. To use this command, simply select the MIDI Part (or Parts) in question, choose MIDI / Functions / Extract MIDI Automation, and MIDI controller data will be converted into automation data.
A final Preference that's handy if you use a hardware MIDI controller for recording Controller data is 'MIDI Controller Input to Automation Tracks', which is found on the MIDI page in the Preferences window. When this is disabled, MIDI Controller data is recorded as normal (if you're in record mode), as MIDI Events in MIDI Parts; but when it's enabled, incoming Controller data remotely controls automation parameters on the selected MIDI track instead. In this mode, you can record Controller data and some track parameters (volume and pan) as Automation Events in the same way you would normally write automation data, but using your regular MIDI hardware controller. However, note that this only works with MIDI tracks (you can't write volume data for a selected audio channel in this way, unfortunately), as the purpose of the feature is to prevent you from recording Controller data as both MIDI and Automation Events.
Understanding automation can greatly improve the quality of mixes produced entirely in Cubase, and, once you've got the hang of it, you'll start to see why hardware control surfaces are so useful. Although they don't actually add anything sonically to your work, one area where they really are useful is writing automation data — especially if they have touch-sensitive controls. Stay tuned for more about this in a forthcoming Cubase workshop article.