Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Universal Audio Apollo Duo
Agrandir
Ajouter ce produit à
  • Mon ancien matos
  • Mon matos actuel
  • Mon futur matos
Universal Audio Apollo Duo
Photos
1/464
Universal Audio Apollo Duo

Interface audio Thunderbolt de la marque Universal Audio appartenant à la série Apollo

7 avis
Prix public : 2 350 € TTC
8/10
Présentation du produit Présentation
Avis 7 7
Comparateur de prix
Petites annonces
Forums 51 51
Actu 20 20
Test 1 1

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

  • 232 réponses
  • 48 participants
  • 49 643 vues
  • 51 followers
1 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 premier post
191
:lol:
En effet le marché DSP est peu rentable, exemple Apollo,uad1, uad2, tc Electronic.
Une reverb est plus a l'aise en natif, exemple la sublime Haloverb de Metric Halo ( DSP).


Merci de nous expliquer ce qui sonne mieux, et pourquoi l'industrie nous le cache!
M6 et un Capital ''processeurs attention danger".

JOURNEYMAN  ( ici en musique) (ici sur Facebook)

 

 

Studio Rouge Prod/Mix/Master

 

 

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

192
x
Hors sujet :
Citation :
Ce qui paraît incompréhensible si c'était si simple, c'est qu'on ait pas encore vu "fleurir" des solutions commerciales de ce type. Il y a eu des annonces mais concrètement je n'ai pas repéré grand chose de près à l'emploi.

un vrai cluster, c'est moyennement compliqué, les solutions existent, nombreuses, libre ou payantes, mais ça se prete pas au travail en temps reel, plutot pour du traitement de données, genre des rendus. En audio, la solution la plus simple, c'est de faire passer les canaux audio/midi par ethernet, de les traiter en face, et de les recuperer ensuite. on s'en sert pas mal par exemple pour de gros systemes a base de samples.
FXteleport s'est fait des couilles en or avec ça a l'epoque, et pour Reaper, y'a une solution integrée qui marche super bien (et qui permet de passer les chaines d'effets d'un ordi a l'autre selon les besoin). Bien sur, ça induit de la latence, donc pas utilisable temps reel, mais en mix ou en compo, c'est jouable. reste que franchemnt, si c'etait necessaire y'a 4/5 ans, aujourd'hui, avec un quad core recent, t'as de quoi garnir un bon paquet de pistes.
193
Le DSP n'est pas forcément mieux que le natif par essence. Les avantages que le DSP avait encore il y a 4/5 ans (exemple des plugs TDM cité précédemment) étaient essentiellement au niveau de l'efficacité et donc de ce qu'on était capable de faire tourner: le DSP le pouvait pas le PC. Il n'y a donc plus aucune raison (et encore une fois je n'utilise quasi que ça, mais simplement parce que ce qui tourne sur les DSP me plaît davantage, c'est tout) pour que le DSP ait conservé un avantage si on fait tourner strictement les mêmes calculs (avec les mêmes méthodes et les mêmes données). Mais certains algo ne sont disponible QUE sur certaines plateforme plutôt DSP (UAD, XITE) et ne sont pas dispo en natif.
Encore même SPL, ça a été recodé entre la version Scope Xite, la version natif et la version UAD donc il y a aussi des chances pour que ça puisse sonner différemment. Je ne pense pas qu'il existe beaucoup d'exemples qui permettent des comparaisons. Je suis certains que SonicCore ou UAD serait capable de faire tourner leur plugs aussi bien en natif qure sur leurs plateformes respectives mais peut-être que cela demanderait des adaptations qui auraient pour résultat de ne pas obtenir le gain de performance attendu sur la base de chiffre de puissance de calcul brut. En gros il faudrait émuler le DSP et quand on émule en général ça fonctionne moins vite.

