by Danny Maland
I recently wrote a series of blog articles that dealt with select portions of building a virtual mixing console. (“Flying X-Series Aircraft” Parts 1-3, which you can read here, here and here.) That series got into some of what happened, and tried to also take an expanded view on some root issues surrounding the process. (If you're new to this whole thing and need some background, my definition of a virtual console is this: An audio mixing system that has its core functions residing in software that runs on general-purpose computing hardware.) What I didn't get into was whether the end result is something you might want to try.
After several weeks and various different shows with my own virtual console, I have an answer for you that I'm willing to stand behind unequivocally: “It Depends.” (Yes, this is the answer that I have been giving to most questions lately.)
Okay – fine. What does the proverbial “it” depend on?
First: Does such an unorthodox system fill a need beyond “it costs less than this other watchamahoozits?”
I simply don't believe that a cost savings is enough to justify venturing into virtual console territory. Yes, cost savings was a part of what motivated me to give a virtual console a try, but it was only one piece of the puzzle. I had a specific input and output channel count that I needed. That was also coupled with a need (and desire) for uncommon flexibility and powerful control, to include things like virtual monitor consoles and my favorite “as many bands of parametric EQ as you want” plugin. Those needs and wants pushed me squarely into a digital console bracket that was out of my reach, and so a virtual solution became a good option. The affordability of the system was key to the decision, but it was a consequence of other factors and not an end in itself.
In other words, if a virtual console fills a client need that little or nothing else in their budget-range can handle, then I would consider one. If they can afford a proprietary solution to those needs, though, I don't think the savings are enough of a justifying factor to tip the scales.
Second: Can your client REALLY tolerate how unorthodox a virtual console is?
This may take some digging to find out, but you need to be intimately familiar with just how (and by whom) the console is going to be used. If the stakeholder who is about to sign-off on the idea of a virtual console doesn't understand what the requirements they've presented to you actually mean, you may be headed for trouble. What you should do is find the stakeholder who actually wrote up the requirements list, and get inside their head. Are they okay with an interface being (potentially) driven only by way of a keyboard and mouse? If not, are they okay with off-the-shelf fader control packs, and switching through banks of faders? Did they write those requirements expecting that the list would require someone further up the chain to sign-off on an analog console? Are they okay with the idea that control will be very, very visual in nature? Do they need a proprietary console from a certain manufacturer to fulfill rider requirements from users of their facility? Can they train their operators to be effective with a virtual console? Will outside operators need to use a console that they can get used to in a matter of minutes?
The answers to these questions may break a virtual console deal, and so you have to be thorough and careful. Selling a virtual console to a client is a reasonable idea when the stakeholders responsible for using the thing are as gung-ho as, or the same people as, the stakeholders writing the check. If there's a disconnect, though – watch out!
Third: Do you have enough in-house experience and training for the buck to stop with you? Are you willing to have the buck stop with you?
A virtual console is a marriage of IT and AV in an enormous way. A brief statement of the implications is this: If you don't have folks around with an intimate, hands-on understanding of digital audio, audio mixing, and the guts of computers, you are OUT OF YOUR MIND if you attempt a virtual console for a client.
The thing is, without strong experience in all those areas, you may still be able to get a virtual console to “fly.” However, where you'll get into real trouble is when the thing breaks outright, or does something unexpected. One of the great things about a virtual console is that the whole assemblage is non-proprietary. You can get inside the box and fix it using your own knowledge, and (usually) parts that are pretty easy to lay your mitts on. One of the worst things about a virtual console is that the whole assemblage is non-proprietary. There is no manufacturer to appeal to for warranty service in the case of the console as a whole system. You are the manufacturer – you are going to have to be responsible for the whole thing, from top to bottom. If you're capable of taking on this kind of responsibility, then you're clear for launch. If you are unable or unwilling to shoulder the whole endeavor, though, then it's probably not right for you.
With all of this being said, please understand that I don't want to frighten you. I believe that virtual consoles, even having been hands-on with one for only a short time, are quite doable. I don't believe that they are THE future, but I think they are a real part of the future. They're currently pretty risky, but risk does have rewards. If you have the expertise and understanding, you could probably run a pretty good business as a full-service console manufacturer. You could have your logo on highly stylish, custom built boxes housing the brains of mix rigs capable of pulling off serious audio ninjutsu. You could do the whole thing in a big way – building, installing, maintenance, training, partnerships with the software developer, and all that nifty stuff.
It's all possible if you understand the risks, and have the right people.
