SimusPlayer y el regreso a un antiguo proyecto

Hace una buen tiempo he estado viendo videos de Phils Computer Lab en donde muestra distintas tarjetas de sonido antiguas, comparando como suenan los archivos MIDI en cada una de ellas, y además de esos videos ha hecho algunos experimentos interesantes como simular un módulo MIDI externo usando un tablet conectado al PC que corre los juegos. En todos sus experimentos existe un factor común, que es un reproductor MIDI para Windows que tiene una interfaz de usuario muy funcional y al mismo tiempo muy atractiva para mí, el SoundFont MIDI player.

Todo lo que viene a continuación comenzó con la pregunta «y habrá algo así para Linux«? Me puse a buscar y encontré un montón de proyectos similares abandonados y también otro gran grupo de poderosas herramientas MIDI pero más orientadas a la producción musical, por ejemplo instrumentos virtuales o secuenciadores, pero yo quería simplemente un reproductor MIDI para Linux de escritorio que tuviera un aspecto similar a SoundFont MIDI player, no tan completo como éste, pero sí con algunas características claves como visualización de las pistas, notas, listas de reproducción, selección de dispositivo y patches.

A medida que seguí dándole vueltas al tema – en la ducha como muchos saben – la idea comenzó a convertirse en algo que va mucho más allá de un MIDI Player para Linux. Ya que vamos a hacer un reproductor de música, por qué tendría que ser sólo MIDI? Si bien sobran maneras de escuchar música en formato audio «normal» como Spotify, iTunes y otros, hay una gran cantidad de material interesante que se encuentra en otros formatos, como los formatos usados por los ModTrackers (MOD, S3M, XM, etc), o los formatos para música de consolas y computadores (SID, Pokey, VGM, etc).

Vaya, que hay todo un universo más allá de la música distribuida en forma comercial.

El enfoque es similar a lo que hace RetroArch con los emuladores, el motor y el frontend es uno solo, pero lo que cambia son los reproductores, en este caso de música. En realidad, el concepto no es tan nuevo, ya lo hacía Winamp a través de sus «input plugins».

Al soportar más formatos también se puede pensar en un display diferente para cada uno de ellos, quizás no específicamente por formato, pero si por el tipo de información disponible. Por ejemplo en música de trackers hay acceso a la forma de onda, y eso se podría desplegar cuando está disponible como se puede ver en la imagen de arriba.

El MIDI Player ya no es solamente un reproductor MIDI, sino que también es un reproductor de múltiples formatos de música digital, y pese a que es algo más complejo de implementar, desde el punto de vista del usuario es algo más simple de usar porque oculta las complejidades de los distintos formatos como si fueran uno solo. El player se llama SimusPlayer o (Simple Music Player), es de código abierto y ya se encuentra en github en su fase inicial.

Si expandimos más el modelo, también podemos agregar skins, procesadores de audio y un largo etc, pero vamos con calma que hay otro aspecto interesante en este proyecto.

MusicTrans y RetroX para sistemas de escritorio

Con ese título podrían pensar que cambié radicalmente de tema, pero como verán está más relacionado de lo que pueda parecer. Cuando hice MusicTrans para Android y lo comencé a usar para mi práctica de guitarra, vi que tener una versión para escritorio (Linux/Mac/Windows) sería bastante conveniente, y como la parte principal del código estaba hecha en C y el resto era Java para Android, ya tenía al menos algo avanzado. Lo que necesitaba hacer era cambiar la parte específica de Android por algún equivalente que funcionara en los sistemas de escritorio.

Lo que hice en esa ocasión fue implementar un «mini Android» que me permitió reutilizar gran parte del código de MusicTrans para Android, y en menos de un mes la versión de MusicTrans para Escritorio ya estaba publicada, terminó siendo prácticamente igual a la de Android en cuanto a aspecto y funcionalidad, y me abrió un mercado no despreciable de nuevos usuarios amantes de MusicTrans que también lo querían en sus escritorios.

Esto tampoco era algo nuevo, de hecho resolver el problema de soportar 3 de sistemas de escritorio diferentes en forma casi nativa ya estaba resuelto por SWT del proyecto Eclipse, y es lo que usé como base para hacer este mini-Android, es una idea que ya andaba rondando hace varios años atrás cuando daba mis primeros pasos en Linux, y que finalmente pude poner en práctica y disfrutar de sus resultados.

