réactions à la news Commentaires sur le test : Logic implacable

Citation de Hakim+K :

[...]

Il te manque des notions de programmation évidente (et je ne connais pas tout dans le détails non plus) mais je sens qu'on va peut-être en emmerder quelques uns si l'on poursuit trop longuement.

J'ai suivi plusieurs threads, sur d'autres forums (anglophones) où prenait part des développeurs de DAW et...

Citation de Hakim+K :

Je ne vois pas pourquoi il n'est pas possible de répartir dès le départ le 1er effet sur tous les coeurs puis le 2ème puis le 3ème. On doit respecter l'ordre OK mais on peut très bien répartir tout systématiquement en temps réel, il ya des logiciels dans d'autres domaines qui le font très bien

Nope! Pas en temps réel!

Ça semble, effectivement, logique à priori et c’est ce que je pensais moi aussi à l’époque, mais c’est un « biais ». Ce n’est pas possible et je te résume simplement (en simplifiant/vulgarisant au max) :

Oublie la MAO et imagine un « projet mathématique »... ...tu veux calculer 2+2 suivit de x3 suivit de /2 (bon, on sait, ça donne 6 ).

Même si ta calculatrice possède 30 coeurs/thread, seul un coeur/thread pourra calculer 2+2 (et x3 .....et /2). Autrement dit, à partir d’un certain point, il est impossible de réduire plus petit et/ou de diviser un calcul simple pour le partager en 2 opérations/process. Pour calculer 2+2, il n’y a rien d’autre à faire que de calculer 2+2 par un seul coeur/thread. Tu ne peux pas envoyer « la moitié de l’opération » à un coeur et « l’autre moitié » simultanément à un autre coeur puisqu’il n’y a pas « deux moitiés de calcul »! Il n’existe qu’un seul « process » à effectuer! Tu piges? ...et puisque que la multiplication par 3 (ainsi que la division) doit se faire après le résultat de 2+2, cette multiplication subséquente ne pourra jamais être effectué simultanément (mais ça, nous sommes d’accord ).