MartinSanchez, pour les oscillateurs SAW de l'XITE par rapport aux synthés en natif, le truc c'est que ce n'est pas codé pareil. Un simple oscilloscope pourrait le montrer.
D'ailleurs, si tu jettes un oeil au test de Sound on Sound sur le Pro12 ASB (algo CreamWare/SonicCore):
https://www.soundonsound.com/sos/may06/articles/creamware.htm
Tu vois bien que les formes d'ondes triangles ou carré n'ont en fait pas grand chose à voir avec un "vrai" triangle ou un "vrai carré (même en analo). Il y a notamment des astuces mises en oeuvre pour limiter les risques d'aliasing dans le cas de la version DSP (lié au fait qu'on est en numérique) et pour l'analo c'est lié aux imperfection des composants électroniques qui ne parviennent pas à faire un vrai triangle mais qui du coup ont un son particulier. Du coup, on voit avec un oscilloscope les différences. Mais ce sont les oreilles qui comptent et là c'est plus subtil: il faut faire un compromis entre ressemblance et qualité sonore donc faire des compromis.
Si le VST dont tu parle fait un triangle fait bêtement une forme d'onde triangle bien droite, il va y avoir de l'aliasing et des surprises au résultat !!!
Les synthés SonicCore sont bourrés de ce type d'astuces et de ficelles (on appelle ça le savoir faire) et les derniers développement (notamment autour du Solaris) montre que leur petite équipe n'est pas à cours de nouvelles astuces innovantes de ce type.
Mais un codeur de VSTi natif talentueux peut aussi faire du très bon boulot (DIVA), la question que je me pose c'est pourquoi dans ce cas quand U-HE réfléchit à une version synthé autonome de DIVA ils pensent tout de suite DSP et pas PC embarqué ?

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

194
Les algos ne sont jamais disponibles que sur une plateforme. Un algorithme est une description de ce qu'il faut faire. L'implémentation peut varier (et donc la sonorité/le ressenti), mais pour un même code C/implémentation dans n'importe quel langage, que ce soit sur DSP lambda ou x86, ça sonnera strictement identique. Pourquoi ? Parce qu'à l'entrée de la moulinette il y a les mêmes nombres dans les deux cas et qu'en sortie il y a aussi les mêmes à des variations imperceptibles près (et si c'est compilé en mode standard, c'est strictement la même chose). Après, ça peut varier sur comment c'est enregistré ou reproduit, mais les variations sont semblables à celles qui sont entre une carte son RME et une Creative Labs.
Le reste n'est que mensonge et propagande. Et je programme des algorithmes numériques pour gagner ma vie, donc je sais ce que je raconte.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

