=dblog=

Encore une traduction d’un article de Mstation, ce coup ci c’est un interview de Steve Harris à propos des plugins LADSPA.
L’URL de l’original est : http://mstation.org/steve_harris_ladspa.php

Steve Harris à propos des plugins LADSPA.

Il y a quelques temps, la communauté Linux audio s’activait à porter le format des plugins VST de Cubase.
Pour différentes raisons cela na pas abouti, par contre, LADSPA etait né, grâce à Richard Furse et quelques autres de la liste de diffusion ‘Linux Audio Developers’.
Parmi les developpeurs de plugins LADSPA, Steve Harris à été le plus prolifique, nous allons engager la conversation avec lui sur LADSPA et la création de plugins.

liens :
La homepage de Steve Harris
plugin.org.uk - Une collection de plugins GPL
Doc. plugin de Steve Harris
www.ladspa.org … l’API etc.
Jack
XMMS supporte LADSPA
La liste de diffusion ‘Linux Audio Dev’
D’autres liens LADSPA sur la page de Dave Phillip

Mstation : Est ce qu’un évenement particulier t’a ammené à Linux, ou bien est ce que tu t’en est approché par curiosité ?

Steve Harris : En fait, à l’époque ou Linux commenca à être utilisable (en 94), je faisait du hacking
sur SunOS et les machines Amiga, donc la transtion à été trés pragmatique, Amiga étant en fin vie, et les machines Sparc sont simplement trop couteuses.

Je regrette certaines chose de l’Amiga, c’etait bien d’avoir un hardware consistant, et les processeurs 68000 sont plus simples à comprendre que les x86.
D’un autre coté, les machines x86 sont vraiment financierement interessantes compte tenu de la puissance de calcul qu’elles offrent.

L’idée de faire communiquer pleins d’applis entre elles est interessante a plus d’un niveau, y compris pour la réutilisation de code. Pouvez vous nous dire ce qu’est en substance LADSPA ?

[aucun rapport avec la communication entre applications]

Ok, c’est un peu fantaisiste - mais j’aime bien le concept, quand même.

Jack fait un excellent travail pour l’interconnexion entre applis. C’est la seule approche simple, à faible latence pour Linux.
La conception est similaire au ‘Core Audio’ d’Apple, en conséquence, le portage d’applis OSX vers jack devrait être assez facile.

LADSPA est un format de plugin DSP. La conception est simpliste (dans le bon sens du terme), et facile à étudier. Lorsque j’ai commencé à écrire des plugins LADSPA, je n’avais jamais écris de plugin, cependant j’avais codé des logiciels audio (mais pas temps réel).

La courbe d’apprentissage est trés douce, beaucoup plus simple qu’avec VST, par exemple.

Les entrées-sorties LADSPA se font au travers de ‘ports’. Il y a des ports de données audio (un buffer d’échantillons), et les ports de données de contrôle (un unique échantillon).
Les données de contrôle sont envoyées à un débit variable, en variant la taille des buffers.
Toutes les entrées-sorties d’un plugin LADSPA sont en 32 bit flottant.

Est-ce que LADSPA est largement accepté ?

