by Danny Maland
In the first installment of this blog series, I declared my intention to build a mixing system that utilizes off-the-shelf computer and audio hardware in combination with a proprietary software package. The idea is as much about delving into the unknown for the sake of itself as it is to have a functioning alternative to an aging console.
With my goal of “unorthodox mixing console or bust” firmly planted in my head, I started carefully choosing computer and audio components for the rig. As I did so, I almost completely forgot about what should have been a core tenet regarding the experience: Experiments are iterative processes. That being out of my mind, I became very focused on the notion that this whole thing was going to come together perfectly in one fell swoop. A careful assembly would be followed by a satisfyingly victorious, and essentially flawless, initial test run. The unbridled triumph would be of the kind celebrated with parades – the parades that were photographed in black and white for newsreels.
What's really ironic is that my pursuit of perfection without iteration probably resulted in the precise opposite. As I became focused on little details too early in the process, I ended up shortchanging myself on some bigger usability issues. I even made a mistake that would probably have been spotted immediately by a reasonably well-educated rookie. The main ways I stepped on my own feet were as follows:
A) I put too much focus into having the “brain” reside in a relatively small, three rack-space chassis. Compactness is great and all, but fitting everything into a relatively shallow and not-very-tall case means that the internals have only a bit more than minimal clearance. After it's fully assembled, there are some parts of the brain system that are inaccessible unless you are willing to substantially tear it all apart again.
B) I went a bit overboard in regards to having a lot of airflow to keep the brain cool. A cool-running computer system tends to be more reliable overall, but having all those fans pushing all that air means that the thing is loud when power is applied. This may or may not prove to be a problem later on. (This system is going to be deployed primarily in situations where there's lots of background noise anyway.)
C) I completely forgot to check for a difference in rack depths between the main audio interface and the I/O expansion units. As a result, the rack case chosen for those components became a bad choice. The case had just enough height to accommodate all three units, but the depth differential meant that plugging and unplugging connectors from the shallowest unit would be a major chore. The maneuvering of latching connectors pretty much requires that you have some vertical clearance for your hand and arm, and doubly so if you have to reach into something to get to the unit you're working on.
D) In my haste to get everything together and working in a short time frame, I forgot to order enough optical cables. I just plain overlooked the whole issue of how I was going to get a clocking reference to the expansion units, having been all wrapped up in just getting expansion units at all. (This is the part that any kid fresh out of an audio education program would have caught.)
Having said all that, it may appear that the major issue in play is the effect of these oversights, but as I said before, I think the real problem is that I lost sight of being involved in an iterative process. Having laid aside the idea of progressively refining the system, I became frustrated with how it wasn't all perfect in one go. That frustration, I think, was a waste of emotional energy. What's more, I think it ran contrary to the spirit of what I'm trying to accomplish with this enterprise.
In “Part 1,” I lamented how there can be a loss of the original awe and wonder that got many of us involved in this kind of business in the first place. I mused about the accomplishments of those who can remain well grounded in good sense while still pushing the envelope with different ideas and techniques. I think that a key component of being able to pull off that kind of behavior is the embracing of iterative processes.
The thing is, though, that embracing iterative processes is hard. It's hard because I think quite a few of us have been taught to fear all failure at all times.
Notice how I said that – ALL failure at ALL times. I don't mean to suggest that no fear of failure, regardless of context, is somehow a good idea. A healthy fear of making a mess in the wrong situation is what drives us to, quite appropriately, refrain from signing off on a system for a client that has not been thoroughly tested. An appropriate fear of failure leads us to check our work, implement quality controls, and take care that end users are happy campers.
What I think is actually troublesome is when there's no room for the notion that mistakes and failures teach much more than success. We can get so wrapped up into the “time is money” bottom line (in multiple ways) that we choke off chances at growth, discovery, and even superior final products. “Time not spent on something that we know will work is wasted time. That means wasted money. We must not waste money, therefore we must not waste time, therefore we must not work on something which does not have assured success.”
Do you see how that last sentence, when applied at all times and in all contexts, might lead to stagnation? There's no real room for experimentation in there. There's no room for an iterative process.
In my mind, the soul of embracing an iterative process is having the expectation that a project is going to have some degree of failure in it. In an iterative process, we execute the project/ build/ whatever-it-is carefully, yet with the expectation that the purpose of our action is to get a result that shows us the flaws in our planning and reasoning. Sure, it would be really spiffy to have gotten it all correct the first time, but embracing the process means that we actually get excited about figuring out how the thing breaks. The reason we can get excited about that is because that knowledge can then be applied to making the project more robust, and more perfect, and more refined. If we keep devoting time to an iterative process, the end result will have a ton of knowledge and experience infused into it, and derived from it. Potentially, that end result can be superior to solutions that taught us rather less, or it can even have put us into a position to innovate.
I think that the folks who build and fly X-Series aircraft know that some of them are going to crash. I think they can accept those crashes because they are counting on a long-term net gain of knowledge and technological expertise.
I'm not you, and I can't tell you how to run your business. I can't presume to tell you just how much risk to take on, and how much failure you can absorb in the name of progress or just plain ideology. I can't make any judgments about where and when iterative processes might be best undertaken by you. I do think, though, that it's appropriate to suggest having a look at these things if you haven't before.
