QLab: Beyond the stage
Over on the OSXAudio forums, someone recently asked the interesting question: what can a “theatre app” like QLab do that other audio processing applications like Live can’t?
It’s a great question. And the answer leads to something more: the unique architecture that sets QLab apart from not only the music-oriented applications like Live, but from even the other “theatre” applications.
But before I get to that, what exactly is the difference of a cueing application like QLab from an audio processing application like Live or Logic? The distinction is basically one of work flow.
The paradigm for programs like Live is a musical environment in which the application digests a constant, steady stream of audio. It’s like one big river of sound you melt and shape through the instrument that is your computer. This “application as instrument” paradigm is quite powerful, but not quite the right fit for all scenarios, especially when you’re moving away from music into other art forms that incorporate audio.
Often it is helpful to be able to treat your audio as many discrete events. You need to be able to build a framework of audio events that is very precise but also very flexible. For example, the sound of the thunderstorm may need to fade out at exactly 3.6 seconds after the lights dim, but the sound of the telephone ringing may happen at a radically different time every night depending on how the actors are playing a scene. So you can’t compose the musical score of a play the same way you can compose the score of a song.
Now here’s where things get interesting. This paradigm of discrete events goes way beyond theatre. I’m focusing on this art form at the moment, but I’ve explicitly designed QLab to be more than just an application for the stage. The ability to collect discrete events together in an exact but flexible way can be used in hundreds of different ways. QLab doesn’t know what kind of cues it’s running, it just runs them. I’ve designed the architecture to let both me and other developers create any kind of cue their hearts desire.
Imagine an interactive museum exhibit: The exhibit designer might set up a video input cue that supports motion sensing to start a sequence of events when a patron enters the north corner of the room. When the motion sensing cue activates, entire other series of events occur in the room. On top of it all, using a timer cue the exhibit could be told to activate at 9 in the morning and turn off at 5, and an email cue could be told to email the museum curator the total amount of time the exhibit had been running that day.
It’s this general event-oriented architecture that sets QLab apart. This is what gives QLab such potential. And after the immediate needs of the core application are completed—once the foundation has been laid—it’s the addition of new, dramatically different kinds of cues that are going to add that extra special spice.