Armonía Práctica

Para todos aquellos que estéis estudiando armonía en el conservatorio (o por libre), comentaros que existe un programa con bastante buena pinta que os puede ayudar a hacer los ejercicios:

Harmony Practice

Un programa apropiado para trabajar y corregir tú mismo tus ejercicios de armonía

Por: Fausto Torre (Italia) y Michel Baron (Canadá)

Página Principal

Descargar la versión 2.01 en Castellano (desde la página oficial)

La licencia del programa no es libre, pero al menos es freeware. Por eso lo incluyo aquí, de todas formas. Destacar que el programa está traducido al castellano por Manuel Alberto Vázquez Diz (de Ourense).

Michel Baron es profesor en el Conservatorio de Música de Québec (Canadá), y tiene una página web muy interesante con apuntes online de armonía, contrapunto y fuga. Dichos apuntes están traducidos al castellano y al gallego.

 

Documentación de la Presentación de OpenPipe

Como os había comentado, el proyecto OpenPipe se presentó formalmente dentro de las VII Jornadas sobre Software Libre, organizadas por la asociación de programadores y usuarios de GNU/Linux GPUL de mi facultad.

Hace unos días se ha publicado en la página toda la documentación de las charlas (transparencias, ficheros de ejemplo, un prototipo software en Java, y un video con la presentación). Espero que sirva de complemento a todo lo comentado aquí.

Ha sido mucho tiempo dedicado a la presentación, y me gustaría darle las gracias a todo el GPUL por el apoyo brindado, sobre todo a su presidente Emilio Padrón, y a mi compañera de clase María Casanova por sus ánimos para seguir avanzando en el proyecto, cuando poca gente se interesaba en él.

Muchas gracias a Antonio Armada, gracias al cual la electrónica ha dejado de ser un obstáculo para convertirse en un poderoso aliado. Todo un crack.

Y muchas gracias a toda la gente que me ha escrito mensajes de felicitación, que han sido unos cuantos. Espero haber respondido a todo el mundo, ¡soy muy despistado!

Por último, indicar que si alguien está interesado en presentar el proyecto en alguna otra parte de España (o en otra parte del mundo, who knows?) puede utilizar las transparencias o pedirme material para preparar alguna charla, que podría enmarcarse en alguna de las muchas jornadas sobre Software Libre (y derivados) que se hacen en muchas asociaciones y universidades.

Introducción a los Microcontroladores (II)

Siguiendo con la descripción de la familia LPC900, hoy hablaremos un poco sobre cómo configurar el puerto serie.

¿Qué es un puerto serie? ¿Y una comunicación serie?

Es muy sencillo. Una comunicación serie es una comunicación en la que la información viaja bit a bit, lo que contrasta con el puerto paralelo en el que es posible transmitir varios bits a la vez. Entonces es sencillo comprender que únicamente es necesaria una línea de datos.

Una UART es un circuito integrado utilizado en las comunicaciones serie. Ahora bien, los conectores a utilizar pueden ser bien diversos. Tenemos el RS-232, el DB-9, por poner un par de ejemplos. Si observáis los esquemas, veréis un montón de líneas más, eso es porque algunos protocolos utilizan señales adicionales. De todas formas, lo más habitual es que se utilice un transmisor (un TxD) y un receptor (un RxD). ¡Y masa (Gnd), por supuesto!

Sin embargo, hay ciertas variables en una comunicación serie que es necesario configurar (en ambos extremos):

• La velocidad: Medida en baudios o bits por segundo.
• Bit de paridad: Es un bit adicional que se utiliza para prevenir errores en la transmisión, por lo que por cada byte se envían 9 bits. Normalmente ese noveno bit es configurable, y suele ser función de los otros ocho.
• Bit de parada: Se refiere a la utilización de un bit adicional como separación entre dos bytes consecutivos (bytes que pueden ser de nueve bits, si es que existe bit de paridad).

