Tordre le cou au moteur audio:

Je soupçonne que pour cette histoire de probabilité, tu confondes avec « la probabilité de passer dans une branche de code plutôt qu’une autre », ce qui oriente le microprocesseur dans la préparation des instructions suivantes.

Sinon en termes d’échanges sur forum, on ne fait qu’essayer d’expliquer les choses clairement, simplement et rigoureusement. Pas la peine d’être agressif hein !

Quand une opération a besoin du résultat d'une autre, tu es bien obligé d'attendre le résultat de la première avant de commencer la deuxième.

mais si on en est encore à ce que vous dites ce n'est pas la peine de fabriquer des machines 36 cores.

Du coup tu pourrais m'expliquer comment le principe de substitution de Liskov s'applique, pour mes petits neurones c'est de la science fiction.

Ok, mais comprends quand même que j'ai eu l'impression d'être agressé en premier quand on me dit à 4 reprises que je ne comprend pas 2+2 ou Y=f(g(x)), au bout d'un moment ça énerve non?

Sinon je suis très impressionné par certaines de tes interventions dans ce sujet,

Et si t'utilises celui qui sonne plus chaud l'été, du coup ca sonne plus chaud que chaud

Si c’est pour composer, peut-être peux-tu jouer avec un instrument virtuel moins lourd, que tu tremplaces ensuite par cette instance de Kontakt en freezant la piste ?

La même chose joué dans le Kontakt Standalone ne sature.
Une séquence jouée par le même instrument Kontakt ne sature pas puisqu'elle est réparti sur les coeurs.
C'est donc bien l’interaction Kontakt + Logic + jeu live qui cause le problème.

Par contre si je mets Kontakt dans un bridge, la répartition fonctionne, bien que je le joue toujours depuis une piste de Logic.

Par contre si je mets Kontakt dans un bridge, la répartition fonctionne, bien que je le joue toujours depuis une piste de Logic.

Et si jamais Kontakt crée en douce plus de threads dans le dos de Logic, ça entre en compétition avec les autres threads de Logic et c'est pire que mieux.

Citation :

C'est juste ce principe logique qu'il est nécessaire de piger.

On la piger depuis longtemps, ça me saoule quand tu me parles comme à un collégien avec ton y=f(g(x)), ah non je ne semble pas piger ça ... n'importe qu'elle imbécile comprend que dans un calcul on fait d'abord les calculs intermédiaires dans l'ordre adéquat...
Sauf que la programmation ce n'est pas juste la réplication de calculs. Il existe aujourd'hui des techniques qui permettent de mutualiser les cœurs pour fabriquer une sorte de gros cœur, du coup ta fonction g(x) est plus vite réalisé avant de devoir appliquer f. Par ailleurs en programmation orienté objet, selon le principe de substitution de Liskov il est possible (même si cela vous semble une aberration) d'effectuer le calcul final Y sans avoir le résultat de g(x) en le remplaçant par une forte probabilité puis en le substituant à la toute fin (en gros hein, c'est beaucoup plus bizarre que ça en réalité).
Non la programmation n'est pas (plus) la réplication en ligne de code de processus mathématiques. Mais je ne suis pas assez calé pour vous expliquer la programmation orienté objet, qui par ailleurs est à la base du concept d'AI.
Je parie juste que le problème initial de la surcharge single-core en temps réel va être résolu... ce n'est qu'une question de temps.

Citation :

On ne peut pas faire en programmation des choses qui sont impossibles dans leur nature même.

Si on le peut, des tas de choses impossibles par calcul sont réalisées aujourd'hui par des programmes.

Citation :

Il a donc fallu adapter les STAN pour bien exploiter les processeurs multicœurs. Logic a dû être adapté un peu moins rapidement et après les autres STAN. Depuis la version 10.3.3 il n’y a plus besoin de créer des bus pour exploiter davantage de cœurs ; j’imagine que désormais Logic crée un thread par tranche, les threads pouvant être répartis sur différents cœurs.

Non cette explication n'est pas suffisante. Logic crée peut-être un thread par tranche mais cela n'explique comment ce fait t'il que sur une seule et même tranche jouée en live aujourd'hui je peux mettre 10 effets de Logic sans constater de surcharge alors que j'en avais autrefois avec 4 ou 5 (selon les types hein). Je reste pourtant sur un unique thread traité par un seul cœur, selon toi, ... moi je suppose que ça fonctionne autrement aujourd'hui, mais je ne peux pas expliquer comment. Je suppose que tous les effets de Logic on été ré-écrit pour utiliser le multi-coeurs même lorsqu'ils sont en cascade. Et je ne crois pas qu'il soit nécessaire d'attendre la fin du calcul du 1er effet pour appliquer le 2ème effet, là encore il y a des mécanismes de substitution et/ou d'anticipation. Surtout avec des effets lourds, je n'imagine pas le process attendre bêtement la fin du traitement d'une grosse reverb à convolution avant de passer à la suite, même si c'est le même signal qui les traverse. On est beaucoup plus malin aujourd'hui. La programmation n'est pas forcement répliquer le comportement physique de la réalité, on n'est pas obliger de faire comme si on branchait des effets hardware en cascade dans la réalité. Vous raisonnez comme si la programmation était la copie de phénomènes réelles.
Par contre les effets et IVs des autres constructeurs ne sont pas forcement écrit de la bonne façon (pour Logic), d'où le fait qu'il n'y a pas de surcharge avec les effets de Logic alors qu'il peut (pas forcement hein) y en avoir avoir les effets d'autres marques (notamment avec NI et selon ma petite expérience pas avec IKM).
J'accepte juste qu'on peut faire en programmation des choses qui me dépassent.

Citation :

Les plugins qui sont « multithreading », comme Kontakt, peuvent exploiter plus d'un thread uniquement quand certaines de leurs opérations ne sont pas liées/dépendantes entre elles.

C'est peut-être vrai pour Kontakt (d'où les problèmes) mais ce n'est pas incontournable. Si le multi-threading n'est pas capable de contourner l'interdépendance des opérations (car presque tout est interdépendant) autant dire qu'il n'a pas d'avenir, pourtant...