Del siglo de oro de Pericles a la síntesis digital de bajos recursos

Heidegger, agregando dramatismo filológico con mucha creatividad a lo que había ya dicho Nietzsche, sostenía que en la Antigua Grecia del siglo IV a.C., la techne había alcanzado un grado de desarrollo inusitado en relación a lo que todavía hoy, disimuladamente, secularmente, podría admitirse como lo bello (esta coincidencia en el valor ontológico del hacer lo animó a pseudosemidesnazificarse al proponer insólitamente un diálogo con el marxismo en su “Carta sobre el humanismo” de 1947). Nietzsche creía que la ciencia y la filosofía eran expresiones decadentes de una sociedad cuyo máximo prodigio fueron las artes, y más concretamente la tragedia. Por eso un poco precipitadamente hablamos de rupturas o vanguardias, ya que por entonces se llegó a vivir un ritmo tan acelerado de innovaciones y escándalos estéticos que explican la posición conservadora de Platón para la proyección de una transformación social (algo que era cosustancial a la disciplina espartana pero que el cristianismo tuvo que imponer con terror, de forma cada vez más alarmantemente comparable a las moralinas contemporáneas). La experimentación y discusión sobre los límites y el sentido de lo sonoro, felizmente, tiene lugar entre nosotros pero es – como diría Borges, según lo propio de la eternidad – una adivinanza lo mismo que una predicción.

La escuela pitagórica se imponía con su metafísica matemática y por eso no era sorprendente (y tampoco sorprende hoy) que muchos proclamados teóricos musicales no hablaran más que de fórmulas y geometrías, como si cualquier experiencia de la vida sensible fuera una posible excusa para realzar su ontología de magnitudes cuantitativas. Contra esta concepción escribió Aristóxeno de Tarento (354-300 a.C.) uno de los tratados más influyentes y a la vez ignorados de la conceptualización del lenguaje musical. Aristóxeno sostenía que la música era, ante todo, un fenómeno estético, sensorial, y que como fenómeno físico podía estudiarse matemáticamente pero su cualidad estaba principalmente determinada en la subjetividad que agrupaba las excitaciones del cuerpo en una unidad de sentido, en un discurso, en un acontecimiento temporal, sensual, que los pitagóricos transustanciaban al abstraer la experiencia concreta de la escucha.

Dicho esto tengo que advertir que, por cuestiones de interés práctico más que filosóficas, voy a referirme, irónicamente, a cuestiones pitagóricas más que estéticas de cómo encuentro satisfacción en el desarrollo de un lenguaje de improvisación porque consiste básicamente en la complejización de una función matemática. La poiesis inspirada y regulada de la evolución de esta función pertenece al campo de la escucha en un sentido profundo y, por lo tanto, exige un tratamiento filosófico que, por el momento, voy a suspender.

Hace casi veinte años que programo en Pure Data y muchos más de veinte desde que me enamoré de las computadoras en un vínculo lúdico y estético (lejos de las bases de datos que eran lo único monetizable por entonces). Antes de saber que ya existía un nombre para describir esta práctica específica, comencé con mi hermano a programar en vivo, mostrando el código de manera espontánea, como quien lanza una botella con un mensaje desde una isla desierta o viste una remera de su banda favorita esperando encontrar cómplices de su placer perdidos en el barroco y corroído paisaje urbano falto de experiencias, como diría Agamben.

Pure Data es un lenguaje modular de procesamiento de señales digitales en tiempo real, esto lo vuelve instintivo e inagotable en términos de síntesis pero también se me hacía extremadamente incómodo y engorroso improvisar. Conforme dirigía mi práctica más y más a la improvisación de código, buscaba la combinación más pequeña y sencilla de módulos-objetos que a la vez no fuera en detrimento de las posibilidades de procesamiento. Reducía cada vez más las conexiones y los esquemas hasta que una vez me puse una especie de consigna imposible: tengo que lograr hacer todo con un solo oscilador. Un día, hará dos o tres años – creo que fue saliendo de un CASo Abierto –, Hernán Kerlleñevich me sugirió que busque información sobre “bytebeat”.

