ben je crois que les deux approches de l'informatique (au sens large du terme) restent extremement differentes.
de mes yeux , j'ai vu une session nuendo ne pas jouer un groupe de pistes parce qu'on avait changé la video.
surement un fichier dont le pc n'aimait pas le codec.

alors, je dirais, que le soft ne l'ait pas joué est une chose.
qu'il ne nous ait rien dit en est une autre.

continuez à "penser" que , parce que vous n'avez pas de message d'erreur, il n'y a pas d'erreurs.

dormez bien braves gens.

nous faisons du son avec des oreilles, et pas avec des certitudes.

bien à vous,
moi je retourne dans les mines du roi solomon *





* zut, elle est bonne celle là, non?

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

Quelques autre réflexions:

Dans les tâches à accomplir par un ordinateur (l'ensemble des éléments qui le compose) il y a celles qui sont prioritaires et celle qui peuvent souffrir d'un certain délai d'exécution.

Longtemps les cartes video du Mac on été médiocres.
Quand dans une session Protools la barre de défilement prend du retard... Il suffit, pour résoudre le problème, de changer pour une carte video plus puissante.
.
Et vu que je suis un peu pervers, je m'amuse, sur Un Gros MacIntel avec une Grosse carte video, en mettant sur le même disque SATA interne les audio files et fichiers vidéo en HD.264....
Eh bien ce n'est toujours recommandé, le display freeze de temps en temps (interruption du défilement de l'image - alors que sur un G5, c'était désynchronisation entre le son et le display)
On arrête pas le progrès!
Qui n'a pas constaté qu'une automation en play ne rejoue toujours en temps et en heure ce qui a été écrit ? surtout sur des automations de plugins (et encore il y a eu beaucoup de progrès de réalisés!)

Yo !

Jolie les amis,

En gros revenez à l'analogique au moins on avait des données techniques concernant le signal ...

ok je sors ...

Alors ca je n'y crois pas une seconde... a moins d'avoir de serieux problemes avec la carte graphique, de driver par exemple, auquel cas tout serait ralenti, même la souris.
Hormis cas particuliers (Open GL, Drect X, etc), la carte graphique ne calcule rien, c'est exactement comme une carte son. N'importe quelle carte graphique est capable d'afficher en 60Hz.

Pour en revenir aux DAW, la seule différence que je vois entre un bounce offline et une lecture/bounce online, c'est le temps que mettent les plugs à calculer. Si le DAW gere mal la compensation de délai alors il peut éventuellement y avoir une différence.

Mais franchement, j'imagine que ce doit etre très léger, et que de déplacer un micro d'1mm à la prise changerait 100 fois plus le son, alors faut ptetre pas chercher le probleme au mauvais endroit.

Et sur quoi tu établis ton incrédulité?
Quand on affirme le contraire d'un autre avis exprimé dans un forum, cet avis contradictoire doit être argumenté ou justifié, il faut être constructif !.
Tu n'y crois pas et tu imagines... Donc tu sais ou ne sais pas ?

salut

moi ,un jour après avoir retouché un morceau,
je refis un bounce.
et puis là.....je ne sais pas ce qui c'est passé,c'est la première fois que je voyait ça!
toute la construction était chamboulée
les reverbes en retard,des sons qui n'etait pas a l'endroit ou je les avait posé!
mais..comme par magie ce bug m'a pondu un remix de fou !
je n'aurai jamais eu assez d'inspiration pour faire pareil,
on peut appeler ça "accident positif",non?!
comme quoi les bugs parfois et meme souvent ça a du bon et c'est bien connu,
ou on a rien compris en musique electronique car ça en fait encore partie!
a condition qu'il en sort au moins une version comme on le souhaite au cas ou..
@+++

Peut-on me dire enfin ce que sont un "bounce on-line" et un "off-line" ??? Il faut bien écouter le mix total avant de "bouncer" ou "mixer(?)" .

(mon avis est que) La mise au point de wfplb n'aurait pas été nécessaire si il y avait eu plus de rigueur dans les interventions. On a changé subrepticement de sujet au fil des pages.
La bataille des "ego" est super barbante.
Faut-il arriver à mon âge pour ne pas sentir minable quand quelqu'un a prouvé que vous avez dit une ânerie ?
Ah, j'vous jure

oui c'est bien de ça dont il est question maintenant alors que ce topic était passionnant

J'ai pourtant bien expliqué, la carte graphique ne fait pas de calcul, donc changer de carte ne peut pas résoudre un problème de lenteur d'affichage dans pro tools