In 1990 we created QSystem, the first 3D audio system for professional audio recording applications. The system was used by Sting, Madonna, Roger Waters, Pink Floyd, and many other artists in the recording studio. Unlike surround sound systems today, this system created audio for playback on 2 speakers. The sound was positioned using filters that tricked the mind into perceiving the sound came from beyond the stereo speakers. The version 1.0 and 1.1 of the system had 8 channels of position processing, and the locations were fixed in a 180 degree arc. In QSystem version 2, pictured above, we wanted to add the ability to control the position of any channel with a joystick, and to record joystick motion so that positioning would be played back with the recording. This meant a completely new user interface, a custom joystick, many new system software features (C++ on DOS) for handling the joystick, recording, and interfacing with the studio automation system, and changing the core audio digital signal processing architecture code that ran on the Digital Signal Processors (DSPs). We also designed a new DSP processor board at the same time. All this with less than 10 people.
The User Interface challenges were significant. We had a system whose primary purpose was audio output. We had to provide a real time graphics display for positional information of each channel, but this was DOS on a 386 and CPU was needed for audio processing control. The processing that did the audio positioning was non-linear and constrained the movement paths within the semicircle shaped sound field. We also had a lot of uncertainty since there was no product like this on the market. When faced with a problem like this we had the benefit of beginner’s mind. We had no idea what was going to work, so we started trying things and kept it simple. I worked on the DSP algorithm, looking for a way to smoothly control audio with a joystick. An industrial designer worked on the joystick case. Our best programmer tackled the joystick recording, playback, and synchronization features.
Some stakeholders drew complicated 3D pictures of how the UI should look, including the founder. Many discussions ensued where we had to explain that we could not commit to such a design until we knew more. As we built up the features, we created a simple 2D map of the speakers and semi circle sound field. The position of the joystick was a dot on this map. As we played with the UI we found that the sound position was not reflected correctly in the UI, so we changed the parameters controlled by the joystick to improve the auditory realism. Once this was working the recording and playback features were added to the system, again the UI was simple, driven mostly by the buttons on the joystick.
While we were working on the system others searched for alternative displays to a bulky PC CRT monitor. The CRT was heavy, not very rugged, and as we discovered with QSystem v1 they caused shipping problems. Late in development the team found an industrial display that met all our system needs, however it was a monochrome LCD. We tried it out and it worked great. Because we had not invested time in a complicated interface we were able to make this robust but simple display work easily.
During testing in the studio the founder and others who had initially wanted the complicated interface got a chance to use the system for hours. In use they found the interface’s simple design was more than enough. They liked the way it focused the attention on the audio instead of the screen. With most of the functions controlled by the joystick, the sound engineer could forget the display and focus on the sound. In later revisions we made some improvements based on feedback. The complicated 3D interface came up a few times and we thought how misguided an idea it seemed knowing what we now knew.
We were successful in solving a complicated UI problem in an elegant way by moving the technology and UI forward together. The technology imposed constraints on the UI, changing our initial design ideas. The joystick made us rethink how to control the system to make it easier to use. The late arrival of a major UI change, the monochrome LCD, did not cause major changes to the UI since we had kept things simple. A complicated graphics intensive UI was strongly advocated in the early phases of the project however it turns out that it would have been a disadvantage in effort/cost to implement, cost of CPU resources, and would not have worked on the monochrome LCD. Locking in complicated UI design upfront would have significantly increased the risk of failure and delays in this project. By focusing on simple solutions as the underlying system was developed, we arrived at a solution that was simple to use, task focused, and flexible.