Síntesis Digital de Sonido en Tiempo Real Por Modelado Físico de Instrumentos Virtuales de Cuerda Percutida

Universidad Nacional de Rosario
Facultad de Ciencias Exactas, Ingeniería y Agrimensura

Escuela de Ingeniería Electrónica
Proyecto de Ingeniería
Síntesis digital de sonido en tiempo real por modelado

físico de instrumentos virtuales de cuerda percutida
Autores: Nelly Lucrecia Villacorta,

Carlos Alejandro Marchiaro
Director: Ing. Federico Miyara

Asesora: Ing. Silvina Ferradal
Julio 2006
Síntesis digital de sonido en tiempo real por modelado físico de instrumentos virtuales de cuerda percutida
Síntesis digital de sonido en tiempo real por modelado

físico de instrumentos virtuales de cuerda percutida
Autores: Nelly Villacorta, Carlos Marchiaro

Director: Ing. Federico Miyara
Asesora: Ing. Silvina Ferradal
Facultad de Ciencias Exactas, Ingeniería y Agrimensura – UNR – Rosario, Argentina
Resumen
El presente informe se centra en el desarrollo e implementación de un
equipo electrónico, basado en DSP (Digital Signal Processing), que permite
generar sonido musical en forma interactiva (tiempo real) a través del
recientemente difundido método de Síntesis por Modelado Físico. Esta técnica
consiste en obtener un modelo físico-matemático de los elementos principales del
instrumento (excitador, resonador y radiador) y de su interacción mutua,
describiéndolos a partir de ecuaciones diferenciales y otros elementos
matemáticos. Conseguido el modelo físico, se implementa un algoritmo de
resolución por métodos numéricos que produce el sonido final por simulación en
tiempo real, a partir de un conjunto de parámetros que definen el instrumento
(propiedades geométricas y de los materiales, propiedades dinámicas, coeficientes
de roce viscoso, etc.), y de señales de control generadas por el intérprete. Dichas
señales ingresan al modelo en forma de acciones mecánicas que modifican el
estado dinámico de determinadas partes del mismo.
Junio 2006
Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 1

INDICE
INDICE ............................................................................................................................................................. 2
1. ESTADO DEL ARTE Y FUNDAMENTOS TEÓRICOS.......................................................................... 4
1.1. TIPOS DE SINTETIZADORES EN LA ACTUALIDAD ...................................................................................... 4
1.2. SELECCIÓN DE UN ESQUEMA DE SÍNTESIS ................................................................................................ 8
1.2.1. Tendencia en la actualidad ....................................................................................................... 8
1.2.2. DWG vs. FTM ....................................................................................................................... 10
1.2.3. Selección final ....................................................................................................................... 11
2. ANÁLISIS DEL MODELO FÍSICO ......................................................................................................... 12
2.1. MODELO DEL RESONADOR ................................................................................................................... 12
2.2. MODELO DEL MECANISMO DE EXCITACIÓN ........................................................................................... 13
2.3. MODELO DEL RADIADOR ...................................................................................................................... 16
3. ALGORITMO DE SIMULACIÓN............................................................................................................ 18
3.1. APLICACIÓN DEL MÉTODO FTM AL MODELO FÍSICO ADOPTADO ............................................................ 18
3.2. CÁLCULO DE COEFICIENTES DE LOS FILTROS IIR................................................................................... 21
3.3. CONSIDERACIONES PARA UN CÓMPUTO EFICIENTE ................................................................................ 22
3.3.1. Filtros IIR .............................................................................................................................. 22
3.3.2. Fuerza de contacto entre cuerda y martillo ............................................................................. 23
3.4. DESCOMPOSICIÓN ESTEREOFÓNICA DEL SONIDO ................................................................................... 24
3.5. OTRAS CONSIDERACIONES ................................................................................................................... 26
4. CONSIDERACIONES PARA LA IMPLEMENTACIÓN DEL MODELO ............................................ 28
4.1. CONSIDERACIONES GENERALES ............................................................................................................ 28
4.1.1. Dispositivo MIDI de control .................................................................................................. 29
4.1.2. Aplicación de software .......................................................................................................... 29
4.1.3. Dispositivo sintetizador.......................................................................................................... 30
4.1.4. Amplificador y reproductor.................................................................................................... 31
4.1.5. Interconexión de los equipos adoptados ................................................................................. 31
4.2. ESTIMACIÓN DE LOS REQUERIMIENTOS COMPUTACIONALES .................................................................. 32
4.3. ADOPCIÓN DEL DISPOSITIVO A EMPLEAR............................................................................................... 33
5. CARACTERÍSTICAS DEL DSKC6713 Y CODE COMPOSER STUDIOTM ........................................... 35
5.1. ESPECIFICACIONES TÉCNICAS DEL DSKC6713 ..................................................................................... 35
5.1.1. Disposición funcional de los elementos en la placa DSK........................................................ 35
5.1.2. Arquitectura de hardware del DSP ......................................................................................... 36
5.1.3. Memoria interna y externa ..................................................................................................... 38
5.1.4. Códec AIC23 ......................................................................................................................... 39
5.1.5. Emulador JTAG..................................................................................................................... 41
5.2. ENTORNO DE DESARROLLO CODE COMPOSER STUDIOTM ........................................................................ 41
5.3. DSP/BIOS ........................................................................................................................................... 41
5.4. RTDX (REAL TIME DATA EXCHANGE) ................................................................................................... 42
6. DESARROLLO DE LA APLICACIÓN HOST ........................................................................................ 44
6.1. MODALIDAD DE EDICIÓN ...................................................................................................................... 44
6.1.1. Parámetros de sistema............................................................................................................ 45
6.1.2. Funciones de edición ............................................................................................................. 46
6.1.3. Funciones de monitoreo ......................................................................................................... 49
6.1.4. Interfaz audiovisual................................................................................................................ 49
6.2. MODALIDAD DE CONTROL .................................................................................................................... 51
6.2.1. Parámetros de sistema............................................................................................................ 52
6.2.2. Funciones de control .............................................................................................................. 54
6.2.3. Funciones de monitoreo ......................................................................................................... 55
6.2.4. Interfaz gráfica....................................................................................................................... 55
7. DESARROLLO DE LA APLICACIÓN TARGET................................................................................... 57
7.1. ANÁLISIS FUNCIONAL DE LA APLICACIÓN ............................................................................................. 57
7.1.1. Datos de la aplicación ............................................................................................................ 59
7.1.2. Funciones de la aplicación ..................................................................................................... 61

7.2. DESCRIPCIÓN DE LOS PROCESOS INVOLUCRADOS .................................................................................. 69

7.2.1. Tarea de comunicación .......................................................................................................... 69
7.2.2. Tarea de simulación ............................................................................................................... 71
7.3. OPTIMIZACIÓN DEL CÓDIGO CRÍTICO .................................................................................................... 73
7.3.1. Método de optimización por Software Pipelining................................................................... 74
7.3.2. Optimización de la función simular.asm ................................................................................ 76
7.3.3. Optimización de la función conv_tabla_arm.asm ................................................................... 81
7.4. ANÁLISIS DE PERFORMANCE ................................................................................................................. 82
8. CONSIDERACIONES FINALES.............................................................................................................. 85
8.1. ANÁLISIS DE LOS RESULTADOS ............................................................................................................. 85
8.1.1. Señal sintetizada .................................................................................................................... 85
8.1.2. Latencia de los eventos de control.......................................................................................... 91
8.2. CONCLUSIONES .................................................................................................................................... 91
8.2.1. Consideraciones sobre los resultados obtenidos...................................................................... 91
8.2.2. Posibles extensiones del proyecto .......................................................................................... 92
8.2.3. Comentarios finales ............................................................................................................... 93
ANEXO A – APROXIMACIÓN POLINOMIAL DE LA FUNCIÓN POTENCIAL .................................. 94
ANEXO B – FUNCIÓN DE SUAVIZADO.................................................................................................... 98
ANEXO C – CÓDIGOS FUENTE DE SECCIONES CRÍTICAS.............................................................. 100
C.1. SIMULAR.ASM .............................................................................................................................. 100
C.2. CONV_TABLA_ARM.ASM ........................................................................................................... 116
ANEXO D – TERMINOLOGÍA MUSICAL............................................................................................... 120
D.1. SONIDO Y NOTA MUSICAL .................................................................................................................. 120
D.2. ESCALA MUSICAL .............................................................................................................................. 120
D.3. NOTAS DEL PIANO ............................................................................................................................. 121
ABREVIATURAS Y ACRÓNIMOS ........................................................................................................... 122
LISTA DE SÍMBOLOS PRINCIPALES..................................................................................................... 123
REFERENCIAS............................................................................................................................................ 124

1. Estado del Arte y Fundamentos Teóricos
En este capítulo se hace un análisis global de los diferentes esquemas de síntesis de sonido
existentes, y de su evolución a través del tiempo. Finalmente se adopta una técnica y se
definen las principales características del proyecto a realizar.
1.1. Tipos de sintetizadores en la actualidad
En la actualidad existen diferentes esquemas de síntesis de sonidos, que se clasifican de

acuerdo a la técnica particular empleada. La figura 1.1 resume los métodos que han surgido
desde los comienzos de la síntesis digital hasta el día de hoy [1].
FIGURA 1.1. Diferentes técnicas de síntesis digital de sonido
A continuación se da una muy breve descripción de cada uno de los esquemas mencionados.
i. Algoritmos Abstractos
Se trata de técnicas que producen sonido basado en una determinada fórmula

matemática, sin guardar, en general, una relación directa con sonidos o principios
acústicos subyacentes al mundo real. Al utilizar este método, es difícil predecir qué tipo
de sonido es producido por un algoritmo en particular, como también diseñar un algoritmo
que resulte en un sonido definido. Dentro de esta categoría se hallan los métodos
correspondientes a la clasificación tradicional conocida como “técnicas no lineales” que
comprenden la síntesis por FM (modulación frecuencial) y waveshaping. En el primer
caso un oscilador (modulador) controla la frecuencia de otro (portadora), como en el caso
del sintetizador DX-7 de Yamaha, lanzado en el año 1983*. En el segundo caso, se afecta
a una señal, usualmente una sinusoide, por una curva de transferencia no lineal,
produciendo un efecto similar a la saturación de un amplificador. Se ha empleado este
último esquema para imitar el timbre de ciertos instrumentos de viento.
*
Como se explica en la sección 2.1, la síntesis por FM guarda relación con un fenómeno físico presente en los
instrumentos de cuerda.

ii. Procesamiento de Muestras Grabadas
Corresponden a esta categoría los llamados samplers, cuyo principio de

funcionamiento consiste en grabar, procesar y reproducir sonidos. Aunque estrictamente
hablando esta técnica no crea sonidos desde cero, la misma ofrece una variedad infinita de
posibilidades, al grabar digitalmente sonidos reales o sintéticos, filtrarlos o editarlos, y
combinarlos con otras señales, hasta el punto de no distinguir el sonido original. Se trata
éste de un esquema altamente difundido en la actualidad.
iii. Modelado Espectral
Los modelos espectrales concentran su atención en las propiedades dentro del dominio
frecuencial de las ondas sonoras tal como son percibidas por el oído, desde un punto de
vista psicoacústico. En un principio, esta categoría incluía a las entonces llamadas
“técnicas lineales”, que comprendían la síntesis aditiva y la síntesis substractiva. La
primera consiste en superponer un conjunto de senoides de distintas fases, frecuencias y
amplitudes, para conformar un mapa espectral definido, el cual puede obtenerse por un
análisis de Fourier de una determinada forma de onda. La segunda técnica parte de una
señal excitadora, de gran riqueza espectral, la cual es procesada por medio de filtros de
segundo orden, los cuales emulan las resonancias del cuerpo del instrumento, que
caracterizan el timbre del mismo. Métodos más recientes tienen en cuenta el carácter no
estacionario de los timbres, y los caracterizan por la evolución temporal de sus
componentes espectrales. Otros esquemas modelan al sonido como una superposición de
componentes armónicas (parte principal) sumada a una componente de ruido (parte
residual), proporcionando una estrategia más eficaz para generar sonidos percusivos, allí
donde las demás técnicas de este tipo no son satisfactorias.
iv. Modelado Físico
Este es el esquema de síntesis en el que se hará mayor énfasis, no solo por ser el más
estudiado en la actualidad, sino porque es el marco en el cual se desarrolla el presente
trabajo. Se puede clasificar en dos categorías, de la siguiente forma (ver [2], [3], [4], [5]
para una descripción detallada).
1. Técnicas de dominio temporal
− Digital Waveguide (DWG)
Este método de “guía de onda digital” está basado en la solución de d’Alembert de la

ecuación de onda, es decir, el principio de propagación de ondas analizado como la
superposición de dos componentes viajando en direcciones opuestas. Este enfoque es
aplicable al modelado de ciertos instrumentos musicales (cuerdas, vientos, instrumentos
de metal, etc.). El modelo en sí está conformado por líneas de retardo, filtros digitales y
frecuentemente elementos no lineales. En principio éstos pueden verse como una clase
particular de esquema de diferencias finitas para modelado físico numérico. De esta forma
se modela la propagación de onda en medios a parámetros distribuidos tales como
cuerdas, tubos, bocinas, platillos, membranas y espacios acústicos.
La figura 1.2. muestra la implementación fundamental del método. Dos líneas de
retardo unidireccionales, implementadas como buffers cuya capacidad N representa la
longitud del medio unidimensional de propagación, donde el contenido es desplazado sin
alteración en cada paso de simulación hacia derecha o izquierda, según se trate de la
componente progresiva o regresiva de la onda total. Luego, en cada punto (posición de la

línea de retardo) donde se requiera la determinación del valor de la onda, simplemente se

calcula una suma algebraica de los valores correspondientes de ambos buffers.
FIGURA 1.2. Composición de la onda

resultante con DWG – (Fuente [3])
Un aspecto importante es que el efecto de las pérdidas distribuidas y la dispersión de

onda son concentrados en un conjunto de filtros digitales, dispuestos en puntos discretos a
lo largo de la línea de retardo, en la cual se manifiesta una propagación ideal. Es usual
combinar modelos distribuidos con modelos a base de filtros a parámetros concentrados.
La figura 1.3. ilustra el caso del modelo de un instrumento de cuerda accionado por arco,
donde puede verse la separación entre los dos tipos de componentes mencionados. La
onda viaja en una dirección, y luego de ser sometida al efecto de la excitación no lineal
(modelo del arco), concentrada en un punto intermedio de la cuerda, continúa su
propagación hasta la terminación (puente) donde una parte es transferida a la salida,
mientras otra (onda reflejada) es reinyectada en la línea de retardo inferior, donde se
propaga en sentido inverso al anterior. En el extremo izquierdo se asume una reflexión
total y sin distorsión, calculada como una ganancia unitaria negativa, para finalmente
cerrar el ciclo.
FIGURA 1.3. Modelo basado en DWG de un instrumento de

cuerda accionado por arco - (Fuente [3])
Este método, introducido por J. Smith en 1986 [5], es actualmente el más empleado
entre los métodos de modelado físico, y se ha implementado en versiones comerciales de
sintetizadores como ser el VL1 de Yamaha.

− Finite Difference Time Domain (FDTD)
En este caso se parte de una discretización directa de la ecuación de onda. Las

derivadas de segundo orden son reemplazadas por diferencias simétricas de segundo
orden, tanto para tiempo como para espacio. Este proceso resulta en una fórmula recursiva
para cada posición espacial, siendo la solución en cada punto calculada a partir de las
correspondientes a puntos adyacentes. Presenta la ventaja de requerir menor cantidad de
recursos en su cómputo, aunque el método es menos robusto numéricamente que el caso
de las DWG.
− Wave Digital Filter (WDF)
Este método se originó en la necesidad de simular el comportamiento de circuitos

analógicos conformados por elementos a parámetros concentrados. Este enfoque apunta a
un modelo electroacústico del instrumento. Si bien es muy robusto computacionalmente,
se centra en el estudio de elementos a parámetros concentrados, lo cual lo hace poco
eficaz para modelar fenómenos de propagación de ondas. Su rol es más bien
complementario de la técnica de DWG.
− Modelado Mixto
Como su nombre lo indica, resulta de integrar los anteriores enfoques de forma de

cubrir los diferentes aspectos del modelado de forma más versátil y efectiva.
2. Técnicas de descomposición modal
Los anteriores métodos DWG, WDF y FDTD son técnicas de simulación explícitas en
el dominio temporal. Las técnicas de descomposición modal emplean formulaciones de
los sistemas bajo estudio dentro del dominio frecuencial. En ellas se descompone el
comportamiento de un sistema en una suma de exponenciales decrecientes, donde las
componentes oscilatorias representan resonancias o autovalores del sistema.
− Síntesis Modal
Se trata de un esquema introducido a fines de los ’80, pero que aun así se adapta a
ciertas aplicaciones actuales. Consiste en representar una estructura vibrante como una
serie de osciladores elementales independientes, provistos de información de
acoplamiento. Cada oscilador modela un modo natural, y la información de acoplamiento
representa la forma geométrica de cada modo vibratorio en la estructura. Existen algunos
trabajos muy recientes [26] basados en esta técnica, que apuntan a resolver los fenómenos
oscilatorios en cuerpos 2D y 3D de geometrías genéricas.
− Functional Transformation Method (FTM)
El método de transformación funcional [6] es un esquema introducido recientemente

(Trautmann, Rabenstein, 2002) para la síntesis de sonido por modelado físico. Basado en
transformaciones integrales, provee una descripción paralela del sistema para cualquier
modelo físico lineal, usualmente descripto por un sistema de ecuaciones diferenciales
parciales (PDE). Tal descripción paralela puede ser implementada a través de un set de
sistemas recursivos elementales dispuestos en paralelo.

El procedimiento general comienza con una discretización del modelo en tiempo

continuo, de forma similar al proceso de discretización de los modelos de redes eléctricas
y otros fenómenos físicos descriptos por ecuaciones diferenciales ordinarias (ODE). El
primer paso consiste en aplicar una apropiada transformación a la ecuación diferencial, de
forma tal que el sistema en tiempo continuo queda representado por una función
transferencia. Luego ésta es transformada en un modelo en tiempo discreto. Cuando se
estudia un sistema multidimensional (MD), se requieren dos tipos de transformaciones:
una transformación respecto del tiempo, la cual resuelve el problema de condiciones
iniciales (IC), y una transformación respecto del espacio, que resuelve el problema con
condiciones de contorno (BC). Para ello se introduce la llamada Transformada de Sturn-
Liouville (T), que cumple un rol análogo a la Transformada de Laplace (L), pero aplicada
al caso del espacio en lugar del tiempo. Así se pueden convertir las ecuaciones
diferenciales en ecuaciones algebraicas ordinarias, al realizar un cambio de variables
donde, además de la usual frecuencia compleja ‘s’ se introduce la llamada frecuencia
espacial ‘μ'. La reagrupación de esta ecuación algebraica resulta en una función
transferencia multidimensional que modela el problema original. Para obtener la solución
se puede aplicar la clásica transformación análoga a discreta. Las transformaciones
inversas con respecto al espacio (Τ -1) y respecto al tiempo discreto (Z -1), resulta en un
sistema discreto cuya forma es especialmente apropiada para una implementación directa
con métodos computacionales. La figura 1.4. muestra el procedimiento general para
resolver el problema con condiciones iniciales y de contorno empleando el FTM.
FIGURA 1.4. Procedimiento general de resolución basado en FTM – (Fuente [6])
Mientras que para el caso de sistemas totalmente lineales la solución tiene asociada
una estabilidad inherente a los principios físicos subyacentes al modelo, en el caso de
sistemas no lineales esto no se cumple necesariamente. En [7], de los mismos autores de
[6], se explica cómo abarcar esta clase de sistemas, a partir de consideraciones energéticas
instantáneas. En [8] además se brinda un enfoque para una implementación alternativa del
método, que persigue optimizar el uso de recursos de procesamiento, derivando en
algoritmos altamente eficientes. De esta forma el campo de aplicación de este método se
vuelve muy amplio, no sólo para síntesis de sonido, sino para simulación en tiempo real
de diversos tipos de sistemas multidimensionales, descriptos en principio por un conjunto
de ecuaciones diferenciales parciales.
1.2. Selección de un esquema de síntesis
1.2.1. Tendencia en la actualidad
Un análisis cronológico de la evolución de las técnicas de síntesis de sonido desde sus

comienzos, permite sacar algunas conclusiones sobre la tendencia actual y futura en esta área.

A excepción quizás de los sintetizadores basados en algoritmos abstractos, todos los

esquemas, en mayor o menor medida, han buscado imitar, o al menos asimilar en su forma,
aquellos sonidos correspondientes a instrumentos musicales acústicos, o más en general,
cualquier sonido natural proveniente del mundo real, con una potencial aplicación a la
creación musical. Se ha argumentado a favor de esto último que si bien no es difícil generar
toda clase de formas de onda dentro del rango audible, no es nada sencillo establecer ni
mucho menos parametrizar los patrones acústicos que determinan que un sonido tenga valor
estético. El hecho de afectar el universo de variables de un conjunto de restricciones, las
llamadas leyes físicas, se traduce en una estructuración de las formas acústicas, imponiendo
determinadas pautas a las que nuestra percepción está más acostumbrada. La tendencia parece
ser la búsqueda de sonidos que resulten naturales, aun cuando no imiten instrumentos
acústicos clásicos, y dejar de lado los sonidos excesivamente sintéticos. Esto también implica
una forma más eficaz de controlar la forma del sonido producido, ya que el conjunto de
parámetros que lo definen está compuesto por magnitudes físicas de tipo geométrico
(longitud, sección transversal, forma del cuerpo del instrumento), estructural (relación entre
los distintos componentes del modelo), propiedades del material (elasticidad, momento de
inercia, densidad), dinámicas (masa, velocidad, presión, fuerza) y energéticas (disipación por
rozamiento, transferencia de un medio a otro).
FIGURA 1.5. Interfaz de control basada en

captación de movimiento – (Fuente [2])
Si bien las técnicas de modelado físico permiten imitar con alto grado de detalle algunas
clases de instrumentos, el interés real no se centra en el realismo, sino en qué tan natural y
expresivo es el resultado [9]. Actualmente se están desarrollando numerosas interfaces (ver
[2], [14]) que permiten al intérprete controlar en forma muy expresiva el mecanismo de
excitación (ver figura 1.5), y así introducir una cantidad de información lo suficientemente
grande como para producir una interpretación más “viva” que en el caso de los samplers y
otros esquemas más convencionales, que sólo reproducen una y otra vez el mismo sonido,
alterándolo en forma más limitada. En general, comparado con otros métodos, el esquema de
modelado físico es el único que puede recrear la riqueza, vividez y complejidad de los sonidos
naturales, pero también es el único que puede reproducir el sentimiento de interactividad
asociado a la ejecución de un instrumento acústico.
Mientras que en comparación con un sampler la demanda de memoria es mucho menor, al
estar los sonidos caracterizados por un pequeño conjunto de parámetros físicos en lugar de
almacenarse grandes bancos de grabaciones, la capacidad de procesamiento necesaria es muy
superior. Es por esto último que este esquema ha cobrado popularidad recién en los últimos
años, donde en el mercado está disponible una amplia gama de microprocesadores de alta
potencia computacional y bajo costo, mientras que a su vez existe un permanente desarrollo
de dicha tecnología.

1.2.2. DWG vs. FTM
Sin duda la técnica basada en DWG es la más popular hasta hoy, y motivo de mayores
investigaciones. Se basa en la analogía entre los mecanismos de propagación de ondas en
medios acústicos y eléctricos. Esta analogía es expresada matemáticamente por la ecuación de
onda, la cual es una descripción simplificada del fenómeno de propagación en sólidos y
fluidos. Analicemos a modo de ejemplo el caso de una cuerda tensa. La ecuación simplificada
queda expresada por la ecuación (1.1)
∂2 y ∂2 y
ρA 2 − TC 2 = f e ( x, t ) (1.1)
∂t ∂x
donde TC es la tensión de la cuerda, ρ es su densidad, A es su sección transversal y fe (x,t) es

la carga distribuida (fuerza por unidad de longitud) que excita la cuerda. La solución de esta
ecuación (D’Alembert) resulta en la superposición de dos formas de onda, una progresiva y
otra regresiva, que se propagan con velocidad de fase lineal con la frecuencia (sin dispersión)
y pérdidas nulas (sin atenuación), o en otras palabras, sin distorsión. Esto es lo que motiva el
enfoque de DWG, en el que simplemente se traslada con una determinada velocidad una
forma de onda, simulando la forma más elemental de propagación. Como desde un punto de
vista acústico son muy importantes la dispersión de onda (velocidad de fase no lineal) y
atenuación, éstas deben introducirse como complemento del modelo, no siendo inherentes a
él, ni estando totalmente integradas al mismo, y siendo sus parámetros de dificultosa
estimación
Mientras tanto, el enfoque de FTM se presenta como un método más sólido y completo, al
ser su aplicación independiente de la forma de la solución, y adaptable a cualquier sistema
que sea expresable en términos de ecuaciones diferenciales. Consideremos la expresión (1.2)
que amplía a la (1.1) [10]
∂2 y ∂4 y ∂2 y ∂y ∂3 y
ρA + EI − TC + d 1 + d 3 = f e ( x, t ) (1.2)
∂t 2 ∂x 4 ∂x 2 ∂t ∂t∂x 2
Aquí E es el módulo de Young del material de la cuerda, I es el momento de inercia de la

sección con respecto al eje que pasa por la fibra neutra y es transversal a la dirección del
desplazamiento, d1 y d3 son coeficientes de pérdidas independientes y dependientes de la
frecuencia, respectivamente. Este modelo se reduce al (1.1) para el caso de tener una cuerda
de rigidez nula y sin pérdidas de energía.
La rigidez de la cuerda introduce un término de cuarto orden que causa la dispersión de
onda. En la figura 1.6 se muestra esquemáticamente la propagación de una onda formada por
la superposición de dos componentes de distinta frecuencia, en un medio dispersivo. Se
observa que las componentes espectrales viajan con diferente velocidad, con lo que se
“desarma” progresivamente la relación entre armónicos.
Los coeficientes d1 y d3 no sólo concentran el efecto del roce viscoso con el aire sino
también las pérdidas en el material de la cuerda y el acoplamiento con el cuerpo de
resonancia.
Se evidencia aquí la ventaja de FTM sobre DWG en cuanto a versatilidad e integridad. Si
bien es atractivo el enfoque de DWG en cuanto a su orientación modular, su evolución se
enfrenta a un cuello de botella a la hora de intentar reproducir fenómenos más sutiles. Se
siguen generando técnicas para rellenar estos huecos, por ejemplo las llamadas líneas de
retardo fraccionales [11] que aportan mayor resolución al ajustar la longitud de las guías de
onda. Algunos autores incluso sostienen que el modelo de la guía de onda puede difícilmente
considerarse como un modelo físico en sí [5], y que no es controlable de forma intuitiva. De

esta forma el FTM parece superar este enfoque cuando entran en juego los elementos más
delicados del modelo, que constituyen la riqueza del sonido. Como desventaja cabe nombrar
la menor modularidad del FTM y la mayor complejidad y demanda de recursos
computacionales en su implementación.
FIGURA 1.6. Efecto de la dispersión en la propagación de onda
1.2.3. Selección final
Finalmente, considerando en forma global el estado actual de desarrollo en las áreas

relevantes y la tendencia de la síntesis digital, se ha optado por orientar el presente trabajo a la
síntesis de sonido por modelado físico basado en FTM. Elegimos como modelo de trabajo el
de una cuerda con rigidez no nula, accionada por un excitador no lineal, ya que es un ejemplo
adaptable a una amplia gama de instrumentos acústicos existentes o a la creación de nuevos
sonidos.

2. Análisis del Modelo Físico
A continuación analizaremos por separado los componentes que integran el modelo que es
motivo del presente trabajo, que ha sido dividido en el resonador, el mecanismo de excitación
y el radiador.
2.1. Modelo del resonador
El resonador es en nuestro caso una cuerda con rigidez no nula. Aunque en apariencia
sencillo, este sistema es susceptible de ser modelado teniendo en cuenta una gran cantidad de
fenómenos mutuamente relacionados [12].
Para comenzar, en una cuerda conviven dos modos de propagación transversales, el
horizontal y el vertical, un modo longitudinal y otro torsional.
Los modos transversales son los predominantes en la mayoría de los casos, y en el caso
de instrumentos como el piano, donde la excitación tiene una interacción unidireccional con la
cuerda, predomina el modo vertical por sobre el horizontal. Es el modo tratado por excelencia
en los análisis de propagación de ondas en cuerdas ideales. La onda propiamente dicha se
genera a partir de una perturbación en que cada punto de la cuerda se ve alejado de la posición
central de reposo, propagándose dicha perturbación a una velocidad c determinada por
parámetros físicos y geométricos de la cuerda, siendo en general dicha velocidad dependiente
de la frecuencia, lo cual explica el efecto de dispersión.
El modo longitudinal ([13], [16]) está presente en las cuerdas de las octavas bajas del
piano y es responsable de gran parte de su riqueza armónica. Se trata de compresiones y
expansiones del material en el sentido longitudinal de la cuerda, los cuales se propagan a
diferente velocidad que los demás modos. Los modos transversales y el longitudinal se
encuentran mutuamente acoplados, de forma que las oscilaciones transversales excitan a las
longitudinales, y éstas a su vez excitan a las transversales. Algunos experimentos en que se
separaba cada modo en una guía de onda diferente produjeron resultados poco satisfactorios
[13], dando la impresión de estar ambos efectos desvinculados, obteniéndose un sonido poco
realista. Por ello la inclusión de este efecto en el modelo demanda una completa integración
de ambos tipos de modos, con la complejidad y consumo de recursos que ello supone.
El tercer modo, de tipo torsional, es sólo apreciable en instrumentos cuya excitación actúa
tangencialmente al eje de la cuerda, como en el caso del violín (uno de los grandes retos
actuales en términos de modelado físico). Aquí la cuerda se comporta como un muelle de
torsión, en que las deformaciones del material se propagan a lo largo de ésta. También en este
caso se presenta una compleja interacción con los demás modos oscilatorios.
Aun en un modelo simplificado con un único modo transversal de propagación, dado que
su contribución predomina fuertemente frente a las otras, existe un fenómeno no lineal que se
hace presente sobre todo en el caso de cuerdas muy largas comparadas con su sección
transversal [15]. En la figura 2.1 se observa una cuerda vibrante, analizada en cuatro instantes
correspondientes a sus puntos de máxima excursión positiva y negativa, y las dos posiciones
intermedias de mínimo estiramiento. Durante la vibración de la cuerda, la longitud de la
misma se ve levemente aumentada al alejarse del punto de reposo, y como resultado de esto
su tensión aumenta una cierta cantidad. A su vez la frecuencia natural del modo fundamental
de oscilación depende directamente tanto de la tensión como de la longitud, de acuerdo con la
expresión (2.1) [12]
1 Ts
f = (2.1)
2L μ

siendo aquí μ la densidad lineal de la cuerda. Suponiendo que la velocidad de propagación de

