Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Point de vue : Le développement de Rave (sixième partie)
(Article écrit par Daniel Jedlicka et extrait de Rear Window - février 2023)
|
|
Note : traduction par David Brunet.
Some like it raw
Lorsque vous développez des logiciels, vous êtes le plus souvent confronté à ce que l'on appelle un "dilemme
de mise en oeuvre" : une situation de type carrefour où vous devez décider de la voie à suivre. Ce qui rend
la situation délicate, c'est que, contrairement à Dean et Sal dans Sur La Route De Jack Kerouac, vous
n'êtes pas libre de faire un choix arbitraire. Les mauvaises décisions de conception ont toujours des
conséquences, souvent imprévues et généralement plus grandes que petites. Faites un mauvais pas, et vous
vous retrouvez à réécrire beaucoup de choses !
Un jour, je suis arrivé au point où mon éditeur
audio Rave avait besoin d'un chargement et d'une sauvegarde
appropriés des échantillons (pour remplacer le code provisoire basé sur les types de données que j'avais
utilisé pour les tests). J'avais développé le programme avec la modularité à l'esprit, en visant un exécutable
principal léger qui déchargeait le travail de base sur des modules externes, donc garder le chargement/sauvegarde
en dehors du programme principal était une évidence. La question était de savoir comment faire exactement cela -
comme toujours, le diable est dans les détails. Une solution possible était de développer un module ou un greffon
de chargement/sauvegarde dédié pour chaque format de fichier ; une approche qui n'est pas étrangère aux logiciels
audio Amiga puisqu'elle a été utilisée dans SoundFX et
AmiSoundEd,
entre autres. Et en effet, opter pour cette
solution semblait logique, d'autant plus que je savais que je pouvais réutiliser ou adapter l'infrastructure d'entrées/sorties
de greffons d'AmiSoundEd (dont le code source est librement
disponible).
Moi, devant un dilemme de mise en oeuvre
Mais étant donné le nombre de formats de fichiers audio que je voulais gérer, la perspective de devoir développer,
maintenir et tester une multitude de modules distincts ne m'enthousiasmait pas vraiment. J'ai donc fini par
opter pour une approche monolithique : un seul module de programme qui gère le chargement et la sauvegarde
de tous les formats de fichiers. Comme je ne peux pas consacrer tout mon temps à réinventer la roue, j'ai basé
le module sur libsndfile,
une bibliothèque audio multiplate-forme qui a également été portée sur AmigaOS 4.
Les lecteurs réguliers de mes articles se souviendront que je l'ai mentionnée dans l'un de mes
précédents rapports d'avancement.
Le choix de cette bibliothèque (qui, soit dit en passant, sert des logiciels populaires comme Adobe Audition
ou Audacity) a été une décision dont je me remercie chaque jour.
Les dilemmes de mise en oeuvre ne se terminent pas toujours aussi bien !
Sur la trentaine de types et de formats de fichiers que libsndfile peut gérer, Rave en fournit une bonne
sélection qui a récemment été portée à vingt. C'est ce que j'appelle avoir l'embarras du choix ! Et peut-être
que cette abondance de formats disponibles est la raison pour laquelle peu de gens ont remarqué que Rave
ne gérait pas l'audio brut dans ses premières versions. Je n'ai pas considéré cela comme une priorité car le
format brut ("raw") n'est pas vraiment recherché de nos jours. Ou du moins, il n'est pas très utilisé dans
la création musicale et l'industrie de l'enregistrement, où les données non formatées n'apportent aucun avantage.
Il est vrai que j'ai lu quelques messages sur des forums où des musiciens, toutes plates-formes informatiques
confondues, essayaient de recréer le "son Amiga classique" en important des échantillons des anciennes disquettes
d'échantillons SoundTracker,
dont beaucoup étaient au format brut. Mais là encore, la plupart de ces sons
légendaires (ou devrais-je dire infâmes ?) ont déjà été convertis en WAV et partagés en ligne, alors pourquoi
s'embêter avec l'importation brute ?
J'ai changé d'avis après avoir acheté un lot d'échantillons de Glitchedtones,
un fournisseur d'échantillons
spécialisé dans les effets sonores, les sons cinématiques et les enregistrements d'ambiance. Le lot
d'échantillons, appelé Data Disruption,
a été créé uniquement en prenant divers fichiers numériques -
binaires de programmes, documents, graphismes bitmap et autres - et en les important sous forme de données
brutes dans un éditeur audio pour les traiter. Cela leur donnait des sons de craquement si merveilleux
et excentriques que je voulais être capable de faire les miens, en utilisant Rave bien sûr. Et c'est ainsi
que la gestion des données brutes est apparue en haut de la liste des choses à faire et que j'ai commencé
à y travailler.
La fenêtre d'importation de fichiers brut
Un fichier brut typique est sans en-tête et il n'y a pas de suffixe standard pour identifier le format
(".raw" est souvent utilisé mais n'est pas obligatoire). Par conséquent, un programme audio n'a aucun
moyen de savoir comment reconnaître le fichier et, plus important encore, comment interpréter les données
qu'il contient : des propriétés telles que la fréquence d'échantillonnage ou le nombre de canaux doivent
être fournies par l'utilisateur. À partir de Rave 1.6, tout type de fichier que le programme ne reconnaît
pas peut maintenant être chargé, à l'aide de la fenêtre d'importation illustrée ci-dessus. La beauté
cachée du brut est que l'importation d'un même fichier avec des propriétés différentes produira une forme
d'onde différente, ce qui ouvre la voie à l'expérimentation. Le résultat est souvent un bruit bizarre et
il peut falloir beaucoup d'essais pour découvrir quelque chose de vaguement musical ou percussif, alors
armez-vous de patience. Votre récompense sera un son intéressant et unique qui méritera peut-être d'être
ajouté à votre collection d'échantillons.
Vous remarquerez sans doute que la plupart des nouvelles fonctionnalités et améliorations de la version 1.6
sont liées au chargement et à l'enregistrement des fichiers. Outre l'ajout de l'importation et de l'exportation
de données brutes, j'ai aussi complètement réécrit la sauvegarde en IFF-8SVX. Pendant les tests, il s'est
avéré que les fichiers IFF produits par libsndfile étaient considérés comme corrompus par plusieurs programmes
audio, notamment OctaMED Soundstudio, MilkyTracker
et AmiSoundEd. Je n'ai aucune idée de la raison pour laquelle
c'était le cas, car libsndfile est par ailleurs très fiable, testé par des milliers d'utilisateurs dans le monde
chaque jour. La situation était la pire avec MilkyTracker car alors que les deux autres programmes affichaient
simplement un message d'erreur, le logiciel se bloquait dans une boucle sans fin en essayant de charger l'échantillon.
Comme MilkyTracker est actuellement mon principal outil de composition sur Amiga et que je l'ai beaucoup
recommandé, vous pouvez imaginer à quel point j'étais impatient de résoudre ce problème.
Je me suis donc assis et j'ai écrit mon propre code de sauvegarde IFF qui contourne libsndfile, et je suis
heureux de vous annoncer que les fichiers résultants s'ouvrent maintenant avec succès dans les trois programmes
mentionnés ci-dessus. La nouvelle implémentation s'accompagne également d'un petit bonus : les fichiers IFF-8SVX
peuvent enfin être enregistrés en stéréo ! C'était impossible auparavant car le format IFF organise les données
stéréo d'une manière pour laquelle libsndfile n'est pas conçu. Personnellement, je n'ai pas beaucoup d'utilité
pour ces fichiers, mais le format IFF a un lien si fort avec l'Amiga qu'il était impensable de le laisser à moitié
gérer.
C'est fait ! Vous ne verrez plus jamais ce message d'erreur
Depuis quelque temps, j'essayais également d'activer l'enregistrement au format
Ogg Vorbis (pour offrir une
alternative au MP3 et au FLAC) mais, pour des raisons qui m'étaient alors inconnues, j'invitais toujours le
Grim Reaper. Lors d'une tentative récente et plus sérieuse de le faire fonctionner, j'ai réussi à localiser
l'origine du plantage : il semblait s'agir d'un problème dans l'une des bibliothèques portées. Mais en inspectant
le code source, je n'arrivais pas à voir ce que la fonction de la bibliothèque en question faisait de mal.
Heureusement, Fredrik Wikström - qui avait porté la plupart des bibliothèques utilisées par Rave - a proposé de
jeter un coup d'oeil au code et au fichier journal. Pour moi, lire un fichier journal de Grim Reaper, c'est
comme lire Heidegger, mais Fredrik Wikström est bien plus expérimenté, et il ne lui a pas fallu longtemps pour
découvrir que la fonction drainait ma pile en faisant des allocations de mémoire plutôt aventureuses. Comme
AmigaDOS n'a pas d'élargissement automatique de la pile, une telle situation se termine malheureusement par un
plantage. Bien sûr, je pouvais simplement augmenter la taille de la pile du programme, mais Fredrik Wikström
a eu une meilleure idée : il a réécrit le code concerné pour le rendre plus "respectueux de l'Amiga" et m'a
envoyé une nouvelle version de la bibliothèque. Et voilà, l'enregistrement en Ogg Vorbis a fonctionné sans problème !
La fenêtre de configuration de la sauvegarde en Ogg Vorbis
Il est temps de conclure, je suppose ; mon moment préféré. Aucune épidémie de cécité n'a été signalée ces
derniers temps, et je suis sûr que les utilisateurs Amiga ont remarqué la série de sorties de Rave depuis
la première introduction publique du programme il y a neuf mois. Bien que le développement absorbe la majeure
partie de mon temps libre, j'aimerais poursuivre cette tendance : je préfère ne pas accumuler de nouvelles
fonctionnalités et, au contraire, publier dès que j'ai quelque chose d'utile à montrer. Maintenant, je pense
que j'en ai mis assez pour appeler cela une mise à jour, donc je ferais mieux de peaufiner la
documentation,
de préparer l'archive de distribution et de sortir la version 1.6 !
|
