Pensamientos sobre los GMO

Los Organismos Genéticamete Modificados (GMO por su siglas en inglés) son organismos a los cuales se les ha introducido parte de un genoma diferente al de su especie original. Normalmente se les conoce como transgénicos, esto es, que poseen genes de otras especies.

Mucho se ha hablado de Monsanto, y hoy en día, debido a falta de argumentos en torno a la seguridad de los GMO, la política de críticas a los GMO se centra en atacar a esta empresa y sus prácticas comerciales. Ahí no me meto, porque tienen para darles por delante y por detrás.

Pero por donde quiero ir, por donde va mi reflexión, es por la idoneidad de utilizar un proceso tecnológicamente avanzado para editar el genoma de una especie y modificar las características que queramos. No es nuevo, y sale frecuentemente a relucir, que todos los alimentos que consumimos, TODOS, son GMO. Durante siglos, milenios, se han seleccionado las semillas que daban tomates más gordos, árboles con más peras y vacas que daban más leche.

La vaca y toro vienen del Uro, su equivalente salvaje, gracias a la modificación genética. El perro, del lobo. Los cerdos de los jabalís (aun siendo técnicamente la misma especie). Lo mismo con la fruta y vedura, hasta llegar a saber que la naranja proviene de un cruce de la mandarina y el pomelo. Todos han sido artificialmente seleccionados y cruzados para conseguir el producto que ahora nos gusta.

Por lo que la pregunta no es si los GMO son buenos o malos. Es tarde para ello, llevamos toda la vida consumiéndolos. La cuestión es: ¿qué es mejor, un organismo al que se le han modifcado solamente las características deseadas o un organismo cruzado que almacena mutaciones unas detrás de otras sin ningún control? Porque eso, amigo, son los tomates que te estás comiendo.

Y para terminar, un poco de luz sobre las razas de los perros, y los peligros de la selección artficial:

Pensamientos sobre los GMO

FluidSynth superado. Ahora empieza lo bueno.

Por fin puedo decir que he echado un pulso a fluidsynth, sus python bindings (pyFluidSynth, see original project and my personal fork) y a todas las dificultades que un proyecto de estas características te pone delante. Pero lo primero es lo primero, así que aquí tenéis una Demo de como funciona fluidsynth en una Raspberry Pi 2 B+ (Raspbian), haciendo llamadas mediante los python bindings de fluidsynth:

Y ahora vamos con los detalles. El video muestra simplemente una llamada a liveDemo.py, un script que he preparado para probar 20 segundos del programa 0 y 20 segundos del programa 50 de cualquier soundfont que tengamos (por defecto carga /usr/share/sounds/sf2/FluidR3_GM). Así que los pasos para probarlo, desde una Raspberry Pi conectada a internet con Raspbian son los siguientes.

En primer lugar, nos aseguramos de tener instalado FluidR3_GM y las librerías de python de ALSA:

sudo apt-get install fluid-soundfont-gm python-pyalsa

Posteriormente, hacemos un clone de pyFluidSynth, con el código:

git clone https://github.com/pakitochus/pyfluidsynth.git

Navegamos hasta el lugar donde está la instalación y ejecutamos:

cd pyfluidsynth
sudo python setup.py install

Y en principio, ya podríamos ejecutar el test con:

cd test
python liveDemo.py

Por supuesto, hace falta tener un teclado midi conectado a la raspberry, yo sugiero MIDI USB. En el script, se presupone que el puerto en el que está conectado es el 20,0, pero esto no tiene por qué ser así. La forma correcta de saber cual es el dispositivo que tenemos completado es mediante el comando:

aconnect -i

que listará algo así como:

cliente 0: 'System' [tipo=kernel]
    0 'Timer           '
    1 'Announce        '
cliente 14: 'Midi Through' [tipo=kernel]
    0 'Midi Through Port-0'
cliente 23: 'MIDI KEYBOARD' [tipo=kernel]
    0 'MIDI KEYBOARD MIDI 1'

Suponiendo esos datos, para cambiar el que está por defecto, editamos el archivo liveDemo.py, y en la línea 29, donde aparece

sender = (20, 0)  # Modify according to the current port of the USB MIDI input

cambiamos por

sender = (29, 0)

De igual modo, para cambiar la soundfont a utilizar o modificar la ruta, vamos a la línea 22 del archivo, y sustituimos la línea

sfid = fs.sfload("/usr/share/sounds/sf2/FluidR3_GM.sf2")

por la ruta hasta el archivo de soundfont que queramos. En el video, he utilizado una colección que he recopilado y creado -a partes iguales- llamada ChusoCol, que podéis encontrar en Sourceforge (pronto subiré la ChusoCol 2, la del video).

Y eso es todo. No deja de ser una demostración de como funciona el fork de pyFluidSynth. Ahora es cuando viene lo bueno: convertir la RPi2 en un single-purpose computer y añadir todos los controles para usar el PiFace Control and Display module.

