No soy un 'pringao'

¿El o la desocupado o desocupada lector o lectora que llegaron hoy todavía no saben qué es ser un pringao?

Entérense aquí de qué es eso.

Desde ahora he decidido y poner en claro que:

• Me importa un pepino si no saben cómo borrar sus archivos.
• Me importa un pepino si no saben cómo cambiar el tamaño del buffer de Max-MSP
• Me importa un pepino si no saben la diferencia entre audio y MIDI y no están en mi clase de Taller MIDI.
• Me importa un pepino si no saben cómo conectar un micrófono a un computador, grabadora, dispensador de post-its, cafetera o cualquier otro dispositivo de cualquier índole y no están en clase conmigo para que les enseñe eso.
• Me importa un pepino si no les da la gana de buscar en Google.
• Etcétera.

Descubrí que mi generosidad tiene límites. Y me parece justo que la gente los conozca para que no se choque con eso y evitar molestias.

Cito a la prof. Catalina Leonor Peralta Cáceres con el único consejo tecnológico verdaderamente útil y trascendente que me dió en la carrera: "Mira el manual". Aplíquenlo todos.

Únicamente pondré mis recursos informáticos, mentales y temporales al servicio de alguien si el proyecto me interesa o si hay ayuda de vuelta en otro aspecto o algún tipo de contraprestación.

Creo en el trueque: Cosas útiles por cosas útiles.

Máquinas deliciosas (2.1)

###ATENCIÓN: PUEDE CONTENER
LENGUAJE TÉCNICO MODERADO Y
ALGO DE CONTENIDO SEXUAL###

Hedonismo digital. Esa frase puede describir mi estado momentáneo. Uno va descubriendo lo que puede hacer con sus máquinas y cómo eso ayuda a descubrir el propio trabajo, sus potencialidades y la manera de percibirlo. Esos descubrimientos a veces pueden llevarme de intenso placer. En este caso una erotización del oido.

Como una de las pruebas que le he aplicado a un nuevo amigo que trabaja conmigo, hice una realización (quiero decir: renderización, para los espanglistas) de una obra mía que normalmente tarda 12 minutos más o menos en llevarse a cabo, bastante considerando que la pieza dura seis minutos cuarenta segundos.

Ficha técnica de las pruebas anteriores: Las pruebas habían sido hechas en dos computadores: un PowerPC G4 de 1.03GHz bajo Mac OS 10.3 y un Pentium IV de 2.4GHz bajo Fedora Core 5, ambas con resultados similares.
Ficha Técnica de la actual prueba: Intel Core Duo de 2.16GHz bajo Mac OS 10.4.

La realización en todos los casos fue de un archivo estéreo en calidad de audio de CD, o sea 44.1KHz con muestras de 16 bits.

Lo primero realmente impresionante de la prueba de hoy fue el tiempo que se tomó en completarla 107,909 segundos, según la terminal, es decir menos de minuto y medio, menos de una sexta parte de lo que se toman los otros dos compus. Igual, esto no es suficiente para erotizar mi oido, ya que el resultado sonoro en los tres casos fue exactamente el mismo.

Después de estar realmente impresionado por unos segundos, hice un par de modificaciones al archivo de Csound de la pieza (si no entienden, pregúntenme, con gusto les explico) para aumentar la resolución del 'renderizado' a 48KHz con muestras de 24 bits. La muestra usada para la granulación en la pieza estaba grabada a calidad CD, fue convertida a 48/24. (Lástima no haberla podido grabar en ese momento con una calidad mejor).

La primera sorpresa es que se demoró 112,284 segundos. Solo un poco más aumentando el número de valores por muestra de 65.536 cada cuarentaicuatromilcienésima a 16'777.216 cada cuarentayochomilésima. Casi el doble de datos con 5 segundos de diferencia, pero eso todavía no es lo más chévere.

Resultado sonoro = ¡Que delicia! Era como si la obra se hubiera quitado un velo de encima. Había muchos más planos de los que mi anterior realización me dejaba oir, había mucha más profundidad, más claridad en la parte alta del espectro, la pieza se acercaba más a su objetivo inicial (leer en el vínculo que lleva a la página de la pieza para ver de que hablo).

La gocé más que nunca. Quedé con ganas de sonar. Quedé 'aurotizado'.

Esta obra -hasta donde he percibido- no ha sido de gran acogida entre mis desocupados escuchas, pero a mí me fascina y más con mayor resolución.

¿Será que la prueba cuadrafónica a 96KHz/24 bits aumentará el efecto 'aurótico'?

