I am currently 5 weeks into a 12 weeks software bootcamp with Makers. This past week I have been thinking a lot about the concept of Object Orientated Programming (OOP) and I’ve been having a lot of revelations. One of them has been the similarities between the concept of OOP and the use and understanding of a recording studio — particularly a large format old fashioned studio.
I appreciate this blog may have a niche market. But it’s helping me get my head around things, so I’m going to get on with it.
A large SSL mixing desk
Recording studios and large format mixing desks are very intimidating in their complexity, and if approached only considering their wholeness, it can be very difficult to even begin to get a handle on it. The answer is to break it down into its components. If we take an 60+ channel SSL desk for example, it is physically huge, and it is literally covered in buttons and knobs. The key to getting your head around one is to understand that every channel is essentially the same. If you can get you head around that, then you have instantly reduced the number of things to get your head around from 60 to 1. Each of these channels receives one audio signal and can give it back to you several times at at several points. The sound travels through the channel as electricity, and on the way you are given the choice to divert the sound to other parts of the studio, and how much to divert. You are also able to shape the tone of the sound using an equalizer, and alter it’s dynamics using a compressor. Lastly there is a main fader which gives you the level going to the main mix.
So if we break it down it becomes a lot easier to understand.
Inputs (either/or)
Line in
Mic in
Outputs
Aux busses
Groups
Main bus
Ways to alter the sound within the channel
Tone (Equalisation)
Dynamics (Compressor)
A (much) younger me at the controls
The complexity comes from the many — there are many of the same channel. The complexity also comes from these many outputs as we can use them to send the sound elsewhere — and this is the bit that is really exciting me when I am thinking about OOP. The thing is you see, despite all the complexity and cleverness, whatever receives that sound knows absolutely nothing about it. I as a human being have decided to plug it into an effects unit for example — lets pick something iconic, an Eventide H3000 — but the Eventide has absolutely no knowledge of what it is receiving. So we have two things with massive complexity interacting to do something wonderful, but neither knows anything about the other. It is up to me as the engineer to make sure that I adhere to the specification at the output and input stage — and then they are free to do their job. In this example both the pieces of equipment are literally objects — they exist in the real world. But the point is that they interact with very simple interfaces and a short set of rules as level and impedance, and have no knowledge about what’s going on with each other. Very high level and very abstract. They each then have a user interface which is designed with the recording engineer in mind — this is a level lower and expects some knowledge, but is still an abstraction — with a handful of controls hiding most of the complexity. Lastly then you have how they actually work, which is not in the domain of the recording engineer (or not necessarily).
And essentially, that is the key to getting your head around a studio — you have many pieces of equipment (objects) — some of them grouped together (like in a mixing desk). They are connected with very simple connections which have simple rules (I’m thinking these are like parameters or exposed variables). Most of these are audio connections. Sometimes there is also some simple control such as MIDI or SMPTE. There are some controls that change things (I’m thinking like methods in a class). And then there is how they actually work — which, to be honest, is normally not thought about that much and is the business of the designers and makers of the equipment, except to part us with our cash because they use some tech-de-jour and essentially saw us coming.
So long as the inputs and outputs are simple and adhere to convention, and the controls are understandable and useful, then that is enough. From this very complicated things can then be built and wonderful things achieved.
I have got to the end of this blog and am still happy that this kind of works as an analogy (for me at least) — would love to hear what you think and if it’s making sense to you. I’m off to read more about OOP and get excited.