Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Digidesign Pro Tools 7 Le
Agrandir
Ajouter ce produit à
  • Mon ancien matos
  • Mon matos actuel
  • Mon futur matos
Digidesign Pro Tools 7 Le
Photos
1/15
Digidesign Pro Tools 7 Le

Séquenceur généraliste de la marque Digidesign appartenant à la série Pro Tools 7

Remplacé par Digidesign ProTools 8 Le.

15 avis
Présentation du produit Présentation
Avis 15 15
Comparateur de prix
Petites annonces
Forums 192 192

Mythe ou réalité

  • 160 réponses
  • 21 participants
  • 7 299 vues
  • 23 followers
Sujet de la discussion Mythe ou réalité
Je lis que Pro Tools sonne et j'en déduis que sa notoriété viens de là. Cependant aujourd'hui il est difficile de comprendre pourquoi Pro Tools sonnerait et pas les autres...tous les séquenceurs actuels fonctionnent en 32 bits et si leurs algorythmes étaient moins performants on peut supposer qu'au fil des versions ils ont rattrapés leur retard.
Alors mythe ou réalité, est ce que Pro Tools sonne mieux que Cubase, Sonar, Ableton, Logic, Digital Performer...
Si vous avez eu un jour l'occasion de comparer, merci de laisser vos impressions sur ce thread :clin:
Afficher le sujet de la discussion
131
Tu veux dire que l'on peut programmer facilement un routeur audio qui fasse aussi enregistreur et lecteur (Jack c'est juste un routeur), et comme le précise binsou2005, pas en utilisant des librairies toutes prêtes, en faisant comme Jorgen Aase (et d'autres)?
132

Citation : Pourtant aux dires de certains router du son est une opération somme toute genérique qui n'induit aucune variation d'un programme a l'autre du moment que ce sont des 0 et des 1 qui transitent sur un princique toujours identique?


En principe sur la chaine que j'ai évoqué rien ne permet de supposer qu'à un moment ou à un autre on perde de l'information...le traitement est déterministe sur cette chaîne (en mettant A en entrée on aura toujours B en sortie). Donc comme le dit Pov Gabou c'est du travail sans plus.
Cependant et lorsque l'on voit la différence de son que produisent les "pilotes" des différents players sous window (à moins que ce ne soit dans la couche supérieure ..soit l'application, c'est plus probable d'ailleurs) on peut en toute paranoia se demander si le pilote que l'on utiliserait n'effectuerait pas un traitement déjà sur les données (filtrage hautes et basses fréquence enfin que sais je)Donc si l'on veut tout contrôler..il faut tout faire.

Citation : Non mais je sais bien. J'utilise le terme de volume pour bien faire comprendre le truc, mais globalement, chaque fois que tu fais des gains dans ta table de mix virtuelle, c'est bien des changements de niveau, et avec le flottant tu n'as pas besoin de te soucier de mixer des trucs a -60 dB, tu perds rien en precision.



Ce n'est pas la représentation d'une valeur (son codage qui pose un problème), on peut créer des types en développement (language C) et si tu veux un développeur peut créer un type Xreal de 128 bits soit 4 double.
Le problème se pose lors des opérations...Quand on fait des opérations avec des valeurs codées sur la taille des registres du processeur il n'y a pas de problème de troncature d'arrondis..etc..dès que la valeur dépasse la taille du registre c'est la que la cuisine interne commence et que tu peux supposer voir ton info sur de long calculs légèrement modifiées.
Aujourd'hui typiquement on fait des acquisitions en 24 bits pour des processeurs dont le "mot" élémentaire (on va dire la valeur élémentaire la plus petite manipulée, à ne pas confondre avec sa traduction littérale en anglais word = 2 bytes soit 16 bits) est 32 ou 64 bits donc on a un peu de marge et d'ailleurs je suppose que ce dimensionnement ne résulte peut être pas d'une donnée économique (prix des convertisseurs) mais peut être aussi de cette considération technique.En électronique un bon système est forcément un système bien dimensionné. Travailler avec des convertisseurs en 32 bits sur un système en 32 bits nous exposerait à des erreurs d'arrondis et de troncature dès les premières opérations ce qui nuirait à la qualité finale.
(si c'est pour se retrouver avec un son de ligne téléphonique à la fin...j'exagère volontairement).
A noter qu'il existe des algorithmes permettant de repousser ces erreurs de troncature vers des décimales ou elles ne sont plus significatives...mais cela implique de faire des tests sur chaque opération et des traitements lourds. (il existe probablement des bibliothèques qui le font)
voila...voilou
133

