Tordre le cou au moteur audio:
- 212 réponses
- 40 participants
- 30 644 vues
- 56 followers

Anonyme

pour ça, un autre thread:
Tordre le coup au moteur audio: polemiques et crtiques

Hakim+K

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...
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 !
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.
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.
[ Dernière édition du message le 23/04/2018 à 11:56:59 ]

Dr Pouet

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).

Dr Pouet

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
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é.

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).

Dr Pouet

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).

Tomb

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.

alex.d.

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.

rubz





ivanoff


rubz




ivanoff

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 ]

Anonyme


Hakim+K

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?

alex.d.


Dr Pouet

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 ]

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.
@Dr Pouet
On commence à la connaitre par cœur cette vidéo, elle est déjà 10 post plus haut...
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 ?
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 ]

Dr Pouet

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 ]

chacal549

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.

Hakim+K

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 ]

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

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.

Anonyme

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

Dr Pouet

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 ]

Dr Pouet

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.
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 ]

miles1981

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...
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.
Audio Toolkit: http://www.audio-tk.com/

Dr Pouet


Miles, un peu de tact, que diable !

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


[ Dernière édition du message le 24/04/2018 à 16:52:09 ]
- < Liste des sujets
- Charte