Emile “iMil” Heitor ’s home

Ça y est, j’ai craqué. À force de faire du duz-duz et que tous les musicos de mon entourage me le suggèrent à longueur de journée, j’ai acheté ça :

Il s’agit d’un clavier MIDI tout ce qu’il y a de plus basique, et surtout, à pas trop cher.

Je m’attendais évidemment à galérer comme pas deux pour faire reconnaitre le bestiau sous GNU/Linux. Voici la marche à suivre :

Brancher la prise dans le trou prévu à cet effet.

Ouais.

C’est tout.

La preuve :

Et finalement sous LMMS(*) :

trop dur.

(*) LMMS 0.4.0 stable est sorti la semaine dernière, et ça vaut clairement son pesant de cacahuètes

NetBSD 4.0 a vu apparaitre un nouveau filesystem, plus ou moins équivalent au FUSE de GNU/Linux. Il s’agit de proposer un framework qui permettra de manipuler sous forme de filesystem (via les opérations associées open, close, read, write…) des outils userland. Parmi les plus pratiques de ces utilisations, citons par exemple SSHfs ou CurlFtpFS. Et c’est précisemment de cette dernière abstraction dont j’ai recemment eu besoin.

Un rapide tour dans pkgsrc nous montre l’existence du package filesystems/fuse-curlftpfs, ce qui signifie que ce que nous envisageons semble à portée. On note cependant dans le Makefile de ce package la dépendance suivante :

.include "../../mk/fuse.buildlink3.mk"

fichier dans lequel on peut lire :

.  elif ${OPSYS} == "NetBSD"
.     if !exists(/usr/include/fuse.h)
PKG_FAIL_REASON+=       "Couldn't find fuse headers, please install librefuse."
.     endif

Munis de ces quelques informations, une recherche bien placée nous dirige evidemment sur NetBSD.org, et en particulier à la section dédiée à puffs. Là, nous pouvons lire la chose suivante :

Using FUSE file systems on NetBSD 4.0 is possible, but in addition to adding puffs support support to the kernel, it requires fetching and manually installing a backport of the ReFUSE library. The library is available here and further instructions are available here.

Bien. Résumons :

Pour utiliser FUSE et ses nombreux backends, nous avons besoin :

• Du support puffs dans le noyau
• Du backport de la librairie ReFUSE

Execution.

Le support puffs s’active de deux façons differentes, directement dans la configuration du noyau via la directive

file-system PUFFS

ou plus simplement en chargeant un module noyau. C’est cette derniere methode, bien moins contraignante, pour laquelle nous allons opter.

Pour mon plus grand malheur, dans une installation de base, pas trace d’un /usr/lkm/puffs.o, il est donc nécessaire de compiler ce dernier puis l’installer. D’abord, la documentation officielle explique qu’il fau placer la variable MKPUFFS=yes dans le fichier /etc/mk.conf. Ensuite, puisque cette machine comporte bien les sources du système mais n’a jamais reconstruit quoi que ce soit concernant la base, construisons les tools :

# mkdir /usr/obj
# cd /usr/src && ./build.sh -m i386 tools

Operation à l’issue de laquelle un repertoire /usr/src/tooldir.NetBSD-`uname -r`-i386 devrait avoir fait son apparition.
Il est maintenant possible de construire notre module en se rendant dans son repertoire source :

# cd /usr/src/sys/fs/puffs
# make install

Un module noyau est maintenant disponible dans /usr/lkm, reste à le charger :

# modload /usr/lkm/puffs.o

Puis à créer son device dans /dev :

# cd /dev && ./MAKEDEV puffs

Et afin d’automatiser cette opération à chaque reboot, de placer dans le fichier /etc/lkm/conf la ligne suivante :

puffs.o -s - - - BEFOREMOUNT

Maintenant que notre système est puffs-ready, il est temps d’installer la couche d’emulation FUSE pour puffs, ReFUSE.

On trouve le lien vers le backport NetBSD 4.0 de la libReFUSE dans la page de puffs chez NetBSD.org. À l’heure ou j’écris ces lignes, ce backport se trouve ici et la documentation associée, ici.

L’installation est “à peu près” complète :

# tar zxvf librefuse_nb4-20080115.tar.gz
# cd librefuse
# make install

Mais l’auteur a oublié de mentionner qu’il fallait copier les fichiers fuse.h et fuse_opt.h dans /usr/include pour satisfaire buildlink. Donc :

# cp fuse.h /usr/include
# cp fuse_opt.h /usr/include

Voila ! il est maintenant possible d’installer un backend FUSE issu de pkgsrc :

# cd /usr/pkgsrc/filesystems/fuse-curlftpfs/ && make install clean

De le démarrer (attention cette commande ne rend pas la main):

# curlftpfs -v -o disable_epsv ftp.lip6.fr /mnt

Et de tester

~/src/librefuse$ ls -l /mnt/
total 782080
dr-xr-xr-x   2 root  wheel       512 Sep  8  2006 etc
drwxr-xr-x   9 root  wheel       512 Feb 16  2001 ibp
drwxr-xr-x  10 root  wheel       512 Jun 22  2000 jussieu
drwxr-xr-x   2 root  wheel       512 Feb 16  2001 liafa
drwxr-xr-x   5 root  wheel       512 Jul 23  2003 lip6
-rw-r--r--   1 root  wheel  50020898 Nov  2 09:50 ls-lR.gz
drwx------   3 root  wheel       512 Feb 16  2001 private
drwxr-xr-x  43 root  wheel      1024 Jan 22  2008 pub

Magnifique.

Au-se-cours.