las ondas longitudinales es mucho mayor que la de las transversales, se puede considerar que
el aumento de tensión producido por el estiramiento se propaga en forma instantánea por toda
la longitud de la cuerda (en otras palabras, es dependiente sólo del tiempo e igual en todos los
puntos).
FIGURA 2.1. Efecto no lineal de modulación frecuencial en la oscilación de una cuerda
El efecto puede entenderse como una modulación de la frecuencia fundamental del modo
transversal f, con una frecuencia del mismo orden que ésta, y es responsable de patrones
armónicos complejos en el sonido de ciertos instrumentos musicales. Algunos autores [6]
afirman que es factible adaptar el método de FTM para incluir este último efecto con un
modesto costo computacional extra, aunque no se proporcionan demasiados detalles al
respecto. Una posibilidad es aproximar la longitud en cada instante por la que adopta un
armónico fundamental de igual valor eficaz. Aplicando luego la fórmula integral de la
longitud de una cuerda y aproximando por Taylor la raíz, se obtiene la expresión (2.2)
⎛ π 2Ymáx 2 ⎞
L' ≅ L ⎜⎜1 + 2
sen 2ωt ⎟⎟ (2.2)
⎝ 4L ⎠
la cual es válida para Ymáx << L. Así se obtiene una relación lineal aproximada entre la tensión
y la longitud. Restaría analizar si es factible extender este modelo a más de un armónico.
Es evidente que se puede ahondar en la complejidad del modelo casi indefinidamente.
Dadas las características del presente trabajo, optamos por adoptar el modelo de una cuerda
con un único modo de propagación transversal, descartando todos los demás efectos. Así, el
presente proyecto se centra más en la implementación del sintetizador, siendo una primera
aproximación en cuanto al modelado físico.
2.2. Modelo del mecanismo de excitación
En la bibliografía reciente abundan trabajos que encaran el modelado físico del piano en
particular, estando disponibles gran cantidad de resultados experimentales. Por ello se ha
optado por el modelo del martillo del piano como mecanismo de excitación no lineal de las
cuerdas.
La figura 2.2 muestra esquemáticamente la disposición de los elementos principales que
entran en juego. La longitud efectiva vibrante de la cuerda es la delimitada por el puente y la

barra Capo d’astro [12]. El martillo golpea a la cuerda en un punto que dista de la barra
aproximadamente entre una séptima y una octava parte de la longitud total de la cuerda.
FIGURA 2.2. Disposición de la cuerda y el martillo en el piano – (Fuente [12])
La figura 2.3 ilustra en detalle la interacción entre el martillo y la cuerda. Nótese que éste
golpea tres cuerdas simultáneamente. En realidad, cada nota del piano es producida por un
número de cuerdas golpeadas simultáneamente, que varía entre una sola (octavas inferiores) y
un máximo de tres (octavas superiores). Esta característica fue ideada a fin de aumentar el
nivel sonoro de los tonos agudos y disminuir el de los graves, variando el número de cuerdas,
para equilibrar el volumen a lo largo del registro completo del instrumento. Al golpearse más
de una cuerda a la vez, se manifiestan efectos como el batido y la doble caída [12], que dan al
sonido del piano características muy particulares. Como se puede ver, el martillo está
revestido de una gruesa capa de fieltro, que es la que entra en contacto con la cuerda. El
apagador es un simple contrapeso con una capa de fieltro adosada a su parte inferior, que
desciende al soltar la tecla para atenuar las vibraciones de la cuerda y apagar su sonido. Este
permanece levantado sin tocar la cuerda durante todo el tiempo en que la tecla está
presionada.
FIGURA 2.3. Detalle de la interacción entre el martillo y

las cuerdas del piano – (Fuente [12])
La figura 2.4 muestra una fotografía detallada del mecanismo de accionamiento del
martillo, a través de la interacción de una serie de palancas [18].

FIGURA 2.4. Mecanismo de excitación del piano – (Fuente [18])
En nuestro caso particular cabe obviar el mecanismo de accionamiento por palancas, y

centrar la atención en la interacción misma. Como primera aproximación al modelo del
martillo debemos estudiar la deformación del fieltro en contacto con la cuerda. Luego de un
análisis que tiene en cuenta las propiedades geométricas y de rigidez de los elementos [20] se
llega a un modelo del martillo que consta de una masa asociada a un muelle no lineal. La
fuerza actuante sobre cuerda y martillo (de igual magnitud y sentidos opuestos) queda
expresada en términos de la contracción del fieltro de acuerdo con la expresión (2.3)
F ( Δy ) = − K h Δy α (2.3)
donde Δy es la contracción del fieltro, Kh es la constante elástica de compresión y α es el

exponente de no linealidad. Este modelo se adaptó razonablemente bien para representar el
sistema en cuestión. No obstante, resultados experimentales más recientes permitieron
observar que la característica de fuerza/contracción presenta un comportamiento histerético
(ver figura 2.5). Hay más de un modelo propuesto en la bibliografía consultada (ver [19],
[21]). Se ha adoptado el descripto por la ecuación (2.4).
⎛ d ⎞
F ( Δy ) = − K h Δy α ⎜1 + μ h Δy ⎟ (2.4)
⎝ dt ⎠
Aquí la constante μh , denominada característica viscoelástica, introduce una dependencia

de la velocidad instantánea de contracción (derivada temporal de Δy) en la ecuación original.
Así la fuerza oscilará respecto de un valor central, siendo afectada de una componente que es
positiva o negativa de acuerdo al sentido de movimiento del martillo respecto de la cuerda.
Obviamente tanto la expresión (2.2) como la (2.3) son válidas sólo para valores de Δy
mayores o iguales a cero, correspondiendo a contracciones negativas una fuerza
idénticamente nula. El modelo del martillo queda totalmente caracterizado al incluir un último
parámetro mh , que representa la masa efectiva del martillo, y permite determinar el
movimiento del mismo durante el proceso de interacción con la cuerda. El efecto del peso es
despreciable en comparación con la fuerza de contacto durante el golpe, y no es tenido en
cuenta*.
*
Aunque la incidencia del peso puede variar de un piano horizontal a uno vertical, los valores de éste son del
orden de las decenas de gramos, mientras que las fuerzas de contacto son del orden de los kilogramos.

FIGURA 2.5. Característica Fuerza/Contracción del martillo

para tres notas del piano – (Fuente [12])
La figura 2.6 muestra las curvas correspondientes al modelo adoptado para diferentes
velocidades iniciales del martillo.
FIGURA 2.6. Característica Fuerza/Contracción del

modelo del martillo adoptado – (Fuente [19])
2.3. Modelo del radiador
La tabla armónica es el principal elemento radiante del piano. Su función consiste en dar
color y amplificación al sonido, como también la sensación de presencia. Pero a pesar de su
importancia, es la parte menos estudiada del piano [24]. Un modelo físico de un cuerpo
resonante requiere una simulación tridimensional de la propagación de una onda acústica
dentro del cuerpo [6]. Aunque existen métodos eficientes para este propósito (incluyendo
FTM), el costo numérico podría ser excesivo comparado a la simulación de un cierto número
de cuerdas. Considerando que el cuerpo resonante actúa como un filtro temporal, es una
alternativa práctica convolucionar la salida del modelo de la cuerda con la respuesta al
impulso del cuerpo. Esta respuesta al impulso puede estar determinada por mediciones de
instrumentos reales o por simulaciones offline de un cuerpo resonante virtual. La mayoría de
los autores opta por una interacción unidireccional entre el puente (el cual concentra el efecto

neto de todas las cuerdas) y la tabla armónica (ver figura 2.7), dejando de lado la influencia
recíproca de ésta sobre el primero (ver [22], [23]).
FIGURA 2.7. Interacción de los componentes

del diagrama de bloques del modelo
La figura 2.8 [23] muestra la función transferencia de la tabla armónica de un piano,

determinada experimentalmente tomando como entrada la fuerza ejercida por el puente, y
como salida la presión sonora recibida a una determinada distancia del instrumento. Dicha
fuerza se obtiene a través de un acelerómetro de alta precisión, solidario al puente [16]. Se
observa en la respuesta en frecuencia de la tabla una gran cantidad de resonancias presentes
dentro del espectro audible, responsables en gran parte de la naturaleza del sonido final.
FIGURA 2.8. Función transferencia Presión Sonora/Fuerza

de una tabla armónica de piano – (Fuente [23])

3. Algoritmo de Simulación
En este capítulo se presenta el algoritmo explícito que calcula la simulación. Se hace una
serie de consideraciones relacionadas con la eficiencia en el uso de recursos de procesamiento
y memoria.
3.1. Aplicación del método FTM al modelo físico adoptado
El método FTM ha sido introducido brevemente en la sección 1.2.1. Como se explicó,

debemos partir de la descripción matemática del modelo físico, que en este caso consiste en
una ecuación diferencial parcial (PDE) y un conjunto de condiciones iniciales y de contorno
impuestas al mismo.
La PDE es la expresión (1.2), que aquí transcribimos para mayor claridad:
∂2 y ∂4 y ∂2 y ∂y ∂3 y
ρA + EI − TC + d 1 + d 3 = f e ( x, t ) (1.2)
∂t 2 ∂x 4 ∂x 2 ∂t ∂t∂x 2
la cual es válida para valores de x contenidos en el intervalo [0, Lc.], donde Lc es la longitud
entre los extremos de la sección vibrante de la cuerda. Dado que la PDE contiene una
derivada temporal de segundo orden, se deduce que debemos definir dos condiciones
iniciales. Éstas definen el estado de la cuerda en el comienzo de la simulación, y no
necesariamente antes de cada impacto del martillo.
La interrupción de la excitación (esto es, la anulación de fe ) durante un cierto período de
tiempo no impide que la cuerda prosiga con su evolución natural. De este modo, el martillo
puede, en cada impacto sucesivo, encontrar a la cuerda con una posición y velocidad
arbitrarias. La citada propiedad, característica de este esquema particular de síntesis, se
traduce en leves variaciones del sonido generado a partir de estímulos idénticos (iguales
velocidades iniciales del martillo), pero ante diferentes estados vibratorios de la cuerda en el
momento del impacto. Esta posibilidad no está presente en los samplers donde los sonidos se
obtienen una y otra vez a partir de las mismas grabaciones.
Por simplicidad, imponemos condiciones iniciales homogéneas, es decir posición y
velocidad nulas:
⎡ y ( x,0) ⎤
f i {y} = ⎢ ∂y ⎥=0 (3.1)
⎢ ( x,0) ⎥
⎣ ∂t ⎦
Las condiciones de contorno, junto con la PDE, definen los modos vibratorios de la
cuerda. En la PDE, el mayor orden de derivación respecto de x es cuatro, con lo cual son
cuatro las condiciones de contorno a imponer. Consideramos el caso de extremos fijos, que se
expresa matemáticamente de la siguiente forma [6]:
⎡ y ( x, t ) ⎤
f b {y} = ⎢ ∂ 2 y ⎥ = 0 ; x = 0, L c (3.2)
⎢ 2 ( x, t ) ⎥
⎣ ∂x ⎦
Una vez obtenida la descripción matemática completa del modelo, debemos aplicar el
método FTM. Inicialmente, como es usual en la teoría de sistemas y señales, se hace uso de la
transformada de Laplace. Su aplicación permite la resolución de ecuaciones diferenciales
ordinarias (ODE), donde la variable independiente es el tiempo. A través de dicha
transformación funcional se obtiene una expresión equivalente, exenta de derivadas

temporales, en el dominio transformado s; esto es, una ecuación algebraica. En la misma
entran en juego las condiciones iniciales impuestas. Es factible aplicar dicha transformación a
la PDE de nuestro caso particular, si consideramos para ello un valor constante de x. Como
resultado obtenemos una expresión que no contiene derivadas respecto del tiempo, pero sí
respecto del espacio:
∞
L{y ( x, t )} = Y ( x, s ) = ∫ y ( x, t )e − st dt (3.3)
0
El FTM introduce la denominada transformada de Sturm-Liouville (SLT), análoga a la de

Laplace, pero aplicable en cambio a la dependencia espacial de la función a transformar. En
otras palabras, ésta permite eliminar las derivadas respecto de la variable x, considerando las
condiciones de contorno. Se define como:
T {Y ( x, s )} = Y ( μ , s ) = ∫ Y ( x, s) K ( μ , s , x) dx
Lc
(3.4)
0
donde μ es la variable del dominio transformado, y puede demostrarse que toma valores
enteros, en correspondencia directa con los valores propios del sistema.
Sin embargo, no existe una única transformación aplicable a todos los posibles casos,
como sucede con la transformada de Laplace. Se hace necesario, en cambio, construir una
transformada específica para cada problema particular. El núcleo de la transformada SLT,
K(μ,s,x), se obtiene como la función propia de un tipo especial de problema de valores de
contorno (problema de Sturm-Liouville). Estos problemas se definen en términos de
operadores diferenciales espaciales, las configuraciones geométricas de los dominios
espaciales y el tipo de condiciones de contorno [48]. Las transformaciones espaciales
correspondientes son integrales finitas, en las cuales la integración se efectúa dentro de los
límites de definición espacial del sistema multidimensional (MD). En [6] se muestra la forma
que toma el núcleo para nuestro problema particular.
Luego de la aplicación sucesiva de ambas transformadas a la PDE, se obtiene una
ecuación algebraica en la que las variables {x, t} han sido reemplazadas por las {μ, s}. Por un
simple reordenamiento se explicita la función transformada Y ( μ , s) , para luego arribar a la
expresión de la función transferencia del sistema:
Y (μ , s)
G e ( μ , s) = (3.5)
F e ( μ , s)
donde F e ( μ , s ) se obtiene de la aplicación de ambas transformadas a la entrada del sistema

fe (x,t).
El siguiente paso consiste en discretizar el modelo a través de la aplicación del siguiente
conjunto de operaciones [6]:
{
G e ( μ , z ) = Z L−1 {G e ( μ , s )} t = kT
d
} (3.6)
A través de la transformada inversa de Laplace, L-1, y el posterior muestreo de la señal a una

tasa Fs = 1 / T, obtenemos la respuesta al impulso en tiempo discreto. Por último se aplica la
transformada Z, arribando al resultado deseado.
Aplicamos ahora al modelo discreto la transformada inversa SLT, la cual se define como:

1
T −1 {Y ( μ , s )} = Y ( x, s ) = ∑ Y ( μ , s) K ( μ , s, x) (3.7)
μ Nμ
donde los denominados factores de normalización, Nμ , se obtienen a partir de la siguiente

condición de ortogonalidad de las funciones propias del sistema:
Lc ⎧ 0 si ν ≠ μ
∫0
K ( μ , s, x) K (ν , s, x )dx = ⎨
⎩ N μ si ν = μ
(3.8)
Se hacen ahora ciertas consideraciones sobre la naturaleza de la señal de entrada. La

fuerza excitadora, fe , se caracteriza por su evolución temporal y por su distribución espacial.
En una excitación simple (es decir, al producirse un impacto completo del martillo) la
distribución espacial permanece aproximadamente invariable durante todo el tiempo de
contacto. De este modo, es factible separar a la señal de entrada en un producto de la forma
fe(x,t) = fe1(x) fe2(t) , lo cual simplifica el problema y facilita la aplicación de la transformada
SLT inversa. De lo dicho resulta:
{ d
H d ( x, z ) = T −1 G e ( μ , z ) f e1 ( μ ) }
∞
1 d (3.9)
=∑ G e ( μ , z ) f e1 ( μ ) K ( μ , x)
μ =1 N μ
Es en este punto donde se evidencia la ventaja esencial del método FTM. Para cada valor
de μ la función transferencia discreta toma la forma de un sistema de segundo orden. En la
expresión (3.9) se pone de manifiesto la posibilidad de representar al sistema como una
disposición paralela de sistemas recursivos de segundo orden, donde μ se corresponde con
cada valor propio, es decir con cada armónico* de la respuesta final. De esta forma, es factible
limitar la suma en la expresión (3.9) a un número finito de términos, N, de manera de
reproducir únicamente los armónicos contenidos en el rango audible de frecuencias. La figura
3.1 muestra la disposición paralela requerida, donde cada armónico es producido por la
contribución de un filtro IIR (respuesta al impulso infinita) de orden dos.
La estructura de la figura 3.1 corresponde al modelo de una cuerda vibrante, sujeto a todas
las simplificaciones explicadas en el capítulo 2. En [48] se aplica el método FTM a modelos
que incluyen propagaciones de ondas longitudinales y torsionales, sistemas no lineales con
coeficientes dependientes de la solución (modulación de frecuencia), diferentes tipos de
excitación no lineal, interacción entre múltiples cuerdas descripta a partir de funciones
transferencia. Para todos ellos se supone que el cuerpo resonante posee densidad y sección
transversal constantes. Estas condiciones permiten obtener la solución a partir de un arreglo
paralelo de filtros de orden dos, similar al de la figura 3.1. Finalmente, el algoritmo
implementado, si bien no es de aplicación general, se adapta a un conjunto considerable de
sistemas.
*
Nos referiremos como armónicos a los componentes espectrales introducidos por cada filtro, ya que es la
denominación empleada en [6]. No obstante, sería más apropiado designarlos como parciales, ya que en general
estos pueden ser también inarmónicos, sobre todo para cuerdas muy rígidas o de gran sección transversal.

FIGURA 3.1. Disposición en paralelo de filtros IIR – (Fuente [6])
3.2. Cálculo de coeficientes de los filtros IIR
De acuerdo con [6], la aplicación del FTM al modelo de la cuerda (1.2) permite llegar a un
número de fórmulas que determinan los coeficientes de los filtros IIR, partiendo de todos los
parámetros físicos de la cuerda en cuestión. Como se explicó, cada uno de estos filtros calcula
la contribución de un único componente armónico a la solución total y(k), que es el valor de la
posición instantánea de la cuerda, evaluado en un punto de observación xa comprendido en su
longitud. La figura 3.2 muestra un filtro IIR genérico, y la nomenclatura adoptada para sus
coeficientes y variables asociados†.
FIGURA 3.2. Filtro IIR correspondiente a un armónico genérico
Los coeficientes que deben determinarse son c0, c1, b1 y a1. La aplicación del FTM a
nuestro problema particular arroja las siguientes fórmulas:
†
La fuerza de contacto fe2(k) se calcula al final de cada paso de simulación, y es función de la posición y
velocidad instantáneas de la cuerda y del martillo. Será analizada en una sección posterior.

Ts sen(ω μ Ts ) σ μ Ts
b1 = e
ρ c Ac ω μ Ts
cos(ω μ Ts )
σ μ Ts
c1 = −2e
2σ μ Ts
c0 = e (3.10)
⎛ μπΔx e ⎞
sen⎜⎜ ⎟⎟
1 ⎝ 2 Lc ⎠ sen⎛⎜ μπ x e ⎞⎟ sen⎛⎜ μπ x a ⎞⎟
a1 = ⎜
Nμ μπΔx e ⎝ Lc ⎟⎠ ⎜⎝ Lc ⎟⎠
2 Lc
Aquí μ designa el número de armónico, es decir, identifica al filtro IIR, y toma valores
que van desde 1 hasta N. TS es el período de muestreo en segundos, Lc la longitud de la cuerda
en metros, ρc y Ac su densidad y sección transversal. xe y xa son las distancias, en metros, a
partir del extremo de la cuerda, en los cuales se aplica la excitación y se evalúa la solución,
respectivamente. Δxe es la longitud de contacto entre el martillo y la cuerda. Como se observa,
se introducen además tres parámetros auxiliares, que dependen de μ. σμ y ωμ son las partes
real e imaginaria de los polos de cada filtro IIR, respectivamente. Los citados parámetros se
calculan a partir de las siguientes expresiones:
Lc
Nμ =
2
σμ =−
1
2 ρ c Ac
(d γ
3
2
μ − d1 )
2 (3.11)
⎡ Ec I c d 32 ⎤ 4 ⎡ Tc d1 d 3 ⎤ 2 ⎡ d 1 ⎤
ωμ = ⎢ − ⎥ γ + ⎢ + γ −⎢
2 ⎥ μ ⎥
⎣⎢ ρ c Ac (2 ρ c Ac ) ⎦⎥ ⎢⎣ ρ c Ac 2(ρ c Ac ) ⎦⎥
μ
⎣ 2 ρ c Ac ⎦
2
μπ
γμ =
Lc
3.3. Consideraciones para un cómputo eficiente
3.3.1. Filtros IIR
Cada uno de los filtros (ver figura 3.2) consta de dos elementos de retardo discreto, lo cual
se traduce en un requerimiento de dos variables de 32 bits, que almacenen en memoria un
dato de tipo float (punto flotante de precisión simple) cada una. Un rápido análisis sugiere
almacenar en cada variable el contenido mismo del elemento de retardo, ψ(k) y w(k)
respectivamente, emulando así una implementación con elementos discretos (latches,
sumadores, multiplicadores). Sin embargo un estudio más detenido muestra que una
implementación computacionalmente más eficiente requiere la definición de una variable
auxiliar w(k) que permite, conociendo sus valores pasados en (k – 1) y en (k – 2), calcular el
resultado en el paso de integración actual:
w(k) = λ(k – 1)
w(k) = fe2(k – 1) b1 + ψ(k – 1) + w(k – 1) c1 (3.12)
w(k) = fe2(k – 1) b1 + w(k – 2) c0 + w(k – 1) c1

La ventaja de usar la variable w y almacenar en memoria sus últimos dos valores es que en
cada paso de integración, el valor de w(k – 2) resulta idéntico al valor anterior de w(k – 1), por
lo que una de las dos variables ya contiene el valor necesario para el cálculo en el paso de
integración actual. Esto implica, a su vez, que los valores w(k – 2) y w(k – 1) sean
almacenados en forma alternada, en un orden o en el inverso según sea el paso de integración
par o impar (ver figura 3.3). Este hecho se tendrá en cuenta al escribir el código del algoritmo
que calcula la integración, diferenciándose los pasos impares de los pares.
FIGURA 3.3. Almacenamiento alternado
3.3.2. Fuerza de contacto entre cuerda y martillo
Tanto la dinámica de la cuerda como la del martillo responden al valor instantáneo que
toma la fuerza de contacto entre ambos. A su vez, dicha fuerza depende en cada instante de la
posición y velocidad relativa entre la cuerda y el martillo. De esto se deduce la necesidad de
calcular el valor de la fuerza fe2(k) en cada paso de integración. Por lo tanto, dicho cálculo
pertenece a la sección crítica del programa y su optimización se vuelve vital para alcanzar los
requerimientos de ejecución en tiempo real.
La expresión que permite obtener la fuerza es la (2.4). En el anexo A se realiza un análisis
de dicha función, y a partir de una serie de consideraciones se obtienen las siguientes
fórmulas aproximadas para el cálculo de la fuerza de contacto en forma eficiente:
( ⎛
) d ⎞
F ( Δy ) = − K h Δy 2 A + Δy 2 B ⎜1 + μ h Δy ⎟
dt ⎠
⎝
α −2 α −2
x2 − x1
B= 2 2
(3.13)
x 2 − x1
α −2 2
A = x1 − x1 B
Aquí x1 y x2 son constantes, cuyos valores son 1×10-3 m y 2×10-3 m respectivamente, y A y B

son variables auxiliares.
Como vemos, la expresión (3.13) corresponde al dominio temporal continuo, y debemos
trasladarla al de tiempo discreto para poder calcularla. La única operación que se ve
modificada es la diferenciación del último término. Su solución en tiempo discreto requiere el
almacenamiento de Δy (contracción del martillo, o bien posición relativa entre cuerda y
martillo) para los dos últimos pasos de integración, y se calcula como su diferencia dividida
por el período de integración (coincidente con el de muestreo).

d Δy − Δy1
Δy ≅ 2 = (Δy 2 − Δy1 )FS (3.14)
dt TS
Se puede obtener una versión más simple si permutamos el orden de la diferenciación con
el de la diferencia:
d ⎛d ⎞
Δy = Δ ⎜ y ⎟ = Δ v (3.15)
dt ⎝ dt ⎠
Finalmente, la solución en tiempo discreto es la expresión (3.16), donde yc es la posición

de la cuerda, y vh es la velocidad del martillo:
Δv = [ y c ( k ) − y c ( k − 1)]FS − v h ( k ) (3.16)
Ahora, obtenida la fuerza de contacto, resta el cálculo del movimiento del martillo. Para
ello simplemente se aplica la ley de inercia, y se determina las variables cinemáticas
instantáneas de la siguiente forma:
− f e2 (k )
a h (k ) =
mh
v h ( k + 1) = v h (k ) + a h (k )TS (3.17)
y h (k + 1) = y h (k ) + v h ( k + 1)TS
Aquí ah , vh e yh son la aceleración, velocidad y posición del martillo respectivamente, y mh es

su masa.
3.4. Descomposición estereofónica del sonido
Existen diversos criterios posibles para determinar la forma en que se separa el sonido en
un canal izquierdo (L) y un canal derecho (R), para formar una imagen acústica estereofónica.
La figura 3.4 muestra los modelos de directividad en el plano horizontal para un piano
vertical. En general, existe un patrón direccional de intensidad distinto para cada componente
armónico de cada una de las notas. Un determinado armónico emitido por una cuerda grave,
no tendrá la misma directividad que el mismo armónico emitido por una cuerda aguda, dado
que ambas cuerdas inciden sobre el puente en puntos diferentes.
En nuestro caso particular, la descomposición estereofónica es la responsable de
reproducir, al menos en forma aproximada, esta imagen acústica. Una solución razonable
sería subdividir el aporte de cada armónico individual (asociado a un filtro IIR) en cada una
de las cuerdas, en una componente yL y otra yR . Si bien esto aporta un procesamiento
adicional a la sección crítica del código, se demostrará que con un esquema apropiado el
sacrificio de recursos no es demasiado significativo. Para separar la señal de salida de cada
filtro y(k) en las dos componentes, L y R, se la afecta de los coeficientes αL y αR. Estas dos
multiplicaciones adicionales (y accesos a memoria), pueden reducirse a una sola, si aplicando
álgebra de bloques reagrupamos las constantes como muestra la figura 3.5.

FIGURA 3.4. Modelos de directividad para el plano horizontal

de un piano vertical - (fuente [12])
FIGURA 3.5. Desdoblamiento de la señal en los canales L y R
Luego, las contribuciones de cada armónico yL(k) e yR(k) son sumadas en forma
independiente para cada canal, como muestra la figura 3.6. Aquí las aLμ y aRμ concentran ya
ambas ganancias.
Sin embargo, es necesario también obtener la posición de la cuerda para el cálculo
posterior de la fuerza de contacto. Si imponemos como única condición que αL + αR = 1 en
todos los armónicos, entonces tendremos que a1L + a1R = a1 y, por consiguiente,
yc (k) = yL (k) + yR (k). Así, basta con añadir una única suma al final de cada paso de
integración, luego del cómputo completo de todos los filtros correspondientes a la cuerda.
El esquema implementado permite considerar la descomposición estereofónica a nivel de
armónicos individuales. La determinación de los coeficientes α para todos los armónicos de
todas las cuerdas (lo que denominaremos distribución de paneo) se efectúa en forma offline,
fuera de la sección crítica, y una única vez para cada instrumento virtual.

FIGURA 3.6. Esquema final de resolución
La descripción completa de la distribución de paneo a partir del ensayo de un instrumento

real, requeriría la determinación de un par de coeficientes {αL, αR } para cada armónico de
cada una de las cuerdas. Un posible procedimiento experimental consistiría en inyectar en el
puente, sobre la posición correspondiente a las sucesivas cuerdas consideradas, entradas
sinusoidales puras de igual amplitud y diferentes frecuencias‡. Luego, un par de micrófonos
dispuestos a ambos lados del sistema radiante permitirían medir la intensidad asociada a cada
canal (L y R), correspondiente a cada una de las entradas.
Se ha considerado que para los propósitos del presente trabajo, dada la dificultad de
obtener la distribución de paneo completa, es suficiente aplicar una descomposición de la
señal a nivel de notas, y no de armónicos. En otras palabras, la separación de los coeficientes
a1 en aL y aR , en cada filtro, se realiza a partir de un único par {αL, αR } común a todos los
armónicos de cada una de las cuerdas. Una futura implementación de la distribución de paneo
completa requeriría un conjunto importante de resultados experimentales, pero sería realizable
a través del algoritmo de resolución que se ha implementado, sin cambios en la sección crítica
del código.
3.5. Otras consideraciones
Como se ha visto, se hace una diferencia entre el parámetro que determina la posición de
la cuerda sobre la cual se aplica la excitación (xe), y aquél que indica el punto en el cual se
evalúa la solución de la simulación (xa).
Normalmente es interesante calcular el desplazamiento de la cuerda en el punto en que
esta se une al puente, de forma tal que la solución sea lo más representativa posible de las
vibraciones tal como éstas inciden sobre la tabla armónica [48]. En el modelo planteado de
esta forma, la impedancia asociada al puente queda contenida en la función transferencia del
‡
Nótese que para poder aplicar el principio de superposición es necesario ensayar el sistema radiante desprovisto
de cuerdas, para que cada salida medida corresponda así al aporte de una única entrada

sistema radiante (ver figura 3.7-a). Un modelo más detallado requeriría considerar una
impedancia en la interacción entre el puente y el cuerpo del instrumento, en forma separada
(ver figura 3.7-b). En este caso, el desplazamiento podría evaluarse en el extremo de la
cuerda, ya que el mismo no estaría fijo respecto del cuerpo.
FIGURA 3.7. Modelo de la terminación de la cuerda (a) considerando la inercia del puente
dentro de la función transferencia del sistema radiante y (b) considerando por separado la
impedancia respecto del cuerpo (x F : posición del puente sobre la cuerda) – (Fuente [48])
A su vez, para implementar nuestro modelo del excitador, en los cálculos interviene la
posición instantánea de la cuerda en el punto donde se ejerce la excitación.
Para satisfacer ambos preceptos deberíamos prever dos simulaciones simultáneas, una
para cada señal. No obstante, cabe notar por inspección de las expresiones (3.10) y (3.11) que
los únicos coeficientes de los filtros IIR que dependen del parámetro xa son los a1μ , siendo
totalmente independientes del mismo c0μ , c1μ y b1μ . Este hecho permitiría calcular ambas
señales con la sola adición de un segundo conjunto de ganancias a1μ que afectaran al conjunto
original de señales wμ(k). Esto se traduciría en un total de dos multiplicaciones, dos
acumulaciones y una lectura de memoria adicionales, por cada armónico.
En nuestro caso se ha optado por calcular la solución únicamente en el punto de
excitación, es decir, hacer xa = xe . Esta señal permite calcular la fuerza de excitación y a la
vez actúa como señal de entrada del modelo de la tabla armónica. Aunque se la ha
considerado innecesaria a los propósitos del presente trabajo, una posible extensión permitiría
el cálculo simultáneo de una segunda señal sin demasiado costo computacional.

4. Consideraciones Para la Implementación del Modelo
En este capítulo se plantea una subdivisión del sistema en partes, y se definen los equipos
que entrarán en juego en la implementación final. Para ello se analizan los requerimientos de
hardware y software, como también los productos disponibles en el mercado.
4.1. Consideraciones generales
A la hora de adoptar una implementación de hardware que resuelva en tiempo real el

procesamiento requerido surgen, a grandes rasgos, dos opciones principales.
▫ La primera opción consiste en escribir una aplicación de software basada en PC,

empleando una interfaz de entrada de control estandarizada (usualmente MIDI,
explicada más adelante) y una tarjeta de sonido para proveer la salida de audio final.
La aplicación implementaría el sintetizador en su totalidad, además de brindar una
interfaz gráfica al usuario, permitiendo el acceso a los parámetros físicos, acústicos y
de control.
▫ La segunda opción es un sistema dedicado, basado en DSP (Digital Signal Processor),
que sea autosuficiente y cuya estructura de hardware esté optimizada y diseñada
específicamente para la aplicación en cuestión. Bastaría aquí con resolver la interfaz
de control de la interpretación musical, e incorporar un sistema de adquisición de
datos numéricos que cumpla la misma función que la interfaz gráfica del caso anterior.
En el presente trabajo se opta por el segundo esquema mencionado, apuntando al