Bytebeat es el nombre de una técnica de síntesis digital de bajos recursos, cuyo precursor describió sin más como “descubrimiento”. Aunque se activan algunas alarmas conceptuales al referirse a una fórmula como descubrimiento, cada vez me parece más simpática esta inocente caracterización. Porque los recursos para esta técnica están disponibles desde hace muchísimo tiempo (de hecho, la principal inspiración parece que fue una demo de Commodore VIC-20) y, sin embargo, no fue hasta que tuvimos procesadores tan exagerados, en relación a lo que es más que suficiente para hacer bytebeat, que finalmente alguien lo investigó y desarrolló más detalladamente.

Me gusta entender al bytebeat con ese destello estético que aparece en el ámbito de la ciencia: la elegancia. Se considera elegante a una fórmula que de la manera más simple y económica satisface los resultados más extensos y complejos. La técnica bytebeat consiste en escribir una función lógico-matemática, por lo general de escasos caracteres, con operaciones de bajo nivel, que tome como única variable el tiempo y mandar el resultado de esta operación “en crudo” al conversor analógico digital, la salida de audio. Para dar una idea, el código o “partitura” de una obra generativa de varios compases de extensión clásica del bytebeat es literalmente:

((t >> 10) & 42) * t

La variable “t” es tiempo, concretamente se trata de un contador regular, un número que incrementa rápidamente en intervalos de unidad equidistantes en el tiempo, una rampa o cronómetro. En una analogía válida podríamos decir que “t” es un LFO diente de sierra de mucha amplitud y nuestra fórmula es un wave-shapper de esa señal. En realidad, “t” es algo más cercano a un contador de samples. Podríamos hacer coincidir la rampa con el sample rate, la “resolución digital X”, o sea, +44100 por segundo. Entonces, el resultado en cada momento de nuestra función determina el valor de cada sample. Es decir, potencialmente se puede crear cualquier sonido dentro de las posibilidades de procesamiento digital. Sin embargo, para esto consideré necesario introducir una modificación en el algoritmo del bytebeat. ¿Por qué?

El bytebeat fue concebido de manera tal que cualquier resultado de la fórmula se escale, se mapee, a un número válido, a un valor existente dentro del espectro del bit depth, de la “resolución digital Y” del sonido. De esta manera no hay “error” posible en la fórmula, es decir, más allá de si produce un efecto deseado, ningún resultado excederá los límites de la señal sonora. Esto produce, además, un comportamiento que muchos no dudan en clasificar como fractal. Los “errores” de la función son reincorporados de alguna manera siempre a los valores posibles, generando simetrías (pido disculpas por la precariedad, reducción e imprecisión de mi lenguaje en estas cuestiones, habrán notado que al descartar un desarrollo filosófico opté por el camino más difícil para mí pero estos conocimientos me parecen demasiado valiosos como para no difundirlos). El problema es que al escalar todos los valores perdemos la posibilidad, por ejemplo, de manipular la amplitud de un modo sencillo. Veamos…

Suponiendo que estamos trabajando con una resolución de 8 bits (1 byte), el resultado de nuestra función será escalado mediante %255 a uno de los 256 valores posibles de amplitud (el 0 se cuenta). Si la función devuelve un número más grande o más pequeño, por ejemplo 260, el módulo (%) convierte al excedente en el valor final: 4. Pero supongamos que quiero generar una onda cuadrada t%2 y reducir su amplitud a la mitad multiplicando o dividiendo como (t%2)*0.5 o (t%2)/2, esto tendría otras consecuencias, no en la amplitud sino en la frecuencia. Lo que hice yo, entonces, fue quitar este mapeo a valores posibles y dejar únicamente un limitador, perdiendo esa natural fractalidad del bytebeat pero ganando en resolución, modelado y legibilidad. También es importante destacar que el objeto que en Pure Data permite procesar estas expresiones (expr~), también admite muchas más operaciones como, por ejemplo, funciones trigonométricas.

