Les fichiers MOD sont basés sur deux choses: des "samples" (échantillons sonores, qui peuvent être rejoués à différentes fréquences pour jouer des notes différentes), et des "patterns" (qui indiquent quel sample jouer à quel moment, à quelle fréquence, à quel volume, etc).
Sur Amiga, la partie "sample" est gérée par le matériel: on dispose de 4 canaux (2 à droite et 2 à gauche sur la sortie stéréo) alimentés par des DMA, avec un réglage du volume et de la fréquence.
Toute la difficulté est donc la gestion des "patterns". Les fichiers MOD ont un format simple sous forme d'une liste de notes, chacune associée à un numéro de sample, un volume et un effet spécial. Un lecteur de musique MOD classique va directement lire ce format (ou une variante simplifiée ou compressée) et calculer en temps réel les fréquences, volumes, etc correspondants (les "effets" pouvant modifier les valeurs par rapport à ce qui est indiqué dans la liste de départ du pattern).
Ce que fait LSPlayer, c'est de précalculer à l'avance tout ça. Les patterns sont donc remplacés par une liste d'évènements de type:
Temps 0: lancer le sample à l'adresse X, sur le cannal A, avec un volume 7 et une fréquence N
Temps 1: changer le volume du canal A à 6
Temps 10: changer la fréquence du canal A à N+2
...
Ainsi, le player proprement dit n'a plus aucun calcul à faire, seulement à programmer ces valeurs directement dans les canaux DMA et la puce son.
Le compromis est qu'une telle liste va peut-être occuper plus de mémoire que le fichier original. Mais, en pratique, le format MOD n'est déjà pas très compact, et en plus, de toutes façons, la plus grande partie de la mémoire nécessaire est occupée par les samples. C'est donc un tr`s bon compromis finalement.
Leonard n'en est pas à son coup d'essai sur le sujet: cette technique est en fait assez directement inspirée de ce qu'il avait déjà fait il y a plusieurs dizaines d'années avec les fichiers YM permettant de faire la même chose, mais avec la puce son de l'Atari ST: stocker directement la liste des valeurs à programmer dans la puce, plutôt que de les calculer en temps réel à partir de données plus haut niveau.
Reste un dernier problème: la version pour Atari ST du player doit s'adapter à un matériel complètement différent, pas du tout pensé pour jouer des fichiers MOD (ou plutôt, l'inverse: les fichiers MOD ont été conçus en accord avec les spécificités de l'Amiga). Là, je n'ai pas regardé quelles astuces et tours de magie sont exploités pour y parvenir. En principe il faut faire logiciellement le mixage, car il n'y a que 2 canaux DMA au lieu de 4, et si je me souviens bien, en plus, leur fréquence n'est pas configurable (ça c'est pour l'Atari STe et Falcon, pour les machines précédentes, c'est encore pire).
# Détails techniques
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Amiga + Mac + Linux MOD player en ASM !!!. Évalué à 10.
Un résumé rapide du principe de ce player.
Les fichiers MOD sont basés sur deux choses: des "samples" (échantillons sonores, qui peuvent être rejoués à différentes fréquences pour jouer des notes différentes), et des "patterns" (qui indiquent quel sample jouer à quel moment, à quelle fréquence, à quel volume, etc).
Sur Amiga, la partie "sample" est gérée par le matériel: on dispose de 4 canaux (2 à droite et 2 à gauche sur la sortie stéréo) alimentés par des DMA, avec un réglage du volume et de la fréquence.
Toute la difficulté est donc la gestion des "patterns". Les fichiers MOD ont un format simple sous forme d'une liste de notes, chacune associée à un numéro de sample, un volume et un effet spécial. Un lecteur de musique MOD classique va directement lire ce format (ou une variante simplifiée ou compressée) et calculer en temps réel les fréquences, volumes, etc correspondants (les "effets" pouvant modifier les valeurs par rapport à ce qui est indiqué dans la liste de départ du pattern).
Ce que fait LSPlayer, c'est de précalculer à l'avance tout ça. Les patterns sont donc remplacés par une liste d'évènements de type:
Ainsi, le player proprement dit n'a plus aucun calcul à faire, seulement à programmer ces valeurs directement dans les canaux DMA et la puce son.
Le compromis est qu'une telle liste va peut-être occuper plus de mémoire que le fichier original. Mais, en pratique, le format MOD n'est déjà pas très compact, et en plus, de toutes façons, la plus grande partie de la mémoire nécessaire est occupée par les samples. C'est donc un tr`s bon compromis finalement.
Leonard n'en est pas à son coup d'essai sur le sujet: cette technique est en fait assez directement inspirée de ce qu'il avait déjà fait il y a plusieurs dizaines d'années avec les fichiers YM permettant de faire la même chose, mais avec la puce son de l'Atari ST: stocker directement la liste des valeurs à programmer dans la puce, plutôt que de les calculer en temps réel à partir de données plus haut niveau.
Reste un dernier problème: la version pour Atari ST du player doit s'adapter à un matériel complètement différent, pas du tout pensé pour jouer des fichiers MOD (ou plutôt, l'inverse: les fichiers MOD ont été conçus en accord avec les spécificités de l'Amiga). Là, je n'ai pas regardé quelles astuces et tours de magie sont exploités pour y parvenir. En principe il faut faire logiciellement le mixage, car il n'y a que 2 canaux DMA au lieu de 4, et si je me souviens bien, en plus, leur fréquence n'est pas configurable (ça c'est pour l'Atari STe et Falcon, pour les machines précédentes, c'est encore pire).