Citation : Cependant et lorsque l'on voit la différence de son que produisent les "pilotes" des différents players sous window (à moins que ce ne soit dans la couche supérieure ..soit l'application, c'est plus probable d'ailleurs) on peut en toute paranoia se demander si le pilote que l'on utiliserait n'effectuerait pas un traitement déjà sur les données (filtrage hautes et basses fréquence enfin que sais je)Donc si l'on veut tout contrôler..il faut tout faire.

Je suis bien content de lire un type qui connais la théorie (a priori ingénieur:clin: ) et qui appréhende les mêmes differences d'acquisition/restitution audio d'un soft a l'autre que l'ignare instinctif (mais qui tente d'être un peut rigoureux) et issue de formation purement artistique que je suis.
134
Aux Etats Unis pour enseigner la philosophie il faut faire des études scientifiques avant. On ne conçoit pas que quelqu'un puisse échafauder des démonstrations philosophales de qualité si il n'a pas au préalable structuré sont esprit et développé ses qualités d'analyse dans une formation adéquate.
En France on oppose l'esprit artistique et l'esprit cartésien comme si il était impossible de conjuger les deux...ce qui est indubitablement faux.
Il y a d'ailleurs des graphistes, musiciens, etc dont on ne peut nier la sensibilité artistique et qui s'illustrent aujourd'hui dans des environnements tel le développement logiciel en complet autodidacte et de façon brillante.(je crois que le concepteur de Bryce sort des beaux arts ou arts déco)
135

Citation : Aux Etats Unis pour enseigner la philosophie il faut faire des études scientifiques

:mdr:

Oui, bon là ils n'ont pas inventé la poudre ! tout au plus ont-ils lu le Discours de la méthode écrit par un certain Français. De manière universelle, depuis le XVIIème, être Cartesien, c'est justement être philosophe et scientifique. et c'est bien une idée de chez-nous non :D: ?!.

Trop de morceaux de musique finissent trop longtemps après la fin. [Igor Stravinsky]

136
Une idée qui n'est plus d'actualité il me semble...
Tu as fait ta philo en fac de sciences toi? :clin:
Mais on s'éloigne du sujet...tu as Pro Tools?
137
Non, j'nai pas protools, mais j'ai essayé un temps, la version PC qui tournait sur Windows 98.

C'était pas extraordinaire, mais à l'époque Protools et surtout ces DSP faisaient réver parceque nos modestes bécannes étaient incapable d'encaisser de gros calculs, les premiers VST n'arrivaient pas à la cheville des Waves TDM.

Evidemment, depuis, l'eau a coulé sous les ponts. La plupart des plugins reservés hier aux plateforme DSP tournent maintenant en natif sur un pauvre portable de bureau (je viens d'essayer l'EQ Oxford de Sony, un délice ).

C'est pourquoi je reste surpris devant tant de phantasme autour du logiciel Protools.

En revanche leur surface de control, c'est autre chose. J'ai une petite bcf2000 et je la trouve déjà remarquable mais l'Icon, là c'est autre chose. Il y a une vrai différence.

Trop de morceaux de musique finissent trop longtemps après la fin. [Igor Stravinsky]

138

Citation :
Cependant et lorsque l'on voit la différence de son que produisent les "pilotes" des différents players sous window (à moins que ce ne soit dans la couche supérieure ..soit l'application, c'est plus probable d'ailleurs) on peut en toute paranoia se demander si le pilote que l'on utiliserait n'effectuerait pas un traitement déjà sur les données (filtrage hautes et basses fréquence enfin que sais je)Donc si l'on veut tout contrôler..il faut tout faire.



Je pense peu probable que pour des drivers "pro", on fasse un traitement. De plus, faire des traitements dans les drivers, c'est un peu suicidaire je pense (sous linux, par exemple, utiliser la FPU, c'est niet dans le kernel). Apres, la couche au dessus (qui a souvent tendance a faire partie du driver sous windows il est vrai, mais bon, windows n'est pas un exemple de design fantastique en general, pour le son en particulier) peut faire des traitements, mais c'est justement ce que tu veux eviter, et ce pour quoi ASIO existe (enfin, une des raisons).

Citation :
Ce n'est pas la représentation d'une valeur (son codage qui pose un problème), on peut créer des types en développement (language C) et si tu veux un développeur peut créer un type Xreal de 128 bits soit 4 double.



En general, un double, c'est 64 bits. Et en C, tu peux justement pas creer de types (c'est une difference fondamentale avec le C++; d'ailleurs, meme le C++, tu peux pas vraiment faire de types, mais je m'egare). Et ton type Xreal, c'est ultra galere a gerer, puisque tu dois faire en soft ce qui est normalement fait en hardware (imagine emuler des double avec des float...). Il y a des librairies pour ca, mais c'est jamais utilise en audio, je pense (le temps de calcul serait au moins multiplie par 10, je pense, voire plus, comme au temps des 486 SX qui emulaient les flottants en soft).