El sistema que armé, y en el que sigo trabajando constantemente, se llama Rampcode y gracias a la colaboración de Reo Matsumoto existe un paquete para utilizarlo con Atom editor. Recientemente incorporé la posibilidad de reemplazar la variable por otra (a la vez función de la primera), agregando una función en el medio. Así que, una vez que tengo algo sonando que me gusta o que tiene “momentos” que me gustan, puedo alterar su secuenciación y velocidad modificando la función anterior, obteniendo variaciones y “efectos”.

Rampa → Función (por defecto = Rampa) → Función

Para ver – y escuchar – más en detalle todas estas cuestiones dejo una selección de links un poco ecléctica, como este discurrir. Queda pendiente, para pronto o quizás nunca, un desarrollo más filosófico respecto de la experiencia estética, seguramente afirmando el plano de inmanencia del lenguaje, en un tono menos pitagórico, con las notas más bellas que me sean posibles.

https://greggman.com/downloads/examples/html5bytebeat/html5bytebeat.html

Un entorno de bytebeat online para jugar un poco.

http://pelulamu.net/ibniz/

En mi opinión, el mejor software de bytebeat.

http://viznut.fi/en/

El pionero del bytebeat y otras genialidades.

http://www.biblioteca.unlpam.edu.ar/pubpdf/circe/v4a09cotello.pdf

Un artículo de respetable academicidad que encontré en castellano sobre Aristóxeno (ver p.162).

https://github.com/gabochi/rampcode

El repositorio de Rampcode.

Cómo evaluamos el concurso?

Rupickman nos preguntó cuáles fueron los criterios de evaluación que se tuvieron en cuenta para definir los ganadores del Concurso Mariana Baraj. Una muy buena pregunta, por básica pero integral.

Lo primero que tenemos que decir es que creemos que una toma de decisión, frente a cualquier cosa que ocurre, es en última instancia subjetiva. Porque los que elegimos los ganadores, no somos el jurado de Latin American Idol, que se propone encontrar «al mejor». Somos personas, que elegimos algunas canciones en particular para resaltar, porque creemos que condensan bien lo que va sucediendo con la Música Libre y Colaborativa. De ahí a que sean las «mejores», hay un camino. O, mejor dicho, no lo hay.

Lo cierto es que, como ya hemos dicho en diversas situaciones, nosotros pensamos el Concurso sin lógica competitiva, sino asociativa. Porque apostamos a la potencialidad de las redes distribuidas, y la lógica del ranking inherente a la competencia puede ser contraproducente. El Concurso, sin embargo, resultó ser un puño en una cama, que aglutinó a gente de distintas tendencias, motivaciones y formas de vida concretas. Los resultados, hay que decirlo, son maravillosos. Con definiciones estéticas propias, cada artista sugirió obras de alto nivel.

Nada de esto, por otro lado, nos detuvo de pensar los criterios de evaluación del Concurso. Simplemente los humanizaron, porque tratamos de tener en cuenta la persona de carne y hueso que se sumó concretamente. Como dato, es importante consignar que las obras se escogieron de común acuerdo con Mariana Baraj.

Los «científicos» criterios.

Lo más relevante fue el nivel de involucramiento personal en la obra. Un dato bastante subjetivo, pero no desconocido: la mayoría de los participantes mandó un relato sobre su experiencia en el concurso; tenemos muchas veces el audio de las canciones que habían subido anteriormente para comparar; en sus perfiles públicos de RedPanal dejan blogs, fotologs o perfiles de otras redes sociales donde vuelcan información más personal. Es decir (con lógica 2.0) el contenido es generado por la comunidad, con datos absolutamente públicos.

Alomejo luego no vuervo, realizada por Huzkey, fue elegida por la integralidad lograda, la diversidad cultural involucrada y la participación personal empeñada.