Por tanto, antes de iniciar una comunicación serie es preciso establecer los anteriores parámetros. Los dos dispositivos participantes, necesariamente, han de estar igualmente configurados; en caso contrario el resultado es impredecible.

Comunicación serie en la familia LPC900

Existen cuatro modos:

• Modo 0: La información se transmite y recibe por RxD. Se utilizan 8 bits y la velocidad es fija, a 1/16 de la frecuencia del reloj.
• Modo 1: La información se transmite por TxD y se recibe por RxD, utilizando un bit de inicio (0 lógico), 8 bits de datos y un bit de parada(1 lógico). La velocidad es configurable utilizando el generador de baudios, o bien por overflow del timer 1.
• Modo 2: La información se transmite por TxD y se recibe por RxD, utilizando un bit de inicio (0 lógico), 8 bits de datos, un noveno configurable (paridad) y un bit de parada. La velocidad es configurable a 1/16 o a 1/32 de la frecuencia del reloj.
• Modo 3: Es exactamente igual al modo 2, pero con la velocidad configurable por medio del generador de baudios, o por overflow del timer 1.

En cualquiera de los cuatro modos se transmite siempre en LSB (es decir, primero el bit menos significativo).

¿Qué es eso del generador de baudios? ¿Overflow del timer 1?

Cuando la velocidad es variable, la UART necesita saber cada cuánto tiempo tiene que enviar los bits. Normalmente se utiliza un contador que va sumando uno de cada vez y, cuando se desborda (se produce overflow), indica que hay que enviar el siguiente bit (opción del timer 1) .

Overflow significa sobrepasar, en el sentido que una variable numérica toma un valor más alto del que puede almacenar. Cuando estás programando, las variables numéricas pueden contener un valor de entre un rango limitado. Por ejemplo, el tipo int (entero) suele ser de 4 bytes. Si una variable es de tipo byte, los valores permitidos son los del intervalo [0, 255]. Supongamos que en una variable se inicializa a cero, y que empezamos a sumale uno indefinidamente. 0 + 1 = 1, 1 + 1 = 2, 2 + 1 = 3, etc. Llegamos a 254, 254 + 1 = 255, 255 + 1 = … Overflow (o desbordamiento).

La idea de usar un timer para saber cuando enviar el siguiente dato es bien sencilla. El timer tiene un valor inicial configurable, que es el valor que se cargará en el timer cada vez que se produzca overflow. Según el procedimiento que hemos descrito, cuanto más alto sea el valor cargado menor será el tiempo necesario para desbordarlo (suponiendo que le sumamos uno de forma constante).

Ejemplo a: Cargando 240

contador (instante t) = 240

contador (intante (t + 1)) = 241

contador (instante (t + 2)) = 242

…

contador (instante (t + 15)) = 255

contador (instante (t + 16)) = ¡Overflow! La UART debe mandar el siguiente bit.

(cargar nuevamente 240 en el contador y repetir el proceso hasta que no haya bits para transmitir).

Ejemplo b: Cargando 180

contador (instante t) = 180

contador (instante (t + 1)) = 181

…

contador (instante (t + 75)) = 255

contador (insante (t + 76)) = ¡Overflow! La UART debe mandar el siguiente bit.

(cargar nuevamente 180 en el contador y repetir el proceso hasta que no haya bits para transmitir).

Pregunta: ¿En qué caso se envían los datos a mayor velocidad? En el caso (a), puesto que cuanto mayor sea el número cargado en el contador, menos se tardará en llegar al overflow, suponiendo que el resto de condiciones son invariantes.

Normalmente existe una fórmula conocida que relaciona el número a cargar en el contador con la velocidad en baudios. Para el caso del micro que nos ocupa, la fórmula es la siguiente:

Número a cargar = (Velocidad del oscilador / Velocidad en baudios) – 16

En donde “Velocidad en baudios” representa la velocidad a la que queremos transmitir los datos. Por ejemplo, para transmitir a 9600 baudios, suponiendo una velocidad de reloj de 7 373 000 Hz (que es a la que trabaja el micro en cuestión), es decir, unos siete MHz, tenemos que:

