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 (quatrième partie B)
(Article écrit par Daniel Jedlicka et extrait de Rear Window - septembre 2022)
|
|
Note : traduction par David Brunet.
Merci pour la mémoire
Lorsque Hyperion Entertainment a annoncé dans un article
de 2014 de son blog qu'AmigaOS 4 allait bénéficier
d'une gestion pour accéder à la mémoire au-delà de la limite de 2 Go, les réactions ont été mitigées. Comme
on pouvait s'y attendre, les commentaires les plus acerbes sont venus de personnes qui n'avaient jamais
possédé de système AmigaOS 4, mais le camp des supporters ne semblait pas non plus ravi. Peut-être que le
titre de l'article ("Casser la barrière de la mémoire") semblait trop prometteur, et que la réalité n'était
pas à la hauteur des attentes suscitées. Mais il y aurait probablement eu moins de déception si les gens
n'avaient pas trop interprété le titre et avaient plutôt pris la fonctionnalité pour ce qu'elle est réellement.
Parce que les objets de mémoire étendue ("Extended Memory Objects" ou ExtMem, comme la fonctionnalité est
communément appelée) n'ont jamais été présentés comme autre chose qu'un pis-aller. Ou bien quelqu'un s'attendait-il
sérieusement à ce qu'AmigaOS adopte miraculeusement l'adressage mémoire 64 bits ?
Cependant, les solutions provisoires sur AmigaOS ont tendance à devenir silencieusement des fonctionnalités
permanentes (prenez AHI, par exemple), donc huit ans après l'annonce de Hyperion, nous n'avons toujours pas
de meilleure solution. Pire encore, l'adoption de la fonctionnalité semble avoir été assez lente : le disque
RAM du système (adapté pour ExtMem par Colin Wenzel) et SketchBlock
d'Andy Broad sont les seules applications
concrètes de la fonctionnalité que je connaisse. La principale raison pour laquelle les programmeurs ne se
précipitent pas pour l'utiliser est probablement les limitations inhérentes à cette fonctionnalité; car, comme
les critiques aiment le répéter, ExtMem est fondamentalement un retour à l'ancienne pratique de
changement de banque
que nous connaissons depuis l'ère des micro-ordinateurs. C'est ringard et technologiquement inepte,
n'est-ce pas ?
Comme la plupart des logiciels audio, mon éditeur audio Rave
peut être très gourmand en mémoire. Les formats
compressés populaires tels que MP3 et la pratique de la lecture en continu ont détourné notre attention du
fait que les données audio d'aujourd'hui peuvent facilement prendre des centaines de mégaoctets lorsqu'elles
sont décompressées dans la mémoire de l'ordinateur. Cela peut être un problème sur un système 32 bits comme
l'Amiga. J'étais donc naturellement curieux de savoir si ExtMem pouvait m'aider à relever certains des défis
auxquels je faisais face. Et il ne m'a pas fallu longtemps pour commencer à chercher dans une direction particulière.
Après la sortie de la première version de Rave, les retours des utilisateurs ont clairement montré que la
fonctionnalité la plus demandée était la fonction "Undo" (Annuler), c'est-à-dire la possibilité d'annuler les
modifications apportées à la forme d'onde. Ce n'est pas une grande surprise : honnêtement, si j'étais à la
place de mes utilisateurs, je serais l'un des premiers à souligner l'omission d'une fonctionnalité aussi
importante ! Mais il est intéressant de voir à quel point nous en sommes venus à considérer la fonction "Annuler"
comme acquise, car, croyez-le ou non, un éditeur audio Amiga doté de telles fonctionnalités est loin d'être
acquis. J'ai récemment lancé un certain nombre de programmes de manipulation audio qui étaient populaires à
l'époque. J'étais curieux de savoir comment mon nouveau-né Rave se compare à eux, et je voulais spécifiquement
voir comment ils implémentent la fonction "Annuler", en espérant trouver de l'inspiration.
Aegis Audiomaster et Digital Sound Studio étaient mes éditeurs
d'échantillons de référence dans les années 1990
Les résultats de mes petites recherches ont été pour le moins surprenants. Sur les dix programmes que j'ai
examinés, seuls trois proposaient une fonction d'annulation dédiée - et une seule des implémentations
d'annulation que je qualifierais d'utile. Pour faire court, j'ai résumé mes conclusions dans un tableau :
| Programme |
Version |
Date |
Implémentation d'annuler |
| Aegis Audiomaster IV |
1.0 |
1991 |
Pas d'annulation |
| Megalosoud |
1.35 |
1993 |
Annulation en une seule étape, les données sont
stockées dans la RAM |
| GVP Digital SOund Studio |
3.0b |
1994 |
Pas d'annulation |
| Samplitude Opus |
3.5 R9-5 |
1997 |
Pas d'annulation |
| SoundProbe |
2.11 |
1998 |
Annulation en une seule étape, les données sont stockées dans la RAM |
| SampleE |
4.08 |
2000 |
Pas d'annulation |
| SoundFX |
4.3 |
2004 |
Pas de véritable annulation : les échantillons modifiés sont stockés en
tant que nouveaux projets (ce qui consomme beaucoup de mémoire et augmente l'encombrement de l'écran) |
| Samplemanager |
1.6 |
2005 |
Annulation illimitée, les données sont stockées sur le disque sous forme de fichiers temporaires |
| AmiSoundEd |
0.12 |
2009 |
Pas d'annulation |
| SampleZ |
0.15 alpha |
2021 |
Pas d'annulation |
Et le gagnant est (roulement de tambour) : Samplemanager de Thilo Köhler !
Même si je n'ai pas envie de montrer ce tableau à mes amis PCistes, les résultats m'ont redonné le moral
car j'ai réalisé que beaucoup de mes prédécesseurs se sont gratté la tête sur la même chose que moi.
Ils ont également confirmé ma petite théorie selon laquelle l'implémentation de la fonction "Annuler"
n'est pas vraiment simple du point de vue du développeur. L'utilisateur peut penser qu'il suffit de vider
les données d'échantillon dans une mémoire tampon et de les rappeler en cas de besoin, mais ce n'est vraiment
pas aussi simple que cela, surtout si vous voulez le faire correctement.
D'un autre côté, je savais que j'étais dans une position différente avec les possibilités matérielles de la
prochaine génération Amiga. Je me disais : si Samplemanager fonctionnait sur un Amiga classique il y a dix-sept
ans, pourquoi devrais-je m'inquiéter sur un système AmigaOS 4 avec une mémoire et un accès au disque beaucoup
plus rapides ?
Samplemanager de Thilo Köhler, un compagnon du séquenceur HD-Rec de l'auteur
Les tests préliminaires effectués sur mes deux systèmes Amiga, un AmigaOne X5000 et une Sam440ep Flex,
ont montré qu'une solution basée sur disque serait plus que suffisante, j'ai donc décidé de suivre cette
voie. J'ai écarté l'idée que la fonction "Annuler" stockerait les données dans la mémoire système normale.
Imaginez une session avec dix projets audio haute définition ouverts, chacun conservant un historique
d'édition distinct, chacun consommant une partie de la RAM à chaque fois que vous effectuez une modification
destructrice. Le simple fait de penser à l'empreinte mémoire me fait frémir ! (bien sûr, je pourrais limiter
l'historique à, disons, dix étapes pour éviter que les choses ne dégénèrent. C'est certainement une grande
amélioration par rapport à l'absence totale de fonction "Annuler", mais alors que j'essaie de défendre
AmigaOS 4 et son logiciel, je n'ai guère de pitié pour les solutions à moitié élaborées).
Malgré tout, avec 4 Go de mémoire installés dans l'AmigaOne X5000, j'étais intrigué par l'idée d'essayer
ExtMem car ce que j'avais lu dans la documentation
semblait encourageant, malgré les "vilaines"
limitations qui gâchent la fête pour les puristes. Quelles sont-elles, en fait ? Par nature, AmigaOS
ne peut pas adresser plus de quatre gigaoctets de RAM, ce qui laisse environ 2 Go d'espace adressable
pour l'utilisation des applications. Le cadre d'application ExtMem permet aux applications de stocker
plus de données que cela, en divisant les données en blocs (objets ExtMem) qui sont stockés dans la
mémoire physique au-delà de la limite d'adressage. Le compromis est que tous les blocs de mémoire ne seront
pas disponibles à un moment donné. En effet, un tel bloc doit d'abord être adressé dans la mémoire système,
en acquérant une adresse dans la plage de 2 Go pour la durée d'utilisation du bloc. S'il n'y a pas assez
de RAM pour adresser les autres blocs, ils doivent rester non adressés (et inaccessibles) dans le vide
électronique.
Cette limitation ne m'a pas vraiment dérangé car, en raison du fonctionnement de la fonction "Annuler",
une seule donnée est nécessaire pour chaque étape précédente. En fait, comme Andy Broad me l'a expliqué,
la clé pour utiliser ExtMem efficacement est de s'assurer qu'un bloc de mémoire n'est jamais adressé
à moins qu'il ne soit immédiatement nécessaire pour la lecture ou l'écriture. Le programmeur doit donc
anticiper et garder les éléments de mémoire organisés et hiérarchisés.
Sachant cela, j'avais toutes les informations nécessaires pour écrire deux morceaux de code d'annulation
analogiques, l'un pour ExtMem et l'autre impliquant le stockage sur disque. Le résultat est un système
double, qui présente plusieurs avantages. Surtout, les utilisateurs d'AmigaOS 4 avec plus de 2 Go de RAM
installés sur leur ordinateur peuvent utiliser la mémoire supplémentaire, qui autrement resterait un espace
mort. Ils gagnent également en vitesse car bien que l'adressage d'un objet ExtMem implique une surcharge processeur,
il est toujours plus rapide que l'écriture sur disque. En même temps, la solution basée sur le disque est
suffisamment bonne et fournit des annulations illimitées même sur des systèmes d'entrée de gamme tels que la
Sam440. Elle fonctionne également comme solution de secours dans les situations où l'enregistrement dans
la mémoire étendue échoue parce qu'il n'y a pas assez de mémoire libre pour adresser le bloc : dans ce cas,
Rave stockera simplement les données sur le disque.
Maintenant que la version 1.3 est disponible,
je vous souhaite à tous un bon déblocage ! J'espère également
que le cadre d'application ExtMem sera davantage utilisé dans la vie réelle pour prouver son potentiel,
et que les programmeurs AmigaOS 4 trouveront des moyens de l'adopter utilement dans leurs programmes. Je
pense qu'il est temps de dissiper l'idée fausse selon laquelle il n'existe aucun logiciel permettant
d'exploiter la puissance et les ressources supplémentaires présentes dans des machines telles que l'AmigaOne
X1000 ou X5000. Il existe désormais un logiciel, et je suis sûr qu'il en existera d'autres à l'avenir.
|