Vi que contar con un framework que me permitiera crear aplicaciones casi nativas para Android y sistemas de escritorio usando casi el mismo código no sólo me da un gran espacio de libertad para publicar aplicaciones, sino que incluso me permite rápidamente crear aplicaciones para escritorio con las mismas habilidades que uso normalmente para Android (Java y C).

Es así como el año 2016 comencé a crear una biblioteca similar a la que usé en MusicTrans pero esta vez orientada a cualquier tipo de aplicaciones y bajo la modalidad de código abierto. Bajo el nombre de FTS lo publiqué en GitHub y senté las bases de lo que sería un gran framework para mí, pero por motivos que ya no logro recordar el proyecto quedo congelado en el tiempo y sólo alcancé a hacer una aplicación de prueba que abre una ventana y nada más.

FTS es agnóstico respecto a el mecanismo de despliegue, FTS sabe qué es un cuadro de texto (TextBox) pero no sabe cómo se dibuja, sabe lo que significa que un objeto gráfico se dibuje al lado de otro, pero no sabe cómo traducir eso en la pantalla. Esto nuevamente no es nuevo, pero es una idea muy flexible: Existe un «driver» para FTS que es el que sabe cómo traducir estas intenciones en algo concreto. En el 2016 sólo hice pruebas con un solo driver, y es un driver que utiliza SWT para dibujar en pantalla, que es lo que tenía a mano en su momento y me sirvió para probar los conceptos fundamentales. El problema es que para Android no puedo usar SWT, y por ahora ese driver no continuará en desarrollo, por lo que tuve que buscar un driver que fuera común denominador entre Android y los sistemas de escritorio, y ese driver es basado en OpenGL ES.

Nuevamente, no es primera vez que planteaba algo similar. Cuando estuve haciendo RetroX para que corriera en forma nativa en Raspberry Pi sin utilizar X.org sino que dibujando directo en el framebuffer, hice un framework llamado SGL (Simple Graphics Library) que esta basado en OpenGL y que me permitió desarrollar en mi escritorio Linux con X.org y ejecutar en Raspberry Pi via framebuffer. SGL fue específico para RetroX y quedó congelado una vez que abandoné la versión de RetroX para Linux/Raspberry Pi, para enfocarme sólo en Android.

Finalmente, todo este código converge y como muchas veces he dicho, no hay que tener miedo de escribir código ni de «perderlo» porque siempre de alguna u otra forma ese aprendizaje o incluso el mismo código servirá. Es así como por ejemplo las mejoras que he hecho a la versión de RetroArch que incluye RetroX usan los conocimientos que adquirí desarrollando SGL, y ese mismo conocimiento ahora se integra a FTS.

Entonces, para resumir, FTS (2016) ha sido descongelado y usará un driver basado en OpenGL ES rescatando parte del código de SGL (2014), y será la base de RetroX para sistemas de escritorio (2020)

Y qué tiene que ver todo esto con el SimusPlayer? Pues SimusPlayer será el conejillo de indias que me permitirá poner a prueba FTS con algo mucho más pequeño y menos riesgoso que hacerlo con RetroX, y de paso me permitirá hacer que el SimusPlayer para Linux también pueda correr en Mac, Windows, Android y .. Android TV!

Y aquí la cosa se pone wena wena.

Más que un simple reproductor de música

Bajo la premisa de hacer un reproductor simple, al agregar Android TV algo que es tan natural en sistemas de escritorio como lo es abrir un archivo, se puede volver muy complicado para un usuario en una aplicación que corre en un televisor o incluso en un móvil. Esto que parece una dificultad es en realidad una oportunidad: Ya que los archivos de música en estos formatos son pequeños, y existen grandes bibliotecas con miles de archivos ya clasificados, por qué no hacer que el mismo reproductor permita buscar y descargar estas canciones!! Por enésima vez, la idea no es nueva y esta aplicación sería como «un Spotify para MIDI/XM/S3M/MOD, etc». Como se trata de una aplicación muy de nicho y los archivos son bastante pequeños, el costo de transferencia de datos desde un repositorio propio no debería ser un problema, para la infraestructura que ya tengo andando con RetroX sería sólo un costo marginal.