(7 373 000 / 9600) – 16 = 752= 0×02F0 (hexadecimal)

Obviamente, sólo podemos configurar la velocidad en los modos 1 y 3.

Para terminar, un generador de baudios no es más que un contador dedicado a gobernar la comunicación serie. Si el micro ya incorpora un generador de baudios, puedes utilizar el contador para otras cosas.

Nota: Contador y timer es lo mismo, por si alguien anda despistado :p

Documentación MIDI

En la página de la MIDI Manufacturers Association (la MMA) se pueden encontrar un pequeño “resumen” de las especificaciones MIDI. En otras páginas se pueden encontrar alguna que otra información interesante, pero que resulta insuficiente para alguien que está diseñando un controlador MIDI.

Es necesario conocer más sobre el MIDI. A un nivel mayor de profundidad.

Una de las opciones es adquirir el libro The Complete MIDI 1.0 Detailed Specification, vendido por la propia MMA. ¿Alguien tiene referencias sobre éste libro? ¿O sobre algún otro que pueda ser útil para un diseñador MIDI?

Editado 12/09/07: Ya he pedido a la biblioteca de mi facultad que encargue la documentación MIDI. Ahora sólo queda esperar a que llegue. Desde aquí, agradecer la amabilidad de nuestra bibliotecaria. ¡¡¡ Gracias Teresa !!!

Introducción a los Microcontroladores (I)

Hace unos meses me compré la tarjeta MCB900, que me permite programar y trabajar con los micros de la familia P89LPC9XX (en concreto estoy trabajando con el P89LPC935) cuyo fabricante es Phillips:

Os voy a contar un par de cosillas bastante interesantes:

1. El microcontrolador. Está conectado en el zócalo, listo para ser programado (grabar un programa en su memoria interna) o bien para ejecutar el programa que esté insertado en dicha memoria.
2. Los jumpers nos permiten configurar la placa para un modo u otro:
   • Por una parte tenemos el jumper AV, que simplemente sirve para indicar que queremos utilizar el potenciómetro que tiene la placa. Si queremos usar el pin 0.3 como entrada / salida, lo más probable es que tengamos que desconectar el jumper.
   • Y por otra parte, tenemos el otro jumper, que nos permite seleccionar entre dos opciones: Reset y Run. Si queremos ejecutar el programa seleccionaremos Run, y si queremos programar el micro seleccionaremos Reset.
3. La parte inferior de la placa nos permite realizar conectar un circuito digital con cualquiera de los pines del micro: Tenemos tres puertos de 8 bits (Puertos P0, P1 y P2) y un cuarto puerto de 2 bits (Puerto P3). Destacar que, dependiendo del micro, se pueden utilizar varios pines para leer una entrada analógica (en el P89LPC935 se pueden configurar hasta 8 pines como entradas analógicas).
4. La propia placa incorpora un potenciómetro, que no es más que una resistencia variable que nos permite seleccionar un valor de voltaje entre el rango [0.0, 3.3] voltios. Para utilizar el potenciómetro, es preciso tener configurado el jumper en AV.
5. La placa también incorpora ocho LED’s que nos permiten conocer en todo momento el estado de cada uno de los pines del puerto 2.
6. La alimentación de la placa (que ha de ser externa, puesto que el RS232 no incorpora alimentación, al contrario de lo que sucede con el USB) se realiza entre 5 y 9 voltios.
7. Por último, la placa incorpora un puerto serie (conector DB-9) que cumple varias funcionalidades:

• Permite conectar la placa a un PC, para descargar un programa en la memoria del micro.
• Una vez el micro está ejecutando un programa, podemos utilizar el puerto serie para comunicar el micro con otro dispositivo externo (mediante una comunicación serie, por supuesto).

General MIDI

