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 (cinquième partie)
(Article écrit par Daniel Jedlicka et extrait de Rear Window - décembre 2022)
|
|
Note : traduction par David Brunet.
Tout ce que je veux pour Noël, c'est Rave
En septembre 2022, après avoir publié trois versions de mon éditeur audio
Rave, cela sur une période
de trois mois, j'ai ressenti le besoin d'une petite pause dans la programmation. J'ai utilisé le temps
libre que je m'étais imposé pour rattraper mon retard en matière de lecture, et j'ai donc finalement
réussi à lire les derniers numéros d'Amiga Future
et d'Amiga Addict, qui s'étaient accumulés dans ma
chambre depuis le début de l'année. Je suis également allé au rassemblement Amiga37 en Allemagne et
je me suis beaucoup amusé, comme je l'ai raconté
précédemment.
Mais à l'approche des fêtes de fin d'année, j'ai pensé qu'il serait bon de préparer une version de Rave pour Noël.
Dans le milieu AmigaOS 4, il y a toujours beaucoup d'attente autour de Noël, et avec les mises à jour
du système d'exploitation qui ne sont plus une évidence, l'attention s'est déplacée vers les sorties de
logiciels. Le développeur est devenu par inadvertance une sorte de Père Noël, je ne voulais donc pas
décevoir et laisser les souliers de Noël de mes utilisateurs vides. Mon seul problème était de savoir
quelles fonctionnalités je pouvais implémenter de manière réaliste dans un délai relativement limité.
Après réflexion, j'ai opté pour deux nouvelles fonctionnalités qui formeront le coeur de la mise à jour 1.4,
que j'ai programmée pour le 25 décembre (bien sûr).
Une fonctionnalité particulière qui n'a pas été intégrée dans les versions initiales de Rave est le
rééchantillonnage, c'est-à-dire la modification du taux d'échantillonnage (ou fréquence d'échantillonnage)
des données audio. Je ne l'ai pas considéré comme une priorité absolue car le matériel sonore typique
d'aujourd'hui n'est plus un mélange de formats de données et de propriétés comme c'était le cas dans les
années 1990. Des logiciels de musique comme Audio
Evolution ou MilkyTracker
importent volontiers des sons disponibles auprès des principaux fournisseurs d'échantillons comme
Loopmasters, ce qui rend le
rééchantillonnage quelque peu superflu. Mais comme un utilisateur l'a fait remarquer à juste titre dans
un commentaire du forum, les musiciens de la vieille école, utilisant des éditeurs musicaux par piste,
seront moins ravis car les programmes Amiga du type ProTracker
utilisent souvent des données audio échantillonnées
entre 8 et 16 kHz. Je dois admettre que produire des "échantillons pour les éditeurs musicaux par piste"
à partir de bibliothèques de sons modernes peut être un défi en l'absence d'une fonction de rééchantillonnage
dédiée.
Mes lecteurs savent que je développe Rave dans le but d'apporter des innovations à l'édition audio sur
Amiga. Par conséquent, je suis à l'affût de tous les standards de l'industrie et des bonnes pratiques qui
peuvent être transférés des principales plates-formes, plutôt que d'essayer d'inventer mes propres solutions
bancales. Pour le rééchantillonnage, j'avais l'oeil sur libsamplerate,
une bibliothèque C indépendante de
la plate-forme qui est connue pour fournir des conversions de fréquence d'échantillonnage de haute qualité.
J'ai même trouvé un vieux portage AmigaOS 4 de la bibliothèque réalisé par Daniel Beorchia en 2008, mais
je me suis découragé en voyant que, pour l'utiliser, je devais soit payer une licence de 1000 dollars
australiens (ouille !), soit publier Rave sous GPL (ouille ! ouille !). Heureusement, en visitant le site Web
de l'auteur, j'ai découvert que la licence avait changé entre-temps, et que je n'avais donc plus à me soucier
de ces restrictions. L'inarrêtable Fredrik Wikström s'est empressé de fournir un nouveau
portage, et début
décembre 2022, j'ai commencé à travailler sur l'implémentation.
La fenêtre de rééchantillonnage
J'ai écrit le rééchantillonneur de Rave comme un module de programme indépendant, qui peut effectuer des conversions
de fréquence d'échantillonnage ainsi que de profondeur de bits. Je trouve cela pratique car si vous avez, par
exemple, un échantillon en 24 bits/44,1 kHz que vous voulez convertir en 8 bits/16 kHz, vous pouvez le faire
à partir d'une seule fenêtre (voir ci-dessus). La conversion de la fréquence d'échantillonnage gère à la
fois le sous-échantillonnage et le suréchantillonnage, et libsamplerate brille vraiment ici. Contrairement à la
plupart des autres éditeurs audio Amiga, le suréchantillonnage dans Rave peut réellement améliorer la qualité du
son, car les filtres d'interpolation de la bibliothèque essaient de reconstruire le signal qui aurait été obtenu
en échantillonnant à un taux plus élevé.
Vous avez le choix entre quatre options de qualité, qui influent sur la précision et la vitesse de la conversion.
L'option "Best" propose logiquement la meilleure qualité mais elle est vraiment très lente : sur une piste
audio complète, l'opération peut prendre plusieurs minutes, même sur un AmigaOne X5000 ! En revanche, l'option
"Low" (qui déclenche un convertisseur basé sur une simple interpolation linéaire) est très rapide mais sacrifie
la qualité. Le réglage par défaut est "Good" - un compromis raisonnable entre qualité et vitesse. Je dois également
ajouter que le module de rééchantillonnage fonctionne de manière asynchrone et ne bloque pas l'éditeur, donc si
la conversion prend plus de temps que vous ne le souhaitez, vous pouvez toujours passer à un autre projet et
l'éditer pendant ce temps.
En même temps, je travaillais sur l'autre fonctionnalité que j'avais prévu d'inclure dans la mise à jour 1.4.
Mon objectif était de retravailler et d'améliorer le greffon Fade. "Attendez une minute", diront certains
d'entre vous, "que peut-on bien améliorer avec le fondu ? Je croyais qu'il s'agissait d'une simple
fonction qui produit une augmentation ou une diminution progressive du niveau du signal ?".
Vous avez raison, il n'est pas nécessaire d'être un ingénieur du son chevronné pour avoir une expérience
pratique du fondu. Que vous ayez besoin de supprimer ce clic désagréable au début d'un échantillon ou que
vous vouliez donner à votre musique une fin douce, il y a de fortes chances que vous ayez lancé votre
éditeur audio préféré et utilisé la fonction fondu entrant/fondu sortant. Si vous avez utilisé votre Amiga pour
faire cela, je suis presque sûr que votre éditeur a produit un fondu linéaire, vous laissant avec une
courbe de signal qui augmente ou diminue de façon parfaitement régulière. Quelque chose comme ceci :
Un échantillon d'oscillateur Moog Mother-32 avec des fondus linéaires créé dans AmiSoundEd
Le problème est que si la régularité plaira à un mathématicien, l'oreille humaine sera peut-être moins
impressionnée. Avez-vous déjà eu l'impression que les fondus enchaînés que vous appliquez à la fin de vos
morceaux sont un peu trop rapides ou abrupts, par rapport aux morceaux que vous entendez sur
les albums ? C'est parce que vos oreilles vous jouent un petit tour. Si vous augmentez ou diminuez le
niveau du signal (que nous percevons comme un volume) le long d'une courbe linéaire, l'oreille l'entendra
comme si le niveau sonore changeait de manière exponentielle. Les éditeurs audio numériques doivent compenser
ce phénomène s'ils veulent que leurs fondus aient un son naturel. Mais le font-ils ? Sur Amiga, je veux dire.
Sauf erreur de ma part, le seul éditeur qui permet de configurer la courbe de fondu est
SoundFX, par l'application d'un modulateur :
Fondu dans SoundFX : la commande Amplify avec une courbe de modulation
Mais tout cela est plutôt technique et difficile à mettre en place ; je voulais quelque chose d'un peu plus
intuitif et plus facile à utiliser. Pour commencer, j'ai introduit deux courbes de fondu non linéaires prédéfinies
pour compléter la courbe linéaire existante. Ma préférée est la "cloche Cosinus", qui applique la moitié de
la fonction fenêtre de Hann
au signal, produisant une transition douce entre zéro et l'amplitude maximale. Une
alternative est le "lobe sinusoïdal" (basé sur la fenêtre de Riemann) avec un début légèrement plus lent et
une progression plus directe. Je peux imaginer qu'à l'avenir, j'ajouterai quelques options supplémentaires, ou
mieux encore, un élément de contrôle permettant de régler avec précision la pente de la courbe de fondu. Mais pour
l'instant, je dirais que le greffon fait le travail assez bien - voir l'image ci-dessous, qui montre trois types
différents de fondus sortants appliqués au même échantillon :
Options de fondu sortant. A gauche : "Linéaire", au milieu : "Cloche cosinus", droite : "Lobe sinus"
Une dernière chose. Comme je voulais que le nouveau greffon Fade soit convivial, j'ai pensé qu'il serait
bien que la fenêtre de ce greffon fournisse également une visualisation de la courbe du fondu, pour donner
à l'utilisateur une meilleure idée du résultat. Pour cela, j'ai écrit un gadget
BOOPSI personnalisé qui
affiche des formes et des courbes simples. Rien d'extraordinaire pour le moment, mais je trouve que c'est
un ajout bienvenu. Au fur et à mesure que Rave recevra plus de fonctions et de greffons, je m'attends à ce
que le gadget soit davantage utilisé dans le programme ; par exemple, il pourrait afficher diverses courbes
d'oscillateur dans de futurs greffons qui génèreront du son par synthèse ou autre...
Le nouveau greffon Fade
Comme tout développeur de logiciels vous le dira, l'écriture d'applications informatiques peut souvent prendre
des tournures inattendues. Alors que je pensais avoir tout le nécessaire pour la version 1.4, j'ai reçu une
demande de fonctionnalité de la part d'un de mes utilisateurs. L'expérience m'a appris à être très prudent avec
les demandes de fonctionnalités et à ne pas essayer de satisfaire tout le monde. Parce que si vous le faites,
le développement perdra rapidement de son intérêt et deviendra incontrôlable. Les nouvelles fonctionnalités
améliorent votre programme, mais elles entraînent également un surcroît de travail, des coûts supplémentaires
et un report de la date de sortie. J'essaie donc toujours de me demander d'abord si une fonctionnalité particulière
va vraiment contribuer à améliorer le processus de travail.
De plus, les utilisateurs finissent parfois par ne pas utiliser les fonctionnalités qu'ils ont demandées. Un
ingénieur logiciel m'a dit un jour qu'il fallait se méfier de ce qu'il appelait les "parachutistes",
c'est-à-dire des utilisateurs qui sortent de nulle part pour demander instamment une fonctionnalité, avant
de disparaître et d'oublier l'existence de votre programme au bout d'une semaine. J'ai fait ma propre expérience
avec un "parachutiste" il y a des années lorsque je travaillais sur le convertisseur de CD
ADRipper, que j'avais
repris de son auteur original, CentaurZ. Un utilisateur que je ne connaissais pas a demandé une nouvelle
fonctionnalité qui a nécessité une grande réécriture du programme et de son fonctionnement interne. Je me suis
épuisé dans ce travail, la sortie prévue a dû être repoussée d'un an, et quand j'ai finalement réussi à le sortir,
le gars n'était plus un utilisateur Amiga. Une grande leçon apprise !
Cette fois, la demande portait sur l'ajout d'un minuteur qui mesurerait et afficherait le temps nécessaire pour
charger ou enregistrer un fichier. Malgré les avantages potentiels, j'ai décidé de rejeter la demande pour le
moment, car je ne voulais pas compromettre la sortie de la version de Noël. Mais l'utilisateur, Mikael, a
rapidement envoyé un don via ma page Ko-fi pour me montrer qu'il était sérieux et nous avons commencé à discuter
de la fonctionnalité sur Discord. L'implémentation de la minuterie n'était pas un problème ; le problème était
de savoir où exactement afficher la lecture dans l'interface graphique du programme. Mikael a suggéré une
requête d'informations mais cela ne fonctionnerait pas car Rave est asynchrone. Dans une session multi-projets,
des opérations peuvent avoir lieu simultanément en arrière-plan, de sorte qu'une requête pourrait prêter à
confusion quant au projet auquel il se réfère réellement. Mais j'ai promis de réfléchir davantage à la question.
Le lendemain, j'ai eu l'idée que chaque projet tienne un journal d'activité pour enregistrer toutes les opérations
(pas seulement le chargement et la sauvegarde), même le temps de réalisation. La fenêtre "Informations"
sur le projet semblait être l'endroit le plus logique pour placer le journal, c'est donc là qu'il a été placé
après un rapide remaniement :
Le journal des activités dans la fenêtre "Informations" sur le projet
Et je dois dire que j'ai vite appris à apprécier cette nouvelle fonctionnalité ! C'est très pratique pour
tester et comparer les performances du programme sur différents systèmes AmigaOS 4 - je me demande pourquoi
je n'y ai jamais pensé avant et que je me suis plutôt contenté d'un chronomètre ?
Quoi qu'il en soit, il est 19 heures passées maintenant et il est grand temps que je mette en ligne Rave 1.4
sur OS4Depot.
J'espère que vous apprécierez cette nouvelle version, et je vous souhaite à tous un très joyeux
Noël ! Restez à l'écoute pour de nouvelles mises à jour dans la nouvelle année !
|
