Sé muy poco sobre este tema, a pesar de lo mucho que me interesa. He estado haciendo programas “generativos” desde la época del QBASIC, a principios de los 90′s. En aquel entonces lo hacía con letras y palabras. Más tarde llegó el MIDI. En mi opinión el MIDI, como concepto, es algo trascendente, aunque nunca logré explicar claramente la razón de mi entusiasmo -que se mantiene incluso en la actualidad, cuando el MIDI parece haber sido superado por nuevas tecnologías-, y eso que tuve a mi cargo la docencia de esa materia durante varios años en la ORT.

Parte de esa explicación la encontraremos hoy aquí. Veremos que, en efecto, el MIDI tiene mucho que ver con lo que podríamos llamar la “modelización” de la música, y que ésta, a su vez, se vincula directamente con el tema central del presente artículo. La música, como fenómeno complejo que es, admite distintos niveles de descripción. La idea de “niveles de descripción” está muy bien explicada en el capítulo X de un libro que me parece maravilloso: Gödel, Escher, Bach… de Douglas Hofstadter (no es un libro de música). El concepto que Hofstadter maneja allí, al que llama de esta manera, es de uso corriente en la teoría informática, pero se puede aplicar prácticamente a cualquier sistema. No voy a desarrollar aquí el concepto mismo, sino que me limitaré a poner algunos ejemplos de su aplicación al campo de la música, con los cuales va a quedar clara inmediatamente la idea.

En la música, el nivel de descripción más bajo que tenemos es el del sonido mismo, nivel en el que podemos medir amplitudes, frecuencias, fases, aplicar análisis de Fourier, etc. Está claro que este es el nivel más exacto de descripción posible, pero que, a su vez, no contiene ningún elemento “musical” propiamente dicho, es decir, no nos dice nada del estilo, del carácter, de la forma de una obra, ni tampoco de los ritmos, escalas o acordes que ella utiliza. Todos esos conceptos (estilo, carácter, ritmo, etc.) pertenecen a descripciones de alto nivel, algunas de más alto nivel que otras. El concepto de nota musical, por ejemplo, pertenece a un nivel de descripción más alto que el del sonido mismo, podría definirse como un sonido que empieza y que termina, es decir, cuya amplitud crece desde 0, se estabiliza en cierto nivel -la intensidad de la nota- y luego decrece nuevamente a 0, posee por ende una duración, y durante la misma mantiene una característica tonal definida, con una frecuencia que predomina sobre las otras -la altura del sonido, que además, no se mide en Hz, sino en Do, Re, Mi, Fa, etc., una escala logarítmica y cíclica de frecuencias-. De esta manera, creamos un concepto de alto nivel a partir de conceptos pertenecientes a una descripción de nivel inferior, y en adelante, podemos prescindir de las nociones de frecuencia, amplitud, etc., para hablar directamente de notas, duraciones, alturas, etc. Luego, a partir de estos nuevos conceptos, podemos definir otros de más alto nivel aun, como escala, acorde, ritmo, melodía, etc.

Tonalidad, forma, estructura, cadencia, modulación, armonía, constituyen, a su vez, un nuevo nivel de conceptos que pueden definirse a partir de los anteriores como acorde, escala y ritmo, por ejemplo. Pero allí no termina la pirámide conceptual de la música. Es habitual, sobre todo en la crítica musical, utilizar conceptos de altísimo nivel, por ejemplo, decir que una música es triste, alegre, solemne, grave, mística, sublime, hermética, fresca, sutil, elegante, iconoclasta, emotiva, soberbia, ingenua, lúdica, etc., etc., etc. (la lista es interminable), o decir que tiene un sonido más pop, con toques de funk y reggae, pero con firmes raíces en el blues (para tener una idea cabal de lo disparatado que puede llegar a ser esto de los géneros, véase la siguente página). En un nivel no tan alto, pero igualmente opinable, se encuentran todas las consideraciones respecto a la interpretación musical, por ejemplo si un cantante hace un uso exagerado del vibrato, si un guitarrista es virtuoso, etc.

Los niveles de descripción más altos de la música, son aquellos que podríamos llamar conceptuales y comprenden otra interminable lista de cosas ya muy lejanas al sonido mismo, desde la letra de una canción (desde el punto de vista semántico, no el de su sonido, que pertenece obviamente a un nivel mucho más bajo), el libro, la filosofía, doctrina o teoría en que está inspirada una obra, hasta la vestimenta o la actitud de los músicos en el escenario, su relación con el público, su extracción etárea, geográfica, social, etc. Todos estos elementos suelen estar presentes cuando se habla de música, y muchas veces se abusa de ellos y se los maneja imprudentemente, como si se tratara de conceptos de bajo nivel, evidentes, medibles e inmutables, como una frecuencia o una amplitud, lo cual me parece una aberración, pero eso ya es tema para otro artículo.

Bien, volviendo al tema del MIDI, ¿en qué radica su trascendencia? El MIDI constituye una descripción de alto nivel de la música, pero sin embargo su nivel es más bajo que el de una partitura de notación musical tradicional. El MIDI no es, por supuesto, una descripción del sonido mismo, en términos de amplitud, frecuencia y fase, sino que se basa en el concepto recién visto de nota, al igual que la teoría musical clásica. El MIDI presenta un nivel de abstracción¹ -para mi gusto- ideal, que permite describir la música en términos de piano-roll (rollo de pianola), es decir, como una gráfica de notas en función del tiempo, que admite alturas, comienzos, duraciones e intensidades arbitrarias para cualquier número de notas. Desde este punto de vista, el MIDI podría definirse como una “partitura de bajo nivel”.

