Desafiando capas: complejidad, Bytebeat y posibles horizontes sonoros para el live coding
Challenging layers: complexity, Bytebeat and possible sonic horizons for live coding
Luis Fernando Medina
(Español)
El live coding es quizá la última encarnación de esos viejos sueños sobre máquinas sonoras y un paso más en la rica historia entre la música y los dispositivos de cálculo. Mas su práctica combina no solamente el conocimiento de un dispositivo tecnológico, sino un conjunto de prácticas colectivas que abarcan desde el uso de herramientas libres, hasta procesos de educación abierta y un fuerte sentido de comunidad.
Brevemente, el live coding es un movimiento tecno-social. Y a pesar de que la relación entre algoritmos y música precede a los computadores digitales, basta con pensar en vaticinios como el de Ada Lovelace, que en el siglo XIX ya adivinaba las posibilidades musicales de una máquina de cálculo mecánica [1] o la presencia de procesos algorítmicos, secuencias, bucles, entre otros, en las estrategias de composición de varios músicos de vanguardia [2]; la versatilidad del software y la conversión del computador de máquina de cálculo a máquina de medios universal [3] han traído un gran impacto al ejercicio sonoro. Específicamente, el nivel de flexibilidad y democratización del software ha enriquecido distintas expresiones artísticas y culturales que trabajan con sonido.
De esta paleta de posibilidades, el live coding se distingue por ofrecer aparentemente un modo de acceso más expedito al corazón de la máquina, al saltarse interfaces, filtros y menús y permitir manipular un código de programación que obedece en tiempo real a los cambios introducidos. Pareciera que el live coding hiciera posible hablar directamente con el esquivo fantasma dentro de la máquina.
Sin embargo, la última afirmación requiere un mayor análisis. Si bien el live coding y sus cualidades performativas exigen una respuesta en tiempo real de la máquina y de su ejecutor —lo cual le confiere propiedades de inmediatez—, las herramientas informáticas usadas en el live coding involucran de manera implícita otro nivel de complejidad. En particular, me refiero a dos características de los lenguajes de programación que cuestionan este supuesto acceso directo del programar en vivo y que pueden denominarse: la pila de capas y la caja negra. Ambos conceptos están relacionados y afectan todas nuestras interacciones digitales.
La pila de capas corresponde al paradigma de traducción [4] presente en todos los sistemas informáticos. Es decir, aplicaciones y sistemas operativos reposan en una pila de capas que van desde capas altas más comprensibles para los humanos, que progresivamente son traducidas a capas inferiores, hasta llegar al críptico lenguaje de máquina. Y aunque esta sucesión de traducciones siempre ha existido, la disponibilidad de hardware cada vez más rápido hace que ya no sea más un problema central en el diseño de sistemas informáticos [5], originando de este modo lo que se conoce como «software inflado» (bloated software) [6]. Por otro lado, el concepto de caja negra puede verse como una consecuencia de lo anterior y conlleva una contradicción. Esto es, entre más transparente y legible sea un lenguaje para el usuario final, probablemente hay más capas inferiores ocultando los mecanismos internos del sistema.
Ahora bien, ¿qué implicaciones tiene esto para el live coding? Teniendo en consideración la pila de capas y la respectiva caja negra, la inmediatez de la programación sonora en vivo resulta en parte ficticia y reposa en la agilidad de un hardware más que en la sencillez de una interfaz textual. Esta observación se hace más evidente si se piensa en una instalación usual para live coding que requiere varios programas y bibliotecas instalados como prerrequisito; eso sin contar las capas más inferiores de acceso al hardware de sonido.
Debe aclararse que más que una crítica, la argumentación anterior abre preguntas que pueden conducir a nuevos terrenos estéticos y de praxis tecnológicas. Por ejemplo, ¿hay maneras de evitar esta pila de capas?, ¿qué nuevos sonidos y formas de live coding podrían salir de ello? Una primera pista a una posible respuesta viene de la misma historia de los lenguajes de programación. Hasta los años setenta, estos eran propuestos principalmente por universidades siguiendo un juicioso diseño de capas y transformaciones matemáticas.
Sin embargo, la aparición del ahora popular lenguaje C constituyó una excepción, pues este fue concebido en un laboratorio empresarial (los famosos Bell Labs, donde también se inventó el sistema UNIX, al que estaba asociado el lenguaje C) y su forma de creación —más artesanal y poco formal— desafiaba el rigor académico. Quizá de allí su popularidad, ya que el lenguaje C, de nivel intermedio, permitía hacer operaciones de bajo nivel antes exclusivas para el lenguaje ensamblador. Esto plantea entonces una posible solución a la pregunta antes mencionada ¿habría una práctica de live coding basada solamente en el lenguaje C y cómo sonaría?
Esto me llevó al descubrimiento de una práctica llamada Bytebeat y a los programas de una sola línea (one liners). Por un lado, el Bytebeat es una práctica que se dio a conocer en el blog del investigador y artista Ville-Matias Heikkilä en el 2011, que consiste en producir programas (generalmente en C) de una sola línea con operaciones aritméticas en un ciclo infinito y que generan datos en bruto dirigidos directamente a la tarjeta de sonido [7]. Por otro lado, dicha práctica retoma la tradición minimalista de los programas mediáticos (con ejemplos de video también) cuya historia se remonta incluso a los años sesenta [8].
Un ejemplo puede verse en el siguiente video:
El programa del video corresponde al siguente código en C:
Este, una vez compilado, debe ser enviado directamente a la tarjeta de sonido, lo cual para un sistema basado en UNIX como linux sería:
El archivo a.out es el resultado de la compilación con gcc del código mostrado. Este es redirigido al programa aplay desde la línea de comandos.
Aunque el Bytebeat no es tan reciente, cabe preguntarse por su relación con el live coding, en tanto familiar de los sonidos elaborados mediante algoritmos y programación. En primer lugar y a diferencia de los lenguajes usados en live coding que son interpretados, el lenguaje C es compilado.
Esto puede parecer una pequeñez técnica, pero tiene que ver con la interactividad y performatividad que se espera del live coding. Pues aunque los programas one liners en lenguaje C son cortos y por ello podría pensarse en estrategias que se acercan a los postulados del live coding (por ejemplo, tener múltiples terminales con programas cortos ejecutándose simultáneamente como si fueran distintos canales, siendo constantemente reprogramados y compilados para mayor interactividad), un problema persiste, y es la notoria complejidad de la ecuación dada y el poco grado de maniobra que da el que esté en un ciclo infinito. A pesar de estos obstáculos, modelos similares ya han sido explorados por comunidades TopLap, como el experimento de programas de una sola línea de supercollider publicados en Twitter por Dan Stowell, en 2009 [9], y que incluso fueron compiladas en un álbum de piezas sonoras enviadas desde distintas partes del mundo: https://archive.org/details/sc140
Finalmente y de forma vindicatoria, cabe señalar que a pesar del carácter oscuro de los programas de una sola línea y del conocimiento matemático que aparentemente reflejan, estos no cierran la oportunidad para una experimentación basada en el ensayo y el error (como se señala en [10]), más cercana al ethos del live coding: lanzar líneas de código en tiempo real e ir moldeando el sonido con la materialidad del texto polivalente que es interpretado tanto por los humanos que ven la proyección como por los circuitos de la máquina.
Este es el propósito de este breve texto que pretende —de manera sucinta— vincular una preocupación propia de los estudios de código y de software (y basada en la arquitectura de los lenguajes de programación) con especulaciones estéticas referentes al live coding: encontrar alternativas que complementen los modelos imperantes y que nos lleven a nuevas formas de ritos colectivos en la comunión del sonido y del código, donde ambos muten y sean compilados, transmitidos y esculpidos en formas diferentes. Una nueva práctica donde el paradigma hegemónico de la pila y las constantes traducciones entre lenguajes sea desafiado en parte por un minimalismo —¿acaso más puro?— más cercano a las entrañas de las máquinas de cálculo sonoro.
[1] Nota A en “Sketch of the Analytical Engine invented by Charles Babbage” (1842) por L.F. Menebrea. Traducción y notas por Ada Augusta, condesa de Lovelace. Disponible en:
http://www.fourmilab.ch/babbage/sketch.html
[2] Steve Goodman. “Sonic Algorithm”. En Software Studies. A Lexicon. MIT Press, 2008.
[3] Peter Lunfeld. The Secret War Between Downloading and Uploading. MIT Press, 2011.
[4] Software Theory. A Cultural and Philosophical Study. Rowman & Littlefield Int. 2015.
[5] Edgar G. Daylight. The Dawn of Software Engineering. From Turing to Dijkstra. Lonely Scholar 2012. (p. 71)
[6] Ibid (p. 155)
[7] Ville-Matias Heikkil. “Discovering novel computer music techniques by exploring the space of short computer programs”, 2011.
[8] Nick Montfort, Patsy Baudoin, John Bell et. al. 10 PRINT CHR$(205.5+RND(1)); : GOTO 10. MIT Press, 2012.
[9] http://ia800202.us.archive.org/29/items/sc140/
sc140_sourcecode.txt
[10] Paul Prudence. “Simplexity, the art of the one-liner for sonic complexity”.Neural Magazine 52: Complexity Issue(s). 2015. (p. 19-21)
(English)
Live coding is perhaps the last incarnation of old dreams about sound machines as well as another step in the rich history between music and calculation devices. Nonetheless, this practice combines not only the knowledge of the workings of a technological device but a set of collective practices that range from the use of free tools to open education processes and a strong sense of community.
In short, live coding is a techno-social movement. And although the relationship between algorithms and music precedes digital computers—it suffices to think of predictions such as Ada Lovelace’s, who in the 19th century had already guessed the musical possibilities of a mechanical calculation machine [1], or of the presence of algorithmic processes, sequences, loops, among others in the composition strategies of several avant-garde musicians [2]—, the versatility of software and the transition of the computer from a calculation machine to a universal media machine [3] have brought a great impact to sound-related practices.
Specifically, the level of flexibility and democratization of software has enriched different artistic and cultural expressions that work with sound. From this palette of possibilities, live coding is well known for—supposedly—offering more expedited access to the heart of the machine, by skipping interfaces, filters, and menus and by allowing to manipulate a code that obeys—in real-time—the changes introduced by the programmer. It seems then that live coding has made possible to speak with the elusive ghost inside the machine in a more direct way.
However, the last statement requires further analysis. Although live coding and its performative qualities demand a real-time response from the machine and its programmer—all which give live coding immediacy properties—, the computer tools used in live coding implicitly involve another level of complexity. With this, I am referring to two qualities of programming languages that question the direct access to live programming: the stack structure and the black-box model. Both, qualities that are interconnected and that affect our digital interactions.
The stack structure refers to the translation paradigm [4] present in all computer systems. That is, applications and operating systems rest on a stack of layers ranging from higher layers more understandable to humans, which are progressively translated into lower layers to reach the cryptic machine language. Although this succession of translations has long existed, the current availability of faster hardware makes it no longer a central problem in the design of computer systems [5], thus originating what is known as “bloated software” [6]. The concept of the black box can be seen as a consequence of the latter, entailing the contradiction that the more transparent and readable a language is for the end-user, the more lower layers hiding the internal mechanisms of the system probably exist.
What implications do these two qualities have for live coding practice? Considering the stack of layers and its respective black box, the immediacy of live sound programming is partly fictitious and relies on the agility of hardware rather than the simplicity of a textual interface. This observation becomes more evident if you think of a ‘common’ live-coding software installation, which usually requires pre-installing several programs and libraries. All this without even considering the software requirements of the lower layers that access the sound hardware.
It should be clarified that more than a criticism, the previous argument opens questions that can lead to new aesthetic and technological praxis. For example, are there ways to avoid this stack of layers? What new sounds and forms of live coding could come out of this avoidance? A first guess comes from the history of programming languages itself. Until the seventies, programming languages were conceptualized mainly by universities following a judicious design of layers and mathematical transformations.
However, the emergence of—the now popular—C language was an exception, as it was conceived in a business laboratory (the famous Bell Labs, where the UNIX system was also conceived and to which the C language was associated with), defying the academic rigor through its more artisanal crafting. Perhaps the latter is where its popularity comes from, since C, in its intermediate level, allowed to make low-level operations previously exclusive to assembly language.
The latter poses a possible solution to the questions: can there be a live coding practice based solely on C? If so, how would it sound? These questions led me to the discovery of a practice called Bytebeat and to the one-line programs (also called one-liners). Bytebeat is a practice that was announced in the blog of the researcher and artist Ville-Matias Heikkilä in 2011, which consists of producing programs (usually in C) of a single line with arithmetic operations in an infinite cycle and that generate raw data sent directly to the sound card [7]. This practice takes up the minimalist tradition of media programs (with video examples too) whose history dates back to the sixties [8].
An example can be seen in the following video:
The video program corresponds to the following C code:
This code, once it’s been compiled, must be sent directly to the sound card, which for a UNIX-based system such as Linux would be:
The a.out file is the result of the compilation with gcc of the C code. This file then is redirected to the aplay program from the command line.
Although Bytebeat is not so recent, it is worth asking about its relationship with live coding, as a practice familiar with the sounds made through algorithms and programming. Unlike the languages used in live coding that are interpreted, C language is compiled.
This may seem like a technical detail but it actually influences the interactivity and performativity expected from live coding. Although one-liner programs in C are short—and that is why we could think of strategies that approach the postulates of live coding (for example, having multiple terminals with short programs running simultaneously as if they were different channels, being constantly reprogrammed and compiled for greater interactivity)—a problem that persists is the notorious complexity of the given equation and the little degree of maneuver that the infinite cycle—in which this equation lives—gives. Despite these problems, similar models have already been explored by Toplap communities, such as the experiment of single-line supercollider programs posted on Twitter by Dan Stowell in 2009 [9], and which were even compiled into an album with sound compositions sent from different parts of the world (see https://archive.org/details/sc140)
Finally, it should be noted that despite the obscure nature of single-line programs and the mathematical knowledge they apparently reflect, they do not close the opportunity for experimentation based on trial and error (as noted in [ 10]), something closer to the ethos of live coding: throwing lines of code in real-time and shaping the sound with the materiality of the versatile text that is interpreted by both the humans who see the projection and the circuits of the machine.
This is the purpose of this brief blog entry that aims to link my concern about code and software studies (grounded on the architecture of programming languages) with aesthetic speculations concerning live coding. All these to find alternatives that complement the prevailing models and that lead us to new forms of collective rites in the communion of sound and code, where both mutate and are compiled, transmitted and sculpted in different ways. A new practice where the hegemonic paradigm of the stack and the constant translations between languages is challenged in part by a minimalism—or more depurated process?—closer to the bowels of the sound calculation machines.
[1] Note A in “Sketch of the Analytical Engine invented by Charles Babbage” (1842) by L.F. Menebrea. Traslation and notes by Ada Augusta, countess of Lovelace. Available at:
http://www.fourmilab.ch/babbage/sketch.html
[2] Steve Goodman. “Sonic Algorithm”. In Software Studies. A Lexicon. MIT Press, 2008.
[3] Peter Lunfeld. The Secret War Between Downloading and Uploading. MIT Press, 2011.
[4] Software Theory. A Cultural and Philosophical Study. Rowman & Littlefield Int. 2015.
[5] Edgar G. Daylight. The Dawn of Software Engineering. From Turing to Dijkstra. Lonely Scholar 2012. (p. 71)
[6] Ibid (p. 155)
[7] Ville-Matias Heikkil. “Discovering novel computer music techniques by exploring the space of short computer programs”, 2011.
[8] Nick Montfort, Patsy Baudoin, John Bell et. al. 10 PRINT CHR$(205.5+RND(1)); : GOTO 10. MIT Press, 2012.
[9] http://ia800202.us.archive.org/29/items/sc140/
sc140_sourcecode.txt
[10] Paul Prudence. “Simplexity, the art of the one-liner for sonic complexity”.Neural Magazine 52: Complexity Issue(s). 2015. (p. 19-21)
Acerca del autor
Luis Fernando Medina Cardona (aka luscus). Profesor asociado, Facultad de Artes de la Universidad Nacional de Colombia (Bogotá-Colombia)
lfmedinac@unal.edu.co
@luscus9
About the author
Luis Fernando Medina Cardona (aka.luscus) is Associate Professor, Faculty of Arts of the National University of Colombia (Bogotá-Colombia)
lfmedinac@unal.edu.co
@ luscus9
