jzu

Aller au contenu | Aller au menu | Aller à la recherche

Bitcoin, ah ah ah ! Ahem.


Tout va bien

L'existence du Bitcoin (BTC, ฿) a été révélée au grand public par la faillite de Mt.Gox, l'un des principaux exchanges permettant d'échanger des Bitcoins contre des dollars US et inversement. Le taux ayant baissé à $450 au lieu du record de $1000 en novembre dernier, d'aucuns ont annoncé la fin de cette monnaie en oubliant un peu vite qu'elle ne valait que quelques dollars naguère.

Il ne s'agit bien sûr que d'une péripétie où une sorte de banque met la clef sous la porte, pas d'un Armageddon généralisé pour le monde des cryptodevises. Celles-ci ont de très bonnes raisons de perdurer car elles jouent pour l'Internet le rôle d'un moyen de paiement en voie de disparition, l'argent liquide.

Bitcoin procède d'une idéologie libertarianiste qui vise à ôter le plus possible de pouvoir économique aux états en faisant frapper monnaie par des réseaux P2P sur lesquels n'importe qui peut miner avec son propre ordinateur, et à rendre l'argent à nouveau anonyme pour limiter les possibilités de contrôle de son utilisation. Son caractère spéculatif colle bien à cette idéologie où la prise de risque financier mérite une récompense sans limite. Toujours dans le but de favoriser la spéculation, le Bitcoin est déflationniste, le nombre d'unités étant volontaimement limité à 21 millions ; ce chiffre sera atteint vers 2140.

Tout va mal

C'est là que les choses se compliquent. J'ai parlé de cryptodevises, au pluriel. Les clones de Bitcoin se multiplient. Certains se veulent de réels concurrents comme Litecoin (LTC) ou Primecoin (XPC). D'autres sont de simples gags, comme Fellatio (BLO), dont l'un d'eux, Dogecoin (DOGE), a accédé par surprise au rang de monnaie cotée. Sur 600 créées, il en existe aujourd'hui 400 en activité dont une quinzaine peuvent être échangées contre des BTC à des taux variant entre 0,02 et 0,001. L'antériorité de Bitcoin lui apporte la reconnaissance médiatique, d'où sa valorisation. Cela ne durera qu'un temps.

Le code, l'implémentation des algorithmes faisant fonctionner ces monnaies virtuelles, est presque toujours dérivé de celui de Bitcoin, qui est naturellement open source. Naturellement parce qu'en matière de cryptographie, le code doit pouvoir être revu et contrôlé afin de valider son fonctionnement. Pour un clone, il vaut mieux partir d'une base solide et n'en changer que le strict minimum afin d'éviter tout risque de baisse du niveau de la sécurité et donc de la confiance.

On voit que les cryptodevises qui ne font pas trop n'importe quoi à ce niveau sont équivalentes dans l'absolu. Parmi celles-ci, certaines vont se dégager du lot, surtout pour des raisons marketing, ou peut-être parce qu'une valeur ajoutée (un peu plus sexy que de trouver des sextuplets de nombres premiers) y sera associée. En conséquence, le nombre d'équivalents-BTC se multipliera, le principe déflationniste volera en éclats et les cryptodevises s'effondreront.

Et après ?

Nombreux seront ceux qui trouveront cela dommage. Ceux pour qui le Bitcoin représente une victoire dans leur combat idéologique. Ceux qui auront stocké des Bitcoins. Ceux qui montent actuellement des datacenters bourrés d'ASIC dédiés au mining en Islande ou en Suède. Ceux qui transfèrent internationalement de l'argent à peu de frais. Ceux qui ont besoin d'acheter ou de vendre discrètement de la drogue ou des armes et, en général, tous ceux pour qui le principe du cash virtuel est réellement pratique, tellement qu'il ne peut pas totalement disparaître.

Les monnaies traditionnelles sont toujours garanties par un ou des états qui en contrôlent le volume émis et qui s'engagent à les racheter au besoin. C'est une des bases de la confiance qui établit leur valeur faciale et qui permet au public de les utiliser au jour le jour.

A contrario, c'est le code implémentant les algorithmes et gérant la communication qui garantit la valeur faciale des monnaies cryptographiques, mais on vient de voir que cette seule garantie n'était pas suffisante. Il faut un facteur extérieur équivalent à l'autorité des états. Or ceux-ci ne sont pas prêts à lancer leurs propres monnaies virtuelles, comme le montre le récent communiqué de la Banque de France, alors que d'autres acteurs se préparent sûrement à se placer dans les starting-blocks.