Como hemos visto anteriormente, el sintetizador nos ofrecía una serie de instrumentos a elegir de los bancos de sonidos. Sin embargo, existía un pequeño problema, bastante sencillo de entender.

Supongamos que creamos un archivo MIDI, una hermosa composición con varios instrumentos, los que vosotros queráis. Cada pista de ese fichero MIDI estaría asociada a un canal, y cada canal estaría asociado en un momento determinado a un instrumento del banco de sonidos. Efectivamente, durante la reproducción de un archivo MIDI, el secuenciador envía un mensaje MIDI especial, que asociaría un instrumento del sintetizador (de toda la gama disponible) a los mensajes que llegasen por un canal concreto.

Siempre que utilizásemos el mismo modelo de sintetizador, no tendríamos el menor problema. Pero como ya habíamos comentado, uno de los puntos interesantes era la modularidad del sistema, por lo que probablemente nos interesaría ejecutar ese fichero con otro secuenciador y con otro sintetizador.

¿Cuál era el inconveniente hasta la llegada de General MIDI? Muy sencillo. Cada fabricante de sintetizadores podían tener los intrumentos en un orden diferente al del resto, lo que provocaba que una composición (en la que nos habíamos esmerado a la hora de escoger los instrumentos) sonase con otros instrumentos completamente distintos. Por ejemplo, el instrumento número cero podía ser un piano en un sintetizador, mientras que en otro podría ser una flauta. O incluso los sonidos de la batería. Nunca se podía saber de antemano cómo sonaría en otros sintetizadores.

General MIDI pretendía ser un estándar mínimo en ese aspecto. La idea central era crear una lista de instrumentos que cualquier fabricante podría incluir de forma sencilla en sus sintetizadores (nótese que es un estándar mínimo, lo que deja la posibilidad de incluir instrumentos adicionales).

En otras palabras, el compositor tendría la garantía de que su composición se ejecutaría adecuadamente con los instrumentos deseados, independientemente de la marca del sintetizador usado.

Más información:

http://en.wikipedia.org/wiki/General_MIDI

http://www.midilandia.com/midiland/articulos/art_midiprincipiantes3.htm

Ubuntu Studio 7.04 Feisy Fawn

Estoy siguiendo con especial interés el lanzamiento de la distro “Ubuntu Studio”, que es una Ubuntu orientada a la edición multimedia, tanto para audio como para video. Seguramente podrá instalarse como un paquete desde una Ubuntu normal (o cualquier derivada de Ubuntu), pero todavía no os puedo dar más detalles.

Comentaros a partir de ahora que, además de ser un blog orientado al proyecto OpenPipe, también se incluirán posts relacionados con música y software libre

Confirmada la presentación de OpenPipe en las VII Jornadas sobre Software Libre

Dicho y hecho. Aquí se irán mostrando las charlas, junto a una breve descripción, a medida que los participantes vayan confirmando su asistencia (por temas de día y hora). Aquí os dejo un enlace al cartel, que me ha recordado al mítico puzzle ayudante del Office (el que se puede escoger en lugar de clippo :p).

Muchas gracias a GPUL por la oportunidad que me han ofrecido, un año más. Y, sobre todo, a su presidente (Emilio J. Padrón) por su dedicación y paciencia conmigo

Presentación “en sociedad” de OpenPipe

A finales del presente mes de Abril, se celebrarán las VII Jornadas sobre Software Libre en la Facultad de Informática de la Universidade da Coruña. Ya en las anteriores jornadas participé con una charla sobre “Nuevos Modelos de Negocio basados en Software Libre” (transparencias y video disponible), en el que realicé una pequeña incursión sobre lo que son las bases del modelo de negocio que plantea actualmente el Software Libre, un negocio centrado principalmente en el servicio y no en el producto, además de comentar las diversas ventajas (directas e indirectas) que aporta a las pequeñas y medianas empresas el uso de éste tipo de software.