Hagan clic aquí para acceder al código y los archivos necesarios para que mis desocupados lectores que se arriesguen hagan las pruebas. De paso, pueden subscribirse al podcast de música y darse un paseo por el sitio (aún en construcción) y mirar.

Como siempre: Bienvenidos y esperados los comentarios.

El sonidista sordo

Que bueno que se oiga mucha música, que bueno que haya gente que quiera mostrar su música, que bueno que haya dónde oírla y mostrarla. Cada vez hay más sitios dedicados a que la gente pueda compartir sus sonares y oíres. Eso me parece simplemente bueno.

Aún así, en el creciente número de salas públicas en las que se oye música en Bogotá hay una también creciente condición que me parece contradictoria: Muchos de los que se encargan del sonido en estos lugares no se molestan en escuchar lo que hacen.

El papel de un sonidista es encargarse de que el sonido sea proyectado o amplificado de la manera más acorde con la clase de sonido que sea (discurso, música de uno o de otro tipo...), con la sala y con el equipo disponible y hacer que el contenido causal, semántico o puramente sonoro (véase abajo) llegue de la mejor manera posible al escucha.

Muchas veces para los asistentes a una sala en la que hay sonido amplificado, el sonidista es un ente anónimo, que cuando lo vemos está detrás de un montón de aparatos o encerrado en un cubículo atiborrado de objetos esotéricos e inaccesibles para muchos.

Lo grave empieza cuando no lo detectamos por los ojos, sino por los oídos.

La labor de un sonidista es una de esas labores que deberían ser invisibles, de las que es mejor no darse cuenta que existe. En la que si no se nota que este sonido está siendo deliberadamente alterado -está siendo amplificado, ecualizado, proyectado, etc.- se nota que el sonidista un buen profesional. Un artesano que no deja huella de la herramienta.

Uno de los retos comunes a estos trabajadores sonoros es enfrentarse al ya referido 'aparato esotérico' o las máquinas propias de la profesión, unas veces más complejas que otra, pero siempre máquina: inhumana y hasta cierto punto 'objetiva', es decir, que hace exactamente lo que se le dice en la mayoría de los casos, no toma decisiones con respecto al resultado final y no puede ir más allá de sus capacidades. Aprender a usar el aparatico ya es bastante, aprender a echar cable y parlante y a desenvolverse entre una mesa y/o pared de aparatos esotéricos es un oficio que requiere atención y paciencia. Pero no lo es todo.

Es muy diferente saber que lo que se tiene enfrente está sonando -oír, llanamente- a que lo que está se tiene enfrente está sonando y está funcionando como se espera.

Cuando el sonidista pierde su transparencia es porque la máquina (la herramienta) demuestra el poder sobre el que la usa y tarde o temprano hace aparecer -a la fuerza- al cuerpo sin voluntad del trabajador sonoro amarrado por metros de cables y kilos de aparatos esotéricos que lo mueven como marioneta.

De las pocas personas que conozco dedicadas a este oficio, algunas tienen entrenamiento específico en este campo, otras tienen entrenamiento musical o tecnológico musical, otras tienen formación producto de la tradición oral, y otras tienen formación completamente empírica. Sin dar adjetivos a cada uno de estos caminos, he llegado a la perogrullosa conclusión de que esas formaciones diferentes pueden colorear, permear, la manera en la que se ejerce el oficio.

Un caso

No hace mucho fui a un concierto con dos amigos también músicos. No íbamos en el plan de oír pepas, como lo hace uno en tercer semestre o cuando eso es lo único que le interesa, sino de oir música en el Jorge Eliécier. El sonido del concierto fue aterrador, tanto como para hacer que el mayor y más experimentado de nosotros se tapara los oídos en cierto punto... Pensé algo, se oían las pepas, pero no la música, todo estaba claro y fuerte, pero no se entendía nada. Se me ocurrió que el sonidista debía haber sido entrenado como músico (hasta cierto punto).

En la profesión de músico, en la que uno aprende solfeo y armonía y contrapunto y algunas cosas más se tiende a privilegiar una escucha reducida que da prelación a las notas y al ritmo, más que al sonido como un todo. Se me ocurre que esto puede ser algo realmente problemático para un sonidista, porque se interesa más en las pepas que en el sonido mismo. Gravísimo.

Pierre Schaeffer define tres tipos de escuchas: causal o figurativa, que busca información con respecto a el cuerpo sonoro que emitiría el sonido y sus estados; semántica o codal, que busca información codificada en el o los eventos sonoros y por último la escucha reducida. Esta escucha reducida no atraviesa al sonido en pos de un significado más allá de este como la hacen las otras dos, sino que selecciona uno o varios parámetros del sonido para analizarlos, filtrando otros. Hasta cierto punto puede llamarse -discutiblemente- una sordera selectiva, de igual manera que una escucha selectiva. Sirve para el análisis y para el entrenamiento auditivo que le enseñan a uno de músico, pero como única escucha para hacer sonido en vivo.