Hier soir, alors que je me rencardais sur DSSI (un API pour créer des plugins audio à la VST), je suis tombé sur ce lien. FST n’est ni plus ni moins qu’un programme qui permet, en utilisant Wine et JACK d’utiliser des plugins VST sous GNU/Linux. Là comme ça, ça a l’air de rien, mais les musiciens dans l’assemblée, s’ils ne sont pas déjà au courant (le projet date de 2006 tout de même), devraient faire dans leur froc.

Un peu dubitatif, je décide d’essayer le machin.

Sous une Ubuntu / Debian, les packages suivants sont nécessaires :

• wine
• wine-dev
• lash-bin
• lashd
• liblash-dev

Décompressons de la version 1.8 de FST.

Après avoir récupéré le SDK 2.3 VST chez Steinberg (voir le lien chez http://www.joebutton.co.uk/fst/), décompresser l’archive vst_sdk2_3.zip puis vstsdk2.3.zip contenu dans cette archive dans le répertoire créé par la décompression de FST, fst-1.8. Le Makefile de FST est un peu foireux, commentez la ligne suivante :

        #cp -a $(VSTDIR) ./vst

Et réalisez cette étape à la main avant d’invoquer make :

$ mkdir vst && vstsdk2.3/source/common/* vst/

Enfin :

$ make

À ce stade, un executable, fst, devrait être disponible.

Démarrez alors LASH en invoquant la commande :

$ lash_panel

Téléchargez l’un des innombrables plugins VST disponibles, souvent gratuits et parfois libres, par exemple sur VST4Free et lancez le de cette façon :

$ pwd
/home/imil/sound/src/fst-1.8
$ ./fst /chemin/vers/le/plugin.dll

Le premier choc, c’est l’apparition du plugin :

Le second, c’est son apparition dans la liste des clients JACK :

Reste à attacher la sortie audio du plugin au port sonore systeme :

Le plugin est alors manipulable en utilisant n’importe quel canal midi (à eventuellement attacher au plugin en utilisant la console jack).

Et maintenant, j’ai besoin de Guronsan.

Pour ne plus avoir de soucis de monopolisation de carte son par JACK, j’ai ajouté une carte dans ma machine principale et l’ai intégralement dédiée à cette utilisation. Problème, fonction de l’ordre de chargement des modules lors du boot de la machine, cette derniere est tantot associée en Card 0, tantot en Card 1. On trouve la solution à ce problème sur le Wiki d’Alsa, et plus particulièrement dans le topic MultipleCards. En ajoutant ces deux petites directives :

options snd slots=snd_hda_intel
alias snd-card-0 snd_hda_intel

au fichier /etc/modprobe.d/alsa-base d’une Ubuntu, on s’assure que la carte dont le driver est snd_hda_intel sera toujours associée au slot 0. Ainsi, tous les évenements sonores “habituels” utiliseront le slot 0 par defaut, et on affectera le slot 1 à JACK et toutes les applications l’utilisant.

Il suffit alors de recharger les modules alsa via la commande :

$ sudo alsa force-reload

et tout devrait rentrer dans l’ordre.

Dans la serie des trucs qui marchaient très bien avant et qui se sont mis à merder depuis héron boiteux, j’appelle à la barre Jack, cet incroyable bout de soft permettant de brancher des applications sonores ensembles et d’en réduire la latence.

En effet, depuis quelques mois, le son provenant d’une application que je faisais passer par Jack grésillait inéxorablement. Gresillement / saturation, difficile de cerner le soucis et d’en rechercher la cause.

La solution vint de Tito, bien plus habitué que moi à bidouiller du son sous GNU/Linux. Via qjackctl, j’ai passé l’option Periods/Buffer de 2 à 8, et ô magie, un son pur comme le crystal s’échappait de mes enceintes.

On trouvera également quelques infos interessantes sur le sujet à cette adresse.

Il y a bien longtemps, lorsqu’un Amiga 1200 ornait mon bureau, je m’essayais à la composition (encore que le mot “composition” soit bien présomptueux ici) à l’aide de differents Trackers, rappelez-vous, Protracker…

Depuis ces temps réculés, devant le manque cruel de temps et d’applications séduisantes, je ne m’étais pas réessayé à la “composition”. J’avais essayé SoundTracker, un équivalent des softs d’antan pour Unix, mais je n’avais finalemnet pas accroché. D’autre part, les logiciels ultra-complets (et complexes) du type Ardour me semblaient impossible à dompter en une soirée.

Finalement, mon ingénieur du son de cousin dont la workstation est une Ubuntu-studio depuis pas mal de temps m’a aiguillé sur le soft qui me manquait: LMMS (Linux MultiMedia Studio).

Si le soft est clairement perfectible, il n’en reste pas moins d’ores et déjà parfaitement exploitable, assez simple d’utilisation, et permet en l’état de créer des morceaux electro de bonne facture. Pour ne rien gâcher et vous mettre rapidement le pied à l’etrier, leur Wiki propose une section “Getting Started” qui se lit en quelques minutes et vous permet en autant de temps de démarrer vos premières boucles. J’aime beaucoup leur mechanisme de retouche d’instruments et l’homogénéité de l’interface (fonctionnellement parlant). La prochaine version (0.4) promet nombre d’améliorations mais est à mon gout trop instable pour etre utilisée. Pour mes maigres besoins, la version 0.3.2 est pour le moment amplement suffisante et amusante.

Munis de LMMS pour la compo, Audacity pour le sampling et SampleSwap pour la banque de son, les possibilités sont relativement importantes… TREMBLEZ Swedish House Mafia !