Top config PC MAO 2019 (test, bench, discussion, débat...)
- 1 600 réponses
- 70 participants
- 95 779 vues
- 81 followers
Darkmoon
Ce sujet est la suite logique de celui intitulé :
Top config PC MAO 2018 (test, bench, discussion, débat...)
(Dernière page ici.)
...où nous avons effectué plusieurs tests, dès le printemps 2018, concernant les nouveaux processeurs du moment, comme le i7 8700k, sous différents DAW/STAN (station de travail audio numérique).
Nous poursuivons donc ici à causer des nouveaux processeurs du moment, comme le i7 9700k et i9 9900k sous Socket 1151, ceux de la série X, comme les i9 9820X, 9800X, 9920X, 9940X, 9960X, 9980XE sous Socket 2066, et, bien sûr, les Ryzen 7 3700X, 3800X, 3900X et les Threadripper 1900X, 1920X, 1950X, 2920X, 2950X, 2990WX.
Mais tous sont bienvenus, peu importe leur processeur!
Nous effectuons parfois des tests et des benchs. Nous causons aussi de configuration MAO et d'optimisation, de notre façon de bosser dans tel ou tel DAW, etc. Nous partageons nos machines et configs et aiguillons les newbs et/ou ceux qui posent des questions vers la machine la plus appropriée pour leur besoin et, bien sûr, nous débattons parfois, mais dans la bonne humeur et le respect, parce que nous sommes passionnés, mais ne partageons pas tous forcément les mêmes idées et opinions (ce qui est très bien ainsi!).
Voilà, en souhaitant de bons échanges à tous!
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
[ Dernière édition du message le 11/09/2019 à 04:37:29 ]
Freudon
Merci pour ton explication
parce que quand tu utilises dans banks de sons du type audiomodeling ou samplemodeling tu vas beaucoup plus loin en terme d'expressivité.... le vibrato en vitesse comme en profondeur sont facilement paramétrables et contrôlables en temps réels.
pour des set orchestraux ca change tout!
Je ne possède pas de banque Audiomodeling ou Samplemodeling
mais je suppose que cela doit être un peu comme la banque Spitfire audio Solo Strings
avec le Solo Violin Total Performance et le Cello aussi dans une moindre mesure
qui utilise beaucoup de ressources.
Mon ancien FX8350 avait du mal a suivre et c'est pourtant un 4 coeurs 8 threads.
Maintenant avec mon 3900x plus de soucis.
Mais là il est vrai que l'on parle d'enregistrement en temps réel.
Ce n'est pas ma façon d'écrire sauf juste a trouver les idées.
Un séquenceur comme cubase que j'ai découvert pour ma part il y a peu permet de faire un travail chirurgical.
Et c'est ce travail qui lui seul peut permettre d'approcher le jeu de tout un orchestre de joueurs professionnels.
Après bien sur en fonction du niveau instrumental de chacun je me doute que beaucoup peuvent s'éclataient
avec toutes les banques qui sortent au fur et a mesure ainsi qu'aux nouveaux matériels.
Mus'images
vous avez vu passer cette news ?
https://www.hardwarecooking.fr/amd-annonce-ryzen-threadripper-pro/
Serait-ce la réponse d'AMD face à certains retours très négatifs en MAO, avec une gestion de la RAM catastrophique lors de sessions exigeantes ? Impossible de se prononcer à l'heure actuel, mais à surveiller de près.
Sinon je suis tombé sur une vidéo avant hier soir, où le mec explique la différence entre le "CPU Performance" et le "Real-Time Performance":
La conclusion rejoint tout ce qu'a pu expliquer Darkmoon, et c'est plutôt frustrant car malheureusement lors de la conception d'un super PC pour la MAO, il ne faut pas se soucier "Que" du nombre de coeurs, mais surtout de tout ce qu'il y a autour pour éviter d'être vite embêté par le "Real-Time Performance".
[ Dernière édition du message le 16/07/2020 à 14:56:27 ]
Freudon
je pensais que la fréquence mémoire était peu importante sur l'optimisation de la mémoire. sauf que ça n'est pas vrai...
pour une optimisation il faut du 3733 mhz... ca n'est pas ce que j'avais lu à gauche à droite. le dossier en question est vraiment fabuleux car il test non seulement les performance cpu mais mémoire aussi et ce pour des buffers de 64 / 128 / 256 / 512 samples!
C'est de ce dossier que tu veux parler.
https://www.cgdirector.com/best-memory-ram-amd-ryzen-cpus-3600-3700x-3900x/
ou celui là peut-être
https://www.scanproaudio.info/tag/dawbench/
D'après plusieurs sites la fréquence optimum pour les ryzens 3000 serait de la 3600mhz.
C'est ce que j'avais déjà signalé plus haut.
Moi je suis en 3200mhz avec 64 gigas mais si je passe a 128 j'opterai pour de la 3600mhz.
[ Dernière édition du message le 16/07/2020 à 15:12:03 ]
Eric Music Strasbourg
oui le dossier https://www.scanproaudio.info/tag/dawbench/ . je n'avais pas vu que tu l'avais mis. c'est une mine d'or
pour audiomodeling en fait il n'y a pas de sample... c'est comme pour les pianos pianoteq... c'est une sorte d'equation mathématique qui va calculer ce que donnerai le son suivant différent parametre comme la pression du souffle l'inclinaison de la tete (avec un breath contrôleur)...
d'apres ce que j'ai pu voir spitfire utilise de ssamples... je ne suis pas certains que tu puisses modifier en temps réel la vitesse et la profondeur du vibrato chez spitfire.. si quelqu'un à l'info ca m’intéresse.
pour samplemodeling le systeme est différents les samples sont lus mais une multitude de samples gérant les vibrato existent. c'est la modulation qui va choisir quells samples doivent etre lus... le cc13 lui va gérer la vitesse du vibrato.
il y a donc deja trois inconues dans le choix des samples à charger et jouer en live.
1) le cc11 ou 2 pour l'intensité
2) le cc1 pour le taux de vibrato
3) le cc13 pour la vitesse du vibrato
il y en a d'autre par exemple le nombre de violoniste. ainsi tu peux faire 8 violoniste puis passer à 12 puis à 16 par exemple avec une pédale d'expression réglé sur le bon cc (dont je ne me souviens plus le numero )
c'est vraiment quelque chose d'incroyable point de vue réalisme. de la meme façon si tu lie deux notes d'une façon particuliere les deux notes seront liés en glissando...
j'ai un peu envie de dire que les keyswitch sont remplaçables avec cette manière de créer et donc de gérer cette bank...
le problème c'est le prix!!! mais ça vaux le coût et largement pour faire le l'orchestral.
il n'y a qu'un probleme à cette technologie la maitrise du breath control... d'ailleurs j'attends la prochaine version midi2.0 qui aura une plage bien plus grande mais saurais-je (si je suis encore de ce monde) maîtriser comme un vrai joueur de trombone de trompette ou de cors français les taux de pressions et la rapidité à avoir...
pour la fréquence mémoire oui 3600 ou 3733. c'est ce qu'explique le mec dans dawbench. tu gagnes 10 à 15 instances ca n'est pas rien.... moi je suis en 3000 faute de budget pour l'instant...
tiens moi au courant en mp pour les 3600 quand tu les auras installés si tu retrouves ce gain de 10% environ.
Eric
[ Dernière édition du message le 16/07/2020 à 16:57:30 ]
Darkmoon
Sinon je suis tombé sur une vidéo avant hier soir, où le mec explique la différence entre le "CPU Performance" et le "Real-Time Performance" [...] La conclusion rejoint tout ce qu'a pu expliquer Darkmoon, et c'est plutôt frustrant car malheureusement lors de la conception d'un super PC pour la MAO, il ne faut pas se soucier "Que" du nombre de coeurs, mais surtout de tout ce qu'il y a autour pour éviter d'être vite embêté par le "Real-Time Performance".
Oui, cette vidéo, je l'ai postée plusieurs fois sur AF! Elle est même devenue « une classique » sur plusieurs forums (surtout anglophone) traitant de MAO, avec ces 2 autres vidéos d'ailleurs :
Monty Montgomery : D/A and A/D | Digital Show and Tell
Ethan Winer : Audio Myths Workshop
Pour ceux qui connaissent déjà, juste à passer, mais en rapport avec la vidéo partagée par Mus'images, je vais rappeler (en français contrairement à la vidéo) pourquoi la jauge CPU de nos DAW n’indique pas forcé 100% avant de « glitcher » et pourquoi la jauge de nos DAW peut indiquer une valeur tout à fait différente de la jauge CPU de L’OS :l
Avant tout, concernant le nombre de cœurs/threads d’un ordinateur et des jauges CPU des DAW et de l’OS, dans un contexte MAO, faut savoir que :
1- ça concerne tous les DAW/STAN, tous les OS/plateforme (Win/Mac/Linux) et tous les plugins!
2- oui, certaines DAW et certaines pulgins sont plus ou moins bien optimisées pour exploiter plus d’un cœur/thread, mais...
Dans un DAW/STAN certaines opérations ne peuvent tous simplement pas être calculé en parallèle par plusieurs cœurs/threads. C’est tout simplement impossible techniquement~physiquement à cause de l’implication du temps réel.
C’est ce qu’explique Richard Ames dans la vidéo en anglais qu’a partagé Mus'images. L’audio, même si ça peut paraitre contre-intuitif a priori est l’activité qui demande le plus de ressources (et la plus sujette à la notion de « bottleneck » ou « goulot d’étranglement » en français).
Parce qu’en montage vidéo/3D, ben l’on effectue des corrections et ajustements et l’on appuie ensuite sur « play », on réajuste et l’on réappuie sur « play », ainsi de suite. L’on ne corrige pas tout en faisant jouer la vidéo. Alors qu’en musique, c’est différent, on laisse jouer pendant que nous effectuons des ajustements. Voilà pourquoi le temps réel est bcp plus important en musique!
Et c’est ce qui explique, dépendamment de la façon dont on travaille, qu’il est souvent plus efficace d’acquérir un CPU avec moins de cœurs, mais avec une plus haute cadence GHz quand on utilise des DAW.
Parce que les divers traitements (calculs) ne peuvent pas toujours s’effectuer en parallèle (= tous les cœurs qui travaillent en même temps) dans les DAW. Autrement dit, l’ensemble des calculs que requièrent nos VSTI/VST n’est pas systématiquement dispatché de façon égale entre tous les cœurs de processeur. Parce que certaines chaines d’effets ne peuvent être traitées qu’en série (donc par un seul et unique cœur). Sans compter que le processeur doit attendre que tous les autres composants et périphériques en cause lui renvoient les infos nécessaires!
Par exemple, si vous avez dans une piste/tranche de plusieurs effets (disons un EQ, suivit d’un comp, suivit d’un enhancer, etc.), le DAW ne peut pas utiliser n cœurs afin de traité simultanément ces 3 effets parce que c’est virtuellement impossible!
Pourquoi? Parce qu’avant de pouvoir calculer et appliquer le résultat du dernier effet, il doit nécessairement calculer le résultat du premier, du deuxième et du troisième. Du coup, quand un cœur/thread calcule le résultat du premier effet, il est impossible qu’un autre cœur/thread puisse effectuer simultanément le calcul de l’effet qui suit (dans une même chaine d’effet/tranche) au même instant t puisqu’il ne connaît pas encore le résultat de l’effet précédent!
Pour faire une image plus parlante, disons que vous avez 12 employés devant construire une maison, c’est-à-dire monter les murs de votre maison, les peindre et au final décorer votre maison, tous prêt à bosser en parallèle, simultanément, ben ces derniers ne pourront de toute façon pas commencer à peindre avant que la charpente et les mures ne soient montées et encore moins commencer à accrocher des tableaux aux murs et des rideaux aux fenêtres avant que la peinture ne soit terminée. Donc puisqu’ils ne pourront de toute façon pas tous bosser en parallèle simultanément, mais devront bosser « en série », c’est à dire à la suite des uns des autres, peu importe leur nombre, au moment où les « cœurs~employés » montent les murs, tous les autres, mêmes si non-exploités, ne peuvent rien faire d’autres qu’attendre! Donc aussi bien avoir moins d'employés, mais extrêmement rapides VS plusieurs employés, mais moins rapide (parce que les murs seront montés plus rapidement et que suivra donc plus rapidement la suite des travaux « en série »).
Aux plus perspicaces qui se diront : « mais pourquoi tout simplement ne pas affecter tous les « cœurs~employés » à chaque opération ? Même lors des traitements en série? Genre, les 12 employés montent les murs, ensuite les 12 peinturent les murs, ensuite les 12 accrochent les tableaux et rideaux aux murs et puis basta! »
Bien joué!
Sauf qu'ils devront alors tous communiquer ensemble pour travailler en symbiose, ce qui ajoutera du temps supplémentaire!
Bon, l'explication réelle est très technique, mais, grosso modo, pour vulgariser~simplifié, c'est qu'il est plus coûteux en temps, pour le système, de communiquer et d'attendre les « réponses » de chaque cœur que lorsqu'une chaîne de traitement est traitée par le même et unique cœur. Voilà pourquoi tous les DAW sont codés de façon à disptacher (répartir) les différentes opérations en terme de « chaîne de traitement » étant liées aux différentes pistes, tranches, BUS, etc., parce qu'au final, c'est plus efficace que de tout donner à tout faire à tous les cœurs.
Bref, ça concerne des problèmes et notions de codage et de fonctionnement des processeurs et ça dépasse mes compétences, mais certains programmeurs ont déjà expliqué tout ceci en détail, ici même sur AF, mais aussi sur plusieurs autres forums.
Donc, pour résumer, toute piste audio ou VSTi qui est lié à une même chaine d’effets (piste/tranche/BUS/AUX) ne peut être traité que par un seul et unique cœur. Et c’est d’ailleurs aussi ce qui explique, même lorsque nous avons qu’une seule piste dans un DAW, que sa jauge d’utilisation CPU puisse parfois indiquer 99% (parce qu’un seul cœur est sollicité, disons, par des effets très gourmands sur la tranche correspondante) alors que le gestionnaire de l’OS, lui, indiquera bcp moins (disons 25%) puisque, lui, tient compte du fait qu’un seul des n cœurs (pour l’ensemble du système) est sollicité par un logiciel.
Par corollaire, nous pouvons donc en déduire que plus nous utilisons de BUS/AUX dans un DAW, plus nous lions ensemble des pistes/tranches qui se partagent alors une même « grande chaine d’effet ». Du coup, le DAW peut moins efficacement dispatcher (répartir) et traiter de façon simultanée, au même instant t, les divers effets de cette même « grande chaine » entre tous les cœurs/thread du CPU parce qu’il doit attendre que les premiers, dans l’ordre du temps, soient calculés avant de passer aux suivants!
Donc, dans certains projets, il vaut parfois mieux travailler en utilisant des pistes indépendantes plutôt que de router toutes les tranches dans un BUS commun. De cette façon, le DAW peut dispatcher et donc traiter (par plus d’un cœur/thread) simultanément, au même instant t, les chaines d’effets qui ne sont pas liés entres elles, ce qui fait que, parfois, même si l’on a bcp plus de VST d’ouverts dans le DAW, la charge sera répartie en plusieurs cœurs/thread et la jauge d’utilisation CPU indiquera un moindre pourcentage, même si cela semble paradoxal ou contre-intuitif à priori, qu’un autre projet utilisant moins de plugins, mais où ils sont tous lié dans un processus en série (de par un BUS commun).
De plus, lors de l’ouverture du DAW, le fait d’ouvrir un tout premier plugin et de constaté que la j’auge indique, disons, 27%, n’implique pas forcément que la charge sera doublée à 54% si nous ouvrons une deuxième instance de ce même plugin. Non, car peut-être que le premier était exploité que par un seul cœur (ça dépend des DAW, des plugins et des options, etc.) et que le deuxième sera attribué à un autre cœur.
Parce que la jauge CPU dans un DAW, contrairement à la jauge du gestionnaire de l’OS, n’indique pas forcément le total de ressource utilisée par tous les cœurs, mais le plus haut « peak » (pointe d'utilisation) de n’importe quel des cœurs/thread utilisés à un instant t précis. Et cela est logique, parce que si un cœur/thread est sollicité à 99% du fait qu’un traitement qui ne peut se faire en parallèle le sollicite presque en entier, car ne pouvant pas utiliser les autres cœurs/thread simultanément, ben à quoi bon diviser le pourcentage par n cœur/thread et nous indiquer /n % puisque, de toute façon, à cet instant t précis, le seul cœur/thread utilisable~exploitable est à 99%! Le DAW est donc bel et bien à 99% de ses capacités de traitement à cet instant t précis puisqu’il ne peut pas exploiter les autres cœurs/thread! et qu'il est tout prêt d'y avoir des glitchs!
Autre exemple concret :
Imaginons une seule piste/tranche de guitare, pour jouer/s’amuser live (au clic du DAW). Ben, même si nous avons un Xeon 12 coeurs/24 threads @2.6GHz, si ce dernier (le seul cœur/thread exploitable dans ce projet) arrive au taquet avec tous les effets que nous ouvrons sur cette seule et unique tranche (effets traités nécessairement en série), nous aurons des glitchs/drops/underruns plus rapidement que si nous achetons un « simple » I7 7700K 4 coeurs/8threads @4,5GHz parce que le seul cœur/thread exploitable (dans cet exemple précis) possède près de 2GHz de plus!
Par contre, si nous ouvrons 12 VSTi ayant chacun leur propre tranche/piste et n’utilisant pas de BUS/AUX communs, là, le 12 coeurs/24 threads @2,6GHz sera probablement plus efficient (ainsi que pour faire du « rendering offline » vidéo, P. Ex.).
Mais encore, en très basse latence, habituellement, en pratique, les plus hautes fréquences s’en sortent mieux (tout chose étant égale par ailleurs, lorsqu’aucun « bootleneck » n’affecte les perfs de l’un et de l’autre).
Conséquemment, pour de la MAO et surtout pour ceux que le temps réel (enregistrement d’instruments live, jeu/entrée de notes live via clavier MIDI) est très important et/ou qui doivent bosser avec des valeurs de buffer très basses, il est nettement préférable de prioriser l’achat d’une haute fréquence de CPU et non du nombre de cœurs/thread.
Pour ceux qui composent à la souris dans le piano roll (ou par notation) et/ou qui écoutent/mixent sans jouer/enregistrer en temps réel (pouvant donc monter le buffer de leur carte son au max), un plus grand nombre de cœurs/thread est préférable.
Mais dans les deux cas, il y a nécessairement un compromis : dans le premier, le CPU sera plus efficient en temps réel avec des valeurs de buffer basses, mais pour mixer et écouter, il pourra gérer, au total, moins de VST/VSTi (à valeur de buffer identique élevé). Dans le second, ce sera le contraire : moins performant en temps réel avec des valeurs de buffer basses, mais pouvant faire jouer (à valeur de buffer identique élevé) plus de VST/VSTi que le premier.
Mais encore, tout ceci dépendamment de l'utilisation, ou non, du nombre de BUS/AUX qui créer des chaines de traitement en série, du DAW et des plugins utilisés et de certaines options utilisées ou non. Et comme expliqué dans la vidéo de Richard Ames, il est important d'avoir des composants et périphériques « équilibrés » qui ne créent pas de « goulot d'étranglement » nuisant au processeur, car sinon ça peut générer des glitchs alors que le processeur est à peine utilisé à quelques valeurs de pourcentage.
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
[ Dernière édition du message le 17/07/2020 à 08:48:36 ]
Didrop
Graffy
Intel i5 9400F + Cooler Master GeminII M4
ASUS B360M-A
16 Go corsair XMP 2666 MHz (bientôt 32 Go)
1 carte vidéo NVidia fanless GT730 2 Go
1 NVMe SSD Samsung EVO 970 pro 250 Go (OS W10)
1 NVMe SSD Samsung EVO 970 pro 250 Go (OS macOS Mojave) Hackintosh
2 SSD MX 500 pour les sessions
1 carte pcie UAD duo
1 carte fille ASUS sortie spdif connectée sur la carte mère.
1 Écran Philips 32 pouces curved 2560x1440 (reconnu comme un retina 5K 27 pouces sous Mojave)
Manque (compatible Mac et Windows bien sûr) :
1 Module Bluetooth/wifi sur port NVMe
1 Carte pcie TH3
1 disque équivalent Fusion/drive 2 To pour les backups.
Des avis ?
[ Dernière édition du message le 17/07/2020 à 12:47:42 ]
Mus'images
Donc, dans certains projets, il vaut parfois mieux travailler en utilisant des pistes indépendantes plutôt que de router toutes les tranches dans un BUS commun.
Merci pour ton retour très explicite Darkmoon, qui m'a enlevé quelques doutes sur ce que j'ai pu comprendre de la vidéo de Richard Ames. Maintenant par rapport à ce que tu dis et que j'ai cité au dessus, j'ai du mal à mettre de l'ordre dans les circuits intégrés de mon cerveau.
Je m'explique,
dans ton explication vulgarisée, j'ai compris que si on plaçait, admettons, 4 ou 5 effets différents en insert "d'une seule piste/un seul instrument", on a plus de chance de se trouver face à ce "bottleneck" si on multiplie cette procédure par "autant de pistes/autant d'instruments" que nécessaire. Le bon sens nous indique donc qu'il est préférable de router plusieurs instruments de la même famille dans une piste groupe, à laquelle on applique un traitement d'effet aussi pénible soit-il.
De ce fait, n'est-il pas préférable, dans n'importe quel type de projet, d'appliquer cette méthode afin de réduire les situations de Bottleneck ?
Autre chose, j'ai vu quelques tutos de compositeurs pour les jeux vidéos, sur Youtube, qui expliquaient qu'il était plus intéressant d'utiliser des "Track Instrument" (en mode "non multi-timbrales"), et suivant ce que je viens d'apprendre avec cette vidéo + ton explication vulgarisée, je comprends mieux l'intérêt, car cela permet d'exploiter au mieux la puissance CPU disponible et que nous ne devrions pas avoir peur de cela. Cependant, on reste toujours dans le cas de figure où on est obligé de router "quelques pistes/quelques instruments" dans une piste groupe, afin d'appliquer un traitement d'effet groupé, car avant toute chose on parle d'homogénéité dans les traitements d'effets.
A partir de là le circuit "A" de mon cerveau me dit "Bien joué Francky", le circuit "B" de mon cerveau me dit "t'es vraiment sûr de toi ?", le circuit "C" de mon cerveau me dit "tu poses la question et tu donnes la réponse en même temps", le circuit "C" de mon cerveau me dit "arrêtez les mecs, Darkmoon vient de dire que parfois il vaut mieux travailler en utilisant des pistes indépendantes plutôt que de router toutes les tranches dans un BUS commun", et le circuit "E" de mon cerveau me dit "naaaan, il a dû se planter en disant ça, attends j'vais lui demander pour être sûr".
Tout cela c'est dans l'éventualité où on a l'habitude de gérer les traitements d'effet au sein même de chaque projet composition, et pour ma part, je trouve vraiment très utile de travailler de cette manière, car rien que le fait de changer une seule note peut avoir un effet de "rendu souhaité" assez significatif, si par exemple pour une basse, au premier essai on écrit un DO1, et il s'avère qu'il aurait été préférable d'écrire ce DO à l'octave supérieure.
En d'autres termes, l'écriture et l'orchestration jouent aussi un rôle important dans la gestion des fréquences, et c'est entre autre pour cela que je trouve que de tout gérer au sein de chaque projet composition, permet d'avoir une bonne maîtrise de la production musicale.
Ta réflexion que je viens de citer me laisse donc assez perplexe
[ Dernière édition du message le 18/07/2020 à 00:19:04 ]
Darkmoon
Ta réflexion que je viens de citer me laisse donc assez perplexe
La notion de « bootleneck » ne concerne pas vraiment (enfin, l’on pourrait la relier, mais ça va devenir bcp trop « pointu » pour rien) la façon de gérer son projet, avec les pistes, les Bus, etc.
Le goulot d’étranglement (bootleneck), ça concerne surtout l’interaction entre tous les périphériques et composants physiques de l’ordi. Alors que 98% de mon pavé précédent ne traite pas de ça. La seule chose à retenir concernant le « bootleneck », c’est que c’est ce qui explique que certains utilisateurs peuvent obtenir des glitchs même si la jauge du DAW et/ou de l’OS indique, P. Ex., 25%
C’est tout, grosso modo. Le CPU n’est pas pleinement utilisé, mais un autre « composant trop lent » tarde à transmettre une info, ce qui fait que le buffer qui « avance » (comme dans la vidéo) ne reçoit pas de données à donner à bouffer au convertisseur D/A de la carte son!
Maintenant, ensuite, pour le reste de ce que j’explique concernant l’avantage de choisir plus de cœur ou moins de cœur, mais avec une plus haute fréquence, ainsi que les diverses façons de gérer nos projets :
- ça a peu d’importance, sinon aucune incidence — avec de bons processeurs actuels — dans de petits~moyens projets. Donc « dont panic », mes exemples sont volontairement « grossières » afin de facilité la compréhension du « principe ». Dans les faits, en 2020, quand tu veux juste, P. Ex., jouer live de ta guitare avec une seule piste de drum virtuel + une simu virtuelle + 3, 4 FX, en principe, t’es pas supposé être incapable de le faire avec un buffer à 64smp parce que t’as acheté un processeur avec 18 cœurs à 3.5GHz au lieu d’un processeur 6 cœurs à 4.8GHz. Ça fonctionnera parfaitement dans les 2 cas puisque c’est trop « petit » comme charge d’utilisation pour faire entrer en cause les principes que j’évoque (en « principe », car en informatique, il y a parfois de mauvaises surprises et des exceptions ).
- faut vraiment utiliser bcp, bcp de plugins dans un petit projet (je sais, ça parait antinomique, mais VS le nombre de pistes, disons) et/ou faire de très gros projets pour observer des différences significatives. Et le fait que personne ne bosse avec le même DAW ni ne bosse de la même façon concernant la gestion des Bus, des send et des pistes et tranches rend difficile d’effectuer des comparaisons pratiques lors de projet en situation réelle. Mais il est possible de s’en rendre compte en faisant divers essais, même s’ils ne correspondent pas à un cas réel. Par exemple, ouvre au moins 50 pistes d’un instrument virtuel (duplique des notes dans le piano roll) assez gourmand, disons u-he Diva en mode « divine » et applique à chacune de leur tranche de console respective un plugin d’FX assez gourmand (un truc « analo like consol strip channel » ou une « grosse reverb »). Appui sur « play » pour faire jouer simultanément les 50 pistes et observe la jauge de conso du DAW. Ensuite change la configuration : tu crées 5 Bus qui recevront chacun 10 pistes/tranches, retire la reverb (du test précédent) de chacune des tranches, mais fout 10 reverb dans chacun des bus. Au final, t’auras exactement le même nombre de pistes~instruments virtuel et exactement le même nombre de plugins d’FX, mais si tu appuies sur « play », tu constateras que la jauge de conso de ressources du DAW n’indiquera pas la même valeur. Mais vu la puissance de ton CPU, la différence peut être minime. Mais plus tu feras les 2 mêmes genres de tests, mais avec plus de pistes et plugins, plus tu remarqueras que l’écart augmente. Ce qui prouve et démontre que lorsqu’il y a des « chaines d’effet » qui se recoupent dans de mêmes « branches de la synoptique » (imagine-toi des « couloirs sonores communs ), le DAW ne gère pas la conso de la même façon/les cœurs sont répartis différemment.
- mais bon, en pratique, perso, je ne m’empêche pas pour autant d’utiliser des Bus et des envois vers des pistes d’effets, etc., mais je tente tout de même de faire attention, quand je fais de très gros projets et que je suis presqu’au taquet. Faut pas virer parano non plus.
- oui, il semble y avoir un consensus, depuis quelques années, sur le fait qu’utiliser, P. Ex., 10 instances de Kontakt (pour l’exemple, ça peut être n’importe quel instrument virtuel disposant de 16 canaux/sorties MIDI) en ouvrant dans chaque instance qu’un seul et unique instrument~patch est plus avantageux, en terme de ressource CPU, que d’ouvrir une seule instance en ouvrant 10 instruments~patch dans cette dernière. Attention, encore une fois c’est pour l’exemple et le principe, car avec une seule instance x 10 instruments à l’intérieur VS 10 instances x chacun un seul instrument~patch, tu n’observeras pas nécessairement bcp de différences. Encore une fois, en pratique, avec la puissance des CPU actuels, faut multiplier bcp plus! La raison (des différences constatées) est attribuable à ce que j’explique dans mon pavé précédent : c’est à dire que dans l’instance qui contient 10 instruments~patchs, ben le DAW n’attribuera qu’un seul cœur pour l’instance. Donc tes 10 pistes correspondantes (et leurs tranches, qui se retrouve en fait à être des espèces de pistes sous « bus artificiel » ) se partagent un seul et unique cœur. Alors que si tu ouvres 10 instances avec chacune un seul instrument~patch, ben chacune des instances peut être traité par un cœur différent! ...à condition de ne pas toute les router ensuite vers un même Bus dans la console de tranches de ton DAW.
- Conséquemment, certains instruments virtuels qui dispose d’une option « multicore~multithread » à activer/désactiver, comme Diva et Kontakt, fonctionnent parfois « mieux » (consomment moins de ressources) quand on la désactive, car sinon, ça elle entre potentiellement en conflit avec le DAW qui, lui, cherche à gérer lui-même ses propres affectations des cœurs disponibles pour tous les plugins. L’option « multicore~multithread » des plugins étant utile en mode « standalone », hors DAW. Voilà pourquoi je dis dans mon pavé « dépendamment des options des DAW et plugins ». Car, en plus, certaines DAW, comme Reaper, P. Ex., entre autres, disposent d’option supplémentaire spécifique (« anticipate FX ») qui peuvent aussi avoir incidence avec tout ceci.
Bref, ça peut paraître complexe, mais inutile de trop se casser la tête. Juste retenir, qu’habituellement, moins il y a de pistes/tranches/instruments différents qui se partagent un « couloir sonore commun » (Bus, piste FX, etc) dans le DAW, plus le DAW est en mesure de répartir de façon plus efficiente tous les cœurs dispo du processeur. Juste à se souvenir de ça si l’on arrive au taquet, dans un gros projet! Et de désactiver (à moins d’observer des résultats contraire, car les exceptions existent en informatique ) l’option « multicore~multithread » des plugins (elle est plutôt rare et est présente surtout chez les instruments visuels, surtout les samplers comme Kontakt et certaines synth comme Diva) parce que sinon ces derniers tentent d’effectuer des requêtes à plusieurs cœurs alors que le DAW tente de faire de même, ce qui peut créer de multiples « requêtes de communication » qui au final consomment du temps et abaissent les performances/provoque des glitchs à basse latence.
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Eric Music Strasbourg
je vais m'amuser à tester un nombre de pistes importantes avec un traitement de compression par une carte uad et la même session avec un compresseur waves...
sur le papier waves qui est en natif et donc traité par le cpu devrait être moins intéressant point de vue allégement, sauf que le fait de devoir transmettre les données au cartes uad dans le premier cas peut créer des temps de latence et d’interruption qui me sont inconnues et donc de la conso cpu...
du coup ce qui est vrai sur le papier sera il vrai en toute réalité??? reponse demain!
Eric
- < Liste des sujets
- Charte