Flying Faders – a deconstruction of automation in modern digital audioworkstations

I use an audio program called Reaper and in the past two years or so there has been an ongoing discussion on how to make the program’s automation system more suitable for audio post-production.  In this post I’m going to lay out an idea I  had resulting from these discussions.  I would also like to put forward the theory that all functional automation can be described in a simple two state system.   In the interest of expediency I am going to assume you, the reader, have at least a moderate familiarity with digital audio workstations in general and their automation systems.

Automation in this case will be defined as the recorded and reproduced alteration of parameters over time.  The most popular representation of automation in modern digital audio is the envelope.  An envelope is a continuous line with nodes which together indicate changes in the parameter over time.  Audio is not the only area to make use of these automation envelopes.   Non-linear video editors make use of similar envelopes as do animators.  With animation there is even the common idea of writing automation through interaction with the content itself.  Moving the 3d model can result in an (often massively multiple) envelope controlled change over time.  The big difference is that in a visual pursuit like video or animation it is apparent at any speed or in any instant what the automation is doing to the actual content.  We as audio producers can not ‘see’ a moment of audio.  Essentially the transport has to be rolling at a meaningful speed for the actual content to be evaluated.

Arguably the audio discipline that makes the most use, point for point, of envelope style automation is Post-Production for video and film.  This is due mostly to high numbers of tracks in the average production combined with a longer than average program length when compared to musical or other broadcast pursuits.  When looking at the automation systems implemented in the two most popular software workstations for Post-Production one sees definite nods towards a linear, tape based legacy of automation.  The new ability to view a representation on screen of how a parameter changes over time is juxtaposed with the older ability to view a single snapshot or window of time of all parameter settings on the control surface of a fully automated console.  For example, on the console one merely refers to the current position of volume fader 1 to know what the gain setting is at timecode 10:13:05:05 .  It is simplicity itself to look up and down the console and survey 24, 32, 128 even 256 tracks of gain settings for that timecode value and only slightly more complicated to arm a track for changes.  Herein lies the appeal of console automation.  It is robust and fast when dealing with complicated automation over large numbers of tracks.  On the flip side there is absolutely no way other than to play forwards or backwards to know what is coming or to review what has just happened.  This is an almost diametric feature set to envelopes on a screen.

My first proposed state of automation is Record.  Just as any audio signal recorded into a DAW needs to be recorded in a linear fashion so should automation.  Overlapping recorded parts can be compiled or edited together to comprise the finished product but ultimately if a specific performance is desired and not a purely synthetic creation then recording needs to take place.

My second proposed state of automation is Trim.  For strictly practical reasons there is an increasing abundance of in-the-box, workstation only DAW systems and large format automated console/control surfaces (mixers) are disappearing.  This means the majority of DAW users, post-production or otherwise, are working with a keyboard, mouse and whatever they gather from the screen.  An informal survey of the colleagues in my local shows that almost all of them make almost exclusive use of this automation state.  They almost never Record automation and prefer instead to open and edit envelopes for parameters manually.  They use the mouse to draw in specific shapes that describe the desired parameter change over time.  This way of working has the advantage of intention.  There is no possibility of an accidental move.  It has the downside that it is time consuming and does not offer a clear representation of the actual content and the change being applied.  In simple terms, it’s difficult to listen to the change while it is being done.

I have noticed one thing regarding the current condition of automation as it is used in a DAW.  Users gravitate to one of these two modes of working (control surface or mouse and keyboard).  I theorize that two modes can accomplish nearly all automation tasks.  By simplifying to a switch back and forth between a mixer surface-Record mode and an envelope non-linear-Trim mode the user can be clear about what task they are doing.  This is valuable because one state has obvious (very nearly corresponding ) advantages for certain jobs over the other.

For the purposes of illustration and experimentation I have written a script in Python that accesses the exposed API calls in Reaper to simulate these two modes.

• Trim state is more or less done for me already.  Reaper does a rather odd and universal version of a trim on all track controls whenever all of the Four stated automation creating modes (Read, Write, Touch, Latch) are off.  This Trim/Read mode, which is the default mode has the interesting role of trimming the values of the automation envelope globally.   It is more defined by what it is not doing than what it is.  It is not recording or displaying automation.  The mix still reads the automation but the mixer interface does not display it.
• Record state is for performing actual automation moves with the mixer interface.  The goal is firstly to lock down as much of the current mix as possible with actual written information.  Ideally this mode should create a current value automation for all parameters in the mix based on the Trim fader value, the envelope value or a combination of the two.  The second goal of this mode is to put all controls into a state of readiness so that any needed changes the user hears can be immediately recorded using the mixer interface or control surface (if one is available).  For my script I selected Touch as the ideal mode for this as it preserves everything except the intended control changes.

Observe how this works in practice…

In this first example we have basic global levels set for the project and we are ready to start automated mixing.  Notice that initially all controls are in Trim/Read mode.  The script is run (that’s the pop-up window) so that all tracks now have volume and pan envelopes set to the current Trim/Read value.  I have chosen Touch mode as the most suitable for a default automation mode.  All tracks are now set to Touch.  It’s important to note that the Trim/Read value is reset to unity since it is added to or subtracted from the automated value.

Now we will record some automation onto a track using the Touch Record state.

Switching back to Trim mode allows us to make static level changes to automation over the entire project or, as in this case a time selection.  Notice that all Trim/Read fader values have been reset. Now when we switch back to Record state the script applies the Trim gain change to the envelopes within the time selection.

My goal in this is a more efficient automation experience no matter which interface you happen to sit in front of.  I would appreciate any thoughts on this paradigm of two state automation.  Comments are more than welcome.  I’m particularly interested in detailed scenarios which these two automation states would not be capable of.

If you are able and inclined the script will be available on the Reaper forum for testing.  At this point the script only applies to Volume and Pan but hopefully the idea will catch on and a more universal implementation can be a reality.