La verdad es que la experiencia fue todo un éxito personal, pues hubo bastante asistencia que luego participó en un improvisado debate. Éste año repetiré, pero ahora para presentar el proyecto OpenPipe de forma oficial, ante la gente de mi facultad. Será como una especie de resumen de todo lo comentado en el blog y en los artículos, orientado sobre todo a que la gente profundice en el conocimiento del MIDI y a que se cree un interés alrededor de lo que puede aportar a la música tradicional un proyecto libre como OpenPipe.

Aunque todavía no he podido implementar nada en hardware, describiré formalmente (pero de forma amena) las bases de su funcionamiento a nivel conceptual, para lo que se introducirá a los asistentes en las bases del protocolo MIDI, a nivel usuario y a nivel de programación. De ser posible, se construirá un pequeño modelo en software (utilizando probablemente Java) para que la gente pueda observar que lo comentado, efectivamente, es viable.

Respecto a la parte de síntesis de audio, se describirán los objetivos ya alcanzados en la “síntesis por tabla de ondas”, y se mostrarán unos cuantos midis de ejemplo, para que la gente pueda escuchar instrumentos midi creados con las sf2tools, demostrando que la creación de un banco de sonidos es algo sencillo gracias a dichas herramientas (y a otras relacionadas, como es timidity).

A poder ser, se intentará explicar el funcionamiento básico de la “síntesis FM”, más que nada para que la gente adquiera mayor conocimiento al respecto, pues la verdad es que es un tema bastante bonito. Es una de esas cosas que, siendo cotidianas, esconde secretos que jamás se te hubieran ocurrido. Sin embargo, probablemente éste punto quedará descartado, pues quizá es de menor importancia que los anteriores. A fin de cuentas, no vamos a utilizar síntesis FM en ningún momento. Más que nada, es curiosidad.

Me encantaría, si quedase tiempo, comentar otros proyectos de Software Libre relacionados con la música. Principalmente, editores de partituras, sintetizadores software, proyectos de recopilación de partituras, etc.

El proyecto OpenPipe (no me gusta decir “mi” proyecto, pues sería incongruente hablar de un proyecto de Software Libre y y referirse a él de forma posesiva) está orientado principalmente a un público quizás no tan técnico como un grupo de estudiantes de ingeniería, sino a personas que estén metidas en el mundo de la música. En concreto, he recibido varios correos de gaiteiros, que seguramente serán los que más uso le puedan dar.

A todos vosotros os iré contestando personalmente a medida en que mi escaso tiempo lo permita (perdonad si me retraso unos días). De todas formas, comentaros que la orientación del proyecto será principalmente práctica. En el sentido de que, por encima de todo, el objetivo será que obtengamos un instrumento que a todos os pueda resultar útil para tocar. Algunos me comentábais que ciertas implementaciones comerciales no os agradaban por algunos aspectos. Aquí intentaremos, en la medida de lo posible, subsanar esas deficiencias. Pero siempre hay que tener en cuenta que los recursos son limitados, lo que no quiere decir que algún día OpenPipe no pueda llegar a ser, algún día, un proyecto muy bueno, como ha sucedido con otros proyectos de Software Libre.

Una cosa que le extrañará a mucha gente es: ¿Puedo construírme yo un controlador MIDI siguiendo las especificaciones de OpenPipe? Por supuesto, no hay ningún problema. De hecho, si necesitáis algún tipo de programación especial con el microcontrolador, os intentaría echar una mano.

Sin embargo, como soy consciente de que no todo el mundo tiene paciencia para andar construyendo un aparato así, intentaría (en la medida de lo posible) enviaros uno ya construído. Lo único que tendríais que abonar es el coste de cada una de las piezas, más el coste de la mano de obra de quien se encargue de ensamblarlo. Si alguien se toma la molestia de construírme las piezas y luego montar las partes, creo que es justo que reciba una cantidad por el tiempo que se ha dedicado.

OpenPipe no tiene ánimo de lucro. Lo que no quiere decir que en algún momento haya movimiento de dinero, para subsanar los gastos producidos por su distribución.

