Conseguí este enlace a un software de pedal de efectos de guitarra, y me ganó la curiosidad y decidí reconstruirlo con el material que tengo a mano. El repositorio contiene código para correr un procesador de efectos de sonido de baja latencia (léase, efectos de sonido en tiempo real).
El código está escrito en C++, usando SDL2 para despliegue visual, RtAudio para interactuar con la salida de audio y crow para un servidor web que presenta la interfaz gráfica de los controles del pedal.
El material que utilicé: un Raspberry Pi 3 montado en una pantalla táctil de element14, un breadboard para montar los botones que se conectan al Raspberry Pi por el puerto GPIO, y un dispositivo de sonido con puerto de micrófono y de salida que se conecta por puerto USB. Es también la primera oportunidad que tuve de probar la pantalla táctil.
El proceso para comenzar a utilizar la pantalla no tuvo contratiempos: se atornilla el Raspberry Pi detrás de la pantalla, se conectan por un puerto especializado, y utiliza el mismo enchufe oficial del Raspberry Pi, que provee suficiente energía para ambos componentes. El Raspberry Pi en forma de tableta es un dispositivo bien interesante, aunque el setup actual está dado para mantenerlo conectado a un enchufe y no a una batería. Igual conecté un teclado porque la vida es muy corta para usar el teclado tactil.
Después de haber comprobado que la pantalla funciona, proseguimos a compilar e instalar GuitarEffects. El procedimiento está razonablemente bien definido en el readme del proyecto. Esto es mayormente instalar las dependencias con apt, y luego compilar a traves de configure, make y make install.
El único comentario que tengo sobre el proceso: la instalación de RtAudio funcionó prácticamente fuera de caja (sin pasar opciones extra). Sin embargo, tuve un mensaje de error cuando intentaba hacer configure: No known system type found for realtime support!. Para resolver esto tuve que instalar el paquete de desarrolladores de ALSA, sudo apt-get install libasound2-dev, y luego el proceso continuó sin más errores.
Una vez todo compilado, corrí sudo ../bin/server desde el directorio web del repositorio. En este momento el programa no pudo determinar cuál iba a ser el dispositivo de audio que iba a utilizar, y lo preguntó por el terminal. Una vez seleccionado mi dispositivo de sonido, el programa abre una ventana que muestra la onda de audio en tiempo real.
El programa sirve una página web que ofrece los controles completos del pedal. Se puede abrir dentro del propio Raspberry Pi o desde otro dispositivo en la misma red.
Lo que queda es conectar un instrumento, unas cornetas y comenzar a tocar.
Decidí usar el Raspberry Pi 3 porque el 4 que recientemente adquirí pasó a ser mi servidor Samba de archivos, reemplazando el viejo RPi 3. Creo que la potencia del 4 me hizo falta, pues noté bastante crujido y popping, seña de que el desempeño no es suficiente. Hay maneras de configurar el Pi para mejorar el desempeño del audio en tiempo real, incluyendo desactivar servicios como networking. Esto en particular para este proyecto no es una opción dado que corre un servidor web.
Los botones no me funcionaron cómo lo declara el readme del proyecto. Sin embargo, esto fue algo a lo que no le presté mucha atención dado que la interfaz web me entretuvo suficientemente. El pedal al momento ofrece una cantidad de efectos interesantes: autowah, filtros de paso alto y paso bajo, flanger, fuzz, delay, distorsión, compresor, reverberación, looper, entre otros más.
Como experimento me pareció muy interesante, y es un proyecto sólido con mucho potencial. Algunas cosas que hubiese hecho con un poco más de tiempo:
Hacer funcionar los botones: la documentación no deja claro qué hacen específicamente, así que tampoco vi la necesidad de hacerlos funcionar
Mejorar el desempeño de audio en tiempo real: el artículo que enlacé anteriormente tiene buenas sugerencias. Mi setup no incluye ventilador, así que no quise lidiar con overclocking. La interfaz web presenta la temperatura del sistema, y no varió en la hora que estuve tocando. Sería cuestión de leer y evaluar la factibilidad de cada sugerencia
Video de RootPump como fue entregado en el Caracas Game Jam 2023
Un Caracas Game Jam más, otro juego hecho, otro postmortem. Estuve casi a punto de escoger PICO-8 nuevamente, pero en un arranque de iluminación decidí darle oportunidad a una herramienta que tenía tiempo queriendo usar: Godot Engine. Godot se ha popularizado en el Global Game Jam como una alternativa a los notorios Unity y Unreal Engine, y al ser un proyecto de código abierto, ha atraído a un segmento bien particular de los desarrolladores de videojuegos. RootPump (entrada en el Global Game Jam) fue el resultado de este año, y la experiencia me permitió formarme algunas opiniones acerca de Godot. El código fuente del juego está en GitHub.
Para comenzar a usar Godot basta con bajar el ejecutable de su página de descargas, la versión 3.5 estable que es la más reciente al momento. Conocía abstractamente que Godot tenía soporte para GDScript, su lenguaje de scripting parecido a Python, y C#. Estoy familiarizado bastante con C# así que me fui por la opción de Godot con soporte para este lenguaje. Con Visual Studio Code ya previamente en mi máquina, instalé las extensiones godot-tools y C# Tools for Godot para facilitar el desarrollo. Durante el evento, cloné el repositorio de código fuente de Godot y esto me permitió navegar en el código desde mi proyecto y resolver muchísimas dudas.
La documentación oficial de Godot es bastante útil. No sólo contiene referencia al código, sino que también tiene artículos para ayudar a implementar lo que tengas en mente. Sin embargo, la documentación oficial generada sólo incluye la referencia a GDScript. La interfaz en C# está documentada en el código, así que es cuestión de generarla para tener una referencia igual de buena que la de GDScript, y paulloz ha tenido la cortesía de generar esta documentación, lo cual fue clave para entender el motor y entender las diferencias con GDScript. Sería bueno que esta referencia estuviese incluída en la documentación oficial si Godot sigue manteniendo su interfaz en este lenguaje.
Concebí RootPump como un juego de ritmo en el que las raíces de una planta crecen de acuerdo a cómo el jugador lleve el ritmo de una canción. Idealmente el gameplay del juego se llevaría a cabo con un solo botón. Decidí que dibujaría los gráficos con cualquiera que fuese la interfaz de código para dibujar en 2D en Godot (al momento lo desconocía), y que utilizaría la interfaz para reproducir audio pre-grabado (también lo desconocía).
Fue entonces una sorpresa agradable conseguirme con un sistema para componer escenas que me es familiar: en Godot una escena es un archivo que contiene un árbol de nodos Node2D. De esa manera, es posible obtener algún nodo a partir de un string (e.g. “Cosa1/Cosa2” para obtener el nodo llamado Cosa2 anidado en Cosa1). Es posible conectar un nodo con un script, y así es posible escribir código para ese nodo. Y así fue mayormente mi ciclo de desarrollo: usé el editor para añadir algunos nodos básicos, poner los elementos de las pantallas, y de resto pasé la mayor parte del tiempo en VSCode escribiendo código para luego probar los cambios en el editor.
Godot tiene una buena cantidad de rutinas matemáticas (Math2f) específicas para videojuegos y no pasé tiempo reimplementando esa funcionalidad. Si ya sabes lo que quieres hacer, todo está a la mano. Godot también ofrece una implementación del patrón observable llamado Signals, en el que es posible que los objetos interesados estén informados cuando ocurre un evento. Esto forma parte de Node2D, así que es muy fácil integrarlo. Sin embargo, en la implementación de mi juego hice varias cosas que no descendían de Node2D y no me fue posible usar las señales.
El sistema de input de Godot me gusta. Godot tiene un mapa abstracto de acciones, y a cada acción se le asocia un botón (o tecla, o acción del control), y luego en código se comprueba si esa acción está presionada, o “ha sido apenas presionada” (para acciones que solo requieren comprobar la primera vez que pasa en un frame).
Godot tiene un sistema de plugins para aumentar la funcionalidad del editor. Solo tuve la oportunidad de probar un plugin, el de git para manejar el versionamiento. Es un buen plugin, provee una interfaz gráfica para git, pero nada que TortoiseGit no ofreciese ya.
La otra agradable sorpresa fue conseguirme con una interfaz de audio bastante buena. Es posible tener varios canales de audio (Audio Buses, se llama el concepto), a los cuales es posible aplicarle efectos de sonido separadamente. Godot incluye también una sección que describe cómo sincronizar el audio con el juego lo cual me cayó de perlas y me ahorró mucho tiempo. La música la hice con Ableton Live, pero realmente no le presté atención, así que me fui por lo más básico. Finalizada la música, exporté los 3 stems a MP3 por separado, y en el juego se escuchan los 3 canales simultáneamente. Me quedó la curiosidad de todas las cosas que se pueden hacer con este setup.
Finalmente aprendí cómo hacer builds de mi juego, hasta entonces sólo había probado directamente dentro del editor. Godot tiene templates para exportar, uno por cada plataforma a la que puedes hacer un build (Windows, Mac, Web, etc.). Esto es una descarga separada que se inicia dentro del mismo editor. Desde el principio había considerado hacer RootPump para Windows, pero definitivamente tenía la curiosidad de ver cómo se comportaba el juego en web. Lamentablemente, el juego se tranca como a los 3 segundos de iniciar la ronda, y creo que es por el setup del audio que hice. Creo que hace falta ser más cuidadoso para exportar a Web, y es algo que vale la pena hacer con más calma, sin la presión de un game jam. Gracias a Edmundo que probó hacer el build en Mac: funciona bien salvo que el build pide permisos para usar el micrófono, y esto está aparentemente cableado en la presente versión de Godot.
El tiempo al final se me hizo corto para implementar el mínimo que esperaba al término del evento. En efecto tengo un árbol que crece, un pulso que se mueve a cierto ritmo, y un mecanismo para comprobar si el jugador va al ritmo de la canción que suena. Los dos mecanismos no están conectados, lamentablemente. Me hubiese gustado que el jugador tuviese mayor control de la dirección del pulso, y tal vez el control hubiese necesitado una dirección para mover el pulso.
Al final, las limitaciones fueron de tiempo, y siento que la herramienta trabajó conmigo, y no en contra mío. Escogería Godot nuevamente para un próximo proyecto.
En noviembre del año pasado hubo grandes cambios en el Tuiter. Desde entonces había querido dejar por escrito algunas opiniones, y aunque ya era evidente lo que iba a pasar, no dolió menos cuando cada cambio se hizo realidad. Este post es más bien un conjunto de pensamientos alrededor de lo que fue Twitter, y un poco de cuáles serán los próximos pasos para mí.
Desde 2007 Twitter para mí fue una plaza pública. Al principio mi comunidad eran los blogueros venezolanos con los que compartía mis posts en El Chigüire Literario. En esa época éramos pocos, lo que nos permitía ser mucho más francos. La intervención del gobierno venezolano en los medios significó que muchos vieron en Twitter el medio donde nos podíamos enterar de lo que estaba pasando. Twitter pasó de ser una mera curiosidad a un lugar importante en el discurso diario. En la plaza pública ya no estábamos sólo unos pocos: pasamos a ser muchos. Y con una masa crítica llegó la viralidad.
La viralidad implica que un mensaje bien puesto puede llegar lejísimos, pero también implica escribir con una mentalidad de que potencialmente cientos de miles de personas de pueden leer. No solamente leer, sino responderte de vuelta. Twitter realmente nunca tuvo herramientas efectivas para controlar una situación así. No todo el mundo tiene la preparación mental adecuada para encontrarse en una situación así. Ser virales no nos pasa en el mundo físico. Leer lo bueno y lo malo puede ser un golpe mental muy duro.
Sin embargo, creo que hice de ese espacio lo mejor que pude. Conocí gente maravillosa, gente no tan maravillosa, conseguí empleo, conecté con gente a las que considero mis amigos, aunque la distancia física no nos haga vernos las caras día a dia.
He estado mucho tiempo online, quizás demasiado. No es la primera vez que me encuentro migrando de red social. Estuve en redes sociales previo a Twitter (te extraño Pare o None). En los inicios de Twitter, cuando se caía a cada rato, compartí un poco en Plurk (al día de hoy un nombre que me sigue pareciendo horroroso). Creo que la lección más importante en todo esto es la importancia de poder preservar tus relaciones. Esto lo saben las redes sociales: por eso hay barreras tan altas cuando intentas migrar. La red social más valiosa es aquella donde está la gente que conoces y con la que charlas. Así, todas las redes sociales tratan en lo posible de mantenerte adentro. Twitter tal vez ha sido la que fue más boleta al prohibir por un rato enlazar a otras plataformas, pero todas en mayor o menor medida son jardines amurallados.
Quizás por esto es que soy insistente en seguir manteniendo una página personal. Aquí no hay mucho más que unos textos hospedados en un servidor. Desearía que no fuese necesario tanto conocimiento técnico para mantener algo así (¿tal vez te puedo tentar a escribir desde un templete como Zonelets y hospedarlo en Neocities?). Tampoco permite mucha interactividad, a lo sumo que me escribas por email (tengo la lista de correos de El Chigüire Literario en la cual escribo muy raramente cuando hay posts nuevos).
Y así llegamos a Mastodon, y al Fediverso en general. Mastodon emula muchas funcionalidades de Twitter, pero implementa un protocolo llamado ActivityPub. ActivityPub permite que cualquiera(asterisco) pueda hospedar una comunidad y compartir los posts de esa comunidad con otras comunidades. Mastodon es una comunidad que se parece a Twitter, pero hay otras comunidades que se parecen a Instagram, como las comunidades que usan Pixelfed.
La idea de la federación (y el Fediverso) es que tú te puedes unir a cualquier comunidad (o servidor, o instancia, como lo quieras llamar), y de ahí puedes seguir a otras cuentas, independientemente de la comunidad donde estén. Como el correo electrónico. En tu comunidad tienes entonces al menos 3 timelines: el timeline personal, compuesto de las cuentas a las que sigues, el timeline local, con una selección automatizada de las cuentas de tu comunidad, y el timeline federado, que es una selección del agregado de cuentas de otras comunidades que seguimos localmente.
El asterisco que puse en “cualquiera puede hospedar una comunidad” es porque si hospedar unos archivos en un servidor web ya es una limitante para mucha gente, correr una comunidad de Mastodon es otro nivel. Yo en algún momento había considerado correr mi propia instancia para hospedar mi cuenta y la de mis bots, pero la barrera económica y de tiempo que necesito para mantenerlo me hizo reconsiderar esa opción. Incluso con opciones relativamente económicas para una instancia administrada por una empresa, hay muchas cosas que no entiendo del concepto de “federación” y que no quiero llevarme golpes con mi cuenta principal.
Como en la vida, hay servidores de Mastodon que son como ciudades, y otras que son más bien pueblos pequeños. El servidor donde estoy actualmente, mastodon.social, es el servidor que mantienen los desarrolladores de Mastodon. Dado que es una de las primeras instancias, y dado lo dificil que ha sido separar el concepto de Mastodon, el software, de Mastodon, la comunidad, es un servidor que creció desmesuradamente durante el cambio de gerencia en Tuiter.
Así que hay gente que prefiere servidores más pequeños y más específicos, como un servidor para la gente de infosec, otro para desarrolladores de videojuegos, otro para gente queer trabajando en tecnología, etc., etc. La federación en teoría permite que podamos seguirnos y leernos sin importar en qué servidor estemos. Digo en teoría porque así como uno puede bloquear cuentas que no te gusten, los servidores pueden bloquear a otros servidores, y es ahí cuando el merengue se complica.
Una de las bondades de Twitter es que con la cantidad de gente que atrajo logró integrar una gran cantidad de comunidades: académicos, profesionales, artistas, y demás. Perder Twitter implica que esa Torre de Babel que teníamos de comunidades interconectadas se va a perder. No todo el mundo quiere migrar a Mastodon. Se ha hecho más complicado exportar tu red de contactos de Twitter desde que cerraron el API para las aplicaciones que hacían esto.
De todas maneras, creo que vale la pena prestarle atención a Mastodon en los años venideros. Como alguien que ha creído siempre en la web abierta, estos espacios tienen que ocuparse para ser defendido. De otra manera se pierden. En joinmastodon.org hay una selección grande de comunidades a las que te puedes unir. Espero que te pueda ver por allá.
Había pensado en sacar un álbum este año, pero eso no pasó. La vida pasó. Sin embargo, salieron 35 sketches de canciones este año. Los Tuesday Tunesdays siguen adelante, aunque este año ya se puede notar el impacto del retorno (si así se puede llamar) a la normalidad.
Comencé a usar Chordpro recientemente después de haber estado usando por largo rato Microsoft Word y Chordette para escribir tabs de canciones. Estoy muy contento con los resultados. Sin embargo, aunque la documentación de Chordpro es buena, no tiene un buen tutorial. Tuve que buscar mucho y experimentar para llegar al punto donde estoy contento, y creo que debió ser más simple. Escribí algunas notas sobre cómo llegué a ese punto, con la esperanza de que a otros les pueda ser útil. Actualmente asume que conoces Linux, o que al menos estás familiarizado con las herramientas de línea de comando.
English
Español
