Y’a quelques jours, je me suis lancé dans un nouveau projet. Plus pour le fun que par réelle nécéssité, je me suis mis en tête d’ecrire un BusyBox-like orienté BSD. J’en suis pour le moment aux balbutiements du projet, mais quelques commandes sont déjà fonctionnelles.

Mon approche est un tantinet differente du fonctionnement de BusyBox. Afin de permettre l’écriture simple et rapide de plugins, je supporte deux modes, un mode statique (ala BB), et un mode dynamique grace aux interfaces DLFCN(3).

Ç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 :

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 :

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.

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 :

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.

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.

Dernier p’tit coup de oUks au soleil: la semaine dernière, c’était la Techno Parade 2008, et c’était assez fou : [MEDIA=11] Bon ok, ça vaut pas un Amnesia, mais faute de mieux…

Après des mois de fixes plus ou moins hasardeux, j’ai enfin trouvé la methode infaillible pour regler définitivement les problèmes liés à cette… bref, la solution :

Cette dernière action effacera également la dépendance ubuntu-desktop, mais cela n’a aucun impact.

Virer toutes les références à pulse potentiellement présentes dans vos ~/.asoundrc et .asoundrc.asoundconf, puis dans System->Preferences->Sound, dans la section Devices, tout passer à Alsa.

Depuis un petit moment, je constate que les derniers builds du QEMU contenus dans KVM explosent en vol au démarrage de la VM. Flemmard, je continuais donc à utiliser le QEMU de la version 68 qui, lui, fonctionnait. Et puis ça a fini par vraiment me démanger. Je comprend à grands renforts de gdb que lorsque l’output SDL est activé en même temps que le support d’une carte réseau virtuelle, QEMU coredumpe. À tout hasard, j’essaye de passer à un modele de carte virtuelle different de la rtl8139 émulée par defaut, puisque les dernieres versions de QEMU/KVM en supportent desormais bien plus qu’auparavant, et là, bingo, plus de Segmentation Fault. Ainsi, le démarrage de mes VMs NetBSD ressemble désormais à ceci :