desarrollo de un instrumento que integre en sí todas las funciones de control, síntesis y
reproducción, sin la necesidad de recurrir a elementos o equipamientos adicionales.
Otro factor determinante para esta elección de la implementación de hardware son las
diversas limitaciones de una PC convencional. Los DSP están optimizados para aplicaciones
de procesamiento de señales, lo cual no se cumple en los procesadores de propósitos generales
(GPP) empleados en las PC. La arquitectura de hardware de los DSP posee determinadas
propiedades que posibilitan la reducción del número de instrucciones requeridas para lograr
un procesamiento eficiente de las señales digitales. Una de sus características fundamentales
es la capacidad de ejecutar un cierto número de operaciones en forma paralela, en un único
ciclo de ejecución. Esto es especialmente apropiado para la implementación de filtros
digitales FIR e IIR y para la convolución de señales, que son las operaciones más críticas que
forman parte de nuestra aplicación particular.
Lograr la performance adecuada empleando un GPP, demandaría entonces una cantidad
significativamente mayor de recursos de procesamiento y memoria; más aun teniendo en
cuenta que en una PC el procesador debe atender los requerimientos del sistema operativo.
Siendo esta una primera aproximación, puede considerarse que lo que se busca aquí es
generar un prototipo que resuelva un modelo en particular, pero realizado de forma tal que se
facilite cualquier futura extensión de sus funciones o de su modelo físico asociado.
Se ha resuelto subdividir el conjunto total en cuatro partes principales:
▫ Dispositivo MIDI de control

▫ Aplicación de software de edición y control
▫ Dispositivo sintetizador
▫ Dispositivo amplificador y reproductor.

En la figura 4.1 se observa en forma esquemática la relación mutua de las citadas partes y
su interacción con el usuario/intérprete.
FIGURA 4.1. Interacción de las partes principales del sistema
4.1.1. Dispositivo MIDI de control
El mismo integra un conjunto de sensores y/o captadores de movimiento que brindan al

intérprete una vía para traducir su expresividad musical en un lenguaje entendible por el
sistema. De esta forma dichas señales de control pueden ser introducidas en el modelo físico
en forma de modificaciones de los parámetros dinámicos del mecanismo de excitación de
cada cuerda. El lenguaje mencionado es el llamado MIDI (Musical Instrument Digital
Interface) altamente difundido en la actualidad. El mismo consiste básicamente en un
protocolo y un set de comandos para almacenar y transmitir información musical de control,
es decir, cuándo una tecla es presionada y con qué intensidad, cuándo es soltada, e
información asociada a diferentes controladores de expresividad (para más información ver
[27]). Se adoptará en nuestro caso un piano digital Roland RD-100, que dispone de una salida
MIDI y consta de 88 teclas sensibles a la velocidad, además de un pedal de sustain.
Si bien este dispositivo posee ya incorporado un sintetizador y su correspondiente salida
de audio estereofónica, para los fines del presente proyecto se hace uso únicamente de la señal
MIDI de salida. Esta transporta la información de control que actuará, luego de un
determinado procesamiento, sobre la dinámica del modelo del mecanismo de excitación, para
así generar el sonido correspondiente en forma interactiva. Por ello, cabe aclarar que cualquier
otro dispositivo MIDI pudiera haberse empleado para tal fin.
4.1.2. Aplicación de software
Tiene la función doble de actuar como vínculo entre el dispositivo MIDI y el sintetizador,
y a la vez permitir al usuario crear y editar conjuntos de parámetros físicos que caractericen a
diferentes instrumentos virtuales. La aplicación será escrita en Microsoft Visual Basic y
funcionará instalada en una PC. Una tarjeta de audio Creative Sound Blaster Live permitirá el
ingreso de las señales de control a través de su puerto MIDI de entrada. También se empleará
su salida analógica de audio para proporcionar al usuario una preescucha del sonido durante la
edición, que le permita ajustar los parámetros físicos hasta lograr el resultado deseado. Esta
simulación previa es offline y está implementada por un algoritmo dentro de la aplicación.

También se añaden visualizaciones gráficas de las señales acústicas generadas, y un cierto
número de funciones de edición y control que se explicarán más adelante.
4.1.3. Dispositivo sintetizador
Cumple la función principal, que consiste en generar la señal de audio a partir de los datos
de control y los parámetros de simulación provenientes de la aplicación de software. Todo el
procesamiento crítico del sistema es realizado en este módulo.
Una solución posible para la implementación del dispositivo sintetizador es el empleo de
alguno de los denominados DSK (DSP Starter Kit) o EVM (Evaluation Modules). Se trata de
tarjetas de costo relativamente bajo, que integran un DSP y un cierto número de componentes
de hardware, como ser memorias RAM, puertos de comunicación compatibles con PC, un
códec de audio, entre otros. También incluyen un entorno gráfico de desarrollo y depuración,
basado en PC, y bibliotecas que posibilitan el intercambio de datos en tiempo real entre la
tarjeta y aplicaciones de software escritas por el usuario.
Freescale (Motorola) y Texas Instruments ofrecen una gama relativamente amplia de
estos productos. A continuación listamos aquellos que están disponibles en el mercado, y que
a su vez se encuentran diseñados especialmente para aplicaciones de audio. En la
comparación, se ha puesto en relieve las características más relevantes para nuestro caso
particular: especificaciones del códec, sistema de comunicación entre la placa y la PC,
capacidad de procesamiento en paralelo y en punto flotante, y precio del producto.
Operación Procesa-
Comunicación Precio
Procesador en punto MIPS MFLOPS miento Códec
con Host (US$)
flotante paralelo
8 unidades
EVM320C6418 No 4000 - 16 bit - Stereo Puerto USB 995,00
func. 32 bit
Instruments
8 unidades
EVMDM642 No 5760 - 16 bit - Stereo Puerto USB 1995,00
Texas
func. 32 bit
8 unidades
DSKC6713 Sí 1800 1350 16 bit - Stereo Puerto USB 415,00
func. 32 bit
8 unidades
DSKC6416 No 5760 - 16 bit - Stereo Puerto USB 515,00
func. 32 bit
24 x 24-bit Señales de
DSP56311EVM No 270 - Puerto USB 310,95
MAC voz
(Motorola)
Freescale
Puerto
24 x 24-bit
DSP56F826EVM No 40 - 16 bit - Stereo paralelo 309,88
MAC
IEEE 1284
24 x 24-bit Puerto serie
DSP56307EVM No 100 - 16 bit - Stereo 613,31
MAC RS-232
En prácticamente todos los casos, las tarjetas poseen códecs de similares características,
brindando salidas stereo de 16 bits y distintas tasas de muestreo.
Los modelos de Texas Instruments se comunican con la PC a través del puerto USB,
aunque prevén la posibilidad de utilizar el puerto paralelo mediante la incorporación de placas
suplementarias que se ofrecen como accesorios.
La capacidad de procesamiento se especifica como la cantidad de operaciones ejecutadas
por unidad de tiempo. Esta información se incluye en la tabla en las columnas MIPS (Millions
of Fixed Point Instructions Per Second ) y MFLOPS (Millions of Floating Point Operations
Per Second). Nótese que sólo el DSKC6713 de Texas Instruments soporta operaciones
aritméticas en punto flotante. Un modelo similar, el DSKC6711, también poseía esta
capacidad, pero ha sido descontinuado recientemente por el fabricante.
Se explicita a su vez la capacidad para ejecutar instrucciones en paralelo. Para los modelos
de Texas Instruments se especifica el número de unidades funcionales. Estas son módulos de

ejecución del procesador, que operan simultáneamente, cada uno de las cuales puede ejecutar
una instrucción de 32 bits (en el capítulo 5 se explica esto con mayor profundidad). En los
modelos de Freescale se indica la capacidad de ejecutar instrucciones MAC (Multiply and
Accumulate) de 24 bits en forma paralela. Se trata de operaciones que combinan un producto
y una acumulación, apuntando a la aplicación en el filtrado y otros procesamientos comunes
de señales digitales.
La selección final del modelo a emplear se realizará en la sección 4.3, luego de estimar los
requerimientos computacionales.
4.1.4. Amplificador y reproductor*
Se encarga de transformar la señal analógica de audio proveniente del sintetizador en una

onda acústica. Bastará para tal fin un equipo de audio ordinario, con entrada de línea
estereofónica desbalanceada.
4.1.5. Interconexión de los equipos adoptados
La figura 4.2 muestra esquemáticamente los equipos que integran el sistema y su

interconexión. Las flechas indican el sentido del flujo de las señales.
FIGURA 4.2. Equipos que integran el sistema
*
Si bien sería más correcto designarlo como transductor, ya que su función es transformar una señal eléctrica en
una acústica, emplearemos la denominación reproductor, por ser el término más comúnmente utilizado.

4.2. Estimación de los requerimientos computacionales
Como primer paso debemos decidir entre una arquitectura de punto fijo y una de punto
flotante. Hoy en día la alta capacidad de integración de componentes electrónicos ha reducido
el costo de fabricación de ALUs (Aritmethic Logical Unit) que ejecutan operaciones en punto
flotante, y lo ha hecho equiparables con el costo de las de punto fijo. Así, el elemento
condicionante es más bien la velocidad de procesamiento de cada tecnología [28]. Para el
problema que nos ocupa, debe notarse que los datos numéricos que intervienen en las
operaciones corresponden en su mayoría a los valores de los parámetros físicos que entran en
juego. Al trabajar en un dado sistema de unidades de medición, las magnitudes físicas llegan a
diferir en muchos órdenes de magnitud unas respecto de otras. Una implementación de punto
fijo, de ser factible, implicaría necesariamente tener que adaptar los valores para que éstos
pudieran ser procesados por el DSP. Por esto nos vemos definitivamente inclinados hacia la
opción de una ALU que soporte operaciones en punto flotante.
Ahora se debe determinar en forma estimativa la capacidad de procesamiento necesaria.
El algoritmo central del sistema es el que implementa el diagrama de bloques de la figura 3.6.
El código necesario será un bucle que en cada iteración resuelva progresivamente la
contribución de cada uno de los filtros IIR. De la observación del diagrama de bloques se
deduce que en cada iteración se deberán ejecutar un total de cinco multiplicaciones, cuatro
sumas y cinco accesos a memoria (como se verá más adelante, los DSP de la familia en
cuestión pueden leer o escribir hasta 64 bits en un único acceso a memoria, correspondiente a
dos datos de 32 bits de punto flotante). A esto hay que agregar un decremento y una
instrucción de salto, utilizados para ejecutar el bucle. En total se trata de 16 instrucciones por
cada armónico considerado, en cada ciclo de simulación. En el caso de tener una frecuencia
de muestreo de 44,1 kHz, y considerando 80 armónicos por cuerda, el consumo asciende a
unas 56,5×106 instrucciones por segundo para cada cuerda.
Luego debemos considerar la capacidad de procesamiento paralelo del DSP. El número
real de operaciones ejecutadas por ciclo es variable [29] y depende de qué tan optimizado está
el código del programa. Sea N el número de instrucciones por segundo que puede ejecutar el
DSP, especificado por el fabricante. El mismo corresponde al caso más favorable posible, en
que se aprovecha toda la capacidad de procesamiento paralelo. Sea W el número máximo de
instrucciones simultáneas que el DSP es capaz de ejecutar en cada ciclo. Entonces el número
real de instrucciones por segundo, NE , variará entre un máximo de N (con toda su capacidad
aprovechada) y un mínimo de N/W (correspondiente a una sola instrucción por ciclo de
ejecución).
El grado de optimización, como se verá en capítulos posteriores, depende tanto de la
estrategia adoptada para la generación de los algoritmos, como de consideraciones sobre el
uso de memoria (uso eficiente de la memoria caché del DSP). En esta etapa no es posible
estimar con gran precisión el requerimiento definitivo, pero sí acotarlo entre ciertos límites.
Definamos al rendimiento medio de la optimización del código de la siguiente forma:
NE
ξ= 100% (4.1)
N
donde N E designa el promedio temporal del número real de instrucciones procesadas por
segundo. Puesto que NE guarda relación directa con el grado de aprovechamiento de la
capacidad de procesamiento paralelo, el rendimiento puede definirse alternativamente como:
WE
ξ= 100% (4.2)
W

siendo aquí W E el promedio temporal del número de instrucciones procesadas en paralelo

en cada ciclo de ejecución.
Luego se deben reservar recursos para la implementación de la tabla armónica y del
mecanismo de excitación, como también para lograr una comunicación fluida entre la
aplicación de software y el sintetizador (responsable esta última de cualquier latencia entre la
acción del intérprete y la producción del sonido correspondiente). En el caso de la tabla
armónica estamos hablando de una convolución en tiempo real de la señal simulada con la
respuesta al impulso de la tabla. Teniendo en cuenta que la señal es estereofónica, cada canal
debe ser convolucionado en forma separada. Algunos autores [23] sugieren que una respuesta
al impulso con un número de muestras menor a 1000 no arroja resultados satisfactorios al
intentar reproducir el sonido del piano, lo que se traduce en un consumo de recursos
considerable. Como primer criterio de diseño, reservaremos para este proceso el 20% de los
recursos totales del procesador.
En cuanto al resto de los procesos, la bibliografía consultada sugiere que no deberían
representar un consumo apreciable en comparación con el de las cuerdas y la tabla armónica.
4.3. Adopción del dispositivo a emplear
Las anteriores consideraciones nos dicen que para nuestra aplicación se deberá trabajar
con capacidades que están en el orden de entre 1000 y 2000 MFLOPS. Optamos finalmente
por el DSKC6713, que cubre en forma aceptable todos los requerimientos impuestos. Las
principales características del DSP, en cuanto a performance, son enumeradas a continuación.
Chip DSPC6713
▫ Reloj de 225 MHz

▫ 1350 MFLOPS
▫ 1800 MIPS
▫ Ocho instrucciones de 32 bits en paralelo por ciclo de ejecución
▫ Set de periféricos optimizados para aplicaciones de audio
▫ Compilador C/C++ altamente optimizado
El número de MIPS y MFLOPS especificado surge a raíz de que las ocho unidades
funcionales soportan operaciones de punto fijo, pero sólo seis pueden ejecutar instrucciones
de punto flotante†. Podemos acotar ahora los valores de la polifonía (número de notas
simuladas a la vez) entre un máximo y un mínimo, correspondientes a los casos de mayor y
menor rendimiento en la optimización del código. La capacidad total requerida C se calcula
según (4.3)
C = P × Cc × (1 + η) / ξ (4.3)
siendo P la polifonía, Cc el número de instrucciones por segundo demandado por cada cuerda,
η el porcentaje de recursos destinados a la tabla armónica y demás funciones y ξ es el
rendimiento en la optimización del código. Como se vio en la sección 4.2, con 80 armónicos y
una tasa de muestreo de 44,1 kHz, Cc asciende a 56,5×106 instrucciones por segundo. Se
asigna a η un valor del 20%, y la capacidad total C es de 1800×106 instrucciones por segundo.
El máximo rendimiento ξmáx es del 100%, y corresponde al caso en que en cada ciclo se
ejecuten 8 operaciones en paralelo. El mínimo rendimiento corresponde a una sola instrucción
†
Para una frecuencia de reloj de 225 MHz, el número de instrucciones por segundo usando 8 unidades
funcionales es: 225×106 × 8 = 1800 MIPS, mientras que para 6 unidades funcionales es: 225×106 × 6 = 1350
MFLOPS

por ciclo, y es ξmín = 1/8 = 12,5%. Luego la polifonía conseguida estará acotada (a cálculo
hecho) entre Pmáx = 26 cuerdas y Pmín = 3 cuerdas.

5. Características del DSKC6713 y Code Composer StudioTM
El presente capítulo tiene como objetivo resaltar las principales características técnicas de
la placa DSK en lo que respecta a su procesador y demás periféricos integrados. También se
hace una breve introducción al entorno de desarrollo Code Composer StudioTM de Texas
Instruments que acompaña al hardware (ver figura 4.1).
FIGURA 5.1. Elementos incluidos en el producto
5.1. Especificaciones técnicas del DSKC6713
Aquí se resumirán los parámetros técnicos de los principales componentes de hardware

del DSK que son el DSP propiamente dicho, la memoria externa incluida en la placa, el
Códec que permite entrada y salida de audio estereofónico, y el emulador de JTAG que
permite comunicación con la aplicación de software instalada en PC empleando la interfaz
USB. Sólo se expondrán los elementos esenciales, de mayor incumbencia en este trabajo, pero
se proporciona en las referencias muy amplia información al respecto de todos los
componentes mencionados.
5.1.1. Disposición funcional de los elementos en la placa DSK
En la figura 5.2 se observa el diagrama de bloques del DSK C6713 [31]. El DSP integrado
en la placa interactúa con los periféricos a través de un EMIF (External Memory Interface) de
32 bits. Las memorias SDRAM y FLASH, y el CPLD (Complex Programmable Logic
Device) están conectadas al bus. Las señales EMIF están también conectadas a un expansor
que permite agregar memoria adicional.

FIGURA 5.2. Diagrama de bloques del DSK C6713 – (Fuente [31])
El DSP interactúa con las señales de audio analógicas a través del códec AIC23 y cuatro
conectores de audio stereo de 3.5 mm (micrófono, entrada de línea, salida de línea y salida de
audífono). Dos McBSP (Multichannel Buffered Serial Port) operan en forma simultánea e
independientemente (en la figura 5.2 aparecen superpuestos, y se designan como McBSP0/1).
El McBSP0 es usado para enviar comandos a la interfaz de control del códec, mientras que el
McBSP1 es usado para datos de audio digitales. Ambos McBSP’s pueden ser routeados en
forma alternativa hacia conectores de expansión de periféricos, donde pueden incorporarse las
llamadas placas hijas que aportan diversas funcionalidades al DSK.
El CPLD es el responsable de gestionar la interconexión de todos los componentes. Posee
una interfaz de usuario basada en registros que permite la configuración funcional de la placa.
El DSK incluye además cuatro LEDs y cuatro switchs DIP de uso general. La placa es
alimentada con una fuente externa de 5VDC, 3,0A. El sistema es mantenido en estado de
RESET hasta que los niveles de tensión son estables.
El Code Composer Studio se comunica con el DSK a través de un emulador embebido de
JTAG (Joint Test Action Group) usando una interfaz USB (JTAG es un estándar de la IEEE
diseñado para testear circuitos impresos, y será explicado más adelante). El DSK puede usarse
también con un emulador externo a través del conector JTAG externo.
5.1.2. Arquitectura de hardware del DSP
El DSP TMS320C6713 incluido en la placa DSK es un procesador de punto flotante

basado en una arquitectura VLIW (Very Long Instruction Word) [32]. A diferencia de otras
implementaciones tradicionales como CISC (complex instruction set computer) o RISC
(reduced instruction set computer), en la arquitectura VLIW el paralelismo de instrucciones
es establecido en forma explícita en el código. De esta forma se obtiene un alto control sobre
el uso de los recursos de procesamiento.
La figura 5.3 ilustra el diagrama de bloques funcional del DSP [30]. La memoria interna
incluye un caché de dos niveles (ver [32] y [33] para información detallada). El nivel uno se
divide en 4 kbyte de memoria de datos L1D y 4 kbyte de memoria de programa L1P. El nivel
dos, L2, consta de 256 kbyte de memoria compartida entre espacio de programa y de datos.

Puede reservarse un segmento de hasta 64 kbyte en L2 para funcionar como memoria caché
de nivel dos, como se explica más adelante. Este nivel tiene una interfaz directa con las dos
memorias sincrónicas (SDRAM y SBSRAM) y las dos memorias asincrónicas (SRAM y
EPROM)
FIGURA 5.3. Diagrama de bloques funcional del TMS320C6713 – (Fuente [30])
El CPU consiste en ocho unidades funcionales independientes, divididas en dos caminos

de datos, (.M1, .L1, .S1, .D1) para el camino A y (.M2 .L2, .S2, .D2) para el camino B, como
muestra la figura 5.3. Las distintas unidades pueden ejecutar determinados tipos de
instrucciones, como se muestra en la siguiente tabla:
Aritméticas Multiplicación Manipulación Acceso a

De salto Lógicas
de bits memoria
PF PFL PF PFL
.M × ×
.L × × × ×
.S × × × × ×
.D × ×
NOTA: PF: Punto Fijo, PFL: Punto Flotante

Cada unidad funcional puede leer desde un archivo de registros dentro de su propio
camino de datos, o escribir en él, en forma directa. Cada camino incluye un conjunto de 16
registros de 32 bits, A0 – A15 y B0 – B15. Dos caminos cruzados (cross paths) 1X y 2X,
permiten a las unidades funcionales de un camino de datos acceder a un operando de 32 bits
ubicado en el archivo de registros del lado contrario. Puede haber un máximo de dos lecturas
de camino cruzado por ciclo. Las unidades funcionales de un lado pueden acceder así al set de
registros del lado opuesto. Hay 32 registros de propósitos generales, pero algunos de ellos
están reservados para direccionamiento específico, o son usados para instrucciones
condicionales.
5.1.3. Memoria interna y externa
La placa DSK incluye, además de los 264 kbyte de memoria interna (L1+L2), que
comienza en la dirección 0x00000000h, 16 Mbytes de memoria externa SDRAM accesibles a
partir de la dirección 0x80000000h. El DSK también incluye 512 kbyte de memoria FLASH,
de los cuales 256 kbyte están disponibles al usuario. Ésta comienza en la dirección
0x90000000h. La figura 5.4 muestra la interacción de los dos niveles de memoria interna, L1
y L2, con el procesador, los periféricos y la memoria externa.
FIGURA 5.4. Diagrama de bloques de la estructura de dos

niveles de memoria interna – (Fuente [33])
Es posible configurar el sistema de forma de reservar una parte de la memoria interna L2

para funcionar como caché en el acceso a la memoria externa SDRAM. Esto permite agilizar
en muchos casos el acceso a datos consecutivos que estén albergados en dicho espacio de
memoria [33], y así compensar en parte la baja velocidad de la SDRAM. En la figura 5.5 se
observan las posibles configuraciones de la caché L2. El modo de trabajo se establece en el
campo L2MODE del registro CCFG (cache configuration register), accesible a través de la
herramienta de configuración incluida en el entorno de desarrollo, explicado más adelante. Se

reservan para la caché L2 un mínimo de 16 kbyte (1-way cache) y un máximo de 64 kbyte (4-
way cache). En general, a una caché L2 mayor, corresponde un menor tiempo medio de
acceso a los datos alojados en memoria externa. Si los accesos a memoria externa no fueran
críticos para la aplicación, también es posible deshabilitar la caché L2, disponiendo de los 256
kbyte como memoria interna de uso general.
FIGURA 5.5. Modos de configuración de la caché L2 – (Fuente [33])
La caché interna, L1, actúa como intermediaria para los accesos a la memoria interna L2.
La misma se divide en 4 kbyte para datos (L1D) y 4 kbyte para código (L1P). Esta es la única
memoria de la tarjeta lo suficientemente rápida como para permitir un acceso en cada ciclo de
ejecución. Como se verá en capítulos siguientes es vital, para lograr la performance requerida,
estructurar el programa y los datos de las secciones críticas cuidando siempre que el uso de la
caché L1 sea óptimo.
5.1.4. Códec AIC23
La placa DSK incluye un códec TLV320AIC23 (en [35] se adjunta su hoja de datos), para
entrada y salida. La figura 5.6 muestra el diagrama de bloques del circuito del códec. El
posible seleccionar el micrófono o la entrada de línea como la entrada activa a través de la
bandera INSEL del registro Audio Analog Path Control del códec. El circuito ADC digitaliza
la señal analógica de entrada de audio y la hace disponible para ser procesada directamente
por el DSP. Un circuito DAC cumple la función complementaria, permitiendo la salida de la
señal de audio procesada o sintetizada por el DSP. Un filtro de salida reconstruye la señal
analógica, que luego es enviada a ambas salidas (LINE OUT y HP OUT) simultáneamente.

FIGURA 5.6. Diagrama de bloques del códec TLV320AIC23 – (Fuente [35])
El AIC23 es un códec de audio stereo basado en la técnica Sigma-Delta. El circuito

ejecuta todas las funciones requeridas para ADC y DAC, filtrado pasabajos, sobremuestreo,
etc.
El códec contiene especificaciones para transferencia de datos de palabras con longitud de
16, 20, 24 y 32 bits. La longitud de las palabras se establece en el campo IWL del registro
Digital Audio Interface Format. No debe confundirse esta especificación con la de resolución
de muestreo, que es como máximo de 16 bits por muestra. Los conversores Sigma-Delta
pueden alcanzar alta resolución con alta relación de sobremuestreo, pero con tasas más bajas
de muestreo. Éstos pertenecen a una categoría en la cual la tasa de muestreo puede ser mucho
mayor que la tasa de Nyquist. Son soportadas tasas de muestreo de 8, 16, 24, 32, 44.1, 48 y 96
kHz, que pueden ser fácilmente configuradas en el programa. Un cristal de 12 MHz actúa
como reloj para el códec (como también para el DSP y la interfaz USB). Las distintas tasas de
muestreo son seteadas a través del campo SR del registro Sample Rate Control del códec, que
actúa como divisor de frecuencia.
La comunicación de entrada/salida entre el códec y el DSP C6713 se realiza a través de
los dos puertos serie McBSP. El McBSP0 es usado como un canal unidireccional para enviar
una palabra de control de 16 bits al AIC23. El McBSP1 es usado como un canal bidireccional
para enviar y recibir datos de audio.

5.1.5. Emulador JTAG
JTAG (Joint Test Action Group) es el nombre usado para el estándar IEEE 1149.1
denominado Standard Test Access Port and Boundary-Scan Architecture para puertos de
acceso de prueba, y fue creado para testear tarjetas de circuitos impresos [36]. Hoy en día se
emplea principalmente para testear sub bloques de circuitos integrados, y también es útil
como mecanismo de depuración de sistemas embebidos, proveyendo una vía alternativa de
acceso al sistema. Cuando es usado como una herramienta de depuración, un emulador
integrado al circuito, el cual emplea JTAG como mecanismo de transporte, permite al
programador acceder a un módulo de depuración montado en el chip. Así el JTAG
proporciona al usuario la capacidad de depurar el software de un sistema embebido.
En la placa DSK C6713 se incluye un emulador embebido de JTAG que emplea la
interfaz USB. La aplicación host que se ejecuta en la PC puede así intercambiar información
de depuración y control con la aplicación target que se ejecuta en la placa DSK. Hoy en día,
la emulación de JTAG es preferida en lugar de la versión original integrada al circuito. En
otras palabras, se incorpora un dispositivo que emula la función del dispositivo original, pero
que tiene pines adicionales que permiten hacer visibles ciertas estructuras internas del
dispositivo. Si bien aun no es satisfactoria para comunicaciones de alta velocidad, esta
tecnología permite mover datos hacia y desde la aplicación target sin interrumpir la ejecución.
Se explicará en más detalle el mecanismo de comunicación entre host (PC) y target (DSK) en
la sección dedicada a RTDX (Real Time Data Exchange).
5.2. Entorno de desarrollo Code Composer StudioTM
Code Composer Studio (CCS) provee un entorno integrado de desarrollo (IDE) para
incorporar las herramientas de software. CCS incluye herramientas para generación de
código, tales como un compilador de lenguaje C, un ensamblador y un enlazador (linker).
Tiene capacidades gráficas y soporta depuración en tiempo real. Provee una herramienta de
software fácil de usar para construir y depurar programas, brindando una plataforma que
soporta todos los procesadores y tarjetas integradas de Texas Instruments. Entre sus funciones
se cuentan herramientas de monitoreo de contenido de memoria, graficación de datos,
depuración paso a paso, optimización automática de código, gráfico de ejecución de procesos,
medición del uso de recursos y múltiples herramientas de gestión y configuración.
5.3. DSP/BIOS
DSP/BIOS es un núcleo escalable de tiempo real diseñado para aplicaciones que requieren
planeamiento (scheduling) en tiempo real y sincronización, comunicación host – target (PC –
DSK) o instrumentación en tiempo real. El DSP/BIOS provee multitarea interrumpible
(preemptive multi-threading), abstracción de hardware, análisis en tiempo real y herramientas
de configuración. (ver [37] para información detallada).
Los programas de aplicación usan DSP/BIOS haciendo llamados a su API (Application
Program Interface), la cual está dividida en distintos módulos. Los mismos proveen interfaces
llamables desde código en lenguaje C. Además, algunos de los módulos API contienen
macros optimizadas en lenguaje Assembler. La mayoría de las interfaces llamables desde C
pueden también ser llamadas desde lenguaje Assembler, respetándose las mismas
convenciones de llamados a funciones para ambos.
Así DSP/BIOS proporciona una capa de abstracción de los dispositivos a nivel de
hardware, permitiendo migrar el código de una familia de procesadores a otra fácilmente. El
núcleo en cuestión está orientado a objetos, cada uno de los cuales actúa como interfaz para
una función específica de hardware (gestión de memoria, manejo de temporizaciones,
comunicaciones con el host y con el códec, esquema de prioridades e interrupciones,

sincronización y comunicación entre tareas, funciones de depuración y monitoreo, etc.) La

herramienta de configuración brinda una interfaz gráfica de gestión de los objetos usados por
DSP/BIOS. La figura 5.7 muestra una lista de las interfaces disponibles, tal como son listadas
en el programa.
FIGURA 5.7. Distintas interfaces usadas por DSP/BIOS – (Fuente [37])
5.4. RTDX (Real Time Data Exchange)
RTDX es la más reciente tecnología de análisis de DSP de Texas Instruments [38]. Está
constituido tanto de componentes del target (DSK) como del host (PC). Un pequeña
biblioteca de software se ejecuta en el DSP target. La aplicación del DSP hace llamadas a
funciones dentro de esta biblioteca (API) para transferir datos hacia o desde la misma.
Esta biblioteca hace uso de un emulador basado en escaneo (scan-based) para mover datos
empleando la interfaz JTAG descripta en la sección 5.1. La emulación basada en escaneo es
una técnica estandarizada por la IEEE, que permite sensar los estados de las interconexiones
de los circuitos integrados de una placa, almacenando dicha información en bits sucesivos de
un registro de desplazamiento [47].
En la plataforma host, una biblioteca RTDX opera en conjunto con CCS, actuando como
intermediaria entre las aplicaciones host y target de usuario.

Las herramientas de análisis y visualización se comunican a través de RTDX, tanto para la

gestión interna de los procesos por parte de CCS, como para monitoreos personalizados del
flujo del programa por parte del usuario. Pero la principal utilidad de esta tecnología es, en
nuestro caso particular, la posibilidad de establecer canales de comunicación entre la
aplicación target y la host. La API proporcionada es compatible con programas host escritos
en lenguaje Visual Basic y Visual C++, a través del uso de un cliente de automatización OLE
(Object Linking and Embedding) (ver figura 5.8). Así es posible enviar al sintetizador los
parámetros de simulación, de control y de configuración .
FIGURA 5.8. Flujo de datos RTDX entre host y target – (Fuente [37])

6. Desarrollo de la Aplicación Host
En este capítulo se aborda el desarrollo de la aplicación de software que se ejecuta en la

PC. La aplicación host ha sido dividida en dos partes principales: modalidad de edición y
modalidad de control. Primero se presenta un diagrama de bloques funcional a grandes rasgos
de cada modalidad. Los algoritmos involucrados se explican brevemente. Para información
detallada se adjunta el código fuente completo, que está comentado en su totalidad.
6.1. Modalidad de edición
Esta parte del programa proporciona herramientas de edición. Cada instrumento virtual
consta de 60 notas, cada una de las cuales consta de una cuerda y de un martillo. Los
parámetros físicos que describen ambos elementos son en total 15 y se enumeran a
continuación:
ρc Densidad de la cuerda [kg/m3]