195
On pouvait théoriquement imaginer que les implémentations sur UAD et Xite des plugs SPL/Brainworx soient les mêmes, puisque ce sont les mêmes cibles (même modèle de DSP même si ceux de l'UAD sont cadencé un poil plus haut (400 MHz) que celui de l'Xite (333 MHz).

Mais les algos qui tournent sur Xite sont la mise bout à bout de petit morceaux de code codé en assembleur (et ayant fait l'objet d'une optimisation soignée). Donc sauf à savoir ce que contiennent ces petits bouts de code, il n'est pas a priori possible de refaire exactement à l'identique même si l'algorithme et son principe sont connu des développeurs de SPL /Brainworx.

Un même code C compilé avec deux compilateurs différents (pas forcément en mode standard) ne produira pas nécessairement le même code machine. Souvent ça effectue les mêmes opérations mais pas forcément de la même façon (genre dans le même ordre ce qui peut avoir un impact sur la précision des calculs). Encore une fois sur une opération simple, c'est transparent mais sur une opération complexe avec des résolutions de calcul limitées, ça n'est pas forcément neutre et l'ordre même des opérations peut avoir son importance. Moins on a de résolution, plus c'est flagrant.
Mais c'est vrai que si on fait les calcul en 64-bits, ça peut commencer à être négligeable plus souvent et à être nettement moins sensible.
Il n'y a pas de magie dans tout ça, c'est du calcul numériques avec les résolutions finies des machines (c'est pas des math purs, ça c'est plutôt le domaine de l'analogique qui lui par contre est sujet à des non linéarité, des distorsions, des effets de la températures ... qui rende tout ça vivant).
Simplement la façon dont on implémente tout ça. Le fait de l'implanter en langage machine/assembleur permet de maîtriser davantage ce type de phénomène même si c'est plus long et donc coûteux à faire (souvenez-vous de ce qu'on obtenait comme animations (programmées en assembleur) sur des Amiga à une certaine époque par rapport à ce que l'on faisait faire à des PC souvent plus puissants).

Mais effectivement, si on prenait le même code C compilé sur un PC en natif ou compilé puis intégré sur UAD ou Xite, il y a de fortes chances pour qu'au obtienne quelque chose de très semblable si ce n'est quelque chose d'identique (je pense que c'est le cas pour l'exemple natif TDM évoqué dans un post précédent).

[ Dernière édition du message le 18/04/2012 à 23:36:29 ]

196
Les processeurs sont capables de calculer sur des valeurs bien plus grandes que celles utilisées par l'audio. Il n'y a jamais d'approximation. Il y a juste des arrondis.
Lorsqu'un arrondi est fait pour être contenu dans les mots audio (24 bits par exemple), c'est de toute façon le développeur qui choisit si l'arrondi se fait au supérieur ou à l'inférieur.
Il n'y a jamais d'aléatoire, c'est complètement fantasmagorique.

Petit rappel : ce ne sont que des additions, multiplications, divisions, soustractions.

Pour l'anecdote, l'aléatoire est justement une des choses les plus difficiles à obtenir en algorithme.
Il est très difficile par exemple de générer aléatoirement un nombre entre 1 et 100, sans qu'un chiffre soit privilégié par rapport à un autre.

On le voit bien sur ces images :

https://boallen.com/random-numbers.html

Le premier algorithme génère à priori un résultat bien aléatoire alors que le second non, le résultat est davantage prévisible.

[ Dernière édition du message le 18/04/2012 à 23:44:57 ]

197
Un arrondi, c'est une approximation.

Une fois le choix de mode d'arrondi effectué, il n'y a effectivement plus d'aléatoire (sauf dans le signal d'entrée qui est lui a priori aléatoire bien entendu) mais si on injecte le même signal d'entrée à plusieurs reprise, on obtient bien le même résultat en sortie de calcul.

Pour arrondir, on peut effectivement se fixer comme règle un arrondi à la valeur supérieure, un arrondi à la valeur inférieure, mais aussi un arrondi à la valeur la plus proche (ce qui demande dans ce un cas un test) ou des choses plus élaborées (genre ne pas effectuer les mêmes calculs en fonction des plages relatives des valeurs en entrées pour optimiser la résolution).

On peut arrondir le résultat d'un calcul sur 24 bits à chaque étape ou ne le faire qu'en sortie d'un ensemble de calculs au moment où il est nécessaire de revenir en 24 bits. Typiquement on rentre un signal sur 24 bits, on fait les calculs avec toute la résolution disponible (32 ou 64 bits) et on ne fait ces fameux arrondis qu'au dernier moment par exemple au moment de transmettre le résultat pour l'envoyer sur une sortie. La deuxième solution paraît la plus logique (pour ne dégrader la précision qu'un dernier moment) et c'est sans doute celle qui est mise en oeuvre la plupart du temps.
198
Oui, je voulais parler d'approximation aléatoire, ou "choisie" par le processeur. (?)

Lorsqu'on compresse un fichier zip et qu'on le décompresse, ce sont des algorithme très complexes, et qu'on utilise un Core i7, un 386, un PowerPC, un DSP ou même un boulier, on retrouve toujours le même fichier à la fin. (ouf !)
199
x
Hors sujet :
Citation :
Lorsqu'on compresse un fichier zip et qu'on le décompresse, ce sont des algorithme très complexes, et qu'on utilise un Core i7, un 386, un PowerPC, un DSP ou même un boulier, on retrouve toujours le même fichier à la fin. (ouf !)


Tu as oublié les cartes perforées :-D

[ Dernière édition du message le 19/04/2012 à 07:27:44 ]

200
Sauf qu'en compression, tu peux mettre en oeuvre deux approches:
- l'une qui permet de faire maigrir le fichier sans dégradation (en ne faisant que des calculs qui tombent juste et qui donc n'implique pas d'approximation): un fichier zip
- l'autre qui permet de faire maigrir le fichier sans dégradation notable (en ne faisant que des approximation raisonnable qui ne dégrade pas trop les fichiers): un fichier mp3