Oui, je pense que la plupart des applis audio Linnux sérieuses travaillent sur le support LADSPA.
Il s’avére facile à intégrer dans les applications (et plateformes), cela dit j’ai jamais essayé.
Même XMMS supporte LADSPA (http://www.ecs.soton.ac.uk/~njl98r/code/ladspa/)

Son status actuel pose t’il des problémes ?

Pas de vrais problèmes. La lacune la plus évidente est le manque de valeurs par défaut pour
les ports de contrôle : quand un environnement crée l’interface graphique, il ne sait pas
comment positionner les valeurs.
Cela dit c’est en cours, la prochaine version standard devrait corriger ce probléme.

Un autre souci lié, et qui est partiellement réglé est le cas de l’IHM. Pour certains plugins, un hôte ne peut pas génerer automatiquement une interface graphique correcte : le filtre Hermes par exemple, dispose de 30 ports de contrôle, et il n’y a aucune indication sur le placement des potards sur l’écran.
Il existe une proposition de standard (LCP), et j’ai crée quelques démos d’IHM avec GTK, mais pour l’instant aucun environnement ne le supporte réelement, c’est un peu le problème de la poule et l’oeuf je trouve.

Enfin, il y un problème commun à tous les systèmes de plugin : la classification des plugins.
On peut les classer par ordre alphabétique, par identifiant unique, mais ni l’un ni l’autre n’est satisfaisant.
Imagine que tu a quatres compresseurs, tu voudrais bien les grouper, et les mettre a côté des expandeurs, gates, etc.

J’ai bien une solution potentielle, mais je dois faire un prototype avant de la proposer, et c’est un peu complexe.

Est ce que cela joue sur l’ordre de calcul ? Imagine le cas ou …

Ah, j’ai pas été clair, je parlais uniquement du placement sur l’interface graphique, pas de
l’ordre de traitement.

on souhaite mette le delay aprés la distortion, plutot que l’inverse (ce qui devrait sonner différemment), pouvez vous faire cela ?

En fait delay et distortion sont orthogonaux, l’ordre de traitement ne change rien, a moins d’avoir un feedback trés court sur le delai.

oui. je pensait à deux appareils distinct, normalement il ne le sont pas.

Pour quelqu’un qui voudrait se mettre à écrire des plugins, par quoi commencer ?

Je pense que à la base il faut connaître l’API, des connaissances en C, enfin il faut acquérir des connaissances en algorithmique pour réaliser ce qu’il veulent.

L’API d’un plugin est très simple, en fait j’écris mes plugins dans un dialecte XML, cela élimine tout le bazard lié aux réglages d’initialisation, ca revient a remplir des cases vides.

Je dirais qu’une expérience du C, des compétences en maths et de bonnes oreilles sont les seuls véritables prérequis. Certaines implémentations utilisent des concepts mathématiques vraiement balèzes, d’autres peuvent être simplistes.

Ce que je trouve vraiment dur, c’est d’implementer des choses dont je ne me sers pas. Par exemple, j’utilise peu les compresseurs, ca m’est donc très difficile de corriger un compresseur, puisque je ne sais pas que qui fait un bon comresseur.

C’est un cas particulier, parceque les gens l’utilisent de différentes façons. Dans certains styles on veut les entendre, dans d’autres il sont carrément bannis !
Je suppose que certains veulent amortir les pics et augmenter le niveau apparent sans devoir trop modifier la balance.

Effectivement, faire des tests comparatifs d’un compresseur transparent c’est facile, mais dès qu’il est question de gôuts et couleurs ca devient compliqué.

Les effets mathématiquement définis sont les plus simples, tu peux faire des test, bidouiller le code et voir bouger des indicateurs dans tous les sens. Mais au bout d’une heure ou deux, tu risque de vraiment détester un morceau de musique que vous adorez.

Voudriez vous nous guider pour un example de plugin simple ?

Bien sûr, j’ai commencé un tutorial, mais je ne l’ai pas terminé.
Je vais en présenter un extrait.

La distribution source contient un script perl qui produit du code C à partir du document XML.

Example de plugin LADSPA :

	
<?xml version="1.0″?>
<!DOCTYPE ladspa SYSTEM “ladspa-swh.dtd"> Définition de la syntaxe XML de ladspa. 
	
<?xml-stylesheet href="ladspa.css” type="text/css"?>
C’est la feuille de style pour le document XML, elle permet un affichage lisible avec Mozilla et IE6.
	
<ladspa>   Définit des choses globalement, pour tous les plugins du document XML.
…
etc
…
unsigned long pos;
for (pos = 0; pos < sample_count; pos++) {
	buffer_write(output[pos], input[pos] * gain);
/* buffer_write est une macro qui copie des échantillons vers le tampon (buffer) de sortie.
Dans notre cas c’est équivalent à output[pos] = input[pos] * gain.
Mais ca pourrait faire d’autres traitements. */
} ]]>
</callback>  
	
