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.
Desde hace bastantes (meses? años?) que tengo ganas de ver los partidos de river pero con el relato de Atilio Costa Febre (que va vía radio AM[1]), pero nunca podía hacerlo de una forma satisfactoria ya que la transmisión de la tele siempre estaba retrasada unos cuantos segundos (gritaban gol en la radio y uno veia la pelota por la mitad de la cancha, insoportable).
También hace bastante que se me habia ocurrido la simple solución de retrasar la transmisión de radio unos segundos con la computadora hasta que se sincronizara todo. El tema es que los plugins de audio clásicos, están pensados para hacer música y generalmente soportan muy pocos segundos de delay (por ejemplo el delay común de los LADSPA), asi que dije bueno, lo armo en CLAM y sale con fritas… Pero no habia delay temporal disponible (sí uno espectral), asi que lo tuve que programar, sino en 5 minutos tenia todo listo.
El resto, armar la red de conexiones con el NetworkEditor[2], la interfaz[3] con el QtDesigner, y listo el prototipo dominguero:
Aparte de todo el poderio y posiblidades que tiene CLAM, como me gusta que también sirva para salir del paso y resolver estos pequeños problemas…
[1] Dado que ahora están en radio mitre y esta transmite por internet, hasta se puede prescindir de una radio externa y usar el streaming por ejemplo con mplayer que soporta jack como backend, lo que permite conectar su salida a la entrada de la red del NetworkEditor fácilmente. El comando:
mplayer -cache 32 mms://streammitre.uigc.net/mitrevivo -ao jack
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:
Este post surge dado que recientemente redescubrí la radio de last.fm. Principalmente gracias a que me bajé el programa que proveen ellos (btw, multiplaforma y Software Libre). Digo que redescubrí porque antes la usaba desde el amarok, cosa que esta bien, ya que uno centraliza todo ahi, pero este programita tiene algunas cosas piolas y en algunas situaciones es mucho más cómodo de usar, sobre todo para cambiar de radios, por artistas o tags, etc y encima te tira algo de data (parecido a lo que tiene el amarok que busca en wikipedia, nada más que “propiedad” de last.fm). Pero lo que me hizo “engancharme” es el tema de poner un artista que me guste y que me empiece a tirar temas con la misma onda, cosa que me hace conocer canciones e interpretes nuevos. ¿Por qué cuento esto? Por que desencadeno en que comience a usar seguido el botón de “Love”/”Favorito” de la aplicación, que es una forma de decirle a last.fm que ese tema te gusta y que lo tenga en cuenta para volverlo a pasar en el futuro o para (supongo) que tengan más probabilidad de aparecer temas similares (si no te gusta para nada, también se puede “bannear”). Bueno, todo esto viene dado que de tanto presionar “love” (y descubrir/redescubrir varios artistas, sobre todo en blues y jazz) queria tener una forma de acceder a todo eso (nombre del tema + interprete). El programa en cuestión muestra una lista de las canciones recientemente maracadas como favoritas, pero no permite copy&paste y tampoco vía web hay forma de acceder a esa información, como si pasa con otras cosas, por ejemplo las canciones recientemente escuchadas… (con la nueva versión del sitio si se puede: Last.fm: The Next Generation)
Bueno, buscando un poco di con la API (versión 2.0), al parecer reciente, pero sin la capacidad de “recuperar” las últimas loved songs… asi que me remití a la versión 1.0 que si lo permite y además se puede usar sin api key. Entonces lo que hice fue armarme un script en python que descargara las últimas canciones “favoritas” y las vaya guardando en un xml (o .txt), es decir a medida que aparecen nuevas, las agrega y elimina los duplicados…
Tip: si uno quiere estar seguro de no perderse ninguna canción, dado que las “canciones favoritas recientes” son solo 10, puede poner este script a correr en cron… (si es que va marcar muchas canciones como favoritas, pero a lo sumo y con mucha suerte uno marca como “loved” una por hora y la frecuencia por supuesto tiende bajar)
Ya que estaba jugando con la api, hice otro script para descargarme todo el historial de escucha (otra “feature” que no vi disponible vía web, pero por suerte con un poco de “hacking” se puede hacer con la API):
No se para que me puede servir, pero es info mía y ya que la tiene otra persona, al menos me gusta poder tenerla yo
Otras aplicaciones
Ya que escribo sobre last.fm aprovecho para comentar un par de “nuevos usos” que se me ocurrieron de este tipo de sistemas, ambos se aplican a un player haciendo scrobbling en una fiesta/reunión:
Con esto se tiene automáticamente trackeada y publicada la lista de canciones que se escucharon. ¿Cuantas veces uno quiere saber como se llama esa canción que le gustó el día anterior para poder volverla a escucharla?
Si uno no quiere estar eligiendo música, pero quiere asegurarse que va a escuchar algo de su agrado, puede poner su radio personalizada y listo… “satisfacción garantizada” . Esta feature ahora es paga, pero dado que cualquier usuario puede escuchar la radio del otro… no es difícil imaginarse como se puede salvaguardar este punto… de todas formas, la suscripción no es cara, alrededor de 3 euros por mes (creo).
Hace un tiempo, se contactó conmigo una persona que me pidió si lo podía poner en contacto con gente que pudiese llegar a interesarse en construir un instrumento de teclado temperado según el sistema Mercator o escala temperada que tenga los conocimiento necesarios como para llevarlo a cabo (la idea era/es armar un mini-grupo de trabajo).
Básicamente:
“La propuesta del presente trabajo es construir un instrumento musical de teclado temperado según la convergente (53 / 31) (ver: Federico Miyara: “La música de las esferas: de Pitágoras a Xenakis… y más acá“). Este temperamento parece adjudicado al célebre matemático Mercator. Del libro “Acústica musical y organología”, Tirso de Olazábal, Editorial Ricordi Americana, 1977, extraigo el siguiente fragmento:”El intento más ingenioso ha sido realizado por el famoso matemático Gerardo Mercator, que propuso en el siglo XVI un sistema basado sobre una sucesión de 53 quintas, que origina una coma pequeñísima; este sistema, llamado a veces “sistema de los 53 grados”, permite obtener quintas y terceras mayores casi perfectas. En el siglo pasado fueron construidos dos órganos con 53 teclas por octava, templados según el sistema de Mercator, pero no tuvieron éxito debido a su enorme dificultad de ejecución.” Para simplificar, llamaré a este sistema “sistema Mercator”, “temperamento Mercator” o “escala Mercator”. Básicamente este temperamento consiste en dividir la octava en 53 “microtonos” iguales entre sí, y usar estos microtonos para obtener los tonos y semitonos de la escala natural con una gran aproximación” (sigue)
Por mi parte, en este momento no cuento con mucho tiempo libre debido al trabajo, facultad y otros proyectos, pero me ofrecí a ayudarlo en lo que pudiera y tratar de ponerlo en contacto con gente a la que le pudiera interesar la idea. Ese es uno de los objetivos de este post, darle difusión. Con la misma idea, lo envié al grupo Buena Señal (ver detalles más abajo).
Un par de observaciones que se me ocurren/puedo hacer sin profundizar demasiado en el tema:
Se me ocurren 2 caminos básicos. Samplear algún instrumento en cada frecuencia base requerida y luego asignarlos a las notas adecuadas o generar sonidos sintéticos teniendo en cuenta las mismas frecuencias calculadas.
En cuanto a los sonidos sintetizados (generados por computadora) hay que tener también en cuenta los armónicos de cada nota (porque como todos sabrán los instrumentos tienen un timbre particular y no se componen solo de una frecuencia “pura” sino de una frecuencia fundamental y armónicos que son frecuencias múltiplos de la primera con diferentes amplitudes)
En cuanto a la parte “física”, por ejemplo se podrían recibir los mensajes convencionales de cualquier teclado MIDI y por medio de este soft específico reproducir las frecuencias adecuadas a la escala elegida.
Como dije antes, también envié la propuesta al grupo Buena Señal, aca les dejo algunas buenas ideas que aportaron:
Por ejemplo, crackerpardo comentó: “Che me gusto la idea, ahora entre la facultad y el trabajo ando algo corto de tiempo como para ayudar bastante pero me parece que podríamos usar ZynAddSubFX, si mal no recuerdo con la síntesis aditiva tenés hasta 64 armónicos con control individual de amplitud y fase por voz, ajustes de tono en ±10 cents (nota: todavia no lei ninguno de los papers adjuntados); también para darle algo mas de realismo se le puede poner un LFO a alguno de los parámetros para hacerlos algo aleatorios o un filtro pasabajo dependiente de la nota para preservar el espectro (eso sería más importante si el sonido fuera sampleado). Bueno, a ver que les parece. Saludos”
Por otra parte, Victor Suarez opinó: “Propongo utilizar un teclado común que mande las notas en MIDI, hacer un plugin VST o similar que capture las notas (eventos midi), y que traduzca los eventos de manera que se altere la frecuencia. Lo que habria que hacer es utilizar el comando “pitch bend“, lo que permite “desafinar” la nota en curso. El efecto es el equivalente a estirar una cuerda en una guitarra. Algunos teclados vienen con una ruedita en la esquina superior izquierda para lograrlo. Aca tiene algo sobre el tema de comandos midi, si bien pobremente documentado, pero pueden conseguir mejor info revolviendo la web: MIDI commands”
Y Juan Vuletich dijo: “Hola! Yo creo que lo mejor es tomar un vstiopen source, como buffersynth2 o Syntopia y agregarles la funcionalidad para elegir la escala, y hacer que usen las frecuencias correctas, no? Suena como algo que se podria hacer en 1 semana. (Si uno tuviera una semana libre, por supuesto!) El proyecto es super interesante. Pero no me animo a ofrecerme como voluntario por falta de tiempo…”
Bueno, eso es todo por ahora…
voluntarios? ideas? comentarios? interesados? (pueden dejar un comentario o comunicarse a través del formulario del blog y los pongo en contacto con Luis Enrique Schiller)
, CLAM 