Como en otros proyectos, inicialmente esto sería sólo para mi uso personal, la diversión está en construirlo y luego disfrutar lo construido, pero aún podemos ir más allá!

SimusPlayer module

Hace unos días conversaba con mi amigo Cristian Astudillo (Atariado) por la compra/venta de los parlantes que él fabrica como AsDub y en el conjunto me ofreció un amplificador Pioneer que es parte de su equipo modular. El módulo es bien bonito y me quedé pensando en cómo extenderlo un poco para que no se viera tan solo, y me acordé que tenía un módulo Sony reproductor de CD por ahí sin usar, sería la compañía perfecta.

Pero luego pensé, y…. por qué no convertir SimusPlayer en un módulo de más? Si la aplicación ya está orientada a ser usada en un Android TV, todas las características de «uso doméstico» la dejan lista para ser integrada en un módulo, o sea, convertir SimusPlayer en un hardware modular.

Otra vez, esto no es nuevo! Roland y otros fabricantes construyeron módulos MIDI que permiten reproducir sonidos y música en formato MIDI de forma independeinte, la idea sería similar pero cubriendo mucho más que sólo MIDI. Roland es una gran inspiración en cuanto a diseño y en cuanto a cómo debería funcionar un equipo de estas características, se podría hacer con una pantalla LED/LCD, una Raspberry Pi, y mucha ayuda de otros amigos expertos en hardware como Atariado y Gastón Centeno (Tongas).

En mi imaginación, veo un display themeable, idealmente un boot corto para que el equipo quede operativo en pocos segundos, control remoto via bluetooth y también control remoto via una simple app para Android. Las posibilidades de entretención construyendo este proyecto son infinitas, y quién sabe, quizás se podría convertir en un aparato interesante para otros que disfrutan de este tipo de música.

Finalmente, esta idea tampoco es nueva! A fines de los años ’90 con mi amigo Max Celedón queríamos hacer un proyecto de este tipo y se llamaba Multi-Audio, la idea era tener un equipo independiente que pudiera reproducir archivos MP3, MOD, MIDI, etc. En ese tiempo al menos MP3 necesitaba un equipo poderoso y la única opción era usar un PC, jamás había usado Linux y la única opción factible era modificar la BIOS para simplificar el proceso de boot y hacer unos simples drivers de DOS para manejar la tarjeta de sonido. Al final abandonamos el proyecto porque sospechábamos que en cualquier momento algún fabricante grande lo haría, cosa que jamás ocurrió, sólo agregaron MP3 muchos años después y los otros formatos de música pasaron al olvido.

Los conceptos de Multi-Audio después fueron aplicados a las primeras aplicaciones para televisión que hice, en donde se combinaban múltiples formato de video en vez de sólo audio, y posteriormente el mismo concepto se aplicó para Multi-Emuladores, lo que hoy se conoce como RetroX. Hacer este nuevo proyecto es darse la vuelta completa a los inicios de todo, con la ventaja de que ahora la tecnología disponible lo permite hacer. Tecnología al alcance de todos como es Linux, Raspberry Pi, servicios en la nube, impresoras 3D, componentes electrónicos económicos, cortadoras laser, etc, permiten jugar a ser inventor y disfrutar del proceso. Vamos a ver como resulta todo esto!

Catrin Labs Computers: CLC-88 Micro de 8 bits

Ya entrando en terreno es hora de hacer algunas definiciones para el computador de 8-bits. Una de las decisiones más difíciles es el procesador, ya que cualquier elección deja inmediatamente fuera al 50% de la población. La mayoría de los programadores dominan sólo uno de los dos, el 6502 o el Z-80 dependiendo de la región en donde vivieron o con qué máquina comenzaron.

Pero si no hay costos de producción involucrados, por qué no incluir ambos procesadores? Si! La idea no es tan descabellada, de hecho fue lo que hicieron en el Commodore 128 que tenía un procesador 6502 para quien quisiera compatibilidad con el C64, y un Z80 para quien quisiera usar el nuevo chip de video y aplicaciones productivas basadas en CP/M. Al momento de iniciar el equipo se decide cuál de los dos chips será utilizado.