La partitura de notación musical estándar no es una descripción completa de la música, solamente establece en forma unívoca la secuencia de alturas de las notas, y brinda una descripción muy somera de su relación con el tiempo, siendo el intérprete en última instancia el que posee y aporta el resto de la información necesaria para convertir esa notación en música, a la hora de ejecutar. Una “secuencia” MIDI, por su parte, comparte con la notación tradicional el hecho de estar basada en notas, pero en cambio, ofrece una descripción muchísimo más completa del aspecto más olvidado de la teoría musical tradicional (y de la propia música clásica europea): el ritmo. Por ejemplo, dos notas que en una partitura normal aparecen como iguales, pueden tener, en la ejecución real, distintas intensidades y distintas duraciones; el MIDI reflejaría sin problemas esa diferencia mientras que la partitura estándar no. (La partitura estándar realiza una abstracción que deja fuera esos detalles, manteniendo en cambio una descripción completa del aspecto tonal; esta predilección por las alturas tiñe a la propia teoría, como ya veremos, y juega -a mi juicio- un rol negativo en la comprensión del fenómeno musical mismo).

El MIDI es, por otro lado, una manera de codificar la música electrónicamente. A principios de la década del 80 las computadoras pudieron manipular este tipo de información, grabar, reproducir, editar, modificar, componer (“secuenciar”), experimentar, y por qué no, generar música algorítmicamente. Actualmente las computadoras son capaces de trabajar con el sonido mismo, con las amplitudes, las frecuencias, las fases, logrando un control sin precedentes sobre la grabación musical desde el nivel más bajo, sin necesidad de recurrir a la abstracción del MIDI. Sin embargo, el MIDI como concepto sigue estando presente en los casos en que se trabaja con sintetizadores -virtuales o no-, y el software permite editar notas, arpegios, escalas, acordes, ritmos; aunque no se vea, el MIDI sigue estando allí. Aunque el resultado final de la cadena salga en forma de audio, el MIDI sigue formando parte de ella. En el caso de la composición algorítmica, cuando el modelo de teoría musical que usamos está basado en notas (podría no estarlo, de hecho existe una buena cantidad de músicas imposibles de describir en términos de notas; no nos ocuparemos de ellas en el presente artículo), entonces ocurre esto mismo, lo que nuestro algoritmo está generando, en última instancia, puede representarse directamente como información MIDI.

Es importante aclarar lo siguiente: resulta imposible disponer de un modelo o una teoría de la música que funcione en todos los niveles de descripción y se ajuste a todas las músicas existentes o posibles (a menudo se habla de sistemas musicales) e incluso que pueda explicar todos los elementos presentes en una sola obra, si vamos al caso. Asimismo, cuando hablamos de composición algorítmica, siempre vamos a estar hablando de niveles de descripción relativamente bajos de la música. Por ahora, la posibilidad de que un programa informático genere u opere con elementos conceptuales, semánticos o de un nivel de abstracción relativamente alto, se encuentra tan lejana como la de que una computadora piense o tenga sentimientos. (Esta aclaración puede resultar obvia, pero sé que a algunas personas les cuesta entender por qué nos fascinan los robots, por ejemplo, y esperan que un robot haga algo verdaderamente humano. De lo que se trata, en realidad, es de investigar, a través de la composición algorítmica, la inteligencia artificial, o lo que sea, temas como de qué está hecha la música, y en definitiva, de qué estamos hechos nosotros). En este artículo nos centraremos en el nivel de descripción de la música que nos brinda el MIDI, aquel en el que podemos hablar de notas, intensidades, duraciones, alturas, ritmo, melodía, armonía, etc., pero está claro que este no es el único nivel posible, que no puede aplicarse a cualquier música, y que ni siquiera puede abarcar todos los aspectos de una sola obra, como dije antes. En particular, soy consciente de que el enfoque MIDI descuida un aspecto del sonido que es de enorme importancia a nivel sensible: el timbre, sin el cual mucha gente se encuentra perdida a la hora de escuchar.

Como decía al principio, sé muy poco sobre composición algorítmica, he leído apenas por arriba algunas generalidades, escuchado sin mucha atención algunos ejemplos, probado sin mucho esmero algún que otro software y tomado nota sin mucho convencimiento de algún que otro algoritmo. Por lo tanto lo que voy a decir aquí carece de “rigor científico”, es más bien una serie de intuiciones que tengo al respecto. La primera de ellas es una observación que insinué más arriba, pero que voy plantear de lleno en este momento: la teoría musical tradicional, y por ende, también la gran mayoría de los artículos que pude encontrar sobre composición algorítmica, se basan en un modelo musical incompleto, en el que se le da mucha importancia al estudio de las alturas (escalas, acordes, armonía) pero que es muy pobre en su descripción del ritmo.

No obstante, algunos teóricos modernos han profundizado en el estudio del ritmo, devolviéndolo de alguna manera a su justo lugar dentro de la teoría musical, y no es casualidad que estos mismos autores también se hayan ocupado, en algunos casos, de temas como la relación entre música y lenguaje o entre música y cognición. En mi concepción, la música es esencialmente ritmo, la melodía puede verse como un concepto ampliado de ritmo (un ritmo multidimensional, y esto abarca, antes que las alturas, las ya mencionadas intensidades individuales de cada nota). El nivel de descripción en el que se habla de frases musicales, puede ser visto como una “melodía de melodías”, y los niveles armónico, formal, estructural, pueden ser vistos también como macro-melodías de bloques musicales, o de reglas que rigen esos bloques.

