réactions à la news Apple frappe -très- fort avec le nouveau Mac Studio

Ce qui complexifie la compréhension, c’est que tant que la limite d’un seul cœur n’est pas atteinte (que ce soit en terme de pourcentage d’utilisation et/ou de glitchs, même sans taper dans le rouge dans la jauge), le fait de créer des jonctions avec des bus/aux (pour une tranche exploitant ce cœur à la limite non atteinte) ne change presque rien (parce que ça devient en fait qu’une seule et même « grande tranche~chaîne » et que la limite n’était pas atteinte de toute façon), alors que quand la limite d’un seul cœur est atteinte à donf, ca ne changera strictement rien dans ce cas de faire comme ce que suggère l’article concernant Logic (parce que ce que suggère l'article ne concerne pas le jeu en temps réel), alors que cela fonctionnera (allégera quelque peu) dans d’autres cas « moins extrêmes » (et/ou en lecture~haut buffer), si ce n’est que parce que certains plugins consomment tjrs quelque peu, même en état d’attente~sans signaux à traiter.

Pour le dernier cas de l’article de Logic, nous lisons ceci (je traduis, le gras et le NDT sont de moi) :

« Dans l’image ci-dessus, il y a une charge très lourde sur un seul cœur, même s’il utilise le routage décrit ci-dessus (NDT, ceux sensés allégé la conso!). Notez que la tranche de console Inst 1 est sélectionnée. Lorsqu’une piste d’instrument logiciel est sélectionnée dans la fenêtre d’arrangement, Logic entre en "mode d’entrée en direct". Dans ce mode, Logic active chaque plug-in dans le chemin du signal de la tranche de console afin que la tranche de console puisse être joué en direct à partir d’un contrôleur MIDI. Tout cela doit être géré par un seul thread et donc un seul cœur. »

Ben voilà! Dès qu’on tombe en « temps réel » (jouer de cette piste au clavier MIDI), ça ne change plus rien et l’on voit que le fait que le VSTi soit routé vers le Bus 1 (qui, lui, est routé vers le Bus 2), ça revient à une seule grande chaîne d’effet qui fait quasi saturer le seul cœur pouvant traiter cette chaîne, car toute chaîne lié, en temps réel, ne peut être traité que par un seul cœur*

Sinon, l’article se termine par :

« C’est une bonne idée de conserver une piste qui utilise une tranche de console audio sélectionnée dans la fenêtre d’Arrangement, sauf si vous jouez ou enregistrez activement sur un instrument logiciel. »

Ben oui, parce que Logic passe les plugins dans un buffer probablement non-temps réel en quelque sorte (probablement similaire à « l'astuce du « blue/green Z » de Studio One, qui débute ce qui est joué en retard, mais ce qui n’affecte pas le jeu live car le musicien joue calé sur ce qu’il entend, lui, avec un buffer plus bas que les instru~VSTi qui sont annotés sur le piano roll).

* Ça pourrait être dispatché à plusieurs cœurs, mais puisque chacun des cœurs devrait attendre les résultats des cœurs qui traitent les effets qui précèdent dans l’ordre temporel (parce qu’impossible de traiter au même instant t, en temps réel), ça ne sert à rien. À ce niveau, ce n’est pas une limitation physique et/ou technologique, c’est à cause de « formalités de programmation/perfs matérielle », parce que le fait de diviser les taches d’une même chaîne d’effets sur plusieurs cœurs induirait au final plus de latence et calculs du fait que le système devrait gérer encore plus d’envois/retours de données à diviser/ré-assembler au final. Du coup, les DAW (les devs*) choisissent (pour des questions de perfs) de limiter ce qui est dispatché~divisé en plus grosses taches, c’est-à-dire, soit un VSTi et/ou un effet = une tache~thread dans un DAW, mais aussi un seul cœur par grande chaîne d’effet lié séquentiellement (où l’ordre des effets importe dans la chaîne). Grosso-modo!

*Ce qui explique les premières phrases de l'article :

« Logic décompose les tâches en threads qui peuvent être affectés à un seul cœur pour exécution »

« Il n'est pas possible de diviser un thread sur plusieurs cœurs »

« bien qu'un seul cœur puisse exécuter plusieurs threads en même temps » (NDT : si ces thread ne sont pas liés dans un ordre séquentiel)

Il n'est pas question de croire ou non, il est question de correctement interpréter ce que dit et démontre l'article et d'effectuer certaines nuances pas évidentes à saisir a priori. C'est différent!

C'est exactement ce que je dis depuis tjrs sur AF!

Étant donné que j'ai participé à nombre de reprises (sur des forums anglophones) où des développeurs de DAW s'exprimaient en personne sur la question, je ne pense pas savoir mieux qu'eux, je ne fais en fait que répéter ce qu'eux on dit et expliqué sur la question!

Spidouz, C’est juste qu’en répétant tjrs « préférez croire ce que vous voulez », ça nous indique que tu ne saisis pas ce que nous te partageons, croyant (c’est toi qui crois)... ...que nous disons le contraire de tes propos, alors que nous apportons plutôt des précisions et nuances. L’on dirait que tu tiens juste à avoir raison sans écouter les nuances que l’on apporte qui n’invalident pas nécessairement ce que tu dis!

Tes propos sur le temps réel sont non-pertinent, car dans l’absolu, ça n’existe pas et n’existera jamais le temps réel « absolu ». Et nous le savons! Même avec un PC du futur un million de fois plus rapide, les calculs d’une chaîne en série se feront toujours dans un laps de temps donné, même si imperceptible pour Dieu lui-même!

Conséquemment, ce qui est pertinent, c’est juste de savoir ce qui peut être calculé réellement en parallèle et/ou en série, pour ce qui nous importe à nous, en fonction de ce qui nous affecte dans notre utilisation pratique, nous les utilisateurs de DAW. Et quand ça ne concerne pas ce que l’on nomme (par convention~commodité) le « jeu en temps réel » dans nos DAW, c’est-à-dire l’offline, le bounce, le rendering, l’export et/ou ce qui peut être traité en parallèle en « pseudo temps réel » quand nous ne jouons pas, l’on s’en cogne les clous!

Ce qui nous importe, c’est l’incidence des calculs pouvant ou non être traité en parallèle/série, dans la mesure où ça affecte ou non les perfs de notre machine lorsque nous jouons~composons au clavier MIDI et/ou enregistrons de l’audio (Input Mic/Line). Pas toi?

Pour ce qui est du reste (compos par notation et/ou uniquement en mode souris dans le piano roll), perso, ça ne ma jamais affecté si ce n’est que je n’ai qu’à foutre le buffer de mon interface à 2048smp et, dans ce cas, j’ai autrement plus de marge que nécessaire. C’est surtout jouer du clavier MIDI/enregistrer de l’audio « live », qui est le nerf de la guerre!

Perso, quand je bosse (sauf phase uniquement de mixage~mastering « post-composition ») dans mon DAW, c’est à dire compose et joue, je suis toujours en 128smp ou moins et, dans ce cas, comme la conclusion de l’article sur Logic le démontre (il n’est pas question de croire ou pas, tu es aussi d’accord avec cette conclusion! ), diviser nos plugins d’une même « chaîne » sur plusieurs pistes~bus~aux — encore liés par l’ordre temporel des effet pour cette « chaîne », n’améliorera pas de façon significative la donne, lors du jeu~recording sur clavier et/ou audio! C’est tout ce que nous (enfin, moi et 2, 3 autres) affirmons (et voulons préciser!). Et tu sembles d’accord avec ça!

Donc

Citation de Darkmoon :

Spidouz, C’est juste qu’en répétant tjrs « préférez croire ce que vous voulez », ça nous indique que tu ne saisis pas ce que nous te partageons, croyant (c’est toi qui crois)... ...que nous disons le contraire de tes propos, alors que nous apportons plutôt des précisions et nuances. L’on dirait que tu tiens juste à avoir raison sans écouter les nuances que l’on apporte qui n’invalident pas nécessairement ce que tu dis!

Je vois surtout que tu ne m’as pas lu depuis le commentaire initial de l’astuce de router une piste, ou alors, comme les autres, tu n’as pas compris ce que j’ai écris. C’est pourtant simple.

Citation :

Et quand ça ne concerne pas ce que l’on nomme (par convention~commodité) le « jeu en temps réel » dans nos DAW, c’est-à-dire l’offline, le bounce, le rendering, l’export et/ou ce qui peut être traité en parallèle en « pseudo temps réel » quand nous ne jouons pas, l’on s’en cogne les clous!

Pas du tout. Quand tu es sur une grosse session avec des centaines de pistes, même sans que les pistes soit live, elles peuvent bouffer trop de ressources pour une simple lecture, et donc cela peut être bon de pouvoir soulager en faisant de la redistribution, et pas que pour la piste active. Puis faire de la redistribution sur les pistes non-live, c’est aussi libérer des ressources pour la piste live que l’on va utiliser pour enregistrer par exemple.

Citation :

Ce qui nous importe, c’est l’incidence des calculs pouvant ou non être traité en parallèle/série, dans la mesure où ça affecte ou non les perfs de notre machine lorsque nous jouons~composons au clavier MIDI et/ou enregistrons de l’audio (Input Mic/Line). Pas toi?

Ce n’était pas ça la question…

A présent ça commence petit à petit à devenir lourd et je commence à perdre mon temps;
j’ai fourni la réponse, j’ai fourni le lien, et les explications nécessaires provenant des équipes Logic et de pourquoi utiliser cette astuce; libre à vous de l’utiliser ou non.

L'astuce de l'article est contre-intuitive et contraire à certains principes théoriques (partagé par des devs/docs de DAW) qui implique que lier des bus/aux ensembles empêche le DAW de pouvoir faire traiter par de multiples cœurs ce qui est lié en série. D’où pourquoi, au départ, certains d’entre nous ont voulu investiguer et vérifier tes « prétentions » concernant l’article. Après lecture et analyse, ils se trouve que nous comprenons que l’astuce de l’article ne concerne pas le jeu en temps réel et que c’est un « procédé » propre et particulier à Logic (qui utilise une « astuce » qui ajoute une latence, de façon transparente pour l’utilisateur, lors de la lecture des pistes), car pour la plupart (il y a peut-être d’autres exceptions?) des autres DAW, lier des bus/aux ne permet pas d’exploiter plus d'un cœur (pour la chaîne lié), même en « lecture ».

Et bien qu’étant sur un forum « Mac », plusieurs utilisent un autres DAW que Logic sous Mac! Il est donc nécéssaire de relativiser et de préciser (parce que toi, tu ne le fais pas!) que ce que tu préconises et suggère ne s’applique, a priori, qu’à Logic, car ceux qui utilisent Studio One, Reaper, FL Studio, Bitwig, DP (ou tout autres DAW compatibles Mac) pourraient croire que partager des bus/aux améliorera les perfs alors que ce n’est pas nécessairement le cas!

C'est quand-même important à spécifier, non?

Par exemple, entre autres, voici ce que nous pouvons lire dans la doc d’un DAW (je ne traduis que les passages pertinents. voir le lien pour la version intégrale en anglais) :

« La logique du traitement audio - Il existe une longue liste de tâches qui doivent être traitées dans l’ordre, ce qui signifie logiquement qu’elles ne peuvent pas être traitées en parallèle (multithread). Par exemple : Les plugins doivent attendre les instructions du Piano roll et de la Playlist avant de produire du son. Les effets doivent attendre le son des instruments et des FX en amont avant de pouvoir le traiter. De plus, il n’est pas possible de traiter en parallèle (multithread) des instruments et des effets qui se trouvent sur le même canal de mixage (où l’audio est mélangé ensemble), ou même dans la même ligne de routage de mixage (lorsqu’une tranche de mixage est liée à une autre et à une autre). Même le traitement des FX a un ordre de haut en bas dans la suite d’FX. Ensuite, la tranche Master doit attendre que chaque instrument > tranche du Mixeur > effet soit traité avant de pouvoir traiter l’audio à travers les effets sur le Master. Logiquement, il y a donc beaucoup d’attente, ce qui est un fait naturel et inévitable du traitement audio séquentiel. Pensez à la génération audio comme à une chaîne de production. Cela signifie que le CPU peut ne pas être particulièrement occupé, n’utilisant pas tous ses cœurs, et pourtant il manque de temps pour remplir le tampon audio. Pourquoi ? Parce qu’il y a beaucoup d’attente pour des choses qui doivent être traitées en séquence et l’attente est essentiellement une perte de temps pour le tampon. Il doit être clair que la vitesse (fréquence) du CPU est très importante et que ce n’est pas la même chose que le traitement multi-core/multi-thread.

Plus précisément, en termes de multi-threading, assurez-vous que vos plugins les plus gourmands en ressources CPU sont acheminés vers des tranche de mixage indépendantes sans canaux d’envoi partagés. Chaque tranche de mixage représente une "opportunité" de créer des chemins de traitement indépendants et parallèles. En résumé, voici comment fonctionne le multithreading :

1. Les générateurs (VSTi) seront traités dans plusieurs threads (si l’option "Allow threaded processing" est activée dans le DAW et que les plugins le permettent).

2. Toutes les tranches du mixeur qui ne dépendent pas les unes des autres pour l’entrée audio, peuvent être traitées en même temps, c’est-à-dire dans plusieurs threads (si "Allow threaded processing" est activé).

3. Les tranches de mixage (bus/aux, etc) qui dépendent de la sortie d’autres tranches de mixage seront traitées après ces autres tranches de mixage et probablement sur le même cœur. »

C’est on ne peut plus clair! Non?

Par conséquent, la meilleure chose à conseiller à tous (au lieu de parler de croyances et/ou de faire comme si Logic était la référence universelle), c’est de leur dire de lire et de se renseigner sur le DAW qu’ils utilisent concernant la façon dont ce dernier gère le multi-core/multi-thread. Parce que tous les DAW ne procèdent pas nécessairement et précisément comme les 2 premiers cas dans l’article concernant Logic. Dans certains, même en « lecture "temps réel" » (qui est un abus de langage, car il y a tjrs un buffer dans tous les cas), sans jouer, tout est géré comme dans le troisième cas (jeu en temps réel) de l’article (et ce qui est partagé ici, plus haut), c’est à dire qu’en liant des tranches avec des bus/aux, tout doit alors être traité que par un seul cœur!

Et c’est pourquoi on peut aussi lire ce genre d’info (tjrs à la même source que plus haut) :

« Le meilleur processeur est celui qui possède suffisamment de cœurs pour répartir le travail ET qui peut effectuer le plus de travail sur un seul cœur pendant chaque tranche de temps de la mémoire tampon. En effet, si un seul cœur ne peut pas suivre, peu importe le nombre d’autres cœurs fonctionnant à moins de 100 %, vous aurez des problèmes audio en temps réel. »

D'ou pourquoi j’ai souvent dit — pour de la MAO — qu’il est préférable de choisir de hautes fréquences de CPU plutôt que le nombre de cœurs (bien sûr, quand on peut avoir les deux, c’est mieux!)

Oui, j'avais bien lu, mais c'est parce que par la suite tu as fait — après avoir trouvé l'article sur Logic — comme si la question était alors résolue, comme si tu avais trouvé la preuve de comment c'était géré (de façon générale), comme s'il n'y avait rien d'autre à discuter et que toutes les nuances de ceux qui te répondaient n'étaient que croyances, et/ou qu'ils ne savaient pas de quoi il parlait, etc.

C'est juste une question d'attitude et « d'approche » de ta part qui fait que tu réponds comme si tout ce que les autres peuvent apporter et préciser par la suite, c'est de la merde, de l'ignorance et des croyances !

C'était si difficile de dire, P. Ex., « oui les gars, vous n'avez pas tort, c'est juste que je cause spécifiquement de Logic, pour les autres DAW, je sais pas, et c'est peut-être différent, comme j'ai dit au départ. L'article sur Logic ne change pas ça »



Mais non, l'on tente d'apporter une nuance, une précision et l'on reçoit « demeurez dans vos croyances », « j'ai apporté les preuves, faites ce que vous voulez »

Bravos pour la finesse de ta « psychologie humaine », ton écoute et ton ouverture!

Je déflag!