Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Commentaires sur le test : C'est un petit pas pour l'homme-studio...

  • 232 réponses
  • 48 participants
  • 51 228 vues
  • 51 followers
Sujet de la discussion Commentaires sur le test : C'est un petit pas pour l'homme-studio...
Universal Audio est une marque pas comme les autres dans le monde de l'audio. Parce que présente depuis 50 ans sur le marché du hardware avec ses préamplis, compresseurs et channel strips, et depuis une dizaine d'années sur le marché du plug-in avec sa fameuse plateforme à DSP UAD, on s'est toujours demandé ce qu'elle pouvait faire à la croisée des chemins, alliant numérique et analogique. L'Apollo, présentée lors du NAMM 2012, est un début de réponse. Focus sur la première interface audio d'Universal Audio !

Lire l'article
 


Ce thread a été créé automatiquement suite à la publication d'un article. N'hésitez pas à poster vos commentaires ici !
Afficher le sujet de la discussion
201
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).
202
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




203

Hors sujet :

 Le balises HS évitent l'envoi de mail aux inscrits.

 

204
Citation de Solid :
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 ... :D:

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 ]

205

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. noidea.gif

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.

206
Citation de miles1981 :
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 ...
207
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 :))

GO

208
x
Hors sujet :
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 ]

209
Citation de golinbo :
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 ... :-D

[ Dernière édition du message le 19/04/2012 à 16:10:32 ]

210
x
Hors sujet :
Je suis sûr que dans les forums dédiés au "point de croix" on doit se crêper le chignon aussi !icon_facepalm.gif:-D

[ Dernière édition du message le 19/04/2012 à 16:20:00 ]

211
+1 :-D
212
Citation de HUROLURA :
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.
213
Le C n'est pas nécessairement moins performant que l'assembleur, il y a juste moyen d'optimiser et de profiter des spécialités propres aux DSP dans le cas des DSP. Le DSP, c'est de l'embarqué. Il ne faut simplement pas faire des comparaisons uniquement en regardant les cadences de fonctionnement et le nombre de coeurs. Le truc, c'est que ça donne une première idée mais l'écart est sans doute moins flagrant que les chiffres bruts ne le laisse supposer.

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 icon_facepalm.gif.
L'objectif n'est généralement pas spécialement le temps réel mais plutôt la polyvalence.
214
Bon, c'est quoi ce thread d'informaticiens mathématiciens je ne sais quoi... ???

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 ?

:)
:lol::lol::lol::lol::lol:
215
Oui. :D:

[ Dernière édition du message le 20/04/2012 à 18:06:30 ]

216
Message de modération :
Même si ça a l'air passionnant, ce serait bien d'arrêter le HS. Merci. :bravo:
217
Bonsoir des tests face à l'orpheus ???
218
Je ne vois pas en quoi c'est hors sujet.
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)
219

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 

220
x
Hors sujet :
super avis!:bravo:

[ Dernière édition du message le 20/04/2012 à 21:52:39 ]

221
x
Hors sujet :
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 ?
222
223
Bonjour,
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+
224
Pas sur que tu ne sois pas rapidement à l'étroit dans les DSP de l'E-MU 1616m mais ça peut être déjà une excellente solution simple et polyvalente.
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 ]

225

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-