Ahora bien, ¿qué importancia tiene todo esto, el modelo musical o el nombre que le pongamos a cada cosa? El problema, para mí, es que un modelo incompleto de la música, conduce a centrar la atención en aspectos irrelevantes, o que por sí solos carecen de sentido, tanto a la hora de analizar música como a la de intentar emularla por medios informáticos. Precisamente, intentar generar música con un software es una buena manera de advertir la limitación de nuestro modelo, y entender la necesidad de un modelo más profunfo, que parta de más abajo y llegue hasta más arriba -en materia de niveles-, y que explique ya no lo que vemos en una partitura, sino lo que realmente suena, la música misma.

En esta última frase se encuentra el quid de la cuestión (qué expresión antigua, ¿eh?). Dijimos más arriba que la partitura tradicional “establece en forma unívoca la secuencia de alturas” pero en cambio, describe en forma pobre o directamente nula otros elementos que, sin embargo, están presentes en una interpretación -quiero decir, en la ejecución de la partitura-, y que no son triviales, dado que la alteración de estos elementos produce cambios radicales en la “musicalidad” del resultado final. Esto es muy fácil de comprobar: si ingresamos la información explícita de una partitura -mayormente las alturas de los sonidos y sus duraciones- en un programa de notación musical, y luego le pedimos al programa que nos haga un preview auditivo de dicha partitura, dependiendo del estilo de la música que se trate observaremos que, en el mejor de los casos, el resultado se parece a una mala ejecución de esa música, pero que también puede resultar una mala ejecución de otra música bastante distinta, o directamente algo que no es música en absoluto.

Por alguna razón, existe una tendencia ingenua, simplista, a modelizar la música como lo que más claramente vemos en una partitura: la secuencia de alturas, prescindiendo de todo lo demás. Incluso el propio Hofstadter tiende a caer en este error cada vez que analiza una música, en su premiado libro (aunque talvez las obras de Bach a las que se refiere allí, sean las que mejor se presten a este tipo de análisis). Lo que me interesa destacar es que me parece trivial concebir un sistema de composición como un simple método para obtener una secuencia de alturas. Una secuencia de alturas no determina prácticamente nada en música, no existen secuencias de alturas “musicales” y secuencias “no musicales”, ni tampoco secuencias más musicales que otras. Cualquier sucesión de alturas puede utilizarse para hacer música, más aun si esas alturas se desprenden de una escala diatónica. Esa es precisamente la razón por la que, se presume, muchos compositores clásicos habrían recurrido de distintas formas al azar como herramienta compositiva, o por la que Hermeto Pascoal practica una composición instantánea a partir de una secuencia de notas azarosa aportada por el público, o por la que, en definitiva, existen tantos sistemas de composición “algorítmicos”, que realmente funcionan, en el sentido de que es posible gracias a ellos componer una música nueva, con la intervención del hombre, pero que no son suficientes por sí solos para generar una pseudomúsica mínimamente interesante, es decir, no resuelven el principal problema de emular electrónicamente un comportamiento musical (no está claro, por supuesto, que sea ése el objetivo que se proponen, pero sí el mio).

En síntesis, considero que concentrarse en sintetizar secuencias de alturas es perder el tiempo, así como lo es analizar la música exclusivamente desde esa perspectiva, o con un énfasis exagerado en ese aspecto. No dudo que la melodía es un elemento sobresaliente en la música, y que merece un estudio detenido y toda nuestra atención, el problema es que el modelo ingenuo de melodía al que se suele recurrir es estéril. Está claro que abstraer la secuencia de alturas per se no conduce a nada, es básicamente un error. Antes bien, nuestro modelo musical debe partir del ritmo. Es imposible explicar la melodía sin recurrir al ritmo, en cambio sí es posible explicar incluso una secuencia de alturas como un fenómeno rítmico. Esta es una idea intuitiva que tengo, que no voy a poder desarrollar por completo aquí, pero que voy a intentar trasmitir a través de los ejemplos de mis propias investigaciones en música generativa.

Mi propia experiencia.

En el 2008, no recuerdo bien en qué circunstancias, me propuse hacer un programa que generara música. La idea, que aun sigue vigente, en realidad, era crear algo así como un instrumento musical de alto nivel, es decir, algo que sirviera a los fines de la expresión pero que en su interacción, en lugar de producir notas como un instrumento estándar, produjera músicas. Claro, en realidad ya existen múltiples dispositivos y softwares de este tipo, desde los viejos órganos con acompañamiento automático que, recuerdo, me atraían mucho cuando era chico, pero la idea era crear uno a mi entero gusto y satisfacción.

Comencé a trabajar y pronto me dí cuenta de que el primer paso era generar patrones rítmicos, prescindiendo momentáneamente del tema de las alturas de las notas. Comprobé, sin embargo, que a su vez, para que haya ritmo deben haber distintas notas, distintos sonidos que contrasten entre sí. Al final terminé modelando un software que generaba comportamientos baterísticos, y lo llamé “Zappator”; aquí está el artículo que en aquel momento le dediqué, y aquí está el programa mismo.