Ec Módulo de Young de la cuerda [N/m2]
Lc Longitud de la cuerda [m]
Ac Sección transversal de la cuerda [m2]
Ic Momento de inercia de la cuerda [m4]
D1c Coeficiente de disipación independiente de la frecuencia [kg/(m × s)]
D3c Coeficiente de disipación dependiente de la frecuencia [kg m/s]
Tsc Tensión de la cuerda [N]
Xac Posición del punto de observación [m]
Xec Posición del punto de excitación [m]
Mh Masa del martillo [kg]
αh Exponente de no linealidad del martillo [adimensional]
Kh Constante elástica de compresión del martillo [N/mα]
μh Constante viscoelástica del martillo [s/m]
ΔXeh Longitud de contacto entre cuerda y martillo [m]
Además de estos parámetros, para que el instrumento virtual quede totalmente

caracterizado, deben incluirse los parámetros de la tabla armónica y los que definen la
distribución de paneo. Los primeros son simplemente un cierto número de muestras de la
respuesta al impulso de la tabla armónica, de forma de efectuar directamente la convolución a
partir de ellos. La distribución de paneo, como se vio en la sección 5.3, queda caracterizada
por un conjunto de 60 coeficientes (αL) uno para cada cuerda. Los 60 coeficientes αR
asociados a éstos son calculados como αR = 1 – αL , siendo su explicitación redundante.
La modalidad de edición es la parte del programa que permite establecer (editar) todos los
parámetros enumerados, y así generar instrumentos virtuales completos. Para lograr esto, se
proporciona al usuario un conjunto de funciones. La figura 6.1 muestra un diagrama de
bloques funcional de esta modalidad de la aplicación host.

FIGURA 6.1. Diagrama de bloques de la aplicación host – Modalidad de edición
6.1.1. Parámetros de sistema
Los parámetros del sistema se dividen en los parámetros físicos, que ya se explicaron en
los párrafos anteriores, y en los parámetros de simulación. Estos últimos definen los
parámetros de la simulación que se realiza en forma offline, y cuyo fin es poder escuchar en
forma previa el sonido correspondiente al conjunto de parámetros físicos, de a una cuerda a la
vez. Los parámetros de simulación son los siguientes:
Tiempo de simulación Establece el número de segundos de la simulación offline

Frecuencia de muestreo Permite modificar la tasa por defecto de 44.1 kHz
Número de armónicos Permite especificar un número de armónicos distinto del valor
por defecto de 80. Esto se aplica únicamente a la simulación
offline, y no modifica el número de armónicos considerados en
la aplicación target
Velocidad del martillo Establece la velocidad inicial del martillo entre un valor
mínimo de 1 y un máximo de 127 (equivalente al parámetro
velocity usado en MIDI*)
*
Se ha supuesto que la relación entre la velocidad del martillo y el parámetro velocity es lineal, aunque esto no
es cierto en general. En algunos teclados MIDI la correspondencia entre éstos es especificada por el fabricante.
Una posible extensión de la aplicación permitiría al usuario definir dicha relación arbitrariamente.

6.1.2. Funciones de edición
Las funciones de edición procesan los parámetros de sistema y generan información que
luego es utilizada por las funciones de monitoreo.
− Simulación
Esta función implementa el mismo algoritmo que el sintetizador partiendo de los

parámetros físicos y de simulación. La simulación es offline, y no presenta ningún tipo de
optimización. Se simula una única cuerda a la vez, pudiéndose seleccionar la cuerda actual
entre las 60 del registro completo. Se calcula la posición instantánea de la cuerda, su
velocidad, la fuerza de contacto entre cuerda y martillo y la señal ya convolucionada.
Luego de obtenidas la señales, las mismas son sometidas a una normalización de valor
máximo y almacenadas en un buffer.
− Funciones de documento
Éstas proporcionan la clásica funcionalidad de abrir y guardar los archivos. Los

mismos contienen todos los parámetros físicos y de simulación, además de algunos
parámetros auxiliares que se explican más adelante. La información se almacena en
archivos de formato binario, de extensión .pi (parámetros de instrumento).
− Configuración de parámetros físicos
Para caracterizar completamente a un instrumento virtual es necesario explicitar todos

los parámetros de cada una de las cuerdas, lo que se traduce en la necesidad de introducir
manualmente un total de 900 parámetros independientes. Para hacer más factible la
edición, se han incorporado los llamados puntos de configuración. Éstos se disponen en
determinadas notas a lo largo del registro del instrumento, y el usuario puede fijar sus
posiciones en forma arbitraria. Al establecer un punto de configuración en la posición de
una nota particular, el programa permite al usuario especificar los 15 parámetros
asociados a dicha nota.
Una vez establecidos los valores en los n puntos de configuración dispuestos por el
usuario, el programa calcula en forma automática los parámetros de todas las demás notas.
Para esto se recurre a una simple interpolación lineal, parámetro a parámetro, que produce
una variación gradual de los valores (y por lo tanto de los sonidos correspondientes) de
notas adyacentes, ubicadas entre puntos de configuración sucesivos (ver figura 6.2). Una
posible extensión sería realizar una interpolación más sofisticada, como ser una cuadrática
o cúbica (spline). La primera y última notas son siempre puntos de configuración, y sus
parámetros deben explicitarse indefectiblemente.
Como se explica más adelante, al activarse la función de autofrecuencia, uno de los
parámetros físicos que define la frecuencia fundamental se calcula a partir de los otros, en
cada una de las notas. En tal caso, los valores de dicho parámetro, entre puntos de
configuración, no son determinados por interpolación.

FIGURA 6.2. Interpolación lineal de parámetros físicos

entre puntos de configuración sucesivos
− Funciones auxiliares
Algunas de las funciones de edición implementadas no entran dentro de las categorías

anteriores, pero no dejan de ser importantes:
1. Función de autofrecuencia
Normalmente se pretenderá obtener un instrumento cuya afinación corresponda a

la de una escala temperada uniforme. Bajo esta afinación, corresponde a la nota A4
(La Nº4) una frecuencia fundamental de 440 Hz. La relación entre las frecuencias
correspondientes a dos notas separadas por una octava completa es f2 / f1 = 2, mientras
que para notas adyacentes la relación es f2 / f1 = 21/12 (ver [39])
Los parámetros físicos que determinan la frecuencia fundamental de oscilación de

una cuerda son únicamente cuatro. Los demás son responsables del timbre del
instrumento y de la forma de su envolvente, pero no afectan la afinación de la nota. La
expresión de la frecuencia natural es la siguiente:
1 Tc
f0 = (6.1)
2 Lc ρ c Ac
La función autofrecuencia permite al usuario seleccionar uno de los cuatro

parámetros físicos, Lc , Tc , ρc y Ac , el cual será determinado automáticamente por el
programa como una función de los tres restantes, y de la frecuencia fundamental f0
correspondiente a la nota en cuestión. En otras palabras, el valor de uno de los
parámetros queda condicionado al valor de los demás, produciendo la afinación
deseada en forma automática.
Como opción adicional, el usuario puede dejar los cuatro parámetros
deseleccionados, lo cual lo posibilita a establecer manualmente la afinación en forma
libre. Esta función podría extenderse de modo de permitir la especificación de

diferentes escalas musicales completas, con lo cual el algoritmo ajustaría los

parámetros automáticamente para obtener las afinaciones correspondientes.
2. Función de normalización
Durante la edición, las diferentes combinaciones de parámetros físicos pueden

arrojar simulaciones en que los valores máximos de la excursión de la cuerda varíen
significativamente de un instrumento a otro, o aun de una cuerda a otra en el mismo
instrumento. Es necesario entonces homogeneizar las respuestas de todas las notas y
de todos los instrumentos, en forma acorde al rango dinámico admitido por la interfaz
de control. Para ello consideramos un parámetro velocity de referencia, y debemos
lograr que para dicha velocidad inicial del martillo, los sonidos presenten la misma
intensidad sonora en todos los casos.
Para implementar este escalamiento o ajuste de amplitud, se incorpora al sistema
un nuevo coeficiente denominado coeficiente de normalización. Éste es calculado para
cada nota de cada instrumento, de forma tal que al ser aplicado como ganancia a la
salida simulada de dicha nota, correspondiente a la velocity de referencia, el nivel
obtenido sea siempre el mismo. Este cálculo se efectúa en forma offline, en la
aplicación host, y dicho coeficiente de normalización pasa a formar parte del conjunto
total de parámetros físicos de cada nota.
El procedimiento de normalización consiste en simular los primeros 15 ms, a partir
del instante en que la cuerda entra en contacto con el martillo, y analizar la señal final
ya convolucionada. En algunas aplicaciones suele usarse una normalización de valor
máximo, que divide la señal por el valor absoluto del máximo valor alcanzado en el
intervalo analizado. Así el valor máximo es siempre unitario. Si bien esta
normalización es sencilla, no garantiza que la intensidad del sonido producido sea
siempre la misma, dado que ésta depende del valor eficaz de la señal y no del valor de
pico. En nuestro caso se ha implementado la segunda opción, siendo la fórmula de
cálculo la siguiente:
M −1
1
Yef =
M
∑y
k =0
2
(k ) (6.2)
donde el número de muestras es en nuestro caso M = 44100 × 0.015 ≅ 661. Antes de

evaluar el valor eficaz, la señal y(k) pasa por una etapa de filtrado en que se
remueven las componentes espectrales inferiores. Esto evita que la normalización
quede afectada por la energía asociada a frecuencias inaudibles. Por último, el
coeficiente de normalización se calcula como el valor inverso de Yef , multiplicado por
una constante.
Este método normaliza la intensidad de la onda acústica en el rango audible, pero
no garantiza que la sonoridad sea uniforme en todo el registro, dado que ésta depende
de un modo complejo del contenido espectral de la señal. Aunque no ha sido
implementada, una posibilidad sería introducir un ajuste empírico más fino, por parte
del usuario, basado en la preescucha de la simulación (explicada más adelante).
Al guardar un documento, el programa establece el parámetro velocity en el valor
de referencia, y simula sistemáticamente los primeros 15 ms, haciendo un barrido de
todas las notas del registro. Los 60 coeficientes de normalización así obtenidos son
almacenados en el archivo de parámetros de instrumento (.pi). Nótese que los
coeficientes de normalización no resultan iguales para distintas tablas armónicas, aun
cuando coincidan nota a nota los demás parámetros físicos.

6.1.3. Funciones de monitoreo
Las funciones de monitoreo son las responsables de presentar al usuario los resultados de
la simulación.
− Visualización
Esta función genera una representación gráfica de las señales obtenidas por
simulación. En un panel se grafican superpuestas la posición de la cuerda, su velocidad, la
fuerza de contacto y la señal convolucionada. Cada una de ellas puede graficarse u
omitirse a discreción del usuario. Una opción especifica al programa que se visualicen
únicamente los primeros 40 ms de simulación. Esto permite analizar en detalle las formas
de onda durante el corto tiempo de contacto entre la cuerda y el martillo. En este lapso de
tiempo se definen la mayor parte de las características espectrales del sonido final.
Corresponde a tiempos de contacto pequeños un sonido más brillante, mientras que
tiempos de contacto grandes (mayores a 3 ms) producen sonidos opacos [12]. Además de
las gráficas, se visualizan en forma numérica los valores máximo y mínimo de la
excursión de cada una de las cuatro señales consideradas.
− Preescucha
Luego de efectuada la simulación y la normalización correspondiente, los datos son

volcados a un archivo temporal de audio en formato Microsoft WAVE soundfile (.wav). En
[40] se describe el formato de su encabezado y sus campos de datos. Mediante un pequeño
conjunto de controles incorporados a la interfaz gráfica, el usuario puede fácilmente
escuchar el sonido generado. De esta forma el ajuste de los parámetros es más eficaz.
6.1.4. Interfaz audiovisual
En la figura 6.3 se muestra el aspecto final de la interfaz gráfica de la modalidad de edición.

FIGURA 6.3. Interfaz audiovisual de usuario de la modalidad de edición

1. Panel de visualización. Aquí se presentan las gráficas de las señales simuladas. La gráfica
verde es la posición de la cuerda, la azul es la velocidad, la magenta es
la fuerza de contacto, y la naranja es la señal convolucionada.
2. Selección de autofrecuencia. Un conjunto de controles checkbox permite seleccionar cuál de los

cuatro parámetros que determina la afinación será ajustado
automáticamente por la función de autofrecuencia.
3. Parámetros de simulación. Aquí se introducen los valores numéricos que caracterizan a la

simulación.
4. Selección de la nota actual. El usuario puede seleccionar de una lista desplegable la nota que desea
editar.
5. Puntos de configuración. Estos comandos permiten establecer o eliminar puntos de configuración,

o desplazarse entre notas que tengan asignados puntos de
configuración consecutivos.
6. Selección de tabla armónica. Una lista desplegable permite seleccionar una respuesta al impulso
particular entre todas las almacenadas en un conjunto de archivos
7. Comando de simulación. Permite iniciar el proceso de simulación
8. Comandos de documento. Permiten efectuar las funciones de abrir, guardar y nuevo documento.
9. Comando de preescucha. Un control multimedia permite reproducir, pausar y detener el sonido,

una vez simulado
10. Visualización de datos. Aquí se muestran los valores máximos y mínimos de las cuatro señales
simuladas. Cuatro controles de checkbox permiten habilitar o deshabilitar
la representación gráfica de cada señal.
11. Ajuste de parámetros físicos. Un conjunto de barras de desplazamiento permite ajustar el valor de
cada uno de los parámetros, entre un mínimo y un máximo. El valor
máximo puede establecerse a un número arbitrario de punto flotante de
32 bits. Los valores así ingresados pueden tomar diversos órdenes de
magnitud.
FIGURA 6.3 (bis). Referencias de la Figura 6.3
6.2. Modalidad de control
Esta modalidad del programa permite transmitir a la aplicación target todos los
parámetros que caracterizan al instrumento virtual activo. El dispositivo sintetizador, a partir
de ellos, simulará en forma permanente la dinámica de su modelo físico asociado. La
modalidad de control es a su vez responsable de la transmisión de las señales de control. Estas
son leídas en forma de mensajes MIDI desde el teclado. Luego de un procesamiento mínimo,
dichas señales se transmiten en forma de parámetros asimilables por la aplicación target.
Finalmente, la información es transmitida hacia la placa DSK, a través del puerto USB, e
ingresada al modelo físico. De esta forma, las señales de control actúan sobre las variables
cinemáticas de los martillos produciendo una respuesta interactiva. La figura 6.4 muestra el
diagrama de bloques funcional de la modalidad de control.

FIGURA 6.4. Diagrama de bloques de la aplicación host – Modalidad de control
6.2.1. Parámetros de sistema
Almacenan toda la información necesaria para establecer completamente el modelo, más

la información de control, tal como deben ser transmitidas a la aplicación target.
− Parámetros de instrumento
Son los 15 parámetros físicos de cada una de las 60 cuerdas del instrumento virtual
seleccionado, más los 60 coeficientes de normalización calculados para una tabla
armónica específica. Todos los valores se almacenan como datos de punto flotante de 32
bits, lo que hace un total de: M = (60 × 15 + 60) × 4 = 3840 bytes
− Coeficientes de tabla armónica
Son las primeras 512 muestras de la respuesta al impulso de la tabla armónica

seleccionada. Cada una de ellas se almacena en un dato de punto flotante de 32 bits,
siendo el total de memoria requerido: M = 512 × 4 = 2048 bytes

− Distribución de paneo
Queda totalmente descripta por un total de 60 valores de punto flotante de 32 bits.

Cada uno de ellos varía entre 0 y 1, y especifica para cada una de las notas del registro el
porcentaje de la señal final que es enviada al canal izquierdo (αL , sección 5.3)†. El
consumo de memoria es: M = 60 × 4 = 240 bytes
− Estado de las teclas
Un primer buffer almacena el parámetro velocity de cada una de las teclas del teclado
MIDI. Los valores van de 0 a 127, por lo que cada dato puede ser almacenado en un solo
byte de memoria. Los mensajes del controlador MIDI son filtrados, ya que no todos ellos
son relevantes para la aplicación, y luego son decodificados.
En la referencia [27] se brinda una explicación detallada de los conceptos
fundamentales de MIDI. Los mensajes MIDI transportan distintos tipos de información, y
pueden ser mensajes de ejecución musical, mensajes de sistema, mensajes de
configuración, entre otros. Dentro de los primeros, que son los que nos interesan, están:
note off (desactivación de nota), note on (activación de nota) y control change (cambio de
control). Los dos primeros indican cuándo una tecla es presionada, y con qué intensidad, o
cuando una tecla es liberada. El mensaje de control change indica que se ha producido un
ajuste de algún controlador asociado al teclado MIDI. Estos controladores pueden ser de
volumen, ingreso de datos, expresión, efectos y pedal de sostén, entre otros.
Todos los mensajes MIDI están conformados por un campo de tres bytes. El primer
byte actúa como encabezado. Sus cuatro bits más significativos dan información del
estado, y los cuatro menos significativos identifican al canal MIDI que está siendo usado,
dentro de un total de 16 canales disponibles. El formato de los campos binarios de los
mensajes MIDI de note on, note off, y control change – sustain se enumeran a
continuación: (la información se obtuvo del manual del fabricante del teclado MIDI [41])
Mensaje Estado 2º byte 3º byte

Note on 9nH kkH vvH
Note off 8nH kkH vvH
Control change
BnH 42H ccH
- Sustain
n = Número de canal MIDI: 0H – FH (canal 1 – 16)

kk = Número de nota: 00H – 7FH (0 – 127)
vv = Velocity de la nota: 00H – 7FH (0 – 127)
cc = Valor de control: 00H – 7FH (0 – 127) 0-63=OFF, 64-127=ON
• Los números de nota fuera del rango 15-113 son transpuestos a la octava más cercana
dentro del mismo
• La función de transposición del teclado no afecta los números de nota reconocidos
• Los valores de velocity de los mensajes de note off son ignorados
La adquisición de datos de control ha sido implementada a través de un control

especial de Visual Basic que llama una subrutina cada vez que un nuevo mensaje MIDI es
†
αR queda determinada como αR = 1 – αL siendo innecesario su almacenamiento
recibido. Luego un algoritmo simple analiza el encabezado y actualiza la tabla que

almacena el estado de las teclas.
Existe una segunda tabla que almacena la información de control tal como será
enviada al sintetizador. La información es ingresada, a medida que es recibida desde el
dispositivo MIDI, en un buffer que actúa como una cola FIFO. Este buffer almacena un
máximo de 20 eventos de teclado. Cada evento está formado por 2 bytes de información.
El primer byte indica el índice de tecla al que corresponde el evento. El segundo byte
almacena el valor de velocity, indicando los valores de 1 a 127 un evento de activación de
tecla (note on) y estando reservado el valor 0 para el evento de desactivación de tecla
(note off). Finalmente, el buffer ocupa un total de: M = 20 × 2 = 40 bytes
6.2.2. Funciones de control
Gestionan la comunicación con el DSK. Se clasifican en:
− Conexión con DSK
Intenta crear un canal de comunicación unidireccional con el DSK, haciendo uso de

las funciones de la biblioteca RTDX. Primero selecciona uno de los dispositivos DSK
disponibles (en caso de haber más de uno), luego define los parámetros RTDX del sistema
(tamaño del buffer, opción de registro de mensajes, modo de trabajo). Por último habilita
el canal de comunicación, quedando disponible para ser usado por otras secciones del
programa. Esta función también se encarga de destruir el canal y liberar los recursos
asociados al mismo cuando el usuario lo desee.
− Transmisión de parámetros de simulación
Un total de tres funciones independientes permiten transmitir en forma secuencial los

parámetros físicos, de la tabla armónica o de la distribución de paneo, en forma
independiente. La comunicación se logra a través de funciones de la biblioteca RTDX,
que a su vez provee la notificación de posibles errores de transmisión. Los buffers más
extensos son enviados en partes sucesivas, para evitar que el sistema se interrumpa
durante un lapso de tiempo demasiado prolongado.
− Seteo de parámetros de control
La tabla que almacena los eventos de control más recientes es enviada periódicamente
a la aplicación target. En el caso de que los eventos de control generados entre
transmisiones sucesivas de la tabla excedan la capacidad de almacenamiento de esta
última, los datos son transmitidos inmediatamente al target. Luego de cada transmisión, la
información de la tabla es descartada y así puede actualizarse con los nuevos eventos de
control.
La transmisión de eventos de control se ha implementado de esta forma para reducir lo
más posible la latencia de la comunicación RTDX. Cada envío de paquetes tiene asociado
un retardo fijo, independiente del tamaño del paquete, que es inherente al sistema RTDX.
Así un esquema en el que se enviara un único evento de control en cada paquete sería
menos eficiente que uno en que se enviaran paquetes de mayor longitud, agrupando cierto
número de eventos. De esta forma se produce un menor número de transmisiones de
datos, y se minimiza el efecto del retardo fijo dentro de la performance general. El número
de eventos que se envía en cada paquete es necesariamente variable, ya que evidentemente
no se puede esperar a que el intérprete genere una cierta cantidad de eventos para enviar la
información al sintetizador. No obstante, si se aumenta indefinidamente el tamaño de los

paquetes la performance comenzará a decaer. Esto es debido a que los envíos de datos se
harán con menor frecuencia, aumentando el intervalo medio de tiempo transcurrido entre
sucesivas transmisiones hasta valores inadmisibles para la aplicación. Así el tiempo medio
entre transmisiones debe ajustarse hasta obtener la mejor performance.
Se trata de funciones que no son directamente accesibles al usuario, sino que se

ejecutan de forma automática durante la inicialización de la aplicación. Una de ellas se
encarga de detectar los dispositivos MIDI conectados al sistema, almacenar cierta
información de los mismos y luego enumerarlos en una lista. La otra función cumple un
rol análogo, pero se aplica a los dispositivos DSK que estén disponibles. Aun cuando no
existiera más de uno de cada uno de ellos, esta función es necesaria ya que obtiene la
identificación del hardware dentro del sistema operativo. Este dato es uno de los
parámetros requeridos por las funciones de inicialización y configuración de los
dispositivos.
6.2.3. Funciones de monitoreo
Las funciones de monitoreo dan información visual sobre el estado de la comunicación, la

actividad del dispositivo MIDI y algunos parámetros de simulación.
− Visualización del estado de las teclas
En un panel gráfico se muestran esquemáticamente las 88 teclas del dispositivo MIDI.

Cada una de ellas es dibujada con un color que guarda relación con la intensidad con que
la misma es presionada (parámetro velocity). Así se tiene una visualización gráfica
interactiva del estado de las señales de control, independientemente del estado de
conexión con el DSK.
− Panel de mensajes
Un pequeño panel de mensajes de texto va registrando todas las operaciones relativas

a la comunicación con el dispositivo target. Una vez concluidas, se indica si el resultado
de la operación ha sido exitoso o fallido.
− Visualización de parámetros de simulación
Un par de paneles muestran una representación gráfica de los parámetros de

simulación. En uno de ellos se grafica la distribución de paneo (para ambos canales) y en
el otro se grafica la respuesta al impulso de la tabla armónica seleccionada.
6.2.4. Interfaz gráfica
En la figura 6.5 se muestra la interfaz gráfica de la modalidad de control.

FIGURA 6.5. Interfaz audiovisual de usuario de la modalidad de control
1. Estado de la entrada MIDI. El panel indica el estado dinámico de cada una de las teclas. El grado de
coloración es representativo del parámetro velocity.
2. Selección de dispositivo MIDI. Un par de listas desplegables permiten enumeran los dispositivos de entrada y
salida MIDI conectados al equipo, que fueron detectados automáticamente.
3. Distribución de paneo. Aquí se representan gráficamente las dos curvas de distribución de paneo. La
proporción destinada al canal L se muestra en verde, mientras la del canal R se
muestra en magenta. Una lista desplegable permite seleccionar una entre un
conjunto de distribuciones predefinidas.
4. Conexión con DSK. En una lista se presentan los dispositivos DSK conectados al equipo, que fueron
autodetectados. Un botón permite conectar y desconectar la aplicación host de
la aplicación target en cualquier momento.
5. Tabla armónica Aquí se grafica la respuesta al impulso de la tabla armónica actual. La misma es
seleccionada a través de una lista desplegable que enumera todas las tablas
armónicas disponibles.
6. Parámetros de instrumento virtual. Una lista muestra todos los archivos de parámetros de instrumento (*.pi)
almacenados en la ubicación del programa. Las operaciones de guardar
documento de la modalidad de edición, producen la actualización automática de
los contenidos de la tabla.
7. Panel de mensajes. En esta ventana de texto se van mostrando los sucesivos mensajes
relacionados con la comunicación entre host y target.
FIGURA 6.5 (bis). Referencias de la Figura 6.5

7. Desarrollo de la Aplicación Target
En este capítulo se incursiona en los diferentes aspectos de la aplicación target que se

ejecuta permanentemente en la placa DSK. Al igual que en el capítulo 6, se adjuntan los
códigos fuente completos. En el anexo C figuran las partes críticas del código, que merecen
una atención especial.
7.1. Análisis funcional de la aplicación
La figura 7.1 muestra el diagrama de bloques funcional de la aplicación target. En el

mismo se muestran las tareas (tasks) principales que se ejecutan en forma paralela, y la forma
en que éstas acceden a las funciones y datos de la aplicación.
FIGURA 7.1. Diagrama de bloques funcional de la aplicación target

La tarea de comunicación cumple el rol de gestionar la transferencia de datos de control y

de simulación provenientes de la aplicación host. Una segunda tarea de simulación lleva a
cabo un proceso cíclico que resuelve en forma permanente la simulación del instrumento
virtual descripto por los parámetros de sistema. La tercera tarea mostrada es la denominada
bucle idle (tarea ociosa).
En la sección 5.3 se explicó brevemente el núcleo DSP-BIOS, estandarizado por Texas
Instruments para sus distintas familias de procesadores. Su estructura central, o API, consta de
un conjunto de tipos de objetos (clases), cada uno de los cuales proporciona una interfaz de
acceso a los recursos o procesos de hardware del DSP y los periféricos disponibles, en forma
indirecta. Esta forma de acceso, implementada a través de un conjunto de funciones asociadas
a cada clase, provee encapsulamiento de los parámetros de configuración de cada dispositivo
(usualmente sus registros internos de control), brindando un cierto grado de independencia de
la familia o modelo específico al que pertenezca éste.
Las tareas de comunicación y de simulación son procesos definidos por el usuario. Éstas
son creadas al generar, en forma explícita dentro del código, dos instancias de objetos de la
clase TSK_Obj, definida dentro de la API del DSP-BIOS. Durante la creación de cada una, se
debe especificar el identificador de una función, definida dentro del código de usuario, la cual
contendrá el algoritmo que deberá ejecutar la tarea. Dicho algoritmo es generalmente un bucle
infinito, ya que al concluir la ejecución del mismo, la tarea asociada a él debe finalizar.
El bucle idle es el proceso de fondo, perteneciente a la estructura interna de DSP-BIOS (es
decir, no es un proceso de usuario), el cual se ejecuta continuamente mientras no esté en
ejecución ningún otro proceso (rutinas de interrupción de hardware o software, y tareas).
Cualquier proceso puede detener el bucle idle en cualquier momento, ya que el mismo es el
proceso con prioridad más baja de toda aplicación DSP-BIOS. Las funciones que se ejecutan
en este bucle son las siguientes [37]:
▫ LNK_dataPump Gestiona la transferencia de datos de análisis en tiempo real y el

canal de datos entre el target y el host. Esto es realizado a través
de RTDX. Dentro del bucle idle, esta función ejecuta el trabajo
de mayor consumo de tiempo, preparando los buffers y
haciendo las llamadas para RTDX.
▫ RTA_dispatcher Es un servidor de herramientas de análisis en tiempo real de la
aplicación target. Implementa funciones de instrumentación y
estadísticas en tiempo de ejecución.
▫ IDL_cpuLoad Emplea un objeto STS (estadísticas) para calcular el porcentaje
de recursos del procesador utilizados. Los mismos son
visualizados en una gráfica en el CCS, la cual se actualiza
periódicamente usando el RTA_dispatcher. Esta función
constituye así una herramienta útil durante el proceso de
desarrollo y depuración de la aplicación.
En la plataforma C6000, RTDX es una interfaz manejada por interrupciones. Como se

verá más adelante, para lograr una performance aceptable en cuanto a la transmisión de
eventos de control en tiempo real, es imprescindible no deshabilitar las interrupciones de
hardware (HWI) durante un lapso de tiempo demasiado prolongado.
La aplicación consta de un conjunto de estructuras de datos que almacenan todos los
parámetros del sistema, como así también de un conjunto de funciones que permiten a las
tareas de simulación y de comunicación procesar dicha información.

7.1.1. Datos de la aplicación
En la figura 7.2 se muestra la estructura del buffer que contiene el total de los parámetros
físicos recibidos desde la aplicación host. Los 16 parámetros que caracterizan a cada cuerda se
almacenan agrupados, y la estructura se repite cíclicamente para las 60 cuerdas. Dicha tabla se
denomina Conjunto de parámetros físicos de cuerdas y martillos. Una vez recibidos todos los
parámetros físicos, a partir de ellos se obtiene un conjunto de valores numéricos que son
requeridos por el algoritmo principal de simulación. La figura 7.3 muestra la forma en que se
almacenan todos estos parámetros en memoria. La tabla denominada Conjunto de coeficientes
de simulación se divide en 60 partes, una para cada nota. Cada una de dichas partes contiene
otras tres tablas. La primera almacena los coeficientes de los filtros IIR para todos los
armónicos de una cuerda. La segunda contiene los coeficientes asociados al martillo de dicha
cuerda. La última contiene únicamente el coeficiente de normalización de la nota
correspondiente, tal como aparece en el conjunto de parámetros físicos.
Como se ve, entre los parámetros del martillo no figura la constante de no linealidad αh,
sino los valores A y B, que permiten evaluar la fuerza de contacto con la función potencial
aproximada (3.13). La determinación de los mismos es realizada por la función de
transformación de parámetros, que se explicará más adelante.
FIGURA 7.2. Parámetros físicos recibidos desde la aplicación host

FIGURA 7.3. Conjunto de coeficientes transformados para el total de las cuerdas
La figura 7.4 muestra la estructura que almacena los datos asociados a las P notas activas,
es decir, las que participan en la simulación*. Toda la información se divide en dos tablas, una
para los filtros IIR y otra para los martillos. En las mismas se deben almacenar no sólo los
coeficientes constantes, sino también las variables cuyos valores se actualizan
permanentemente, en sucesivos pasos de la simulación. En el caso de los filtros, estas
variables son los dos últimos valores de la señal w(k), descrita en 3.3. En el caso de los
martillos, se almacenan los parámetros dinámicos instantáneos (posición, velocidad,
aceleración y fuerza de contacto) del martillo, además de la posición de la cuerda en los
últimos dos pasos de integración. El tamaño de las tablas es proporcional a la polifonía, P, del
sistema.
La forma peculiar en que se almacenan los datos permite evitar operaciones innecesarias
en la sección crítica. Al agrupar los parámetros en forma de constantes multiplicativas se
obtiene un código más eficiente.
*
Nótese que en la sección crítica se procesan un número constante de cuerdas P (polifonía). Esto se cumple aun
cuando un número de ellas pueda, en general, estar en estado de reposo, con un consiguiente aporte nulo al
sonido final sintetizado.

FIGURA 7.4. Subconjunto de coeficientes y variables para la simulación de las cuerdas (sección crítica)
Además de todos los datos mencionados, existe la llamada tabla de teclas activas, que
almacena información asociada a los eventos de control. Cada una de las entradas de la tabla
consta de un número que identifica la nota correspondiente al evento, su parámetro velocity,
su estado (que puede ser activa, inactiva o soltada) y un parámetro denominado tiempo, que
contiene un valor que indica la antigüedad del evento registrado. Estos parámetros se detallan
más adelante.
7.1.2. Funciones de la aplicación
A continuación se explican las funciones principales que intervienen en la aplicación

