(Note: I wrote this as something to tell to the clam-devel mailing list about some of my source-code commits)

About eight months ago, there was a foundation of something like an “audio club” in my university [1]. As soon i learned about that, i quickly got in touch with them and noticed that there was a major interest in analog issues (the only audio area with at least elective, courses in the university). So i told them about all the cool things that are available and ready to do with digital audio, mostly signal processing related. I talked in general, but of course i also talked about clam, with all its prototyping, real-time and easy development of plugins features. Even many of them ended installing and using it, and some even developing with more or less help. One thing to notice is that most of them are students from first years and most (but not all) are students with a basic programming level (because they are from electronics) but strong dsp knowledge (behind this is an university with more emphasis in theory than practice)
We started specifying plugins from a more abstract level (inputs/outputs/controls) and generating the source code base using
CLAM’s Templated Plugins Code Generator [2] and prototyping some simple applications. But one of the things we ended up doing was to take advantage of clam as platform to prototype medic related applications like filter ECG signal from noise in realtime, and some like _vice-versa_, i mean applying some processing knowledge from that area to audio.

Some of that work (one hour per week average) it’s now in the repo, most remarkable i think are filters work, by above the adaptative notch one (which even was used as a demo of a talk of one of the members about the steepest descent algorithm and its application to filter ECG signals)

Some development screenshots:
http://clam-project.org/wiki/Image:FilterByCoefExample.jpg
http://clam-project.org/wiki/Image:FilterExample-LP-HP.jpg
http://clam-project.org/wiki/Image:ThreeBandFilterOutputWithWhiteNoiseAsInput.jpg
http://clam-project.org/wiki/Image:GaussianWhiteNoiseHistogram.jpg
http://clam-project.org/wiki/Image:UniformWhiteNoiseHistogram.jpg

[0] FIUBA: Engineering Faculty of Buenos Aires University
[1] Group: http://code.google.com/p/club-audio-fiuba
Source code repo: http://groups.google.com/group/club_de_audio_fiuba
[2] http://audiores.uint8.com.ar/blog/2009/08/17/showing-a-little-about-clam-as-a-prototyping-tool-at-the-audio-club-of-fiuba/

algorithms , audio , blog , c++ , CLAM , ClubAudioFiuba , effects , english , free software , GPL , ideas , math , matlab , news , noise , plugins , programming , projects , python , signal processing

Share This/Compártelo

Hace un tiempo, cuando le regalé a mi hermana un afinador para violín, para mi sorpresa (por que lo ignoraba) me enteré que hasta los afinadores más baratos incorporan el afinado por vibración (de la madera). Esto es muy conveniente por que elimina ruidos externos de una manera natural, algo imagino casi imprescindible para un violín tradicional (sin micrófonos) que en general se afina en presencia de otros instrumentos de una orquesta. Lo que se hace es colocarlo en alguna parte del instrumento con una especie de prensa que tiene para que quede bien sujeto. La verdad que me gustó.

(el afinador era un: matrix gt2)

acoustics , audio , Castellano , hardware , instruments , lutheria , noise , sound

Share This/Compártelo

Hoy vi el video demostración de TAPESTREA: Techniques And Paradigms for Expressive Synthesis, Transformation, and Rendering of Environmental Audio (también conocido como taps). Intenta ser un entorno para el diseño de sonido, pero desde un enfoque totalmente nuevo (lo mejor es ver el video para entender mejor de que se trata).

Me llamó la antención (además de la división del sonido entre sus componentes sinusoidales, transitorios y residuo), la interfaz gráfica intuitiva y sencilla y la manipulacíón de sonidos en el espectrograma.

TAPESTREA: Sound Scene Modeling By Example - For more funny movies, click here

 
El video completo esta disponible aca: http://soundlab.cs.princeton.edu/listen/taps/tapestrea.mov
 

Según su web, la idea es ser un framework unificado para analizar de forma interactiva sonidos complejos, transformarlos y sintetizarlos:

