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


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


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



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].

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.

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



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.

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.

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.

FIGURA 1.3. Modelo basado en DWG de un instrumento de cuerda accionado por arco - (Fuente [3])

FIGURA 1.2. Composición de la onda resultante con DWG – (Fuente [3])



− 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.

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.

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



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).

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.

FIGURA 1.5. Interfaz de control basada en captación de movimiento – (Fuente [2])



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

2

2

2

txfx

yTt

yA eC =∂∂

−∂∂

ρ (1.1)

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

3

312

2

4

4

2

2

txfxtyd

tyd

xyT

xyEI

tyA eC =

∂∂∂

+∂∂

+∂∂

−∂∂

+∂∂

ρ (1.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.

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.

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



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]

μTs

Lf

21

= (2.1)



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).

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)

⎟⎟⎠

⎞⎜⎜⎝

⎛+≅ tsen

LY

LL máx ωπ 2

2

22

41' (2.2)

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

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



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.

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.

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.3. Detalle de la interacción entre el martillo y las cuerdas del piano – (Fuente [12])

FIGURA 2.2. Disposición de la cuerda y el martillo en el piano – (Fuente [12])



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)

αyKyF h Δ−=Δ )( (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).

⎟⎠⎞

⎜⎝⎛ Δ+Δ−=Δ y

dtdyKyF hh μα 1)( (2.4)

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.4. Mecanismo de excitación del piano – (Fuente [18])



La figura 2.6 muestra las curvas correspondientes al modelo adoptado para diferentes velocidades iniciales del martillo.

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

FIGURA 2.6. Característica Fuerza/Contracción del modelo del martillo adoptado – (Fuente [19])

FIGURA 2.5. Característica Fuerza/Contracción del martillo para tres notas del piano – (Fuente [12])



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]).

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])

FIGURA 2.7. Interacción de los componentes

del diagrama de bloques del modelo



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

3

312

2

4

4

2

2

txfxtyd

tyd

xyT

xyEI

tyA eC =

∂∂∂

+∂∂

+∂∂

−∂∂

+∂∂

ρ (1.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:

{ } 0)0,(

)0,(f i =

⎥⎥

⎦

⎤

⎢⎢

⎣

⎡

∂∂= x

ty

xyy (3.1)

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]:

{ } c, L x tx

xy

txyy 0 ; 0

),(

),(f

2

2b ==

⎥⎥

⎦

⎤

⎢⎢

⎣

⎡

∂∂= (3.2)

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:

{ } ∫∞ −==0

),(),(),( dtetxysxYtxyL st (3.3)

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:

{ } ∫==Lc

dxxsKsxYsYsxYT0

),,(),(),(),( μμ (3.4)

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 ),( sY μ , para luego arribar a la expresión de la función transferencia del sistema:

),(),(),(sF

sYsGe

eμ

μμ = (3.5)

donde ),( sF e μ 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]:

{ }{ }kTte

de sGLZzG =

