Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Tordre le cou au moteur audio:

  • 212 réponses
  • 40 participants
  • 30 644 vues
  • 56 followers
Sujet de la discussion Tordre le cou au moteur audio:
Ok, je vais essayer de mettre dans ce thread un petit recapitulatif d'avis t d'infos récupérés a droite a gauche sur le net, afin de ruiner le vieux mythe du moteur audio. merci de ne pas poster de commentaires et de ne pas entamer de fumeux debats sans arguments ici.
pour ça, un autre thread:
Tordre le coup au moteur audio: polemiques et crtiques
Afficher le sujet de la discussion
76
Citation :
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.

Ben oui c'était un peu ça l'idée...
Citation :
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 ! :boire:

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? Un peu d'ouverture d'esprit pour ne serait-ce qu'envisager un autre point de vue aurait évité cela.
Citation :
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.
Et de 5, je crois qu'on bien compris ça, vous pouvez juste arrêter de le répéter.

[ Dernière édition du message le 23/04/2018 à 11:56:59 ]

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

Ah ben si, car il y a plein d’autres logiciels qui en bénéficient bien. Et surtout : en général on fait tourner plein de logiciels en même temps sur nos ordinateurs. Et généralement chaque logiciel, à commencer par le système d’exploitation, utilise plusieurs threads (= fil d’execution = des programmes indépendants mais qui se synchronisent de temps à autres). Or chacun de ces threads peut tourner sur un cœur différent, d’où « une certaine augmentation de puissance ».

Mais s’il y a un thread qui fait des calculs hyper lourds, alors ça pourra se passera mieux avec moins de cœurs mais une fréquence d’horloge plus élevée (en supposant que ce soit les mêmes cœurs ; situation un peu théorique).
78
Citation :
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.

Ben c’est peu long à expliquer, bien que pas hyper compliqué dans le fond des choses.

J’ai un peu de mal à trouver un exemple bien clair, mais celui-ci n’est pas trop mal :
https://fr.wikipedia.org/wiki/Polymorphisme_(informatique)#Intérêt_du_polymorphisme


Citation :
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?

Ben ce n’était pas méprisant ; juste pour essayer d’être clair et précis. Je vois ce que tu veux dire, et je suis donc désolé que tu te sois senti agressé. :boire:

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

Bah on a tous nos petites passions et domaines de compétences ! L’informatique est hypervaste et je suis loin de tout connaître, mais ça me passionne depuis longtemps (et assez au centre de mes études et mon boulot).
79
Ces débats sont intéressants car ils montrent certaines des vraies difficultés qui caractérisent le « moteur audio » d’une STAN.

L’amélioration dans Logic 10.3.3 de la gestion du multicœur en est un exemple bien représentatif.

C’est pour ça qu’il ne faut absolument pas essayer de transposer dans le domaine numérique, les difficultés typiques qu’on rencontrait dans l’électronique analogique (comme par exemple « le son » d’une table de mixage).
80
Question complètement innocente puisque je n'y connais rien:
N'est-il pas possible d'imaginer:

Temps t: CORE A calcule r1=g(buffer B1).

Temps t+1 cycle: CORE A calcul r2 = g(buffer B2) | CORE B calcule Y1=f(r1) (obtenu par Core A au temps t)

Temps t+2 cycles: CORE A calcul r3 = g(buffer B3) | CORE B calcule Y2=f(r2) (obtenu par Core A au temps t+1)

etc. ?

Ainsi la relation entre les traitements est respectée mais distribuée sur plusieurs coeur.

81
Oui, c'est possible. C'est un schéma qu'on appelle le pipeline.
Mais pour une application audio, la granularité n'est pas forcément adaptée. Avec un petit buffer, ça coûtera souvent plus cher d'échanger les données que de calculer localement.
82
De toute façon c'est de notoriété publique que Logic sonne plus chaud que toute autre DAW ! :oops2::-Dicon_facepalm.gif
83
Personnellement je bosse avec deux DAW, une qui sonne plus chaud l'hiver, et une plus froide pour l'été, et ça le fait pas trop mal !!
84
Et si t'utilises celui qui sonne plus chaud l'été, du coup ca sonne plus chaud que chaud ! :bave::8O:
85
Citation :
Et si t'utilises celui qui sonne plus chaud l'été, du coup ca sonne plus chaud que chaud

Je pense qu'on doit pouvoir arriver à trouver un son plus analogique que le hardware, le seul paramètres a régler finement est le seuil du nombre de bières à utiliser!!

[ Dernière édition du message le 23/04/2018 à 16:53:11 ]