Bref, ce que je voulais dire dans le passage que tu citais, c'est que ca n'a aucun sens de comparer les bits entre deux representations differentes: dire que 48 bits chez pro tools (il m'a toujours semble que c'etait du 24, d'ailleurs ?) c'est mieux que le 32 bits des PC, ca ne veut strictement rien dire. En fixe, la precision effective depend du niveau absolu de tes valeurs, alors qu'en flottant, non.

Citation :
Tu veux dire que l'on peut programmer facilement un routeur audio qui fasse aussi enregistreur et lecteur (Jack c'est juste un routeur),



Non, jack, c'est tres balaise, ca resoud justement une partie des problemes que les systemes sous windows/mac resolvent a l'aide du "moteur audio" (synchronisation, etc...). Par contre, un programme qui est au dessus de jack, et qui dump le son qui lui arrive dans un fichier (disons fichier wav), c'est 200 lignes de code a tout casser (c'est d'ailleurs un des exemples fourni dans la doc developpeur de jack).

Le truc fondamental, c'est comme dit d'agir au niveau le plus haut qui soit commun aux deux softs qui sont compares. Donc par exemple si tu veux comparer 2 softs qui utilisent tous les deux asio (plutot courant), alors tu peux faire un petit truc qui lui aussi utilise asio.
139
J'aimerais bien savoir qui c'est déjà permis de supprimer ce message. J'ai créé ce thread et j'entends bien ne pas laisser dire n'importe quoi dessus...Si vous voulez censurer quelqu'un...et bien censurez les mythomanes qui sévissent sur AF et répandent gratuitement la polémique.

Allez fini les gamineries...VADE RETRO MYTHO :clin:

Citation : Je pense peu probable que pour des drivers "pro", on fasse un traitement


C'est tout l'inverse..les drivers pro comme tu le dis s'entendent pour du matériel dédié que l'on trouve sur du matériel de studio haut de gamme (pyramix..etc) et au contraire question pilote..il serait logique de penser que tout y est permis, y compris de ne respecter aucun protocole standard. Avec un matériel propriétaire et sans souci de compatibilité on fait des pilotes...propriétaires..logique non?

Citation : De plus, faire des traitements dans les drivers, c'est un peu suicidaire je pense (sous linux, par exemple, utiliser la FPU, c'est niet dans le kernel)


Ha bon?? De mieux en mieux...Suivant les vieux principes utilisés en informatique (les mêmes depuis 30 ans) on utilise la FPU (unité de calcul flottante) à travers des instructions spécifiques envoyées au processeur et non directement.Celui-ci les dispatch vers la FPU. Quoi de plus logique encore une fois. Ensuite cela voudrait dire que dans le noyau on ne peut utiliser certaines instructions du processeur..ce qui est bien évidemment le contraire, le noyau représentant un environnement d'exécution possédant justement tous les "privilèges".