Esto no ha hecho más que empezar. Pero ya hay un paso menos que dar.

FluidSynth superado. Ahora empieza lo bueno.

Y vuelvo a tocar con Achake

Lo cual es un honor enorme. El grupo de Rock Urbano por excelencia de mi pueblín, Achake cumple 10 años y lo van a celebrar por todo lo alto con un concierto en el paseo. Además, el día 13 de Agosto, mi cumpleaños.

Es un buen regalo volver a compartir escenario con estos fieras a los que he visto nacer, crecer y hacerse grandes desde que yo mismo era un moco. Han sido probablemente el grupo exponente de Alcalá, y una de las bazas más importantes de la música del pueblo, si no la que más (por supuesto, obviando a superstar como Roko, y a los grandes Flash allá por su época dorada).

Ya toque con ellos una vez, y también grabando disco. Esta noche repetirán, y será un espectáculo para recordar. Espero que salga, por lo menos, como el X aniversario de Anima Adversa, casi el último concierto en el que estuve, y un bombazo.

Mientras, os dejo con la presentación:

Y vuelvo a tocar con Achake

Ahora empieza lo bueno

Así que tras la vuelta de esas vacaciones-trabajo llamadas congresos, nos toca ponernos a trabajar. Nos han seleccionado Tres papers para un Special Issue de impacto 6!! Pero hay que hacer el trabajo desde cero.

También llega la época de corregir, revisar papers, etc, así que manos a la obra.

Mientras tanto, ha llegado por fin la grabación de nuestra maravillosa actuación en la 9ª de Beethoven:

Ahora empieza lo bueno

ChusoCol

Conforme pasa el tiempo, parece que he abandonado por completo el proyecto ChuSynth. Nada más lejos de la realidad. Simplemente, con diferentes tareas que surgen de la investigación (y ahora también obligaciones docentes) pues no tengo tanto tiempo para dedicar a ello. Sin embargo, en estos días atrás estoy continuando otro proyecto que va de la mano de ChuSynth, y que es su principal fuente de sonido: ChusoCol, una soundfont ligera (alrededor de 300 MB), enfocada en el realismo de instrumentos acústicos y que pueda ser ejecutada de forma eficiente en una Raspberry Pi.

ChusoCol

La página web la diseñé hace tiempo y la mayor parte del trabajo de actualización lo hice durante mi estancia en Cambridge, pero ahora estoy dando los últimos retoques y espero poder lanzar ChusoCol 2 en poco tiempo. Mientras tanto, en la página web se puede descargar la primera ChusoCol, que me acompañó a muchísimos sitios cuando iba de conciertos con Anima Adversa.

ChusoCol

XIX Veladas Musicales

xIX Veladas Musicales de la ETSIIT

Están siendo unas semanas muy intensivas de trabajo, pero siempre hay rato para la música. Particularmente, en este caso, nuestro estreno (de moza y mío) como pareja en los escenarios: Acoplados (a couple), en las XIX Veladas Musicales de la ETSIIT.

Estaremos este Martes 5 de Mayo a partir de las 19:30 en el Salón de Actos. ¡Esperemos que salga muy bien!

XIX Veladas Musicales

Errare Humanum Est

Errar es humano. O mejor aún, es errar lo que nos hace humanos. Toda una amalgama de errores que se concatenan, y que inundan cada rincón de nuestra vida: desde olvidar donde pone uno las llaves hasta fallos de ejecución en una obra musical, pasando por sesgos cognitivos e incoherencias internas que son las que nos dan poco a poco la vidilla, y la razón para pensar.

Pero es de los fallos en la música de lo que hablaré. Porque si hay algo que me fascinó cuando era mucho más pequeñajo era la perfección de un disco, con una filosofía que bebía directamente del mundo de las ideas de Platón, haciendo de una pista grabada el ideal de la canción que luego cambiaría en cada una de las ejecuciones.

La música grabada, en ese momento, me parecía la obra culmen de la música, el pico de perfección que jamás se podría alcanzar, tal vez solo llegar infinitesimalmente cerca. Una suerte de mundo de ideas de platón que, al pasar por nuestras manos, se convertirían al mundo de lo físico añadiendo imperfecciones.

Con la llegada de la música electrónica llegó una autoimposición bestial de la perfección. Todo se podía racionalizar, cuantizar… La era del MIDI y la informática que transformó a la música en algo inmutable, reproducible. En definitiva, tan inerte como una piedra. Esto está tan dentro de nuestro ADN que nos hace parir chistes tan geniales como:

– ¿Te vienes a echar unas cervezas?

– No, estoy grabando a un grupo…

– ¿Grabar? ¿Y eso qué es?

– Es como el MIDI, pero con personas..

No es tan alocado como puede parecer, en todo caso. Poco a poco, y estando ya en Anima Adversa, vi como todos nos dejábamos llevar por la obsesión con esa perfección. Una perfección que es falsa.

