1. Not loading your session after console boots

Probably 8 out of 10 issues I have had with users and their sessions arose from the simple fact that they set up their FOH, boot up a console that has been sitting in storage for a week and then transported to a venue, and dive into their work without reloading their last saved session. There could be a minor chance that the session got minutely corrupted if the shutdown procedure was not completed properly (maybe the power was cut before the shutdown process was completed) and the session will start giving you issues down the road. Or somebody else might have been using the console (especially if this is hired from a rental company) and changed your session by accident. You always have the option of recalling the backup session that the console creates regularly, but it is way better to use common sense and make sure that the correct session is being used. With that in mind – always remember to load your session after a console reboot (preferably from a USB drive that you have) – it is one of the best ways of ensuring that your event will go smoothly.

2. Not saving your work

DiGiCo consoles are built with redundancy in mind. However, you should always save your work as you make changes. Sure, you can rely on the fact that the audio engine is completely separate from the control PC and that the NVRAM chip will keep your audio going in case of major issues, or on the fact that the console creates sessions and backup sessions in the background. But in case something goes really wrong (like a power outage), you always want to have a session that you have saved yourself. It is like relying on the word processor on your computer to save your work – sometimes those auto saved documents are missing the last two sentences you wrote.

I can’t tell you how many times I have seen engineers recall their sessions, realizing that they forgot to save their work at the end of yesterday’s gig and they now have a different starting point than the one they hoped for. There are two things that can be saved: the snapshot and the session. The best approach is always to save both. Make it a habit to regularly save your work every few minutes. The rule is- save your snapshot before firing another snapshot. If you do not, the console thinks you are still making changes and the snapshot you have been working on will not be saved. A quick tip: create macros for Save Session and Update Current Snapshot functions, so you can quickly perform these actions without exploring the menus.

Create Macros to quickly save sessions and update snapshots without going into the console menu.

3. Not realizing that recalling a snapshot might not recall your preamp gain by default

If you are using snapshots in your sessions, the preamp gain information might not be recalled, if you do not turn that option on. This is meant to prevent your gain settings to change within a session when you change snapshots. However, you can find the option to recall Input Gain and Trim values from your saved session in your Snapshots > Global Scope menu. If you want to make certain that your snapshot Gain values, I suggest you insert a new snapshot to the first snapshot position, turn on the Input Gain and Trim values in the Global Scope menu, and make sure that the rest of the snapshots have these values turned off (unless you are mixing with gains as well). Then reload your session. You will now have all of your preamp values recalled from your snapshot.

But beware – this setting is off by default for a reason. Let’s say you recall the gain from the first snapshot and then have the rest of the snapshots not recalling the gain and trim. You make a gain change during the show and save your session. When you recall the first snapshot next time, your change will be lost and gain returned to the values stored in the first snapshot. Make sure that you register your changes in the “Gain Snapshot” as well so that you do not lose your work.

The default setting does not recall preamp values. Go to Snapshots > Global Scope and press on the red crosses in the Input Devices row (turn them into green ticks) to recall preamp value from your saved session. Remember to re-load your session to finalize the procedure.

4. Using snapshots instead of sessions

One of the common mistakes that I have encountered is a misconception of what snapshots can do. I’ve witnessed engineers trying to change channel types, ganging, or even mono to stereo values of a channel in snapshots and became frustrated when those values would not change when snapshots were recalled. What I always suggest to them is to imagine sessions as all of the information data for a specific band and snapshots all of the data for specific songs of that band. To oversimplify – snapshots are there to change values of the same channels, sessions are there to recall a completely new set of channels or console properties. When those rules are kept in mind, there are usually no more problems with programming and running a show on a DiGiCo console.

5. Using parallel signal paths without considering latency

This is one for the slightly more experienced users. One of the best features of a DiGiCo console in my opinion is the option to route anything anywhere. You can set channel inputs to listen to aux or group busses, merge inputs, run the same preamp channel to multiple inputs and those inputs to various bus combinations – the possibilities are endless. But there is one trade off – in order to achieve that level of freedom and flexibility, there is no built-in delay compensation feature. Still, DiGiCo has made it quite easy for us – every channel strip has an equal time-length. No matter what type of channel it is (input, group bus, aux bus, matrix) and no matter what internal processing you use on that channel, they all produce a fixed time delay of 14 samples (290uS @ 48kHz, 145uS @ 96kHz). If you route an input channel strip to a master bus, it will produce 14 samples of delay. That holds true for all channels with that direct path. However, if you route an input channel to a group and that group to a master bus, the signal goes through two processing channels, each adding 14 samples, with a total latency value of 28 samples. It’s like stacking LEGOs – if you want to have the same height of your tower (equal time arrival), use the same amount of LEGOs. So the engineer has to be mindful of that when doing more complex routing.

The most common mistake I encounter is the setup for parallel compression. A channel is sent directly to the master bus and at the same time to a group bus, which gets treated with heavy compression and then sent to the master bus. So the same signal has two different path lengths and there are audible phasing issues when the compressed bus is added into the mix. Solution: be mindful of the signal path when programing the console. A simple fix to the above mentioned conundrum would be to create 2 group busses – one for clean signals with no processing and one for processed signals. Route all channels to the clean group (and of course not directly to the master bus) and the channels that you want to process to the second group. When you send both groups to the master bus, you have perfect time alignment and no latency issues.

DiGiCO consoles are one of the best tools of our trade, that is why they are so commonly used for the most demanding projects. Most of the users in the field have encountered at least some, if not all of the above mentioned scenarios and don’t even think about them anymore, because the console has become so second nature for them. But I always feel we should constantly brush up on the basic – that allows us to avoid major issues and propels us to explore the vastness of options these consoles provide with confidence and ease of mind.