Framework AP-Gen

AP-GenFramework generador de esqueletos de plugins de audio a partir de

abstracciones y templates

Hernán Ordiales<[email protected]>

Consultor IndependienteEstudiante de Ingeniería en la Universidad de Buenos Aires, Argentina.

Septiembre, 2010

2do Congreso Internacional de Acústica UNTREF 2010

http://h.ordia.com.ar

mailto:Hernan Ordiales <[email protected]>

AP-GenFramework for audio plugins skeletons generation from abstractions and

templates

Hernán Ordiales<[email protected]>

Independant ConsultantEngineering Student at Universidad de Buenos Aires, Argentina.

September, 2010


http://h.ordia.com.ar

mailto:Hernan Ordiales <[email protected]>

Resumen

Contexto: Arquitectura de plugins de audio.I Posee numerosas ventajas.I Pero también presenta numerosas dificultades en el desarrollo.

AP-Gen:I ¿Qué es? Un framework. Un marco de trabajo.I ¿Para que sirve? Permite llegar rápida y fácilmente al momento de

implementar el procesamiento del audio (DSP).I ¿Cómo? Usando abstracciones (del plugin) y templates (de los

estándares).


Arquitectura de plugins

Modelo con dos tipos de actores:

I Host: aplicación principal capaz de comunicarse con uno o máselementos modulares de software a través de una interfaz definida.

I Plugins: Elementos de software de funcionalidad específica querespetan una determinada interfaz y una serie de convenciones.

Estándares: Definen como se deben construir los hosts y los plugins paraque sean compatibles entre si.


Ventajas

I Permite a terceros (individuos o empresas) extender una aplicación.I Ya sea para simplificar el programa principal, o como una forma de

agregar capacidades no previstas originalmente.I Permite desarrollar unidades de procesamiento específicas. Que hagan

solo una cosa y bien.I Su naturaleza modular, permite concatenar plugins formando redes o

cadenas de procesamiento, logrando asi funcionalidades complejas apartir de unidades simples y dedicadas.


Estándares de plugins de audio más populares

I Estándares: VST, AU, RTAS, LADSPA, lv2.I ¿Cuáles puede soportar AP-Gen? Cualquiera, se basa en templates.I ¿Para que sistema operativo? Cualquiera, idem.


Secuencia típica de desarrollo

1 (opcional) Prototipar el algoritmo en otra plataforma (ej: Matlab).2 Elegir un estándar de plugins según las necesidades o requerimientos.3 Seleccionar herramientas de trabajo. Librerias, compilador, IDE, etc.4 Crear archivos siguiendo convenciones y requerimientos del estándar

elegido.• Construir clases o estructuras. Escribir defines, constantes, etc.• Respetar convenciones de nombres, por ejemplo para variables ométodos.• Agregar cuestiones particulares del plugin en cuestión a laestructura general, como ser cantidad y nombre de entradas y salidasde flujos de señal de audio y controles.

5 Crear y configurar sistema de construcción según el SO elegido.6 Escribir función de procesamiento e interacción con los controles.


Problemática del desarrollo de plugins de audio

Cuestiones detectadas:

I Necesidad de contar con profundidad de conocimiento en 2 áreas deespecialización separadas:• Conocimiento teórico sobre procesamiento de señales en tiempodiscreto.• Desarrollo de software.

I Dificultad en el comienzo de los procesos de desarrollo, muchas veces,terminando en abandono.

I Mucho código parecido entre plugins (información redundante).I Predominio de librerias en C y C++ (por cuestiones de performance).I Sistemas de construcción poco intuitivos (en general).


Dificultades en el desarrollo

Para principiantes:I Escasa o mala

documentación.I Dificultades de

compilación asociadas acada arquitectura.

Para avanzados:I Muchas tareas repetitivas.I Cantidad de detalles y

formas que requiere cadaarquitectura.

I El camino directo lleva aun acoplamiento noconveniente entre lalógica general y laarquitectura.


Consecuencia principal (en todos los casos)

Pasa demasiado tiempo antes de que uno puedaconcentrarse en la implementación de la función deprocesamiento.

Es decir, lo que generalmente más nos importa de unplugin.


Algunas herramientas existentes que ayudan en el procesode desarrollo

I CLAM: C++ Library for Audio and Music.I FAUST: varios backends.I Librerias que simplifican el manejo de los estándares.I Wrappers (envoltorios) para otros lenguajes.I Otras.

¿Hacen lo mismo que AP-Gen? No. AP-Gen tiene un enfoque diferentepara la misma problemática.


Objetivos buscados en la solución propuesta

I Desacoplar las características de alto nivel de los plugins, de losdetalles de implementación de cada estándar.Y de configuraciones particulares de los sistemas de construcción para cadaSO.

I Evitar todo el trabajo mecánico posible.Evitar prácticas del tipo basarse en otro código y abusar del ’buscar yreemplazar ’ o el ’copiar y pegar ’.

I Poder generar código base o esqueletos para diferentes estándares.I Crear y proponer estructuras comunes y convenciones en base a

prácticas recomendadas.I Soportar diferentes sistemas operativos, de forma tal que el código