Posteriormente, intenté seguir desarrollando el Zappator pero no llegué muy lejos. Prácticamente no volví a meterme en el tema de la música algorítmica, exceptuando, si se quiere, el caso de la Pelota de los Dioses y la danza del Robotito. En el primero de esos casos no se trataba tanto de generar patrones musicales, sino de mapear data proveniente de sensores a parámetros del sonido, una de las técnicas clásicas de la composición algorítmica, cuando esa data en lugar de provenir de sensores proviene de procesos estocásticos, autómatas celulares y todo tipo de algoritmos matemáticos. Precisamente, en ocasión de trabajar en ese proyecto, volví a caer en la cuenta de que asignar secuencias “mágicas” de números obtenidos por el más bello algoritmo, o por el muestreo del más significativo fenómeno, a algún parámetro de relativo bajo nivel del sonido -las alturas y las duraciones de las notas, por ejemplo, o directamente la frecuencia de un oscilador o un filtro dentro de un algoritmo de síntesis- produce resultados muy interesantes, pero en ningún caso música, tal como yo la concibo. En LPDLD había una rutina generadora de música, en realidad, y eran los parámetros de esa rutina los que se veian afectados por los ejes del sensor, junto con algún parámetro directo del MIDI, típicamente el pitchbend. Pero la rutina generadora de música era bastante aleatoria y muy poco musical, aunque el resultado podía mejorar en cierta medida gracias a la “habilidad” (o la suerte) del ejecutante.

El mes pasado, tuve la oportunidad de trabajar para la instalación Picidae Chorus, de Tangible Interaction, que se estrenó el 8 de Julio en el Stanley Park, con motivo del 125 aniversario de la ciudad de Vancouver. Mi trabajo consistió en desarrollar el software que desde una Arduino Mega 2560 controla a los 7 “woodpeckers” (pájaros carpinteros) que picotean rítmica y sincronizadamente sobre una madera sonora, cada uno en su árbol, y al hacerlo se alumbran con un led RGB y luego disminuyen lentamente su luminosidad. Estos pájaros generan en su conjunto una pseudomúsica, que va evolucionando lentamente, con patrones que ocasionalmente se repiten, voces que se contestan unas a otras, etc., como para dar la sensación de que hay una inteligencia en ellos.

Este trabajo me dio la oportunidad de reflotar uno de los intentos fallidos que había ensayado en 2008, previos al Zappator: la fractal_rhythm. Se trataba de una rutina recursiva, con la cual quería poner en práctica la idea de que ritmo, melodía y estructura podrían obedecer a las mismas reglas de generación. Era una idea atractiva y ambiciosa, pero en la práctica no había funcionado. Volví entonces a implementar esta rutina recursiva, pero ahora con reglas mucho más explícitas, y que pueden ser distintas para cada nivel de recursión. Esta vez sí tuve éxito, gracias además, a que las probabilidades de cada opción que el programa puede tomar en cada momento, se controlan fácilmente y de forma precisa con una rutina que vengo utilizando en otros proyectos, la markov (en honor a las cadenas de este señor).

Veamos aquí una de las primeras pruebas que realicé antes de llegar a la versión final, utilizando la garrafa de brazos de disco duro que gentilmente me prestaron Daniel Argente y Marcos Umpiérrez, sus creadores.

Pinche aquí para ver el vídeo

Otras pruebas con la misma versión del software pueden verse aquí: [1] [2] [3].

Expliquemos brevemente cómo funciona esto. El software de control alojado en la Arduino, consta fundamentalmente de 2 módulos: por un lado el generador y por otro lado el reproductor. El generador se encarga de crear los patterns musicales, a demanda, colocándolos en un gran buffer con capacidad para 384 divisiones rítmicas en total. El reproductor se encarga de traducir esa información a los distintos periféricos (solenoides, luces RGB, salida MIDI) en tiempo real.

Una capa de nivel superior que podríamos llamar el programador se encarga de decidir cuándo, con qué parámetros y en qué región del buffer generar, y cuándo, qué, y con qué parámetros, reproducir. Este módulo es el responsable de la lenta “evolución” de los estilos musicales, los cambios de tempo, de métrica, etc., la repetición de patterns y las paráfrasis (patterns que se repiten pero con leves cambios). Para esto último, el programador llama ocasionalmente a unas subrutinas denominadas plugins, que producen transformaciones sobre los patterns actualmente almacenados, por ejemplo “cambiar alturas”, “quitar notas”, “agregar notas”, etc. El programador es entonces responsable de la macro-estructura musical. (En la versión de los videos, esta capa no está implementada aun, y en su lugar hay un tosco programador que cambia bruscamente los parámetros cada entre 3 a 8 compases, generando la sensación de que la música se va del tiempo, y jamás repite un pattern sino que siempre genera uno nuevo; pero más abajo tendremos un render de 8 minutos de audio generados con la última versión de este software, en la que sí está implementado el programador).

Existe tambíén una capa de bajo nivel, gobernada por una interrupción asociada con un timer, que gestiona la temporización necesaria para los solenoides y las luces. Los solenoides necesitan un tiempo de sustain de aproximadamente 50ms y las luces necesitan atención permanente para producir el efecto de fade-out. Esta capa no tiene nada que ver con la música, pero gracias a ella el hardware puede ser controlado con la misma Arduino, sin interferir con la reproducción musical real-time, cuyos tiempos tienen que ser exactos.

De todos estos módulos, el generador es por supuesto el más complejo. Su funcionamiento se basa en la rutina recursiva antes mencionada, que va recorriendo la línea de tiempo, y a cada paso tiene la opción de colocar una nota, colocar un silencio, o subdividir, o sea generar un nuevo nivel de recursión. La subdivisión puede ser en 2, 3, o 4 partes iguales, o incluso en patrones métricos predefinidos, como por ejemplo el 3-3-2. Esta estructura de árbol básica, está condicionada por una cantidad de reglas definidas, las cuales establecen la probabilidad de que ocurra una u otra de estas opciones, dependiendo del nivel de recursión en que se esté, de la ubicación temporal, de la duración de la nota anterior, etc., etc. A este conjunto de “reglas rítmicas”, se suman las “reglas melódicas”, es decir, una vez que se establece que en determinado punto va un sonido y se conoce su duración, hay otro conjunto de reglas para determinar la altura de ese sonido y su intensidad (velocity MIDI). Estas nuevas reglas también utilizan probabilidades controladas, que dependen del lugar que ocupe la nota en la métrica, de su duración, y de las propiedades de las notas anteriores, entre otras cosas.