Otro caso

En este caso no sólo se interpone el sentido del oído de quien proyecta el sonido, sino una buena intención mal dirigida.

A fines del 2005 se presentó en la Iglesia-Museo Santa Clara un montaje de danza contemporánea que incluia música hecha por J. B. Lully, mi persona y una mezcla de ambos. Ofrecí encargarme de la proyección sonora de la parte electrónica, pero ya habían contratado a una gran compañía de sonidistas para encargarse de esto, con el objetivo de hacer lo mejor posible para ese espectáculo.

Cuando llegué el día del estreno me encontré con un personaje muy amable con mucho gusto por lo que hacía encargado del sonido. Eso es realmente bueno. Cuando me contó cómo había hecho para preparar el sonido quedé atónito.... me mostró un rack lleno de aparatos esotéricos avanzadísimos que lo hacían buena parte del trabajo por él, de manera, que él podía delegar su labor.

El sonido llenó el lugar, pero lo ocultó. Todo estuvo ajustado de tal manera que se compensaran las características propias del lugar, así que mi conocimiento del lugar y mis reverberaciones delagadas al espacio no sirvieron de nada... no sonó mi música. Tanto me dolió que cometí una bobada, no cobré por ese trabajo.

(nunca vuelvo a sucumbir tan bobamente a mi orgullo, jamás, jamás, jamás...)

Coda

El elemento que no vemos y del que sólo podemos tocar la parte externa es el oído. Ese es tan fregado de entrenar como una voz, que es un instrumento que no se ve ni se puede tocar como una fagot, un computador o un tambor, sino que se tiene que sentir por dentro y extender las capacidades perceptivo-fisiológicas para entenderlo en su totalidad.

Enseñar a oír no es fácil y definitivamente requiere algo de actitud epicúrea hacia la vida.

Hay que confiar más en los sentidos.

El luthier digital

Con la pérdida de fuerza de los patrones dominantes en cuanto a la selección de alturas, de temas, de formas, de estilos que se dió en la música culta occidental a lo largo del siglo pasado también la instrumentación sufrió por muchas razones, entre ellas la aparición de los medios electrónicos, que ayudaron a re-pensar el sonido y las maneras en las que se puede producir.

El paradigma del instrumento, como el objeto productor de música es uno de los que permanece y todavía está bien parado en la música electroacústica.

Construir un instrumento hecho de átomos -o sea tangible y en algunos casos tocable- es como tocar un instrumento de hecho átomos. El que hace un buen instrumento es alguien que ha perfeccionado sus destrezas a lo largo de un proceso -valga la redundancia- largo y lleno de trabajo duro y de una gran disciplina. Las características básicas de un instrumento hecho de átomos, como una guitarra son las mismas, sea hecha por el guitarrero tradicional, por la inmensa fábrica de Yamaha en Corea o por un artesano especializado en instrumentos de concierto altísimo nivel. Sin tener en cuenta las variaciones en el diseño básico del instrumento que pueda tener tal o cual fabricante, es claro que toda la diferencia está en los materiales y la destreza del constructor.

En la música por computador, cuando uno diseña un instrumento, uno diseña un algoritmo. Este algoritmo no sólo puede ser hecho para ser capaz de calcular el valor de cada una las muestras de audio digital que representarían una forma de onda correspondiente al sonido o clase de sonidos que se quiere hacer, sino también puede ser un procesador de sonido, como un filtro, un instrumento agente de composición, generando eventos, por ejemplo 'notas' en el sentido tradicional de la palabra.

Aunque de muy diferente naturaleza, los dos oficios tienen algo clave en común: La pericia en el oficio, es decir la habilidad para el diseño y el uso apropiado de las herramientas es algo que se desarrolla a lo largo de la carrera.

Con frecuencia, los compositores de música por computador diseñan sus instrumentos exclusivamente para una pieza representando a veces estos el objetivo general de la pieza, como por ejemplo, en Stria de John Chowning, el instrumento que se usa en la pieza está construido de acuerdo con leyes similares de disposición de alturas y de disposición en el tiempo (forma, ritmo, envolventes...) que el resto de la pieza(1).

Salvo en el ámbito de la música experimental es raro que los compositores construyan el instrumento específicamente para una pieza. El instrumento es tradicionalmente una especie de object trouvé que es usado por el compositor de maneras más o menos recursivas, tanto como en el aspecto tímbrico como propiamente técnico.

