Music production, and especially the mixing of music, is a curious beast. I do a lot of writing, recording, mixing, and production in my spare time, and will never forget my mentor explaining to me how recorded music is a “trick”. Hit the “solo” button on any instrument on the console during a dense mix and you’ll hear the strangest things. This button mutes all the other channels so you can hear only what that specific instrument is doing. Hit that, and suddenly you’ll hear guitars that sound like angle grinders cutting through ice; vocals that spit and fizzle like a roman candle; drums in mineshafts. Each on its own sounding nothing like the original instrument, and leaving you wondering how on earth it could possibly work. But pull everything else back up, and the collision of the sounds, and the way they blend, suddenly falls back into shape. Every instrument sounds richer and fuller and, strangely, clearer.
This is why many Producers will warn you against working on instruments “in solo”. You can spend hours fiddling with individual sounds, tweaking their EQ, dynamics, reverb, and effects, but this is all meaningless without the context of the full mix. In fact, working in solo is probably one of the best ways to waste time when working on a dense arrangement. You’ll most likely end up undoing everything you’ve tweaked in solo when you open up the rest of the tracks.
One of the oldest jokes in mixing is “What is the loudest track in the mix? The last thing you worked on.” Hilarious, I’m sure you’ll agree, but very, very true.
Hyper-focus is extremely important when mixing music. You need to be able to pick out where the issues are coming from, and rectify them with a laser focus on many disparate but related levels. Timbre is always key. Does an instrument sound warm, or harsh, or spiky, or dull? Obviously changing the EQ will alter this, but changes to other things will also affect this massively. Changing the dynamics with compression will change the timbre, as will adding more or less reverb, or a different type of reverb. Also, because of the way human hearing works, even changing just the volume of an instrument in the mix will alter its perceived timbre. It’s a fine balancing act. A trick!
Again though, any issues can only be fixed in the context of the mix. And a mix is also about much more than being able to hear every instrument. The emotional intent of a song also rests heavily on the shoulders of the Mix Engineer and the Producer.
Technology is too often seen as a precise science. If you do X in one part of a platform, then Y will happen at the other end. Certainly the underlying code is precise and atomic enough to do its thing unfettered by anything else, but once you get into the wider ranges of a large platform, it can begin to feel like a symphony orchestra. Complex interactions between components is what gives platforms their power and their “feel”. This is where the business logic lives, and where the true value of the system lies.
This is why a strong Business Analyst, Technical Project Manager, or Product Owner will give your platform the oversight it needs. They are the client in the room, and their job is to keep shaping the overall, whilst co-ordinating the minutiae. However, this is an approach that can, and should, be shared across the entire team.
Gregory Scott is one of my favourite people when it comes to strategies for music mixing and production. He’s an audio hardware & software developer that makes all sorts of wonderful outboard EQs, compressors and the like, but he’s also a very talented musician, Producer, and Mix Engineer, whilst being one of the most chilled orators on the planet.
He has a fantastic approach to help engineers struggling to bring their mix to fruition, and it involves just three main things:
Work fast.
Small moves.
Shave the mix.
By working fast you don’t spend too much time on any one thing. Listen to the mix, and when you’ve got 3 things that you want to change, stop and work on them. But make small moves. Knock the offending tracks up or down by 2 decibels, or pull back the high or low EQ on them by 2 decibels. Then play it again and see what you’ve done.
Shaving the mix is something that Gregory’s early mentor gave him. You don’t gouge out huge sections of a song and hyper-focus for ages on one area. You work from the outside in, making small shaves towards your goal each time you go through the song. Take breaks often. Go outside. Hear something different for a while. Bring your focus back to the overall, and listen again.
This is essentially Agile development in another realm. In Agile, the ability to build and release small packages of functionality is really powerful, but too often we miss its greatest strength - iteration.
Now, I’m not talking about Agile requirements. I would NEVER talk about that. That way lies madness. No, what I’m talking about is shaping your Epics and Sprints to do more of a “shave” of your project plan, rather than carving out big solid chunks. Too many “Agile” projects are simply chunked up waterfall in disguise. A set of weirs, I guess. Yeah, I’m having that.
The next time you have to plan a project, try laying out the Epics in a way that initially gets you all the way through the platform as quickly as possible. It will be rough, and it will be clunky and there will be huge gaps, but you will have made your first shave of the entire application. Epics don’t have to be complete, shiny, finalised boxes. There’s nothing to stop you from having Epics such as “From Registration to Download (Rough)”, and later “Registration (Finalise)”. Ironically, Agile is actually still a marathon, not a sprint. A-ho ho.
One of the real benefits of this is that the team will be taken through the entire platform, or at least a huge percentage of it, in one fell swoop. This will give everyone the insight they need in order to see how the entire platform is supposed to hang together. It will help the whole team understand dependencies and interplay in genuine, tangible terms. Not just esoteric relationships between tickets on the board. It will also help to highlight potential interoperability issues before you get to finalising each component; it's a much more human and natural way of seeing things; and it’s a great way to get the whole team thinking about the overall, contributing to it, and feeling valued for their contribution.
One of the most challenging aspects of software is that initially it lives entirely in your head, and it can remain there for a very long time throughout the development process. During that time, the team can really suffer from a loss of perspective, and how what they’re doing fits into everything. Getting it out into the real world so everyone can see what its going to do is a real blessing.
Then everyone can get their razors out, lather up, and shave away until the platform is shiny, smooth, and er… splashed all over with Brut? Mental note - it is possible to take a metaphor too far.
If you fancy listening to Gregory take you through this from a mixing perspective, hit this link.