target.
− Inicialización
Esta función se ejecuta por única vez al comienzo del programa, y es responsable de
asignar espacio en memoria para almacenar todos los datos de la aplicación, y de
establecer sus valores por defecto.
Los buffers son ubicados en espacios consecutivos de memoria, cuya dirección de
comienzo (alineación) es múltiplo de un determinado número de bytes. Esta disposición
de los recursos permite que el uso de la caché sea lo más eficiente posible. En cada

solicitud de lectura de memoria, la caché crea una copia del segmento completo en el que
se aloja el dato requerido, previendo posibles accesos sucesivos a datos adyacentes al
mismo. Los segmentos copiados tienen siempre longitud y alineación fijas en memoria,
relacionadas con las características de cada caché. Para que en cada copia realizada por la
caché el segmento considerado contenga siempre datos útiles, se hace necesario alinear los
buffers de la aplicación de igual manera. En el caso de la memoria externa (SDRAM), la
alineación óptima es de 128 bytes, mientras que para la memoria interna (IRAM) la
alineación debe ser de 32 bytes [33].
Esta función es llamada desde la función main. La forma de operación de DSP/BIOS
garantiza que ninguno de los procesos de la aplicación comienza su ejecución hasta que la
función main ha concluido. Así, se evitan posibles conflictos de acceso a los recursos.
− Creación de streams
Esta función se encarga de crear el canal de comunicación (stream) entre la aplicación

y el códec AIC23. La comunicación entre la aplicación target y un periférico genérico
(device) se establece, en el marco de DSP/BIOS, a través del esquema mostrado en la
figura 7.5.
FIGURA 7.5. Entrada/Salida independiente del dispositivo

en DSP/BIOS – (fuente [37])
En este caso es necesario crear dos instancias a interfaces de DSP-BIOS, una de la

clase DEV_Obj (módulo DEV) y la otra de la clase SIO_Obj (módulo SIO).
En la parte sombreada de la figura 7.5 (módulo DEV) se concentran los elementos
dependientes del dispositivo. El manejador o driver consta de una serie de funciones que
proveen serialización y sincronización de peticiones de entrada/salida, y brinda también
algunas funciones de gestión. Las rutinas de servicio a interrupción asociadas (RSI) son
llamadas al generarse las señales de interrupción del dispositivo, actuando luego sobre el
driver según corresponda.

El módulo SIO proporciona a la aplicación target una función de entrada/salida

independiente del dispositivo. Los programas invocan indirectamente la funcionalidad
correspondiente implementada por el driver que gestiona el dispositivo físico (device)
particular al que está vinculado el stream, usando funciones genéricas provistas por el
módulo SIO (Stream In/Out). (ver [42] y [37] para información detallada sobre el manejo
de drivers).
El principio de funcionamiento del módulo SIO se ilustra en la figura 7.6. Una tarea
(TSK) de la aplicación envía o recibe datos hacia o desde un par de dispositivos virtuales.
El dispositivo virtual de entrada se divide en dos partes:
1. /scale2 designa un dispositivo que transforma un flujo de datos de punto fijo

producido por un dispositivo subyacente (/a2d) en un flujo de valores de punto fijo
escalados.
2. /a2d designa un dispositivo gestionado por el driver del dispositivo conversor A/D
– D/A, el cual produce un flujo de entrada de punto fijo desde un conversor A/D.
El dispositivo virtual de salida consta a su vez de dos partes, /mask2 y /d2a que
cumplen la función análoga pero sobre un flujo de datos en sentido opuesto. La tarea hace
uso de un par de funciones del módulo SIO: SIO_get() y SIO_put(). A través de ellas
intercambia con los dispositivos virtuales buffers con información útil (llenos) y buffers
habilitados para ser escritos (vacíos), como muestra la figura
FIGURA 7.6. Flujo de paquetes llenos y vacíos –

(fuente [37])
La conexión a través del módulo SIO permite dos modelos: el estándar, denominado
get/put, y el llamado de issue/reclaim (proveer/reclamar). El segundo es más complejo
pero brinda mayor control sobre el flujo de datos. En ambos casos, el principio de
funcionamiento es el mismo.
En la figura 7.7 se muestra el código que crea y configura un stream para envío de
datos hacia el códec AIC23. Primero se crea una instancia de una estructura SIO_Attrs,
usada para especificar los parámetros de configuración del stream. En ella se indica la
alineación en memoria de los buffers y el modo de trabajo issue/reclaim. Luego la función
SIO_create() crea un stream de salida, con un tamaño de buffer especificado†.
†
El tamaño de los buffers se discutirá en la sección dedicada a la optimización del código

static Void CrearStreams()

