Dans NAM mise en œuvre première partie, nous avons exploré les différents types de modèles et présenté les principaux chargeurs logiciel et matériels disponibles actuellement. Dans cette seconde partie, nous allons présenter les différentes architectures de modèles NAM, après une petite présentation du vocabulaire associé au système NAM. On fera ensuite un point pratique sur les ressources nécessaires pour pouvoir utiliser les modèles NAM « live ». Un pack de modèles en téléchargement est par ailleurs associé à cet article afin de réaliser vos propres tests avec différentes architectures de modèles, si vous le souhaitez.
Wavenet, epochs et ESR
NAM repose sur une approche de deep learning appliquée à l’audio : un modèle NAM va produire un signal de sortie à partir d’un signal d’entrée après avoir été entrainé pour cela. Et pour ce faire, NAM s’appuie principalement sur le système Wavenet. Celui-ci à originalement été développé et mis au point par Deepmind (filiale de Google) vers 2016, et son premier champs d’application était la génération audio et plus particulièrement des applications dans le domaine de la synthèse vocale comme le text-to-speech (https://en.wikipedia.org/wiki/WaveNet). Vu d’avion, Wavenet mis en oeuvre avec NAM permet de prédire une valeur de sortie à partir d’une valeur d’entrée à travers l’utilisation d’un modèle. On génère ce modèle par apprentissage à partir d’un jeu de données source (fichier « input ») et d’un jeu de données cible, c’est à dire le résultat obtenu en envoyant le signal source à l’ampli ou à la pédale (ce qui constitue le fichier « output« ). L’apprentissage est réalisé à travers le programme « trainer » de NAM, qui construit le modèle à travers l’exécution de multiples itérations (epochs).
Le modèle obtenu réalise ses prédictions (i.e. la reproduction du son du matériel capturé) à partir d’un système de couches (layers) et en utilisant des paramètres régissant les dilatations (dilations en Anglais).
Dans le système par apprentissage par deep learning, on procède par itérations successives (les epochs) dans lesquelles on surveille l’évolution de l’ESR (Error-to-Signal Ratio, ou rapport d’erreur sur signal). Plus l’ESR se rapproche de 0 et plus le modèle est fidèle à l’original. L’obtention d’un ESR bas nécessite généralement un nombre relativement important d’itérations : les créateurs de modèles NAM utilisent fréquemment jusqu’à 800 ou 1000 epochs. Au delà d’un certain nombre d’itérations, on observe généralement un plateau à partir duquel il n’est plus intéressant de continuer l’apprentissage, les gains devenant très marginaux ou nuls au regard des couts en temps et en GPU.
Concernant l’ESR, voici quelques points de repères inspirés par la page de MOD Audio décrivant les best practices autour des captures AIDA-X (https://mod.audio/modeling-amps-and-pedals-for-the-aida-x-plugin-best-practices/) et que j’ai repris et légèrement aménagés pour les transposer à NAM :
- ESR <= 0.01 : excellente précision, le modèle est très fidèle
- 0.01 < ESR ≤ 0.05 : très bonne précision, le modèle est fidèle
- 0.05 < ESR ≤ 0.15 : bon compromis qualité/utilisation, modèle encore assez fidèle.
- 0.15 < ESR ≤ 0.35 : différences perceptibles, utilisation possible mais avec prudence.
- ESR > 0.5 : modélisation très approximative, probablement non satisfaisante
- ESR > 0.9 : très éloigné, probablement inutilisable. Niveaux, réglages et alignements à vérifier.
Nous reviendrons sur cette phase de capture et d’apprentissage dans un autre article de cette série.
Pour information, les modèles NAM sont des fichiers au format JSON qui regroupent les informations du modèle lui même et une partie métadonnées qui donne au chargeur des informations sur le modèle :
Pour en savoir plus sur les clefs utilisées dans les fichiers NAM, vous pouvez explorer le contenu de fichiers .NAM par vous-même et consulter la petite documentation présente ici : https://neural-amp-modeler.readthedocs.io/en/latest/model-file.html#
Architectures NAM
Steve Atkinson à mis au point 4 jeux de paramètres, permettant de générer 4 types de modèles pour répondre à la problématique de ressources CPU nécessaires pour mettre en oeuvre les modèles NAM. Dans le vocabulaire NAM, ces types de modèles sont désignés sous le terme d » « architectures« . Le modèle NAM de base est considéré comme l’architecture « standard » : il offre un très bon niveau de fidélité, mais il peut se révéler problématique en terme de consommation CPU pour les utilisateurs disposant de machines très peu puissantes ou anciennes, et surtout pour des plates-formes propriétaires (multi-effets ou machines comme les Raspberry Pi) qui s’appuient fréquemment sur des processeurs beaucoup moins puissants que ceux des PC/MAC -voire que ceux des iPhone-, la plupart du temps pour des raisons de couts des puces et des couts d’intégration associés. S. Atkinson a donc introduit des variantes plus légères d’architectures : ce sont les modèles LITE, FEATHER (plume) et NANO. Ces variantes impactent la taille du modèle sur disque et en mémoire, ainsi que le niveau de consommation CPU nécessaire pour les faire fonctionner.
La complexité (et la fidélité) des modèles NAM est définie à travers les différentes couches et niveaux de dilatations introduits dans la section précédente. In fine, cette complexité peut se résumer à travers le nombre de paramètres gérés par le modèle NAM :
| Architecture | Parameters | Size on disk (approx). |
|---|---|---|
| STANDARD | 13800 | 280-300 KB |
| LITE | 6600 | 141 KB |
| FEATHER | 3000 | 65 KB |
| NANO | 841 | 20 KB |
La communauté d’utilisateurs NAM a également fait émerger de nouvelles architectures de modèles, principalement les modèles xStandard et Complex. Ce dernier cherche à accroitre le niveau de fidélité et, contrairement à la démarche d’allégement présenté dans le paragraphe précédent, il demande significativement plus de puissance CPU pour fonctionner :
| Architecture | Parameters | Size on disk (approx). |
|---|---|---|
| COMPLEX | 90000 | 1.9 - 2.3 MB |
| XSTANDARD | 12400 | 270 KB |
Les différences de consommation CPU sont présentées dans une section suivante de cet article et attention, pour rappel, les modèles complexes nécessitent des machines suffisamment rapides.
Si vous débutez avec NAM et/ou que vous souhaitez explorer les rendus et comportements des différentes architectures de modèles sur votre propre matériel, je vous invite à télécharger un starter pack à partir de ce lien : https://overdriven.fr/overdriven/index.php/download/nam-models-markt-15-p1-extended/
Ce pack contient 7 modèles de base (1 Clean, 1 Crunch , 3 high gains et 2 modèles boostés avec une OD) inspirés d’un ampli MT 15*. Ce pack est téléchargeable sur tone3000 (vous trouverez le lien sur la même page) mais cette version contient -outre les modèles Standard, xStandard et Complex présents sur Tone3000- les déclinaisons LITE, FEAHER et NANO, tous constitués à partir des mêmes fichiers ré-ampés. Et en bonus, ce pack contient des presets Genome pour pouvoir réaliser rapidement des essais. Les presets pointent par défaut les modèles _S (standard) mais vous pourrez les switcher à votre guise….
*Voir mention légale en bas d’article
Et voici ci-dessous un tableau des ESRs obtenus pour les différents modèles de ce pack :
| Model name | ESR | Loudness | Tone type |
|---|---|---|---|
| ODN-MarkT-15-CLEAN-02-CH1-VOL4_C.nam | 0.00114 | -17.7 | clean |
| ODN-MarkT-15-CLEAN-02-CH1-VOL4_F.nam | 0.01298 | -17.8 | clean |
| ODN-MarkT-15-CLEAN-02-CH1-VOL4_L.nam | 0.01058 | -17.8 | clean |
| ODN-MarkT-15-CLEAN-02-CH1-VOL4_N.nam | 0.01847 | -17.6 | clean |
| ODN-MarkT-15-CLEAN-02-CH1-VOL4_S.nam | 0.00416 | -17.8 | clean |
| ODN-MarkT-15-CLEAN-02-CH1-VOL4_XS.nam | 0.00477 | -17.6 | clean |
| ODN-MarkT-15-CRUNCH-01-CH2_C.nam | 0.00149 | -17.7 | crunch |
| ODN-MarkT-15-CRUNCH-01-CH2_F.nam | 0.00998 | -18.0 | crunch |
| ODN-MarkT-15-CRUNCH-01-CH2_L.nam | 0.00705 | -17.8 | crunch |
| ODN-MarkT-15-CRUNCH-01-CH2_N.nam | 0.02170 | -18.0 | crunch |
| ODN-MarkT-15-CRUNCH-01-CH2_S.nam | 0.00455 | -17.8 | crunch |
| ODN-MarkT-15-CRUNCH-01-CH2_XS.nam | 0.00434 | -17.9 | crunch |
| ODN-MarkT-15-HIGHGAIN-01-CH2-G3_C.nam | 0.00197 | -18.2 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-01-CH2-G3_F.nam | 0.01500 | -18.5 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-01-CH2-G3_L.nam | 0.00969 | -18.4 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-01-CH2-G3_N.nam | 0.03836 | -18.6 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-01-CH2-G3_S.nam | 0.00656 | -18.4 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-01-CH2-G3_XS.nam | 0.00535 | -18.4 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-02-CH2-G4_C.nam | 0.00235 | -18.3 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-02-CH2-G4_F.nam | 0.01980 | -18.7 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-02-CH2-G4_L.nam | 0.01292 | -18.6 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-02-CH2-G4_N.nam | 0.04332 | -18.9 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-02-CH2-G4_S.nam | 0.00822 | -18.6 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-02-CH2-G4_XS.nam | 0.00732 | -18.3 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-03-CH2-G5_C.nam | 0.00430 | -18.5 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-03-CH2-G5_F.nam | 0.02364 | -18.7 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-03-CH2-G5_L.nam | 0.01586 | -18.6 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-03-CH2-G5_N.nam | 0.05254 | -19.0 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-03-CH2-G5_S.nam | 0.00985 | -18.6 | hi_gain |
| ODN-MarkT-15-HIGHGAIN-03-CH2-G5_XS.nam | 0.00925 | -18.6 | hi_gain |
| ODN-MarkT-15-OD-01-CH1-VOL4_C.nam | 0.00078 | -17.6 | overdrive |
| ODN-MarkT-15-OD-01-CH1-VOL4_F.nam | 0.00521 | -17.6 | overdrive |
| ODN-MarkT-15-OD-01-CH1-VOL4_L.nam | 0.00400 | -17.7 | overdrive |
| ODN-MarkT-15-OD-01-CH1-VOL4_N.nam | 0.01296 | -17.3 | overdrive |
| ODN-MarkT-15-OD-01-CH1-VOL4_S.nam | 0.00209 | -17.6 | overdrive |
| ODN-MarkT-15-OD-01-CH1-VOL4_XS.nam | 0.00263 | -17.7 | overdrive |
| ODN-MarkT-15-OD-02-CH1-VOL4_C.nam | 0.00087 | -17.5 | overdrive |
| ODN-MarkT-15-OD-02-CH1-VOL4_F.nam | 0.00720 | -17.4 | overdrive |
| ODN-MarkT-15-OD-02-CH1-VOL4_L.nam | 0.00381 | -17.6 | overdrive |
| ODN-MarkT-15-OD-02-CH1-VOL4_N.nam | 0.01860 | -17.2 | overdrive |
| ODN-MarkT-15-OD-02-CH1-VOL4_S.nam | 0.00262 | -17.6 | overdrive |
| ODN-MarkT-15-OD-02-CH1-VOL4_XS.nam | 0.00328 | -17.6 | overdrive |
Les suffixes utilisés dans le tableau correspondent à :
- _S : Standard
- _XS : XStandard
- _C : Complex
- _L : Lite
- _F : Feather
- _N : Nano
On peut formuler deux remarques à la lecture de ce tableau :
- les architectures les plus complexes permettent d’obtenir les ESR les plus bas (les modèles les plus fidèles)
- les modèles high gain (et pire les fuzz, qui ne sont pas présentés dans cet exemple) ont des ESRs moins bons que les clean ou les crunch : ces types de sons sont en effet plus complexes à modéliser…
Si vous testez le pack exemple, vous devriez constater des différences assez flagrantes par exemple en partant du standard et en descendant vers Lite, Feather puis Nano. Pour autant, les modèles Lite et Feather ne sont pas ridicules en terme de rendu et peuvent déjà donner de bons résultats.
Dernier point : dans le cas ou l’on souhaiterait utiliser plusieurs modèles NAM simultanément (scénario d’un modèle pour une overdrive et d’un autre modèle pour un ampli), on pourra considérer l’utilisation de modèles light ou feather pour la partie pédale, les sons étant moins complexes à modéliser que ceux d’un ampli… : les modèles lite ou feather pourrait donc suffire pour produire de bons résultats…
Ressources CPU
Les informations présentées dans cette section ne sont ni exhaustives ni garanties, mais sont plutôt destinées à fournir des observations et des points de repères concernant l’utilisation des différentes architectures de modèles –dans une configuration spécifique– sur différentes catégories de machines, notamment du point de vue de la capacité à utiliser des modèles « en direct », c’est à dire de pouvoir pratiquer, répéter et potentiellement tracker ses enregistrements en temps réel, et ce soit à travers les applications NAM standalone, soit via un plugin dans une STAN. Il vous est vivement recommandé de tester par vous-meme la viabilité d’une configuration avant de vous lancer dans un achat de matériel, pour votre contexte et pour vos besoins.
Le tableau ci-dessous présente des observations de consommations CPU de l’application standalone Genome configurée spécifiquement avec une chaine simple utilisant un unique modèle NAM (voir un peu plus bas la configuration du test); et ces observations sont réalisées manuellement à partir de la lecture des informations présentées par Task Manager sous Windows et le moniteur d’activité sous OSX pour les tests sur matériels Apple. Les mesures sont des observations de valeurs « stabilisées », observées sur quelques dizaines de secondes après le chargement et l’utilisation d’un modèle NAM donné, mais notez que la consommation peut fluctuer autour des valeurs présentées.
Les pourcentages de consommation présentés sont également différents entre OSX et Windows : sur OSX, le maximum de consommation CPU est le nombre de coeurs * 100 : par exemple, sur une machine 8 coeurs le maximum est de 800%, et -par exemple- 110% représente l’utilisation d’un peu plus d’un coeur mais ne représente que 110/800 = 13,75% du total de la machine. A l’inverse, les valeurs données pour Windows sont en pourcentage de la capacité CPU totale de la machine : ainsi 20% sur une machine 4 coeurs est bien 20% du total de la capacité CPU, et notez qu’elle est également proche de la consommation maximale sur un coeur (100/4 = 25).
Attention également à l’aspect suivant : les machines les moins puissantes pourront plus facilement et plus rapidement être perturbées dès que votre système va réaliser d’autres tâches , par exemple l’exécution des systèmes de mises à jour, les scans d’antivirus/antimalware, les processus d’indexation,…ce qui peut avoir pour effet de perturber des applications audio comme NAM ou Genome standalone (interruptions, craquements, anomalies…). De manière similaire, si la machine est en limite de capacité sur le test (ie lorsqu’on se rapproche de l’utilisation d’un coeur complet de la machine), l’ajout d’autres effets pourra devenir rapidement problématique : en bref, il vaudra donc mieux avoir un peu de marge…
Notez également les points suivants, qui sont importants pour lire les mesures présentées :
- Version de Genome utilisée sous Mac et Windows : 1.10
- 1 seul et unique modèle NAM et un bloc IR loader chargé avec un mix de 2 IRs (100 ms)
- Configuration en mono (le mode stereo consomme un peu plus)
- Configuration de la carte son en 48 KHz / 128 samples : dans les tests que j’ai pu réaliser, l’utilisation de fréquences plus élevées engendre une consommation CPU significativement plus importante (downsampling/upsampling ?)
- Désactivation des animations dans Genome
- Utilisation de deux cartes sons avec pilotes ASIO sous Windows : SSL2+ MKII et Scarlett 2i2, Core Audio sous OSX.
- Oversampling de Genome désactivé (OFF)
- Et à titre d’indication, le tableau présente le score CPU Mark Single Thread du CPU rapporté par https://www.cpubenchmark.net
| OS/CPU | CPU | Complex | xStandard | Standard | Lite | Feather | Nano |
|---|---|---|---|---|---|---|---|
| OSX/M4 MAX 16C | 4562 | OK (33%) | OK (21%) | OK (20%) | OK (19%) | OK (17%) | OK (17%) |
| OSX/M1 PRO 8C | 3761 | OK (46%) | OK (30%) | OK (29%) | OK (27%) | OK (25%) | OK (23%) |
| Win11/Ryzen 6C | 2871 | OK (11-14%) | OK (3-7%) | OK (4-5%) | OK (3-4%) | OK (2-3%) | OK (2%) |
| Win11/I5-9600K 6C | 2727 | OK (15%) | OK (5%) | OK (5%) | OK (4-5%) | OK (4-5%) | OK (3-4%) |
| OSX/i5-8259U | 2190 | KO** | OK (53%) | OK (49%) | OK (44%) | OK (41%) | OK (37%) |
| Win11/N95 4C | 1927 | KO* | OK (15%) | OK (13%) | OK (12%) | OK (10%) | OK (9%) |
« * » : limite, instable, très sensible aux fluctuations : inutilisable
« ** » : 100% pour le host, 85% reporté par Genome, limite et instable
Informations complémentaires sur les CPU :
- Ryzen 6C : Ryzen 5 5625U 6C
- I5-9600K : I5-9600K @ 3.70 GHz 6C
- i5-8259U : i5-8259U @ 2.30GHz 4C
- N95 : Alder Lake N95 @ 1.70 Ghz 4C
Attention/disclaimer : dans le cadre de fréquences de travail différentes (88K, 176K…), avec des tailles de buffer plus élevées et dans le cadre de travail sous une STAN (enregistrement, mix), les puissances nécessaires peuvent être fortement différentes de celles présentées dans le tableau. Par exemple, en 176K/512 samples pour le Mac le plus ancien de la liste (8259U) , l’utilisation de modèle standard devient problématique, idem pour le xStandard sur la machine N95.
Sur des machines récentes et puissantes, les modèles les plus complexes ne posent pas de problèmes (33% pour le complexe sur le M4 Max ce qui correspond à une charge de 2% pour la machine…) et on constate qu’on arrive à faire tourner les modèles standards sur une vaste panoplie de machines, en tout cas dans les conditions du test présenté…
Alors pas de modèles xStandard ou Complex si on a pas de machine assez puissante ? Hé bien, il reste toujours la possibilité -dans le contexte de l’enregistrement et de la création de morceaux de musique- d’utiliser votre plugin NAM en offline dans votre STAN et de réaliser des bounce / freeze de vos pistes, une pratique classique lorsque l’on manipule des projets un peu complexes (en nombre de pistes et/ou en nombre de plugins) ou que l’on met à contribution des plugins qui nécessitent beaucoup de ressources. Le workflow de travail est un peu moins fluide mais il tout à fait envisageable et cela met à votre portée l’utilisation des modèles les plus fidèles même si vous ne disposez pas d’un monstre de puissance….
Conclusion
Après une introduction aux concepts fondamentaux des modèles NAM et de leur création, nous avons présenté les différentes architectures disponibles et leurs performances en terme de fidélité (ESR). La seconde partie a présenté le résultat d’observations pour donner des points de repères sur les machines et les puissances nécessaires pour faire tourner les différents types de modèles dans le contexte d’une utilisation « en direct ». Le prochain article sera consacré à un point essentiel pour tirer parti des modèles NAM : la gestion du gain.
Mention légale
Toutes les marques et tous les produits ou noms de sociétés mentionnés sur ce site et dans cet article peuvent être des marques déposées, appartenant à leurs propriétaires respectifs. Elles ne sont en aucun cas associées à Overdriven.fr ou au propriétaire d’overdriven.fr : leur mention n’implique aucun sponsoring ou association d’overdriven.fr/le propriétaire d’overdriven.fr avec ces marques. Ces marques ou noms de produits sont simplement utilisés pour décrire le matériel utilisé dans la création des profils ou modèles.
Laisser un commentaire