A su vez, todas estas reglas poseen parámetros globales ajustables desde el programador, por ejemplo: coeficiente de silencio, coeficiente para cada uno de los tipos de subdivisión, rango de alturas restringido, etc., etc. Combinando todos estos parámetros, más la propia medida del pattern y el tempo global, es posible generar una amplia gama de comportamientos, que van desde un simple tren de negras, a sobrecargados e intrincados ritmos, desde una nota única que se repite, a escalas que suben y bajan. De esta manera, podríamos implementar varios de estos generadores trabajando simultáneamente, asignados a distintos timbres, con distintas pautas de comportamiento y distintas tesituras, es decir, una verdadera “orquesta” algorítmica. Para realizar esta prueba sería necesario antes que nada portar el programa a Processing, porque el Arduino no tiene suficientes recursos para esto.

Como ya dijimos, en los 4 videos anteriores no existe la capa de alto nivel encargada de darle cierta “forma” al material. El concepto de “melodía” que maneja el programa es en realidad un concepto rítmico, es decir, considera el conjunto de notas -que en este caso es de 7 notas- como un conjunto ordenado de “sonidos contrastantes con los que generar un ritmo”,  sin preocuparse en absoluto de las relaciones armónicas entre las notas. (En este caso los intevalos entre las notas sucesivas son de 5as., para las 7 notas que salen del módulo MIDI, pero a su vez esas 7 notas están mapeadas sobre las 4 notas de la garrafa, cuyas alturas son poco definidas, y prácticamente aleatorias). En el siguiente ejemplo escucharemos un audio de 8 minutos aprox., usando la salida MIDI con un timbre de piano, obtenido con la última versión del programa. En este caso, las notas son 12 y corresponden a una escala cromática.

Como podemos oir, el programa sigue sin saber nada de intervalos ni de armonía. Su concepto de melodía consiste en gravitar en torno a una altura y aplicar grado conjunto (que en este caso resulta ser siempre un semitono) o saltos mayores dependiendo de la articulación rítmica. Sabe, por ejemplo, la dirección melódica, y tiene reglas que le indican cuándo conservarla y cuándo invertirla. Las reglas melódicas en realidad son muy básicas, porque, en efecto, la aplicación para la que fue concebido era meramente percusiva. El algoritmo no maneja duraciones de notas, por ejemplo, sí puntos de comienzo, por supuesto, y también acentuaciones (intensidades individuales de cada nota) lo cual es importante. El paso para dotarlo de noción armónica es simplemente restringir a escalas o arpegios predefinidos el subconjunto de notas con que puede operar en cada compás o fragmento de compás, y, con un grado aun mayor de sofisticación, establecer un subconjunto más restringido para tiempos fuertes o partes fuertes del tiempo, y otro más amplio para tiempos débiles o partes débiles del tiempo.

Obsérvese la acción del programador. Aquí sí podemos hablar de una capa de nivel superior que se encarga de administrar los patterns y repetirlos ocasionalmente, total o parcialmente, textualmente o con pequeñas modificaciones. En la práctica, el programa trabaja sobre un buffer de 4 compases, donde ocasionalmente sustituye cierto sector por un material completamente nuevo, otras veces transforma levemente lo que está actualmente almacenado en un sector, y otras veces simplemente ejecuta al azar alguno de los sectores. Los “sectores” normalmente son compases, pero puede ocurrir que sean fragmentos de compás, cuando, por ejemplo, un material fue generado en 4/4 y a la hora de ejecutarlo o modificarlo, la métrica puede haber pasado a 2/4 o a 3/4, o a la inversa, entonces ocasionalmente se forman combinaciones parciales de patterns, muy interesantes.

El resultado de todo esto es que se generan estructuras parecidas a las de la música normal, tipo AABA’CBC’ADD’CDB’EC etc. Esta capa de macroestructura es lo que estaba faltando para que la pseudomúsica tuviera “forma”, pero comprobé que no hace falta que las estructuras sean simétricas, geométricas, ni con ninguna forma especial, sino que basta con esa simple cadena levemente aleatoria para obtener un resultado bastante “musical”, muy distinto de lo que se oye en los anteriores videos. Con respecto a los plugins que transforman el material, actualmente hay uno solo, pero ya tengo en mente muchísimos más, que emularían los recursos clásicos de la composición (paráfrasis, inversión, espejo, desplazamiento rítmico, transposición, expansión-compresión temporal, etc., etc.).

P.G., 26/7/2011

Revisión e ilustraciones de Alvaro Cassinelli

Pinche aquí para ver el vídeo

En setiembre del año pasado, luego de su presentación en el marco de los workshops del 6º Campeonato de Sumo Robótico, todavía no tenía muy claro qué hacer con SAMSA, hacia dónde orientar su programación.

Finalmente decidí que SAMSA tenía que ser un robot capaz de un nivel más sofisticado de sensibilidad auditiva, ya que en mis robots anteriores había experimentado más que nada con diversos tipos de dispositivos ópticos (con mayor o menor suerte), y de emisores de sonido. Esto podría darme la excusa, por ejemplo, para desarrollar un sistema de reconocimiento del ritmo, que le permitiera al robot bailar al compás de la música (y de paso me serviría para el momentáneamente abandonado proyecto Zappator). Por otro lado, me interesaba también experimentar con redes neuronales, ya que suponía que éstas podrían constituir una alternativa a tener que programar línea por línea todo el comportamiento de un robot.

