QUOTE (reno08 @ mar 1 mai 2007, 20:56)
...Je maintiens qu'un microprocesseur fait toujours infailliblement les traitements et calculs qu'on lui demande, ouaip, et encore heureux ! Tu trouves pas ça le minimum, que quand tu donnes à une calculette un calcul elle se plante pas ?
Comme l'a dit jeriqo, t'as déjà vu un éditeur de texte qui te change 10% des lettres à chaque fois que tu enregistres ? Bien sûr que non !!
Les ordinateurs n'existeraient tout simplement pas si ce que tu disais était vrai, parce qu'un chiffre qui change dans de l'audio ou de la vidéo, c'est pas toujours dramatique, mais pour d'autres types de données un seul bit qui change peut tout planter !
Un ordinateur qui change comme ça des chiffres au pif ou qui ne retient pas EXACTEMENT ce qu'on lui donne ou qui fait des erreurs de calcul, ça signifie une barrette mémoire ou un processeur défectueux, et en général ça tient pas 10 minutes avant de freezer violemment...
Bon on va essayer de clarifier cette discussion !
Il y en a qui parlent de processeur (lequel n'est qu'une calculette puissante — et ça personne ici n'en doute)
L'argumentaire semble être : "
puisque le proc. ne se trompe jamais, le résultat du bounce est toujours identique. Et le quiproquo est : puisque les calculs sont toujours identiques donc le DAW (Digital Audio Workstation) est infaillible"...
Il me semble que c'est confusion de raisonnement — une mauvaise relation de cause à effet...
Et il y a ceux, dont le métier est d'utiliser des DAW jours et nuits, qui ne sont pas particulièrement informaticiens, souvent autodidactes, donc qui utilisent souvent un langage imprécis, inexact ou même poétique... Ces utilisateurs béotiens (en informatique) constatent qu'on n'est pas toujours dans le meilleur des mondes et qu'existent certains errements quant au résultat de leurs manipulations quelquefois hasardeuses...
Décortiquons un peu les opérations physiques nécessaires à un bounce, sous les ordres d'un logicien dédié à l'audio... (en une tentative de vulgarisation, donc, de ce fait, scientifiquement inexacte.)
Un calcul fait par le proc. ne se fait pas instantanément à un instant donné : à l'entrée un calcul à traiter, à la sortie le résultat du calcul... au milieu: le temps nécessaire au calcul. Il a donc une durée, c'est une fenêtre de temps
La durée de calculs étant dans une échelle de l'ordre des nanosecondes, cette durée a tendance à être considérée comme négligeable par les informaticiens...
Les ordinateurs ont évolué du mono-core (1 processeur) au bi-core (2 processeurs) au quadri-core (Next le premier en son temps) et aux multi coeurs etc...
Mais pourquoi donc ?
Parce le processeur ne calculait pas assez vite ce qu'on lui demandait de calculer dans un temps donné... Et évidemment si un problème survient au niveau du proc. un message d'erreur viendra l'annoncer.
Examinons vulgairement ce qui se passe dans un
DAW (lien avec la définition Wikipedia en anglais)
1) Les acquisitions
Le soft va chercher d'avance sur le (ou les disques) les fichiers audio pour les stoker en ram jusqu'au moment de les entendre... le temps d'acquissions est variable, dépendant du de la vitesse de lecture des disques et du nombre de pistes à lire.... en général un message d'erreur signale quand cette fonction n'est pas remplie dans le temps alloué
Le soft va chercher les représentations des waves (pour PT c'est le WaveCache.wfm)
Le soft va chercher les informations d'automation de mixage
Le soft va chercher l'image (quand il y en a une) qu'il doit afficher via une chaîne vidéo, (laquelle aura sa propre latence...)
Pour les plugins RTAZ ou VST ou AU, donc traités par le CPU (Central Process Unit ou en Français, unité centrale de calcul) et non pas des DSP (Digital Signal Processor) spécialisées, le soft principal va aussi utiliser le buss interne de l'ordinateur dans les deux sens.
C'est pourquoi le buss interne d'un ordinateur a autant évolué ces dernières années vers le 64 bits, avec ses variantes historiques de buss série, vers série/parallèle, multiplexage ... (et ce n'est pas fini!)
Le contrôleur du buss, c'est : à chacun son tour, à toi, à lui, à l'autre etc...
(Ça me rappelle que sur les premiers PC on pouvait déjà régler les interruptions de clavier (temps minimum entre 2 frappes) afin qu'il ne rentre pas en confit avec les autres opérations)
2) Les calculs
Tout ce qui a besoin d'être calculé est envoyé au CPU via la RAM qui stocke (tamponne) les informations en attendant de les envoyer à calculer au bon moment
au retour, la ram tamponne à nouveau pour les envoyer au bon moment vers la lecture et/ou ou l'enregistrement du fichier résultant
Pour un soft natif (n'utilisant que le CPU) le délai global de traitements sera conséquemment plus grand que pour du TDM (la latence que nous a très bien expliqué ici reno08 )
En résumé dans un DAW, chacun a une tâche à accomplir, dans des laps de temps donnés,
Maintenant, essayons de trouver d'où pourraient venir les anomalies quelquefois constatées.
Le maillon faible pourrait avoir pour origine les plugins utilisés et aussi la complexité du projet.
Cela va de situations conflictuelles entre différents plugins (non-respect du cahier des charges et des protocoles (tables d'attribution pour communiquer) donnés par le développeur du soft maître), à certaines médiocrités, légèreté ou escroqueries d'écriture desdits plugins.... etc...
Exemples:
- Quand on utilise en TDM certaines reverbes à convolution (qui demandent beaucoup de ressources) et si l'ordinateur en a la capacité, l'utilisation de plusieurs plugins de ce type (disons à partir de 5 à 6) fait que les convolutions semblent se délaiter, s'empâter, de dégrader... Sans doute une impression subjective)aussi le même plug (même preset) utilisé en TDM ou en natif "sonnera" différemment.
- Avec un compresseur multi bandes et multipistes genre C4, le résultat entre plusieurs passages pourra être différent (ce qui pourrait s'expliquer du fait de l'utilisation de paramètres tenant compte de l'historique du signal)
- Si on accumule plusieurs plugins sur la même tranche stéréo, certains plugins de EQ pourtant réputés auront une sommation en mono différente dans les fréquences aigues (dérive de la phase dans la bande passante) Etc...
L'utilisateur chevronné ne s'étonnera pas de ces "para phénomènes",
Une fois constaté il évitera, sans même plus y penser, certaines configurations qu'il a apprises à connaître souvent à ses dépens. (Ici on appelle para phénomène un résultat qui ne s'explique pas et qui de devrait pas exister dans la théorie. Quand cette anomalie aura été identifiée, on lui donnera un nom!)
Une autre raison d'errements pourrait être le non-respect, ou les erreurs de restitution numérique au travers du trajet du signal.
Vous allez rétorquer que dans les calculs il n'y a pas de trajet du signal et que c'est un fantasme de plus…Reformulons : des calculs exacts peuvent introduire des aberrations ou des trahisons dans le traitement du signal. Bien sûr ce n'est pas la calculette qui se trompe mais le programmeur qui est un branleur.
Le résultat pour l'utilisateur ira du message d'erreur clair et net (en général, pas toujours documentés sur le site « answerbase » de Digi ou celui sur celui des développeurs d'Apple), à la sensation diffuse qu'il y a quelque chose qui cloche…
Maintenant, les rapports de bugs sont triés par catégorie et classe de priorité…
Priorité veut donc dire qu'on traite en urgence les bugs prioritaires (Lapalissade)
Ps : Tien today il y a des updates de sécurité chez Apple. Une semaine pour réagir à de nouvelles failles de sécurité, détectées (publiées) le 20 avril…Pas mal ! j'espère que cela ne va pas foutre le souk dans nos DAW
Bounce Ou Pas?, la meilleure façon d'enregistrer un morceau
mar. 1 mai 2007, 21:11
*