• Identificar puntos de interés en el sonido y extraerlos para crear “templates” (una muestra/un sample) reusables
• Transformar componentes de sonido de forma independiente a su entorno y otros eventos sonoros
• Resintetizar continuamente las texturas de fondo de una forma perceptualmente convincente
• Posicionamiento de eventos “templatizados” sobre la escena de fondo por medio de una novedosa interfaz de usuario o scripts escritos en Chuck (un lenguaje de programación orientado al audio)
• Recuperación de componentes de sonidos basandose en la similaridad con otros.

TAPESTREA otorga una nueva forma de transformar dinámicamente una escena de sonido, permite generar puestas de cualquier duración, facilita la composición y el diseño de sonido combinando elementos de diferentes grabaciones de forma muy sencilla y ofreciendo miles de variantes para su manipulación (solo pensar en las posiblidades que otorga el solo hecho de poder manejar por separado sinusoides, transitorio y residuo).

Sin duda, una herramienta de trabajo interesante tanto para “diseñadores de sonido” como invesitigadores del audio, compositores y cualquier persona interesada en experimentar con el sonido.

Por si todo esto fuera poco, es Software Libre y multiplataforma. El código fuente y los binarios se consiguen aquí.

Más info:

• Web oficial
• Artículo en Wikipedia
• Artículo en linuxjournal

audio , Castellano , Chuck , effects , free software , GNU/Linux , GPL , music , noise , programming , signal processing , sound

Share This/Compártelo

Andrés Kasulin, a friend of mine from the University gave me some light about the issue of SMS interference (check “Catching (phone) SMS pulse train with CLAM…“)

He says in a comment from that post:

“I’ve found nice data in wikipedia[1].

It seems to be radiofrequency interference produced by the the phone, and filtered by the mic-cable-probes-osciloscope system. I think there is only a square pulse because the carrier frequency is much higher than filter cutoff frequency (maybe near 10^5 times).”

[1] http://en.wikipedia.org/wiki/GSM#Radio_interface

 
 

I’d add from that article:

“A nearby GSM handset is usually the source of the “dit dit dit, dit dit dit, dit dit dit” signal that can be heard from time to time on home stereo systems, televisions, computers, and personal music devices. When these audio devices are in the near field of the GSM handset, the radio signal is strong enough that the solid state amplifiers in the audio chain function as a detector. The clicking noise itself represents the power bursts that carry the TDMA signal. These signals have been known to interfere with other electronic devices, such as car stereos and portable audio players. This is a form of RFI, and could be mitigated or eliminated by use of additional shielding and/or bypass capacitors in these audio devices. However, the increased cost of doing so is difficult for a designer to justify.”

Very thanks Andrés!

audio , english , hardware , noise

Share This/Compártelo

From today I’ll try to start blogging a little more about my gsoc progress…

First of all I was adding bounded limits to many transformations, a task that taught me a lot about CLAM infrastructure (good suggestion pau!), then I had pitch discretization working in NetworkEditor (new network) and built a prototyped example (this taught me about how to make GUI prototypes with QTDesigner). I also worked in some minor bug fix and new features like add set default value to InControls.

 
 
 
Indeed I had wrote a couple of unit tests too (something very easy, but totally new for me). I have to say that testfarm and automatic testing are very cool features for this kind of development.

Testfarm looks like this:

 
 
 
I’ve also added a new network for hoarseness, I think very useful as first aproach to work with Sinusoidal+Residual models (SMS)

 
 
Anyway, most of my work was with SMS Harmonizer, but that is for a forthcoming post.

audio , CLAM , effects , english , GSoC2007 , GUI , noise , programming

Share This/Compártelo

CLAM es un completo framework para hacer investigación y desarrollo sobre audio y música (esto también incluye aplicaciones para usuarios finales). Ofrece un modelo conceptual y herramientas para el análisis, la síntesis y el procesamiento de señales de audio. Tiene una interfaz muy amigable, es Software Libre, multiplataforma y esta escrito en C++ (en muchas de sus aplicaciones utiliza tiempo real).

A pesar de que tuvo su origen en una Universidad de Barcelona, España, la documentación en español sobre este framework es escasa, asi que me decidí a hacer una pequeña introducción sobre las cosas básicas, pero con links (eso si, la mayoria en inglés) para el que quiera ir más allá. Pienso que le puede servir a más de uno para empezar.