Citation : Apres, la couche au dessus (qui a souvent tendance a faire partie du driver sous windows


Aucune couche ne fait partie d'un driver..ce serait plutot l'inverse...voir le modèle OSI ici comme exemple de décomposition en couches pour les applicatifs réseau :
http://www.frameip.com/osi/



Citation : windows n'est pas un exemple de design fantastique en general, pour le son en particulier) peut faire des traitements, mais c'est justement ce que tu veux eviter, et ce pour quoi ASIO existe (enfin, une des raisons).

Qu'est ce que tu en sais..tu n'as manifestement pas les compétences requises.

Citation : En general, un double, c'est 64 bits

C'est vrai si on se base sur une plateforme 32bits..sur une plateforme 16bits c'est 32bits, 64bits ->128, etc. Donc tout va dépendre de la plateforme (du processeur). Il n'y a pas d'en général.

Citation : Et en C, tu peux justement pas creer de types (c'est une difference fondamentale avec le C++; d'ailleurs, meme le C++, tu peux pas vraiment faire de types

C'est faux et tu ne connais manifestement ni le language C ni le C++. La primitive "typedef" permet de définir un type particulier..soit en renommant un type existant soit en définissant un type struct..voir ci-dessous pour plus de précisions :
http://www-clips.imag.fr/commun/bernard.cassagne/Introduction_ANSI_C/node115.html
http://c.developpez.com/faq/?page=types

Citation : Et ton type Xreal, c'est ultra galere a gerer, puisque tu dois faire en soft ce qui est normalement fait en hardware (imagine emuler des double avec des float...). Il y a des librairies pour ca


Evidement il faut un certain niveau pour cela..Quand aux librairies ce n'est pas Jésus qui les à fait..heureusement d'ailleurs.


Citation : mais c'est jamais utilise en audio, je pense (le temps de calcul serait au moins multiplie par 10, je pense

Ha bon?? Comment tu peux savoir cela?? Un calcul multiplié par 10?.comme ca de tête...étant donné le nombre d'âneries que tu distilles lol :mdr:



Citation : Bref, ce que je voulais dire dans le passage que tu citais, c'est que ca n'a aucun sens de comparer les bits entre deux représentations différentes: dire que 48 bits chez pro tools (il m'a toujours semble que c'etait du 24, d'ailleurs ?) c'est mieux que le 32 bits des PC, ca ne veut strictement rien dire.

D'ou tu sors cela? Je n'ai jamais fait ce type de rapprochement. :oo:

Citation : En fixe, la precision effective depend du niveau absolu de tes valeurs, alors qu'en flottant, non.

Ca n'a aucun sens.Tu ne sais pas ce qu'est un nombre flottant et sa représentation dans un système informatique..comme le confirme un de tes premiers post ci-dessous.

Citation : Non, non, c'est tout en 32 bits flottant. Faut vraiment bien faire la différence entre flottant et fixe, ca ne veut rien dire de comparer les bits comme ca, sinon. Un nombre 32 bits flottant, c'est un bit de signe, 23 de precision (mantisse en termes savants) et 8 bits pour le "niveau" (exposant).

En partie faux. Dans ton argumentation tu parles de niveaux et il semblerait que tu penses qu'un flottant code une valeur fixe. Tu écris d'ailleurs que l'exposant code le "niveau". Je ne sais pas d'ou viens ce niveau. Un nombre flottant est avant tout et simplement un nombre à virgule. L'exposant code comme sur ta machine à calculer l'emplacement de la virgule, voir ici pour les détails de la repésentation de nombres (nombre à virgule) en langage C :
http://www.commentcamarche.net/c/ctype.php3

Citation : Maintenant, en notation flottante, si ton signal est très faible, la partie exposant fait office de "volume", et tu peux donc garder la précision meme a faible niveau (dans une certaine mesure, évidemment). C'est pour ca que sur PC, on utilise presque toujours du flottant

Relier une notation en virgule flottante et un signal n'a aucun sens. Le convertisseur converti le signal en présence en une valeur entière codée sur 8,10,20 bits qui sera ensuite reprise par le système informatique dans une variable propre au langage(nombre flottant). Donc aucune relation entre le signal et le codage informatique. Que ton signal soit fort ou faible..le programme derrière se chargera de récupérer la valeur délivrée par le convertisseur sans plus. Encore une fois tu parles de volume...On utilise des nombres flottants tout simplement parce que les calculs génèrent des nombres à virgule.

Citation : Par contre, un programme qui est au dessus de jack, et qui dump le son qui lui arrive dans un fichier (disons fichier wav), c'est 200 lignes de code a tout casser

Avec ce qui suit ci-dessus :mdr: :mdr: :mdr:
140
Je comprends pas tres bien ces attaques sans fondements. Tu serais pas eleve ingenieur par hasard ? ;)

Que tu ne sois pas d'accord avec mes points techniques, c'est une chose, mais m'accuser de mythomanie parce que tu ne comprends pas ce que je dis en est une autre. Tous les points que j'ai developpes sur ce thread sont fondes, et issus de ma vision des choses en programmation. A part jouer sur les mots, et faire des contre sens un peu gros, je comprends pas tres bien tes arguments.

Hors sujet :
Pour la mythomanie, je sais pas bien quoi te repondre, a part que suffisament de personnes sur AF m'ont rencontre soit en vrai, soit sur d'autres forums/communautes, entre autre de programmation.

J'ai participe a suffisament de threads techniques sur le traitement du signal qui montrent que sans etre un expert (je me pose pas en ayant lu un pdf, perso, typiquement ;) ), je connais un minimum de quoi je parle lorsque je parle de traitement du signal.