Google, eBay, Facebook, Yahoo... Le poids économique de ces entités commerciales dépasse de loin celui de nombreux pays fondés à battre monnaie. Pourquoi hésiteraient-elles à conforter leur pouvoir ? Le moment venu, elles s'appuieront sur leur puissance financière pour garantir chacune leur propre moyen de paiement. Celui-ci serait toujours virtuel, toujours fondé sur des algorithmes cryptographiques, et il pourrait même rester décentralisé et P2P. La compagnie lui fournirait un petit quelque chose en plus, peut-être inhérent au code mais pas forcément, comportant en tout cas un éventail d'actions destinées à inspirer confiance comme l'achat massif de devises afin de soutenir le cours : rien que de très classique dans ce domaine.

Cet accaparement de la monnaie par des sociétés commerciales représentera la dernière étape du processus actuel de discrédit des états, qui crée un vide où s'engouffrent les acteurs privés. Le libertarianisme nourri des préceptes d'Ayn Rand vise à détruire l'État, vu comme le mal absolu, au profit de l'individu ; mais en fait seuls quelques-uns des individus en profiteront réellement et les vraies gagnantes seront les corporations.

Gnome 3

Non mais c'est juste pas possible. Qu'est-ce qui leur a pris, à cette bande de cons ? Gnome 2 n'était peut-être pas parfait mais le pékin lambda voulant utiliser une machine sous Linux s'y retrouvait sans problème, bien que l'environnement ne ressemble ni à Windows ni à MacOS. Une certaine logique donnait à l'utilisateur un accès facile aux tâches courantes tout en lui laissant la possibilité d'aller plus loin en cas de besoin.

Tout a changé avec Gnome 3. On ne peut plus créer de lanceur sur le bureau pour y lancer une appli, et en fait le clic droit ne fait plus rien nulle part, on ne peut pas déplacer les barres de statut, et ainsi de suite. La liste des régressions est longue ainsi que celle des fonctionnalités sans intérêt ; elles procèdent clairement d'une volonté d'abêtir l'interface, probablement pour la faire coller à un hypothétique « grand public » décérébré par TF1. À côté, Windows Seven devient un rêve d'ergonomie. À quoi ressemblera Gnome 4 ? À Microsoft Bob ?

Je ne demande pas grand-chose à un environnement de bureau : accéder aux ressources dont j'ai besoin en faisant clicka-clicka. Je peux facilement me passer du drag and drop et de l'automount, pas de la sélection des hotspots wifi ou de la gestion des écrans.

On peut quand même créer des icônes dans la barre de statut du haut en y glissant un item de menu. Mais, oups, j'en crée une de trop...Que faire ? Pas de menu contextuel pour la supprimer. Non, là, c'est trop.

Unity

Le portable étant sous Ubuntu, je passe à Unity : ça ne peut pas être pire. Ça ne l'est pas, en effet, et c'est même assez utilisable. Je tiens quelques jours et puis ce dock stupide me court vraiment trop sur le haricot : il faut trouver autre chose. Pas KDE, que je ne hais point (je sais qu'il fait le boulot) mais que je n'aime pas non plus

Xfce

À ce portable est souvent raccordé un deuxième écran. Gnome et Unity s'en débrouillent sans problème tant que le window manager sous-jacent est Metacity et non Compiz, horriblement buggé sur ce point depuis quelques mois. Pas Xfce, que ce soit avec son outil ou celui de Gnome ; aucun n'accepte de dé-cloner les écrans. C'est dommage car le compromis ergonomie/fonctionnalité/consommation des ressources est très bon, vraiment l'option à retenir quand on veut s'éloigner des sentiers battus et surtout des bloatwares actuels. Et quand on n'a qu'un seul écran. Tant pis.

LXDE et autres WM

Impossible de s'arrêter en si mauvais chemin. Au tour de LXDE, encore mieux dans un genre épuré ; il faut dire qu'il s'agit moins d'un environnement de bureau que d'un simple window manager auquel se greffe lxpanel, dérivé de fbpanel, une barre placée en bas de l'écran contenant des petites applets de base (menu, charge machine, etc,), le tout très léger. Mais... mais... mais il ne gère pas plus le double écran que Xfce, ni d'ailleurs les WM comme Sawfish (mon favori même s'il n'est maintenu que sporadiquement, c'est historique) ou Openbox. Enlightenment non plus. De toute manière, ce dernier ne m'intéresse plus depuis longtemps et E17 n'y changera rien.

À quelque chose malheur est bon, j'ai découvert fbpanel qui reste maintenant à demeure sur mon Sawfish à la maison.

KDE

Non.

Non, vraiment. Pas plus que les "tiling WM" à la Ratpoison ou Awesome, pour des raisons différentes mais toutes en rapport avec les goûts et les couleurs.

La boucle est bouclée

Au cours de mes pérégrinations sur divers forums, blogs et lidies, je découvre qu'il existe bien un moyen d'accéder aux menus contextuels de Gnome.

Alt-clic droit.