Básicamente hay dos perfiles: el de usuario final (de las aplicaciones) y el de desarrolladores que quieran escribir sus propios programas sobre este framework.

En este momento se compone de 4 programas principales:
 
NetworkEditor:
Es una aplicación que permite conectar módulos en forma de red de procesamiento al estilo pd (pero mucho más amigable), MaxMSP o Reaktor (o para los que usan matlab, tipo simulink). Estas redes se ejecutan en tiempo real y se pueden correr con jack, portaudio, LADSPA o VST como backend.
Una de las características más interesantes es que esta red se puede exportar y después correr con una interfaz gráfica diseñada con QTDesigner (ambos programas exportan a un xml que luego se corre con la aplicación Prototyper)

Recomiendo ver esta presentación: “Visual prototyping of audio applications”

Es decir, un usuario que no es programador puede armar complejos plugins o aplicaciones sin escribir una sola línea de código. También es muy útil para armar prototipos de futuras aplicaciones o desarrollos.
En este momento se esta integrando con LADSPA, lv2 y se planea reforzar aún más la posibilidad de usar plugins externos (como un módulo más) dentro del NetworkEditor y vicerversa, usar estas redes como plugins en otras aplicaciones.

Para el que quiera empezar, recomiendo esto:

• NetworkEditor tutorial
• Jugar con las varias redes de ejemplo que están en el directorio ‘example-data’

 
Annotator:
Es un programa para hacer transcripciones, en el estilo de Sonic Visualizer. Muy potente y con características que lo hacen único.

Para conocer más:

• Annotator tutorial
• Annotator: reconocedor de acordes en canciones
• Artículo en linuxjournal
• CLAM Music Annotator, chord analyzer

 
SMSTools:
Un analizador de señales de audio en el estilo de wavesurfer que soporta diferentes tipos de visualización como spectogramas, y todas las derivadas del módelo Sinusoides + Residuo asi como trasnformaciones complejas basadas en este modelo (gender change, pitch-shifting, morph, etc) y muchas otras cosas más (ver tutorial).

 
Voice2MIDI:
Convierte voz en MIDI. Esta comentado en este artículo de linuxjournal.

 
Para desarrolladores, sirve como entorno para realizar sus propias aplicaciones de forma fácil o como herramienta para hacer prototipos de sus futuras implementaciones.

Recomiendo:

• Empezar por la página wiki de desarrollo
• Anotarse en la lista de desarrollo y unirse al canal #clam en freenode
• Leer estos tutoriales “Constructing and playing a simple network“, “Loading and playing a simple network“, “Creating a minimal processing object” (hay varios más)
• El código esta bastante bien documentado, se puede consultar la versión online

Si uno quiere, puede aportar al proyecto mandando ‘patchs’ de código a los desarrolladores principales y hasta convertirse en ‘developer’ luego de haber mandado varios de ellos.

 
En fin, es un proyecto bastante grande y ambicioso. Incluso hay miles de desarrollos más sobre el mismo que no están en el ‘paquete principal’, pero me pareció útil dar un panorama general porque tal vez sea tan abarcativo que maree un poco para el que recién escucha algo de él.

Como ya dije, es multiplataforma y esta disponible para GNU/Linux (con paquetes para varias distribuciones), Windows y Mac (ver más y descargar)

Otro links interesantes:

• Página principal
• Wiki
• Approaching CLAM, where to start
• Artículo en linuxjournal

algorithms , audio , c++ , Castellano , CLAM , effects , free software , GNU/Linux , GPL , GSoC2007 , GUI , libraries , library , midi , music , noise , programming , projects , publications , signal processing , speech , standards

Share This/Compártelo

Es un modelo de análisis/síntesis para procesamiento espectral orientado a aplicaciones musicales y de audio. Se puede ver como una generalización de la STFT (transformada de tiempo corto) y los modelos sinusoidales. Básicamente añade flexibilidad a la STFT manteniendo buena fidelidad de sonido y una representación eficiente.