El compositor electroacústico, en particular el de música por computador, rara, muy rara vez usa un instrumento electrónico (no como un theremin o una guitarra eléctrica, sino un instrumento digital) como lo encontró. Casi siempre hay algún tipo de variación, que va más allá de los eventos mismos, las 'notas' ya mencionadas, sino que se mete con el funcionamiento mismo del sonido para adaptarlo a la obra.

La debilitación de los paradigmas establecidos no sólo fue cosa de la música culta. La música popular se permeó de estas maneras de pensar u de hacer las cosas; y por esto no solo los electroacústicos que se dedican a trabajar con síntesis de sonido son quienes desempeñan este oficio de lutería digital, muchos con diversas profesiones dentro del campo de la música (como productores, DJs, programadores, por ejemplo) trabajan con instrumentos digitales y esto muchas veces se ven supeditados a lo que les da el instrumento prefabricado, estancándose frecuentemente en el convencionalismo y la norma tácita dictada por los ajustes de fábrica de las aplicaciones de audio o plugins.

Dicho esto, diría un servidor, que por la naturaleza de los medios que usa el músico digital, no solo el músico electroacústico, tendría como MANDATO en pro de la calidad de su trabajo el conocer las habilidades de la lutería digital e ir más allá del preset.

Como en los instrumentos acústicos, las herramientas cambian, pero las técnicas permanecen. Las herramientas comerciales de producción caen en la obsolescencia, por no decir que pasan de moda con rapidez, pero las técnicas debajo de ellas permanecen. Así que, profesores dedicados a enseñar a los compositores, productores y demás 'primos gremiales', enseñen cosas que ayuden a la conciencia del oficio, no a hacer el oficio a ciegas.

Tenemos que exhortar a los alumnos a ser luthiers/hackers. A expandir las capacidades de sus herramientas(2).

(1) A mis contados lectores, les recomiendo mucho esta obra es uno de esos pocos ejemplos en los que la consistencia de un sistema compositivo a lo largo, ancho y alto de la obra es efectiva. Eso sí al oirla, idealmente traten de que no sea la versión editada de la excelente colección Ohm, the early gurus of electronic music, que es una edición que dura aproximadamente cinco minutos, sino la original que dura casi veinte. Igual, asi esté recortada, se goza.

(2) Es recomendable, incluso saludable de leer y está muy en el espíritu de esta entrada de este blog este texto de Juan Reyes.

Otro tutorial más...

El exceso de información acerca de alguna cosa puede llevar fácilmente a la entropía. Este riesgo se corre frecuentemente en la comunidad de el software libre y más cuando se refiere a lenguajes de programación. Cada cual tiene una aproximación diferente a la enseñanza de este o de aquel lenguaje y por ende, aparecen cien mil quinientos treinta tutoriales y manuales 'alternativos' (asumiendo que haya uno principal). Todos terminan diciendo casi lo mismo, algunos se enfocan en algunos aspectos, otros dicen las mismas cosas en otro orden...

Como estoy metido en esto de la enseñanza de lenguajes de programación -como profe y como simple gomoso- me concierne hondamente eso del tutorial y creo que sería útil expresar la manera en la que creo -según creencias y experiencias- deben estar ordenados, estructurados o que contenido deben tener los tutoriales, aunque cien mil quinientos treinta otros profes, gomosos y/o desocupados con buenas intenciones hagan lo mismo.

Los contenidos

Hay tres elementos que identifico en los tutoriales que me han gustado, es decir, que han sido efectivos, y si no, al menos divertidos.

1. La introducción: Como buen curioso, me gusta ver que es y de donde viene lo que estoy aprendiendo, de manera que una introducción descriptiva e histórica es un gancho para el curioso.
2. Los ejemplos: Los métodos de trabajo, sintaxis, opcodes, objetos, etcétera deben ser demostrados en contexto, dentro de un programa prefabricado, de manera que se pueda ver cómo se interrelacionan los elementos y se construyen los programas (patchers, scripts o similares).
3. Los proyectos: Nada se aprende si no se aplica, así las aplicaciones iniciales sean banales (no más piensen en el omnipresente hello world!). Son una especie de exámenes para el autodidacta, en el que se tiene que poner a prueba la creatividad con los elementos ejemplificados.

Tres ejemplos de estructuras de la lección

Podríamos dividir el tutorial en dos niveles grandes, el bajo, de la lección particular y uno alto de la organización del conjunto de lecciones. Me gustaría citar tres ejemplos de tutoriales autodidácticos que conozco y que me han parecido en cierta forma efectivos, de los que puedo inferir tres estructuras típicas de lección, con ligeras similitudes y diferencias.