−= ),(),( 1 μμ (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),(),(1 xsKsYN

sxYsYT μμμμ μ∑==− (3.7)

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

μ μνNμν

dxxsKxsK0 si

si 0),,(),,( νμ (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:

{ }

),()(),(1

)(),(),(

11

11

xKfzGN

fzGTzxH

ede

ede

d

μμμ

μμ

μ μ∑

∞

=

−

=

= (3.9)

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.2. Filtro IIR correspondiente a un armónico genérico

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†.

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.

FIGURA 3.1. Disposición en paralelo de filtros IIR – (Fuente [6])



( )

( )

⎟⎟⎠

⎞⎜⎜⎝

⎛⎟⎟⎠

⎞⎜⎜⎝

⎛Δ

⎟⎟⎠

⎞⎜⎜⎝

⎛ Δ

=

=

−=

=

c

a

c

e

c

e

c

e

T

sT

T

s

s

cc

s

Lx

senLx

sen

LxL

xsen

Na

ec

Tec

eT

TsenA

Tb

s

s

s

μπμπμπ

μπ

ω

ωω

ρ

μ

σ

μσ

σ

μ

μ

μ

μ

μ

2

21

cos2

1

20

1

1

(3.10)

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:

( )

( ) ( )

c

cccccc

c

cccc

cc

cc

c

L

Ad

Add

AT

Ad

AIE

ddA

LN

μπγ

ργ

ρργ

ρρω

γρ

σ

μ

μμμ

μμ

μ

=

⎥⎦

⎤⎢⎣

⎡−

⎥⎥⎦

⎤

⎢⎢⎣

⎡++

⎥⎥⎦

⎤

⎢⎢⎣

⎡−=

−−=

=

212

2314

2

23

12

3

222

21

2

(3.11)

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.

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:

( )

BxxA

xxxx

B

ydtdByAyKyF hh

21

21

21

22

21

22

22 1)(

−=

−

−=

⎟⎠⎞

⎜⎝⎛ Δ+Δ+Δ−=Δ

−

−−

α

αα

μ

(3.13)

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).

FIGURA 3.3. Almacenamiento alternado



( ) SS

FyyT

yyy

dtd

1212 Δ−Δ=

Δ−Δ≅Δ (3.14)

Se puede obtener una versión más simple si permutamos el orden de la diferenciación con

el de la diferencia:

vydtdy

dtd

Δ=⎟⎠⎞

⎜⎝⎛Δ=Δ (3.15)

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:

[ ] )()1()( kvFkykyv hScc −−−=Δ (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:

Shhh

Shhh

h

eh

TkvkykyTkakvkv

mkf

ka

)1()()1()()()1(

)()( 2

++=++=+

−=

(3.17)

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.



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.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



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

FIGURA 3.6. Esquema final de resolución



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.

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.

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 (xF: posición del puente sobre la cuerda) – (Fuente [48])



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.

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

FIGURA 4.1. Interacción de las partes principales del sistema



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.

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

Procesador

Operación en punto flotante

MIPS MFLOPS Procesa-miento

paralelo Códec Comunicación

con Host Precio (US$)

EVM320C6418 No 4000 - 8 unidades func. 32 bit 16 bit - Stereo Puerto USB 995,00

EVMDM642 No 5760 - 8 unidades func. 32 bit 16 bit - Stereo Puerto USB 1995,00

DSKC6713 Sí 1800 1350 8 unidades func. 32 bit 16 bit - Stereo Puerto USB 415,00 Te

xas

Inst

rum

ents

DSKC6416 No 5760 - 8 unidades func. 32 bit 16 bit - Stereo Puerto USB 515,00

DSP56311EVM No 270 - 24 x 24-bit MAC

Señales de voz Puerto USB 310,95

DSP56F826EVM No 40 - 24 x 24-bit MAC 16 bit - Stereo

Puerto paralelo

IEEE 1284 309,88

Free

scal

e (M

otor

ola)

DSP56307EVM No 100 - 24 x 24-bit MAC 16 bit - Stereo Puerto serie

RS-232 613,31



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.

* 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.

FIGURA 4.2. Equipos que integran el sistema



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:

%100N

N E=ξ (4.1)

donde EN 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:

%100WWE=ξ (4.2)



siendo aquí EW 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).

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.1. Elementos incluidos en el producto



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.

FIGURA 5.2. Diagrama de bloques del DSK C6713 – (Fuente [31])



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)

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

PF PFL PF PFL De salto Lógicas Manipulación

de bits Acceso a memoria

.M × ×

.L × × × ×

.S × × × × ×

.D × × NOTA: PF: Punto Fijo, PFL: Punto Flotante

FIGURA 5.3. Diagrama de bloques funcional del TMS320C6713 – (Fuente [30])



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.

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

FIGURA 5.4. Diagrama de bloques de la estructura de dos niveles de memoria interna – (Fuente [33])



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.

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.5. Modos de configuración de la caché L2 – (Fuente [33])



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.

FIGURA 5.6. Diagrama de bloques del códec TLV320AIC23 – (Fuente [35])



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.

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.

FIGURA 5.7. Distintas interfaces usadas por DSP/BIOS – (Fuente [37])



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.



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.

FIGURA 6.1. Diagrama de bloques de la aplicación host – Modalidad de edición



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.



− 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:

cc

c

c AT

Lf

ρ21

0 = (6.1)

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

FIGURA 6.2. Interpolación lineal de parámetros físicos entre puntos de configuración sucesivos



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:

∑−

=

=1

0

2 )(1 M

kef ky

MY (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



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.

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.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

FIGURA 6.4. Diagrama de bloques de la aplicación host – Modalidad de control



− 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 - Sustain BnH 42H ccH

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. − Funciones auxiliares

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.



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

FIGURA 6.5. Interfaz audiovisual de usuario de la modalidad de control



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



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.3. Conjunto de coeficientes transformados para el total de las cuerdas



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

FIGURA 7.4. Subconjunto de coeficientes y variables para la simulación de las cuerdas (sección crítica)



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.

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.

FIGURA 7.5. Entrada/Salida independiente del dispositivo en DSP/BIOS – (fuente [37])



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

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

FIGURA 7.6. Flujo de paquetes llenos y vacíos – (fuente [37])



− 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

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



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.

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

FIGURA 7.8. Diagrama de flujo del algoritmo de manejo de la excitación



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. − 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.

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:

3

23

2

22

1

γγ

γγ

τ

τ

τ

τ

τ

τ

==⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛=

+−

+−

−

−

+−

+−

Tt

Tt

T

T

Tt

Tt

Ke

Ke

e

e

Ke

Ke (7.1)

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):

FIGURA 7.9. Curva de atenuación exponencial escalonada



τττ

τ

τ

γγ TTtTt

Tt

Tt

eeKe

Ke===

++

+−

+−

+− 2

22

1 (7.2)

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.



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,

FIGURA 7.10. Diagrama de flujo de la tarea de comunicación



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.

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

FIGURA 7.11. Diagrama de flujo de la tarea de simulació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:

∑+∞

−∞=

−=∗=k

knhkxnhnxny )()()()()( (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.



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.

FIGURA 7.12. Almacenamiento alternado de las muestras simuladas x(k)



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.



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

FIGURA 7.13. (a) – Fases del pipeline en punto flotante; (b) – Flujo de la ejecución del pipeline en punto flotante – (fuente [45])



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.



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.14. Gráfico de dependencia del paso de integración PAR



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.

FIGURA 7.15. Gráfico de dependencia del paso de integración IMPAR



U 0 3 6 9 12 15 18 21 24 27 .D1 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW .D2 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 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 .M1 MPYSP MPYSP MPYSP .M2 MPYSP MPYSP MPYSP .L1 ADDSP .L2 ADDSP .S1 B B .S2 1X MPYSP MPYSP MPYSP 2X 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 .M2 MPYSP MPYSP 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

U 0 3 6 9 12 15 18 21 24 27 .D1 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW .D2 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 .M2 MPYSP MPYSP MPYSP .L1 ADDSP .L2 ADDSP .S1 B B .S2 1X MPYSP MPYSP MPYSP 2X 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 .M2 MPYSP MPYSP 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



− 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).

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

FIGURA 7.18. Ejecución en sentido horizontal (por muestras) vs. vertical (por cuerdas)



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



− 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

U 0 1 2 3 4 5 6 7 8 9 .D1 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW .D2 LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW LDDW .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



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.

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%

FIGURA 7.21. Uso de recursos de CPU vs. polifonía



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.2. Ejemplo 2 – Nota C2 – Formas de onda antes (curva negra) y después de la convolución (curva gris)

FIGURA 8.1. Ejemplo 1 – Nota E2 – Formas de onda antes (curva negra) y después de la convolución (curva gris)



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

FIGURA 8.3. Ejemplo 3 – Nota G#2 – Formas de onda antes (curva negra) y después de la convolución (curva gris)



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í.

* Se entiende aquí por distancia a la diferencia entre los valores centrales de frecuencia de cada componente espectral.

Ejemplo 1 - Nota E2 - Tabla armónica 1 (80 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]

Ejemplo 1 - Nota E2 - Señal sin convolucionar (80 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]


-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]