Este modelo también es conocido como SMS (Spectral Modeling Synthesis) y como HILN en el contexto de MPEG4.

Básicamente esta modelado como la suma de un conjunto de sinusoides (los “sobretonos” estables armónicos o no, las componentes determinísticas del sonido) más el residuo de ruido (modelado como un proceso estocástico) como dos componentes separadas:

donde y son la amplitud y fase instantaneas de la sinusoide respectivamente, y es la componente de ruido en el tiempo .
La fase instantanea de la ecuación es:

El primer paso del análisis detecta los sobretonos presentes en el espectro y los representa con sinusoides que varian con el tiempo . Luego se le resta al sonido original las componentes sinusoidales para obtener el “residuo” (ver el diagrama de bloques).

La señal residual es modelada como un proceso estocástico y se describe como ruido blanco filtrado:

donde es ruido blanco y es la respuesta al impulso de un filtro que varia con el tiempo evaluada en el instante .

El residuo comprende la energía debida a vibraciones no estacionarias y a cualquier otra componente energética de naturaleza no sinusoidal.

Algunas áreas donde este modelo se puede aplicar:

• análisis
• compresión de sonido
• separación de fuentes de sonido
• acústica musical
• percepción musical

Algunos links con más información sobre este modelo:

• Xavier Serra: “Musical Sound Modeling With Sinusoids Plus Noise“.
• Tesis de Xavier Amatriain: “Sinusoidal plus Residual Model“
• Libro DAFX: Chapter 10 - Spectral Processing.
• CLAM SMSTools: Introduction tutorial, more details.

Este tipo de cosas me hace acordar que tengo que postear sobre la tesis de Juan Vuletich: “Nuevas bases para el procesamiento de música en el dominio tiempo-frecuencia” (aca un paper sobre la misma idea) un enfoque diferente para este tipo de cosas (wavelets) que pienso que merece (como mínimo) un post entero lo antes posible.

audio , Castellano , CLAM , GSoC2007 , noise , publications , signal processing , sound , standards

Share This/Compártelo

Is an analysis/synthesis model for spectral processing oriented to audio and music applications. We can see it as a generalization of STFT and sinusoidal models, basically adds more flexibility to STFT while maintaining a good sound fidelity and efficient representation.

This model is also known as SMS (Spectral Modeling Synthesis) and HILN in the context of MPEG4.

Basically is modeled as the sum of a set of sinusoids (only the stable partials of a sound, harmonics or not, deterministic components) plus a noise residual (modeled as stochastic process) as two separate components:

where and are the instantaneous amplitude and phase of the sinusoid respectively, and is the noise component at time .
The instantaneous phase of the equation is:

The first analysis step detects partials present in the spectra and represents them with time-varying sinusoids. Then the sinusoidal component is subtracted from the original sound to obtain the remaining “residual” (see the block diagram).

This residual signal is modeled as stochastic process and is described as filtered white noise:

where is white noise and is the response of a time varying filter to an impulse at time .

The residual comprises the energy produced by not stationary vibrations plus any other energy component that is not sinusoidal in nature.

Some areas where this model could be applied:

• analysis
• sound compression
• sound source separation
• musical acoustics
• music perception

Some links with more info about this model:

• Xavier Serra: “Musical Sound Modeling With Sinusoids Plus Noise“.
• Xavier Amatriain’s Thesis: “Sinusoidal plus Residual Model“
• DAFX book: Chapter 10 - Spectral Processing.
• CLAM SMSTools: Introduction tutorial, more details.

These kind of things remembers me that I have to post about Juan Vuletich thesis: “New bases for music processing in the time-frequency domain” (ATM only in Spanish, here a paper about the same idea) a different approach of those kind of things (wavelets) which I think deserves a (at least) an entire post ASAP.


audio , CLAM , english , GSoC2007 , noise , publications , signal processing , sound , standards

Share This/Compártelo