Tal como había publicado en la 1ª etrega de la documentación de SAMSA, la distribución total de tareas del robot a cargo de un sólo y modesto ATmega128 (microcontrolador de 8bit/128KB/16MHz) dejaba, en lo que respecta al audio, tan sólo la posibilidad de medir la intensidad del sonido cada cierto lapso, y ni soñar siquiera con algún tipo de análisis de frecuencias.

La única alternativa parecía ser la de incluir un segundo procesador hardware, exclusivamente dedicado al procesamiento de sonido; pero eso implicaba agregar más componentes, en definitiva, exigirle más al ya sobrecargado sistema electro-mecánico del robot. Era mucho trabajo, y no me convencía.

Se me ocurrió entonces otra solución: al mejor estilo “ZX-81”, el robot entraría temporalmente en un modo “escucha”, durante el cual no podría moverse, mostrar gráficos ni hacer ninguna otra cosa; utilizaría todos sus recursos para “analizar” el audio y actuar en consecuencia. La idea sería aumentar la frecuencia de las interrupciones (a 8KHz, de hecho), y sustituir la actual ISR (interrupt service routine), por otra que sólo procesara audio.

Bien, y cuando decimos “procesar audio”, lo primero que nos viene a la mente es analizar frecuencias. ¿Por qué? Por muchísimas razones, talvez la más importante es que nuestro cerebro mismo percibe el sonido de esa manera. Como no soy para nada experto en FFT, ni estaba seguro de que fuera realmente posible su implementación con estos escasos recursos de cómputo, busqué algún tipo de proceso más liviano, hasta que llegué a un algoritmo que yo mismo bauticé “filtros por correlation recursivos”, que ya debe estar inventado, con otro o con el mismo nombre, y que veremos en breve.

Una vez implementados los 4 filtros de frecuencias fijas (o bandas, no me pregunten.. por cierto, es probable que toda la implementación esté plagada de errores de aliasing y distorsiones de todo tipo; no obstante, contra todo pronóstico, funciona) mirando en la pantalla las gráficas que estos filtros producían, tuve la intuición de que era posible intentar un reconocimiento de palabras, y eso me iba a dar la excusa para “entrarle” a las redes neuronales.

Pasaron un poco más de 6 meses, durante los cuales primero desarrollé la herramienta de diseño y entrenamiento de redes neuronales (Palmer Neural Networks), pero después, al momento de usarla, me daba cuenta de que faltaba algo y no podía avanzar, estaba bloqueado. Por un lado no disponía de mucho tiempo para pensar en esta idea, y por otro lado había empezado a dudar de que fuera posible cumplir con el objetivo. Finalmente a fines de febrero de este año, comencé a dedicarle horas al proyecto, hasta que llegué a este resultado, que dista de ser ideal, pero que nos ilustra claramente qué podemos esperar y qué no, de un sistema con estas características.

Los invito a compartir un viaje por la arquitectura interna de un sistema de reconocimiento de palabras implementado íntegramente en un microcontrolador ATmega128.

Siguiente sección –> Reconocimiento de voz en un ATmega128

Buscando una herramienta para programar y experimentar con audio, efectos y síntesis, decidí probar la biblioteca Minim de Processing. Existen muchos entornos informáticos interesantes para diseñar sonido, algunos son gráficos, otros son de escribir código, algunos son libres, otros son pagos; cito algunos ejemplos: Reaktor, Max-MSP, PureData, SynthEdit, SynthMaker, JSyn, Csound, SuperCollider, ChucK.

Dentro de Processing, existen varias bibliotecas para manejar sonido, entre ellas: Ess, Sonia y Minim, siendo esta última la que viene con la distribución oficial del producto. Rápidamente, repasemos las principales ventajas e inconvenientes -a mi modesto entender- de Minim:

• Ventajas: es simple, transparente, bastante bien documentada y Open Source.
• Inconvenientes: utiliza Java Sound para comunicarse con el hardware de audio.

Muchas de las bibliotecas de Processing son justamente “wrappers” de las funcionalidades de Java. Minim utiliza Java Sound para el audio I/O, partes de otras bibliotecas para otras tareas -como reproducir mp3, por ejemplo- pero también agrega cosas propias e interesantes, en materia de análisis, procesamiento y generación de sonido. A su vez, uno de los principales inconvenientes del sistema de audio de Java es que no soporta ASIO, que como todos sabemos, es la única manera de obtener baja latencia, al menos bajo Windows XP.

¿Cómo funciona la generación de sonido a nivel de software?

El audio digital, a nivel del software, se maneja en buffers. Un buffer es un conjunto de muestras -por ejemplo, 1024 muestras- que se envían o se reciben en bloque hacia o desde el hardware. Mientras la tarjeta de audio reproduce esas 1024 muestras (lo que le llevará 23ms, si el muestreo es de 44,1KHz), el programa tiene tiempo de calcular el bloque siguiente. Cuanto más grande sea el buffer, o sea cuantas más muestras contenga, mayor será la latencia de la que hablábamos en el párrafo anterior (más información sobre buffers y latencia aqui).

En Minim, la clase Oscillator es la base de los generadores de sonido. Cuando se llama al método “generate”, este “llena” un buffer con una forma de onda calculada de alguna manera, por ejemplo con la función trigonométrica seno.