On en revient donc exactement au même point! Quand, P. Ex., il y a une EQ dans une tranche du DAW, le tout premier calcul de la toute première ligne de code de cette EQ ne peut être effectué que par un seul et unique coeur/thread... ...ainsi que la deuxième opération, idem à la ligne de code suivante... .... et ainsi de suite jusqu’à la fin de toutes les lignes de codes qui concernent cette EQ. Seuls différents effets/instruments (« process/opérations » pour un codeur/dev) peuvent être affecté à différentes unités de calcul simultanément. ...et puisque l’ordre des effets dans un DAW est tributaire d’un ordre temporel (tout comme l’ordre des opérations à une importance en mathématique et doit tenir compte du résultat précédant), l’on ne s’en sort pas quand ils font partie d’un même ordre temporel (d'une même chaine d’effet). Non seulement chaque effet doit être traité l'un à la suite de l'autre, mais c'est aussi vrai pour chacune des lignes de code d'un seul et même effet.

Citation de Hakim+K :

Ce que tu expliques, c'était avant.

Nope. Et le principe demeurera le même jusqu'à la fin des temps! ...à moins qu'on trouve comment effectuer 2+2 en 10 sous opérations différentes pouvant être calculé par plusieurs unités de calcul.

T'as même pas besoin d'être un dev/codeur pour piger. Tente de formaliser une opération qui décompose en plusieurs parties distinctes l'opération 2+2 (sans multiplier le nombre de process temporel nécessaire).

Bonne chance!

> Je ne vois pas pourquoi il n'est pas possible de répartir dès le départ le 1er effet sur tous les coeurs puis le 2ème puis le 3ème.

Ce n’est pas réellement possible, ou plus exactement ça n’aurait aucun intérêt, car le deuxième effet a besoin du résultat du calcul du premier, tout comme on ne peut pas vernir un tableau avant de l’avoir terminé.

Si les effets d’une même tranche étaient répartis sur différents cœurs, le cœur du deuxième effet attendrait la fin du calcul effectué sur le cœur du premier effet. Donc temporellement on ne gagne rien ; et en plus on rajouterait une communication et synchronisation, donc ce serait encore moins bon.

Te plains pas Otist,
je n'ai pas le choix que de bosser avec les produits Autodesk (BIM) heureusement que mon Rhino préféré tourne mieux sur Windows que sur Mac OS. À chaque fois que je dois donner des formations et que je me retrouve face à des pauvres gars derrière leurs iMacs avec Autocad LT for Mac auquel il manque la moitié des fonctions les plus importantes c'est l'angoisse.
Sur de la grosse modélisation en conception architecturale avec modules de contraintes et dimensionnement je suis bien heureux de ne pas être confronté à une Pomme.
Pour des tas de choses Mac OS fait parfaitement l'affaire, parfois mieux encore, mais pour certaines tâches spécifiques et pointues (des niches) je préfère arrêter de m'ennuyer avec Pomme : je ne forme plus, je ne prends plus de missions où l'on me l'impose et je fais assembler mes stations de travail certifiées pour les softs que je soutiens depuis presque 15 ans. Ras le bol du racket d'Autodesk et de ce BIM qui va finir de flinguer la profession.

Rhino tres bon modeleur voir le meilleur mais trop souvent inutile pour moi, a part sur certaines taches tres precises, SKP est bien plus approprié après ce sont des habitudes...
Par contre j’ai des temoignages inverses au tiens sur sa stabilité sur Mac, merci de l’info.

Autocad sur mac, ca tourne bien même mieux... et c’est plus soigné niveau ergo, j’en ai convertis plus d’un et puis je me suis convertis moi même a Draftshift car j en avais ras le ponpon d’engraisser Autodesk. (DS c’est Dassault, c’est pas fou non plus mais bien moins cher... et oui je paie mes logiciels messieurs ! )

Et Pas de Revit sous mac, mdr...

Pour le LT, a part la 3D et les lisp y a pas grandes differences pour des archis, enfin pas qui justifie les 2500e !!! de difference sur le prix des licences... (par contre, les lisp pour ma part c est indispensable) encore foutage de gueule !!

La pomme n’est tout simplement pas implantée et optimisée pour cette industrie et ces applications mais
1- pour beaucoup d’archi ca suffit et
2- si le monopole de Windaube n’etait pas orchestré, HP, Dell... (comme celui de mac en graphisme) tu serais ravi d’utiliser ton mac pour concevoir de petits comme de gros projets...

C’est pas le BIM qui flingue la profession, ce sont
1-les logiciels qui sont les outils du BIM car Revit n’est pas le BIM, Archicad non plus...
2-La surdose d’imagerie de synthese ennuyeuse a mourir, les mecs, vous savez tenir un stylo je vous vois a 10bornes avec votre Vray biaisé !?

Tout comme Adobe avec Affinity, Autodesk se fera montrer du doigt dans peu ( par honnêteté je dois dire que j’utilise encore LightRoom.) Le regne n’aura qu’un temps.

Dans la musique finalement il a plus de support et c’est tant mieux !

Au moins en concours tu fais l’ancienne et c’est parfait... heureusement qu’il y a ce petit bol d’air.

Désolé du HS...

Linn134, en MP si tu le souhaites

Pour LT sur Mac ce sont des fonctions particulières mais essentielles, comme l'export en PDF avec calques par exemple. Pour sortir des plans de communication c'est juste irremplaçable. Et il y en a un paquet d'autres. Je ne parle que de fonctions simples de LT qui ne sont pas disponibles en version pomme, pas de celles présentes sur Revit ou Archi ou Inventor.

Concernant Rhino je suis plus que certain de ce que j'avance. Je suis le dev depuis la version béta de la 2, béta testeur, contributeur et formateur dessus depuis plus de dix ans. La version Mac est sympa mais largement moins optimisée. C'est normal, c'est quand même "Nurbs modelling for Windows". Il y a trop de modules incompatibles avec Mac OS, et je ne parle que dans l'optique architecture puisque c'est mon métier.

Pour du SketchUp + Artlantis + Archicad c'est clair : Mac sans souci. Pour du gros projet qui demande du BIM et de la modélisation très lourde c'est tout aussi clair : grosse station de travail PC avec de la Quadro P en nombre.
Une config proche de ce qu'exige Catia par exemple.

On est vraiment dans l'application spécialisée et la config dédiée.

Désolé pour le hors sujet, c'est rare de rencontrer un confrère ici

Moi j'ai bien aimé votre petit dérapage Darkmoon et Hakim, car ce sont des explications que je ne connaissais pas...

Citation de Mrben :

Question peut-être bête, mais s’il n’y a pas de plug in sur le bus master mais simplement un fade out en fin de morceau, de ce fait les pistes du projet sont elles liées par le fader master ?

Oui, forcément, parce qu’au final la résultante de toutes les pistes passe par le master. Mais s’il n’y a aucun effet en insert sur le master, une « bête » baisse progressive de volume est le genre de calcul le plus simple à effectuer par un CPU. Du coup, ce n’est pas ce type de calcul qui prend le plus de temps à effectuer même si, dans l’absolu, il doit quand même s’effectuer après que tout le reste (toutes les autres pistes/effets) ait été calculé. Et de toute façon, la piste master étant une obligation (on ne peut ne pas l’utiliser), inutile de se casser la tête à son sujet. On doit faire avec.

Darkmoon, je reste pas d'accord, mais je ne vais pas entrer dans les détails. Inutile de m'expliquer que la chronologie impose de faire un calcul puis le suivant. Vous raisonnez en interruption, dans le cas où le processor réalise une opération suite à une sollicitation du programme. Vous n'avez manifestement pas compris ce que je nomme taches cycliques déterministes La tache cyclique ne répond pas à une demande de calcul, elle s'execute de la même façon avec le même temps quoiqu'il arrive, même si on veut rien faire, elle se fait à vide mais elle peut être répartie sur plusieurs coeurs c'est un autre façon de programmer. Je suis automaticien et je suis capable de le faire avec des automates, ne me dites pas que ce n'est pas possible avec des processeurs. La difficulté sur un ordinateur est d'imbriquer les 2 types de programmation car dans le 2ème type le processeur est utilisé même quand on ne fait rien.
Et je répète que sur Logic il n'y a pas le problème quand on bourre d'effets une piste, c'est bien qu'il y a eu un progrès. Je constate que vous postez tous des explications sur la gestion multi-coeurs vues et revues qui sont obsolètes et qui ne tiennent pas compte des avancées dans ce domaine intervenues à partir de la version 10.3.3. Sortez-moi des trucs d'après nov 2017. Après je prends le pari que ce problème va disparaitre car on va manifestement vers la multiplication des coeurs et on peut tous faire en programmation.

Tant que des experts en info traînent sur ce thread, une question qui me turlupine depuis longtemps:
Quand on a le choix d'ouvrir un même plugin en AU ou en VST (par exemple un NI sur Ableton Live), vaut-il mieux l'ouvrir en VST, en AU, panacher entre pistes, pas d'importance? Ceci afin de limiter la charge processeur...

Citation de Hakim+K :

Darkmoon [...] Vous n'avez manifestement pas compris ce que je nomme taches cycliques déterministes...

J'ai très bien compris. Mais je te répète qu'il est impossible (c'est une question de logique élémentaire) qu'un seul plugin soit traité totalement et simultanément par plusieurs threads. Réponse détaillée ici.