By Matthew B. Pohl
Improvisatory performance has long been part of musical interpretation since the days of fugue and counterpoint, with virtuosic musicians such as Mozart and Beethoven serving as the earliest such examples in the Western art tradition. The twelve-bar blues progression and its number of variants serve as a more popular form of music containing improvisational language and techniques. Both of these examples follow the traditional idea of interacting directly with a sound source, using a number of control mechanisms – force, speed, intonation, subtlety – to invoke a desired sound from an instrument.
For example, if a drummer wanted the kick drum to make sound, they would force their foot into the pedal, which results in the kick drum being struck by a mallet with the help of some mechanics to transfer the force of motion. This somewhat complex process can normally take place in less than a quarter of a second. In the case of the ICE Ensemble and its live coding dynamic, the process changes and so do the variables: to produce a kick drum sound, one must effectively and efficiently type the name of the low-level sound location, its selection number, a gain value, and a pan value, in syntax, within an IDE containing TidalCycles. For a proficient coder/typist, this process can take anywhere from ten to thirty seconds, a far cry from the near instantaneous motion of interacting with a kick drum pedal.
The ICE Ensemble explored a very interesting perspective on performance this semester: live coding for video games. There is an exceptional range of spontaneity involved in video games, as the player alone is in control of the flow of the game and, in the case of live music creation for the game, the flow of the performance. The challenge was to explore limits when live coding for games, and what we can do to overcome this.
The first challenge is, with modern technology, exceptionally simple: overcoming the delay from slow typist speeds with copy/paste. To implement complex lines of code quickly, scenes used in performance would have to be developed and practiced beforehand by musicians and gaming performers in tandem. This cuts down on both the delayed response, but since the gamer also has practice beforehand it also cuts down on the spontaneity of live gameplay.
The second challenge becomes how one incorporates live coding into gameplay without removing its spontaneity – or at the very least the sense of spontaneity. This challenge is much more difficult to answer, partially because any observation of an audience’s perception of spontaneity would have resided in the final concert that was cancelled due to extraneous circumstances. However, one should reflect on the core idea that an interpretation of music and its related elements will vary from person to person, and that a non-performer will likely maintain a different perception than a performer concerning what is spontaneous, what is planned, and what is rehearsed.
Leading up to the final concert, one of the practicing gamers commented a number of times that her perception of the in-game music changed while practicing with the ensemble, and that it was more enveloping and interactive to have it created while the game was being played by the individual as opposed to being as a computer-interpreted result of that player’s actions, and that gaming at home after the practices “just isn’t the same”. Perhaps that would be the general consensus among an audience with similar backgrounds to this individual, while taking in such a unique subtype of music creation in an exceptionally unique way. Perhaps in this case, then, spontaneity is not about being unaware of what will happen, but about the anticipation of what could happen. Remember that first time you listened to Beethoven’s 9th Symphony as a critical music listener?