Nous arrivons au terme de cette série avec une question très concrète : que faire aujourd’hui de ces fichiers MOD, XM, S3M et IT ? Les archiver est indispensable, les télécharger reste utile, mais il est également possible de leur redonner leur fonction première : être exécutés par un moteur musical.
Le navigateur moderne constitue pour cela un environnement particulièrement intéressant. Une page Web peut charger un module, le décoder, produire son audio, afficher ses informations et synchroniser sa lecture avec une autre application — par exemple un jeu DOS exécuté dans la même interface.
Le tracker quitte alors son logiciel historique sans perdre nécessairement sa logique.
La première différence architecturale est essentielle. Pour lire un MP3, le navigateur dispose déjà d’un décodeur audio standard. Le fichier est transformé en signal sonore puis envoyé vers la sortie audio.
Avec un module tracker, il faut davantage de logique. Le logiciel doit comprendre la structure du format, charger les samples et les instruments, parcourir la séquence et les patterns, gérer les rows et les ticks, appliquer les effets puis mixer les différentes voix.
Nous retrouvons donc toute la mécanique étudiée dans les neuf articles précédents.
Dans une architecture Web, le module peut être récupéré depuis le serveur comme une ressource binaire. JavaScript reçoit les octets du fichier puis les transmet à un parser ou à une bibliothèque spécialisée.
Cette couche ne devrait idéalement connaître ni l’interface du lecteur ni la logique du jeu. Son rôle est simple : récupérer le fichier demandé et fournir ses données au moteur.
Cette séparation facilite énormément la maintenance.
Le parser doit déterminer ce qu’il reçoit. Un MOD n’est pas organisé comme un XM ; un S3M ne possède pas exactement la structure d’un IT.
Une fois le format identifié, le parser transforme les données binaires en structures exploitables : titre, instruments, samples, patterns, ordre du morceau, tempo initial et autres informations nécessaires au replay.
À ce stade, aucune interface graphique n’est indispensable. Le logiciel construit simplement une représentation interne du module.
Le moteur constitue le cœur musical du système. Il conserve la position courante dans la séquence, le pattern actif, la row, le tick, la Speed et le BPM.
Pour chaque canal, il maintient également l’état nécessaire : instrument courant, sample, volume, panoramique, hauteur et mémoire des commandes d’effets.
Sa boucle conceptuelle reste celle étudiée précédemment :
Order → Pattern → Row → Tick → Effects → Mix → Tick suivant
Cette partie doit rester indépendante de l’affichage. Le bouton Play peut disparaître ou changer de couleur sans que cela modifie la manière dont un vibrato est calculé.
Le replay décide ce que chaque voix doit faire. Le mixer transforme ensuite ces voix en un flux audio commun.
Il doit lire les samples à la bonne hauteur, gérer leurs boucles, appliquer les volumes et panoramiques, puis additionner les différents canaux. Selon le moteur choisi, il peut également proposer plusieurs méthodes d’interpolation ou différents modes de compatibilité.
Le résultat est finalement un flux PCM que l’environnement audio du navigateur peut restituer.
Dans le navigateur, la Web Audio API fournit les outils nécessaires à la construction d’un graphe audio et à la restitution du son.
Un moteur tracker peut produire des blocs d’échantillons qui sont ensuite envoyés vers la sortie audio. Selon l’architecture retenue, une partie du traitement temps réel peut être isolée afin d’éviter que les opérations de l’interface perturbent le son.
C’est un point important : animation, scrolling ou ouverture d’un menu ne devraient jamais modifier le tempo du morceau.
Deux grandes approches sont possibles. Un moteur peut être écrit directement en JavaScript, ce qui facilite l’intégration et l’étude de son fonctionnement.
Une autre solution consiste à utiliser dans le navigateur un moteur mature écrit historiquement dans un langage comme C ou C++, compilé pour le Web via WebAssembly. Cette approche permet de réutiliser une grande quantité de travail déjà consacrée à la compatibilité des formats et des effets.
Pour un projet patrimonial ou un lecteur multi-format, cette deuxième voie peut être particulièrement intéressante : l’interface reste en JavaScript tandis que le cœur de replay demeure spécialisé.
Une architecture saine peut être découpée en plusieurs composants :
Loader → Parser → Replay Engine → Mixer → Audio Output → UI
L’interface utilisateur envoie des ordres au moteur : Play, Pause, Stop, Seek ou chargement d’un nouveau module. Le moteur peut en retour exposer son état : titre, pattern, row, temps écoulé, canaux actifs ou position dans la séquence.
Cette séparation permet ensuite de construire plusieurs interfaces au-dessus du même cœur : lecteur classique, mini-player, visualiseur ou lecteur intégré à une page de jeu.
Pour un site consacré aux jeux DOS, la musique tracker peut devenir une véritable couche d’accompagnement.
Chaque fiche de jeu peut référencer un ou plusieurs modules compatibles avec son univers. Au lancement du jeu, le contrôleur choisit éventuellement une piste dans cette liste et demande au lecteur tracker de la démarrer.
La relation peut rester extrêmement simple :
GAME START → TRACK START
GAME PAUSE → TRACK PAUSE
GAME RESUME → TRACK RESUME
GAME STOP → TRACK STOP
Le lecteur tracker et l’émulateur restent deux composants indépendants, reliés par des événements.
Si plusieurs morceaux sont associés à un jeu, une sélection aléatoire peut être effectuée au démarrage. L’important est que cette logique appartienne au contrôleur musical et non au moteur de replay lui-même.
Le moteur doit simplement savoir : « charge ce fichier et joue-le ». Le contrôleur décide pourquoi ce fichier a été choisi.
Cette distinction permettra plus tard d’ajouter d’autres règles : playlist fixe, rotation, piste favorite, sélection par catégorie ou mémorisation de la dernière musique utilisée.
Le lien entre les composants peut prendre la forme d’une petite API JavaScript interne. Elle n’a pas besoin d’exposer toute la complexité du tracker.
Quelques actions peuvent suffire conceptuellement :
load(module)
play()
pause()
resume()
stop()
setVolume(value)
L’émulateur ou la page de jeu appelle ces fonctions lorsqu’un événement important se produit.
Le Web permet également de rendre visible ce qui resterait normalement caché. Sous la zone du jeu, une petite box peut présenter le titre du module, son format, sa durée, son état de lecture et un lien de téléchargement.
Une version plus avancée pourrait afficher le pattern courant, la row, les canaux actifs ou un visualiseur audio.
Le visiteur ne reçoit alors pas seulement une musique d’ambiance : il découvre qu’il écoute un véritable fichier tracker.
La lecture Web ne devrait pas remplacer le fichier original. Elle devrait au contraire faciliter sa découverte.
Un bouton de téléchargement permet de conserver le MOD, XM, S3M ou IT tel qu’il est stocké sur le serveur. Le visiteur peut ensuite l’ouvrir dans un tracker compatible, examiner ses patterns et découvrir sa structure.
C’est une différence importante avec une simple diffusion audio : le site devient également un outil de transmission du format.
Le fichier lui-même peut être accompagné d’une fiche interne au site : titre, format, compositeur lorsqu’il est connu, jeu associé, style, taille, durée estimée et emplacement du fichier.
Cette fiche peut être stockée en base de données ou dans une structure d’index générée par l’administration. Le lecteur reçoit alors à la fois le module binaire et les informations nécessaires à son affichage.
Cette organisation permet de gérer les trackers comme une véritable collection éditoriale plutôt que comme un simple dossier de fichiers.
Le principal avantage de cette séparation est l’évolutivité. Le catalogue peut changer sans modifier le moteur. L’interface peut être refaite sans toucher au parser. Un nouveau format peut être ajouté sans réécrire les pages de jeux.
On obtient ainsi plusieurs briques autonomes :
Catalogue tracker
Association jeu ↔ musique
Moteur de replay
Contrôleur d’événements
Interface du lecteur
Téléchargement
Chaque partie peut évoluer indépendamment.
Faire fonctionner un module tracker dans un navigateur n’est donc pas simplement une démonstration technique. C’est une manière de relier plusieurs générations d’informatique.
Le fichier conserve les samples, les patterns et les commandes. Le moteur moderne reproduit leur comportement. JavaScript relie le lecteur au reste de la page. Le navigateur fournit l’audio et l’interface. Et le jeu DOS retrouve autour de lui une ambiance musicale cohérente avec son époque.
Nous revenons ainsi à l’idée du premier article : un morceau tracker est davantage qu’un enregistrement. C’est une structure musicale faite pour être interprétée.
Nous sommes partis de Soundtracker et du MOD, avons ouvert la structure des fichiers, découvert FastTracker II et XM, étudié les rows, ticks et commandes d’effets, comparé MOD, XM, S3M et IT puis observé les différences entre moteurs de replay.
Le Web n’efface pas cette histoire. Bien utilisé, il peut au contraire la rendre accessible : écouter le morceau, voir son format, comprendre sa construction, télécharger le module original et le replacer dans l’univers logiciel ou vidéoludique auquel il appartient.
Le tracker n’est pas seulement un ancien format musical. C’est une manière de penser la musique avec la machine — et cette logique peut encore vivre aujourd’hui.
MOD, XM, S3M et IT partagent la logique des trackers, mais ils ne racontent pas la même histoire. Du quatre canaux de l’Amiga aux instruments avancés d’Impulse Tracker, chaque format reflète une génération de machines, de logiciels et de choix musicaux.
Un module tracker contient ses samples, ses patterns et ses commandes, mais le résultat final dépend encore du moteur qui les interprète. Quirks historiques, mémoire des effets, interpolation, fréquence, filtres et compatibilité peuvent faire sonner différemment exactement le même fichier.
Dans un tracker, une note ne dit pas tout. Une colonne d’effet peut faire glisser sa hauteur, créer un vibrato, rejouer le sample, modifier le volume ou envoyer la lecture vers un autre pattern. Ces commandes constituent une véritable couche de programmation musicale exécutée tick après tick.
Dans un tracker, le temps ne se résume pas à un simple BPM. Le moteur avance à travers une séquence de patterns, de lignes et de ticks. Comprendre cette horloge interne permet d’expliquer le rythme, les effets et une grande partie du comportement particulier des fichiers MOD et XM.
Le MOD avait posé les fondations, mais FastTracker II voulait aller beaucoup plus loin. Avec XM, le module gagne des instruments multisamples, des enveloppes de volume et de panoramique, davantage de canaux et une structure capable de conserver une composition bien plus expressive.
FastTracker II a transformé l’écran DOS en véritable studio de composition. Patterns verticaux, instruments, samples, enveloppes, effets et raccourcis clavier forment un workflow où la musique se construit presque comme du code. Découvrons la logique de FT2 et pourquoi elle reste fascinante aujourd’hui.
Que trouve-t-on réellement à l’intérieur d’un fichier MOD ? Derrière l’extension se cache une organisation précise : titre, descriptions des samples, table d’ordre, patterns, canaux, notes, effets et données audio. Ouvrons conceptuellement le module pour comprendre comment un lecteur reconstruit la musique.
Avant FastTracker II, XM et les trackers modernes, une idée décisive s'impose sur Amiga : construire un morceau avec des échantillons, des canaux, des patterns et une séquence de lecture. Retour aux fondations de la musique tracker et au format MOD.
Avant le streaming et les stations audio modernes, les trackers ont proposé une autre manière de composer : assembler des échantillons, des notes, des patterns et des commandes que le lecteur interprète en temps réel. Une logique musicale proche à la fois de la partition, du séquenceur et du programme.