Instalación Interactiva de Música Generativa

Instalación Interactiva de Música Generativa Interactive Generative Music System Trabajo de Fin de Grado Curso 2023–2024 Autores Jesús Alberto Barrios Caballero Samuel Asanza Mesa Directores Jaime Sánchez Hernández José Ignacio Gómez Pérez Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid Instalación Interactiva de Música Generativa Interactive Generative Music System Trabajo de Fin de Grado en Ingeniería Informática Autores Jesús Alberto Barrios Caballero Samuel Asanza Mesa Directores Jaime Sánchez Hernández José Ignacio Gómez Pérez Convocatoria: Septiembre 2024 Calificación: Grado en Ingeniería Informática Facultad de Informática Universidad Complutense de Madrid 13 de septiembre de 2024 Dedicatoria A nosotros mismos, por el esfuerzo y la disciplina, aún cuando se nos agotaban las energías v Agradecimientos A mi familia y amigos, por su indispensable apoyo durante todo el recorrido de la carrera y el desarrollo de este proyecto. En especial a mi madre, por superar un cáncer con muchísima fuerza y siempre una sonrisa en la cara, y a mi padre, por aguantar el dolor y los malos pensamientos que la situación implicó y, con todos los golpes de la vida, ninguno de los dos dejó ni por un momento de darme lo que necesitaba y hacerme feliz. Y a Isma y Lavi, por dejarme sin dudarlo su casa como sala de estudio cuando necesitaba máxima concentración, y como consulta donde compartir nuestras crisis existenciales. - Samuel A mis abuelas Elina y Nidia, que emprendieron un viaje a temprana edad en busca de una vida mejor, una cruzando el charco y la otra cruzado una frontera. A mis padres, que dejaron todo atrás para darnos a mis hermanas y a mi un futuro. A mis amigos, que me prestaron un apoyo incondicional estos últimos meses turbulentos. Finalmente, gracias a la tierra que me vio crecer y a los buenos recuerdos que tengo de ella, que me hicieron la persona que soy hoy en día (Gloria al bravo pueblo). - Jesús vii Resumen Instalación Interactiva de Música Generativa En este proyecto hemos desarrollado una instalación interactiva capaz de detectar la posición y los gestos de las manos de un usuario gracias a una cámara y una red neuronal entrenada. Con estos gestos, el usuario interactúa con una música ambiental que evoluciona en directo mediante va sonando. Esto lo hemos conseguido gracias a un modelo de inferencia pre-entrenado que hemos personalizado para nuestro objetivo. La música que suena sigue la filosofía de la música generativa, y el sonido se crea mediante síntesis granular; todo esto gracias a diferentes programas que hemos conectado entre sí, de manera que los datos obtenidos de los gestos sean traducidos en variaciones de los parámetros de la música a tiempo real. De esta manera, se generan texturas sonoras en base a unos audios y presets preguardados y, gracias a los mensajes recibidos de la red neuronal, se puede interactuar de múltiples maneras con este sonido generado. Por otro lado, a este sonido se le aplican efectos de reverb y ecualización, dándole mayor riqueza. El resultado: tenemos establecidas las bases para generar un ambiente sonoro evolutivo en el cual se involucra el usuario, creando su propio sonido haciendo gestos y movimientos en el aire. Este proyecto pretende acercar a un usuario inexperto al mundo de la música ambiental y permitirle crear, utilizando la Inteligencia Artificial no como sustituto, sino como herramienta creativa. Se trata de un trabajo con el aspecto técnico de la programación y el entrenamiento de un modelo, así como el aspecto experimental y creativo de la informática musical. También se pretende explorar el potencial de la fusión de todas estas herramientas y lo compacto y portable que puede ser el resultado. Palabras clave Música Generativa, Síntesis Granular, Open Sound Control, Modelo de Inferencia, MediaPipe, Instalación Interactiva, Python, JUCE, Jupyter Notebook, Machine Learning ix Índice de tablas 6.1. Resultados de las métricas . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Parámetros asociados con los diferentes gestos y manos. OR =parámetro de OrilRiver; EC =parámetro de Emission Control . . . . . . . 44 xvii Cap´ ıtulo 1 Introducción “No es el destino lo que importa. Es el cambio de escenario.” — Brian Eno Entre sus cuasi infinitos ámbitos y aplicaciones, en la era digital actual la informática está fuertemente enlazada al arte en todas sus disciplinas; más aún hemos visto esto en los últimos años, siendo testigos de cómo la inteligencia artificial es capaz de crear obras artísticas que algunos considerarían dignas de un ser humano. Sin ahondar en este complicado terreno, desde hace décadas la tecnología digital se ha arraigado en una de las siete bellas artes del mundo: la música. Tanto es esto así que la tecnología es fundamental desde su creación (creación de sonidos, grabación, composición, producción...) hasta su consumo (difusión, venta, modificación, reproducción...). Concretamente, donde más destaca el uso de la tecnología digital es en el género de la música electrónica, que se basa en el uso de instrumentos y tecnología digital para su producción e interpretación. Enfocándonos definitivamente en la clave de este proyecto, vamos a introducir la piedra angular del mismo: la música generativa [1]. Sin entrar muy en detalle, pues le dedicaremos un capítulo entero más adelante, la música generativa es prácticamente una analogía a la informática: la idea clave es que el autor crea una serie de reglas, podríamos decir que las “programa”, y es en su reproducción que, siguiendo dichas reglas, se crea la obra; esta obra, como ya veremos, puede ser distinta y única cada vez que se reproduzca, lo que le da una mayor riqueza y genialidad a este concepto de la música electrónica. Existen miles de técnicas para crear esta música generativa, siendo una de ellas la síntesis granular [2], la cual desarrollaremos en profundidad más adelante. En resumen, la clave de esta técnica es crear texturas o eventos acústicos en base a cortos granos de sonido. Variando la duración y densidad de estos granos es posible crear sonidos complejos que evolucionan dinámicamente. Recuperando el tema de la inteligencia artificial, hoy en día están en boca de todos las IAs generativas, que sustituyen el aspecto creativo humano del arte, pero 1 2Capítulo 1. Introducción ese no es el único enfoque que se puede dar a una herramienta tan potente como una red neuronal (de nuevo, tendrá su propio capítulo más adelante). Una manera muy interesante de implementar esta tecnología en el ámbito musical es entrenar un modelo para que un usuario pueda interactuar con sus gestos con un sistema que, a su vez, sea el que cree esta música generativa. Así, en vez de utilizar la inteligencia artificial para sustituir al humano, esta puede ser empleada como una herramienta para que sea el humano quien genere arte. Con todo esto sobre la mesa, ¿cómo se puede comunicar un modelo de inferencia con un sintetizador granular? Pues bien, en el mundo de la música digital existe un protocolo de comunicación casi tan utilizado como MIDI que es el protocolo Open Sound Control (OSC) [3]. Este es un método de comunicación ligero, flexible, muy preciso y de baja latencia orientado a la interpretación de música en tiempo real. Tiene su propio formato y codificación, al que dedicaremos un capítulo más adelante. 1.1. Motivación La idea fundamental en este proyecto es que el usuario final, sin necesidad de tener un conocimiento musical previo, sea capaz de interactuar intuitivamente con un sistema musical con unos presets y sonidos pre-configurados que puedan variar y evolucionar. De esta manera, teniendo nosotros un control sobre el resultado final y sus límites (para evitar, hasta cierto punto, silencios o sonidos desagradables y estridentes), el usuario tendrá ciertos grados de libertad para la generación de la música, permitiéndole moverse en un rango limitado. El sonido creado, sin embargo, será algo fluido y sin una estructura clara; no se busca una pieza con un tempo fijado o una partitura bien definida, sino algo más bien cercano a la música ambient [4], creándose una textura y una atmósfera sonora constantes a las que el usuario aplicará pequeñas variaciones con sus gestos. En definitiva, queremos una instalación interactiva intuitiva que cree una música ambiental y cinemática, de manera que el usuario, sin necesidad de saber lo que está cambiando, pueda escucharlo y se sienta parte de la obra. En este proyecto buscamos introducir a usuarios sin experiencia en el ámbito de la música ambiental, ofreciéndoles la posibilidad de crear con el apoyo de la Inteligencia Artificial, no como un reemplazo, sino como un recurso creativo. La idea es unir el aspecto técnico de la programación y el entrenamiento de modelos con el lado experimental y artístico de la informática musical. Asimismo, buscamos explorar cómo la integración de múltiples herramientas puede generar resultados compactos y fácilmente transportables. 1.2. Objetivos Los objetivos del proyecto son: Entrenar un modelo robusto capaz de reconocer gestos. 1.3. Plan de trabajo 3 Buscar y explotar un software de generación musical partiendo de la técnica de la síntesis granular. Plantear la interacción del usuario, mediante los gestos de sus manos, con todos los posibles parámetros musicales. Desarrollar un programa que utilice MediaPipe para detectar los gestos y la posición de la mano. Establecer una conexión cliente-servidor, utilizando el protocolo OSC, entre el programa que hace la inferencia y el entorno encargado de la música generativa. Habilitar una instalación interactiva en el salón principal de la Facultad de Informática de la Universidad Complutense de Madrid. 1.3. Plan de trabajo Una vez se plantearon los objetivos principales del proyecto vistos en la sección anterior, se desarrolló un plan de trabajo para lograrlos en un cierto orden. 1.3.1. Investigación del dataset de gestos Para desarrollar este proyecto, hubo una investigación en la que revisamos varios datasets de gestos de manos provenientes de distintos sitios especializados (como lo son Kaggle [5] o HuggingFace [6]). Tuvimos en cuenta varias nociones, como la cantidad de imágenes o los gestos en sí. 1.3.2. Exploración de la creación del modelo Una vez escogimos el dataset, se procedió a investigar qué herramientas se utilizarían para la creación del modelo, qué arquitecturas de red neuronal nos favorecen o, incluso, si se puede usar un modelo pre-entrenado para facilitar el trabajo. 1.3.3. Exploración de granuladores Al comienzo del proyecto hubo un proceso muy experimental de búsqueda, estudio y descarte de distintos softwares externos hasta encontrar el más fiable y que más se adecuara a nuestras necesidades; todo este proceso tiene su propio capítulo más adelante. 1.3.4. Experimentación con el entorno musical Una vez centrados en el programa con el que finalmente nos quedaríamos, se sucedió de nuevo un proceso experimental y creativo de estudiar dicho programa, entender los distintos parámetros, explotar a fondo sus posibilidades y generar texturas sonoras ricas e interesantes. También se comenzó a investigar cómo recibe los mensajes OSC. 4Capítulo 1. Introducción 1.3.5. Desarrollo del programa de reconocimiento Una vez tuvimos el modelo entrenado, debíamos crear un programa que reconociera los gestos con la ayuda que nos proporciona MediaPipe. Este desarrollo debe ser escalable y con el suficiente rendimiento para tener una latencia baja y que el usuario pueda tener una experiencia interactiva fluida. 1.3.6. Definición de los mensajes Llegados a este punto, debíamos concretar el formato que tendrían los mensajes OSC y cómo interactuaría cada gesto con los distintos parámetros del granulador. 1.3.7. Establecimiento de la conexión vía OSC Conociendo el formato de los mensajes que se van a mandar, se debe desarrollar una estructura cliente-servidor, de manera que el programa de reconocimiento de gestos envíe los resultados de la inferencia con el formato acordado a un servidor que redirigirá estos mensajes a los programas que generan la música. 1.3.8. Refinamiento de la interacción gestual Una vez tuvimos el sistema completo diseñado, debíamos pulir todos sus elementos: que la inferencia de los gestos se hiciera de manera precisa y consistente, que no surgieran problemas de latencia ni de rendimiento durante la ejecución, que los gestos fueran intuitivos y afectasen a parámetros notables y que la música resultante fuera agradable e interesante. 1.4. Estructura de la memoria En esta sección se verá cómo está dividido el documento y se dará una pequeña explicación de en qué consiste cada capítulo. Capítulo 1 - Introducción: se explica la motivación del proyecto, los objetivos del desarrollo, el plan de trabajo que se siguió y, por último, la estructura del documento. Capítulo 2 - Estado de la Cuestión: se revisan varios proyectos anteriores relacionados con elementos fundamentales de este trabajo, como lo son la detección de gestos, la música generativa y la propias instalaciones musicales interactivas. Capítulo 3 - ¿Qué es la Música Generativa?: se explica en extensión qué es la musica generativa, desde su origen y popularización hasta métodos, aplicaciones y ejemplos. Capítulo 4 - Síntesis Granular: se define la técnica de la síntesis granular y sus diversas aplicaciones en el ámbito de la música generativa. 1.4. Estructura de la memoria 5 Capítulo 5 - Selección del Software a Utilizar: se muestra una de las etapas experimentales de este trabajo, en la que se probaron distintos softwares independientes que se emplearon en la instalación del proyecto. Capítulo 6 - Inferencia y Entrenamiento de Gestos: se presentan las herramientas encargadas de la inferencia de los gestos y cómo se aplican los resultados de dichas inferencias, Además se explican cómo se entrenó el modelo utilizado para la detección de los gestos de las manos. Capítulo 7 - Conexión OSC: se explica el protocolo OSC y su uso para el envío/recepción de los distintos parámetros. Capítulo 8 - Instalación Musical: se define la instalación completa de este proyecto, reuniendo todo lo explicado anteriormente. Capítulo 9 - Conclusiones y Trabajo Futuro: se resume el resultado final del proyecto, qué objetivos se cumplieron, cuáles no y el posible trabajo a futuro que deja. Cap´ ıtulo 2 Estado de la Cuestión En este capítulo revisaremos algunos proyectos y estilos musicales ya existentes, así como diversas instalaciones musicales interactivas; analizaremos distintos ejemplos para ver la tecnología, el diseño sonoro y las técnicas interactivas que han implementado para crear experiencias inmersivas y participativas. Con esto, podremos entender la base de lo que se quiere lograr en este proyecto. Podemos comenzar hablando de una obra clásica rompedora que, aun temporalmente lejana al concepto de la música generativa, era en espíritu lo que posteriormente sentaría las bases de este estilo de composición. Esta obra no es ni más ni menos que “In C”, compuesta en 1964 por Terry Riley para un número indefinido de intérpretes. Lo interesante de la pieza son sus directrices de interpretación: “Todos los intérpretes tocan a partir de la misma página de 53 patrones melódicos tocados en secuencia. Cualquier número de instrumentos de cualquier tipo puede tocar. Todos los intérpretes deben tocar estrictamente en ritmo, y es esencial que todos toquen cada patrón con cuidado. Se puede suponer que cada patrón se repetirá durante 45-90 segundos o más. Es muy importante que los intérpretes se escuchen atentamente entre ellos, incluso parando ocasionalmente a escuchar. También es importante no apresurarse de un patrón a otro, sino estar en cada uno lo suficiente para entrelazarse con otros patrones que están sonando. A medida que avanza la interpretación, los intérpretes no deben separarse unos de otros más de 2 o 3 patrones. El conjunto puede ser apoyado por un pulso de corchea tocado en los Do agudos de un piano o un instrumento de percusión.” [7] Como se puede suponer, una obra como esta hace de su interpretación una aventura única cada vez, centrada en la confianza y coordinación entre sus intérpretes1 2. 1Interpretación de In C por la orquesta de la escuela Juilliard: https://www.youtube.com/ watch?v=u7IErSweXpk 2Interpretación de In C por Terry Riley y el grupo Stargaze: https://www.youtube.com/ watch?v=lJPJywWfyGo 7 14 Capítulo 4. Síntesis Granular por ello que decidimos centrarnos en tecnologías de este estilo. [17] 4.2. Curtis Roads y la síntesis granular Curtis Roads ha sido una figura destacada en la historia de la síntesis granular. No solo su trabajo en el campo ha sido innovador, sino que también ha ayudado a solidificar la técnica como un elemento fundamental en la producción de música electrónica y experimental. Con su libro “Microsound” de 2001, que se podría considerar un trabajo importante sobre la síntesis granular y los métodos relacionados con la manipulación de sonido a escala microtemporal, Roads explora cómo se pueden usar los granos para crear nuevos tipos de sonido y música. Su trabajo se basa, en general, en la premisa de que cada grano es lo suficientemente pequeño como para ser considerado una unidad fundamental de sonido. Mezclando y transformando los granos de esta manera, se pueden crear texturas sonoras complejas que son completamente inconvencionales respecto a la música tradicional. [18] Roads también ha investigado la posibilidad de la síntesis granular en materia de música generativa, ya que la capacidad de producir y manejar miles de granos de sonido al mismo tiempo en tiempo real permite producir paisajes sonoros que cambian con el tiempo. En sus obras, como “Point Line Cloud” de 2005, Roads demuestra cómo la síntesis granular se puede emplear para originar estructuras sonoras complejas que cambian de maneras impredecibles, el factor principal de la música generativa. [19] 4.3. Aplicaciones de la síntesis granular en la música generativa La síntesis granular se ha convertido en una herramienta esencial para compositores y artistas que trabajan en música generativa, por su capacidad de producir sonidos complejos y en constante transformación. Algunas de las aplicaciones más destacadas de la síntesis granular en este ámbito incluyen: 1. Creación de texturas evolutivas: la capacidad de la síntesis granular para generar texturas densas y en constante cambio es ideal para la música generativa, donde la variación continua es una característica fundamental. Al manipular los parámetros de los granos, como su densidad, duración, o frecuencia, el compositor puede crear sonidos que evolucionan orgánicamente a lo largo del tiempo. 2. Manipulación temporal y espacial: la síntesis granular permite un control detallado sobre el tiempo y el espacio del sonido. Por ejemplo, los granos pueden ser dispersados en estéreo, creando paisajes sonoros envolventes. Asimismo, el tiempo puede ser estirado o comprimido, lo que permite explorar diferentes dimensiones temporales en la música generativa. 4.3. Aplicaciones de la síntesis granular en la música generativa 15 3. Interacción en tiempo real: En la música interactiva, la modificación de los parámetros en tiempo real es crucial. La síntesis granular, especialmente cuando se implementa en software o hardware especializado, permite a los artistas manipular los sonidos en vivo, respondiendo a otros elementos generativos o a la interacción del público. Esta flexibilidad es inestimable en la creación de obras generativas que deben adaptarse a entornos cambiantes o a la participación activa del oyente. 4. Transformación sonora: La síntesis granular es también útil para transformar sonidos grabados o sintetizados en formas nuevas. Por ejemplo, un simple sonido puede ser transformado en una textura completamente diferente al ser procesado de forma granular, lo que abre un vasto campo de posibilidades para la experimentación sonora en contextos generativos. Cap´ ıtulo 5 Selección del Software a Utilizar Existen miles de softwares orientados al desarrollo musical, entre DAWs (estaciones de trabajo de audio digital), plugins, programas stand-alone, etc. Aun concretando en música generativa y síntesis granular, la variedad es vastísima. En este capítulo vamos a hablar de los programas de música generativa y relacionados que hemos encontrado y estudiado a lo largo del desarrollo del proyecto, con cuáles nos hemos quedado, y cuáles finalmente hemos descartado y por qué. Este ha sido un proceso muy experimental, de prueba y error, hasta quedarnos con el que sería el entorno final. 5.1. Generación de la música Inicialmente tuvimos en consideración dos programas: Cecilia 5 y Emission Control 2, ambos centrados en la síntesis granular para la producción de texturas sonoras. También nos planteamos otras alternativas como: Nodal: [20] tiene un concepto muy interesante de creación musical pero, aparte de ser un software de pago, se alejaba completamente de la síntesis granular y no encajaba en nuestro sistema. Wotja: [21] es un sistema gratuito con formatos plugin e independiente muy potente de música generativa en vivo. PolyGAS: [22] un plugin de síntesis granular muy completo e interesante que intentamos hacer funcionar en la DAW gratuita Reaper, pero está desactualizado (la última versión está hecha para Windows XP) y se colgaba a los pocos segundos de encenderlo. The Mangle: [23] otro plugin de síntesis granular que, sobre el papel, parecía muy interesante, pero que no pudimos conseguir ya que también estaba desactualizado y su equipo creador, Sound Guru, ya no existe. Granulator III: [24] una posibilidad que manejamos fue implementar el sistema con una DAW que incluyera un plugin de síntesis granular. Más específi17 18 Capítulo 5. Selección del Software a Utilizar camente, el plugin “Granulator III ” para Ableton, pero este software requiere de una licencia de pago. 5.1.1. Cecilia 5 Cecilia 5 es “un entorno de procesamiento de señales de audio. [...] incluye módulos propios para efectos de sonido y síntesis” [25]. Está completamente escrito en Python y utiliza el motor de audio pyo, un potente módulo para procesar señales de audio. Figura 5.1: Interfaz de Cecilia 5 con el módulo UltimateGrainer Cecilia es un programa muy potente y completo, pero su complejidad jugaba en nuestra contra al ejecutarlo al mismo tiempo que la inferencia, dando problemas de rendimiento; por otra parte, la conexión mediante OSC no estaba del todo correctamente implementada ni documentada, y también sufría de problemas de rendimiento. 5.1.2. Emission Control 2 Emission Control 2 es un software desarrollado por Curtis Roads y otros colaboradores, diseñado para componer y manipular sonido usando síntesis granular en tiempo real. Este programa, escrito en C++, tiene un rendimiento mucho mejor cuando ejecutamos todo el conjunto del proyecto, por lo que decidimos centrarnos en él y explorar todo su potencial. Aunque requiere bastante ensayo y calibrado obtener sonidos y texturas agradables e interesantes con Emission, tras trabajar en profundidad con él y entender todos sus parámetros, nos dimos cuenta de que es un software muy potente y versátil. En la Figura 5.2 podemos ver su interfaz gráfica. Para entender los principales parámetros de Emission Control, vamos a hacer referencia a su manual (para mayor detalle, véase el mismo en la bibliografía [26]): 1. Grain Rate [0.1, 100]: Tasa de emisión de los granos por segundo. 5.1. Generación de la música 19 Figura 5.2: Interfaz de Emission Control 2 en funcionamiento 2. Asynchronicity [0, 1]: Grado de asincronía en la emisión de los granos. La densidad de los granos es la misma tanto si el flujo es sincrónico como asincrónico. En un flujo perfectamente sincrónico, los granos se siguen unos a otros en intervalos periódicos. Un flujo asincrónico se randomiza en el tiempo. 3. Intermittency [0, 1]: Grado de interrupción del flujo de granos, independientemente de si el flujo es sincrónico o asincrónico. Una alta intermitencia reduce la densidad de los granos. 4. Streams [1, 12]: Número de flujos paralelos de granos. Los granos de nuevos flujos se insertan entre los granos existentes. La densidad general de granos es un producto de la tasa de granos, la duración de los granos y el número de flujos. 5. Playback Rate [-2, +2]: Cambia la velocidad a la que cada grano reproduce el archivo de sonido fuente, lo que varía el tono y/o la dirección de lectura. 6. Filter Center [60, 5000]: Frecuencia central en hercios de un filtro pasobanda. Cada grano se filtra por separado. 7. Resonance [0, 1]: Ajusta el valor Q o la resonancia del filtro. A un valor de 1 genera una onda sinusoidal. 8. Sound File:Selecciona el archivo de sonido a granular. Se pueden cargar múltiples archivos de sonido y guardar presets de sonidos. Los usuarios pueden mover el deslizador para cambiar entre los archivos de sonido cargados. La selección del archivo también puede modularse mediante un LFO. 9. Scan Begin [0, 1]: Controla el punto de inicio en el búfer de sonido para comenzar la granulación. Es un valor relativo, donde 0 indica el inicio del archivo de sonido, 0.5 indica el punto medio y 1.0 indica el final, independientemente de la longitud del archivo de sonido seleccionado. 20 Capítulo 5. Selección del Software a Utilizar 10. Scan Range [-1, +1]: Determina qué longitud del archivo explorar. Un valor de 1 significa explorar todo el archivo. Un valor de 0 mantiene el escáner en el lugar del punto de inicio de la exploración. También se pueden establecer valores negativos para extender el rango a la izquierda del punto de inicio de la exploración. 11. Scan Speed [-2, +2]: Determina qué tan rápido se explora el archivo y en qué dirección. Esto es independiente del Playback Rate, que cambia el tono de los granos individuales. Puede ser 0, por ejemplo, en cuyo caso se repite un solo grano. Determina el cambio de tono y si el grano se lee hacia adelante o hacia atrás. 12. Grain Duration [0.01, 1000]: Controla la duración del grano en milisegundos. La duración mínima del grano ahora depende de la tasa de muestreo, que es 2000/Sample Rate. Por ejemplo, si la tasa de muestreo es 44.1 kHz, la duración mínima del grano es aproximadamente 0.045 ms. Si la tasa de muestreo es 96 kHz, la duración mínima del grano es aproximadamente 0.021 ms. 13. Envelope Shape [0, 1]: Determina la forma de la envolvente del grano. Con valor 0 esta tiene un ataque abrupto y decaimiento exponencial o expodec; en el medio toma forma de campana; con valor 1 es un expodec invertido. 14. Pan [-1, +1]: Posición espacial de los granos. -1 es izquierda. 15. Amplitude [-60, +24]: Ajusta la amplitud de salida en decibelios (dB). Todos estos parámetros pueden ser modulados en base a osciladores de baja frecuencia (LFOs). En la sección MODULATION CONTROLS se puede asignar el rango de esta modulación, y en la sección LFO CONTROLS se especifican los parámetros de los osciladores para seleccionar el tipo de modulación. Además, cabe destacar lo bien implementada que está en Emission Control la conexión con OSC y su fácil comprensión, como se puede observar en la Figura 5.3; esto nos permitió diseñar la arquitectura encargada de interactuar con todos sus parámetros, que explicaremos más adelante. Emission Control permite manejar mediante OSC todos los deslizadores, la carga de presets, iniciar/detener la grabación y modificar la carpeta y el nombre del fichero de salida de las grabaciones. En el menú de la figura 5.3 podemos especificar la dirección IP, el puerto y el tiempo de timeout de la conexión OSC; más abajo podemos asignar el address del mensaje (todo esto se explicará en el capítulo 7) a cada parámetro y, si lo necesitamos, mapear el valor recibido. Una de las características más destacables de este programa son los presets, en los que podemos guardar configuraciones específicas de parámetros; de esta manera, tenemos un mayor control sobre el resultado final, pudiendo almacenar múltiples configuraciones que sabemos que suenan bien y permitiendo al usuario final navegar entre ellas y aplicarles pequeñas variaciones. Emission también nos permite hacer 5.2. Software de enrutamiento de señal y efectos 21 Figura 5.3: Ventana de configuración de la conexión OSC en Emission Control 2 transiciones graduales entre estos presets, pudiendo especificar la duración (morph time) de las mismas. Para investigar Emission Control 2 más a fondo, se puede encontrar un manual en la descarga que hay disponible en su GitHub [27], o bien, de manera más resumida, se puede leer el comunicado de prensa disponible en la web oficial de Curtis Roads [28]. 5.2. Software de enrutamiento de señal y efectos Una posibilidad que mejora mucho el resultado sonoro es enlazar la salida de Emission Control a algún tipo de reverb/ecualizador para enriquecer el resultado final; para conseguir esto se utilizaron los siguientes programas y drivers: Pedalboard 2: este software es un host de plugins VST diseñado para uso en vivo. Está basado en el código “audio plugin host” de JUCE [29] y se maneja de forma modular e intuitiva como vemos en la figura 5.4; además, permite controlar los parámetros de estos plugins mediante mensajes OSC. OrilRiver: plugin con reverb y ecualizador de 3 bandas que permite simular la reverberación de una pequeña o gran habitación; esto añade textura y riqueza al sonido que creamos en Emission Control. En la Figura 5.5 podemos ver su interfaz. 22 Capítulo 5. Selección del Software a Utilizar Figura 5.4: Pedalboard 2 en uso, conectando entradas y salidas de audio Figura 5.5: Interfaz gráfica de OrilRiver VB-Cable: este driver es un dispositivo de audio virtual que funciona como cable de audio; es decir, conecta entradas y salidas de audio de manera virtual para poder entrelazar dispositivos de audio. De esta manera, la conexión es la siguiente: la salida de audio de Emission Control, quien genera el sonido, se conecta mediante VB-Cable a la entrada de Pedalboard; este conecta dicha entrada a OrilRiver, que aplica reverb al sonido y saca el audio modificado; finalmente, este audio se envía a la salida deseada del dispositivo (por ejemplo, los altavoces). Esto se puede ver más claramente en el esquema de la figura 5.6. 5.2. Software de enrutamiento de señal y efectos 23 Figura 5.6: Esquema del enrutamiento del audio 30 Capítulo 6. Inferencia y Entrenamiento de Gestos 1hparams = gesture_recognizer . HParams ( 2export_dir = " ../ models " , 3epochs = 30, 4learning_rate = 0.005 , 5batch_size = 32, 6lr_decay = 0.999 7) 8 9model_options = gesture_recognizer . ModelOptions ( 10 dropout_rate = 0.2, 11 layer_widths = [256 ,128 ,64] 12 ) 13 14 options = gesture_recognizer . GestureRecognizerOptions ( 15 hparams = hparams 16 ) 17 18 model = gesture_recognizer . GestureRecognizer . create ( 19 train_data = train_data , 20 validation_data = validation_data , 21 options = options 22 ) Figura 6.4: Configuración de MediaPipe Model Maker Precision:es la proporción de verdaderos positivos respecto al total de predicciones positivas (verdaderas y falsas) que realizó el modelo. Precision = T P T P +F P Recall: es la proporción de los verdaderos positivos que identificó correctamente el modelo en comparación con el total de casos que eran realmente positivos. Recall = T P T P +F N F1-Score:es la media armónica de la precisión y el recall. Esta media demuestra si hay un buen balance entre estas dos métricas. F1-Score = 2 ×Precision ×Recall Precision +Recall 6.3. Inferencia de gestos 31 Figura 6.5: Matriz de confusión Métrica Resultado Accuracy 0.98 Precision 0.99 Recall 0.98 F1-Score 0.99 Tabla 6.1: Resultados de las métricas Como podemos observar en la tabla 6.1, todos los resultados están por encima de 0.98, reflejando la robustez y fiabilidad del modelo para la clasificación de los gestos. Está equilibrado en su capacidad para identificar correctamente las clases positivas y minimizar los errores de predicción. 6.3. Inferencia de gestos En esta sección detallaremos cómo aplicamos las distintas herramientas que ofrece MediaPipe Task para aprovechar los resultados obtenidos del reconocimiento de los gestos. A su vez, expondremos una de principales clases que usa dicha herramienta y cómo esta transforma dichos resultados en lo que luego serán los mensajes. 32 Capítulo 6. Inferencia y Entrenamiento de Gestos 6.3.1. MediaPipe Task Entrando más en detalle en el framework, el cual dispone de gran cantidad de funciones, podemos destacar el procesamiento de imágenes de entrada, el umbral de puntuación y la lista de etiquetas permitidas que, en esencia, son las categorías que reconoce el modelo. Además, tiene múltiples parámetros que se pueden configurar para crear el “GestureRecognizer” [38], que es la herramienta con la que se hace la inferencia. A continuación, se muestran algunos de estos parámetros: running_mode: establece el modo de ejecución de la herramienta. Existen tres modos: •IMAGE: es el modo para entradas de una sola imagen. •VIDEO: es el modo para los fotogramas decodificados de un vídeo. •LIVE_STREAM : es el modo para una transmisión en vivo de entradas de datos. num_hands: cantidad máxima de manos que pueden ser detectadas. min_hand_detection_confidence: la puntuación de confianza mínima necesaria para la detección de la mano respecto al modelo de detección de la palma (si la puntuación de confianza supera este umbral, se considera que la mano ha sido detectada exitosamente en la imagen). min_hand_tracking_confidence: la puntuación de confianza mínima necesaria para que se considere exitoso el seguimiento de la mano. result_callback: configura el objeto de escucha para recibir los resultados de la clasificación de forma asíncrona. Solo se puede utilizar en el modo de ejecución LIVE_STREAM. 6.3.2. Inference class Esta clase es la principal encargada de la inferencia de los gestos, además de manejar los resultados de esta inferencia a tiempo real. Explicaremos paso por paso cómo se implementó el framework de MediaPipe Task y cómo se personalizó para este desarrollo. En la figura 6.6 se puede ver el fragmento de código utilizado para la creación del modelo de reconocimiento de gestos, junto con la función asociada al parámetro “result_callback”, la cual se explicará en detalle más adelante. Una vez configuramos el “GestureRecognizer” con la ayuda de OpenCV [39], se le van suministrando frames de la transmisión en vivo al modelo mientras este va recogiendo el resultado de manera asíncrona en la función “print_result”, que se aprecia en la figura 6.6 como parámetro de “result_callback”. La función “print_result” recibe el “GestureRecognizerResult” [40], que es donde se guardan los resultados de la inferencia como se muestra en la estructura de la 6.3. Inferencia de gestos 33 1options = GestureRecognizerOptions( 2base_options = BaseOptions( 3model_asset_path = 4" utils \ gesture_recognizer . task " 5), 6running_mode = VisionRunningMode . LIVE_STREAM , 7result_callback = self . print_result , 8num_hands = 2, 9min_hand_detection_confidence = 0.2 , 10 ) Figura 6.6: Configuración de GestureRecognizer MediaPipe Task figura 6.7 . Dichos resultados son la información recopilada del frame inferido, de la que se destaca la clasificación del gesto, la lateralidad, los landmarks normalizados respecto a la imagen y los landmarks sin normalizar. Esta información viene dada en forma de vectores, uno para cada mano detectada. 1mp. tasks .vision . GestureRecognizerResult ( 2gestures : 3List [List [ category_module . Category ]], 4 5handedness : 6List [List [ category_module . Category ]], 7 8hand_landmarks: 9List [List [ landmark_module . NormalizedLandmark ]], 10 hand_world_landmarks: 11 List [List [ landmark_module . Landmark ]] 12 ) Figura 6.7: Configuración de GestureRecognizer MediaPipe Task Ahora bien, para este proyecto debíamos enviar estos datos para traducirlos en los parámetros que afectarían a la creación de la música generativa. A continuación se explicarán uno por uno y cómo se consiguieron a partir de los resultados de la inferencia: 1. Gesto inferido: es el dato que se consigue de manera más directa. Es simplemente la categoría del gesto inferido; si bien, el “GestureRecognizerResult” da como resultado el nombre del gesto, a este le aplicamos una traducción numérica para sea más fácil de enviar. 2. Coordenadas X e Y: para estos datos se utilizan los landmarks normalizados. Estos, a través de una función, se traducen a las coordenadas reales del 34 Capítulo 6. Inferencia y Entrenamiento de Gestos frame capturado, y para simplificar solo se usa un punto de la mano detectada (en este caso, el noveno punto de referencia, véase la figura 6.2). 3. Gesto numérico: los gestos numéricos son generados de manera artificial usando las posiciones de los landmarks. Dichos gestos consisten en los números del uno al cinco (como se ve en la figura 6.8). Para conseguir esto, se utilizan los landmarks normalizados; estos, igual que en el apartado anterior, pasan por un serie de funciones, dando como resultado los puntos de referencia normalizados respecto al punto de la muñeca. Con dichos valores, se calculan las distancias entre varios puntos de interés (como lo son las puntas de los dedos) para determinar si se está realizando el gesto. 4. Lateralidad: este es otro dato que se consigue de manera directa. Aunque no se emplea en el mensaje, sí influye en dónde se envía, haciendo que los mismos tipos de datos se apliquen de manera diferente dependiendo de la mano. Figura 6.8: Gestos numéricos Cap´ ıtulo 7 Conexión OSC El protocolo “Open Sound Control” (OSC) [3] es una codificación de transporte de datos que fue desarrollado para la comunicación entre ordenadores, sintetizadores musicales y otros dispositivos multimedia. Tiene como ventajas la independencia del medio de transmisión y la flexibilidad para transportar cualquier tipo de dato. Principalmente se transmite utilizando el protocolo UDP. El formato del mensaje está compuesto por una cadena de bytes que se divide en tres partes: dirección, tipo de datos y contenido de los datos. Estas tres partes deben tener una longitud en bytes múltiplo de 4, para poder así controlar y mantener una lectura eficiente entre los distintos datos. La primera parte del mensaje OSC es la dirección. Esta consiste en una cadena que comienza con el cáracter “/”, que indica la jerarquía de navegación, seguido de la clave que indica por dónde el servidor va a enviar (dispatch) el mensaje. La segunda parte del mensaje empieza con el símbolo “,” seguido de una cadena compuesta de distintas letras. Cada una de estas letras identifica un tipo de dato que el mensaje transporta. Por último, la tercera parte del mensaje corresponde a los datos como tal. Estos van unos seguidos de otros, sin bytes de separación, como se observa en la figura 7.1 . 7.1. Envío de mensajes Del envío de mensajes se encarga principalmente la clase Sender usando la librería “python-osc” [41]. Esta librería permite crear de manera sencilla clientes UDP a los que se asignan una dirección ip y un puerto por donde se podrán mandar mensajes OSC. Así mismo, esta librería permite crear los mensajes con uno o varios argumentos y especificar el OSC-address que va a tener vinculado. En la figura 7.2 se muestran las address que utilizamos y en la 7.3 cómo se manda cada uno de los mensajes. Para evitar el ruido de los mensajes y no hacer cambios bruscos en la música, el Sender emite el mensaje cuando haya reconocido unas ciertas veces seguidas el gesto. De esta manera, evitamos el ruido de inferencias erróneas puntuales. Ahora 35 36 Capítulo 7. Conexión OSC Figura 7.1: Mensaje OSC de ejemplo 1def __init__ ( self ,ip , port ): 2self .client = udp_client . SimpleUDPClient (ip , port ) 3self.OSC_ADDRESS1 = "/ mediapipe / handsR " 4self.OSC_ADDRESS2 = "/ mediapipe / posR " 5self.OSC_ADDRESS3 = "/ mediapipe / handsL " 6self.OSC_ADDRESS4 = "/ mediapipe / posL " Figura 7.2: Address OSC utilizadas bien, en el caso de las coordenadas, implementamos una cola circular: en esta se calcula el promedio de todos los resultados obtenidos y es dicho resultado el que se envía, haciendo que el cambio sea mucho más progresivo. El envío de los mensajes, como se aprecia en la figura 7.2 , se hace a través de esas 4 OSC-Address. Como se ha comentado en capítulos anteriores, se usa la lateralidad de la mano para dividir los resultados en derecha e izquierda, teniendo así dos conjuntos de datos por cada mano: uno con los gestos (tanto inferidos como numéricos) y otro con las coordenadas de la mano. 7.2. El intermediario: JUCE 37 1def send_hands_left ( 2self , gest:int , numerics : int 3): 4msg = OscMessageBuilder ( address = 5self.OSC_ADDRESS3) 6msg . add_arg ( gest ) 7msg . add_arg ( numerics ) 8msg = msg. build () 9self . client . send ( msg ) Figura 7.3: Ejemplo de Sender 7.2. El intermediario: JUCE Llegados a cierto punto, nos dimos cuenta de que no era suficiente con enviar directamente los mensajes OSC del modelo a Emission Control y Pedalboard directamente: necesitábamos un intermediario capaz de procesar y reenviar correctamente los mensajes. Esto nos daría más libertad y control sobre cómo podrían afectar los gestos del usuario a los distintos parámetros que teníamos disponibles. Fue con este objetivo que comenzamos a trabajar con JUCE: “JUCE es un framework multiplataforma de código abierto escrito en C++ para crear aplicaciones de escritorio y móviles, incluyendo plugins de audio y hosts de plugins en múltiples formatos. [...] JUCE puede ser usado como herramienta de creación de proyectos mediante Projucer, que permite exportar proyectos para Xcode (macOS e iOS), Visual Studio, Android Studio y Makefiles de Linux, además de contener un editor de código fuente.”[42] JUCE posee un módulo creado específicamente para tratar con OSC, del cual nos aprovechamos para procesar esos mensajes, reformatearlos y reenviarlos a Emission Control y a Pedalboard (que actúan cada uno como un servidor distinto) según la mano, el gesto y los datos que estemos recibiendo. Este último proceso sucede gracias a la arquitectura que hemos programado para el procesamiento de mensajes. Esta arquitectura es robusta ante posibles falsos mensajes, errores de formato o valores fuera de rango. Para ello, se implementa un “juce::OSCReceiver::ListenerWithOSCAddress” que, al recibir un mensaje OSC, invoca el callback “oscMessageReceived”, que se puede ver en la figura 7.4. Es en esta función que, dependiendo del address OSC recibido, se toman los datos correspondientes y se llama al método “resend”. Este método, a su vez, es el que, según el dato recibido, envía el mensaje correspondiente a Emission Control o a Pedalboard. En las figuras 7.5 y 7.6 se pueden ver ejemplos de cómo se reenvían la posición y el gesto. También se puede ver cómo, en caso de error, se detiene el método y se lanza el mensaje correspondiente. 38 Capítulo 7. Conexión OSC 1void MainComponent :: oscMessageReceived (const juce :: OSCMessage & message ) { 2juce :: String error = ""; 3 4if ( message . getAddressPattern () == "/ mediapipe / handsL") { 5leftHand . gesture = message [0]. getInt32 (); 6leftHand . numeric = message [1]. getInt32 (); 7 8if (! resend ( fromAddress :: handsL , error )) 9showConnectionErrorMessage (error); 10 } 11 else if ( message . getAddressPattern () == "/ mediapipe / handsR ") { 12 rightHand . gesture = message [0]. getInt32 (); 13 rightHand . numeric = message [1]. getInt32 (); 14 15 if (! resend ( fromAddress :: handsR , error )) 16 showConnectionErrorMessage (error); 17 } 18 else if ( message . getAddressPattern () == "/ mediapipe / posL ") { 19 leftHand .x = message [0]. getInt32 (); 20 leftHand .y = message [1]. getInt32 (); 21 22 if (! resend ( fromAddress :: posL , error )) 23 showConnectionErrorMessage (error); 24 } 25 else if ( message . getAddressPattern () == "/ mediapipe / posR ") { 26 rightHand .x = message [0]. getInt32 (); 27 rightHand .y = message [1]. getInt32 (); 28 29 if (! resend ( fromAddress :: posR , error )) 30 showConnectionErrorMessage (error); 31 } 32 else {} // Address unknown 33 } Figura 7.4: Método oscMessageReceived del código de JUCE 7.2. El intermediario: JUCE 39 1case MainComponent :: fromAddress :: handsL : 2MainComponent::currentGesture.first = 3( MainComponent :: handGesture ) leftHand . gesture ; 4 5switch (( MainComponent :: handGesture ) 6leftHand . gesture ) 7{ 8case MainComponent :: handGesture :: none: 9if ( leftHand . numeric > 0 && 10 leftHand . numeric <= 5) 11 { 12 if (! senderEC2 . send ("/juce/EC2/ soundFile ", (float) leftHand . numeric )) 13 { 14 e="Error : could not send soundFile 15 to Emission Control 2"; 16 return false ; 17 } 18 else {} // Numeric unknown or none 19 } 20 21 break; 22 23 (...) 24 25 case MainComponent :: handGesture :: thumbDown : 26 if (! senderOR .send ("/ juce /OR/ bypassWet ", 27 1.0 f)) 28 { 29 e="Error : could not send bypassDry on 30 to OrilRiver "; 31 return false ; 32 } 33 34 break; 35 36 (...) Figura 7.5: Fragmento del método resend, con ejemplo del reenvío de los gestos 46 Capítulo 9. Conclusiones y Trabajo Futuro a la que se sometía el equipo que se nos prestó, ya que este tenía que mantener en funcionamiento distintos programas pesados (como lo es Emission Control) a la vez que la inferencia. Por otro lado, se nos presentaron distintos problemas de compatibilidad con respecto a varias librerías que utiliza MediaPipe y el sistema operativo empleado (Windows 10), con lo que pasamos semanas estancados en varios pasos del desarrollo. A su vez, MediaPipe no ofrece ciertas características en el entorno de Windows que nos hubieran parecido interesantes. También, debido a que Emission Control es un granulador puro sin ningún tipo de añadido, es complicado obtener un sonido rico y agradable. Esto nos llevó a añadir otros efectos como una reverb y un ecualizador, además de un concienzudo trabajo de aprendizaje de cada parámetro y sus efectos en el sonido final. Por último, dado que utilizamos múltiples programas con bases muy diferentes, encontramos un alto grado de complejidad en el proceso de comunicarlos todos. Esto se encontró tanto en el envío de los datos mediante OSC, ya que cada software implementa estos mensajes de manera diferente, como en el enrutamiento de la señal de audio entre los programas encargados del sonido. Pese a las dificultades y el tiempo de trabajo, logramos cumplir los objetivos establecidos, consiguiendo mediante la interacción física y los gestos un resultado musical en directo. 9.2. Trabajo Futuro Entre otras cosas, somos conscientes del potencial desaprovechado de JUCE. Esta es una herramienta extremadamente potente y llena de posibilidades; el uso que le hemos dado ha sido ínfimo en comparación y creemos que, por ejemplo, sería posible incorporar en el intermediario un host de plugins que sustituya por completo Pedalboard 2 y VB-Cable. Respecto a la interfaz de la instalación, sería viable implementar una GUI o algún elemento visual que resulte refrescante y aliente al usuario a seguir probando e interactuando con la instalación. Otra vía en la que el trabajo se podría expandir sería realizar un estudio de la instalación en el que se pudiera preguntar qué tan interactiva o intuitiva es esta, midiendo si los gestos son fáciles de asociar al parámetro musical que modifican o si los cambios de los parámetros musicales son apreciados por los usuarios. Todo este estudio involucraría recoger el “feedback” de cada persona que lo utilice. Chapter 10 Introduction “It’s not the destination that matters. It’s the change of scene.” — Brian Eno Among its almost infinite fields and applications, in today’s digital era computer science is strongly linked to art in all its disciplines; even more so we have seen this in recent years, witnessing how artificial intelligence is capable of creating artistic works that some would consider worthy of a human being. Without delving into this complicated terrain, for decades now digital technology has taken root in one of the world’s seven fine arts: music. So much so that technology is fundamental from its creation (sound creation, recording, composition, production...) to its consumption (diffusion, sale, modification, reproduction...). Specifically, where the use of digital technology stands out the most is in the genre of electronic music, which is based on the use of instruments and digital technology for its production and interpretation. Focusing definitively on the key of this project, let’s introduce the cornerstone of the project: generative music [1]. Without going too much into detail, as we will dedicate a whole chapter to it later, generative music is practically an analogy to computer science: the key idea is that the author creates a series of rules, we could say that he “programs” them, and it is in its reproduction that, following these rules, the work is created; this work, as we will see, can be different and unique each time it is reproduced, which gives a greater richness and genius to this concept of electronic music. There are thousands of techniques to create this generative music, one of them being granular synthesis [2], which we will develop in depth later. In short, the key to this technique is to create acoustic textures or events based on short grains of sound. By varying the duration and density of these grains it is possible to create complex sounds that evolve dynamically. Returning to the topic of artificial intelligence, nowadays generative AIs are on everyone’s lips, replacing the human creative aspect of art, but that is not the only 47 48 Chapter 10. Introduction approach that can be given to a tool as powerful as a neural network (again, it will have its own chapter later on). A very interesting way to implement this technology in the musical realm is to train a model so that a user can interact with his gestures with a system that, in turn, is the one that creates this generative music. Thus, instead of using artificial intelligence to replace the human, it can be used as a tool for the human to generate art. With all this on the table, how does one communicate an inference model with a granular synthesizer? Well, in the world of digital music there is a communication protocol almost as widely used as MIDI which is the Open Sound Control (OSC) [3] protocol. This is a lightweight, flexible, very accurate and low latency communication method geared towards real-time music performance. It has its own format and encoding, to which we will devote a chapter later. 10.1. Motivation The fundamental idea in this project is that the final user, without any previous musical knowledge, will be able to interact intuitively with a musical system with presets and pre-configured sounds that can vary and evolve. In this way, having control over the final result and its limits (to avoid, to a certain extent, silences or unpleasant and strident sounds), the user will have certain degrees of freedom for the generation of the music, allowing him to move in a limited range. The sound created, however, will be somewhat fluid and without a clear structure; we are not looking for a piece with a fixed tempo or a well-defined score, but something closer to ambient music, creating a constant sound texture and atmosphere to which the user will apply small variations with his gestures. In the end, we want an intuitive interactive installation that creates an ambient and cinematic music, so that the user, without needing to know what is changing, can listen to it and feel part of the work. In this project we seek to introduce inexperienced users to the field of ambient music, offering them the possibility of creating with the support of Artificial Intelligence, not as a replacement, but as a creative resource. The idea is to unite the technical aspect of programming and model training with the experimental and artistic side of music computing. We also seek to explore how the integration of multiple tools can generate compact and easily portable results. 10.2. Project Objectives The objectives of the project are: Train a robust model able to recognize gestures. Tearch and exploit a music generation software based on the granular synthesis technique. 10.3. Workplan 49 Consider the interaction of the user, by means of hand gestures, with all the possible musical parameters. Develop a program that uses MediaPipe to detect hand gestures and hand position. Establish a client-server connection, using the OSC protocol, between the inference program and the environment in charge of the generative music. To enable an interactive installation in the main hall of the Faculty of Computer Science of the Complutense University of Madrid. 10.3. Workplan Once the main objectives of the project, as seen in the previous section, were established, a work plan was developed to achieve them in a certain order. 10.3.1. Gesture Dataset Research To develop this project, there was a research in which we reviewed several hand gesture datasets from different specialized sites (such as Kaggle [5] or HuggingFace [6]). We took into consideration several notions, such as the number of images or the gestures themselves. 10.3.2. Exploring the creation of the model Once we chose the Dataset, we proceeded to investigate which tools will be used for the creation of the model, which neural network architectures we favor or, even, if a pre-trained model can be used to facilitate the work. 10.3.3. Exploration of granulators At the beginning of the project there was a very experimental process of searching, studying and discarding different external software until we found the most reliable and the one that best suited our needs; this whole process has its own chapter below. 10.3.4. Experimentation with the musical environment Once we focused on the program we would finally stay with, an experimental and creative process of studying the program, understanding the different parameters, exploiting its possibilities and generating rich and interesting sound textures took place again. We also began to investigate how OSC receives messages. 50 Chapter 10. Introduction 10.3.5. Development of the recognition program Once we had the model trained, we had to create a program that would recognize the gestures with the help provided by MediaPipe. This development must be scalable and with enough performance to have a low latency so that the user can have a smooth interactive experience. 10.3.6. Definition of the messages At this point, we had to specify the format of the OSC messages and how each gesture would interact with the different parameters of the granulator. 10.3.7. Establishing the connection via OSC Knowing the format of the messages to be sent, a Client-Server structure must be developed, so that the gesture recognition program sends the results of the inference with the agreed format to a server that will redirect these messages to the programs that generate the music. 10.3.8. Refinement of the gestural interaction Once we had the complete system designed, we had to polish all its elements: that the gesture inference was accurate and consistent, that there were no latency or performance problems during execution, that the gestures were intuitive and affected notable parameters, and that the resulting music was pleasant and interesting. 10.4. Document structure This section will show how the document is divided and give a brief explanation of what each chapter consists of. Chapter 1 - Introduction: This chapter explains the motivation for the project, the development objectives, the work plan that was followed, and finally, the structure of the document. Chapter 2 - State of the Art: reviews several previous projects related to fundamental elements of this work, such as gesture detection, generative music and interactive music installations themselves. Chapter 3 - What is Generative Music?: This chapter provides an extensive explanation of what generative music is, from its origins and popularization to methods, applications, and examples. Chapter 4 - Granular Synthesis: defines the technique of granular synthesis and its various applications in the field of generative music. 10.4. Document structure 51 Chapter 5 - Software Selection: This chapter presents one of the experimental stages of the project, where different independent software tools used in the installation were tested. Chapter 6 - Gesture Inference and Training: The tools responsible for gesture inference are presented, explaining how the results of these inferences are applied, and how the model used for hand gesture detection was trained. Chapter 7 - OSC Connection: This chapter explains the OSC protocol and its use for sending/receiving various parameters. Chapter 8 - Musical Installation: The complete installation of this project is defined, bringing together everything explained previously. Chapter 9 - Conclusions and Future Work: summarises the final outcome of the project, which objectives were accomplished, which were not, and the possible future work it leaves for the future. Chapter 11 Conclusions and Future Work To conclude, we will review what we have achieved throughout this project, the objectives we have reached and what remains as possible future work. Thanks to the various programmes we have used, we have managed to create a generative ambient music based on granular synthesis that, with a firm base of sound environment, varies thanks to a user’s interaction and hand gestures. In doing so, we have been able to remove the random element of generative music and replace it with human interaction; in this way, each use of the project will remain unique, not because of randomness, but because of the natural and spontaneous reaction of each person. With all this, and thanks to the equipment offered by our tutors, we have installed the whole system in a compact machine in the Faculty of Computer Science, with the possibility of being displayed in the main hall. This way, whoever passes by and has a moment, can enjoy creating music. In conclusion, we have succeeded in designing a complete interactive music system that, with good documentation, can be installed on a minimally powerful machine almost anywhere. We have achieved this by creating our own software, written in different environments and languages, in conjunction with existing programmes and by shaping the interaction between all these independent elements. Although it is always at the aesthetic discretion of each user and each listener, we consider that we have achieved a final result of very good sound quality, uniting techniques and achieving very rich, varied and unique sound textures. All in all, we have been able to investigate and explore the union of the technical discipline of computing with the art of music, being able to bring it closer to a user who, without needing to have extensive knowledge of either area, can enjoy and feel involved in the sound which, in the end, is in part their creation. 11.1. Difficulties One of the main difficulties in this development was the latency with which gesture recognition was performed. This was largely due to the high load on the equipment we borrowed, as it had to keep several heavy programs (such as Emission 53 54 Chapter 11. Conclusions and Future Work Control) running at the same time as the inference. On the other hand, we had different compatibility problems with respect to several libraries that MediaPipe uses and the operating system used (Windows 10), so we spent weeks stuck in several steps of the development. At the same time, MediaPipe does not offer certain features in the Windows environment that we would have found interesting. Furthermore, since Emission Control is a pure granulator without any additives, it is difficult to get a nice, rich sound. This led us to add other effects such as a reverb and an EQ, plus a lot of painstaking work to learn each parameter and its effect on the final sound. Finally, due to the fact that we used multiple programs with very different bases, we found a high degree of complexity in the process of communicating them all. This was found both in the sending of the data via OSC, as each software implements these messages differently, and in the routing of the audio signal between the programs in charge of the sound. Despite the difficulties and the time involved, we managed to achieve the established objectives, achieving a live performance through physical interaction and gestures. 11.2. Future Work Among other things, we are aware of the untapped potential of JUCE. This is an extremely powerful tool and full of possibilities; the use we have made of it has been tiny in comparison and we believe that, for example, it would be possible to incorporate a plug-in host in the intermediary to completely replace Pedalboard 2 and VB-Cable. Regarding the interface of the installation, it would be feasible to implement a GUI or some visual element that is refreshing and encourages the user to continue testing and interacting with the installation. Another way in which the work could be expanded would be to conduct a study of the installation in which one could ask how interactive or intuitive the installation is, measuring if the gestures are easy to associate with the musical parameter they modify or if the changes of the musical parameters are appreciated by the users. This whole study would involve collecting “feedback” from each person using it. Contribuciones Personales Desde un inicio tuvimos claro que este proyecto tenía una división muy clara: el modelo encargado de leer los gestos y el conjunto de programas encargado de crear la música, con la unión entre ambos de la conexión OSC. Gracias a esto, fuimos capaces de dividirnos el trabajo entre ambos desde el principio, de manera que pudiéramos trabajar en paralelo, sin bloquearnos el avance el uno al otro. A continuación especificaremos cada uno cuáles fueron nuestras contribuciones personales a lo largo del desarrollo del proyecto. Samuel Asanza Mesa Me enfoqué principalmente en el apartado de informática musical, pues había cursado el año anterior dicha optativa y quería aplicar los conocimientos la misma. De esta manera, y manteniéndome principalmente en contacto con el tutor Jaime Sánchez, comencé a recuperar el material sobre música generativa y síntesis granular. Inicialmente estudié y probé los granuladores Cecilia 5 y Emission Control 2, probando distintos sonidos de entrada y tocando los parámetros. Uno de los principales objetivos que tenía en mente era el de encontrar los límites donde cada parámetro hacía que el sonido generado fuera desagradable. Además del apartado creativo, comencé a informarme sobre OSC e investigar cómo enviar estos mensajes a cada granulador, pues cada uno tiene implementado este protocolo de una manera diferente. En un inicio dejé de lado Emission Control para centrarme en Cecilia, ya que este granulador genera un sonido agradable e interesante sin mucho esfuerzo, pues incluye más efectos aparte de granulación pura. Por contra, me di cuenta de que Cecilia, al ser más complejo, presentaba problemas de rendimiento. Además, cuando comencé a estructurar la comunicación OSC, vi que la aplicación de este protocolo en Cecilia era realmente tediosa, ya que está mal implementado y vagamente documentado, por lo que decidí buscar alternativas. Entre estas alternativas encontré las que hemos expuesto en el capítulo 5. De 55