Una consecuencia interesante de esta naturaleza de Minim, es que si nosotros intentamos modificar un parámetro de la onda que se está generando -por ejemplo su amplitud o su frecuencia- desde el módulo principal (la Draw() de Processing) ya sea a partir de un control externo o de una función prefijada, los cambios se van a manifestar de a “saltos” equivalentes a la duración del buffer (23ms, en el ejemplo que veíamos). Esto nos impide hacer un cambio gradual y continuo de cierto parámetro, por ejemplo una envolvente de amplitud. Para lograr este tipo de control, necesitamos implementar otro “Oscillator” que genere la señal de control, y que el primer “Oscillator” consulte a esa señal al calcular cada muestra que pone en el buffer.

Aplicando esta idea a diversos módulos de la biblioteca, e implementando algunos módulos nuevos, surgió la Minim 2.02 PE (palmer edition), con la cual podemos hacer una modesta síntesis modular, que paso a describir y ejemplificar en la página a continuación.

Siguiente sección –> Minim 2.02 Palmer Edition

Cuando la cantidad de combinaciones de variables de entrada es demasiado grande como para elaborar una tabla, y la función es demasiado compleja como para encontrar un algoritmo, las Redes Neuronales Artificiales constituyen una manera distinta de abordar el problema, sumamente efectiva aunque no perfecta, como ya veremos.

Podríamos considerar a la RNA como una especie de “algoritmo universal”, capaz de responder de muchísimas maneras distintas, y al que podemos “enseñar” el comportamiento deseado “mostrándole” ejemplos del mismo (una tabla parcial), para luego esperar que se comporte de la manera buscada frente a todos los casos posibles. Precisamente en esto radican sus principales virtud y defecto: el porcentaje de aciertos puede ser increíblemente grande (teniendo en cuenta lo general que es el método) pero no tenemos ninguna garantía de la exactitud del resultado. La analogía con un “cerebro” animal surge inmediatamente.

Existen en internet numerosos artículos introductorios y avanzados, que explican claramente el funcionamiento de una RNA, mucho mejor que cualquier cosa que yo pudiera escribir aquí al respecto (empezando por este). Mi aporte, en cambio, consistirá en presentar un programa mediante el cual podemos tener una aproximación práctica a la materia, experimentar con redes neuronales, introducir ejemplos reales, lidiar con el entrenamiento y visualizar el proceso de aprendizaje. PNN nos permite “sentir” las redes neuronales artificiales en nuestra propia experiencia, y también resolver algún caso práctico, que fue lo que originalmente me motivó a desarrollarlo.

Características técnicas del programa.

Este programa  se basa en el artículo de Steven W. Smith sobre redes neuronales artificiales, en el capítulo 26 de su excelente The Scientist and Engineer’s Guide to DSP. La red presentada vendría a ser un perceptrón multicapa, con una capa de entrada, una capa oculta y una capa de salida, cada una de ellas interconectada totalmente con la siguiente, con neuronas de bias en las dos primeras capas  y con función de transferencia sigmoide en cada neurona.  El algoritmo de entrenamiento es el que propone dicho autor, al que llama steepest descent, pero que también podemos encontrar bajo el nombre de gradient descent o simplemente backpropagation.

Instrucciones

Para invocar el applet, hagan click aquí.

Al hacerlo, aparecerán 2 ventanas: la ventana de visualización, hecha en Processing, y el panel de control flotante, hecho en Java (que a veces queda oculto tras aquella).

Lo primero que debemos hacer es dimensionar nuestra red. Escribimos el número de neuronas o nodos de cada capa, y apretamos el botón “Dimensionar”. Al hacerlo aparecerá en la ventana de visualización un modelo 3D en el que las neuronas de cada capa están representadas por esferas de distinto color (y las de bias, de un tamaño ligeramente mayor y blancas [ya nos ocuparemos de las opciones de esa visualización, antes de eso, sigamos con la parte "científica"]).

Al apretar el botón “Aleatorizar pesos” aparecen las conexiones entre las neuronas; las verdes son positivas y las azules negativas, y su diámetro es proporcional al peso de la conexión correspondiente.

A continuación deberíamos ir a “Archivo” y seleccionar “Cargar set de ejemplos”, pero lamentablemente esta opción no está habilitada en las applets de internet, por razones de seguridad. En su lugar podemos ir a “Ayuda” y seleccionar “Demo”. Esto tendrá el efecto de dimensionar una red con 7 entradas y 3 salidas, y cargar 3 sets de ejemplos.

Para simplificar las cosas, todos los ejemplos están “asociados” a una salida; esto quiere decir que se asume que producen “1” en dicha salida y “0” en todas las demás. En la lista podemos ver a qué salida está asignado cada ejemplo. Los ejemplos se pueden sacar, seleccionándolos y apretando la tecla “suprimir”. Si apretamos “Enter” sobre un ejemplo, éste se carga arriba, y podemos testear el comportamiento de la red apretando “Procesar salida”. También es posible ingresar valores manualmente en ese campo y probarlos, y una vez ingresados se pueden agregar a la lista con el botón “Agregar ejemplo”. Los valores en las entradas pueden ser enteros de cualquier tamaño; los pesos son números de coma flotante, y los valores de salida son de coma flotante entre 0 y 1.

Si ahora probamos cualquier grupo de valores de entrada, el resultado en las tres salidas va a ser siempre aproximadamente 0,5. Eso se debe a que la red no está entrenada aun. Para entrenarla debemos apretar el botón “Iniciar aprendizaje”. Al hacerlo, los pesos se irán modificando, y un número grande a la derecha nos irá indicando la suma del error que producen todos los ejemplos al ser procesados en la red actual. El objetivo del “juego” (si usted decide aceptarlo) consiste en dejar ese valor lo más bajo posible. El proceso de optimización se repite 1000 veces cada vez que apretamos “Iniciar aprendizaje”, pero habitualmente esto no es suficiente; la cantidad de repeticiones se puede subir a 10000 con el deslizador de abajo a la izquierda. En todo momento podemos ir probando el comportamiento de la red, entre aprendizaje y aprendizaje.