Hoy voy a comentar sobre un tema que generalmente no se asocia con el audio, aunque en realidad es toda una rama de estudio del mismo: hablo del ruido. Pero el enfoque que le voy a dar es el del mismo en las computadoras personales, para muchos, nuestra principal herramienta de trabajo y ocio. Y como en general a todos los que nos gusta el audio y la música (parte de la temática de este blog), generalmente somos más sensibles (y nos molesta más) que a otros; soportar varias horas por día una colección de ventiladores (que a veces nos recuerdan más a una fábrica en producción que a una pc), puede tornarse insoportable. Asi que voy a volcar aqui todo lo que aprendí en “mi búsqueda” por lograr una pc silenciosa.

Por empezar, el ruido en las computadoras personales proviene de las partes móviles de las mismas y para encarar el problema (o “recomendaciones a seguir para lograr una pc silenciosa”) las voy a dividir en dos grupos:

1. Los ventiladores o coolers, usados para refrigerar los componentes (fuente, procesadores, etc)
2. Dispositivos mećanicos: partes móviles de CDROM’s, discos rígidos, etc.

Para analizar el primer grupo es importante conocer lo siguiente: el ruido que generan es proporcional a su velocidad de giro, generalmente medida en rpm (revoluciones por minuto) y esta es proporcional a su tensión de alimentación (medida en Volts). Por otra parte el volumen de aire que mueven también es proporcional al diámetro de los mismos, asi que hay que tratar de que sean lo más grandes y “lentos” posible. La primera opción es tratar de eliminarlos, pero generalmente es complicado lograr niveles similares de enfriamento por otros medios y suele ser extremadamente caro[1], asi que lo que se termina haciendo es usar otros sistemas de refrigeración que también usen ventiladores, pero como método complementario y que requiera mucho menos volumen de aire (menos rpm y por lo tanto menos ruido) como por ejemplo:

• Watercooling (refrigeración con agua u otro líquido refrigerante) donde hay un radiador enfriado por un ventilador a bajas rpm.

• Disipadores de mayor tamaño o más eficientes (por ej. heatpipes + ventilador a bajas rpm).

Los disipadores+coolers de los procesadores que vienen en box (AMD al menos) son muy ruidosos y en general hace más ruido este cooler que el de cualquier fuente, asi que es muy recomendable cambiarlos. Los sistemas que usan “heatpipes” (un mecanismo para disipar el calor[2]) son muy buenos. Tienen unos tubos cerrados (pipes) conectados con la fuente principal de calor por los que al calentarse el líquido que tienen dentro, este se evapora y sube hasta el otro extremo donde hay unas placas horizontales u verticales separadas por unos milímetros a las que le transfiere el calor y se condensa al enfriarse, la idea es que estas placas ayuden a disipar (por superficie, además notar que hay aire entre ellas) por lo que se les pone un ventilador encima para enfriarlas y mejorar el rendimiento, que obviamente tiene muchos menos requirimientos de flujo de aire que el necesario para los disipadores “tradicionales”; incluso si no se exige mucho el procesador (no se usa constantemente para 3D, juegos, overclocking, etc) se puede llegar a prescindir del mismo (ojo!, no es lo recomendable). La parte mala es que son muy pesados (son de aluminio o cobre) y hay que tener más cuidados con la máquina (por ej. hay que sacarlos si se la va a transportar porque por el peso y la fuerza que hacen pueden romper el motherboard). En este punto también hay que tener en cuenta que los Intel suelen calentar más que los AMD y por lo tanto son más “complicados” y se requieren mejores disipadores y mayor volumen de aire por parte de los ventiladores. Lo recomendable es averiguar cuales son las temperaturas normales de trabajo de cada procesador y hacer una especie de análisis, fijarse los valores que arrojan los sensores de temperatura e ir modificando las rpm de los ventiladores hasta lograr un régimen aceptable de temperatura y ruido. En fin, hay que tener un poco de cuidado (no me hago responsable, jeje) porque algunos componentes pueden “quemarse” y quedar inservibles.Lo mismo para los ventiladores de las fuentes, que tienen que ser grandes y lentos (o no tener, pero son muy caras[1]).
Ver también la Tecnología Cool’n'Quiet de AMD.

Read the rest of this entry »

acoustics , audio , Castellano , español , hardware , noise

Share This/Compártelo