Superflu: La conversion est un autre problème, un problème de plus. Notre soucis est la sommation qui intervient en amont de la conversion.
C'est le convertisseur qui "fabrique" le signal analogique à partir d'une donnée numérique. Si la donnée numérique est "foireuse" le meilleur convertisseur du monde ne donnera qu'un son "foireux".
Le convertisseur travaille avec une seule donnée à la fois, celle qui sort de la sommation, quelle que soit le nombre de piste que l'on fait avaler à la sommation.
Barthe, Je n'ai pas lu ton lien dans les détails (pis de doute façon je comprends pas tout), mais ton résumé est plein de fondements. Je confirme que ces problèmes de sommation n'existent pas (beaucoup moins, voire pas du tout) sur les sorties aux, car effectivement peu d'entrée sont assignées à la sommation de ces sorties.
Mais par contre je ne crois pas à la résolution du problème en scindant la sommation en plusieurs groupes pour les remixer comme on le fait en analogique.
Je m'explique: il ne faut pas raisonner en ce que l'on connait de l'analogique mais en programme informatique.
Le routage d'une console numérique que l'on dessine sur le papier pour reprendre nos références analogiques, est totalement faux.
Les entrées : in1 in2 in3 in4
Les groupes : grp1 grp2
La sortie : out
Dans analogique : in1+in2=grp1 // in3+in4=grp2 // grp1+grp2=out
Dans numérique : in1+in2+in3+in4+gr1+gr2 = out
Pour essayer d'être plus clair les valeurs des grx ne sont que des données de corrections inclues dans le calcul de la sommation des inx. En gros la sommation ana est série, la num est parallèle. Par contre si tu fait une sortie grp, alors c'est un nouveau calcul de sommation pour ce convertisseur : in1+in2=grpout
Dans ce calcul de la sommation ne pas oublier d'y incorporer les correctifs d'Eq de Comp de Gate etc... Tout n'est que donnée de correction, le signal n'existe pas, ni avant ni après l'Eq qui n'existe pas lui même, sauf si tu assigne le post Eq au convertisseur casque, ça calculera une sommation spécifique pour lui.
Tout est données calcul, tout est virtuel.
Ce n'est pas moi qui programme chez Souncraft ou Yam, mais si je devais le faire je partirais dans ce sens. En proces numérique il est très couteux, en terme de cycles et de ressources calcul, d'adresser et de cataloguer en mémoire des sous-résultats. On essaie toujours de ne faire qu'un calcul définitif si toutes les entrées sont présentes.
Mes connaissance en programmation sont déjà plutôt vieilles avec des langages qui n'existent plus, alors peut-être que les nouvelles générations font autrement, je ne demande qu'à être contredit.
De plus, en admettant que les calculs se fassent en série, cela revient à dire que l'on fait une sommation de 2 sommations, ce qui revient à dire que l'on somme deux erreurs de sommation auxquelles on rajoute une autre erreur. même si on admet le taux d'erreur plus faible car moins chargé, le simple fait de faire des calcul sur des erreurs ne doit pas être tellement mieux.
Donc ce que j'ai essayé(très très vite fait) c'est de faire deux sommation, une pour les instrus et une pour les voix, les deux en stéréo donc quatre sorties donc 4 sommations et deux fois moins de travail pour chaque sommation. Ce qui implique deux façades, pour faire une sommation acoustique, oups! Et bien ça marche. Encore une fois j'ai fait ça à l'arrache avec des "Bandes", à confirmer en live.
Mais le plus simple je crois est quand même de prendre une console qui tienne la route pour le nombre de patch! Arf!
Par exemple une 64 piste quand on a besoin de 32, et donc de sous exploiter ces merveilleux miroir aux alouettes que sont les consoles d'aujourd'hui. Arf!
Bon! J'ai mal à la tête moi maintenant, vous m'avez obligé à réfléchir j'ai pas l'habitude...
Pourtant pas ingé numérique...