Sans rire. Pas clic droit, non, ce serait trop simple. Ces développeurs sont complètement cinglés. Ou bien ils se droguent et je pose alors la question : est-ce qu'il leur en reste ? Mais ça me suffit pour repasser sous Gnome en espérant qu'un des environnements testés consente à prendre en compte un deuxième écran... ou qu'arrive un jour une version de Gnome un peu meilleure, bref qu'existe un vrai choix d'environnements de bureau répondant à mes desiderata, entre KDE, Gnome et Xfce. On peut rêver.

Slampler, suite

Suite, mais pas fin, des aventures du Slampler !

Slampler monté - cc by-nc-sa

L'intégration du joystick au pédalier est terminée. L'ajout des pièces de tuyauterie en PVC, pour loger les interfaces, lui donne un petit air d'arme secrète soviétique. Déco à prévoir en conséquence.

Slampler monté - cc by-nc-sa

Le circuit imprimé du joystick n'était pas totalement détruit après ies premiers tests. Il restait 6 contacts opérationnels... juste assez pour y brancher tous les switchs. La leçon en est qu'il ne faut pas souder sur les pistes, qui se décollent, mais sur les points de soudure existants.

Composants du slampler - cc by-nc-sa

L'ensemble des composants a un peu de mal à rentrer, surtout à cause du long câble USB du joypad. Avantage, rien ne bouge à l'intérieur. Inconvénient, la place est maintenant terriblement comptée alors que j'envisage de remplacer l'atroce dongle C-sound par une interface Behringer UCA-202. Il faudra probablement déplier et insérer le câble à l'intérieur du tuyau des switchs pour gagner de la place.

Slampler assemblé - cc by-nc-sa

Le NSLU2 ne dispose que de 28 MiB de RAM. Combien de samples, de quelle longueur, peut-on loger ? En y stockant des samples mono sur deux octets à 44100 Hz, cela donne 88200 octets par seconde et 10 MiB permettent de loger 113 secondes, soit, pour 15 samples, 7 secondes en moyenne par sample.

Je dois largement dépasser cette taille car il y a parfois des trous dans la reproduction audio, probablement parce que le programme swappe un peu (4 MiB en swap après exécution) et que l'écriture est coûteuse sur une clef USB. Et puis il n'y a pas de secret, il faut réduire la taille des samples. La durée totale de mes samples actuels étant de 141 secondes, cela représente dans les 12 MiB en interne; il faudrait donc descendre à 8 MiB soit dans les 90 secondes. FAUX ! CF. infra. J'aurais aussi pu conserver les samples sur disque et les lire à la volée, ce qui serait concevable en n'en lisant qu'un seul à la fois, mais je voulais pouvoir en lire plusieurs en même temps.

Code du slampler en mode debug - cc by-nc-sa

Cela signifie aussi qu'il faut vraiment tuer les démons comme hald et udevd pour gagner quelques MiB en mémoire. Il ne sera alors plus possible de monter automatiquement une clef USB supplémentaire contenant les répertoires 0/, 1/ et 2/ allant se mettre par dessus ceux d'origine de /data, mais qu'elle ne peut être prise en compte qu'au boot.

Pour l'instant, on reste sur un déclenchement simple où le sample ne s'arrête pas avant la fin. Le choix se fera à la prochaine répétition... en janvier. Si cela change, l'architecture devrait aussi changer pour lire les samples directement depuis le disque puisqu'il sera alors assez difficile d'en déclencher plusieurs en gardant le pied appuyé...

Edit La situation est plus grave que ça. J'ai été intrigué par un core dump de 30 MiB. En me connectant en ssh au Slug pendant que ./slampler tournait, la commande top donne cette taille dans la colonne VIRT (mémoire virtuelle). Bref, le programme swappe à mort. Solutions :

  • Réduire encore plus drastiquement la taille des samples (mais c'est pas drôle) ;
  • Réduire l'empreinte noyau (mais ça m'amuse moins que dans mon jeune temps, surtout les tests sur une machine headless) ;
  • S'arranger pour que les samples courants sortent de la swap quand on sélectionne une banque de sons (là, j'ai une idée).

Slampler

Le Slampler, Slug Sample Player, est né avec la formation d'un nouveau groupe, sur les cendres des Knou. À la première répétition, on aurait voulu envoyer des samples comme ceux que Paul avait insérés sur ses maquettes enregistrées avec Ableton Live. En général, cela signifie acheter un pédalier sampler/looper comme un Boss RC-50 ou un Boomerang, mais on ne trouve pas grand-chose en dessous de 400 € si on veut plusieurs déclencheurs, et les fonctionnalités de boucle et d'enregistrement en direct ne sont pas nécessaires. Non, il fallait simplement quelques switches au pied, chacun lançant son échantillon, éventuellement répartis en banques à travers lesquelles on peut cycler grâce à un dernier poussoir.

Son of Slab