86
dommage qu'on soit sur AF, c'était techniquement intéressant
87
Dr Pouet, en y repensant je reste sur ma faim, par rapport à cette discussion. Si on résume en prenant du recul, les étapes de cette discussion étaient :
1. Je me plains d'un problème existant depuis le début de la MAO et des multi-cœurs, la surcharge single-core de la piste live. Je suis surpris qu'en 2018 les développeurs de Logic n'aient pas trouvé une parade.
2. Vous m'expliquez que c'est impossible, il faut faire un calcul après l'autre car ils sont interdépendants pour le jeu en temps réel, on ne peut pas les répartir sur les cœurs. C'est impossible et ça le sera toujours. (Répété plusieurs fois).
3. Je fais de la programmation (à un petit niveau) et en 20 ans je n'ai fait qu'entrevoir le champ des possibles en matière de programmation, je me dis qu'il doit y avoir un moyen quand même. Connaissez-vous donc toutes les techniques de programmation, tous les langages, pour dire que quelque chose est impossible? (au passage je démontre que ce n'est pas moi qui a des "certitudes" hein).

En pratique : Je veux jouer live un son d'Analog Strings de Output dans un Kontakt placé sur une piste de Logic et il me sature à lui tout seul le 24ème cœur (dans les jauges de Logic). J'ai déjà fait les différents trucs qui permettent de réduire la conso dans Logic et dans Kontakt (on ne va pas les redire hein!). Donc c'est impossible avec mon 12 cœurs 2.7GHz, il me faut une autre machine? C'est bien ça, vous confirmer?
88
Si Kontakt sature un core à lui tout seul, alors Logic n'y peut rien. C'est Kontakt qu'il faut lui-même paralléliser. Mais au vu du coût de synchronisation entre cores (avec le matos actuel), ça n'est pas trop rentable avec une granularité fine. Avec des buffers à 65536, pourquoi pas, mais la latence risque de ne pas être trop terrible.
89
C’est un problème conceptuel, donc aucune solution technologique ne pourra le contourner. C’est comme la conservation de l’énergie en physique : aucune technologie ne peut s’en affranchir, il est impossible d’avoir un rendement supérieur à 1, etc...

Accessoirement, au niveau langage de programmation, je soupçonne que toutes les STAN soient écrites en C ou C++.

La solution serait effectivement plutôt du côté des réglages dans Kontakt, mais si tu as tout essayé, ça semble mal barré. Ça pourrait venir de problèmes de timing, comme évoqué dans la vidéo postée dans l’autre thread. Tu joues en temps réel ? 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 ?

Edit : la vidéo sur les aspects timing temps-réel :



Bon d’un autre côté, ce qu’on a expliqué est un principe théorique, en supposant toutes choses égales ou optimales par ailleurs. Mais il se peut très bien que des choses ne soient pas faites de manière optimale dans Logic, qu’elles pourraient consommer moins de ressources, et donc qu’une nouvelle version pourrait améliorer (ou dégrader !) la situation. Idem pour Kontakt.

Et puis on n’a parlé que de la charge CPU en partant du principe que le problème est bien là, mais c’est peut-être plus compliqué (problèmes de timing / interruptions comme évoqués dans cette vidéo).

[ Dernière édition du message le 24/04/2018 à 09:01:38 ]

90
@alex.d.
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.

@Dr Pouet
On commence à la connaitre par cœur cette vidéo, elle est déjà 10 post plus haut...
Citation :
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 ?
Ben tu te doutes bien que c'est ce que je fais, ou j'allège le son en reduisant le nombre de voix et d'effet dans Kontakt, c'est plus pour jouer en concert le problème car je voudrais en plus piloter 2 instruments Output... par dessus le jeu d'une séquence Logic.
Mais si physiquement c'est impossible de répartir la conso de cette instance Kontakt dans le cadre d'un jeu live, comment se fait-il que ça soit possible en utilisant un bridge comme VEP? Je joue mon Kontakt placé dans le VEP5 depuis Logic et comme par miracle tous les cœurs sont utilisés. (Juste que je ne veux pas dépenser 250€ maintenant). C'est bien une solution réalisée par programmation non? Donc ce n'est pas impossible! Tout comme il ne serait pas impossible que Logic implémente d'une façon ou d'une autre ce type de solution de façon masquée en interne?

[ Dernière édition du message le 24/04/2018 à 09:13:45 ]

91
Par conséquent il y a certainement un truc perfectible dans Logic.

Il n’est pas exclu qu’une astuce ou un réglage côté Logic pourrait résoudre le problème, mais je ne saurais pas dire lequel. En fait si ça passe avec Kontakt seul, c’est étonnant que ça ne passe pas dans Logic.

Dans Logic tu as des effets sur la tranche où tu as mis Kontakt ? As-tu essayé sans ?


Il faut bien voir que les explications qu’on a données portent sur, disons, « les limites maximales ». Mais si les choses ne sont pas bien optimisées, on peut ne pas exploiter au mieux un cœur ; c’est à ce niveau là que les choses peuvent éventuellement s’arranger.

