Automation Paradigms and Mixing System Design

Not so many years ago the only mixing automation available to engineers was a group of people gathered around the mixing desk awaiting their turn to move a fader, pan or EQ at the right time... at the proper level.

It seems almost unbelievable today compared with what we do commonly with computers today. I'm sure if someone told me back then that I was going to be able to someday have a system that would remember EVERY move that I made, I would have laughed at him/her but secretly dream it would come true.

After years of trials and many disappointments, engineers and designers came up with a system that could record the fader "moves" for you then play them back in real time.

This was not a small task. I still remember the early MCI automation systems that used to encode fader moves on audio tracks. One was supposed to record the "first pass" of fader moves onto track 1, then for the second pass, one would add those moves plus any additional moves onto track 24... this process of bouncing data back and forth between tracks 1 and 24 would continue until the mix was perfect (well almost).

Unfortunately, designers forgot to figure in the fact that there was a few milliseconds delay every time you bounced tracks from one analog track to another. By the time the mix was done, one's fader moves could start several milliseconds late!!!!

After talking with Rupert Neve several months ago, I asked him about the early days of Necam (one of the first moving fader systems). He told me of early prototypes that could rip your fingers off because there was no such thing as a "touch sensitive" fader back then. One was forced to tell the "computer" when you wanted to make an automation move, grab the fader, move it, then tell the computer you were done. If you forgot to tell the computer you wanted to make a move, and you grabbed the fader first, the fader was strong enough to cut your fingers!!! (ouch!)

We both laughed when he told me of this... Today, we would never dream of designing a system where you had to tell the automation EVERYTHING you wanted to do BEFORE you did it... or would we?

Common concepts

Punch-In Mixing

Not too long after the early days of automation, and during the beginnings of digital mutli-tracks, engineers "figured out" that one could use 2 tracks of a multi-track recorder to mix to. Since the 2 mix tracks would inherently be in sync with the multi-track data, the engineer could "punch-in" sections of a mix to get the mix sounding perfect.

But this scenario doesn't take into consideration those situations where someone might want the EXACT same mix but with the vocal up 1 db or 2... or maybe do the EXACT same mix WITHOUT the vocal... Oops, this blows this idea.

Since the mix data was written onto the 2 mix tracks as AUDIO data, any punch-ins would ERASE the previous audio data and he/she would be have to try and duplicate the settings of the faders for that time period on the tape. This was unacceptable. BUT THE IDEA OF PUNCHING-IN LEVELS WAS GOOD.

SMPTE based automation.

SMPTE is an acronym that stands for Society of Motion Picture & Television Engineers. These guys are responsible for defining STANDARDS in the Motion Picture and Television industry.

One of the standards that they came up with is SMPTE timecode. This is a method of writing time information into various formats. One of the things it allows for is time to be written as an AUDIO track on a multi-track tape recorder.

The ramification of setting this standard was to allow the synchronization of separate devices via an audio signal.

This meant the days of bouncing data between tracks 1 and 24 to store fader moves were gone... and one did not have to re-create fader moves and positions when one did "punch-in" mixing onto 2 tracks of a multi-track.

It also meant that one could store fader "moves" onto some kind of storage device (a disk drive, for example) and those "moves" could be read back at a later time and be used to make the fader "move" at the appropriate time without engineer intervention.


One of the first paradigms to appear in mixing systems was the read/write/update paradigm.

