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.
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.
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).
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.