Commentaires sur le test : C'est un petit pas pour l'homme-studio...
- 232 réponses
- 48 participants
- 51 228 vues
- 51 followers
Red Led
Lire l'article
Ce thread a été créé automatiquement suite à la publication d'un article. N'hésitez pas à poster vos commentaires ici !
miles1981
Audio Toolkit: http://www.audio-tk.com/
Solid Foundation prod
Salut
Traumax
Hors sujet :
Le balises HS évitent l'envoi de mail aux inscrits.
HUROLURA
Les gars votre discussion est surement très intéressante, c'est mailing forum ici... ça me parais un peu s'éterniser et dévier du sujet original l'apollo.
Salut
Ben non, on essaie de discuter de ce qui se passe à l'intérieur ...
Bon, c'est sûr, c'est un peu barbant/compliqué/pas très musical.
Mais dès qu'on lance un débat DSP versus Natif, c'est le risque.
Et c'est sans fin, chacun pouvant avoir son opinion sur le sujet.
Et comme il y a très peu de plugs disponibles à l'identique sur DSP et natif, c'est à mon avis un peu vain ...
Pour ma part, je n'ai pas d'avis tranché, je cherche juste à comprendre.
J'avais tendance effectivement à me dire que avec la poursuite de la montée en puissance des PC, l'argument des solutions DSP consistant à soulager les CPU est de moins en moins flagrant.
L'argument latence demeure mais peut être verra t'on bientôt des drivers plus performants que les ASIO avec des liaisons (type thunderbold) plus performantes également qui réduiront cette différence.
Je pense simplement que l'Apollo est un progrès par rapport aux UAD2 parce qu'elle apporte enfin une première réponse à ce qui devenait pour moi le principal défaut de ce type de solution à savoir ajouter latence I/O-DAW et latence DAW-DSP en faisant du I/O-DSP-DAW.
Le plus important à mon sens c'est de juger de la qualité des plugs proposés et le fait d'être en DSP ou non est secondaire dans 80% (aujourd'hui) des cas (quand on ne fait pas de temps réel).
Le fait d'intégrer DSP+carte son+plugs permet d'avoir du tout en un.
UAD était le dernier à proposer des "accélérateurs" à base de DSP sans I/O, les autres étant passé au natif pour la plupart (SSL Duende) tout en conservant ce savoir faire DSP là où il est pertinent/utile (TC qui abandonne powercore mais en garde un morceau au niveau des interfaces Konnekt, SSL qui abandonne les Duende hardware mais a toujours dans sa gamme le MX4 qui combine I/O et DSP, Focusrite qui abandonne les Liquid Mix mais a toujours du DSP dans sa Saffire Pro 24 DSP ou Liquid Saffire 56). De fait, UAD faisait un peu figure de dernier des mohicans.
A terme, on verra sans doute disparaître les UAD2 au profit de déclinaisons de l'Apollo (sauf peut être comme carte d'extension pour interface type Apollo).
L'autre atout que peut présenter le DSP, c'est l'aspect utilisable sans ordi, un peu comme les Nord Modular à une certaine époque: on utilise l'ordi et sa souplesse en phase de préparation mais on peut être autonome en live ou simplement pour pouvoir mettre sous tension et faire de la musique sans prise de tête.
[ Dernière édition du message le 19/04/2012 à 09:42:28 ]
Anonyme
Hors sujet :
jeriquo-> l'aléatoire dont tu parles ne parait pas bien compliqué à mettre en oeuvre, c'est juste des probas avec une loie de répartition uniforme.
Il me semble que c'est ce que fait un dithering en mode rectangular.
miles1981-> merci d'amener un peu de sérieux et d'expérience à cette discussion.
HUROLURA
Hurolora > Si tu écris un code C, il a le même comportement sur toutes les plateformes. La majorité fait de toute manière du out of order, donc l'ordre n'a rien à voir dans l'histoire. Si tu respectes le standard, tu as une assurance d'avoir un résultat identique (à des fractions non audibles près selon le niveau d'optimisation et le respect de la norme IEEE que tu demandes).
Nous sommes tout à fait d'accord, si on utilise du C normalisé pour exécuter le même code sur différentes plateforme, on obtient bien des résultats identiques (c'est un peu l'objectif).
Mais ça suppose d'avoir le même code source en C et de le compiler pour les différentes cibles.
On aura bien le même résultat, pas nécessairement la même performance (ça dépend un tout petit peu de la cible).
Mais, comme précisé auparavant, un plug fait pour la plateforme SonicCore (celle que je connais) n'est pas écris en C mais à l'aide d'un outil qui permet d'utiliser des petits bouts de code écrits par CreamWare/SonicCore (un peu à la façon de ce qu'on peut faire dans Reaktor de NI) et je ne suis pas certain que ces bouts de code aient été écrits en C (je penche plutôt pour de l'assembleur et j'ignore si on manipule des flottants ou des entiers bien qu'il me semble que ce soit les deux).
On a toujours pu faire mieux en terme d'optimisation avec de l'assembleur (et de très bons développeurs) qu'avec du C compilé (même si il y a régulièrement des progrès de ce côté). L'intérêt du C, c'est que c'est en fait plus efficace en terme de temps de développement et c'est bien pour ça que ce type de langage de haut niveau est le plus utilisé. D'autant que avec des softs complexes en assembleur, on peut très vite perdre pieds. L'usage du C ou de langage de haut niveau facilite donc aussi la maintenance ...
golinbo
je suis musicien ( pas ingé-son, ni physicien ),
je suis ce thread pour essayer de me faire une opinion avant de claquer un max de brouzoufs dans une "carte-son" (?)
... merci vraiment à tout le monde ..
j'ai fait mon choix > ce sera donc Poterie et Point de croix
GO
Anonyme
Citation :Mais dès qu'on lance un débat DSP versus Natif, c'est le risque.
Oui, ce n'est pas la première fois que ce sujet est traité sur AF !
Pour moi la solution des DSP permet de soulager le ou les processeur(s) de nos bécanes.
Je me souviens quand j'avais mes cartes Creamware (2 Luna 2 et une Scope NFR), j'adorais le son qui en résultait car elles avaient de bon convertos. Le son des plugs venait de leur code source mais pas des DSP eux-même, eux, ils ne font que calculer. C'est clair qu'entre un plug pour DSP et le même en natif, si c'est le même language et les mêmes routines, il ne devrait pas avoir de différence. Je dis "devrait" parce que je ne suis pas développeur moi même.
[ Dernière édition du message le 19/04/2012 à 16:16:11 ]
HUROLURA
Bonjour,
je suis musicien ( pas ingé-son, ni physicien ),
je suis ce thread pour essayer de me faire une opinion avant de claquer un max de brouzoufs dans une "carte-son" (?)
... merci vraiment à tout le monde ..
j'ai fait mon choix > ce sera donc Poterie et Point de croix)
Pas de panique, tu peux continuer à faire de la musique !!!
Indépendamment de nos discussions savantes et stériles, le plus important à mon avis face au choix de l'Apollo, c'est:
- est-ce que j'ai besoin du "zero" latence sur les effets dans l'usage que j'envisage sur l'Apollo ?
- est-ce que les plugs me plaisent/me suffisent d'un point de vue sonore par rapport à l'usage que j'en aurais (et sinon, est-ce qu'il y a de quoi compléter et à quel prix) ?
- est-ce que les entrées/sorties correspondent à mes besoins (et sinon qu'est-ce qui est en trop, qu'est-ce qui manque) ?
- est-ce qu'il n'y a pas d'autres solutions plus adaptées à ce que je fais ou ce que je cherche à faire ? (natif avec autre carte-son, autres solutions DSP/carte son, ...)
Avec la poterie, tu risques de te salir les mains et avec le point de croix aussi ...
[ Dernière édition du message le 19/04/2012 à 16:10:32 ]
Anonyme
Je suis sûr que dans les forums dédiés au "point de croix" on doit se crêper le chignon aussi !
[ Dernière édition du message le 19/04/2012 à 16:20:00 ]
HUROLURA
miles1981
Nous sommes tout à fait d'accord, si on utilise du C normalisé pour exécuter le même code sur différentes plateforme, on obtient bien des résultats identiques (c'est un peu l'objectif).
Mais ça suppose d'avoir le même code source en C et de le compiler pour les différentes cibles.
On aura bien le même résultat, pas nécessairement la même performance (ça dépend un tout petit peu de la cible).
Mais, comme précisé auparavant, un plug fait pour la plateforme SonicCore (celle que je connais) n'est pas écris en C mais à l'aide d'un outil qui permet d'utiliser des petits bouts de code écrits par CreamWare/SonicCore (un peu à la façon de ce qu'on peut faire dans Reaktor de NI) et je ne suis pas certain que ces bouts de code aient été écrits en C (je penche plutôt pour de l'assembleur et j'ignore si on manipule des flottants ou des entiers bien qu'il me semble que ce soit les deux).
On a toujours pu faire mieux en terme d'optimisation avec de l'assembleur (et de très bons développeurs) qu'avec du C compilé (même si il y a régulièrement des progrès de ce côté). L'intérêt du C, c'est que c'est en fait plus efficace en terme de temps de développement et c'est bien pour ça que ce type de langage de haut niveau est le plus utilisé. D'autant que avec des softs complexes en assembleur, on peut très vite perdre pieds. L'usage du C ou de langage de haut niveau facilite donc aussi la maintenance ...
On est d'accord, dans ce cas l'implémentation n'est pas la même et l'algorithme lui-même est sans doute différent.
Ensuite, le coup du C moins performant que l'assembleur, c'est vrai sur de l'embarqué, c'est faux pour tout le reste. Sur x86, tu peux t'accrocher pour faire mieux que le compilateur.
Audio Toolkit: http://www.audio-tk.com/
HUROLURA
Pas sûr non plus en effet qu'il y ait beaucoup de spécialistes de talents en matière de programmation en assembleur C sur x86
L'objectif n'est généralement pas spécialement le temps réel mais plutôt la polyvalence.
charlototo
Pouvons nous revenir des des choses qui intérressent + de 3 personnes svp ?
Après les chimistes vont venir nous parler de la peinture intérieure de l'Apollo qui ralentirai les ondes positive du musicien nan ? MDR
Bon aller.. des retours sur le son, l'ergonomie, les test audio et tout ça vous dit ?
HUROLURA
[ Dernière édition du message le 20/04/2012 à 18:06:30 ]
Will Zégal
Même si ça a l'air passionnant, ce serait bien d'arrêter le HS. Merci.
Lino
jeriqo
Un peu de pragmatisme ne peut pas faire de mal face à l'ésotérisme ambiant dont est victime le monde de l'audio.
D'ailleurs, qui est capable d'entendre une différence entre un Orpheus, un Metric Halo, et un RME ?
(à l'aveugle, bien entendu)
tomoner
je pense que sur un mix complet avec un tas de pistes empilées avec des monitoring tres haut de gamme et une accoustique d'enfer on verrait une legere difference quand meme ....
je dis sa en supposant je n'ai jamais l'occasion de faire ce genre de test apres on pourra pas dire ce mix c'est fais avec l'orpheus et sa avec la RME mais je pense qu'on entendrait une legere difference
Silicon Machine Extended
super avis!
[ Dernière édition du message le 20/04/2012 à 21:52:39 ]
c_planet
on est quand même pas obligés de boire tout de go le marketing servi sur le matos pro dans les forums amateurs - je trouve ça pas mal que certains ayant des connaissances poussées tentent de remettre l'église qu'ils pensent être au milieu du village.
sinon, on est censés lire quoi pendant 22 pages ? .... qu'on ne peut pas comprendre avec nos m-audio 3 canaux à 105 euros ?
srak
raoulish
pffiou c'était long de lire tout ça...
Moi aussi je cherche une carte son avec DSP pour faire du Live, du coup j'ai vu ce nouveau truc. Par contre "Mac-only" + "hyper-cher" = pas pour moi.
J'ai vu passer dans ce thread quelques noms: rme, motu, metric halo, tc...
Je ne connais pas bien tout ça mais ça m'intéresse, c'est vrai qu'un comparatif ça serait cool.
Mais pourquoi personne ne parle de la E-MU 1616m ??
Si j'ai bien compris, elle a aussi du dsp integré, des entrées micro, instru, phono, bref tout-en-un... et surtout elle est moins chère.
A+
HUROLURA
Après il ne faut pas s'attendre à retrouver l'équivalent des plugs DSP de UAD, Metric Hallo ou SonicCore/Creamware ... la puissance embarquée "date" un peu, mais ça peu déjà rendre des services
Tant qu'à faire dans une gamme de prix "similaire" il peut également valoir le coup de lorgner sur la Motu Ultralite MK III ou la TC Electronic Impact Twin pour rester sous la barre des 500 € ...
[ Dernière édition du message le 04/06/2012 à 19:17:22 ]
vivalazik
UA vient de sortir son Oxford EQ en partenariat avec Sonnox.
C'est ptet bien le moment de comparer avec la version native non ?
:))
-jeremy-
- < Liste des sujets
- Charte