This is a paradigm used by many automation systems that can separate the moves of a physical fader from the moves of the device that changes the level that one hears. (Usually a VCA... Voltage Controlled Amplifier, but with Digital Audio Workstation's it is more than likely a 'number' controlling the Digital Audio Level, or a DCA... Digitally Controlled Amplifier, or even more likely, a DAC... Digital Audio Converter).

By contrast, in a MOVING FADER SYSTEM, the fader IS the component that determines the level of the audio. This is because the audio signal actually goes THROUGH the fader before it reaches outside of the console. And the PHYSICAL POSITION of this fader determines the AUDIO LEVEL which is heard.

Note that in a VCA based system, however, the fader's physical position doesn't have to be the same as the audio level that you are hearing. This is because the fader's physical level merely sends a "signal" to the VCA to 'be' at a particular playback level.

An automation system that uses the read/write/update paradigm usually has 3 buttons for each and every fader that would determine the "status" of a particular channel for mixing.

The buttons are usually labeled as follows:

read (vca 'looks' at disk information only)

write (vca 'looks' at fader move information only)

update (vca calculates and uses an offset derived from both fader and disk information)

The advantage of this system are twofold... the user/engineer has instant access to any channel at any time to change a fader level. But most importantly, It was easy to learn.

The disadvantage of this system is that the user/engineer was LIMITED to moving only the number of faders that he/she could grab at one time. This is fine when one doesn't care how long a mix takes, but NOT good when things have to be done in an expedient and efficient manner.


One of the least understood but MOST POWERFUL paradigms is the MIX REVIEW / MIX RUNNING paradigm. This is used mainly on high end console automation systems such as SSL and others. But there is NO BETTER automation on the planet than this that I know of.

This paradigms allows the engineer to move multiple faders (more faders than he/she has fingers) with great ease and WITHOUT using groups! It is intuitive (once you learn the basics) and extremely powerful.

How is this done WITHOUT telling the computer what to do?

It's done with MIX REVIEW / MIX RUNNING status.

MIX REVIEW simply means we're in a mode with the automation that simply plays back the automation moves that have already been written to disk and we're LISTENING to the moves that we've already done... MIX RUNNING means we're actually MIXING right now and recording new fader moves. (and these moves either DIRECTLY correlate to the levels we hear, or they are OFFSETS to ones already written to disk)

Here is an example.

Assume we are mixing 32 channels and we've made our first pass of automation and have made our faders move in their appropriate positions for most of mix.

We re-wind the tape (or hard disk) to the start of the mix, and push play. The intro goes by... all is well... (let's assume we don't need to change the intro).

The verse goes by... oops, we need to turn on the vocal track, lower the guitar track, change the mix on the drums, and lower the piano track.

This is more moves than we have fingers!

And unfortunately these tracks are spread across the entire console and in order to change their levels we would normally have to make multiple passes to adjust these levels on most automation systems.

But with a MIX REVIEW / MIX RUNNING system, all we have to do is move the faders of interest (no need to stop the tape/disk... just keep it rolling) and when we get all of the faders/mutes to the appropriate levels/states for the verse that we are currently passing, then re-wind the tape/disk to just BEFORE the point where the verse starts.

Push play and as the beginning of the verse ROLLS BY, press a button (it's called a 'join' button) and ALL of the channels will change to their new appropriate offset levels... that's it... no groups, no buttons to push on each fader, and since we were listening to the mix as it went by, we already know we've written the correct levels to disk.

This is NOT the same thing as recalling a 'scene' or static fader levels (as an O2r does). But instead, this is doing what is called in SSL terms a 'JOIN' mix... We are JOINing a new mix to an existing disk mix in real time.

In a MIX RUNNING / MIX REVIEW situation, when the tape/disk is stopped, the SMPTE timecode stop point is "remembered" as a CROSSOVER POINT

Fader moves made BEFORE this CROSSOVER POINT are considered "already written" to disk, and the system simply "reads" those disk levels as the automation levels sent to the faders/DACs.

The part of the mix AFTER the crossover point are considered NOT written to disk and the system will go into a "write" or "trim" mode state when the system crosses over this point.

Continuing with our example from above, at the CROSSOVER POINT (just b4 the verse in this case) the user presses a key which simply moves the "crossover" point to the beginning of the verse. Simple and elegant! The user could have changed EVERY FADER on the console and the system would have updated ALL of those faders for the user with the push of a single button. All WITHOUT the user having to tell the computer ANYTHING. It is inherent in the design of the system and is ALWAYS available. It is the MIX REVIEW / MIX RUNNING paradigm.

This system is far superior to having to tell the computer to "remember" this or "remember" that. It is inherently intuitive and once the concept is grasped, extremely FAST! There are no buttons to tell the computer to 'read' this or 'write' that... it is elegant.

Finer points to consider...

Once I have spent an hour or so riding a vocal track to "smooth" it out, the last thing in the world I want to do is re-do my automation moves.

But MOST moving fader systems REQUIRE that you re-do your moves, or work OFFLINE to do updates to levels... this is because MOVING FADERS are CONNECTED to their audio controlling devices (real faders). They do not provide for doing 'updates' to a previous pass because the audio level is DETERMINED by the physical position of the fader.

Touching a fader on a moving fader system (placing that fader into write mode) inherently HAS to over-write previous moves... This is the big drawback for moving fader systems.

There is no easy way to update a moving fader mix without having to "re-do" previous moves. (unless you're using a system that has BOTH moving faders and VCA's... like in an SSL ULTIMATION system)

This is because the PHYSICAL position of the faders IS the audio level that we hear.

I will return to this topic after I explain the following...

Absolute, Trim, and Auto-Takeover

What is needed in many mixing situations is the ability to get "in" and "out" of a fader move easily and quickly.

There are many ways to do this. In read/write/update systems, you simply hit the button you are interested in at the appropriate time, move the fader, then hit the other appropriate button to get out of a move.

A much more elegant way to deal with updating a fader move is to reduce the number of buttons that the user has to hit to a minimum. (How about just one?... and let's call it a STATUS button). In addition, wouldn't it be nice if we only had to hit that button ONCE and the system "knew" what to do when we hit it?

The solution is to add 'modes' of fader operation.

Wouldn't it be nice if we could do writes on some faders, reads on others, updates on others and make absolutely sure that some other faders are not changed at all?

Also, wouldn't it be nice if the MUTES were treated ENTIRELY separate from the fader moves?

The answer to the above questions is YES to both!

This is done with the following 'modes' for each channel fader/mute combination...








Each fader can be in its own 'mode' and this paradigm only requires ONE status light to 'know' what mode you're in for each fader.


In all of the cases below, if the play position is BEFORE the 'crossover point' the levels are read from DISK (also known as MIX REVIEW)... The 'modes' listed below apply to the channels when the play position is AFTER the crossover point. (also known as MIX RUNNING. This 'crossover point' is remembered for EACH fader and not just the entire console... (I will explain the reasons for this later on in this paper)

When a fader is in ABSOLUTE mode the PHYSICAL position of the faders IS the level that we hear (or more correctly, the level that the VCA/DAC is operating at...) Meaning that if the fader is PHYSICALLY positioned at the bottom, the VCA/DAC is at its lowest level. If the fader is PHYSICALLY positioned at the top, then the VCA/DAC is operating at its maximum level.

Note: (see below)

When a fader is in UPDATE/TRIM mode the PHYSICAL position of the faders is RELATIVE to the level that we hear (or the level the VCA/DAC is operating at...) Meaning that if the fader is PHYSICALLY positioned at the bottom, the VCA/DAC maybe somewhere else. The ACTUAL level that the VCA/DAC is operating at is determined by BOTH the PHYSICAL level of the fader and the DISK LEVEL written to disk from an earlier pass.

Moving the fader adds to or subtracts from the levels written to disk.

In other words, if at the start of this mix pass the VCA starts at 50 and the fader's physical position is at 25, the actual VCA/DAC level is 50. But if the fader is moved to 30, then the VCA/DAC moves to 55. This OFFSET for each fader is determined by the fader's PHYSICAL position at the start of the each mix pass.

This essentially creates a 'moves on moves' scenario. In SSL terms it is called a 'join' mix.

When a fader is in READ mode the PHYSICAL faders is DISCONNECTED from the VCA/DAC... Moving the fader while in this mode DOES NOTHING to the audio.. The VCA/DAC levels are controlled TOTALLY by those written previously to disk.

The difference between READ mode and DISCONNECT mode is that in READ mode, fader levels are still recorded, but are not used unless the 'join' key is hit. If the 'join' key is hit, then the disk levels are 'trimmed' by the offset difference of the fader moves made during the mix pass.

This mode is the most fun and one of the most useful. When a fader is in AUTO-TAKEOVER mode the channel starts out in a mode similar to UPDATE/TRIM mode.

In other words, if at the start of a mix pass the VCA starts at 50 and the fader's physical position is at 25, the actual VCA/DAC level is 50. But if the fader is moved to 30, then the VCA/DAC moves to 55. But after the user hits the 'status' button on that channel, the fader 'looks' for the point where the VCA/DAC is currently. (this VCA/DAC level comes from disk).

When the user moves the fader up to (or down to) the point where the fader level matches the VCA/DAC level, the channel changes its status to DISCONNECT mode... and from THAT point on, the fader moves are IGNORED by the automation system.

From that point on, toggling the 'status' button switches between AUTO-TAKOVER and DISCONNECT modes.

This mode is fun because once the user has hit the 'status' button to go into AUTO-TAKEOVER mode, the user/mixer can simply SLAM the fader in a direction and the channel will go out of UPDATE/TRIM mode automatically.

This makes for EXTREMEMLY fast times to get out of a UPDATE/TRIM situation while mixing.

It also makes for very smooth exiting from complicated VCA/DAC moves... In other words, if previous passes produced VCA/DAC levels that are moving continuously, one does not need to try to 'match' levels to get out of an UPDATE/TRIM situation. Simply slam the fader in a direction and the channel will go out of the UPDATE/TRIM condition as soon as it 'passes by' the VCA/DAC level.

Although not specifically discussed earlier... mutes and levels are considered TOTALLY SEPARATE automation events... (as they SHOULD be) In this mode, Mutes are ALWAYS read from disk and faders are ABSOLUTE or UPDATED (depending on configuration).

Although not specifically discussed earlier... mutes and levels are considered TOTALLY SEPARATE automation events... (as they SHOULD be) In this mode, Faders are ALWAYS read from disk and mutes are ABSOLUTE or UPDATE (depending on configuration).

In DISCONNECT mode, the faders and mutes are DISCONNECTED from the VCA/DACs. Any movement made to either the faders or the mutes is ignored by the VCA/DACs. This is a must for those situations where the engineer is working with a 'hands-on' type producer who just can't seem to keep his hands off the console while he 'listens' to a mix. It allows for the mix to be played without the possibility of anyone tampering with it by accidentally re-writing faders or mutes.

DISCONNECT mode is different from READ mode in that fader positions are completely ignored by the automation system. Mix 'join' ignores these fader levels.









This is the same 'mode' that is used almost exclusively by most 'MOVING FADER ONLY' systems. It is very limiting but has the advantage of 'showing' the mixer the current levels of each fader at a glance.


Every pass on automation should be remembered... there are no exceptions... If automation is 'on', then fader moves and mutes should be recorded... period.

They should be stored as mix files with naming conventions similar to how you do tracks... pass one is automix.1 pass two is automix.2 etc. This will allow for unlimited undo's of mixes.

Also, keep SOLOs OUT OF MIX DATA!!! They don't belong there... SOLOs are dynamic temporary listening solutions for monitoring particular tracks... They have NO BUSINESS being written to disk.

If a bunch of channels are supposed to be muted, then write the mutes... don't use SOLO to do it.

This is all of the time that I have today to write about automation... However, if you would like more information, I would be happy to answer any questions that you might have about it.

In Closing...

There are other points that I did not go into in this paper because of time constraints. (specifically the differences between mix 'join' and mix 'revise'.