compile desde el inicio.


Análisis del plugin

1 Pensar en un modelo abstracto.2 Definir su ’entropía’ o información pura.


Modelo común de un plugin de audio

I Flujos de señal:entrada/salida.

I Controles: entrada/salida.I Propiedades.


Entropía del plugin

Eliminación de redundancias.Información pura que luego se pueda expandir a código de cualquierarquitectura.

I Abstracciones generales de estructura:Tipo de entradas y salidas de datos y controles.

I Algoritmos de procesamiento y control.I Propiedades internas.I Nombre del estándar y sistema operativo destino.


Entropía del plugin

Si interesa expandir la entropía a código listo para compilar de cualquierestándar.

I ¿Por qué no guardar de forma independiente toda la entropía posible?I ¿Por qué no guardarla de forma ordenada? Por ejemplo en un archivo

XML.I Excepto los algoritmos de procesamiento y control, el resto se puede

almacenar clara y facilmente.


¿Cómo generar el código automáticamente?

I Ya pensamos el plugin en forma abstracta.I Ya lo definimos en sus elementos de información de pura (no

redundante).I Falta generar el código automáticamente para cada arquitectura.

¿Cómo? Por ejemplo usando un motor de templates.

¿Y qué vendrian a ser los templates? Los elementos que conservan lascaracterísticas comunes de cada estándar.


Motor de templates

I Entrada 1: Archivos .XML condefiniciones.

I Entrada 2: Archivos de template(VST, LADSPA, etc).

I Salida: Código base o esqueleto delplugin.


Ok, ya definí todo y pasé por el motor. ¿Y ahora?

Como se puede leer en una parte de la documentación del proyecto Django:

“Tomarse 5 minutos para maravillarse detodo el código que no se tuvo que escribir”


Secuencia de desarrollo propuesta

1 Crear un archivo XML con un editor de texto plano o por medio deuna interfaz gráfica.

2 Generar el esqueleto del plugin pasando el XML por el motor detemplates (aplicación de AP-Gen).

3 Implementar la entropía faltante del plugin.• Función de procesamiento.• Interacción con controles.• Ajustar detalles menores según el estándar elegido.


Archivo XML con definicionesMetadata: Datos que definena los datos.

Plugin de salida. Elección detemplate.

· Sistema de construcción.· Sistema Operativo.· Configuraciones específicasde cada estándar.


Un ejemplo viejo: CLAM ProcessingCodeGenerator

I Ejemplo de mixer.I 2 entradas y una salida

mono.I 1 control.


Ejemplo de función de procesamiento

I Ejemplo de código para elDo() de un processing deCLAM.

I Aparte de las definicionesen el XML, trabajando deesta forma, es el únicocódigo que hay queescribir.

I Distorsión muy simple,tipo clipping.


Ventajas de trabajar en la forma propuesta

I Ahorra tiempo. Permite que el programador se pueda concentrarrápidamente en el desarrollo de la función que efectua elprocesamiento (DSP).

I Provee una estructura favorable para el desarrollo comercial deplugins multiplataforma .Permite diferentes salidas a partir de la misma definición.

I Simplifica la tarea de portar código de un plugin ya codificado a unestándar diferente.

I Propone buenas prácticas de desarrollo que se traducen en mejoresresultados (abstracciones, desacoplamiento del código, estructura generaltemplatizada, desarrollo incremental y convenciones).


Ventajas de trabajar en la forma propuesta

I Facilita el desarrollo para la distribución de algoritmos ya prototipadosen Matlab R© o similar, como plugins compatibles con cualquierprograma host.

I Posee soporte modular y extensible para las diferentes arquitecturasde plugins.

I Evita que el desarrollador tenga que ocuparse del sistema deconstrucción.

I Fines educativos. Sirve como referencia introductoria para conocer undeterminado estándar.


Conclusiones

I Se logró proponer una nueva forma de trabajo.Esta implementación esta escrita en Python, pero lo que importa es laidea de trabajo.

I No se considera un enfoque mejor ni peor, sino distinto.I Lo más importante, es pensar en el plugin como una estructura

abstracta, desacoplada de la implementación.I ¿Cuándo usarlo? Dependerá de los objetivos y requerimientos.

Asi como de los tiempos y el background del desarrollador.


Trabajo futuro

I Darle más difusión al proyecto.I Implementar nuevos módulos, soporte para nuevos estándares de

plugins.I Templates generativos para wrappers u otros lenguajes.I Conectar el estándar de definiciones XML propuesto con el rdf de lv2.I ¿Integrarlo a algún IDE?


¿Dónde conseguirlo?

AP-Gen se puede descargar de http://code.google.com/p/ap-gen/ yse distribuye como Software Libre bajo licencia GPL.

La cual entre otras cosas permite:I Usarlo con cualquier propósito.I Estudiar cómo esta construido y adaptarlo a las propias necesidades.I Hacer y distribuir copias.I Realizar mejoras y redistribuir las versiones mejoradas.


http://code.google.com/p/ap-gen/

Fin

¿Preguntas?


Fin

Gracias por venir!


Framework AP-Gen

Technology

Transcript of Framework AP-Gen