{
SIO_Attrs attrs;
/* Alineación del buffer para uso óptimo del caché L2 */

attrs = SIO_ATTRS;
attrs.align = BUFALIGN;
attrs.model = SIO_ISSUERECLAIM;
/* Creación del stream */

outStream = SIO_create("/dioCodec", SIO_OUTPUT, BUFSIZE, &attrs);
if (outStream == NULL) {
SYS_abort("Falló la creación del stream de salida de audio.");
}
FIGURA 7.7. Código de la función CrearStreams
− Transformación de parámetros físicos
Se designa por transformación de parámetros a la obtención del conjunto completo de

coeficientes de simulación a partir de un conjunto de parámetros físicos y de la
distribución de paneo. Las expresiones que permiten determinar todos los parámetros son
las introducidas en las secciones (5.1) para los coeficientes de los filtros IIR, (5.2) para los
coeficientes de la función potencial aproximada, y (5.3) para la descomposición
estereofónica de la señal.
El proceso de transformación involucra un gran número de operaciones, incluyendo
funciones trigonométricas y exponenciales. Para reducir al mínimo el tiempo del cálculo,
que puede ser de varios segundos, se hace uso de una biblioteca de funciones matemáticas
especial denominada FastRTS (Fast Run-Time-Support) [43]. Se trata de una biblioteca
específica de la familia C67x, incluida con CCS, donde las operaciones y funciones
matemáticas de punto flotante se encuentran altamente optimizadas para aplicaciones de
tiempo real.
− Manejo de la excitación
En la tabla de teclas activas, explicada en el ítem anterior, se almacena la información

del estado de todas las notas que están siendo simuladas. Cada una de sus entradas está
asociada a una respectiva entrada de las tres tablas que contienen el subconjunto de
coeficientes y variables de los filtros IIR, el subconjunto de coeficientes y variables de los
martillos, y el subconjunto de coeficientes de normalización. Todas las mencionadas
tablas poseen un número de entradas fijo, igual a la polifonía P. En cada una de las
entradas se almacena la información, y se reserva espacio para las variables, que emplea el
algoritmo de simulación para producir la señal estereofónica de salida de una única nota.
Cada vez que una nueva nota comienza a simularse, deben leerse todos los
coeficientes asociados a la misma desde la posición correspondiente de la tabla que
contiene el conjunto completo de parámetros de simulación. Luego éstos son copiados en
sus respectivas posiciones dentro de las tres tablas más pequeñas, que contienen los
subconjuntos de coeficientes asociados a las P notas en actividad. Algunos de los campos
de dichos subconjuntos corresponden a variables, y deben establecerse en valores iniciales
apropiados antes de comenzar la simulación de la nota.
La función de manejo de la excitación analiza las tablas de eventos de control
recibidas en tiempo real desde el host. Recorre entrada por entrada, verificando si las
mismas almacenan eventos o si están vacías. Cuando detecta un evento válido, se ejecuta
un algoritmo que lleva a cabo las acciones necesarias, de acuerdo con el tipo de evento. La
figura 7.8 muestra el diagrama de flujo de dicho algoritmo.
FIGURA 7.8. Diagrama de flujo del algoritmo de manejo de la excitación
En el caso de un evento de activación (NOTE ON) se verifica si en la tabla de teclas

activas existe un evento correspondiente a la nota en cuestión. Esta situación se produce
cuando se reciben dos eventos de activación consecutivos, y ninguno de desactivación
entre ellos. Lo cual ocurre, por ejemplo, si se presiona una tecla, luego se la suelta y
después se la presiona nuevamente, manteniendo siempre presionado el pedal de sustain.
De esta forma el algoritmo evita que se simulen a la vez dos notas repetidas.
En caso de no estar en la tabla, se intenta almacenar el nuevo evento en una entrada no
usada. Si todas las entradas de la tabla están ocupadas, lo que significa que se está
simulando el máximo número de notas simultáneas, se debe sobrescribir la entrada
correspondiente al evento más antiguo registrado. Esta estrategia es la más lógica,
teniendo en cuenta que los sonidos decaen en amplitud con el tiempo, y así las notas que
se iniciaron antes son las menos perceptibles. Para poder identificar la antigüedad de un

evento, se almacena un índice entero en el campo tiempo. Cada vez que un nuevo evento
de activación es registrado, se incrementa un contador global y se asigna al campo tiempo
el valor del contador.
Si, por el contrario, el número de nota del evento ya estaba registrado, la información
actualizada de velocity y tiempo se almacena en la misma posición dentro de la tabla de
teclas activas. En este caso basta con reinicializar las variables cinemáticas del martillo
correspondiente (en conformidad con el nuevo parámetro velocity), manteniéndose
inalterados todos los demás coeficientes y variables. También se actualiza el campo
tiempo, con lo que se evita que las próximas notas generadas sobrescriban a la actualizada
recientemente. En cualquier caso, el estado dentro de la tabla se establece en TECLA
ACTIVA.
Es interesante notar que al no reinicializar las variables asociadas a los filtros IIR,
w(k – 1) y w(k – 2), la cuerda continúa con su estado vibratorio original, hasta que se
produce el nuevo impacto. Esto permite simular lo que sucede en un instrumento real,
donde una cuerda no necesariamente vuelve al reposo cuando se la vuelve a tocar,
agregando un factor de impredecibilidad que, por lo general, no está presente en otros
tipos de sintetizadores.
Puede verse en el diagrama de la figura 7.8 que todo el proceso descrito se ejecuta con
las interrupciones de hardware deshabilitadas. Esto previene el caso de que comience un
nuevo ciclo de simulación antes de que todos los coeficientes y variables estén
completamente actualizados. En caso contrario se correría el riesgo de que la simulación
se realizara a partir de datos numéricos inconsistentes, arrojando resultados impredecibles.
Finalmente, resta explicar el caso en que el evento es de desactivación (NOTE OFF).
Aquí se analiza la tabla de teclas activas, verificando si existe una instancia de la nota
asociada al evento. Esto no siempre se cumple, ya que es posible que un número de
eventos de activación superior a la polifonía hayan sobreescrito todas las entradas de la
tabla, mientras la tecla de la nota buscada aun se encontraba presionada. En caso de estar
la nota registrada en la tabla, se establece su estado en TECLA SOLTADA. Este estado no
es igual al de TECLA INACTIVA, en el cual se libera la entrada correspondiente dentro
de la tabla de teclas activas. El estado de TECLA SOLTADA indica que la nota debe
comenzar a extinguirse (apagado), para pasar gradualmente a la inactividad. La función de
apagado se describirá luego, dentro de la categoría de funciones auxiliares.
Se trata de procedimientos que cumplen ciertas tareas muy específicas, pero no menos
importantes que las demás funciones.
i. Función de apagado
Una vez liberada una tecla, el sonido de la nota correspondiente debe extinguirse. En
el caso del piano, este proceso es llevado a cabo por el apagador, que absorbe la energía
vibrante de la cuerda por contacto. Una implementación a través de un riguroso modelado
físico exigiría modificar las constantes de atenuación D1c y D3c , de forma de concentrar
el efecto del apagador.
Una modificación de dichos parámetros físicos se correspondería con una variación de
todos los coeficientes de los filtros IIR de dicha cuerda. Sería factible obtener, para cada
una de las cuerdas, dos conjuntos completos de coeficientes, uno correspondiente al
estado normal y el otro al estado con constantes de atenuación modificadas. Este cálculo
se realizaría en forma offline, por única vez, sin repercutir en la sección crítica del código.
Ante un evento de desactivación de una nota particular, la aplicación debería copiar el
segundo conjunto de coeficientes correspondientes a dicha nota, lo cual no representaría

un tiempo demasiado grande. Como contraparte, se haría necesario almacenar en memoria

dos conjuntos completos de coeficientes para todas las cuerdas.
Existe un método alternativo, menos riguroso, pero que es más rápido y no requiere el
uso de memoria adicional. Observemos que, por analogía con los fenómenos de absorción
en procesos vibratorios, la extinción se traduce, a grandes rasgos, en una modulación de
amplitud cuya envolvente es una exponencial decreciente. Siendo el tiempo de extinción
muy corto, esta simplificación pasará relativamente inadvertida por el oyente. Para
implementar este esquema, podemos felizmente recurrir al hecho de que el coeficiente de
normalización es aplicado a la señal simulada en forma permanente. Bastará afectar a
dicho coeficiente de una atenuación exponencial para conseguir la extinción del sonido
final de la simulación, aun cuando la dinámica interna del modelo se halle en completa
actividad.
Como se verá, las señales son simuladas en bloques que agrupan un cierto número de
muestras. Durante la simulación de un bloque, la ejecución nunca es interrumpida. Así, la
aplicación de la atenuación al coeficiente de normalización de una nota solo puede
ejercerse entre simulaciones sucesivas de bloques completos. Esto se traduce en una curva
de atenuación exponencial escalonada, como la mostrada en la figura 7.9.
FIGURA 7.9. Curva de atenuación exponencial escalonada
Aquí se designa por TB al tiempo transcurrido entre simulaciones sucesivas de bloques

de muestras. La curva γ(t) presenta discontinuidades de salto que aquí han sido exageradas
para mayor claridad. Los valores que asume la curva exponencial en tres instantes
sucesivos equiespaciados un intervalo TB se designan como γ1, γ2 y γ3. Dadas las
propiedades algebraicas de la función exponencial se cumple:
−
t +T
⎛ −
T
⎞ −
t + 2T
γ 1 Ke τ ⎜ e τ ⎟ Ke τ γ2
= t + 2T ⎜ ⎟= = (7.1)
γ2 −
τ
T
⎜ −τ
t + 3T
⎟ Ke − τ γ3
Ke ⎝e ⎠
La relación (7.1) se cumple para todo valor de K y de τ. Esta propiedad permite

obtener la atenuación exponencial escalonada del coeficiente de normalización a través de
una simple multiplicación, en cada paso, por un escalar menor que la unidad. Como cabe
esperar, este escalar está relacionado con la constante de tiempo τ de la exponencial. Esto
se ve rápidamente en la expresión (7.2):

t +T
− t +T t + 2T
γ 1 Ke τ − +
T
= = e τ τ
= e τ
(7.2)
γ2 −
t + 2T
τ
Ke
Finalmente, conociendo TB (que es del orden de los 10 ms, según se determinará en la

sección 7.4) y la constante de tiempo deseada, se obtiene la constante de atenuación.
Como se explicó cuando se introdujo la función de manejo de la excitación, cuando
una tecla es liberada, la nota pasa al estado de TECLA LIBERADA. Un algoritmo, que es
ejecutado periódicamente (con un período TB), analiza la tabla de teclas activas y atenúa
las constantes de normalización de las notas que se hallan en el mencionado estado.
Cuando el coeficiente de normalización de alguna nota adquiere un valor inferior a un
umbral (que se calcula como un cierto porcentaje del coeficiente de normalización
original) la nota pasa al estado de TECLA INACTIVA, liberándose la entrada de la tabla
de teclas activas que ésta ocupaba.
ii. Función de suavizado
Como se explicó en el punto anterior, la simulación se realiza por bloques, durante los
cuales la ejecución no puede ser interrumpida por ningún otro proceso o servicio de
interrupciones de hardware. Por esta característica, la señal simulada (antes de ser
convolucionada con la respuesta impulsiva de la tabla armónica) posee ciertos rasgos que
cambian en forma periódica, espaciados un tiempo TB. Uno de ellos es la atenuación
durante el apagado de las notas, explicado en el punto i. Otra causa de posibles
discontinuidades de salto es el resultado de sobrescribir una entrada antigua de la tabla de
teclas activas con un evento reciente. Esto produce una interrupción abrupta de la forma
de onda correspondiente a los parámetros de simulación de la nota original, para ser
reemplazada por la nueva forma de onda. Teniendo en cuenta que los accesos a la tabla de
teclas activas se realizan siempre entre sucesivas simulaciones de bloques completos de
muestras, estas discontinuidades de salto sólo pueden producirse cada intervalos de
tiempo múltiplos de TB.
El efecto de una discontinuidad relativamente abrupta se hace claramente perceptible
en el sonido final. De por sí, un escalón en la señal produce un sonido percusivo, ya que
introduce gran cantidad de armónicos. Pero el efecto se intensifica al convolucionar la
señal discontinua. Esto puede verse si consideramos a la señal simulada como una
superposición de una señal continua y de una función escalón. Al ser la convolución una
operación lineal, el resultado de la misma será la suma de dos señales: la primera asociada
a la componente continua de la señal simulada, y la segunda proporcional a la respuesta al
escalón de la tabla armónica. Esta última, siendo la integral de la respuesta al impulso, es
en general una señal cuyo espectro contiene un alto porcentaje de componente de ruido.
En efecto, los sonidos generados al convolucionar una señal discontinua están afectados
de algo similar a un ruido de ráfaga, del todo perceptible.
Para solucionar este problema, nos valemos del hecho de que las discontinuidades de
salto, independientemente de cual sea la causa que las origina, surgen siempre en forma
periódica. Se introduce aquí un procedimiento cuya función consiste en “suavizar” las
discontinuidades, y así eliminar el problema desde su raíz.
En el anexo B se arriba a una fórmula matemática, la denominada función de
suavizado, que permite tomar una curva con una discontinuidad de salto y transformarla
en una curva suave (continua y con primera derivada continua) que aproxima la forma de
la curva original. La nueva señal, así obtenida, difiere de la original sólo dentro de un
intervalo de tiempo de duración fija T, que es pequeña comparada con TB (TB / T ≈ 50).

La función de suavizado es llamada periódicamente, entre sucesivas simulaciones de

bloques completos de muestras, independientemente de si existe una discontinuidad de
salto o no. La aplicación de esta función mostró en las pruebas una importante
disminución del ruido de ráfaga en el sonido final.
7.2. Descripción de los procesos involucrados
Al principio de la sección (7.1) se expuso el diagrama de bloques de la aplicación target.

En la figura 7.1 se observa que, además de la tarea ociosa (idle), se ejecutan paralelamente
dos tareas principales: la tarea de comunicación y la tarea de simulación. Cada una de ellas
hace uso de las funciones de aplicación y accede a los diferentes bloques de datos. En el
marco de DSP/BIOS, se puede asignar a cada tarea (TSK) una prioridad, a través de la
herramienta de configuración [37]. Así, distintos procesos pueden ejecutarse
independientemente uno del otro, en lo que constituye un esquema de multitarea‡. Un proceso
determinado puede ser interrumpido en cualquier punto de su ejecución por otro proceso de
mayor prioridad. A su vez, cuando un proceso de prioridad alta se halla bloqueado (por
ejemplo, esperando que un dispositivo de hardware concluya una cierta tarea) pueden
continuar su ejecución los procesos de prioridad menor.
En nuestro caso es conveniente asignar una prioridad mayor a la tarea de simulación que a
la de comunicación. Esto garantiza que en la situación más desfavorable, es decir en aquella
en que la performance de tiempo real del sistema no alcance su nivel óptimo, no se interrumpa
nunca la generación de sonido. A su vez esto implica que en tal caso pudiera aumentar la
latencia en la transferencia de las señales de control y/o en el manejo de la excitación, lo cual
no se considera tan grave como un deterioro del sonido sintetizado.
A continuación se explican los procesos que intervienen en las dos tareas principales.
7.2.1. Tarea de comunicación
La figura 7.10 muestra el diagrama de flujo del algoritmo ejecutado por esta tarea.
‡
En rigor de verdad, nunca se ejecutan dos procesos simultáneamente, lo cual no sería factible a nivel de
hardware. La denominación multitarea se refiere a una ejecución alternada de los distintos procesos, que en una
escala de tiempo grande comparada con los tiempos de conmutación causa la ilusión de ser una ejecución
simultánea.

FIGURA 7.10. Diagrama de flujo de la tarea de comunicación
Al inicio la ejecución se mantiene en un bucle, esperando que la aplicación host habilite

los canales de comunicación RTDX. Una vez que los canales están listos, la tarea pasa a un
bucle continuo que tiene la función de despachar los mensajes que son recibidos desde el host
por el canal 1. Estos mensajes pueden ser de dos tipos, mensajes asociados a eventos de
control, o mensajes asociados a parámetros de simulación. Son de 40 bytes de longitud y son
diferenciados unos de otros por inspección de su código de identificación, incluido en su
encabezado de 2 bytes.
Como se explicó en la sección 6.2, cada transmisión de paquetes de datos empleando
RTDX tiene asociada una latencia fija, independiente de la longitud del paquete. Para
minimizar el número de transmisiones, los mensajes recibidos por el canal 1 son de un tamaño
suficiente para contener la tabla de eventos de control completa, tal como es enviada desde la
aplicación host. Así, cuando el mensaje recibido es del tipo de eventos de control (EC), en el
mismo ya se incluye toda la información necesaria para ejecutar el manejo de la excitación.
En el espacio de 40 bytes del campo de datos del mensaje cabe un total de 20 eventos de
control.
Cuando el mensaje está asociado a parámetros de simulación, éste tiene la función de
indicar a la aplicación target que se comenzará la transferencia por el canal 2, en forma
secuencial, de un bloque de datos con parámetros de simulación de algún tipo. De esta forma,

el mensaje transporta como único dato útil un número de 1 byte que especifica el tipo de
parámetros de simulación que serán transferidos: Parámetros de instrumento (PI), parámetros
de tabla armónica (TA) o una distribución de paneo (DP). En el caso de los PI y la DP, luego
de recibidos todos los datos, se comienza de forma automática un proceso de transformación
de parámetros. De esta forma los filtros IIR y martillos pasan a tener los coeficientes que
corresponden al nuevo instrumento virtual activo.
En el segundo caso, tanto el proceso de recepción de los bloques completos de datos como
la posterior transformación de parámetros pueden tardar un tiempo del orden de los segundos,
ya que éstos se realizan durante los períodos de inactividad de la tarea simulación, de mayor
prioridad. Se ha considerado, bajo esta circunstancia, que lo más apropiado es suspender la
ejecución de dicha tarea durante la transferencia de los PI, TA o DP y su transformación. Esto
se consigue por medio de la función TSK_setpri(), que permite a la tarea de comunicación
modificar su propia prioridad, y asignarle temporalmente un valor superior al de la tarea de
simulación. Con esta estrategia el tiempo de transferencia y transformación se reduce
considerablemente, a costa de una breve interrupción del sonido generado.
7.2.2. Tarea de simulación
La figura 7.11 muestra el diagrama de flujo de la tarea de simulación.
FIGURA 7.11. Diagrama de flujo de la tarea de simulación
Puede verse que esta tarea también consta de un algoritmo que se ejecuta en forma cíclica.
Aquí se llama sucesivamente a las funciones que intervienen en la producción del sonido, con
lo que el flujo del programa resulta mucho más simple que en los demás casos analizados.
Como se explicó en la sección 7.1.2, el proceso de comunicación con el códec emplea dos
buffers. La aplicación escribe en uno de los buffers las muestras de la señal final, a medida
que éstas son calculadas. Paralelamente, el códec lee en forma secuencial el contenido del
otro buffer, donde se aloja el último bloque completo de muestras de la señal a reproducir.
Una vez que el códec termina de procesar el contenido del buffer, éste es liberado y puesto a
disposición de la aplicación para ser sobreescrito con el siguiente bloque de muestras.
El bucle de la tarea de comunicación comienza haciendo un llamado a la función
SIO_reclaim(), cuyo propósito es obtener un puntero a un nuevo buffer vacío. Esta función

tiene una importante propiedad: La tarea que la invoca permanece bloqueada hasta que el
módulo SIO (conectado al códec) está en condiciones de proporcionarle un buffer vacío. Esta
propiedad permite que durante todo el tiempo en que la tarea de simulación se halla inactiva,
la tarea de comunicación, de menor prioridad, pueda ejecutarse. Si no se cumpliera esto,
simplemente no se iniciaría ningún proceso de transferencia de datos entre host y target.
Una vez obtenido un buffer vacío, la tarea inicia un proceso de simulación. Para esto
invoca a la función SimularIIR(). Esta obtiene un bloque completo de muestras (sin
convolucionar), las cuales produce nota a nota, para luego sumar las contribuciones parciales
de todas ellas. El verdadero trabajo es realizado por una segunda función, sim_cuerda(),
escrita en código assembler, que es a su vez llamada desde SimularIIR() una vez para cada
nota. Esta función se explicará en detalle en el punto 7.3. A continuación la tarea aplica la
función de suavizado a ambos canales (L y R) de la señal simulada.
La convolución de la señal simulada con la respuesta impulsiva de la tabla armónica se
define, en tiempo discreto, de la siguiente manera:
+∞
y (n ) = x ( n) ∗ h ( n) = ∑ x(k ) h(n − k )
k = −∞
(7.3)
Consideremos que la respuesta al impulso h(k) posee valores no nulos en un intervalo de

M muestras, siendo cero fuera del mismo. A su vez, sea N la cantidad de muestras que deben
ser generadas en cada bloque de muestras simuladas (para un único canal). Es fácil demostrar
que la suma de la expresión (7.3) contiene únicamente un número N+M de términos no nulos
(en general). La señal simulada que queremos convolucionar puede considerarse como no
nula a partir de un tiempo inicial indefinido, ya que los lapsos de actividad de las notas son en
general mucho mayores que el intervalo de tiempo que cubre cada bloque de muestras
simulado. De lo anterior se deduce que la obtención de N muestras nuevas requiere la
convolución de las M muestras de h(k) con las N+M últimas muestras de la señal simulada
x(k). Entonces, cada nuevo bloque de N muestras de y(k), requiere la obtención de sólo N
nuevas muestras de x(k), dado que las M restantes ya fueron simuladas en pasos anteriores.
Llegamos a la conclusión de que debemos conservar en memoria las últimas M muestras
del bloque simulado en el paso anterior. Por simplicidad, y por razones que se explicarán en el
punto 7.3, se ha adoptado en nuestro caso M = N. Es decir, la respuesta al impulso h(k) consta
de N muestras, mientras que el buffer de la señal simulada x(k) almacena, para cada canal, un
total de 2N muestras.
De esta forma, la estrategia de uso de memoria más eficiente consiste en escribir las
últimas N muestras simuladas de x(k), en forma alternada, en la primera o la segunda mitad
del buffer (ver figura 7.12). Para ello, se dispone de un par de punteros, uno para cada canal
de audio, los cuales se apuntan a la posición 0 o a la posición N en forma alternativa, en los
sucesivos pasos. La función SimularIIR() escribe entonces a partir de la dirección apuntada
por dichos punteros.
La función que obtiene la convolución, conv_tabla_arm(), está escrita en código
assembler y se explica en la sección 7.3.

FIGURA 7.12. Almacenamiento alternado de las muestras simuladas x(k)
Las muestras de la señal que se envían al códec son representadas como números enteros
de 16 bits con signo. De esta forma, los valores máximo y mínimo que pueden almacenarse
son: ymáx = 215 – 1 = 32767, ymín = – 215 = –32768. Un algoritmo simple recortará los valores
de la señal que se hallen fuera de este rango. Esto último se producirá en muy raras ocasiones,
pero no deja de ser posible. A diferencia de otros tipos de sintetizadores, como por ejemplo
los samplers explicados en el capítulo 1, aquí el nivel de la señal asociada a una nota no está
acotado. Bajo determinadas circunstancias, sucesivos impactos del martillo pueden aumentar
gradualmente la energía de vibración de la cuerda, pudiendo generar una excursión de
amplitud mayor a la que corresponde al máximo valor de velocity posible. Cuando esta
situación se produce, incluso una limitación (recorte) abrupta de la señal es preferible en
comparación con un overflow. Si se intentara representar un valor levemente superior a ymáx
como un entero con signo de 16 bits, el valor resultante correspondería a un número negativo.
Es fácil ver que una forma de onda así alterada presenta una distorsión mayor que la de una
simple limitación de amplitud. No obstante, la solución óptima consistiría en aplicar a la señal
algún tipo de compresión en tiempo real, lo cual queda planteado como una posible futura
extensión.
Las muestras finalmente se depositan en el buffer de salida de audio. Las muestras del
canal L deben colocarse intercaladas una a una con las del canal R, tal es la convención
impuesta en las especificaciones de todos los modos de operación de la interfaz digital de
audio del códec [35]. Por último se hace un llamado a la función SIO_issue(), que provee al
módulo SIO un puntero al buffer recientemente escrito. Ésta, a diferencia de SIO_reclaim(),
es no bloqueante, por lo que la tarea continúa con su ejecución. Por último, ya generado un
bloque completo de muestras, se invoca el algoritmo que gestiona la liberación de las teclas.
Cada cierto número de muestras simuladas se hace un llamado a la función IDL_run(), la
cual fuerza la ejecución de la tarea idle. Esto permite que las funciones RTDX del sistema se
lleven a cabo fluidamente.
7.3. Optimización del código crítico
Las secciones computacionalmente más críticas corresponden a las funciones que calculan
la sección de filtros IIR y martillos, y la convolución. Ambas funciones han sido escritas en
código assembler (simular.asm y conv_tabla_arm.asm respectivamente), de manera de aplicar
una optimización manual a nivel de máquina. Claro está, una optimización manual es en
general más eficiente que cualquier función de optimización automática implementada por
CCS. Para esto se siguen diferentes estrategias, siendo la más significativa la denominada
optimización por Software Pipelining, explicada a continuación.

7.3.1. Método de optimización por Software Pipelining
El pipelining (canalización) es una característica clave en un DSP para obtener un

funcionamiento apropiado de las instrucciones ejecutadas en paralelo. El pipeline de la familia
C67x provee flexibilidad para simplificar la programación y mejorar la performance. Las
características principales son (ver [45] para información detallada):
▫ El pipeline puede despachar ocho instrucciones en paralelo por cada ciclo de

ejecución§
▫ Las instrucciones en paralelo se procesan simultáneamente en cada fase de pipeline
▫ Las instrucciones en serie se suceden a través del pipeline con una diferencia de fase
relativa fija entre instrucciones
▫ Las direcciones de lectura y escritura son gestionadas de manera de evitar conflictos
de acceso a memoria
Las fases de pipeline se dividen en tres etapas: carga (fetch), decodificación (decode) y
ejecución (execute). Todas las instrucciones en el C67x deben pasar por las mencionadas
etapas. La etapa de fetch tiene cuatro fases de un ciclo de reloj cada una, y la de decode dos,
en todos los casos independientemente de cual sea la instrucción procesada. Mientras tanto, la
etapa de execute requiere un número variable de fases, dependiendo del tipo de instrucción.
Un paquete de ejecución (execute packet) es un grupo de instrucciones que pueden ser
ejecutadas en paralelo en el mismo ciclo. Un paquete de carga (fetch packet) es un conjunto
de paquetes de ejecución, que pueden ser como máximo ocho paquetes de una instrucción
cada uno, y como mínimo un único paquete de ocho instrucciones.
Las fases de fetch son las siguientes:
PG Generación de dirección de programa

PS Envío de dirección de programa
PW Espera de acceso a datos
PR Recepción del paquete de carga
Las fases de decode son:
DP Despacho de la instrucción hacia la unidad funcional correspondiente

DC Decodificación propiamente dicha de la instrucción
La etapa de execute consta de diez fases (E1 a E10) para instrucciones de punto flotante y
de cinco fases (E1 a E5) para instrucciones de punto fijo. Diferentes tipos de instrucciones
requieren un número diferente de estas fases para completar su ejecución.
La figura 7.13 muestra un ejemplo del flujo de paquetes de carga consecutivos con ocho
instrucciones en paralelo cada uno. Como puede verse, la forma en que fluyen los paquetes de
ejecución a través del pipeline del DSP influye profundamente en los tiempos de
procesamiento del código de la aplicación.
§
En este procesador particular, un ciclo de ejecución equivale a un ciclo de reloj.

FIGURA 7.13. (a) – Fases del pipeline en punto flotante; (b) – Flujo de la
ejecución del pipeline en punto flotante – (fuente [45])
El método de software pipelining (canalización de software) permite sincronizar

eficientemente las instrucciones de un bucle de código, de forma que múltiples iteraciones del
mismo se ejecuten en paralelo. Los recursos de procesamiento en paralelo hacen posible
iniciar una nueva iteración, antes de que terminen de ejecutarse iteraciones previas del bucle.
El método apunta a usar el total de ocho unidades funcionales** en cada ciclo de
ejecución, obteniendo así el máximo rendimiento del procesador. Cada instrucción posee, en
general, un retardo de ejecución diferente (variando entre 0 y 5 ciclos). Una completa
planificación de los tiempos en que se inician las instrucciones permite minimizar el tiempo
ocioso de cada una de las unidades funcionales del DSP. El código obtenido luego de aplicar
el método, consta de tres partes: prólogo, núcleo y epílogo.
Durante el prólogo, no se usa el total de las unidades funcionales. En cada ciclo sucesivo
se añaden instrucciones en paralelo. En el momento en que se tiene el máximo rendimiento
del procesador (máximo número de unidades funcionales ocupadas por ciclo) comienza el
núcleo del código. Aquí se ejecuta en forma cíclica el mismo conjunto de instrucciones, ahora
ya completamente sincronizadas. Normalmente esta sección debería ser la más extensa del
código, para así lograr una optimización mayor. Finalmente, en el epílogo se completa la
ejecución de las últimas iteraciones del bucle, que fueron iniciadas en el núcleo. Lógicamente,
durante esta etapa el número de instrucciones ejecutadas en paralelo disminuye
progresivamente, hasta el final del código.
Es importante notar que toda sección de código optimizada por software pipelining debe
ejecutarse siempre con todas las interrupciones del sistema deshabilitadas. De otra forma, un
proceso de mayor prioridad, de aplicación o de sistema, podría interrumpir la ejecución. Esto
ocasionaría la pérdida de sincronización entre las distintas instrucciones de forma irreversible.
En la documentación incluida en CCS se introduce un método gráfico que permite llevar a
cabo la optimización de software pipelining en forma manual. El método se divide en dos
partes: elaboración de un gráfico de dependencia, y sincronización (o programación) de las
**
Las unidades funcionales del procesador se explican en la sección 5.1.2

instrucciones. En los puntos siguientes se mostrará la aplicación de este método a nuestro caso
particular. En [32] y [44] se presenta el tema con mayor profundidad.
7.3.2. Optimización de la función simular.asm
Como se explicó en la sección 3.3 el código que calcula la evolución de los filtros IIR y
los martillos debe diferenciarse en ciclos pares e impares. Esto es así porque los valores de la
variable w(k) son almacenados en forma alternada en memoria.
Para cada paso, par o impar, se debe evaluar la misma expresión algebraica (3.12) que
aquí repetimos para mayor claridad.
w(k) = fe2(k – 1) b1 + w(k – 2) c0 + w(k – 1) c1 (3.12)
Las principales instrucciones que se usarán son las siguientes:
LDDW (Load double-word) Lee 64 bits consecutivos de memoria, y los

almacena en dos registros de 32 bits. Ciclos de
retardo: 5
MPYSP (Multiply single precision) Multiplica dos números de punto flotante de
precisión simple (32 bits). Ciclos de retardo: 4
ADDSP (Add single precision) Suma dos números de punto flotante de precisión
simple (32 bits). Ciclos de retardo: 4
STW (Store word) Escribe en memoria un número de punto flotante
de precisión simple (32 bits). Ciclos de retardo: 1
SUB (Subtraction) Decrementa el valor de un registro en un número
entero de unidades. Ciclos de retardo: 1
B (Branch) Operación de salto. Ciclos de retardo: 6
Cuando cualquier instrucción aparece en el código precedida de “[nombre-registro]” esto

significa que la misma debe ejecutarse en forma condicional, evaluando el contenido del
registro entre corchetes como una variable booleana.
− Optimización por software pipelining
Las figuras 7.14 y 7.15 muestran los gráficos de dependencia para los pasos par e
impar respectivamente. Junto a los círculos se coloca el nombre de una instrucción,
acompañada del nombre de la unidad funcional que la ejecuta, y un número (encuadrado)
que designa el ciclo en que es iniciada la instrucción.
En el interior de los círculos se coloca el identificador de los registros de destino de la
instrucción correspondiente. A su vez, los registros de fuente (o condicionales) de la
instrucción son aquellos de los cuales provienen las flechas que llegan al círculo. En
algunos casos, el registro de destino de una instrucción coincide con el registro de fuente,
como en el caso de la instrucción SUB que decrementa en cada paso el contador del bucle.
En el caso de las instrucciones de escritura (STW), los identificadores designan
direcciones de memoria y no registros del procesador.
Junto a las flechas se indica el número de ciclos de retardo correspondientes a la
instrucción que obtiene el dato de fuente asociado a la misma. De esta forma, el número
de ciclos que transcurren entre la instrucción de la que parte la flecha y aquella adonde
ésta termina, debe ser mayor o igual que el retardo de la instrucción que origina el dato.

FIGURA 7.14. Gráfico de dependencia del paso de integración PAR
Para poder determinar en qué ciclo y bajo qué unidad funcional se ejecuta cada
instrucción, se recurre a la denominada tabla de programación (schedule). Recordemos
que cada unidad funcional puede ejecutar una única instrucción en cada ciclo. La tabla de
programación permite asignar rápidamente los recursos sin generar conflictos temporales
ni espaciales. Las figuras 7.16 y 7.17 muestran las tablas de programación para los pasos
de integración par e impar. Las columnas de las tablas corresponden a ciclos de ejecución,
y las filas están asociadas a las ocho unidades funcionales (.D1, .D2, .M1, .M2, .L1, .L2,
.S1, .S2). Dos filas adicionales permiten designar los cross paths (.1X, .2X), que siempre
son asignados conjuntamente con alguna de las ocho unidades funcionales.

FIGURA 7.15. Gráfico de dependencia del paso de integración IMPAR
En nuestro caso, cada iteración del núcleo del código consta de tres ciclos de
ejecución. Para este caso corresponden tres tablas de programación. La primera con los
ciclos (0,3,6,...) , la segunda con los ciclos (1,4,7,...) y la tercera con los ciclos (2,5,8,...).
Dado que cada tres ciclos de ejecución se inicia una nueva iteración del bucle, una vez
colocada por vez primera una instrucción particular, la misma se vuelve a colocar cada
tres ciclos hasta que es ejecutada un número de veces igual a la cantidad total de
iteraciones del bucle. Finalmente, los tres ciclos que se repiten en el núcleo son el 25, 26 y
27. El epílogo no se muestra en la tabla, ya que su estructura es el complemento exacto del
prólogo, de manera que todas las instrucciones se ejecuten el mismo número de veces en
total.
En el anexo C se muestra el código assembler completo, ya optimizado. Las
operaciones asociadas al martillo se ejecutan al final de cada paso de integración, par o
impar. Se aprovechan las unidades funcionales ociosas durante el epílogo, para mayor
eficiencia. Por esto algunos ciclos aparecen divididos en instrucciones asociadas a filtros e
instrucciones asociadas a martillos, aunque se ejecuten en forma paralela.

U 0 3 6 9 12 15 18 21 24 27
.D1 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW
.M1 MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP
.M2
.L1 ADDSP ADDSP ADDSP ADDSP ADDSP
.L2
.S1 SUB
.S2
1X
2X
U 1 4 7 10 13 16 19 22 25
.D1 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW
.D2
.M1 MPYSP MPYSP MPYSP
.L1 ADDSP
.L2 ADDSP
.S1 B B
.S2
1X MPYSP MPYSP MPYSP
U 2 5 8 11 14 17 20 23 26
.D1 STW STW STW
.D2 LDDW LDDW LDDW LDDW LDDW
.M1 MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP
.L1 ADDSP ADDSP ADDSP ADDSP ADDSP ADDSP
.L2
.S1
.S2
1X ADDSP ADDSP ADDSP ADDSP ADDSP ADDSP
2X
FIGURA 7.16. Tabla de programación para el paso de integración PAR
U 0 3 6 9 12 15 18 21 24 27
.M2
.L1 ADDSP ADDSP ADDSP ADDSP ADDSP
.L2
.S1 SUB
.S2
1X MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP
2X
U 1 4 7 10 13 16 19 22 25
.D1 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW
.D2
.L1 ADDSP
.L2 ADDSP
.S1 B B
.S2
U 2 5 8 11 14 17 20 23 26
.D1 STW STW STW
.D2 LDDW LDDW LDDW LDDW LDDW
.M1 MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP
.L1 ADDSP ADDSP ADDSP ADDSP ADDSP ADDSP
.L2
.S1
.S2
1X ADDSP ADDSP ADDSP ADDSP ADDSP ADDSP
2X MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP MPYSP
FIGURA 7.17. Tabla de programación para el paso de integración IMPAR

− Optimización del uso de la memoria caché
El código ya optimizado requiere accesos a memoria interna L2 una vez por cada ciclo
de ejecución. La única sección de memoria que admite tal frecuencia de acceso es la L1
(ver sección 4.1). En ella se dispone de 4 kbyte para datos y 4 kbyte para código. Cada vez
que el programa intenta acceder a una dirección de memoria interna L2, primero verifica
si el dato no se halla ya almacenado en caché L1. Si el dato está presente, lo lee de allí con
una velocidad de acceso alta. Si el dato no está presente, copia el segmento completo de
memoria L2 que contiene dicho dato, y lo almacena en la caché L1, lo cual requiere un
tiempo mayor a un ciclo de ejecución. Concluimos entonces que para lograr que cada paso
del código optimizado se procese en un único ciclo de ejecución, todos los valores que
deben ser leídos de memoria deben estar alojados en memoria L1 [33].
Debemos simular P cuerdas, de 80 armónicos cada una, y corresponden a cada una un
total de M muestras por bloque simulado (para cada canal). El método de software
pipelining produce buenos resultados cuando se aplica a bucles con un gran número de
iteraciones. En nuestro caso, se presentan dos posibilidades (ver figura 7.18):
(a) simular cuerda por cuerda, obteniendo una única muestra cada vez
(ejecución en sentido vertical)
(b) simular las M muestras, pero primero para los armónicos de una cuerda,
luego de otra y así sucesivamente (ejecución en sentido horizontal).
FIGURA 7.18. Ejecución en sentido horizontal

(por muestras) vs. vertical (por cuerdas)
La ejecución en sentido vertical puede resultar atractiva, ya que es posible condensar todo
el código en un único bucle de P × 80 iteraciones (una por cada filtro IIR) con el agregado de
una lógica sencilla que permita calcular las sumas parciales que dan la posición de cada
cuerda. Un bucle de mayor número de iteraciones se traduce en una mayor eficacia de la
optimización de software pipelining, al disminuir el tamaño del prólogo y epílogo en
comparación con el núcleo. No obstante, una ejecución en sentido vertical implicaría
almacenar en memoria caché L1 el total de los coeficientes de los P × 80 filtros y P martillos,
lo cual es irrealizable ya que exceden ampliamente su capacidad. Así, al simular sucesivas
cuerdas, debería actualizarse permanentemente el contenido de la caché, degradando la
performance considerablemente.
Mientras tanto, una ejecución en sentido horizontal requiere el almacenamiento de los
coeficientes y variables de 80 filtros IIR más los de un único martillo, que no exceden la
capacidad de 4 kbyte de la caché L1. Como contraparte, si queremos lograr niveles aceptables

de optimización, el número de muestras por bloque simulado, M, debe ser lo mayor posible.
Por otra parte, si M aumenta, también aumenta el tiempo de procesamiento por cada paquete
y, con él, el tiempo durante el cual los demás procesos deben esperar. Esto ocasiona una
mayor latencia media en la transmisión de eventos de control por dos motivos: por una parte,
el tiempo que debe esperar la tarea de comunicación aumenta; por otra parte, la performance
de la biblioteca RTDX decae significativamente. En las especificaciones de la biblioteca se
advierte que la deshabilitación de las interrupciones de hardware durante un número de ciclos
mayor a un valor crítico (del orden de los 1000) produce un rápido aumento de la latencia
media de las funciones RTDX.
Se realizaron pruebas a fin de determinar el valor óptimo para M, y se concluyó que un
número de unas 500 muestras era el más apropiado. Para que el uso de la memoria caché
fuera óptimo, se adoptó finalmente M = 512 muestras por cada canal stereo. Además, las
interrupciones de hardware se deshabilitan y rehabilitan para cada una de las cuerdas
simuladas.
7.3.3. Optimización de la función conv_tabla_arm.asm
En este caso se aplicó el mismo método que en el caso anterior, con la salvedad de
algunas consideraciones adicionales. El código final se muestra en el anexo C.
− Optimización por software pipelining
La figura 7.19 muestra el gráfico de dependencia del código de la función de

convolución, mientras que la figura 7.21 muestra la tabla de programación asociada.
Como se puede ver, en este caso el bucle del núcleo consta de un único ciclo de ejecución,
en el cual se usan las ocho unidades funcionales.
FIGURA 7.19. Gráfico de dependencia de la función de convolución

U 0 1 2 3 4 5 6 7 8 9
.M1 MPYSP MPYSP MPYSP MPYSP MPYSP
.M2 MPYSP MPYSP MPYSP MPYSP MPYSP
.L1 ADDSP
.L2 ADDSP
.S1 SUB
.S2 B B B B B B
1X MPYSP MPYSP MPYSP MPYSP MPYSP
2X MPYSP MPYSP MPYSP MPYSP MPYSP
FIGURA 7.20. Tabla de programación para la función de convolución
− Consideraciones del uso de memoria
Como se explicó en la sección 7.2, la convolución se obtiene a partir de las últimas

2M muestras simuladas, siendo M el número de muestras de cada bloque. La función
conv_tabla_arm() devuelve en cada llamado una única muestra de la señal
convolucionada, y por lo tanto debe ser llamada un total de M veces. El proceso consiste
simplemente en calcular una suma de productos, leyendo pares de valores de 32 bits de
memoria, sirviéndose para ello de un par de punteros que se van incrementando.
A pesar de ser un algoritmo muy sencillo, resta aun implementar de alguna forma una
lógica de control que permita al código detectar el momento en que el puntero excede la
dirección más alta (2M – 1) contenida en el buffer de muestras. En este momento, el
puntero debe direccionarse hacia el comienzo del buffer (dirección 0), para continuar
normalmente con el cálculo. Si quisiéramos implementar esta lógica de control con
instrucciones del código, deberíamos forzosamente emplear un ciclo más de ejecución
para cada iteración del bucle (dado que todas las unidades funcionales están ocupadas).
Felizmente, el DSP C6713 posee un modo de direccionamiento alternativo denominado
circular, que implementa esta funcionalidad en forma automática.
La configuración de este modo se realiza a través del registro de control AMR
(Addressing Mode Register) [46]. En el mismo se especifica el tamaño del buffer circular
(cuya dirección de comienzo deberá estar alineada en un número de bytes igual a su
longitud), como así también cuál de los registros del procesador se usará como puntero.
En nuestro caso, el tamaño del buffer es 2 × 512 × 4 = 4096 bytes.
Como última observación, las muestras de la respuesta al impulso de la tabla armónica
se almacenan en memoria en orden temporal inverso, para simplificar el proceso que se
reduce de esta manera a un simple producto punto de vectores.
7.4. Análisis de performance
Hemos definido en la sección 3.3 al rendimiento del código ξ como el porcentaje

promedio de las unidades funcionales que son utilizadas. De esta forma, suponiendo que la
longitud del núcleo de los códigos optimizados es mucho mayor que las de el epílogo y
prólogo, tenemos para la función simular() un rendimiento de:
ξ = 100% × (6 + 5 + 5) / 24 = 67%
En tanto que para la función conv_tabla_arm() tenemos un rendimiento de ξ = 100%.

Para el rendimiento de la primera función, de acuerdo con las estimaciones hechas en la
sección 3.3, obtendríamos como valor máximo posible una polifonía:
P = ξ Pmáx = 17 notas

Claro está, el valor real será siempre menor, ya que para el cálculo no se considera el
rendimiento de los demás procesos que intervienen en la tarea de simulación††.
A fin de determinar la polifonía real, se ensayó la simulación para distinto número de
cuerdas simultáneas, midiendo el porcentaje de recursos de procesador utilizados. Se obtuvo
la gráfica de la figura 7.21.
FIGURA 7.21. Uso de recursos de CPU vs. polifonía
Como se puede ver, el mayor valor de polifonía que arroja un consumo inferior al 80%
corresponde a P = 12 notas. Una característica llamativa de la curva es su forma escalonada,
produciéndose incrementos mayores del consumo de recursos por cada dos notas adicionadas
a la polifonía.
El período de tiempo transcurrido entre bloques completos de muestras simuladas puede
calcularse como TB = M / FS , donde M es el número de pares de muestras stereo (frames) por
bloque y FS es la frecuencia de muestreo. De acuerdo con los valores determinados en las
secciones previas, tenemos TB = 512 / 44100 Hz = 11,6×10-3 s.
En la sección 4.1 se introdujo brevemente el sistema de comunicación entre host y target,
basado en el protocolo de comunicación JTAG. Como se explicó, el procesador C6713
implementa dicho protocolo por emulación, lo que significa que cierta cantidad de recursos
del CPU deben emplearse para ello. El fabricante no da casi ningún dato al respecto de la
performance de RTDX, basada en JTAG, pero menciona ocasionalmente en la documentación
que la misma es afectada por la manera en que se ejecutan los diferentes procesos de la
aplicación target. Uno de los factores, ya expuesto, es el tiempo durante el cual se
deshabilitan las interrupciones de hardware (HWI). Esto tiene que ver con el hecho de que la
biblioteca RTDX del target (sección 5.4) está implementada a partir de procesos basados en
interrupciones.
Otra causa de disminución de la performance en el proceso de comunicación es el sistema
operativo bajo el cual se ejecuta la aplicación host. El sistema Windows XP no está
específicamente orientado a aplicaciones de tiempo real. Un conjunto de procesos de sistema
se ejecutan permanentemente en forma paralela, atendiendo funciones de red, manejo de
dispositivos de hardware y aplicaciones de usuario. Por esto es probable que el sistema deje
de atender temporalmente a la aplicación host, ante el pedido de atención de un proceso
externo de mayor prioridad. Estas situaciones, si bien son poco frecuentes, pueden producir
aumentos muy significativos de la latencia.
En un piano real, el tiempo transcurrido entre la pulsación de la tecla y el contacto
posterior del martillo con la cuerda es como máximo de entre 10 y 20 ms [12]. A su vez, en
††
Este valor es el límite teórico, y correspondería al caso ideal en que el 80% del código procesado de la
aplicación estuviera optimizado con un rendimiento del 67%

una interpretación rápida, las notas pueden tener una duración del orden de los 100 ms o
menos. Si el retardo entre la generación de las señales de control y la producción de los
sonidos correspondientes es del mismo orden que la duración de la notas, se pierde la
interactividad por parte del usuario, dificultando la interpretación musical.
En las pruebas, para una polifonía de 12 notas, se comprobó que las transferencias de
datos de control desde el host hacia el target presentaban una latencia media del orden de los
500 ms. De las anteriores consideraciones concluimos que este valor es totalmente
inadmisible para la aplicación. Además se observó que la latencia presentaba variaciones
considerables respecto de su valor medio, entre sucesivas transmisiones. Finalmente, fue
necesario reducir la polifonía a 8 notas, obteniendo una latencia media del orden de los 125
ms, valor que consideramos aceptable.
En la sección 8.1.2 se describe el proceso de análisis estadístico empleado para la
determinación de la latencia media, y además se propone un sistema alternativo de
comunicación, más eficaz, que no está basado en RTDX.

8. Consideraciones Finales
En este capítulo se hace un análisis general de los resultados obtenidos, y se proponen

posibles extensiones del proyecto. Por último se exponen las conclusiones finales.
8.1. Análisis de los resultados
En esta sección observaremos primero las características de los sonidos sintetizados, tanto
en el dominio temporal como en el frecuencial, y luego determinaremos la latencia media
entre la generación de los mensajes MIDI de control y la producción del sonido final.
8.1.1. Señal sintetizada
Las figuras 8.1, 8.2 y 8.3 muestran las formas de onda sintetizadas para el caso de tres
instrumentos virtuales diferentes (ejemplos 1 al 3). En todos los casos se está simulando una
única nota. En cada ejemplo se muestran dos gráficas superpuestas: la señal antes de ser
convolucionada (en color negro), y la señal final, luego de la convolución (en color gris).
Todos los ejemplos se anexan además en archivos de audio en formato Microsoft WAVE
soundfile (.wav), para poder así contrastar las diferencias entre las distintas señales en forma
auditiva.
FIGURA 8.1. Ejemplo 1 – Nota E2 – Formas de onda antes (curva negra)

y después de la convolución (curva gris)
FIGURA 8.2. Ejemplo 2 – Nota C2 – Formas de onda antes (curva negra)


FIGURA 8.3. Ejemplo 3 – Nota G#2 – Formas de onda antes (curva negra)
La señal del ejemplo 2 presenta un alto grado de periodicidad, repitiéndose esto, aunque
en menor grado, para la señal del ejemplo 1. En cambio, la señal del ejemplo 3 es claramente
inarmónica (aperiódica). Esto se debe a que las cuerdas de los ejemplos 1 y 2 poseen una
rigidez mucho menor que la del ejemplo 3, es decir, las ondas se propagan en ellas con menor
dispersión.
En las figuras 8.4 a 8.6 se muestran las densidades espectrales de energía de las señales de
los ejemplos 1 a 3 respectivamente. Éstas se obtuvieron, en todos los casos, a través de una
transformada rápida de Fourier (FFT) de 4096 puntos. Las dos primeras gráficas de cada
figura corresponden a las señales antes y después de la convolución, para un total de 80
armónicos. La tercera gráfica corresponde a la señal convolucionada, pero considerando en
total 200 armónicos.
Se observan diferencias importantes en el ancho de banda de las diferentes señales. En el
ejemplo 1, la frecuencia fundamental, correspondiente a la nota E2, es f0 = 82,41 Hz. De ser la
señal perfectamente armónica, su componente espectral más alta debería ubicarse en
fmáx = f0 × 80 = 6,59 kHz. Dada la inarmonicidad de la señal, vemos que en realidad su
espectro se extiende hasta superar los 10 kHz. Al considerar 200 armónicos, surge una serie
de picos en frecuencias más altas, pero la rápida disminución de sus amplitudes con la
frecuencia hace que las diferencias respecto del sonido original sean relativamente
inapreciables en forma auditiva.
En el ejemplo 2, la frecuencia fundamental corresponde a la nota C2 y es f0 = 65,41 Hz. La
componente de mayor frecuencia, en el caso de armonicidad pura, se ubicaría en
fmáx = f0 × 80 = 5,23 kHz. Como muestra la figura 8.5, en este caso el ancho de banda real se
aproxima más al de una señal perfectamente armónica, extendiéndose hasta cerca de los 6,5
kHz. Esto guarda relación con la acentuada periodicidad de la señal en el dominio temporal.
Al considerar 200 armónicos, el ancho de banda real se expande en forma considerable. En
este caso, la adición de componentes espectrales en la región de altas frecuencias, es
claramente apreciable en forma auditiva.
Por último, las señales del ejemplo 3 poseen componentes espectrales distribuidas en todo
el rango audible. La separación entre éstas aumenta visiblemente con la frecuencia, lo cual
denota una profunda inarmonicidad. Siendo la nota un G#2, tenemos una frecuencia
fundamental f0 = 103,83 Hz. La frecuencia máxima correspondiente al caso armónico puro,
sería entonces fmáx = f0 × 80 = 8,31 kHz, muy inferior al valor real. En el caso de 200
armónicos, aunque los picos principales se mantienen en sus posiciones originales, se observa
un aumento general de la densidad espectral de energía en las posiciones intermedias.
De lo anterior podemos concluir que el ancho de banda de cada nota sintetizada está
limitado como mínimo al valor ABmín = f0 × (N – 1) (siendo N el número de componentes

espectrales considerado), correspondiente al caso armónico puro, y como máximo al rango

audible completo, en el caso más general. Normalmente un valor de N = 80 arrojará
resultados satisfactorios sólo para señales relativamente aperiódicas, como en los ejemplos 1 y
3. Nótese que esta limitación se hace más apreciable en una nota grave que en una aguda, ya
que su ancho de banda comienza en frecuencias más bajas, y sus componentes espectrales
están más distanciadas* entre sí.
Ejemplo 1 - Nota E2 - Señal sin convolucionar (80 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
Ejemplo 1 - Nota E2 - Tabla armónica 1 (80 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
FIGURA 8.4. Ejemplo 1 – Análisis espectral –

Resolución de la FFT: N = 4096 puntos
*
Se entiende aquí por distancia a la diferencia entre los valores centrales de frecuencia de cada componente
espectral.

Ejemplo 2 - Nota C2 - Señal sin convolucionar (80 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
Ejemplo 2 - Nota C2 - Tabla armónica 1 (80 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
Ejemplo 2 - Nota C2 - Tabla armónica 1 (200 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]


Ejemplo 3 - Nota G#2 - Señal sin convolucionar (80 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
Ejemplo 3 - Nota G#2 - Tabla armónica 1 (80 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
Ejemplo 3 - Nota G#2 - Tabla armónica 1 (200 armónicos)
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]


En la figura 8.7 se muestran los análisis espectrales correspondientes a una misma cuerda,
pero aplicando la convolución con las respuestas impulsivas de tres tablas armónicas
diferentes. La distribución espectral original de la energía se ve modificada como resultado
del filtrado asociado a cada tabla armónica. Podemos observar que en los distintos casos el
ancho de banda permanece relativamente invariable. Las tres señales mostradas se anexan
como archivos de audio en formato .wav, junto con los demás ejemplos.
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]
-20
-40
FFT [dB]
-60
-80
-100
-120
-140
0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]


8.1.2. Latencia de los eventos de control
Debemos realizar ahora un análisis estadístico de la latencia entre la transmisión de los

mensajes MIDI de control y la producción final de los sonidos correspondientes. Para el
experimento nos valemos del sintetizador integrado al teclado MIDI empleado. Se ingresan a
la PC dos señales de audio diferentes, una en cada canal stereo, a través de la entrada de línea
de la tarjeta de sonido. La primera señal ingresada es uno de los canales stereo de la salida del
sintetizador a ensayar, y la segunda es uno de los canales stereo de la salida de audio del
teclado MIDI. Paralelamente, la salida MIDI de este último brinda a la aplicación host la
información de control requerida por el sintetizador ensayado.
Luego se obtiene una grabación digital de ambos canales de la entrada de línea,
empleando un software de edición de audio genérico. Sobre el archivo de audio así obtenido,
es posible determinar el tiempo transcurrido entre el comienzo de notas análogas de ambos
sintetizadores, con precisión relativamente alta†.
Sobre un total de 63 mediciones, se obtuvo el histograma de frecuencias de la figura 8.8.
El archivo de audio empleado se anexa junto con los de los demás ejemplos.
12
10
8
Frecuencia
0
0 30 60 90 120 150 180 210 240 270
Latencia [m s]
FIGURA 8.8. Análisis de la latencia – Histograma de frecuencias
La latencia media medida es de 125,63 ms, siendo su desvío estándar de 43,46 ms. Se
presentó además un caso aislado, no graficado en la figura 8.8, en que se midió una latencia
de 740 ms. Este retardo, considerablemente mayor que el promedio, se debe probablemente a
una falta de atención por parte del sistema operativo a los procesos de la biblioteca RTDX, al
atender temporalmente procesos externos de mayor prioridad.
8.2. Conclusiones
Finalmente, aquí se exponen las observaciones más importantes sobre el proyecto, en

forma general, a modo de conclusión final.
8.2.1. Consideraciones sobre los resultados obtenidos
En la sección 8.1.1 se consideraron las características del sonido sintetizado. Del análisis
del ancho de banda de las distintas señales concluimos que, en general, no basta considerar un
†
Suponemos aquí que las dos señales generadas por el teclado (la de audio y la MIDI) son transmitidas en forma
simultánea, o con un retardo despreciable comparado con la latencia a determinar

total de 80 componentes espectrales para cubrir el rango audible de frecuencias. A su vez, de

acuerdo con lo expuesto en la sección 4.2, el número de muestras de la respuesta impulsiva
consideradas para la convolución, no permite caracterizar completamente el modelo de la
tabla armónica. Además, como se mencionó en la sección 3.4, la descomposición
estereofónica del sonido ha sido descripta de manera simplificada, lo cual limita la capacidad
del sintetizador para reproducir una imagen acústica definida.
En cuanto al tiempo de respuesta, analizado en la sección 8.1.2, consideramos que la
latencia en la producción del sonido es en promedio excesivamente alta para la aplicación. La
elevada desviación media de los valores de latencia deteriora aún más la interactividad,
reduciendo el grado de control sobre la producción musical por parte del intérprete.
Cabe también destacar que la polifonía lograda es muy baja, comparada con la de otros
tipos de sintetizadores, que pueden alcanzar las 64 notas simultáneas.
El modelo físico implementado está descripto de forma muy simplificada, excluyéndose
un conjunto importante de fenómenos que son apreciables en forma auditiva. No obstante, la
gama de sonidos diferentes que se pueden sintetizar es relativamente amplia.
8.2.2. Posibles extensiones del proyecto
Como se explicó el capítulo 4, el sistema implementado es un prototipo, cuyo diseño

contempla la posibilidad de realizar un conjunto de modificaciones sin cambios esenciales en
sus estructuras de hardware y software. En una versión definitiva, las cuatro partes en que ha
sido dividido el sistema podrían integrarse en un único equipo electrónico dedicado (pudiendo
excluirse, opcionalmente, el amplificador y reproductor, como es usual en muchos
sintetizadores).
También sería interesante desarrollar una placa que permita introducir al DSK la
información de control en forma directa, empleando una interfaz MIDI. Para ello sería
apropiado valerse del conector de expansión de periféricos, incorporado en el DSK. Luego
bastaría implementar el protocolo de comunicación MIDI, por software o hardware, logrando
compatibilidad con dispositivos de control MIDI en general. Una gran ventaja de esto es la
posibilidad de prescindir de la plataforma RTDX para el ingreso de los parámetros de control.
En este caso, la aplicación target tendría un acceso casi directo a dicha información, lo cual
demandaría un consumo mucho menor de recursos de procesamiento que la biblioteca RTDX,
y a su vez reduciría notablemente la latencia de las transmisiones.
Bajo este nuevo enfoque, la aplicación host podría considerarse como un complemento del
sintetizador, cuya función sería sólo proveer herramientas para la generación y edición de
instrumentos virtuales completamente caracterizados. Existe un conjunto de posibles
extensiones para la funcionalidad de la aplicación host, que son enumeradas a continuación:
▫ La función de normalización podría incluir un ajuste fino por parte del usuario, basado
en la percepción de la preescucha, a fin de igualar los niveles de sonoridad de las
distintas notas. También esto podría ser realizado automáticamente por la aplicación,
considerando las curvas de igual nivel de sonoridad y otros elementos psicoacústicos
[39]. Otra extensión posible es la normalización en todo el rango dinámico, a partir de
dos o más valores de velocity de referencia para cada nota, y teniendo en cuenta las
curvas de correspondencia entre velocidad del martillo y velocity del dispositivo
MIDI. Esto demandaría un procesamiento previo mayor, pero proveería un mayor
control sobre la expresividad del instrumento.
▫ Los parámetros físicos correspondientes a notas entre puntos de configuración,
podrían ser determinados por interpolación cuadrática o cúbica (spline), dando una
transición más gradual de los sonidos entre notas sucesivas del registro.

▫ Sería interesante permitir al usuario especificar escalas musicales completas, cuya

afinación se lograría a través de una adaptación de la función de autofrecuencia.
▫ Los archivos de parámetros de instrumento (.pi) podrían ser archivos de texto, con lo
cual sería posible su edición en forma manual, empleando un editor de texto.
Es posible aplicar distintos tipos de procesamiento digital a la señal simulada, para así
obtener un resultado de mayor calidad acústica. En la sección 7.2.2 se explicó la necesidad de
limitar la amplitud de la señal. Esta operación podría generalizarse en un proceso de
compresión de audio, de parámetros configurables por el usuario. También sería posible
aumentar la riqueza espectral de las señales por procesado no lineal, por ejemplo, a través del
uso de resaltadores [39].
Finalmente, el modelo físico podría extenderse para así contemplar efectos no lineales
(modulación de frecuencia), distintos modos de propagación, distintos mecanismos de
excitación, interacciones complejas entre las cuerdas (simpatía, doble caída), descripción más
completa de la tabla armónica y de la distribución de paneo. Como se explicó en capítulos
anteriores, todo esto puede ser implementado sin cambios esenciales en la sección crítica de la
aplicación target.
8.2.3. Comentarios finales
El prototipo, siendo una primera aproximación al equipo definitivo, ha cubierto

aceptablemente los objetivos iniciales del proyecto. Todas las extensiones sugeridas son
factibles y no requieren modificaciones esenciales en las estructuras de hardware y software,
habiéndoselas dejado de lado con el único fin de acotar la extensión del presente proyecto.

Anexo A – Aproximación Polinomial de la Función Potencial
El cálculo de la fuerza fe2(k) se realiza a través de la siguiente expresión:
fe2(k) = – Kh Δy α ( 1 + μh Δv ) (A.1)
Dado que ésta se calcula en cada paso de simulación y para cada cuerda, se hace necesario
disminuir al mínimo el costo computacional. La expresión (1) no presenta mayores
complicaciones, a no ser por la función x α cuya evaluación demanda una cantidad excesiva
de ciclos de ejecución. Una posible solución consiste en realizar la aproximación siguiente:
xα ≅ Α xm + B xn (A.2)
siendo en esta última m y n números naturales, mientras que A y B son números reales. De
esta forma, basta con multiplicar un número entero de veces x por sí misma, primero m y
luego n veces, luego multiplicar por A y B, y finalmente sumar. Esto es mucho más rápido que
cualquier algoritmo iterativo que calcule la potenciación de números de punto flotante de 32
bits.
Llamemos a las funciones original y aproximada como*:
f (x) = x α (Α.3a)
g(x) = Α x m + B x n (A.3b)
Ahora bien, dado que tenemos sólo un parámetro (α) mientras que debemos determinar
cuatro incógnitas (A, B, m, n), nos valemos de las siguientes consideraciones inherentes al
modelo físico:
i. g(0) = 0;
ii. g’(0) = 0;
iii. g ( x) ≥ 0; ∀x
iv. 2 ≤ α ≤ 3;
v. x ≤ X máx ;
La condición (i) se deduce de la necesidad de que la fuerza varíe en forma continua ante
variaciones continuas de la contracción elástica. Al ser la fuerza nula cuando el martillo y la
cuerda no están en contacto (contracción negativa), es importante que la curva le haga
corresponder un valor cero a la fuerza cuando la contracción es 0. La condición (ii) surge para
dar no sólo continuidad a la curva, sino también a su primera derivada respecto de x. Las
condiciones (i) y (ii) también guardan relación con el hecho de que toda función del tipo xα ,
dentro de los valores posibles de α, las cumple.
La condición (iii) es muy importante, ya que de no cumplirse existirá al menos una región
de x para la cual la fuerza será de atracción en vez de repulsión. Supongamos que la curva es
como la mostrada en la figura A.1. Como se ve, existe una región (I) y otra (II) cuya frontera
es el punto crítico xo en el cual la curva pasa de ser negativa a positiva. En la región (I), la
fuerza es de atracción, aun cuando el martillo se halla comprimido. Por esto en la región (I) la
compresión tiende a aumentar. Mientras tanto, en la región (II), el martillo y la cuerda tienden
a separarse y la compresión disminuye. De esta forma, si la energía inicial del martillo no
supera un valor crítico, el mismo podría quedar “atrapado” entre ambas regiones,
*
Para el cálculo final, es más eficiente distribuir la expresión (A.3b) como g(x) = (A + B xn − m) xm

aproximándose en sucesivas oscilaciones al punto crítico, donde finalmente reposaría en

forma estable. Si esto ocurriera, el martillo quedaría “adherido” a la cuerda y comprimido
permanentemente una cantidad xo , alterando en forma irreversible los resultados de la
simulación.
FIGURA A.1. Función potencial aproximada con valores negativos
Una vez impuestas las condiciones (i), (ii) y (iii), se hace evidente que las constantes m y
n tienen que ser números pares. La condición (iv) nos lleva a elegir valores de m y n cercanos
al rango normal 2 < α < 3. Finalmente, la función que cumple todo lo enumerado es de la
siguiente forma:
g(x) = Α x 2 + B x 4 (A.4)
Para determinar los valores de A y B, consideramos la condición (v). Para un gran número
de combinaciones de parámetros físicos diferentes, las simulaciones han mostrado que los
valores de la contracción del martillo oscilan dentro de un rango relativamente constante. Para
minimizar la separación entre la curva original y la aproximada en este rango, podemos hacer
que las mismas tengan un par de puntos en común, uno en el extremo máximo del intervalo y
el otro en alguna parte dentro del mismo§. Llamemos a las abscisas de dichos puntos x2 y x1
respectivamente. Luego de todas estas consideraciones, podemos expresar A y B como
funciones de α , x1 y x2 :
⎧⎪ g ( x1 ) = Ax12 + Bx1 4 = x1α

⎨
⎪⎩ g ( x2 ) = Ax2 2 + Bx2 4 = x2α
(A.5)
⎧⎪ A + Bx12 = x1α −2
⎨
⎪⎩ A + Bx2 2 = x2α −2
Luego, el problema se reduce a resolver el sistema:
⎛1 x1 2 ⎞⎛ A ⎞ ⎛ x1α −2 ⎞
⎜ ⎟ ⎜ ⎟
⎜1 x 2 ⎟⎜⎜ B ⎟⎟ = ⎜ x α −2 ⎟ (A.6)
⎝ 2 ⎠⎝ ⎠ ⎝ 2 ⎠
A cálculo hecho, la solución es:
§
Nótese que el extremo inferior del intervalo es el origen, donde ya tenemos un tercer punto común a ambas
curvas

α −2 α −2
⎧ x2 − x1
⎪B = 2 2
⎨ x 2 − x1 (A.7)
⎪ α −2 2
⎩ A = x1 − x1 B
En las figuras A.2 a A.5 se contrasta la gráfica original con su versión aproximada para
diferentes valores de α. En la figura A.5 se muestra lo que sucede si α < 2. La aproximación
es aceptable dentro del entorno de validez, pero como B resulta negativa, finalmente la curva
tiende a −∞ a medida que x aumenta. Esto debe ser tenido en cuenta en ciertas combinaciones
especiales de los parámetros físicos. Si x llegara a penetrar en la región donde g(x) es
negativa, el martillo se vería acelerado en forma opuesta a la normal. Así, éste nunca
emprendería el retroceso, sino que atravesaría la cuerda y continuaría alejándose
indefinidamente.
FIGURA A.2. Función potencial aproximada

α = 2; x 1 = 1mm; x 2 = 2mm

α = 2.5; x 1 = 1mm; x 2 = 2mm


α = 3; x 1 = 1mm; x 2 = 2mm

α = 1.5; x 1 = 1mm; x 2 = 2mm

Anexo B – Función de Suavizado
Sea f(t) una función del tiempo en el dominio continuo, seccionalmente suave.
Supongamos que f tiene una discontinuidad de salto en el instante t = t1. Definamos ahora las
funciones f1(t) y f2(t) de forma tal que la primera sea idéntica a f para valores de t menores a t1
y la segunda sea idéntica a f para valores mayores a t1 (ver figura B.1).
FIGURA B.1. Función de suavizado
Nos proponemos hallar una nueva función g(t), definida en el intervalo [t1; t2] cuya
longitud T = t2 – t1 es una constante especificada, tal que cumpla las siguientes condiciones:
⎧ g (t1 ) = f (t1 )
⎪ g (t ) = f (t )
⎪ 2 2
⎨ (B.1)
⎪ g (t1 ) = f (t1 )
′ ′
⎪⎩ g ′(t 2 ) = f ′(t 2 )
Entre todas las formas posibles que puede tomar una función g que cumpla con estas
características, optamos por la expresión polinomial (B.2):
g (t ) = At 3 + Bt 2 + Ct + D (B.2)
Debemos ahora expresar los coeficientes del polinomio en términos de los valores que
toma f y de sus derivadas en los puntos t1 y t2, a los cuales llamaremos y1, y2, y1’ e y2’. Sin
restar generalidad, hagamos valer t1 = 0, con lo cual t2 = T. Luego derivamos la expresión
(B.2):
g ′(t ) = 3 At 2 + 2 Bt + C (B.3)
De (B.1), (B.2) y (B.3) se deduce inmediatamente que D = y1, C = y1’. Finalmente, por un
simple reemplazo y trabajo algebraico obtenemos la solución:
⎧ D = y1
⎪C y ′
⎪ = 1
⎪ 1
⎨ A = 3 [2(CT + D − y 2 ) + T ( y 2′ − C )] (B.4)
⎪ T
⎪
⎪B =
1
(
y 2′ − 3 AT 2 − C )
⎩ 2T
Como puede observarse, esta función g permite obtener una versión suavizada de f (es
decir, continua y con primera derivada continua) modificando su gráfica original en un
intervalo de longitud T especificada en forma arbitraria, y sin alterarla fuera de él. El cálculo
de sus coeficientes es de bajo costo computacional, ya que requiere un pequeño conjunto de
operaciones de suma y multiplicación de punto flotante. En las divisiones que forman parte de
las expresiones (B.4) sólo interviene la constante T, y su cálculo puede hacerse por única vez
en forma offline. La figura B.2 muestra superpuestas la curva original discontinua, y la que
resulta de aplicar el suavizado para un caso particular.
FIGURA B.2. Curva original y suavizada –

t 1 = 2; t 2 = 8; y1 = 4; y2 = 5; y1’= 1; y2’= π/6.

Anexo C – Códigos Fuente de Secciones Críticas
C.1. SIMULAR.ASM
*------------------------------------------------------------------------------
* Funciones llamadas desde código C
*------------------------------------------------------------------------------
.def _sim_cuerda
*------------------------------------------------------------------------------
* ======= Función _sim_cuerda =======
*------------------------------------------------------------------------------
* Valor devuelto -> (void)
* Parámetros:
* (Ptr): dirección del buffer W / c0
* (Ptr): dirección del buffer W / c1
* (Ptr): dirección del buffer YL / YR
* (Ptr): dirección del buffer H (parámetros del martillo)
* (Ptr): dirección del buffer b1
* (Ptr): dirección del buffer aL / aR
* (float): coeficiente de normalización para la cuerda en cuestión
* -----------------------------------------------------------------------------
_NUM_ARMONICOS .set 80 - 11
_NUM_FRAMES .set 512
_NUM_CICLOS .set _NUM_FRAMES / 2
_FS .set 44100
FS: .float _FS

TS: .float 1.0/_FS
CONST_0 .float 0.0
CONST_1 .float 1.0
_sim_cuerda:
STW .D2 A15,*B15-- ;

STW .D2 B14,*B15-- ;
STW .D2 A14,*B15-- ;
STW .D2 B13,*B15-- ;
STW .D2 A13,*B15-- ;
STW .D2 B12,*B15-- ;Guarda en el stack los registros que
STW .D2 A12,*B15-- ;se van a usar (PUSH)
STW .D2 B11,*B15-- ;
STW .D2 A11,*B15-- ;
STW .D2 B10,*B15-- ;
STW .D2 A10,*B15-- ;
STW .D2 B9,*B15-- ;
STW .D2 A9,*B15-- ;
STW .D2 B8,*B15-- ;
STW .D2 A8,*B15-- ;
STW .D2 B7,*B15-- ;
STW .D2 A7,*B15-- ;
STW .D2 B6,*B15-- ;
STW .D2 A6,*B15-- ;
STW .D2 B5,*B15-- ;
STW .D2 A5,*B15-- ;
STW .D2 B4,*B15-- ;
STW .D2 A4,*B15-- ;
STW .D2 B3,*B15-- ;
STW .D2 A3,*B15-- ;
STW .D2 B2,*B15-- ;
STW .D2 A2,*B15-- ;
STW .D2 B1,*B15-- ;
STW .D2 A1,*B15-- ;
STW .D2 B0,*B15-- ;
STW .D2 A0,*B15-- ;
MV .L1 B15,A3 ;Salva el SP (stack pointer)

|| MV .L2 A10,B13 ;Salva el coeficiente de normalización
MVK .S2 _NUM_CICLOS,B1 ;Inicializa cont1

|| LDW .D2 *+B6[9],A11 ;Cargo el último valor de Fe2
BUCLE_PRINCIPAL:
[B1] SUB .S2 B1,1,B1 ;Decrementa cont2

|| MV .L1 B4,A0 ;Copia la dirección del buffer
;W-2/c1 en el puntero de W
*==============================================================================
*------------------------------------------------------------------------------
* Comienzo del Paso de Integración IMPAR
*------------------------------------------------------------------------------
*==============================================================================
*CICLO #0 ---------------------------------------------------------------------
LDDW .D1 *A4++[4],A15:A14

;Lee de memoria W-1 y c0
|| LDDW .D2 *B4++[4],B15:B14
;Lee de memoria W-2 y c1
|| MVKL .S1 CONST_0,A5 ;Carga en A5 la 1º parte de la
;direcc. de CONST_0
*CICLO #1 ---------------------------------------------------------------------
MVKH .S1 CONST_0,A5 ;Carga en A5 la 2º parte de la

;direcc. de CONST_0
|| LDW .D1 *A5,A7 ;Carga en A7 CONST_0
*CICLO #2 ---------------------------------------------------------------------
MVK .S1 _NUM_ARMONICOS,A1 ;Inicializa cont2

|| LDW .D1 *A5,B7 ;Carga en B7 CONST_0
*CICLO #3 ---------------------------------------------------------------------
LDDW .D1 *A4++[4],A15:A14 ;Lee de memoria W-1 y c0

|| LDDW .D2 *B4++[4],B15:B14 ;Lee de memoria W-2 y c1
*CICLO #4 ---------------------------------------------------------------------
LDW .D1 *A8++[8],A10 ;Lee de memoria b1
*CICLO #5 ---------------------------------------------------------------------
MPYSP .M2X B14,A15,B5 ;Multiplica W-2*c0 -> S2
*CICLO #6 ---------------------------------------------------------------------

|| MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1
*CICLO #7 ---------------------------------------------------------------------
*CICLO #8 ---------------------------------------------------------------------
MPYSP .M2X B14,A15,B5 ;Multiplica W-2*c0 -> S2
*CICLO #9 ---------------------------------------------------------------------

*CICLO #10 --------------------------------------------------------------------
*CICLO #11 --------------------------------------------------------------------
MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3

|| MPYSP .M2X B14,A15,B5 ;Multiplica W-2*c0 -> S2
|| ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12
*CICLO #12 --------------------------------------------------------------------

*CICLO #13 --------------------------------------------------------------------
*CICLO #14 --------------------------------------------------------------------
LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR

|| MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3
*CICLO #15 --------------------------------------------------------------------

|| ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W
*CICLO #16 --------------------------------------------------------------------
*CICLO #17 --------------------------------------------------------------------
LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR

*CICLO #18 --------------------------------------------------------------------

*CICLO #19 --------------------------------------------------------------------

|| MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK
|| MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK
*CICLO #20 --------------------------------------------------------------------
STW .D1 A9,*A0++[8] ;Escribe en memoria W

|| LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR
*CICLO #21 --------------------------------------------------------------------

*CICLO #22 --------------------------------------------------------------------

|| [A1] B .S1 BUCLE_IMPAR ;Salto a BUCLE_IMPAR (si cont2 > 0)
*CICLO #23 --------------------------------------------------------------------

*CICLO #24 --------------------------------------------------------------------

*------------------------------------------------------------------------------
* Comienzo del bucle principal
*------------------------------------------------------------------------------
BUCLE_IMPAR:
*CICLO #25 --------------------------------------------------------------------

|| ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL
|| ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR
|| [A1] B .S1 BUCLE_IMPAR ;Salto a BUCLE_IMPAR (si cont2 > 0)
*CICLO #26 --------------------------------------------------------------------

*CICLO #27 --------------------------------------------------------------------

|| [A1] SUB .S1 A1,1,A1 ;Decrementa cont2 (si cont2 > 0)
*------------------------------------------------------------------------------
* Final del bucle principal
*------------------------------------------------------------------------------
*CICLO #28 --------------------------------------------------------------------

*CICLO #29 --------------------------------------------------------------------

*CICLO #30 --------------------------------------------------------------------
MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1

*CICLO #31 --------------------------------------------------------------------

*CICLO #32 --------------------------------------------------------------------

*CICLO #33 --------------------------------------------------------------------
MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1

*CICLO #34 --------------------------------------------------------------------
MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK

*CICLO #35 --------------------------------------------------------------------

*CICLO #36 --------------------------------------------------------------------
ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W
*CICLO #37 --------------------------------------------------------------------

*CICLO #38 --------------------------------------------------------------------

*CICLO #39 --------------------------------------------------------------------
*CICLO #40 --------------------------------------------------------------------

*CICLO #41 --------------------------------------------------------------------

*CICLO #42 --------------------------------------------------------------------
*CICLO #43 --------------------------------------------------------------------

*CICLO #44 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
|| MV .L1 B6,A5 ;Copio la dirección de p_H para

;accesos al buffer desde el lado A
;A5-> Lado A, B6-> Lado B
|| MVKL .S1 TS,A10 ;Cargo 1º parte de la direcc. de TS
|| MVKL .S2 FS,B2 ;Cargo 1º parte de la direcc. de FS
|| LDDW .D2 *++B6,B11:B10 ;Cargo Yh:aux en B11:B10
*CICLO #45 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
MVKH .S1 TS,A10 ;Cargo 2º parte de la direcc. de TS

|| MVKH .S2 FS,B2 ;Cargo 2º parte de la direcc. de FS
|| LDDW .D1 *A5++[2],A13:A12 ;Cargo Vh:(Ah*TS) en A13:A12
|| LDDW .D2 *++B6[2],B15:B14 ;Cargo (-Kh):MUh en B15:B14
*CICLO #46 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
|| LDW .D1 *A10,A9 ;Cargo TS en A9

|| LDW .D2 *B2,B3 ;Cargo FS en B3
|| MVKL .S2 CONST_1,B0 ;Cargo 1º parte direcc. de CONST_1
*CICLO #47 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
|| MVKH .S2 CONST_1,B0 ;Cargo 2º parte direcc. de CONST_1

|| LDW .D2 *B0,B12 ;Cargo CONST_1 (=1.0) en B12
*CICLO #48 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
LDDW .D1 *A5++[2],A15:A14 ;Cargo A:B en A15:A14

|| LDW .D2 *+B6[4],B11 ;Cargo Yc(k-1) en B11
*CICLO #49 --------------------------------------------------------------------
ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL

*====== MARTILLO ==============================================================
|| LDW .D1 *A5,A10 ;Cargo (-TS/Mh) en A10
*CICLO #50 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
ADDSP .L1 A13,A12,A13 ;Sumo (Ah*TS)+Vh -> A13
*CICLO #51 --------------------------------------------------------------------
NOP
*CICLO #52 --------------------------------------------------------------------

*------------------------------------------------------------------------------
* Sección Martillo
*------------------------------------------------------------------------------
*CICLO #53 --------------------------------------------------------------------
MV .S1 A7,A5 ;Salva la semisuma par de YL

|| MV .S2 B7,B5 ;Salva la semisuma par de YR
*CICLO #54 --------------------------------------------------------------------
MPYSP .M1 A13,A9,A2 ;Multiplica Vh*TS -> A2

|| STW .D2 A13,*--B6[6] ;Guarda en memoria Vh (Retorna el
;p_H a la posición inicial
*CICLO #55 --------------------------------------------------------------------
NOP
*CICLO #55_1 ------------------------------------------------------------------
ADDSP .L1 A5,A7,A7 ;Calcula la suma total de YL

|| ADDSP .L2 B5,B7,B7 ;Calcula la suma total de YR
*CICLO #55_2 ------------------------------------------------------------------
NOP
*CICLO #55_3 ------------------------------------------------------------------
NOP
*CICLO #55_4 ------------------------------------------------------------------
NOP
*CICLO #56 --------------------------------------------------------------------
ADDSP .L2X A7,B7,B0 ;Suma YL+YR->YT ( =Yc(k) )

*CICLO #57 --------------------------------------------------------------------
MPYSP .M1X A7,B13,A7 ;Aplica coef. de normaliz

;YL*Coef_N ->YL
|| MPYSP .M2 B7,B13,B7 ;Aplica coef. de normaliz
;YR*Coef_N ->YR
*CICLO #58 --------------------------------------------------------------------
ADDSP .L2X B10,A2,B10 ;Suma Yh+(Vh*TS)->Yh
*CICLO #59 --------------------------------------------------------------------
NOP
*CICLO #60 --------------------------------------------------------------------
STW .D2 B0,*+B6[11] ;Guarda en memoria Yc(k-1)

;(Yc(k-1) en el paso siguiente es
;Yc(k) = YT del paso actual)
*CICLO #60_1 --------------------------------------------------------------------
SUBSP .L2 B11,B0,B11 ;Resta Yc(k-1)-Yc(k-2)->B11
*CICLO #61 --------------------------------------------------------------------
STW .D1 A7,*A6++ ;Guarda en memoria YL
*CICLO #62 --------------------------------------------------------------------
SUBSP .L2 B11,B10,B2 ;Resta Yc(k-1)-Yh(k)->B2

|| STW .D2 B10,*+B6[2] ;Guarda en memoria Yh
*CICLO #63 --------------------------------------------------------------------
NOP
*CICLO #64 --------------------------------------------------------------------
MPYSP .M2 B11,B3,B11 ;Multiplica ( Yc(k-1)-Yc(k-2) ) * FS

;->B11
|| STW .D1 B7,*A6++ ;Guarda en memoria YR
*CICLO #65 --------------------------------------------------------------------
NOP
*CICLO #66 --------------------------------------------------------------------
MPYSP .M2 B2,B2,B9 ;Multiplica Dy * Dy->B9
*CICLO #67 --------------------------------------------------------------------
NOP
*CICLO #68 --------------------------------------------------------------------
SUBSP .L2X B11,A13,B11 ;Resta (Yc(k)-Yc(k-1))*FS - Vh->B11
*CICLO #69 --------------------------------------------------------------------
NOP
*CICLO #70 --------------------------------------------------------------------
MPYSP .M2 B9,B14,B14 ;Multiplica Dy² * (-Kh)->B14

|| MPYSP .M1X B9,A15,A15 ;Multiplica Dy² * B->A15
*CICLO #71 --------------------------------------------------------------------
MVKL .S1 CONST_0,A7 ;Carga 1º parte direcc. CONST_0
*CICLO #72 --------------------------------------------------------------------
MPYSP .M2 B11,B15,B15 ;Multiplica Dv * MUh->B15

|| MVKH .S1 CONST_0,A7 ;Carga 2º parte direcc. CONST_0
*CICLO #73 --------------------------------------------------------------------
LDW .D1 *A7,A7 ;Carga CONST_0 en A7
*CICLO #74 --------------------------------------------------------------------
ADDSP .L1 A15,A14,A14 ;Suma Dy²*B + A->A14
*CICLO #75 --------------------------------------------------------------------
NOP
*CICLO #76 --------------------------------------------------------------------
ADDSP .L2 B15,B12,B15 ;Suma Dv*MUh + 1.0->B15
*CICLO #77 --------------------------------------------------------------------
NOP
*CICLO #78 --------------------------------------------------------------------
MPYSP .M1X A14,B14,A14 ;Multiplica (Dy²*B+A) * (-Kh*Dy²)

;->A14
*CICLO #79 --------------------------------------------------------------------
CMPLTSP .S2X B2,A7,B2 ;
*CICLO #80 --------------------------------------------------------------------
NOP
*CICLO #81 --------------------------------------------------------------------
NOP
*CICLO #82 --------------------------------------------------------------------
[!B2] MPYSP .M1X A14,B15,A11 ;Si Dy >= 0:

;Multiplica (Dy²*B+A)*(-Kh*Dy²) *
;(1+Dv*MUh)->Fe2
*CICLO #83 --------------------------------------------------------------------
[B2] MV .S1 A7,A11 ;Si Dy < 0: setea Fe2 = 0.0
*CICLO #84 --------------------------------------------------------------------
NOP
*CICLO #85 --------------------------------------------------------------------
NOP
*CICLO #86 --------------------------------------------------------------------
MPYSP .M1 A11,A10,A10 ;Multiplico Fe2*(-TS/Mh)->A10

|| STW .D2 A11,*+B6[9] ;Guarda en memoria Fe2
*CICLO #87 --------------------------------------------------------------------
NOP
*CICLO #88 --------------------------------------------------------------------
NOP
*CICLO #89 --------------------------------------------------------------------
NOP
*CICLO #90 --------------------------------------------------------------------
STW .D2 A10,*+B6[1] ;Guardo en memoria Ah
|| MV .L1 A4,A0 ;Copia la dirección del buffer

;W-2/c0 en el puntero de W
*==============================================================================
*------------------------------------------------------------------------------
* Comienzo del Paso de Integración PAR
*------------------------------------------------------------------------------
*==============================================================================
*CICLO #0 ---------------------------------------------------------------------
LDDW .D1 *--A4[4],A15:A14 ;Lee de memoria W-2 y c0

|| LDDW .D2 *--B4[4],B15:B14 ;Lee de memoria W-1 y c1
|| MVKL .S1 CONST_0,A5 ;Carga en A5 la 1º parte de la
;direcc. de CONST_0
*CICLO #1 ---------------------------------------------------------------------
MVKH .S1 CONST_0,A5 ;Carga en A5 la 2º parte de la

;direcc. de CONST_0
|| LDW .D1 *A5,A7 ;Carga en A7 CONST_0
*CICLO #2 ---------------------------------------------------------------------
MVK .S1 _NUM_ARMONICOS,A1 ;Inicializa cont2

|| LDW .D1 *A5,B7 ;Carga en B7 CONST_0
*CICLO #3 ---------------------------------------------------------------------

*CICLO #4 ---------------------------------------------------------------------
LDW .D1 *--A8[8],A10 ;Lee de memoria b1
*CICLO #5 ---------------------------------------------------------------------
MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2
*CICLO #6 ---------------------------------------------------------------------

|| MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1
*CICLO #7 ---------------------------------------------------------------------
*CICLO #8 ---------------------------------------------------------------------
MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2
*CICLO #9 ---------------------------------------------------------------------

*CICLO #10 --------------------------------------------------------------------
*CICLO #11 --------------------------------------------------------------------
MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3

|| MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2
*CICLO #12 --------------------------------------------------------------------

*CICLO #13 --------------------------------------------------------------------
*CICLO #14 --------------------------------------------------------------------
LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR

*CICLO #15 --------------------------------------------------------------------

*CICLO #16 --------------------------------------------------------------------
*CICLO #17 --------------------------------------------------------------------
LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR

*CICLO #18 --------------------------------------------------------------------

*CICLO #19 --------------------------------------------------------------------

*CICLO #20 --------------------------------------------------------------------
STW .D1 A9,*--A0[8] ;Escribe en memoria W

|| LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR
*CICLO #21 --------------------------------------------------------------------

*CICLO #22 --------------------------------------------------------------------

|| [A1] B .S1 BUCLE_PAR ;Salto a BUCLE_IMPAR (si cont2 > 0)
*CICLO #23 --------------------------------------------------------------------

*CICLO #24 --------------------------------------------------------------------

*------------------------------------------------------------------------------
*------------------------------------------------------------------------------
BUCLE_PAR:
*CICLO #25 --------------------------------------------------------------------

|| [A1] B .S1 BUCLE_PAR ;Salto a BUCLE_IMPAR (si cont2 > 0)
*CICLO #26 --------------------------------------------------------------------

*CICLO #27 --------------------------------------------------------------------

|| [A1] SUB .S1 A1,1,A1 ;Decrementa cont2 (si cont2 > 0)
*------------------------------------------------------------------------------
*------------------------------------------------------------------------------
*CICLO #28 --------------------------------------------------------------------

*CICLO #29 --------------------------------------------------------------------

*CICLO #30 --------------------------------------------------------------------
MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1

*CICLO #31 --------------------------------------------------------------------

*CICLO #32 --------------------------------------------------------------------

*CICLO #33 --------------------------------------------------------------------
MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1

*CICLO #34 --------------------------------------------------------------------

*CICLO #35 --------------------------------------------------------------------

*CICLO #36 --------------------------------------------------------------------
*CICLO #37 --------------------------------------------------------------------

*CICLO #38 --------------------------------------------------------------------

*CICLO #39 --------------------------------------------------------------------
*CICLO #40 --------------------------------------------------------------------

*CICLO #41 --------------------------------------------------------------------

*CICLO #42 --------------------------------------------------------------------
*CICLO #43 --------------------------------------------------------------------

*CICLO #44 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
|| MV .L1 B6,A5 ;Copio la dirección de p_H para

;accesos al buffer desde el lado A
;A5-> Lado A, B6-> Lado B
|| MVKL .S1 TS,A10 ;Cargo 1º parte de la direcc. de TS
|| MVKL .S2 FS,B2 ;Cargo 1º parte de la direcc. de FS
|| LDDW .D2 *++B6,B11:B10 ;Cargo Yh:aux en B11:B10
*CICLO #45 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
MVKH .S1 TS,A10 ;Cargo 2º parte de la direcc. de TS

|| MVKH .S2 FS,B2 ;Cargo 2º parte de la direcc. de FS
|| LDDW .D1 *A5++[2],A13:A12 ;Cargo Vh:(Ah*TS) en A13:A12
|| LDDW .D2 *++B6[2],B15:B14 ;Cargo (-Kh):MUh en B15:B14
*CICLO #46 --------------------------------------------------------------------

*====== MARTILLO ==============================================================
|| LDW .D1 *A10,A9 ;Cargo TS en A9

|| LDW .D2 *B2,B3 ;Cargo FS en B3
|| MVKL .S2 CONST_1,B0 ;Cargo 1º parte direcc. de CONST_1
*CICLO #47 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
|| MVKH .S2 CONST_1,B0 ;Cargo 2º parte direcc. de CONST_1

|| LDW .D2 *B0,B12 ;Cargo CONST_1 (=1.0) en B12
*CICLO #48 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
LDDW .D1 *A5++[2],A15:A14 ;Cargo A:B en A15:A14

*CICLO #49 --------------------------------------------------------------------

*====== MARTILLO ==============================================================
|| LDW .D1 *A5,A10 ;Cargo (-TS/Mh) en A10
*CICLO #50 --------------------------------------------------------------------
*====== MARTILLO ==============================================================
ADDSP .L1 A13,A12,A13 ;Sumo (Ah*TS)+Vh -> A13
*CICLO #51 --------------------------------------------------------------------
NOP
*CICLO #52 --------------------------------------------------------------------

*------------------------------------------------------------------------------
* Sección Martillo
*------------------------------------------------------------------------------
*CICLO #53 --------------------------------------------------------------------
MV .S1 A7,A5 ;Salva la semisuma par de YL

|| MV .S2 B7,B5 ;Salva la semisuma par de YR
*CICLO #54 --------------------------------------------------------------------
MPYSP .M1 A13,A9,A2 ;Multiplica Vh*TS -> A2
|| STW .D2 A13,*--B6[6] ;Guarda en memoria Vh (Retorna el
;p_H a la posición inicial
*CICLO #55 --------------------------------------------------------------------
NOP
*CICLO #55_1 ------------------------------------------------------------------
ADDSP .L1 A5,A7,A7 ;Calcula la suma total de YL

|| ADDSP .L2 B5,B7,B7 ;Calcula la suma total de YR
*CICLO #55_2 ------------------------------------------------------------------
NOP
*CICLO #55_3 ------------------------------------------------------------------
NOP
*CICLO #55_4 ------------------------------------------------------------------
NOP
*CICLO #56 --------------------------------------------------------------------
ADDSP .L2X A7,B7,B0 ;Suma YL+YR->YT ( =Yc(k) )

|| LDW .D2 *+B6[10], B0 ;Carga Yc(k-2) en B0
*CICLO #57 --------------------------------------------------------------------
MPYSP .M1X A7,B13,A7 ;Aplica coef. de normaliz

;YL*Coef_N ->YL
|| MPYSP .M2 B7,B13,B7 ;Aplica coef. de normaliz
;YR*Coef_N ->YR
*CICLO #58 --------------------------------------------------------------------
ADDSP .L2X B10,A2,B10 ;Suma Yh+(Vh*TS)->Yh
*CICLO #59 --------------------------------------------------------------------
NOP
*CICLO #60 --------------------------------------------------------------------
STW .D2 B0,*+B6[10] ;Guarda en memoria Yc(k-1)

;(Yc(k-1) en el paso siguiente es
;Yc(k) = YT del paso actual)
*CICLO #60_1 ------------------------------------------------------------------
SUBSP .L2 B11,B0,B11 ;Resta Yc(k-1)-Yc(k-2)->B11
*CICLO #61 --------------------------------------------------------------------
STW .D1 A7,*A6++ ;Guarda en memoria YL
*CICLO #62 --------------------------------------------------------------------
SUBSP .L2 B11,B10,B2 ;Resta Yc(k-1)-Yh(k)->B2

|| STW .D2 B10,*+B6[2] ;Guarda en memoria Yh
*CICLO #63 --------------------------------------------------------------------
NOP
*CICLO #64 --------------------------------------------------------------------
MPYSP .M2 B11,B3,B11 ;Multiplica ( Yc(k-1)-Yc(k-2) ) * FS

;->B11
|| STW .D1 B7,*A6++ ;Guarda en memoria YR
*CICLO #65 --------------------------------------------------------------------
NOP
*CICLO #66 --------------------------------------------------------------------
MPYSP .M2 B2,B2,B9 ;Multiplica Dy * Dy->B9
*CICLO #67 --------------------------------------------------------------------
NOP
*CICLO #68 --------------------------------------------------------------------
SUBSP .L2X B11,A13,B11 ;Resta (Yc(k)-Yc(k-1))*FS - Vh->B11
*CICLO #69 --------------------------------------------------------------------
NOP
*CICLO #70 --------------------------------------------------------------------
MPYSP .M2 B9,B14,B14 ;Multiplica Dy² * (-Kh)->B14

|| MPYSP .M1X B9,A15,A15 ;Multiplica Dy² * B->A15
*CICLO #71 --------------------------------------------------------------------
MVKL .S1 CONST_0,A7 ;Carga 1º parte direcc. CONST_0
*CICLO #72 --------------------------------------------------------------------
MPYSP .M2 B11,B15,B15 ;Multiplica Dv * MUh->B15

|| MVKH .S1 CONST_0,A7 ;Carga 2º parte direcc. CONST_0
*CICLO #73 --------------------------------------------------------------------
LDW .D1 *A7,A7 ;Carga CONST_0 en A7
*CICLO #74 --------------------------------------------------------------------
ADDSP .L1 A15,A14,A14 ;Suma Dy²*B + A->A14
*CICLO #75 --------------------------------------------------------------------
NOP
*CICLO #76 --------------------------------------------------------------------
ADDSP .L2 B15,B12,B15 ;Suma Dv*MUh + 1.0->B15
*CICLO #77 --------------------------------------------------------------------
NOP
*CICLO #78 --------------------------------------------------------------------
MPYSP .M1X A14,B14,A14 ;Multiplica (Dy²*B+A) * (-Kh*Dy²)

;->A14
*CICLO #79 --------------------------------------------------------------------
CMPLTSP .S2X B2,A7,B2 ;
*CICLO #80 --------------------------------------------------------------------
NOP
*CICLO #81 --------------------------------------------------------------------
NOP
*CICLO #82 --------------------------------------------------------------------
[!B2] MPYSP .M1X A14,B15,A11 ;Si Dy >= 0:

;Multiplica (Dy²*B+A)*(-Kh*Dy²) *
;(1+Dv*MUh)->Fe2
*CICLO #83 --------------------------------------------------------------------
[B2] MV .S1 A7,A11 ;Si Dy < 0: setea Fe2 = 0.0
*CICLO #84 --------------------------------------------------------------------
NOP
*CICLO #85 --------------------------------------------------------------------
[B1] B .S2 BUCLE_PRINCIPAL ;Salta a BUCLE_PRINCIPAL si cont1>0
*CICLO #86 --------------------------------------------------------------------
MPYSP .M1 A11,A10,A10 ;Multiplico Fe2*(-TS/Mh)->A10

|| STW .D2 A11,*+B6[9] ;Guarda en memoria Fe2
*CICLO #87 --------------------------------------------------------------------
NOP
*CICLO #88 --------------------------------------------------------------------
NOP
*CICLO #89 --------------------------------------------------------------------
NOP
*CICLO #90 --------------------------------------------------------------------
STW .D2 A10,*+B6[1] ;Guardo en memoria Ah
MV .S2 A3,B15 ;Restablece el SP (stack pointer)
LDW .D2 *++B15,A0 ;

LDW .D2 *++B15,B0 ;
LDW .D2 *++B15,A1 ;
LDW .D2 *++B15,B1 ;
LDW .D2 *++B15,A2 ;
LDW .D2 *++B15,B2 ;
LDW .D2 *++B15,A3 ;
LDW .D2 *++B15,B3 ;Lee del stack los registros que fueron
LDW .D2 *++B15,A4 ;salvados (POP)
LDW .D2 *++B15,B4 ;
LDW .D2 *++B15,A5 ;
LDW .D2 *++B15,B5 ;
LDW .D2 *++B15,A6 ;
LDW .D2 *++B15,B6 ;
LDW .D2 *++B15,A7 ;
LDW .D2 *++B15,B7 ;
LDW .D2 *++B15,A8 ;
LDW .D2 *++B15,B8 ;
LDW .D2 *++B15,A9 ;
LDW .D2 *++B15,B9 ;
LDW .D2 *++B15,A10 ;
LDW .D2 *++B15,B10 ;
LDW .D2 *++B15,A11 ;
LDW .D2 *++B15,B11 ;
LDW .D2 *++B15,A12 ;
LDW .D2 *++B15,B12 ;
LDW .D2 *++B15,A13 ;
LDW .D2 *++B15,B13 ;
LDW .D2 *++B15,A14 ;
LDW .D2 *++B15,B14 ;
LDW .D2 *++B15,A15 ;
B .S2 B3
NOP 5
.end
C.2. CONV_TABLA_ARM.ASM
*------------------------------------------------------------------------------
* Funciones llamadas desde código C
*------------------------------------------------------------------------------
.def _conv_tabla_arm
*------------------------------------------------------------------------------
* ======= Función _conv_tabla_arm =======
*------------------------------------------------------------------------------
* Valor devuelto -> (float)
* Parámetros:
* (Ptr): dirección del buffer p_Buff_YL/R_T[Offset_YL/R]
* (Ptr): dirección del buffer p_TablaArm
* -----------------------------------------------------------------------------
_NUM_FRAMES .set 512

_NUM_CICLOS .set _NUM_FRAMES/2 - 15
_conv_tabla_arm:
STW .D2 A15,*B15-- ;

STW .D2 B14,*B15-- ;
STW .D2 A14,*B15-- ;
STW .D2 B13,*B15-- ;
STW .D2 A13,*B15-- ;
STW .D2 B12,*B15-- ;Guarda en el stack los registros que
STW .D2 A12,*B15-- ;se van a usar (PUSH)
STW .D2 B11,*B15-- ;
STW .D2 A11,*B15-- ;
STW .D2 B10,*B15-- ;
STW .D2 A10,*B15-- ;
STW .D2 B9,*B15-- ;
STW .D2 A9,*B15-- ;
STW .D2 B8,*B15-- ;
STW .D2 A8,*B15-- ;
STW .D2 B7,*B15-- ;
STW .D2 A7,*B15-- ;
STW .D2 B6,*B15-- ;
STW .D2 A6,*B15-- ;
STW .D2 B5,*B15-- ;
STW .D2 A5,*B15-- ;
STW .D2 B4,*B15-- ;
;
STW .D2 B3,*B15-- ;
STW .D2 A3,*B15-- ;
STW .D2 B2,*B15-- ;
STW .D2 A2,*B15-- ;
STW .D2 B1,*B15-- ;
STW .D2 A1,*B15-- ;
STW .D2 B0,*B15-- ;
STW .D2 A0,*B15-- ;
MV .L1 B15,A3 ;Salva el SP (stack pointer)

|| MVK .S1 _NUM_CICLOS,A1 ;Inicializa cont1
MVKL .S2 0x0001,B0 ; Parte baja de AMR

MVKLH .S2 0x000B,B0 ; Parte alta de AMR
MVC .S2 B0,AMR ; Inicializa el registro de modo de
; direccionamiento (AMR) para fun-
; cionar en modo circular:
; Base: A4, Tamaño: 4096 bytes
*==============================================================================
*------------------------------------------------------------------------------
* Comienzo de la convolución
*------------------------------------------------------------------------------
*==============================================================================
*CICLO #0 ---------------------------------------------------------------------
LDDW .D1 *A4++,A15:A14 ;Lee de memoria YL/R(k):YL/R(k+1)

|| LDDW .D2 *B4++,B15:B14 ;Lee de memoria h(k):h(k+1)
|| ZERO .L1 A9 ;Resetea S1
|| ZERO .L2 B9 ;Resetea S2
*CICLO #1 ---------------------------------------------------------------------

*CICLO #2 ---------------------------------------------------------------------

*CICLO #3 ---------------------------------------------------------------------

*CICLO #4 ---------------------------------------------------------------------

|| [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0)
*CICLO #5 ---------------------------------------------------------------------

|| MPYSP .M1X A14,B14,A7 ;Multiplica YL/R(k) por h(k)
|| MPYSP .M2X A15,B15,B7 ;Multiplica YL/R(k+1) por h(k+1)
*CICLO #6 ---------------------------------------------------------------------

*CICLO #7 ---------------------------------------------------------------------

*CICLO #8 ---------------------------------------------------------------------

*------------------------------------------------------------------------------
*------------------------------------------------------------------------------
BUCLE:
*CICLO #9 ---------------------------------------------------------------------

|| ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1
|| ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1
|| [A1] SUB .S1 A1,1,A1 ;Decrementa A1 (si cont1 > 0)
*------------------------------------------------------------------------------
*------------------------------------------------------------------------------
*CICLO #10 --------------------------------------------------------------------
MPYSP .M1X A14,B14,A7 ;Multiplica YL/R(k) por h(k)

*CICLO #11 --------------------------------------------------------------------

*CICLO #12 --------------------------------------------------------------------

*CICLO #13 --------------------------------------------------------------------

*CICLO #14 --------------------------------------------------------------------

*CICLO #15 --------------------------------------------------------------------
ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1

*CICLO #16 --------------------------------------------------------------------

*CICLO #17 --------------------------------------------------------------------

*CICLO #18 --------------------------------------------------------------------

*CICLO #19 --------------------------------------------------------------------
MV .S1 A9,A10 ;Guarda 1º parte de la suma 1 en A10

|| MV .S2 B9,B10 ;Guarda 1º parte de la suma 2 en B10
*CICLO #20 --------------------------------------------------------------------
ADDSP .L1 A10,A9,A10 ;Suma partes 1 y 2 de S1 en A10

|| ADDSP .L2 B10,B9,B10 ;Suma partes 1 y 2 de S2 en B10
*CICLO #21 --------------------------------------------------------------------
MV .S1 A9,A12 ;Guarda 3º parte de la suma 1 en A12

|| MV .S2 B9,B12 ;Guarda 3º parte de la suma 2 en B12
*CICLO #22 --------------------------------------------------------------------
ADDSP .L1 A9,A12,A9 ;Suma partes 3 y 4 de S1 en A9

|| ADDSP .L2 B9,B12,B9 ;Suma partes 3 y 4 de S2 en B9
*CICLO #23 --------------------------------------------------------------------
NOP
*CICLO #24 --------------------------------------------------------------------
NOP
*CICLO #25 --------------------------------------------------------------------
NOP
*CICLO #26 --------------------------------------------------------------------
ADDSP .L1 A9,A10,A9 ;Suma partes 1-2 y 3-4 de S1 en A9

|| ADDSP .L2 B9,B10,B9 ;Suma partes 1-2 y 3-4 de S2 en B9
*CICLO #27 --------------------------------------------------------------------
NOP
*CICLO #28 --------------------------------------------------------------------
NOP
*CICLO #29 --------------------------------------------------------------------
NOP
*CICLO #30 --------------------------------------------------------------------
ADDSP .L1 A9,B9,A4 ;Suma S1 y S2 en A4 (valor devuelto)

|| ZERO .L2 B0 ;0 -> B0
|| MVC .S2 B0,AMR ;Reseteo AMR
MV .S2 A3,B15 ;Restablece el SP (stack pointer)
LDW .D2 *++B15,A0 ;

LDW .D2 *++B15,B0 ;
LDW .D2 *++B15,A1 ;
LDW .D2 *++B15,B1 ;
LDW .D2 *++B15,A2 ;
LDW .D2 *++B15,B2 ;
LDW .D2 *++B15,A3 ;
LDW .D2 *++B15,B3 ;Lee del stack los registros que fueron
;salvados (POP)
LDW .D2 *++B15,B4 ;
LDW .D2 *++B15,A5 ;
LDW .D2 *++B15,B5 ;
LDW .D2 *++B15,A6 ;
LDW .D2 *++B15,B6 ;
LDW .D2 *++B15,A7 ;
LDW .D2 *++B15,B7 ;
LDW .D2 *++B15,A8 ;
LDW .D2 *++B15,B8 ;
LDW .D2 *++B15,A9 ;
LDW .D2 *++B15,B9 ;
LDW .D2 *++B15,A10 ;
LDW .D2 *++B15,B10 ;
LDW .D2 *++B15,A11 ;
LDW .D2 *++B15,B11 ;
LDW .D2 *++B15,A12 ;
LDW .D2 *++B15,B12 ;
LDW .D2 *++B15,A13 ;
LDW .D2 *++B15,B13 ;
LDW .D2 *++B15,A14 ;
LDW .D2 *++B15,B14 ;
LDW .D2 *++B15,A15 ;
B .S2 B3
NOP 5
.end
Anexo D – Terminología Musical
Aquí se introduce brevemente algunos conceptos y términos fundamentales de la teoría

musical. Este pequeño apéndice intenta facilitar al lector la asimilación de algunos de los
conceptos expuestos en el presente trabajo.
D.1. Sonido y nota musical
El oído distingue nítidamente entre ondas periódicas (o cuasi periódicas) y ondas

aperiódicas. Las primeras son percibidas como notas musicales, y las segundas como ruido
(el cual también puede ser musical). Un tono puro (o simple) es un sonido continuo de una
sola frecuencia, tal como el producido por un diapasón que vibra en su frecuencia
fundamental [49].
La mayoría de las fuentes sonoras, incluyendo los instrumentos musicales, producen
sonidos espectralmente complejos, en los que interviene un conjunto de componentes
frecuenciales, en general, variable en el tiempo. Cuando un sonido es estrictamente periódico,
sus componentes espectrales se denominan armónicos, correspondiendo a frecuencias cuyos
valores son múltiplos enteros de la frecuencia más baja, o fundamental. En el caso de sonidos
cuasi periódicos, o aperiódicos, los componentes espectrales se designan en forma más
general como parciales.
Hay tres sensaciones primarias asociadas con un cierto sonido musical: la altura, la
sonoridad (o intensidad) y el timbre. El timbre es lo que nos permite distinguir los sonidos
emitidos por diferentes instrumentos, aún cuando la altura y sonoridad sean las mismas. La
asignación sin ambigüedad de estas tres cualidades a un sonido dado es lo que diferencia un
tono musical de un ruido. A pesar de que podemos asignarle sonoridad a un ruido, es muy
difícil o imposible asignarle una única altura o timbre.
Las tres sensaciones descritas son subjetivas, sin embargo cada una de ellas puede ser, en
principio, asociada a magnitudes físicas bien definidas de la onda sonora correspondiente. La
altura está primariamente asociada a la frecuencia fundamental del tono musical, la sonoridad
a la intensidad de la onda y el timbre con su espectro.
Así una nota puede definirse según la convención musical (a cada nota se le hace
corresponder una altura) o mediante la expresión de su frecuencia, por ejemplo La4 o A4
(según el sistema de notación inglés) es igual a 440 Hz.
D.2. Escala musical
Se llama escala musical a la sucesión de sonidos constitutivos de un sistema (tonalidad)

que se suceden regularmente en sentido ascendente o descendente, y todos ellos en relación
con una nota que da nombre a la escala, o tónica. Actualmente la llamada escala musical
diatónica (sin alteraciones ni accidentes tonales) está compuesta por siete notas. En el caso de
la escala mayor de Do, las notas son las siguientes:
Do Re Mi Fa Sol La Si (sistema de notación musical latina)

C D E F G A B (sistema de notación musical inglesa)
La distancia entre notas, en un sentido físico, se define como el cociente de sus

frecuencias fundamentales. Las notas o grados de una escala no guardan igual espacio entre
sí. La distancia mayor entre una nota y otra se llama tono, la distancia menor se llama
semitono. Las frecuencias correspondientes a dos notas separadas por un semitono guardan la
relación f2 / f1 = 21/12, y en el caso de un tono es f2 / f1 = 22/12.
D.3. Notas del piano
La estructura del teclado del piano es periódica, es decir, se repite un patrón a lo largo del
mismo. Este patrón está compuesto de siete teclas blancas y cinco negras, siendo el Do la
primera tecla del mismo. La figura D.1 muestra los nombres de las notas correspondientes a
tres octavas del teclado del piano. Además de las siete notas ya enumeradas en el punto
anterior, aparecen otras cinco. Cuando el símbolo ‘#’ (sostenido) acompaña a una letra,
designa a una nota que se encuentra un semitono por encima de la nota correspondiente a la
letra.
FIGURA D.1. Notas correspondientes a las teclas del piano.

Se muestran sólo tres octavas del registro
Las notas asociadas a las teclas están en orden de altura ascendente, de izquierda a
derecha, siendo el intervalo musical entre notas adyacentes (tanto para teclas de igual como de
distinto color) de un semitono. Las notas asociadas a las teclas blancas corresponden a la
escala mayor de Do (diatónica). Conjuntamente con las notas de las teclas negras, se obtiene
la escala cromática, en la cual todas las notas consecutivas distan entre sí un semitono. De
esta forma, las frecuencias correspondientes a las notas del piano conforman una serie
exponencial creciente, duplicándose su valor cada doce notas consecutivas* (octava).
*
Un intervalo de 12 notas consecutivas en la escala cromática equivale a una separación de 8 notas en la escala
diatónica (teclas blancas). Esta es la razón por la cual se denomina a dicho intervalo octava.
Abreviaturas y Acrónimos
API Application Program Interface

CCS Code Composer Studio
CISC Complex Instruction Set Computer
CODEC Coder – Decoder
CPLD Complex Programmable Logic Device
DP Distribución de Paneo
DSP Digital Signal Processor
DSK DSP Starter Kit
DSP/BIOS DSP Basic Input/Output System
DWG Digital Waveguide
EC Eventos de Control
EMIF External Memory Interface
EVM Evaluation Module
EPROM Electronically Programmable Read-Only Memory
FLOPS Floating Point Operations
FIFO First In – First Out
FTM Functional Transformation Method
IIR Infinite Impulse Response
JTAG Joint Test Action Group
L1 Memoria interna de nivel 1
L2 Memoria interna de nivel 2
McBSP Multichannel Buffered Serial Port
MFLOPS Millions of Floating Point Operations per Second
MIDI Musical Instrument Digital Interface
MIPS Millions of Fixed Point Operations per Second
OLE Object Linking and Embedding
ODE Ordinary Differential Equation
PI Parámetros de Instrumento
PDE Partial Differential Equation
RISC Reduced Instruction Set Computer
RTDX Real-Time Data Exchange
SBSRAM Synchronous Burst Static Random Access Memory
SDRAM Synchronous Dynamic Random Access Memory
SLT Sturm-Liouville Transform
SRAM Static Random Access Memory
TA Parámetros de Tabla Armónica
USB Universal Serial Bus
VLIW Very Long Instruction Word
Lista de Símbolos Principales
ρc Densidad de la cuerda [kg/m3]

Ec Módulo de Young de la cuerda [N/m2]
Lc Longitud de la cuerda [m]
Ac Sección transversal de la cuerda [m2]
Ic Momento de inercia de la cuerda [m4]
D1c Coeficiente de disipación independiente de la frecuencia [kg/(m × s)]
D3c Coeficiente de disipación dependiente de la frecuencia [kg m/s]
Tsc Tensión de la cuerda [N]
Xac Posición del punto de observación [m]
Xec Posición del punto de excitación [m]
Mh Masa del martillo [kg]
αh Exponente de no linealidad del martillo [adimensional]
Kh Constante elástica de compresión del martillo [N/mα]
μh Constante viscoelástica del martillo [s/m]
ΔXeh Longitud de contacto entre cuerda y martillo [m]
fe2 Fuerza de contacto entre cuerda y martillo
N Número de armónicos por cuerda
FS Frecuencia de muestreo
TB Período de tiempo transcurrido entre bloques completos de muestras simuladas
M, N Número de muestras por bloque
P Polifonía (Número máximo de notas reproducidas simultáneamente)
PT Número total de notas del registro del instrumento
W Número de unidades funcionales del DSP
WE Promedio temporal del número de unidades funcionales del DSP utilizadas
C Capacidad de procesamiento del DSP en instrucciones por segundo
Cc Capacidad de procesamiento por cuerda en instrucciones por segundo
η Porcentaje de recursos destinado a la convolución y procesos no críticos
ξ Rendimiento en la optimización del código
Referencias
[1] V. Välimäki , T. Takala, Virtual musical instruments – natural sound using physical models, (1995)
[2] M. Karjalainen, T. Mäki-Patola, Physics-based modeling of musical instruments for interactive virtual
reality, (2004)
[3] J. O. Smith, A basic introduction to digital waveguide synthesis (for the technically inclined), (2005)
[4] J. O. Smith, Physical modeling synthesis update, (1996)
[5] N. Castagne, C. Cadoz, 10 criteria for evaluating physical modelling schemes for music creation, (2003)
[6] R. Rabenstein, L. Trautmann, Digital sound synthesis of string instruments with the functional
transformation method (2002)
[7] R. Rabenstein, L. Trautmann, Stable systems for nonlinear discrete sound synthesis with the functional
transformation method, (2002)
[8] S. Petrausch, R. Rabenstein, Sound synthesis by physical modeling using the functional transformation
method: efficient implementations with polyphase-filterbanks, (2003)
[9] Applied Acoustic Systems, Tech talk: Physical modeling, (2006)
[10] T. Akylas, C. Mei, Wave propagation, (2004)
[11] V. Välimäki, T. Tolonen, M. Karjalainen, Signal-dependent nonlinearities for physical models using
time-varying fractional delay filters, (1998)
[12] J. J. Burred Sendino, La acústica del piano, (1999)
[13] B. Bank, L. Sujbert, A piano model including longitudinal string vibrations, (2004)
[14] D. Howard, S. Rimell, CYMATIC: A tactile controlled physical modelling instrument, (2003)
[15] V. Välimäki, T. Tolonen, M. Karjalainen, Plucked-string synthesis algorithms with tension modulation
nonlinearity, (1999)
[16] B. Bank, Physics-Based Sound Synthesis of the Piano, (2000)
[17] M. Hirschkorn, S. Birkett, J. McPhee, Kinematic Model of a piano action mechanism, (2002)
[18] M. Hirschkorn, Dynamic model of a piano action mechanism, (2004)
[19] F. Avanzini, D. Rocchesso, Modeling collision sounds: non-linear contact force, (2001)
[20] A. Stulov, A simple grand piano hammer felt model, (1995)
[21] A. Stulov, Two nonlinear hysteretic models of piano hammer, (2001)
[22] F. Avanzini, B. Bank, G. Borin, G. De Poli, F. Fontana, D. Rocchesso, Musical instrument modeling:
the case of the piano, (2001)
[23] B. Bank, G. De Poli, L. Subjert, A multi-rate approach to instrument body modeling for real-time
syntesis applications, (2002)
[24] H. Lehtonen, Analysis and parametric synthesis of the piano sound, (2005)
[25] Applied Acoustics Systems, String Studio VS-1 - String Modeling Synthesizer, (2006)
[26] C. Bruyns, Sound synthesis and instrument design for computer music, (2005)
[27] Microsoft MSDN Library, Musical Instrument Digital Interface (MIDI), (2005)
[28] G. Frantz, R. Simar, Comparing fixed- and floating-point DSPs, (2004)
[29] FutureTech Research, MIPS/MFLOPS and CPU performance, (2006)
[30] Texas Instruments Inc., TMS320C6713, TMS320C6713B floating-point digital signal processors,
(2005)
[31] Spectrum Digital Inc., TMS320C6713 DSK technical reference, (2003)
[32] R. Chassaing, Digital signal processing and applications with the C6713 and C6416 DSK, Wiley
Interscience, (2005)
[33] Texas Instruments Inc., TMS320C621x/C671x DSP Two-level internal memory reference guide, (2004)
[34] Texas Instruments Inc., TMS320C6000 DSP cache user’s guide, (2003)
[35] Texas Instruments Inc., TLV320AIC23 Stereo audio CODEC data manual, (2001)
[36] N. Patavalis, A brief introduction to JTAG, (2001)
[37] Texas Instruments Inc., TMS320 DSP/BIOS User’s Guide, (2002)
[38] D. Keil, Real-Time data exchange, (1998)
[39] F. Miyara, Acústica y Sistemas de Sonido – 3º edición, UNR EDITORA, (2003)
[40] S. Wilson, WAVE PCM soundfile format, (2003)
[41] Roland Corporation, Roland RD-100 - MIDI Implementation, (1999)
[42] Texas Instruments Inc., DSP/BIOS driver developer's guide, (2002)
[43] Texas Instruments Inc., TMS320C67x FastRTS library programmer’s reference, (2002)
[44] Texas Instruments Inc., Code Composer Studio v2 help - Software pipelining, (2002)
[45] Texas Instruments Inc., Code Composer Studio v2 help - TMS320C67x pipeline overview, (2002)
[46] Texas Instruments Inc., TMS320C6000 CPU and instruction set reference guide, (2002)
[47] Corelis Inc., Boundary-Scan Tutorial, (2006)
[48] L. Trautmann, R. Rabenstein, Digital Sound Synthesis by Physical Modeling Using the Functional
Transformation Method, Kluwer Academic / Plenum Publishers, (2003)
[49] R. Welti, Introducción a la Física de las Ondas, UNR EDITORA, (1996)

Síntesis Digital de Sonido en Tiempo Real Por Modelado Físico de Instrumentos Virtuales de Cuerda Percutida

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Síntesis Digital de Sonido en Tiempo Real Por Modelado Físico de Instrumentos Virtuales de Cuerda Percutida

Uploaded by

Copyright:

Available Formats

Universidad Nacional de Rosario

Facultad de Ciencias Exactas, Ingeniería y Agrimensura

Síntesis digital de sonido en tiempo real por modelado

Autores: Nelly Lucrecia Villacorta,

Director: Ing. Federico Miyara

Síntesis digital de sonido en tiempo real por modelado

Autores: Nelly Villacorta, Carlos Marchiaro

Facultad de Ciencias Exactas, Ingeniería y Agrimensura – UNR – Rosario, Argentina

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 1

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 2

7.2. DESCRIPCIÓN DE LOS PROCESOS INVOLUCRADOS .................................................................................. 69

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 3

1. Estado del Arte y Fundamentos Teóricos

1.1. Tipos de sintetizadores en la actualidad

En la actualidad existen diferentes esquemas de síntesis de sonidos, que se clasifican de

FIGURA 1.1. Diferentes técnicas de síntesis digital de sonido

Se trata de técnicas que producen sonido basado en una determinada fórmula

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 4

ii. Procesamiento de Muestras Grabadas

Corresponden a esta categoría los llamados samplers, cuyo principio de

iii. Modelado Espectral

iv. Modelado Físico

1. Técnicas de dominio temporal

− Digital Waveguide (DWG)

Este método de “guía de onda digital” está basado en la solución de d’Alembert de la

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 5

línea de retardo) donde se requiera la determinación del valor de la onda, simplemente se

FIGURA 1.2. Composición de la onda

Un aspecto importante es que el efecto de las pérdidas distribuidas y la dispersión de

FIGURA 1.3. Modelo basado en DWG de un instrumento de

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 6

− Finite Difference Time Domain (FDTD)

En este caso se parte de una discretización directa de la ecuación de onda. Las

− Wave Digital Filter (WDF)

Este método se originó en la necesidad de simular el comportamiento de circuitos

Como su nombre lo indica, resulta de integrar los anteriores enfoques de forma de

2. Técnicas de descomposición modal

− Functional Transformation Method (FTM)

El método de transformación funcional [6] es un esquema introducido recientemente

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 7

El procedimiento general comienza con una discretización del modelo en tiempo

FIGURA 1.4. Procedimiento general de resolución basado en FTM – (Fuente [6])

1.2. Selección de un esquema de síntesis

1.2.1. Tendencia en la actualidad

Un análisis cronológico de la evolución de las técnicas de síntesis de sonido desde sus

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 8

A excepción quizás de los sintetizadores basados en algoritmos abstractos, todos los

FIGURA 1.5. Interfaz de control basada en

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 9

1.2.2. DWG vs. FTM

donde TC es la tensión de la cuerda, ρ es su densidad, A es su sección transversal y fe (x,t) es

Aquí E es el módulo de Young del material de la cuerda, I es el momento de inercia de la

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 10

FIGURA 1.6. Efecto de la dispersión en la propagación de onda

1.2.3. Selección final

Finalmente, considerando en forma global el estado actual de desarrollo en las áreas

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 11

2. Análisis del Modelo Físico

2.1. Modelo del resonador

Proyecto final de ingeniería - Facultad de Ciencias Exactas, Ingeniería y Agrimensura - UNR 12

siendo aquí μ la densidad lineal de la cuerda. Suponiendo que la velocidad de propagación de

FIGURA 2.1. Efecto no lineal de modulación frecuencial en la oscilación de una cuerda

2.2. Modelo del mecanismo de excitación