Rien de plus simple en partant du Slab puisqu'il suffit d'en prendre les parties qui assurent la sortie audio, la gestion du joystick, et d'y ajouter une gestion simplissime des fichiers d'échantillons. On a donc N fichiers de nom quelconque par répertoire nommé numériquement (0, 1, 2...) pour chaque banque de son, et hop. Il suffit de presser un bouton de joystick pour que le son correspondant soit reproduit.

La carte-son est toujours l'horrible petit dongle C-sound à quelques euros pièce. Elle semble suffire à la tâche, surtout dans un contexte de répétition ou de petit concert... mais on en reparlera plus loin.

Slampler en studio - © 2010 Delphine 13

Prototype avec la pédale contenant l'interface audio, le Slug et le joypad


Le code

Le code est sur Github et rien de vraiment notable n'a changé depuis le Slab hormis l'initialisation de la carte-son. Elle passe maintenant par la fonction snd_pcm_set_params() qui simplifie tout. À l'époque, j'avais dû lire une doc obsolète où cette fonction ne figurait pas encore. Le point notable est qu'elle accepte de plus un paramètre latency. Je ne le retrouve pas dans les primitives ALSA alors que ce paramètre est décisif pour le temps se réponse. Dans l'exemple pcm_min.c, il est fixé à 500000 en millonnièmes de secondes, et le sample met effectivement une demi-seconde à se déclencher. 500 et 5000 donnent une sorte de grésillement au playback et 50000 (50 millièmes de seconde) envoie un son correct quasiment instantanément. Il faudra donc revoir l'initialisation du Slab puisque ce paramètre additionnel pourrait corriger les divers problèmes de latence observés.

Là où le Slab utilise un buffer circulaire pour gérer l'audio, le Slampler emploie autant de pointeurs qu'il existe de switchs déclarés. Dès qu'une variable d'état change depuis le thread du joystick suite à l'activation du sample, un de ces pointeurs est affecté au short * du sample, puis un certain nombre de trames sont copiées vers *playbuf par addition et le pointeur est incrémenté à chaque itération. À la fin du sample, le pointeur est remis à NULL.

Le code est directement portable d'une Debian à une Ubuntu et de ARM à Intel. Pas essayé sur une Fedora ou une OpenSuSE (sur un IBM zSeries non plus, d'ailleurs).

Les données audio

Le répertoire des données est indiqué par un #define dans le source et peut être monté sur un système de fichiers à part comme celui d'une clef USB ou d'une carte SD. Dans ce cas, il faut bien entendu bricoler le fichier /etc/fstab pour y insérer une ligne comme

/dev/sdb1 /data vfat default 0 0

si le source contient

#define DATADIR /data

Les fichiers échantillons seront donc dans les répertoires /data/0, /data/1, etc.

Leur format est obligatoirement s16le à 44100, mono ou stéréo. La fréquence est fixée car on ne peut pas s'amuser à convertir les flux audio à la volée avec un processeur à 266 MHz. La commande qui suit convertit tout fichier audio non compressé au bon format :

# sox src.wav -c 1 -b 16 dst.wav rate -h 44100 dither -s

Pour convertir un fichier MP3 ou OGG en WAV, il suffit de lancer

# mpg123 -w fichier.wav fichier.mp3

À noter, un petit quirk des systèmes de fichiers évolués comme les ext*fs : l'ordre d'insertion dans un répertoire n'est pas celui dans lequel les entrées de fichier seront ensuite lues par readdir(). Ce n'est pas le cas des FAT des clefs USB où le premier fichier copié dans un répertoire vide sera le premier à apparaître dans la liste. Celui-ci sera alors affecté au switch de gauche, le deuxième au suivant, etc.

Chaque échantillon est stocké en RAM en mono quel que soit son format d'origine pour optimiser la place. Il est converti en 2 canaux au moment du playback car certaines cartes son n'acceptent pas de signal mono, et son amplitude est divisée par deux pour pouvoir mixer les signaux de samples différents sans trop de saturation. Un mécanisme transforme le dépassement de capacité en simple écrêtage.

Le système

Comme pour le Slab, le socle est une Debian ARM pour pouvoir éditer/compiler/tester sur le NSLU2 lui-même. Les démons inutiles comme hald sont coupés.

Il faut insérer une ligne dans le fichier /etc/inittab comme par exemple chez moi :

sl:23:respawn:/home/slug/slampler/slampler

Elle démarre un processus slampler et le relance chaque fois ou'il s'arrête. telinit q force le processus init à relire ce fichier si on (dé)commente cette ligne pour passer d'une configuration de production à une configuration de développement et vice-versa.

Le programme tourne en tant que root ce qui lui donne les bons droits pour allumer et éteindre les LED du NSLU2 selon la banque de sons sélectionnée.

Pied au plancher

Les joysticks et les joypads que je connais peuvent comporter jusqu'à 10 boutons. Il suffira donc de souder aux contacts de ces boutons des fils allant à des poussoirs fugitifs pour les commandes au pied, le tout intégré dans un boîtier plat, un demi-tuyau en PVC ou une gouttière en alu, pour obtenir l'interface de conmande.

