by Danny Maland
Not too long ago, my dad, sister, and I were making our way out to California. We had tried to stop for fuel in St. George, Utah, only to be thwarted by our vehicle having a stuck filler door. While trying to find a route to the dealership where we could get the door fixed, we ended up in a commercial development that had no connecting road to the rest of town. We would have to get back on the highway, and to get back onto the highway we would be routed through my dad's least favorite traffic control system:
A roundabout.
As we approached the roundabout, we were faced with a confusing tangle of guidance arrows and other traffic symbols, pointing every which way, all being festooned on road signs and painted onto the asphalt. Faced with all the unfamiliar and not-digestible-in-a-hurry information, my dad's patience found its limits.
“There are SQUIGGLY LINES all over THE [words not appropriate for this publication] ROAD!”
As I'm sure most of you are keenly aware, it can be hard to embrace a new work-flow, especially if you're both comfortable with and heavily invested into a proven set of methods. (For my dad, the proven method is most definitely that of having stoplights.) I'm pretty sure that we all develop our own way of going about something, and even when faced with an updated and potentially superior methodology, we can get a little resistant to changing our “magic formula.” Sometimes this is legitimate, but it holds us back in other situations.
I encountered this myself just recently. As the other articles in this series have described, I've been in the process of implementing an unorthodox audio mixing system. This mixing system, in keeping with my metaphor of experimental aircraft, operates in ways that are both familiar and non-familiar. Most experimental jets essentially behave like other airplanes to a point, but they do tend to “bite” when a pilot gets out of the work-flow required for that particular flying machine. Similarly, a “virtual” console's control scheme and work-flow is very similar to that of any other live-sound console. However, there are some pretty marked differences in the way that one has to organize a work-flow to achieve maximum efficiency, and resisting those practices made my first couple of events a bit more difficult than they might otherwise have been.
Having tweaked my system build into a usable configuration, and having given it a few bench tests to see if it would hold up at all, I felt that a proper shakedown in a live situation was in order. The best risk-to-reward ratio (I felt) would be achieved by integrating it into the semi-permanent install that I'm involved with at a local live-music venue. The events for that weekend seemed tailor-made for a thorough test of the new mix rig's capabilities: A pair of acts that I had worked with before, playing on a stage in a room that I know well, with lots of time to set up and check things over, and with a backup console close at hand if things really went south.
While the second night conformed to my expectations, the first night did not. I had misunderstood the extent to which the venue picking up a benefit concert was going to change the night – amongst other things. What I was ultimately faced with on the first night was changing over multiple acts, adjusting and re-adjusting monitor mixes on the fly far more than I had been preparing for, and a main act which was much more electrified than it had been the last time they had played.
My “serious shakedown” had turned into a baptism by fire, but the intensity of the experience helped to expose how my resistance of the recommended system work-flow was a liability.
The intended work-flow for the system is to use a series of sub-consoles for monitor duty, one sub-console for each monitor mix. I resisted this, and opted to use a single sub-console for all monitor mixes. Even though I'm firmly a part of the digital console crowd, I am also pretty strongly entrenched in the idea that “You don't need to have all that for every mix. Just set up one monitor console and use the auxiliaries!” Now, this works just fine from a technical perspective. The signals go where they need to go with no routing trouble at all. The problem is that making changes to monitor mixes is rather clumsy and slow with this way of doing things. I like having the full display of the selected channel's controls in front of me when using the auxiliaries, but a lot of control immediacy is lost in that situation. Long story short, if I had used the recommended work-flow I could have made monitor mix changes using just the number and arrow keys. The way I was trying to do it required, navigation all across the keyboard, along with constantly having to visually locate controls and mouse over to them.
I didn't fully realize the error of my ways until after the second night, but the idea that I really should adopt the software developer's intended usage did finally come through. I'm looking forward to the opportunity to try the recommended control method in a few days. My gut feeling is that everything will be just that much smoother with me not having to hunt for as many different controls all the time.
I think that my wider point for this article also ties into an expanded view of what I'm getting at through this series of blogs. In the specific case of work-flow, I think we (appropriately) use an established method because it's become very effective for us. It's brought us measurable success in the form of money, clients, pats on the back, and feeling good about what we've accomplished. This can become a trap, though, if we venture into unorthodox territory without being ready to try the new work-flow suggestions first. This recent experience has taught me that a recommended methodology, even when it seems a little excessive, just might be grounded in a solid knowledge of what it takes to really make effective use of a “boundary-pushing” system. We have to overcome our certainty that we already know how to use every tool handed to us, and give that seemingly wacky suggestion a try. It just might not be as wacky as we think – and if it is, well, we actually have proof that it IS crazy.
The expanded view of the series, I think, is that if we want to participate in innovation we have to be on guard against our own stodginess. I don't think that “experimental aircraft” are the right thing for everyone to operate. There are some business models and client situations that outright prohibit venturing into territory marked “Here There Be Dragons.” I'm not saying that prudence equates to dullness. However, I can't shake the idea that getting beyond what we see every day requires that somebody try some things that are at least a bit dangerous. Not everybody can or should be Chuck Yeager, but I think that higher dosages of that sort of spirit could really do a lot of good for a number of folks. I just can't help but feel an indignant twinge when I hear somebody writing off a new idea before it's even had a chance to be thoroughly debugged in real-life situations.
