Sujet Commentaires sur la news : Apple frappe -très- fort avec le nouveau Mac Studio

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!