Jusqu'à 8 sons peuvent être activés simultanément puisque 8 switchs sont définis dans le code plus celui de banque. Cela donnerait un pédalier à 9 poussoirs, donc d'au moins 80 cm de long si on les espace de 10 cm. Un peu long pour mon goût : je me contente de 5 poussoirs de samples plus un de banque, espacés de 8 cm, ce qui donnera un peu plus de 50 cm avec les marges sur les côtés.

Pédalier du Slampler - cc by-nc-sa

Le pédalier en construction


Pour le prototype, les contacts d'un Logitech Precision seront soudés à 7 fils (1 pour le commun) courant vers un tuyau en PVC de 40 mm de diamètre, calé par deux quarts de tuyau dans le sens de la longueur pour le stabiliser, dans lequel sont percés les trous recevant les poussoirs. Ceux-ci porteront les fils électriques soudés à des fils de faible section, eux-mêmes soudés aux contacteurs du joypad. La fiabilité est le point faible du proto. Il faudra probablement un tuyau de plus grand diamètre pour héberger tout le foutoir branché au Slug : intérieur du joypad, carte-son, clef USB et hub passif.

Tout cela sera possible une fois que je serai arrivé à souder correctement les fils sur le circuit du joypad. Pour l'instant, j'ai surtout réussi à griller deux contacteurs...

Résultat