En este caso, la arquitectura de audio y video se mantendría para ambos, por lo que se podrá programar con el assembler que más te acomode, y siempre usando el mismo hardware de audio, video, mapeo de memoria e I/O.

Esto abre las puertas a que independiente del computador con el que hayas aprendido a programar puedas rápidamente programar en este nuevo computador, y usando el assembler que más te acomode. Y más interesante aún, se podrían hacer ports de juegos existentes con la misma facilidad que en el pasado se hacían ports entre Atari y C64 (6502), y entre MSX, Spectrum y Amstrad (Z80).

Kernel / Basic

Como el sistema está pensado principalmente para juegos y no hay necesidad de compatibilidad con impresoras o sistemas de I/O diversos, al menos en un principio el sistema operativo sería bastante minimalista.

El sistema operativo básicamente se encargaría de hacer el sistema booteable. Sus tareas principales serían:

  • Inicializar el audio
  • Inicializar un modo de video
  • Atender las interrupciones por linea, vertical blank, NMI y alguna otra que se requiera
  • Operaciones de Input / Output con el medio de almacenamiento (SD Card)

Con un sistema minimalista de este tipo se dejaría disponible casi toda la RAM principal y no costaría tanto hacer las dos versiones que se necesitarían para 6502 y Z80.

En una segunda fase, se podrían añadir funciones orientadas a la programación como despliegue de texto, cursor, operaciones matemáticas (división, multiplicación, trigonométricas), dibujo de lineas y otras. En una tercera fase estas funciones podrían ser llamadas desde un interprete de basic implementado para ambos procesadores.

Modos de Video

Un criterio similar es aplicable a lo modos de video. Para qué inventar todo un nuevo sistema si se puede recuperar lo mejor de cada chip y de paso nuevamente hacer que sea muy fácil portar un juego de un sistema existente. Algo así se hizo en el MSX en donde existía un modo de video similar al del Spectrum, entonces cuando no habían recursos para un port con todas las de la ley, se hacía un port de Spectrum casi calcado. No era lo mejor, pero ahora sin restricciones de presupuesto a partir de ese port inicial ya funcionando se podría modificar el código para aprovechar el nuevo hardware.

Acá juega un papel importante el uso de las Display Lists que existían en Atari. Se trata de un conjunto de instrucciones que sigue el chip de video para generar la pantalla linea por linea. Éstas instrucciones permiten mezclar distintos modos de video, distintas paletas de colores, distintos niveles de scroll y distintos sprites por cada linea. Por ejemplo si queremos tener un juego tiled con scroll suave y abajo un marcador en modo bitmap pero usando otra paleta de colores, el display list lo permite perfectamente.

En este nuevo computador existirían modos de video compatibles con los computadores ya mencionados además de nuevos modos de video más poderosos, todos combinables en una sola pantalla gracias al Display List.

Nombre tentativo: CLC-88

Con el título ya sabrán que este micro de 8 bits ya tiene nombre: CLC-88. No es que bruto que original el nombre pero creo que representa muy bien la idea de que primero, es un computador de 8 bits y segundo, es un computador que perfectamente podría haber sido diseñado el año 1988.  El prefijo CLC corresponde a Catrin Labs Computers, y al mismo tiempo es una famosa instrucción del 6502 que usabas cada vez que querías sumar.

Para el equipo de 16 bits si es que llega a concretarse, se seguirá una lógica similar con CLC-92. En este caso si bien no dice nada de 16 bits, sí es un computador que podría haber sido diseñado en 1992. Además que estrictamente estos equipos eran híbridos de 16 y 32 bits por lo que «16» no le haría tanta justicia… Esto último se me ocurrió recién, la verdad es que quería usar el número 92, pero suena creíble!

Mas info:

Parte I: Catrin Computer Labs

Parte II: Chip de video

 

Catrin Labs Computers: Chips de Video