Hasta aquí la operación general del programa. Veamos ahora los detalles.

Redimensionar la red

Al cambiar el número de neuronas en las capas de entrada o de salida, se pierden todos los ejemplos y el aprendizaje realizado. No así al redimensionar la capa oculta. De hecho, es un buen recurso, si notamos que nuestra red tiene “dificultades para aprender”, dotarla de más “capacidad” aumentando el número de neuronas de la capa oculta.

Factor de aprendizaje

Al aumentar este número, hacemos que el aprendizaje sea más rápido, pero también inestable; en ocasiones el error puede quedar oscilando o incluso aumentar. Al disminuir el valor, el aprendizaje se vuelve lento pero seguro.

Aprendizaje extra

La idea de este parámetro está sacada del antes citado libro de S. W. Smith, y consiste darle más importancia, en el aprendizaje, a los ejemplos “positivos” o a los “negativos” (un ejemplo destinado a la salida 2 es un ejemplo “negativo” para la salida 1). Sinceramente yo no encontré ningún resultado con esto, lo voy a revisar para la próxima versión.

Menú Archivo

Todas las opciones del menú Archivo están desactivadas, algunas por razones de seguridad del Java, otras porque no están implementadas aun. La más importante sería la de salvar los pesos una vez concluido el entrenamiento. También podríamos volverlos a cargar para usarlos como punto de partida de una siguiente sesión de aprendizaje.

Menú Configuración

El “Modo Automático” va a estar implementado en la próxima versión. Consistiría en que el propio programa tome nota de cómo va decreciendo o aumentando el error, ajuste automáticamente los parámetros de entrenamiento, y siga actuando solo hasta llegar a un mínimo de error prefijado.

Los distintos “modos de aleatorización” afectan al comportamiento del botón “Aleatorizar pesos”. El algoritmo de aprendizaje parte de un estado aleatorio de los pesos y va modificando sus valores en el sentido en que el error decrece. Puede pasar que en determinado momento el error no descienda más, pero aun continúe alto: estaríamos frente a lo que llaman un mínimo local. Aquí viene al caso la aleatorización relativa, que lo que hace es modificar levemente los pesos pero en relación a su valor actual (introduce una pequeña “mutación”). Con esto conseguimos, a veces, que el error aumente un poco pero luego siga disminuyendo, es algo así como  ”un paso atrás, dos adelante”.

Respecto al error

El dato mostrado a la derecha como “error” se calcula de la siguiente manera:

cada uno de los ejemplos que están en la lista se pasa por la red, y se mide la diferencia entre el valor que debe producir en cada salida y el que realmente produce. Todos estos valores elevados al cuadrado, sumados entre sí y sumados con los provenientes del resto de los ejemplos, nos dan el error total para un estado en particular de la red (media cuadrática). Esto quiere decir que cuanto mayores sean el número de salidas y el número de ejemplos cargados, mucho más difícil va a ser llevar ese valor a 0 (y por supuesto, esto también depende del contenido de los ejemplos mismos). En el caso del problema que viene como demo (que, dicho sea de paso, consiste en diversas versiones de las palabras “uno”, “dos” y “tres” capturadas y codificadas por un nuevo programa de procesamiento de audio que estoy desarrollando para SAMSA) la red se desempeña aceptablemente bien con el error en 20, más o menos.

Opciones de visualización

Por último, la parte “coqueta” del programa.

Al hacer foco en la ventana de visualización, quedan disponibles las siguientes opciones:

• haciendo click con el botón derecho del mouse, detenemos o reanudamos la rotación automática del modelo. Cuando la rotación automática está detenida, podemos rotarlo libremente con el botón izquierdo del mouse.
• con las teclas de dirección seleccionamos un parámetro, que va a aparecer detallado en el ángulo inferior izquierdo de la pantalla, y con las teclas “+” y “–” modificamos ese parámetro.
• los parámetros que se pueden modificar son: la disposición espacial de las neuronas en cada capa, el espaciado de las mismas, la rotación de todo el plano de la capa y la cantidad de caras de la sección de los “caños” que interconectan a las neuronas, que por defecto es 20, pero puede ir de 2 a 50, generando la sensación cilíndrica.

Mejoras para el futuro

Esta es una lista de las mejoras que podrían implementarse en futuras versiones del PNN, algunas de las cuales fueron sugeridas por mis amigos Alvaro y Tomás  (y otras pueden ser un divague, también).

• que las neuronas se muevan, respondiendo a leyes físicas, y que las fuerzas de atracción y repulsión dependan de los pesos.
• ponerle sonido (con la biblioteca minim de Processing)
• esferas texturadas que giren sobre sí mismas
• que las conexiones cambien de color cuando son modificadas
• que las neuronas vibren según su “energía”
• que unas bolas circulen por adentro de los caños
• rotación de las conexiones
• hay que inventar algo para que no haya que apretar 200 veces “Iniciar aprendizaje”
• salvar y cargar pesos
• modo automático: que combine algoritmos genéticos con el backpropagation.

Este post es provisorio, como siempre, aquí van a ver parte de la presentación en dorkbot.mvd el 19 de abril de este año, pero prometo ampliar la información técnica y anecdótica de este maravilloso artefacto, en el futuro.

Pinche aquí para ver el vídeo

Este manual lo escribí en el 2008 para mis cursos. Actualmente lo estoy reformulando por completo, tratando de hacerlo menos denso. Esta entrada es provisoria, el slide contiene incluso algunas páginas en borrador.