<port label="input” dir="input” type="audio">
Déclaration d’un port audio d’entrée, appelé input,
<name>Input</name> et un nom plus descriptif.
</port>  
	
<port label="output” dir="output” type="audio">
Devine ce que c’est 
<name>Output</name>
</port>  
	
<port label="gain” dir="input” type="control">
Déclaration d’une entrée de controle, appelée gain, avec une plage de 0 à 10.
<name>Gain</name>
<range min="0″ max="10″/>
</port>  
	
</plugin>
</ladspa>
	

C’est vraiment trés élégant … voyons si j’ai bien compris.
Le script perl va prendre la ligne 27 (

“gain” est à la fois une variable dans le code C, et un élement de la structure plugin. Le programme hôte écrit les valeurs du paramètre dans la variable de plugin gain, ce qui la rends disponible pour le plugin.

Les valeurs des ports sont fixées pour la durée de l’appel run(), mais elle peuvent changer entre deux appels.
Des fois, entre les appels, il faut mettre en cache certaines opérations mathématiques, et refaire le calcul que si les valeurs des ports ont changés.

Cela nous méne en douceur à l’intérieur de l’architecture d’un plugin. Est-ce que LADSPA est
essentiellement une liste de paramétres audio avec des plages de valeurs autorisées ?

En fait, c’est une liste de ports, chaqu’un pouvant être soit controle (une seule valeur) soit audio (un tampon), et quelques plages recommandées. On peut tout a fait mettre n’importe quelle valeur dans un port LADSPA, auquel cas on a aucune garantie sur la sortie !

Reprenons votre exemple - vous devez créer un plugin d’amplification (!). Comment va on s’y prendre ?

Bon, c’est un exemple top simple pour être interessant, mais je commencerai par refléchir aux types de ports ncessaires (dans ce cas, une entrée audio, une sortie audio, et un controle pour le gain).
Il faut simplement écrire le code DSP (Traitement de signal numérique) pour relier le tout. (ie : out = in * gain

Dans un cas plus compliqué, dés que j’ai l’idée ou la suggestion, je devrai me renseigner sur l’effet (google, livres sur le traitement de signal), trouver des informations sur la partie mathématique, ensuite je peux commencer par écrire des programmes C d’amusement pour voir comment ca sonne.

Dès que j’ai une solution logicielle qui marche je la transforme en plugin LADSPA, c’est aussi le moment de l’optimiser pour obtenir de meilleurs tempos de traitement. J’ai une version modifiée de appplyplugin qui résoud le problème des 0dB et calcul le nombre de cycles processeur pour le traitement d’un échantillon.

Ajuster le code peut être trés long, Ajuster, écouter, ajuster, écouter - y a t’il des tests objectifs à faire en priorité ?

Pour certain plugin le résultat est décrit mathématiquement, donc on peut automatiser les tests, mais je passe le plus de temps à corriger à l’oreille. Malheuresement il y a souvent des combinaisons de valeurs particuliéres que j’oublie, j’ai besoin des retours de bugs d’utilisateurs qui remarque des problémes de qualité sonore.

Je n’avait pas pensé à faire des plugins plus complexe, j’imagine que c’est un bon test des capacités de recherche et programmation.
Premiérement, identifier les composants sonores nécessaires, ensuite se mettre à coder. Sachant que certains sons sont le resultat d’accidents que le gens ont apprécié puis reproduit. Avez vous déja crée un plugin uniquement depuis votre imagination ?

Généralement ils sont inspirés de vrais trucs, ou de patches de synthétiseurs que j’aurai fait.
On ne pars pas vraiment de rien, les plugins sont (conceptuellemnt) un assemblage de filtres, delais et tout le reste, et c’est seulement la façon de brancher ensemble ces composants qui vont faire un plugin particulier.

Peut être qu’on peut récapituler tout ca en disant (pour les adeptes du C), “lire l’API, se renseigner sur l’effet, Coder !”
Je pense que c’est ca !

Yep, c’est a peu près ca.

Merci Steve.