1. La lección es el ejemplo: los toots de Csound. En este caso, se muestra el código y se describe que es lo que hace, la tarea del autodidacta (me parece mejor que alumno) es copiar el código y hacerlo funcionar (1). De alguna manera no se ve una exhortación explícita a hacer alguna código por fuera del marco del toot.
   Nota: lo que más me gusta independientemente de sus cualidades pedagógicas es el nombre 'toots'.
2. Ejemplos + proyectos: Los tutoriales de Max. Aquí hay ejemplos precocidos(2) intercalados con ejercicios más o menos de libre realización. Estos tutoriales son especialmente de mi gusto por varias razones, pero aparte de la modularidad, el estar separados en fragmentos autocontenidos es el humor.
3. La lección es el proyecto: los tutoriales de las aplicaciones de Macromedia. Estos tutoriales están completamente basados en el proyecto. Se propone un proyecto (por ejemplo, hacer una animación interactiva en Director con ciertas características particulares) que se realiza paso a paso -sobre la aplicación. Es efectivo, pero me parece que estimula poco la creatividad por lo determinístico del proyecto.

Organizaciones de alto nivel

Aunque parezca que estoy hablando de síntesis granular, no. Sigo hablando de tutoriales ;-). Como se dijo arriba, la organización de alto nivel es la manera en la que están organizadas las lecciones (o bien, los conjuntos de lecciones más cercanas) unas con relación a las otras.

Aquí se me ocurren de primerazo dos tipos de organizaciones: Lineal y no lineal.

La organización lineal tiene las lecciones dispuestas en un orden -decidido por el redactor- de complejidad o de prerrequisitos para la siguiente. Este tipo de organización es muy práctica para principiantes, ya que se da una guia paso a paso para el entendimiento del lenguaje. En cuanto a los lenguajes de programación, el principio es casi siempre el hello world o algo similar.

Algo que me gusta bastante de esta organización es que si se es lo suficientemente astuto -y por que no, intrépido- se puede hacer una curva de enseñanza que poco a poco vaya dependiendo menos del profesor-tutorial y dando paso a proyectos cada vez más libres, en los que la invesigación propia sea determinante. Como dice Murray Schaffer:

(...)La primera tarea del maestro es programar su propia extinción (3).

La linealidad de un tutorial puede acompañar fácilmente un proceso así y es bastante práctica a la hora de ser utilizada en un entorno de clase, porque se puede decidir hasta donde llegar, dependiendo del progreso del conjunto profesor-alumnos.

La organización no-lineal no tiene un orden específico y a mi parecer presume conocimientos previos para las lecciones. Antes de seguir, no se tome que tomo esta preasunción como algo malo, símplemente es otro tipo de proceso. Un tipo de instructivo al que se podría asimilar esto sería un manual de referencia altamente ilustrativo, pero hay un texto en particular al que me gustaría más asimilar esto, las conferencias de física de Richard Feynman, en las que no recuerdo bien si el mismo Feynman o alguno de sus coeditores dice que las lecciones no tienen un orden particular, pero que presumen un conocimiento de álgebra y de las unidades de medida.

Otro aspecto interesante de la no-linealidad es la posibilidad de un tutorial hipertextual que se adapte a las búsquedas y necesidades del autodidacta.

En cualquier caso de no-linealidad, las lecciones deben estar bastante puntualizadas y ser casi completamente autocontenidas, lo que aumenta su tamaño y puede darse para varios niveles de organización adentro de las lecciones mismas.

Todo esto para...

Toda esta cháchara el respecto de cómo creo se debe organizar un tutorial tiende a la necesidad de expresar las dudas, planes y alguna que otra certeza -si es que las hay- con respecto a la construcción de un tutorial en línea de Pd, que llevo rato escribiendo, aunque barajando sería mejor palabra. En este momento sólo se ha publicado la introducción y un apéndice, pero ahí, va, ahi va...

Siga este vínculo para llegar al tutorial en progreso.

Como siempre, se reciben y solicitan comentarios.

(1) En el caso particular de Csound el poner a sonar los ejemplos -o cualquier código- puede ser de por sí un reto más o menos difícil para el principiante, dependiendo del entorno o la plataforma.
(2) Léase: preporgramados o prefabricados, yo sé... es otra fijación gastro-tecno-erótica...
(3) Schaffer, R. Murray, El rinoceronte en el aula, pp. 17, ed. Ricordi Americana, Buenos Aires, 1998; publicación original, The Rhinoceros in the Classroom Universal Edition, Canada, 1975