[ Dernière édition du message le 24/04/2018 à 09:35:10 ]

92
je viens de regarder, Analog Strings me semble en plus être effectivement un bouzin assez costaud mêlant samples et synthèse, de quoi mettre à genoux un coeur pas à la pointe de la rapidité...

C'est pour ça que j'apprécie la fonction de omnisphère permettant de charger les presets en version "lite" pour le jeu live

Avocat du diable et de sa musique et expert en vacuité dispendieuse.

93
J'ai dit que j'arrive quand même à m'en sortir, on peut aussi alléger les sons dans Kontakt mais ça s'entend, et en live j'aimerais mettre 1 Analog String + 1 substance dans un Kontakt.
Et sinon par rapport à ma question avant (post 90) sur le fait de placer Kontakt dans Vienne Ensemble Pro?
Pourquoi là c'est réparti sur les coeurs, pourquoi Logic n'utiliserait pas de façon masquée ce genre de subterfuge?... en tout cas c'est possible ;-)

[ Dernière édition du message le 24/04/2018 à 09:39:15 ]

94
Citation de Hakim+K :

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.

Bon, donc d'une manière ou d'une autre, Kontakt est déjà parallélisé. J'imagine qu'il répartit simplement les différentes voix sur les cores, et que la synthèse d'une voix elle-même n'est pas parallélisée.

Après, on en arrive au grand problème suivant du parallélisme : l'allocation des ressources. Qui décide du nombre de cores à utiliser, et comment fait-on pour que tout ça ne se marche pas sur les pieds les uns des autres ?
Si tu exécutes Kontakt en standalone, il utilise tous les cores qu'il veut. Si tu l'exécutes en plugin, que se passe-t-il ? En vrai, je n'en sait rien ; je connais bien le standard LV2, mais pas trop VST. Le plugin peut-il exprimer qu'il veut plusieurs cores ? Je ne pense pas. Du coup, Logic l'exécute sur un core, comme un plugin normal. 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. Et même si on imagine que Kontakt puisse demander plusieurs cores, qui décide du nombre à lui allouer ? Pour décider, il faudrait connaître les besoins de tous les autres plugins et diviser. Pas impossible, mais assez chaud à faire.
95
Oui c'est l'explication habituelle du phénomène c'est d'ailleurs la raison qui fait qu'on doit régler Logic en multithread et mettre le paramètre multi-core du plugin Kontakt sur off, sinon c'est pire. Par contre dans la version standalone de Kontakt on met le paramètre multi-core sur le max. Kontakt permet des réglages différent entre standalone et plug.
Par contre si je mets Kontakt dans un bridge, la répartition fonctionne, bien que je le joue toujours depuis une piste de Logic.
96
Citation de Hakim+K :

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

c'est pourquoi tu n'acceptes pas les explications données plus ?!? ce serait intéressant de connaître le fin mot de l'histoire ...
97
Non mais il faut dire que Alex.d et moi, on a philosophé sur une question théorique assez simple : « peut-on paralléliser (= découper en petits bouts et mettre dans des threads, pouvant être répartis sur différents cœurs) n’importe quel petit morceau de logiciel ? ».

On a essayé d’expliquer pourquoi ce n’est pas toujours possible, et donc pourquoi il ne serait pas forcément intéressant d’avoir un ordinateur avec mille cœurs, chacun tournant à 500MHz.

Mais la réalisation technique concrète des choses est souvent loin d’être aussi bien que ce qui est théoriquement possible et optimal ; donc il peut y avoir des marges d’amélioration. Chose que recherche Hakim.

Là vu que ça marche en bridge, ça laisse penser qu’il y a encore des trucs pas bien optimisés dans Logic.

[ Dernière édition du message le 24/04/2018 à 15:39:36 ]

98
Citation :
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 dans ce cas tu as la même chaîne de traitements ? Notamment 1 Analog String + 1 substance dans Kontakt, + des effets dans Logic ? (bref tout pareil mais avec le bridge en plus)

Si oui, il semble que le problème et les limitations soient du côté de Logic. Déjà le fait que Logic soit incompatible avec le multicore de Kontakt, ça ne me semble pas génial quand même.

Citation :
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.

Vu le test en bridge, ça semble plutôt mieux se passer.

[ Dernière édition du message le 24/04/2018 à 15:41:24 ]

99
Citation de Hakim+K :
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 :8O:... 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...

J'ai rarement vu autant de conneries en un seul post. Bravo. Tu n'as rien compris au traitement du signal, a l'IA ou meme a la programmation.
100
icon_facepalm.gif
Miles, un peu de tact, que diable ! :-D

En plus on s’est expliqué et fait des bisous dans les messages après celui que tu cites !

Allez, peace :boire: :bravo:

[ Dernière édition du message le 24/04/2018 à 16:52:09 ]