WordPress database error: [Incorrect file format 'wp_comments'] SELECT comment_author, comment_author_url, comment_ID, comment_post_ID FROM wp_comments WHERE comment_approved = '1' ORDER BY comment_date_gmt DESC LIMIT 10
If you ever wrote at least 2 audio plugins in your life, for sure you have noticed you had to write a lot of duplicated code. In other words, most of the times, writing a plugin there is very little entropy from your code.
Now i’m with a simple but i think powerful project (derived from the needs i noticed at club de audio de la fiuba) to have an application to generate code of different standards using XML based specifications. Then, as before, you nearly only need to write the signal processing code of the plugin (and can forget about the mechanical work).
The idea is to get VST, LADSPA, lv2, CLAM, Audio Units and possibly others standards base code ready to compile for different operating systems and using different build systems. Indeed, once finished, will be easy to implement new modules for others plugins specifications since will consist only into implement an interface.
My proposed xml specification (comments and suggestions are welcome!), showed as a clam plugin definition example is here. Basically contains metadata, input and output ports and controls and other build definitions:
< ?xml version="1.0"encoding="UTF-8"?>< !DOCTYPE AudioPlugin SYSTEM "AudioPluginDef.dtd"><audiopluginVersion="0.1"><metadata><name>TestRtPlugin</name><description>This is a test realtime audio plugin</description><authors>Fulano, Sultano, Mengano</authors><copyrightYear="2010">Club de Audio FIUBA</copyright><license>GPL</license><category>Plugins</category></metadata><inputs><portName="L Input">AudioInPort</port><portName="R Input">AudioInPort</port><controlName="Gain"Min="0."Max="1.0"DefaultValue=".5">InControlFloat</control></inputs><outputs><portName="L Output">AudioOutPort</port><portName="R Output">AudioOutPort</port></outputs><outputpluginStandard="CLAM"BuildSystem="Scons"OS="Linux"><basetemplatename>Default</basetemplatename><clam_defaultconfig><!-- CLAM plugin specific configuration --><baseclass>Processing</baseclass><withconfig>True</withconfig></clam_defaultconfig></outputplugin></audioplugin>
I also thought about an UID (Uniqued ID) field at metadata, there is not showed in the example since is not needed to clam plugins.
There is also a .dtd file to check the correctness of the plugin spec.
(Note: I wrote this as something to tell to the clam-devel mailing list about some of my source-code commits)
About eight months ago, there was a foundation of something like an “audio club” in my university [1]. As soon i learned about that, i quickly got in touch with them and noticed that there was a major interest in analog issues (the only audio area with at least elective, courses in the university). So i told them about all the cool things that are available and ready to do with digital audio, mostly signal processing related. I talked in general, but of course i also talked about clam, with all its prototyping, real-time and easy development of plugins features. Even many of them ended installing and using it, and some even developing with more or less help. One thing to notice is that most of them are students from first years and most (but not all) are students with a basic programming level (because they are from electronics) but strong dsp knowledge (behind this is an university with more emphasis in theory than practice)
We started specifying plugins from a more abstract level (inputs/outputs/controls) and generating the source code base using CLAM’s Templated Plugins Code Generator [2] and prototyping some simple applications. But one of the things we ended up doing was to take advantage of clam as platform to prototype medic related applications like filter ECG signal from noise in realtime, and some like _vice-versa_, i mean applying some processing knowledge from that area to audio.
Last week, at the recent ‘audio club’ of my university, I was showing how to work with the CLAM framework as a tool to prototype realtime audio signal processing applications in a simple and fast way.
We started with an example network to show some about the NetworkEditor capabilities: karaoke.clamnetwork
After that, we continue with a simple ‘diodo distortion’ plugin:
We specified and generated the source code base in this way:
Ayer estuve mostrando un poco de como usar el framework CLAM para prototipar aplicaciones de procesamiento en tiempo real de audio de forma rápida y sencilla.
Empezamos con una red de ejemplo para mostrar un poco el NetworkEditor: karaoke.clamnetwork
Luego seguimos con el plugin “distorsión de diodo”.
Recently I been playing with python bindings for the CLAM library. Here is a demo demonstrating how to interactively build a network and play a file using the IPython shell:
Hace bastante tiempo que tenia archivada esta conversación sobre síntesis por FM y Horgand que quería publicar.
Qué es Horgand? un sintetizador por soft capaz de realizar sonidos de órgano y otros tipos de sonido como pianos eléctricos (Rhodes , Wurlitzer, DX E.Piano ), Jazz Guitar, Strings, Brass, Fretless Bass, Accordion etc. Esta basado en síntesis por FM, según su web:
“Is based on a FM audio synthesizer with twenty carriers (20) without modulators in a plain based algorithm.
each carrier frequency can be modified for construct complex sounds. The synthesizer incorporate also a LFO (Low frequency oscillator) for generate tremolo effects and detune effects applying LFO Pitch and Amplitude to the carrier frequency’s. Some synthesizer parameters can be edited for each sound including two ADSR, (Normal and Percussion), Fine Frequency, Attenuation, Rotary Amplitude, Transpose, etc. Four DSP effects are available for obtain more complex sounds, Rotary, Chorus, Delay and Reverberation. Sounds are stored in banks of 32 organ sounds and can be changed externally with MIDI program change (1-32).”
También incorpora reconocimiento de acordes para producir acompañamiento automático (bajo y bateria) y con líneas de bajo editables para cada ritmo.
No conozco mucho de síntesis por FM y tenía curiosidad de como lograba el sonido y terminó saliendo una especie de entrevista improvisada, creo que puede ser interesante para quienes quieran adentrarse en este tipo de programación.
La conversación:
—
<hordia> despues me tenes que contar en que te basaste para conseguir el sonido de horgand digitalmente…
<holborn> pues en el DX7 …. tiene 32 algoritmos de colocacion de los operadores … pero si usas el plano (todos en linea)… todo lo que hagas suena a organo … a partir de ahi … pues añadirle los efectos … y claro en vez de 6 “osciladores” hay 10 … que en realidad son 20 … con lo cual pues es mas rico que un emulador de dx7 tipo hexter o en el dx7 mismo … en realidad .. para usar 20 osciladores no chupa CPU nada … otros porgramas usan 3 y ch
<holborn> claro que para ahorrar cpu .. tuve que limitar algunos parametros de edicion … pero bueno … yo lo que queria era que sonara … si nadie se pone a editar sonidos … ni dios vaya …
<hordia> que es el DX7? me suena a un teclado legendario pero no estoy seguro…
<holborn> el DX7 fue el primer sintetizador FM … es de yamaha .. y fue una revolucion porque era el primero que mas o menos imitaba bien sonidos reales … algunos mejor que otros …
<holborn> los vendieron todos y mas …
<holborn> yo realmente era un experto … en aquella epoca ni dios sabia nada de musica electronica … yo me hice un curso que daba un loco de la musica electronica .. y sabia programar sintes cosa que nadie sabia .. te estoy hablando de hace mil años …
<holborn> cuando salio el DX7 pues me tuve que empapar toda la info porque realmente es muy diferente a un sinte analogico tradicional … y bueno .. le pedi a un amigo que trabajaba en un distribuidor de yamaha .. que me consiguiera info de verdad … de hecho todavia la conservo ..por ahi ..
<hordia> :O
<holborn> yo llegue a trabajar programando sintes en un estudio de grabacion …. vaya no todos los dias pero me llamaban de vez en cuando
<holborn> haciendo presets … me refiero .. claro
<hordia> veo que horgand es el resultado de muchos años de experiencia…
<holborn> si … a ese nivel si … pero todo fue gracias a un ejemplo de la web de alsa .. .se llama fmminisynth.c … o lago asi … 100 lineas de codigo … entonces se me ocurrio … y empece ..
<holborn> luego buscando … encuentras mil ejemplos de codigo … en HArmony Central … no esta el codigo pero explican como funcionan los efectos … en cristiano .. sin mucha matematica … esta muy bien .. luego ya el implementarlo es cosa de uno … pero el mismo Paul Nasca dice por ahi (el del zyn) que se basa en esa explicaciones … y yo tambien claro
<holborn> ya te aseguro que su implementacion es mejor que la mia
<hordia> jeje
<holborn> ahora …la mia consume un tercio de cpu que la suya
<hordia> entonces hay que ver que parametros se toman para definir cual es mejor
<holborn> pues es un sinte … lo que suena … sus efectos suenan mejor …. pero … el usa 3 o 4 osciladores por sonido … yo uso 20 … con lo cual en algun lado hay que recortar …
—
After prototype different kind of simple distortions in NetworkEditor i managed to port all them to ladspa plugins. Despite the fact that the task was less difficult than i had expected at first, prototype with CLAM first worth a lot. Probably, if i had begun coding directly to ladspa source, reach the same status would be taken to me 10 or more times more. I think also was very interesting as “development process”, instead of modeling for example with matlab, you could easy modeling (among other things) in CLAM, and then, if you want/need make your final product by your own.
More, the other day i learned that is already possible to compile ladspa plugins directly from CLAM networks… very cool! Though i think this feature is not completely ready yet and i’m still have to dig in it, i don’t think that i have lost time porting manually because now i have a better knowledge and understanding about ladspa specification that for sure will be useful to work with this (for me “new”) feature, that probably needs some fixes.
About the ladspa plugins programming, i just downloaded the sdk from ladspa.org, read some of the ladspa.h file and some basic examples (the ones from sdk) and that was enough to handle the basis. Ah, i had to ask for some ladspa ID’s for my plugins here: ladspa at muse.demon.co.uk
A week or more ago, Daniel Vidal Chornet (collaborator of Musix) asked me if i can develop guitar distortion effects, because he couldn’t find something decent that suits his needs, i said “sadly i have no idea about distortions effects and anyway i have no time right now to do that”, but then i remembered how useful could be the clam framework and i tried to do a little spike about. Results were better than i had expected at first (is not a super cool distortion, but at least sound like one).
Basically i merged and tweaked a couple of simple/base algorithms found in the web for distortion and compression and in less than 30 minutes i had something working and sounds like a guitar distortion (”clean” ones seems to sound better easily). I was amazed how fast and easy (develop and test in clam/networkeditor, once you get the basis) was. I think right now is far to be a good distortion, but as learning process and first demo seems very good.
Some optional tweaks could include add a three band filter but i’m still not sure if it’s better to put it at first or at the end.
Special thanks for testing and audio samples to Daniel Vidal Chornet. I should take from my closet my fender stratocaster and do my own samples . OTOH, we already arrange to do a remote gig with this.
Another useful NetworkEditor processings plugins i had made during this “work”:
AutomaticGainControl: Adaptative automatic gain control. Given an output reference and step response adjusts the output volume to keep it constant (AutomaticGainControl.tar.gz)
AudioSwitch: Switchs between a configurable amount of inputs (like a multiplexer) (AudioSwitch.tar.gz)
Hoy vi el video demostración de TAPESTREA: Techniques And Paradigms for Expressive Synthesis, Transformation, and Rendering of Environmental Audio (también conocido como taps). Intenta ser un entorno para el diseño de sonido, pero desde un enfoque totalmente nuevo (lo mejor es ver el video para entender mejor de que se trata).
Me llamó la antención (además de la división del sonido entre sus componentes sinusoidales, transitorios y residuo), la interfaz gráfica intuitiva y sencilla y la manipulacíón de sonidos en el espectrograma.
Según su web, la idea es ser un framework unificado para analizar de forma interactiva sonidos complejos, transformarlos y sintetizarlos:
Identificar puntos de interés en el sonido y extraerlos para crear “templates” (una muestra/un sample) reusables
Transformar componentes de sonido de forma independiente a su entorno y otros eventos sonoros
Resintetizar continuamente las texturas de fondo de una forma perceptualmente convincente
Posicionamiento de eventos “templatizados” sobre la escena de fondo por medio de una novedosa interfaz de usuario o scripts escritos en Chuck (un lenguaje de programación orientado al audio)
Recuperación de componentes de sonidos basandose en la similaridad con otros.
TAPESTREA otorga una nueva forma de transformar dinámicamente una escena de sonido, permite generar puestas de cualquier duración, facilita la composición y el diseño de sonido combinando elementos de diferentes grabaciones de forma muy sencilla y ofreciendo miles de variantes para su manipulación (solo pensar en las posiblidades que otorga el solo hecho de poder manejar por separado sinusoides, transitorio y residuo).
Sin duda, una herramienta de trabajo interesante tanto para “diseñadores de sonido” como invesitigadores del audio, compositores y cualquier persona interesada en experimentar con el sonido.