Otra cosa. La gente suele ser bastante impaciente, quiere obtener resultados en poco tiempo. Sin embargo, es habitual que los proyectos se retrasen, por una razón u otra. Aunque todavía no haya construído nada, durante varios meses hubo una labor muy intensa relativa a investigación. Realmente desde que tienes una primera idea hasta que empiezas a plasmarla en un diseño hay un camino muy largo. De hecho, incluso me matriculé en la asignatura Periféricos e Interfaces para tener una base con el tema de los microcontroladores. Además, por otro lado está el mantenimiento del blog, la difusión de las ideas, la publicación del código, de los diseños, la presentación, etc. ¡Y mis cinco asignaturas!… ¡Ah! Y bueno, hace un mes y algo me concedieron una beca en la biblioteca. Menos tiempo, menos tiempo…

Simplemente os pido un poquito de paciencia. Las cosas empezarán a salir poco a poco. Y tengo la confianza de que todo saldrá adelante. Seguro.

¡Un saludo muy grande a todos los que apoyáis el proyecto! Y recordad que vosotros también formáis parte del proyecto. Intentaré que todo el mundo sea tenido en cuenta…

Sobre los comentarios

Ahora que la cosa está un poco más tranquila, estoy contestando a todos los comentarios y correos que me quedaron pendientes por responder. Si alguien tiene interés en comentar algo que no esté relacionado con el proyecto, pero que esté dentro del tema del MIDI y la música por ordenador, no tengo ningún inconveniente en aportar mi punto de vista.

Es más, me encanta que haya preguntas tan dispares. Eso quiere decir que lo que he escrito en éste blog ha despertado la curiosidad de unas cuantas personas, lo cual es una satisfacción personal muy grande. La idea es que el Software Libre no es sólo Software, sino una gran cantidad de gente que aporta una gran cantidad de cosas en torno a un interés o una necesidad en común.

He recibido varios correos de gente muy entusiasmada por el proyecto. Algunos incluso me han comentado que estaban muy interesados en que les enviase un aparato a casa, ¡todavía no he empezado a construírlo! Pero la cosa va por buen camino. Hace una semana y poco he adquirido una tarjeta MCB9000 para programar una variante del 8051 de Philips, el modelo 89PLC935.

Si no tuviera que hacer cosas de clase, el proyecto evolucionaría mucho más rápido de lo que lo hace. Mis intenciones iniciales fueron muy ambiciosas, pero aún yendo con algo de retraso respecto a lo que tenía previsto, estoy muy contento por haber llegado hasta aquí. Ya se empiezan a ver cosas interesantes, como por ejemplo que es posible crear instrumentos musicales MIDI de forma sencilla, o el esbozo de lo que es el diseño de toda la circuitería.

Como seguramente habrá gente interesada en probarlo, estaba pensando en alguna forma de construír el diseño y mandarlo por correo. Sin embargo, hay algunos problemas que me gustaría solventar:

• En primer lugar, aunque sea un diseño Open Source, en caso de que la gente quisiera tener un aparato construido para uso personal, los gastos relativos a los materiales, construcción y envío correrían por su cuenta.
• Aunque haya dinero de por medio, eso no significa que haya interés lucrativo de por medio. Si consiguiese que alguien montase el aparato y lo enviase por correo, creo que sería justo que esa persona que dedica su tiempo a montarlo recibiera una cantidad, en concepto de mano de obra.
• El problema es que cuando hay tema monetario de por medio, se puede entrar en conflicto con proyectos similares a OpenPipe que, supuestamente, estarían en posesión de algún tipo de patente, puesto que alguien podría afirmar que hay un beneficio personal. Nada más lejos de la realidad, puesto que para implementar el diseño físicamente, es necesario un coste. Y ese coste está asociado a la implementación de un diseño, como si es cualquier otro.

¿Qué opináis? Es un debate interesante.