FIGURA 8.4. Ejemplo 1 – Análisis espectral – Resolución de la FFT: N = 4096 puntos



Ejemplo 2 - Nota C2 - Tabla armónica 1 (80 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]

Ejemplo 2 - Nota C2 - Señal sin convolucionar (80 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]

Ejemplo 2 - Nota C2 - Tabla armónica 1 (200 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]




Ejemplo 3 - Nota G#2 - Tabla armónica 1 (80 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]

Ejemplo 3 - Nota G#2 - Señal sin convolucionar (80 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]

Ejemplo 3 - Nota G#2 - Tabla armónica 1 (200 armónicos)

-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]




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.


-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]


-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]


-140

-120

-100

-80

-60

-40

-20

0

0.0E+00 4.0E+03 8.0E+03 1.2E+04 1.6E+04 2.0E+04 f [Hz]

FFT

[dB

]




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.

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

0

2

4

6

8

10

12

0 30 60 90 120 150 180 210 240 270

Latencia [ms]

Frec

uenc

ia

FIGURA 8.8. Análisis de la latencia – Histograma de frecuencias



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 α ≅ Α x m + B x n (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. xxg ∀≥ ;0)( iv. ;32 ≤≤ α v. máxXx ≤ ;

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



FIGURA A.1. Función potencial aproximada con valores negativos

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.

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 :

( )( )

⎪⎩

⎪⎨⎧

=+

=+

⎪⎩

⎪⎨⎧

=+=

=+=

−

−

22

22

21

21

24

22

22

14

12

11

α

α

α

α

xBxA

xBxA

xBxAxxg

xBxAxxg

(A.5)

Luego, el problema se reduce a resolver el sistema:

⎟⎟⎠

⎞⎜⎜⎝

⎛=⎟⎟

⎠

⎞⎜⎜⎝

⎛⎟⎟⎠

⎞⎜⎜⎝

⎛−

−

22

21

22

21

11

α

α

xx

BA

xx (A.6)

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



⎪⎩

⎪⎨

⎧

−=

−

−=

−

−−

BxxA

xxxx

B

21

21

21

22

21

22

α

αα

(A.7)

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; x1 = 1mm; x2 = 2mm


α = 2.5; x1 = 1mm; x2 = 2mm




α = 3; x1 = 1mm; x2 = 2mm


α = 1.5; x1 = 1mm; x2 = 2mm



FIGURA B.1. Función de suavizado

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).

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:

( ) ( )( ) ( )( ) ( )( ) ( )⎪

⎪⎩

⎪⎪⎨

⎧

′=′′=′

==

22

11

22

11

tftgtftg

tftgtftg

(B.1)

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):

( ) DCtBtAttg +++= 23 (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):

( ) CBtAttg ++=′ 23 2 (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:

( ) ( )[ ]

( )⎪⎪⎪

⎩

⎪⎪⎪

⎨

⎧

−−′=

−′+−+=

′==

CATyT

B

CyTyDCTT

A

yCyD

22

223

1

1

321

21 (B.4)



FIGURA B.2. Curva original y suavizada – t1 = 2; t2 = 8; y1 = 4; y2 = 5; y1’= 1; y2’= π/6.

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.



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 --------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 *CICLO #7 --------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 *CICLO #8 --------------------------------------------------------------------- MPYSP .M2X B14,A15,B5 ;Multiplica W-2*c0 -> S2 *CICLO #9 --------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 *CICLO #10 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 *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 -------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 *CICLO #13 --------------------------------------------------------------------



LDW .D1 *A8++[8],A10 ;Lee de memoria b1 *CICLO #14 -------------------------------------------------------------------- LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || 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 #15 -------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #16 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 *CICLO #17 -------------------------------------------------------------------- LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || 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 #18 -------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #19 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 || 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 || 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 #21 -------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #22 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || [A1] B .S1 BUCLE_IMPAR ;Salto a BUCLE_IMPAR (si cont2 > 0) *CICLO #23 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || 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 #24 -------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *------------------------------------------------------------------------------ * Comienzo del bucle principal



*------------------------------------------------------------------------------ BUCLE_IMPAR: *CICLO #25 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || 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 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || 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 #27 -------------------------------------------------------------------- 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 || MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W || [A1] SUB .S1 A1,1,A1 ;Decrementa cont2 (si cont2 > 0) *------------------------------------------------------------------------------ * Final del bucle principal *------------------------------------------------------------------------------ *CICLO #28 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #29 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || 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 #30 -------------------------------------------------------------------- MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #31 -------------------------------------------------------------------- LDW .D1 *A8++[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #32 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || 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 #33 -------------------------------------------------------------------- MPYSP .M1X A14,B15,A12 ;Multiplica W-1*c1 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #34 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK



|| ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #35 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #36 -------------------------------------------------------------------- ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #37 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #38 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #39 -------------------------------------------------------------------- ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #40 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #41 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W || LDDW .D2 *B8++[4],B11:B10 ;Lee de memoria aL y aR *CICLO #42 -------------------------------------------------------------------- ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #43 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #44 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W *====== 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 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK



|| MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *====== 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 -------------------------------------------------------------------- STW .D1 A9,*A0++[8] ;Escribe en memoria W *====== 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 || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *====== 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 -------------------------------------------------------------------- ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *------------------------------------------------------------------------------ * 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[11],B0 ;Cargo 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[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 --------------------------------------------------------------------- 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 *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 --------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 *CICLO #7 --------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 *CICLO #8 --------------------------------------------------------------------- MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 *CICLO #9 --------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1



*CICLO #10 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 *CICLO #11 -------------------------------------------------------------------- MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #12 -------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 *CICLO #13 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 *CICLO #14 -------------------------------------------------------------------- LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #15 -------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #16 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 *CICLO #17 -------------------------------------------------------------------- LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #18 -------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #19 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 || 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 || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #21 -------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #22 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || [A1] B .S1 BUCLE_PAR ;Salto a BUCLE_IMPAR (si cont2 > 0)



*CICLO #23 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #24 -------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *------------------------------------------------------------------------------ * Comienzo del bucle principal *------------------------------------------------------------------------------ BUCLE_PAR: *CICLO #25 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR || [A1] B .S1 BUCLE_PAR ;Salto a BUCLE_IMPAR (si cont2 > 0) *CICLO #26 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #27 -------------------------------------------------------------------- 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 || MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W || [A1] SUB .S1 A1,1,A1 ;Decrementa cont2 (si cont2 > 0) *------------------------------------------------------------------------------ * Final del bucle principal *------------------------------------------------------------------------------ *CICLO #28 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #29 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #30 -------------------------------------------------------------------- MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #31 -------------------------------------------------------------------- LDW .D1 *--A8[8],A10 ;Lee de memoria b1 || MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #32 --------------------------------------------------------------------



STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || MPYSP .M2 B14,B15,B5 ;Multiplica W-1*c1 -> S2 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #33 -------------------------------------------------------------------- MPYSP .M1 A14,A15,A12 ;Multiplica W-2*c0 -> S1 || ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #34 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #35 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #36 -------------------------------------------------------------------- ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #37 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #38 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR || MPYSP .M1 A11,A10,A13 ;Multiplica Fe2*b1 -> S3 || ADDSP .L1X A12,B5,A5 ;Suma S1+S2 -> S12 *CICLO #39 -------------------------------------------------------------------- ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #40 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #41 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W || LDDW .D2 *--B8[4],B11:B10 ;Lee de memoria aL y aR *CICLO #42 -------------------------------------------------------------------- ADDSP .L1 A13,A5,A9 ;Suma S3+S12 -> W *CICLO #43 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *CICLO #44 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W *====== 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 -------------------------------------------------------------------- MPYSP .M1X A9,B10,A2 ;Multiplica W*aL -> YLK || MPYSP .M2X A9,B11,B9 ;Multiplica W*aR -> YRK || ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *====== 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 -------------------------------------------------------------------- STW .D1 A9,*--A0[8] ;Escribe en memoria W *====== 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[5],B11 ;Cargo Yc(k-1) en B11 *CICLO #49 -------------------------------------------------------------------- ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *====== 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 -------------------------------------------------------------------- ADDSP .L1 A7,A2,A7 ;Acumula YL+YLK -> YL || ADDSP .L2 B7,B9,B7 ;Acumula YR+YRK -> YR *------------------------------------------------------------------------------ * 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 ---------------------------------------------------------------------



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) *CICLO #2 --------------------------------------------------------------------- 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) *CICLO #3 --------------------------------------------------------------------- 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) *CICLO #4 --------------------------------------------------------------------- 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) || [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0) *CICLO #5 --------------------------------------------------------------------- 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) || 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) || [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0) *CICLO #6 --------------------------------------------------------------------- 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) || 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) || [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0) *CICLO #7 --------------------------------------------------------------------- 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) || 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) || [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0) *CICLO #8 --------------------------------------------------------------------- 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) || 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) || [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0) *------------------------------------------------------------------------------ * Comienzo del bucle principal *------------------------------------------------------------------------------ BUCLE: *CICLO #9 --------------------------------------------------------------------- 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) || 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) || 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) || [A1] B .S2 BUCLE ;Salto a BUCLE (si cont1 > 0) *------------------------------------------------------------------------------ * Final del bucle principal *------------------------------------------------------------------------------ *CICLO #10 -------------------------------------------------------------------- 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) || ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1



*CICLO #11 -------------------------------------------------------------------- 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) || ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #12 -------------------------------------------------------------------- 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) || ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #13 -------------------------------------------------------------------- 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) || ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #14 -------------------------------------------------------------------- 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) || ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #15 -------------------------------------------------------------------- ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #16 -------------------------------------------------------------------- ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #17 -------------------------------------------------------------------- ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *CICLO #18 -------------------------------------------------------------------- ADDSP .L1 A9,A7,A9 ;Acumula S1 + S1k -> S1 || ADDSP .L2 B9,B7,B9 ;Acumula S1 + S1k -> S1 *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.

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.

FIGURA D.1. Notas correspondientes a las teclas del piano. Se muestran sólo tres octavas del registro



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

EW 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)

Documents

Síntesis digital de sonido en tiempo real por modelado físico de instrumentos virtuales de cuerda percutida