Integralidad. Alomejo es un tema que uno podría perfectamente imaginar que fue grabado por Mariana Baraj y Huzkey en conjunto, teniendo la canción forma desde antes de entrar al estudio. Sabemos que no ocurrió así, pero pon el tema y escuchalo… Increíble!

Diversidad Cultural. Las pistas de una copla folclórica del norte argentino se juntaron con el rap ibérico en la red, por voluntaria espontaneidad de las partes. Un entrecruzamiento que no tiene accesorios superfluos. Se basa en el arte, en la música, en cuerpos que danzan hace miles de años, y lo siguen haciendo.

Participación personal. Huzkey había subido su disco a RedPanal. Una decisión personal que apuesta a la Cultura Libre como paradigma que crece. Si lo escuchan, notarán que es notablemente similar (en términos estéticos) a la canción del concurso. Huzkey sabe lo que quiere hacer y lo hace. Compuso el tema, su melodía y las letras, con un perfil definido, teniendo en la base las pistas de Mariana. Y, como si fuera poco, llamó a sus amigos Gonzilla y DJ Swanky para que hagan el scratching. Porque cuando los músicos tenemos un buen tema eso es lo primero que hacemos, convocamos a la muchachada a tocarlo un poco a ver qué pasa.

En los próximos posteos hablaremos sobre las canciones «destacadas» (las cuatro que hemos puesto en la home de RedPanal.com) y las «menciones especiales».

Participa de nuestro Foro o deja tu comentario!

Mariana Baraj y Tomas Olano.

Tomás Olano se plantea la necesidad de no repetir formas en el proceso creativo. Dejamos el texto que nos envío sobre su experiencia en el Concurso Mariana Baraj, muy rico por su capacidad cuestionadora.

«Terminé la composición para el concurso con los sonidos del PROYECTO B. Lo único que agregué fue el piano, porque en mis años de estudio aprendí que pocos recursos pero bien trabajados hacen que la obra sea clara, concisa y exprese de manera mas sencilla la idea del compositor. Trabajé con pocas pistas, intenté ocultar los sonidos (porque como músico también amo el silencio) pero no pude. La obra trabaja sobre y con la voz. No hay tempo estable (loops), aunque por momentos aparece una rítmica constante que se diluye. Creo que salir del tradicionalismo es escapar primero a las presiones que tiene el alma, a las constantes rítmicas, tonales, formales, tímbricas.»

Para Tomás «disponer de variados y excelentes programas de edición no asegura nada. La mayor parte de las veces el programa compone por nosotros si no sabemos como utilizarlo. Por eso me llevó tiempo hacer la obra. Hasta que no sonora lo que yo quería y necesitaba, no continuaba.» De acuerdo a esto, nos plantea que en la pestaña Editores de RedPanal hablamos de ellos como cada vez más intuitivos y nos hace una excelente pregunta… ¿Acaso la intuición no nos lleva muchas veces a terrenos ya conocidos? Desde RedPanal creemos que lo intuitivo de estos programas tiene que ver con la facilidad para utilizarlos, y no con los planteos estéticos de cada uno. Sin embargo, no deja de ser una interesante pregunta disparadora la que nos hace.

Finalmente, Tomás nos cuenta que «un problema que surgió fue la utilización de los metales. Me hubiese gustado que la obra tuviera alguna irrupción de una Tuba o una Trompa, pero aunque disponía del instrumento y el instrumentista no hacía tiempo para el estudio de grabación. Jamás pensé en sustituir eso con un instrumento midi. No hay nada mas odioso que escuchar sinusoides altivas. En fin, la obra es lo que se presenta, no la ausencia de

Eso es todo -concluye-. Subo algunos de los sonidos con los que trabajé (que son los editados del Proyecto B) para que estén a disposición de todos. La obra no es el sonido en sí, sino como se presenta y se transforma en el tiempo. Acaso eso sea la composición, una continua transformación de los sonidos y de nosotros mismos…».