Recuerdo habiendo sacado El Grito en el Cielo, como Juanpy dijera: a mi me gusta más El Otro Yo, tiene un alma, un algo. En ese momento, mi respuesta fue: claro, tiene que está mal grabado. Y es increíble como, estando tan acertado, estaba tan equivocado. Por supuesto, el disco es en sí una sucesión de ejemplos de como no hay que grabar. Sin embargo, esa sucesión de imperfecciones hacían que la música cobrase vida.

Hoy en día creo firmemente en que la música sólo está viva en directo, y que por tanto, la música grabada no debe ser reflejo de la perfección inerte del mundo de las ideas. Este mundo de las ideas no existe mas que en nuestras cabezas. La música grabada debe ser una de las reflexiones físicas de nuestro mundo de las ideas interior, y que fluye a través de nuestras propias capacidades de ejecución, entrenadas al máximo.

Y es que errar no es más que el acto creador que nos convierte en dioses capaces de conferir alma a la música. El resto, son piedras.

Errare Humanum Est

¿Qué IDE puedo usar para trabajar con Python como si fuera Matlab?

Esta es la primera pregunta que me hice a la hora de pasarme a Python. Y no es una respuesta fácil. Si dejamos de lado diferencias tan sustanciales como que Python es orientado a objetos y Matlab no, y las diferencias a la hora de trabajar con uno y otro, habría que atender a varias circunstancias. Para mi, un IDE que funcione bien tiene que tener al menos:

  • Editor integrado (si puede ser con sugerencias)
  • Ventana de comandos (IPython a ser posible)
  • Visor de variables
  • Posibilidad de salvar un workspace

Prácticamente todos los IDEs cumplen estas características. Después de mucho navegar por la web me encontré los más parecidos a Matlab que me podía tirar a la cabeza: Spyder y IEP. Ambos cumplen exactamente lo que prometen: un IDE para trabajar con SciPy (con todo lo que ello conlleva: numpy, matplotlib, scipy, sklearn).

Spyder UI

El primero que probé era Spyder, bastante consolidado ya en el mundillo, y que cumple todo lo anteriormente dicho. Es bueno, fiable y permite guardar el workspace en un único fichero (pero esto también puede ser un problema, porque es un fichero propio de spyder). Tiene un autodetector de las funciones que se están usando, que muestra la ayuda de dicha función en una pestaña (si la tenemos visible). En su contra diré que es más bien feo (tanto la UI como el icono) y que no tiene sugerencias instantáneas.

EIP UI

Por otra parte, conocí EIP, que por el momento me gusta más. Está en un desarrollo un poco más activo, aunque menos maduro que Spyder, con todo lo que ello conlleva. La principal diferencia es que no tiene un asistente para guardar workspace (se puede hacer desde código), pero en contrapartida posee sugerencias live de funciones, objetos y demás que estén en el workspace, lo que es muy conveniente cuando uno está empezando. También en el apartado estético gana por su limpieza e integración con el sistema operativo. Todavía es pronto para hacer un diagnóstico y me quedan muchas horas que trabajar con alguno de ellos, pero por lo pronto, yo me quedo con EIP, por las sugerencias y por su interfaz más pulida. Quizá en algún momento necesite guardar variables del workspace, en ese momento me plantearé que opción es más buena.

Editado: Una tercera opción que se me olvidó citar al ser de pago (aunque tienen una versión gratuita) es Canopy. Quizá es la que más se parezca a Matlab y viene perfecamente equipado con todo lo necesario para trabajar. Lo que es más, está disponible tanto para Windows como para Mac y Linux, lo que lo hace una opción muy buena a tener en cuenta si no importa el hecho de que no sea open source.

¿Qué IDE puedo usar para trabajar con Python como si fuera Matlab?

Tocando mis primeras notas

Por primera vez, he logrado lanzar fluidsynth desde una terminal python, crear su correspondiente driver MIDI y tocar algunas notas con el teclado en directo. A partir de aquí, es todo mejorar.

El problema que estaba teniendo era con la función new_fluid_midi_driver(settings, handler, event_handler_data), en el que en la documentación aparece como que hay que llamarlo (en C) de esta forma:

fluid_settings_t* settings;
fluid_midi_driver_t* mdriver;
settings = new_fluid_settings();
mdriver = new_fluid_midi_driver(settings, handle_midi_event, NULL);

sugiriendo el uso de fluid_midi_router_handle_midi_event() como handler callback. Finalmente, la mejor opción para mi fue:

mdriver = new_fluid_midi_driver(settings, fluid_synth_handle_midi_event, synth)

O sea, que había que la función fluid_synth_handle_midi_event es la pancea y en ningún sitio de la documentación de API te la especifican. Bien por fluidsynth. Y usar el propio objeto sintetizador synth como event_handler_data.

Tocando mis primeras notas