En répétition, avec un joypad actionné à la main puisque le pédalier n'était pas encore soudé, l'ensemble s'avère utilisable à un détail près. La très mauvaise qualité de l'interface provoque un hiss assez perceptible à volume de groupe. Il faut changer de carte son mais je ne connais pas les interfaces pas chères actuelles (comme la Behringer UCA 202), ou insérer une noise gate bas de gamme en sortie comme la Harley Benton de chez Thomann à 25 euros (ne pas prendre la Behringer, qui ne marche pas de l'avis général).

Slampler en action - © 2010 Delphine 13

Portrait de l'artiste en jeune geek


D'autre part, un bug dans le code actuel provoque parfois le défilement de plusieurs samples à la suite quand on change de banque pendant qu'un échantillon tourne encore. C'est facilement corrigeable, soit en coupant les samples en train de tourner quand on passe à la banque suivante, soit en gérant les structures de donnéss un peu différemment.

Enfin, faut-il simplement lancer un sample et attendre qu'il se termine, ou bien ne le jouer que le temps que le switch correspondant reste enfoncé ? C'est actuellement la première solution qui est mise en œuvre mais il serait facile de tenir compte de l'état courant des switchs. Comme d'habitude, à suivre.

Diaspora*

Coïncidence. Le jour où je m'inscris enfin sur Facebook pour accéder aux photos du concert d'il y a 15 jours, un article sur Slashdot renvoie vers le projet de 4 étudiants de NYU. Diaspora* vise rien moins qu'à remplacer Facebook, non comme ce dernier avait remplacé Myspace, Friendster et Orkut, mais en utilisant un nouveau paradigme, celui de la décentralisation.

Dans Diaspora*, aucune donnée ne résiderait sur des serveurs centraux. Toutes les communications seraient chiffrées par GPG. Les utilisateurs géreraient leur propre espace selon les fonctionnalités de publication, de droits d'accès, etc. offertes par le protocole.

Notez le conditionnel. Rien n'existe encore. Ces quatre zozos doivent passer leurs examens de fin d'année avant de consacrer l'été au codage de la V1. Cependant, ils ont eu une très bonne idée et leur solution semble à moitié se tenir. Ils ne sont pas les seuls à l'avoir eue mais eux ont su la communiquer - il n'y a qu'à voir leurs vidéos où la petite bande explique le concept devant un tableau noir. Ils savent aussi se donner les moyens de leur politique en lançant une souscription sur Kickstarter en demandant $10000 pour remplacer l'argent de leurs stages et de leurs boulots d'été.

Ils en sont aujourd'hui à $130000 et ça continue de grimper.

J'ai donné $5, comme je donne une pièce dans le métro à un musicien qui, lui, au moins, ne reprend ni les Beatles ni la variété des années 70. J'ai contribué à ce projet-qui-n'existe-pas comme plus de 3500 personnes parce que cette équipe voit le monde sous la coupe de Skynet et veut le changer en rendant aux gens la propriété de leurs données. Rien que cette volonté-là mérite mes $5. Le montant astronomique des sommes récoltées pour rien d'autre qu'un vaporware montre, ou plutôt confirme, autre chose : plein de monde en a marre de Skynet au point de saisir au vol n'importe quelle autre option, n'importe quelle promesse de possibilité.

La trajectoire de Facebook pourrait avoir atteint son apogée, et c'est à ce moment précis que je m'y inscris... Coïncidence ? Aucune. Je voulais voir des photos qui ne sont disponibles nulle part ailleurs, parce que, de lieu de rencontre dispensable, Facebook montre maintenant son vrai visage d'espace clos, fermé à l'Internet, où se trouvent des données accessibles uniquement en s'y inscrivant. Et il devient maintenant trop incontournable pour rester tolérable.

Cela explique le succès de Diaspora*, à qui je souhaite de résoudre les problèmes insensés dûs à la décentralisation des ressources. Allez-y les gars, ce n'est pas grave si vous vous plantez. D'autres viendront de toute manière prendre le relais si j'en juge par la motivation de vos contributeurs.

SLAB - Slug Audio Blaster

Après le Phaseur Arduino, l'étape suivante était logiquement un système embarqué sous Linux afin de pouvoir gérer assez de RAM pour des effets comme l'echo et, peut-être, la reverb, en plus du flanger. Enfin, un vrai système d'exploitation avec un compilateur et un serveur SSH ! Ça change de l'IDE limité et des transmissions série de l'Arduino. Parfois, j'aime mes aises. Et une vraie carte-son permet de s'affranchir des bricolages d'I/O analogiques et d'obtenir un rapport signal-bruit correct.

Parmi tous les matériels compacts pouvant tourner sous GNU/Linux, le Linksys NSLU2, alias Slug, est un choix logique parce qu'il est très largement supporté et qu'il comprend 2 ports USB. Plusieurs distros pour processeur ARM sont disponibles dont SlugOS/LE, qui ne m'a pas convaincu (trop compliqué à customiser, surtout alors que je pensais encore utiliser jack) et Debian. Le seul vrai inconvénient de Debian est l'ajout obligatoire d'espace disque supplémentaire, ce qui implique d'utiliser un des ports USB pour une clef de 2Go. La carte-son choisie est un dongle USB appelé C-sound, compatible usb-audio, trouvé sur eBay pour 4 €.

Le contrôleur ? Une wah chinoise à 16 € (+fdp) dépouillée de son électronique et un peu bricolée pour pouvoir se servir réellement du switch. N'importe quelle wah mécanique fera l'affaire, en évitant de préférence les wah chinoises comme la mienne qui ne sert qu'à prototyper. Les Morley, Behringer et autres pédales à commande optique sont donc à oublier pour l'instant. Le potentiomètre de 100 kΩ est connecté à un convertisseur 15 broches analogigue -> USB. Sa résolution de 7 bits n'est ni plus ni moins pathétique que les joysticks USB habituels mais les potards de ceux-ci ne sont pas compatibles. Il faudrait aussi que je retrouve ce fabricant anglais de convertisseurs analogique-numérique pas trop chers, qui ont une bien meilleure résolution.

Ok, il faut trois ports USB au total, donc ajouter un hub. Pas grave car il peut être passif, mais le joystick doit être connecté en direct sinon il marche très mal (un hub actif n'y change rien). Deux câbles USB vont donc de la pédale au Slug.

Ensuite, quelle couche logicielle attaquer ? Jack est tentant sur le papier mais, sérieusement, il n'y a ici rien à multiplexer et ses capacités « temps réel » dépendent avant tout de la couche ALSA sous-jacente. Malgré l'étrange avis du tutoriel de l'API ALSA concernant le full-duplex (In a word: JACK), on peut parfaitement lire et écrire sur la même carte-son.

Le code, sous GPL, est structuré en gros en :

  • Thread séparé du joystick ;
  • Initialisation de la carte-son en full-duplex ;
  • Boucle de traitement avec l'enchaînement d'effets ;
  • Diverses fonctions de gestion des indicateurs lumineux, d'affichage de debug, gestion des signaux, etc.

Dans les données, on notera surtout

  • procbuf, le buffer circulaire où le signal est traité ;
  • joyval, indiquant la position du potard de la pédale, dont il faut intégrer les variations pour éliminer les fluctuations engendrant des distorsions ;
  • sinus, un tableau de valeurs pre-calculées pour pallier l'absence de FPU sur cet ARM.

On compile le source unique par :

$ gcc -g -Wall -lasound -lthread -o slab slab.c

et c'est tout. Si l'exécutable résultant est lancé par root, il permet en plus de commander les petites lumières du Slug qui indiquent quels effets sont enclenchés. Le flag -d fait afficher des messages de debug.

ALSA ne se laisse pas programmer facilement. Comme le rappelait déjà Alan's clob en parlant de ses efforts sur Gnuitar, il faut en passer par une palanquée de fonctions de bas niveau quand, la plupart du temps, on voudrait simplement ouvrir une carte-son avec des paramètres par défaut. Heureusement, ALSA fournit des variantes suffixées par _near pour ajuster les paramètres en interne si ceux qui ont été passés ne correspondent pas exactement à ce qu'accepte la carte.

L'echo et le flanger fonctionnent plutôt bien. Il faut intégrer la valeur du joystick de manière différente dans les deux effets pour ne pas voir apparaître d'altération. Pourquoi ? Parce que je ne sais pas m'y prendre, probablement.

La distorsion modélise plus ou moins un étage de sortie en push-pull d'ampli à lampes. Plutôt moins que plus, hein. Disons qu'il génère un bon paquet d'harmoniques tierces grâce à une fonction de transfert en quart d'onde sinusoidale, qu'on applique récursivement pour accentuer l'effet.

Le gros problème est la latence, dans les 22 ms, en partie due au bus USB auquel est raccordé la carte-son. Ce délai est perceptible (il gêne le jeu) sur les effets non temporels comme la distorsion ; beaucoup moins sur les effets d'ambiance où la précision est moins cruciale. L'USB n'est pas le seul coupable car j'observe aussi des latences avec la carte-son d'un vieux portable IBM 240 sur lequel tourne le programme.

En conditions réelles, on doit pouvoir sélectionner deux effets par les poussoirs rouges situés devant la pédale. Un troisième, plus petit, situé juste au-dessous d'eux, permet de réinitialjser le programme - en fait de l'interrompre, le système le relançant par une boucle dans /etc/rc.local - au cas où une série de write_underrun engendre un délai énorme (une seconde) que l'on ne peut plus faire disparaître : il faut resetter toute la stack ALSA. Je ne maîtrise pas encore tout de l'API, d'où peut-être ce délai étonnant qui apparaît au playback quand, lors des tests, le traitement s'effectue aux dépens des I/O.

La latence de base et l'absence de FPU limitent sérieusement les possibilités. Il faudrait tester avec un système du type PC embarquant une carte-son intégrée mais cela reviendrait beaucoup plus cher que les 140 € de l'ensemble. Un vieux portable comme l'IBM dont il est question plus haut pose des problèmes potentiels de fiabilité (disque dur, à remplacer par de la SSD ?) et de solidité mécanique (boîtier plastique) qui interdisent son utilisation sur scène. Et la latence n'y disparaît pas totalement, loin de là (qu'en dit le projet Gnuitar ?). Je recherche surtout une manière de lire les trames USB au plus bas niveau pour démiauler les données brutes et les réinjecter directement après traitement. Sans trop d'espoir, mais à vrai dire sans trop de motivation non plus : quand le système sera complètement intégré, d'ici quelques soudures, il fera malgré tout exactement ce qui lui était demandé au départ, et je pourrait l'intégrer à mon pedalboard pour remplacer la Cry Baby qui remplace l'airFX.

Les photos !

Le Slug et la carcasse de wah : SLAB - premier essai

Les éléments, de haut en bas - NSLU2, hub sur lequel est monté clef USB et carte-son, convertisseur joystick, carcasse (sans les boutons) : SLAB 2

L'intégration dans le boîtier : Slab complet

Les samples !

Premier essai. Clairement, cette pédale souffre, il faut faire quelque chose.

Ça marche ! Son clean, en direct sur une console de mixage.

Avec une fuzz devant, on peut jouer avec la résonance pour obtenir une mélodie par-dessus les accords. La résolution imparfaite du convertisseur USB donne des notes discrètes au lieu d'un portamento continu.

Les liens !

nxv - networked xv

Je suis un vieux con.

Un vieil Unixien (depuis System III en 1983) qui a du mal à perdre ses habitudes.

Un des programmes installés par les premières Slackware, vers 1994, s'appelait xv et permettait de visualiser des images, et d'effectuer des manipulations de base, le tout en quelques touches et quelques clics de souris. L'espace pris sur le "screen estate" restait minimal. Comparé à display, dont il est impossible de sortir par une action au clavier, à gqview et ses widgets inutiles, xv est un rêve d'ergonomie - l'ergonomie étant, pour un vieux con, idéalement définie par un programme comme vi : une action, une touche. :-)

Mais xv est vieux, lui aussi. Il ne gère pas les formats de fichiers modernes. Il se comporte bizarrement avec certains window managers (l'option -nolimits ne fonctionne pas sous Gnome, Sawfish refuse les actions previous-workspace et next-workspace vers un espace où une image est maximisée). Il n'est plus maintenu que par une petite communauté d'utilisateurs qui diffusent des patchs malheureusement incompatibles : je n'ai jamais réussi à accepter en même temps le PNG et les différents formats JPEG. Alors que display accepte les URL en argument, xv ne gère que les fichiers locaux.

C'est probablement la paresse de m'habituer à un autre visualisateur d'images qui m'a poussé à passer plusieurs heures sur un wrapper donnant à xv la fonctionnalité qui me manquait le plus : l'accès par le réseau. Le processus de téléchargement dans un fichier temporaire a donné aussi la possibilité de convertir les formats « difficiles » vers des formats connus de xv, de PNG vers GIF et de JPEG vers JPEG. Il y aurait sûrement plus propre et plus rapide que ma manière de faire mais, au moins, ça marche. Le script nxv attaché en pièce jointe est le résultat de mes élucubrations. S'il lui faut une licence, qu'elle soit BSD. Ou WTFPL.

Edit: Le système de pièces jointes de Dotclear est borké. Voici le lien direct : nxv

Le Phaseur

Update: English translation avalaible at http://jzu.blog.free.fr/index.php?pages/Le-Phaseur

L'airFX prenant trop de place sur le pédalier, il avait giclé au profit d'une wah de base, mais j'avais toujours besoin de cet effet de flange malade qu'on peut entendre par exemple sur Youpi Youpi Yeah (la chanson) - enfin, moins maintenant, mais bon - et, après tout, pourquoi ne pas bricoler un effet numérique ? Il existe déjà une pédale se voulant open source dont le manque de succès est peut-être dû à son prix élevé, dans les $300. On peut baisser les coûts en utilisant un Arduino, par exemple, si on n'a pas besoin de trop de mémoire ni de définition, et puis ça peut être cool d'architecturer soi-même tout le système. Il faut quand même faire un peu d'électronique, et savoir optimiser son code car on ne dispose là que d'un pauvre micro-contrôleur ATmega168 à 16 MHz avec quelques kilo-octets pour le programme et 1 kilo-octet pour les données, y compris la stack. Juste de quoi piloter un lave-vaisselle. Ou fabriquer un effet de déphasage lo-fi.

Arduino

Le déclic est venu d'un article d'Instructables où, même si les effets n'avaient pas trop d'intérêt et s'il s'y glissait deux ou trois erreurs, son auteur, kylemcdonald, posait toutes les bases nécessaires que ce soit au niveau matériel ou logiciel. Ma solution est maintenant un peu différente sous ces deux aspects mais n'aurait jamais vu le jour sans cet article.

En attendant le circuit commandé aux USA, j'ai commencé par tester mes idées de « flange variable » avec Audacity pour valider l'algorithme à employer en décalant un signal de quelques millièmes de seconde et en faisant varier ce décalage. Le colis reçu, on commence le boulot d'intégration avec l'adaptation des entrées-sorties audio. En entrée, il faut 5 volts alors que le signal d'une guitare est de l'ordre de quelques centaines de millivolts. En sortie, c'est l'inverse. Il faut donc un étage d'amplification comme un ampli op (le LT1006 convient pour 5 volts) en entrée et un diviseur de tension en sortie. L'entrée analogique autorise 10 bits mais, pour obtenir une sortie d'une résolution au moins aussi correcte, il faut combiner deux sorties numériques 8 bits en PWM en ajustant les résistances de sortie pour que l'une soit d'une valeur 256 fois supérieure à l'autre. Enfin, on peut obtenir 5 volts à partir de 9 volts avec un régulateur de tension sur un radiateur. Quelque chose comme ça, les parties en pointillés étant optionnelles :

Schema adapatation Phaseur

A posteriori, je vois bien que le circuit d'entrée est buggé et que les filtres passe-bas ne sont pas nécessaires. Mais il a suffit à obtenir du son au bout de quelques essais difficiles, avec le proto du circuit d'adaptation sur un breadboard.

phaseur1.jpg

Les premiers essais avec le prototype complet - dont une vieille pédale italienne nullissime recyclée pour l'occasion - donnent ce sample. Attention aux oreilles sensibles.

Phaseur complet 1

Et finalement, on peut embarquer une version définitive dans la vieille wah. La correction du circuit électronique donne un meilleur résultat du point de vue de la saturation mais le son devient bien moins intéressant malgré le sample and hold involontaire (interférences au niveau du multiplexeur d'entrées analogiques audio et potentiomètre ?)

phaseur8.jpg

Le code du Phaseur, sous licence Artistic 2.0, est rébarbatif et simple en même temps. Rébarbatif en raison de la proximité du matériel qu'aucune librairie n'isole du programmeur (« Cachez ces registres que je ne saurais voir »). Simple car l'algorithme consiste à mélanger l'échantillon courant avec ce qu'on a écrit dans le buffer circulaire juste un peu plus tôt, selon la position de la pédale. Tout se passe dans loop().

À suivre. Car, même si un autre effet est prévu sous Linux avec des possibilités de traitement de qualité CD et de la mémoire a gogo, l'Arduino reste une solution efficace - car sans système d'exploitation - si on se contente de 8 ou 10 bits de résolution. Une fois que l'électronique d'adaptation sera au point et que le son obtenu sera correct, il suffira de décaler l'offset de la polarisation et de monter le gain pour obtenir l'effet cradingue du premier sample qui plaît tant à certains (et terrorise les autres).