La parte que no es tan obvia en cuanto a hardware en este proyecto es el chip de video. Si pensamos en usar un chip de video de la época necesariamente nos casaríamos con un tipo de estética, ya sea el attribute clash de Spectrum o los 4 colores por línea del Atari, o la extraña paleta de verdes, grises y cafés del C64.

En los tiempos en que se diseñaban estos computadores se hacían prototipos físicos, no habían computadores para simular el comportamiento ni nada de eso. Simplemente se armaban protobards, se conectaban todos los cables y sobre eso se iteraba, era natural que sólo el diseño se planificaba para ser realizado en varios meses o incluso años.

Hoy en día no existe ese problema y los computadores son tan potentes que pueden perfectamente ayudar a diseñar y simular nuevos chips, así como existen emuladores para simular chips antiguos por qué no crear un emulador también para simular un chip que no existe?  Eso permite experimentar y refinar el diseño antes de convertirlo en hardware real y elimina la limitación de ajustarse al hardware existente. Si a esto agregamos que existe tecnología como FPGA que permite implementar diseños electrónicos de nuevo hardware via hardware existente, el camino de un diseño en software a una ejecución en hardware es posible.

Afortunadamente hay suficiente información de cómo diseñar chips de video, tenemos el mismo código de los emuladores, y en camino viene un libro que trata sobre el diseño del ULA en el Spectrum. También Leonardo Ruilova me recomendó otro libro de la misma temática, escrito por uno de los creadores de un proyecto similar, XGameStation.

Alternativas

Hay múltiples alternativas para resolver el problema del chip de video. Siempre pensando en que es un proyecto de largo plazo y hay tiempo para experimentar, veo las siguientes opciones:

  • Que este nuevo hardware simplemente corra sobre hardware potente como una Raspberry Pi, como si fuera un emulador de toda la vida, pero a diferencia de los emuladores existentes, éste siempre sería perfecto, pues no existe el hardware a emular y la única referencia sería el código del emulador. En este caso el chip de video sería un emulador de un nuevo chip, implementado en la Raspberry Pi. Posteriormente se podría crear el hardware real y quizás sería un raro caso en donde primero se construye el emulador y luego el hardware.
  • Utilizar VGA pero con un procesador dedicado sólo a video.  VGA sólo actuaría como framebuffer, y el procesador dedicado sería el equivalente a un custom chip del Amiga o a un chip de aceleración. Este chip tendría acceso casi exclusivo a la VRAM y operaría a una frecuencia diferente del procesador principal. El chip estaría inicialmente implementado en software controlando la VGA física. Si consideramos que un PC antiguo puede emular perfectamente computadores de 8-bit y 16 bit, la dedicación exclusiva a procesar video es perfectamente posible.
  • Utilizar un chip de video existente.  En el proyecto de 8-bit guy están siguiendo este camino, pero está el inconveniente de que aparecen las restricciones del chip de video existente. Por ejemplo el chip que están usando sólo puede generar graficos tiled (como una NES), y la interfaz de comunicación es serial. Por ahora esta alternativa está descartada (*)
  • Utilizar un chip de propósito general para generar video. Es algo similar a la opción de usar VGA sólo que el chip generaría directamente la señal de video. Es una opción bastante interesante y ya se ha hecho, pero por problemas de rendimiento no se pueden generar muchos colores con los chips conocidos.

(*) Sigo atentamente la evolución del proyecto de 8-bit guy y está bastante activo. Hoy publicaron un demo de lo que pueden hacer con Gameduino y es bastante impresionante, pero nuevamente se aleja de la esencia del proyecto que es tener limitaciones de recursos de la época.

Por ahora, creo que el camino más flexible es implementar un emulador de un chip que genere un framebuffer. Esto permitiría tener un diseño en el corto plazo y ya con más experiencia poder tomar cualquiera de estos tres caminos: Mantener la emulación, Controlar una VGA, Utilizar un chip de propósito general.

Actualización: Hay un proyecto similar llamado Anvil-6502 en donde hicieron un chip de video que funciona bastante bien. Es principalmente bitmapped y requiere un procesador rápido, pero puede servir de base para convertir el framebuffer en señal de video. Hay unos demos bastante espectaculares.

Más info en:

Parte I : Catrin Labs Computers

Parte III: CLC-88 Micro de 8 bits