Programmers are weird animals. Manipulating three (and more) dimensional objects, composed of cryptic software code, in one’s head requires a certain amount of weirdness. 
So it follows that the design of software, even software for theater audio will often be a little weird too. But it shouldn’t be. Not if the software developer knows the subject of theater and live audio and appreciates the rules required for creating usable software.
This article is designed to give you a snapshot into the mind of the primary software developer – or programmer – of MixAction. It strives to be frank if not at times brutally honest and is different to most articles you’ve possibly read before from programmers or their “marketing departments”. In short it discusses a few of the things developers and in particular developers of theater sound software would prefer you not to know. It does not name names as that would be unethical and unprofessional.
There are programmers and “Programmers” just like there are audio engineers and “Audio Engineers”. Not all are created equal, not all are professionals, or act professionally and not all know their subject matter. Like the Audio Engineer some are hobbyists who play at it while others do it for a living or at the very least study it to fully understand it, in order to rise above mediocre. Hobbyists tend to invest little money or time in improving their tools or knowledge where as, again like a pro Audio Engineer, the professionals spend copious amounts of money and time in all areas pertaining to their field. If they don’t have something they buy or build it, if they don’t know something they seek to find out. Where as the amateur who has a different mindset will invariably choose to ignore it or create excuses and it shows, exactly like it shows with audio engineering too.
It is fair to say most free or budget (under $50) software is written by the amateur, though there are significant well known exceptions to this. Having made that generalization not all software $50 and above is professional either, hopeful perhaps, but not necessarily pro. There is no such thing as bug free software, just as there is no such thing as perfect audio. It is imperative, if not humbling for us all to keep this in mind.
It’s also fair to say that generally a sloppy user interface, lack of care over simple things like icons on toolbars or user interface “widgets” (buttons, sliders etc) are also hallmarks of an amateur. If it looks “odd” it invariably is odd in the programming code too. Novice programmers break user interface design rules often because they don’t know companies, like Microsoft or Apple, publish them. They don’t know why they publish them and thus fail to appreciate the importance of a consistent, predictable user interface experience for their customers. A classic user interface design error is the program that is all black in colour, or in 2009, is all gray. Icons that look dull or cheap and so on. A pro knows it, an amateur does not.
When I started software programming in the 1970′s, as a teen hobby, before it became my career in the 1980′s, programs were text based and often “on the command line.” By the end of the 1980’s people expected interfaces to operate software. By the mid 1990’s a Graphical User Interface (like Windows or the Mac) was essential. It takes many years of study by working software developers to understand fully the implications of this. But at the end of the day the golden rule is “if it ain’t broke don’t try and improve on it.”
In the realm of computer audio and in our case here, specifically, theater audio sound software - replication of a life like sound surface is not necessarily a good metaphor. Cramming large objects into small spaces breaks the metaphor’s purpose. The purpose of computer software is not just to re-represent what we already have and know but to expand and empower what we are doing. This is why MixAction differs so markedly from other theater audio software products. It’s entire emphasis is on theater.
There should indeed be easily identifiable objects, like faders, to manipulate. It makes sense to put the person using the software at ease with some familiar paradigms. But slavishly copying an interface from “real world” live or recording mixing consoles, or worse, Mickey Mouse style DJ mixers, misses the mark when it comes to improving productivity. The screen is to small, knobs can be hard if not impossible to manipulate. They have a place, but the programmer must know their place when designing interfaces that use them.
The same goes for representations of waveforms. In an editing situation editing sound via a waveform makes good sense, but it makes very little sense during playback of a sound cue during a production. This is because the information it represents is not used during playback except, perhaps, to make the interface appear more complex than it needs to be – which has the unwanted side effect of increasing complexity at the expense of ease of use and clarity.
As you’ll learn, reading this blog in the future, MixAction is designed to operate like a theater play or production. It divides things up into Acts and Scenes for good reason – that reason being that your workflow as a theater audio engineer is broken up into Acts and Scenes too. It seeks to provide familiarity, logic, convenience and clarity through organization. Anything less and it wouldn’t be theater sound software, in fact all you’d have at the end of the day is a glorified Windows Media Player or iTunes with some special effects thrown in.
Of course it does do more than that, much more. Indeed the premise in designing MixAction was to make the process not just fun but more importantly a tool to support, enhance and generate your creativity. I believe software developers should approach software at this level.
What do you think?
MixAction’s acts and scenes layout, it’s clean separation between the sound editing tools and performance tools is the result of not only experiences in professional software development but in experiences in audio too, both live and in the studio.
What we have done in the development of the MixAction user interface is wherever possible blend the clean simplicity of so called Web 2.0 and the consistency of the Microsoft Office style productivity applications.
As I said at the beginning of this article – programmers minds are weird places.
In software development we have a concept of “widgets”. Controls we either drop onto our editors, create from scratch in code “on the fly” or visually design ourselves. Widgets can be expensive to purchase or if created ourselves very time consuming – which at the end of the day is also “expensive”. For free software or dirt cheap budget and amateur software it’s OK to kludge it because nobody really takes such efforts seriously. But when charging serious money for serious software solutions the developer should be seriously investing in the right tools and widgets.
An example of this is the Microsoft fluid interface or “Ribbon” as seen in Microsoft Office 2007, across most of the soon to be released Windows 7 user interface and in MixAction. The Ribbon is patented by Microsoft and whether one agrees with patents or not to use it legally the programmer must sign a license with Microsoft and agree to follow each of their requirements when implementing it (and possibly some optional ones they’ve set out as well if applicable to the software). Yet one theater audio package on the market clearly has never signed or followed the requirements, yet charges serious money for the product – therefore expecting you to follow their license agreement when they don’t follow those of others – such as Microsoft. How does one tell this is the case? Because the Ribbon widget in question breaks the most basic rules in functionality, colour, look and feel and so on. We counted no less than 67 of these violations of trademark license in that theater sound cue software package alone – before giving up in disbelief.
I’ve not even touched on the fact, here, that most do not license their audio engines in cases where they do no develop their own.
There is something gravely wrong, amateur and arrogant about that in my opinion. As programmers we must respect our customers – and each other. It’s OK to be a little weird, it comes with the job, but in terms of sticking to the law – not so much.
I don’t expect to write too many articles of this type here on this blog, from time to time I might publish the odd article like this one, but by and large topics will be restricted to theater, sound and of course MixAction.
Thanks for reading!
Scott Kane
CEO and Primary Developer MixAction Theater Sound Software
Trackbacks/Pingbacks
[...] You can read that article by Clicking Here. [...]