Tordre le cou au moteur audio:
- 212 réponses
- 40 participants
- 29 024 vues
- 56 followers
Afficher le sujet de la discussion
Oui il y a des arrondis et donc des distorsions. Mais elles sont tellement faibles qu'elles seront totalement inaudibles, et en fait complètement masquées par le bruit apporté par les composants électroniques qui travaillent en analogique. Or comme notre cerveau ne prend pas plaisir à regarder des nombres (on n'est pas comme les personnages de Matrix
), il y a forcément un moment où on repasse en analogique (typiquement : convertisseur N/A, puis amplification, puis haut-parleurs).
Vu que depuis pas mal d'années les CPU ont de la marge de puissance par rapport au "minimum syndical pour mixer" (à l'époque des Beatles on se contentait de 16 voire 8 pistes !), si c'était problématique les concepteurs de logiciels audionumériques se seraient tous tournés vers des nombres avec davantage de décimales pour réduire ces distorsions. Par exemple il y a bien eu des modifications des logiciels pour :
- passer de représentations sur des nombres entiers à des nombres à virgule flottante (ça implique davantage de calculs)
- passer de 16 à 32 bits (idem : augmentation de la charge de calculs)
Mais depuis pas mal d'années, et à quelques exceptions, davantage motivées par du marketing, on peut dire que tous les logiciels restent en 32 bits virgule flottante (sauf ProTools, qui pour des raisons de limitations sur leur hardware, est obligé de rester en virgule fixe, mais avec des nombres environ sur 32 bits, et des astuces pour avoir à peu près la même "dynamique ou plage de valeurs petites/grandes" qu'en virgule flottante : en gros, un peu plus de détails sur les pistes indépendantes, des nombres de plus de 32 bits pendant le calcul de sommation, puis un peu moins de détails mais une valeur max plus grande sur les bus après sommation de pistes indépendantes et en revenant à 32 bits à virgule fixe ; en gros le logiciels se tape lui-même le "déplaçage de virgule" ).
Il faut distinguer deux étapes, et elles ont été évoquées dans diverses discussions sur AF, alors c'est peut-être à ces discussions que tu penses, ou ce sont elles qui engendrent cette question.
1- il faut convertir ce qui est affiché sur le curseur du DAW (disons -3.2dB) en un nombre à virgule flottante, qui sera le gain g
2- il faut multiplier chaque sample par ce gain g
Pour l'étape 2, c'est tellement simple que tous les DAW feront exactement pareil. Comme dit par Jay f. ci-dessus.
Pour l'étape 1, il y a quelques étapes de calcul. En fait : "-3,2" c'est le résultat de "vingt fois" le "logarithme en base 10 (= log et pas ln). Et il n'est pas certain que tous les DAW partent de ce "-3.2" affiché ; certains pourraient partir "de la distance en pixels entre la position actuelle du fader et la position zéro". Imaginons que : la course du fader fasse 300 pixels (=un quart d'écran), qu'en bas pour ce DAW ça corresponde à -120dB, et que le fader soit à 8 pixels en dessous du 0dB : 8/300*120 = 3,2000000000004 (*)
Du coup un DAW pourrait partir de 3,2000000000004 et l'autre de 3,2. Ensuite ils calculent le gain correspondant ( 10 puissance (-3,2/20) ), ou 10 puissance (-3,2000000000004/20).
Après le "bounce" dans le DAW ça ne donnera pas les mêmes fichiers : il y a ce 0,0000000000004 dB de différence sur le gain appliqué. Ce ne sera pas "le même mixage" ; mais deux mixages tellement proches que la différence est inaudible.
Si on affichait le gain en valeur absolue et pas en dB, on n'aurait moins ce genre de différence, mais on sait tous que ce ne serait pas parlant. Et en plus dans mon calcul (*) j'ai fait une règle de 3 = proportionnalité entre les pixels et les dB ; mais ça ne doit pas être ça : le fader fait des petites différences de dB quand il est près de zéro, puis des plus grosses. Donc c'est encore un peu plus compliqué.
C'est ce qui explique que dans certaines discussions on dit que les bounce de 2 DAW différents donnent des fichiers différents, mais ce sont les gains qui sont très légèrement différents, alors que après calcul du gain les 2 DAW appliquent ce gain de la même manière (valeur du sample x le gain).
C'est pour ça que pour simplifier mon tableau, j'ai pris 6dB, parce-que normalement quand le fader affiche ça, ça correspond à un gain de 2. Et ça simplifie les valeurs et leur calcul dans mon tableau.
Bon c'est un peu compliqué, alors j'espère que ce sera quand même à peu près clair.
Mais en résumé ce qui peut varier très légèrement entre 2 DAW, c'est le lien "position graphique du curseur, ou valeur affichée en dB sur seulement 2 chiffres" <---> valeur du gain par lequel on va multiplier les samples.
Ensuite c'est juste une multiplication. Et les arrondis de cette multiplication sont fixées par la norme IEEE 754.
Et les pan pot ajoute encore des possibilités d'avoir des différences :
- des différences importantes car il y a différentes "lois de pan" (généralement les DAW offrent ces différentes lois sous forme d'un réglage dans les options)
- et ensuite, comme un pan est un gain, on retombe sur cette incertitude entre "affichage sur le bouton" <---> valeur du gain.
Pour éviter ça, on pourrait imaginer d'afficher la valeur du gain sur une échelle linéaire (= non logarithmique), mais :
- ce serait très peu lisible
- ça n'aurait d'utilité que lors de tests "informatiques", comme il en est question dans ces sujets. Or l'interface d'un DAW a pour but de faciliter le mixage, pas de faire des "tests comparatifs" qui relèvent de l'informatique !
Là on en revient à la justification d'utiliser des échelles logarithmiques (= en dB) plutôt que linéaire. C'est une question sur le fonctionnement de l'oreille humaine (et de nos sens en général) ; ce n'est pas l'informatique qui nous dit que "c'est pratique d'avoir une valeur, en décibels, et sur seulement 2 chiffres" : c'était déjà comme ça sur les consoles analogiques !
Voilà!
C'est ce que j'ai tenté d'expliquer à Hakim en simplifiant avec un bête calcul (2+2), mais il ne semble pas piger. Ça n'a rien à voir avec Logic, car le principe demeure le même avec des formules math à calculer. Peu importe le domaine d'application (audio, image, vidéo, 3D, recherche, etc.) et le logiciel, il est tout simplement impossible (ou contre-productif) de partager entre plusieurs threads des lignes de codes/calculs qui ne sont pas indépendantes les unes des autres.
Ce que Hakim ne pige pas, c'est que peu de (voir aucune) lignes de code (celles qui concernent le traitement du son) sont indépendante les unes des autres dans le code qui compose un plugin. Du coup, même au niveau du code, l'aspect de l'ordre temporel des opérations est un impératif.
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. Par exemple, quand on ouvre plusieurs instruments dans une même instance et que ces derniers ne se partagent pas d'effets dans les tranches de la table de Konatkt, ben, n'ayant aucune dépendance les uns envers les autres, ils peuvent être (en principe) traités par différents threads. Par contre, toutes les fonctions qui concernent un seul instrument (dans la fenêtre d'édition avancée de Kontakt, par exemple, entre autres, avec leurs effets respectifs) sont, elles, dépendantes d'un ordre de procédure concernant les calculs à effectuer.
Le principe demeure le même avec un plugin de synthétiseur. P. Ex., les différents oscillateurs peuvent être traité en parallèle (en principe), mais dès que leur « signal » respectif se rejoignent tous ensemble pour passer dans un des effets global du synthétiseur (par exemple, un chorus/reverbe), une « dépendance » (et un ordre temporel) se créer du fait que le chorus/reverbe ne peuvent être calculer simultanément que les oscillateurs du fait que ces effets doivent attendre le résultat des calculs traitant les oscillateurs avant de pouvoir être calculé. Du coup, aucun plugin le moindrement complexe (comportant des effets, etc. Donc aussi bien dire tous les VSTi de synthé actuel) ne peut jamais être totalement traité (toutes ses lignes de code) de façon simultanée (comme la vision simpliste d'Hakim) par plusieurs threads puisque, de toute façon, le ou les threads doivent attendre certains calculs ayant un ordre dans une « chaine en série »!
C'est juste ce principe logique qu'il est nécessaire de piger. Ça n'a rien à voir avec un DAW en particulier ni avec aucun logiciel ou plugin, c'est un principe logique universel!
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.
Si on le peut, des tas de choses impossibles par calcul sont réalisées aujourd'hui par des programmes.
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.
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...
Jay f.
4162
Squatteur·euse d’AF
Membre depuis 16 ans
Anonyme
103
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Citation de Canem :
si, par exemple on applique un gain de 5,73 dB (au pif). là on multipliera tout par un nombre à virgule probablement assez long (du genre 1.975564654354354...) donc forcément il y aura des "arrondis". à ce moment là, il n'y a pas de distorsion, même très faible qui apparaissent?
Oui il y a des arrondis et donc des distorsions. Mais elles sont tellement faibles qu'elles seront totalement inaudibles, et en fait complètement masquées par le bruit apporté par les composants électroniques qui travaillent en analogique. Or comme notre cerveau ne prend pas plaisir à regarder des nombres (on n'est pas comme les personnages de Matrix
), il y a forcément un moment où on repasse en analogique (typiquement : convertisseur N/A, puis amplification, puis haut-parleurs).Vu que depuis pas mal d'années les CPU ont de la marge de puissance par rapport au "minimum syndical pour mixer" (à l'époque des Beatles on se contentait de 16 voire 8 pistes !), si c'était problématique les concepteurs de logiciels audionumériques se seraient tous tournés vers des nombres avec davantage de décimales pour réduire ces distorsions. Par exemple il y a bien eu des modifications des logiciels pour :
- passer de représentations sur des nombres entiers à des nombres à virgule flottante (ça implique davantage de calculs)
- passer de 16 à 32 bits (idem : augmentation de la charge de calculs)
Mais depuis pas mal d'années, et à quelques exceptions, davantage motivées par du marketing, on peut dire que tous les logiciels restent en 32 bits virgule flottante (sauf ProTools, qui pour des raisons de limitations sur leur hardware, est obligé de rester en virgule fixe, mais avec des nombres environ sur 32 bits, et des astuces pour avoir à peu près la même "dynamique ou plage de valeurs petites/grandes" qu'en virgule flottante : en gros, un peu plus de détails sur les pistes indépendantes, des nombres de plus de 32 bits pendant le calcul de sommation, puis un peu moins de détails mais une valeur max plus grande sur les bus après sommation de pistes indépendantes et en revenant à 32 bits à virgule fixe ; en gros le logiciels se tape lui-même le "déplaçage de virgule" ).
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Citation de Canem :
... et qui seraient gérées différemment par les différentes daw? j'espère que la question est claire et pas trop bête
Il faut distinguer deux étapes, et elles ont été évoquées dans diverses discussions sur AF, alors c'est peut-être à ces discussions que tu penses, ou ce sont elles qui engendrent cette question.
1- il faut convertir ce qui est affiché sur le curseur du DAW (disons -3.2dB) en un nombre à virgule flottante, qui sera le gain g
2- il faut multiplier chaque sample par ce gain g
Pour l'étape 2, c'est tellement simple que tous les DAW feront exactement pareil. Comme dit par Jay f. ci-dessus.
Pour l'étape 1, il y a quelques étapes de calcul. En fait : "-3,2" c'est le résultat de "vingt fois" le "logarithme en base 10 (= log et pas ln). Et il n'est pas certain que tous les DAW partent de ce "-3.2" affiché ; certains pourraient partir "de la distance en pixels entre la position actuelle du fader et la position zéro". Imaginons que : la course du fader fasse 300 pixels (=un quart d'écran), qu'en bas pour ce DAW ça corresponde à -120dB, et que le fader soit à 8 pixels en dessous du 0dB : 8/300*120 = 3,2000000000004 (*)
Du coup un DAW pourrait partir de 3,2000000000004 et l'autre de 3,2. Ensuite ils calculent le gain correspondant ( 10 puissance (-3,2/20) ), ou 10 puissance (-3,2000000000004/20).
Après le "bounce" dans le DAW ça ne donnera pas les mêmes fichiers : il y a ce 0,0000000000004 dB de différence sur le gain appliqué. Ce ne sera pas "le même mixage" ; mais deux mixages tellement proches que la différence est inaudible.
Si on affichait le gain en valeur absolue et pas en dB, on n'aurait moins ce genre de différence, mais on sait tous que ce ne serait pas parlant. Et en plus dans mon calcul (*) j'ai fait une règle de 3 = proportionnalité entre les pixels et les dB ; mais ça ne doit pas être ça : le fader fait des petites différences de dB quand il est près de zéro, puis des plus grosses. Donc c'est encore un peu plus compliqué.
C'est ce qui explique que dans certaines discussions on dit que les bounce de 2 DAW différents donnent des fichiers différents, mais ce sont les gains qui sont très légèrement différents, alors que après calcul du gain les 2 DAW appliquent ce gain de la même manière (valeur du sample x le gain).
C'est pour ça que pour simplifier mon tableau, j'ai pris 6dB, parce-que normalement quand le fader affiche ça, ça correspond à un gain de 2. Et ça simplifie les valeurs et leur calcul dans mon tableau.
Bon c'est un peu compliqué, alors j'espère que ce sera quand même à peu près clair.
Mais en résumé ce qui peut varier très légèrement entre 2 DAW, c'est le lien "position graphique du curseur, ou valeur affichée en dB sur seulement 2 chiffres" <---> valeur du gain par lequel on va multiplier les samples.
Ensuite c'est juste une multiplication. Et les arrondis de cette multiplication sont fixées par la norme IEEE 754.
Et les pan pot ajoute encore des possibilités d'avoir des différences :
- des différences importantes car il y a différentes "lois de pan" (généralement les DAW offrent ces différentes lois sous forme d'un réglage dans les options)
- et ensuite, comme un pan est un gain, on retombe sur cette incertitude entre "affichage sur le bouton" <---> valeur du gain.
Pour éviter ça, on pourrait imaginer d'afficher la valeur du gain sur une échelle linéaire (= non logarithmique), mais :
- ce serait très peu lisible
- ça n'aurait d'utilité que lors de tests "informatiques", comme il en est question dans ces sujets. Or l'interface d'un DAW a pour but de faciliter le mixage, pas de faire des "tests comparatifs" qui relèvent de l'informatique !
Là on en revient à la justification d'utiliser des échelles logarithmiques (= en dB) plutôt que linéaire. C'est une question sur le fonctionnement de l'oreille humaine (et de nos sens en général) ; ce n'est pas l'informatique qui nous dit que "c'est pratique d'avoir une valeur, en décibels, et sur seulement 2 chiffres" : c'était déjà comme ça sur les consoles analogiques !
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Dr Pouet
52037
Membre d’honneur
Membre depuis 20 ans
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de Dr :
On ne peut pas faire en programmation des choses qui sont impossibles dans leur nature même.
Si on a :
y = f( g( x ) )
On est obligé d’attendre le résultat, et donc la fin du calcul de g(x) pour pouvoir appliquer f( ).
Voilà!
C'est ce que j'ai tenté d'expliquer à Hakim en simplifiant avec un bête calcul (2+2), mais il ne semble pas piger. Ça n'a rien à voir avec Logic, car le principe demeure le même avec des formules math à calculer. Peu importe le domaine d'application (audio, image, vidéo, 3D, recherche, etc.) et le logiciel, il est tout simplement impossible (ou contre-productif) de partager entre plusieurs threads des lignes de codes/calculs qui ne sont pas indépendantes les unes des autres.
Ce que Hakim ne pige pas, c'est que peu de (voir aucune) lignes de code (celles qui concernent le traitement du son) sont indépendante les unes des autres dans le code qui compose un plugin. Du coup, même au niveau du code, l'aspect de l'ordre temporel des opérations est un impératif.
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. Par exemple, quand on ouvre plusieurs instruments dans une même instance et que ces derniers ne se partagent pas d'effets dans les tranches de la table de Konatkt, ben, n'ayant aucune dépendance les uns envers les autres, ils peuvent être (en principe) traités par différents threads. Par contre, toutes les fonctions qui concernent un seul instrument (dans la fenêtre d'édition avancée de Kontakt, par exemple, entre autres, avec leurs effets respectifs) sont, elles, dépendantes d'un ordre de procédure concernant les calculs à effectuer.
Le principe demeure le même avec un plugin de synthétiseur. P. Ex., les différents oscillateurs peuvent être traité en parallèle (en principe), mais dès que leur « signal » respectif se rejoignent tous ensemble pour passer dans un des effets global du synthétiseur (par exemple, un chorus/reverbe), une « dépendance » (et un ordre temporel) se créer du fait que le chorus/reverbe ne peuvent être calculer simultanément que les oscillateurs du fait que ces effets doivent attendre le résultat des calculs traitant les oscillateurs avant de pouvoir être calculé. Du coup, aucun plugin le moindrement complexe (comportant des effets, etc. Donc aussi bien dire tous les VSTi de synthé actuel) ne peut jamais être totalement traité (toutes ses lignes de code) de façon simultanée (comme la vision simpliste d'Hakim) par plusieurs threads puisque, de toute façon, le ou les threads doivent attendre certains calculs ayant un ordre dans une « chaine en série »!
C'est juste ce principe logique qu'il est nécessaire de piger. Ça n'a rien à voir avec un DAW en particulier ni avec aucun logiciel ou plugin, c'est un principe logique universel!
"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
Hakim+K
2179
AFicionado·a
Membre depuis 19 ans
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...
[ Dernière édition du message le 23/04/2018 à 09:51:30 ]
- < Liste des sujets
- Charte