[Test] Plug-ins à la carte

creamware ok mais Sonic Core a pris le relai et leurs cartes sont top (XITE1 et XITE1D) contiennent déjà de très bon plugs et vont surement développer d'autres plugs.

SSL les cartes Duende sont encore utilisables et les plugs sont portés en natifs mais restent de très bons plugs.

juste pour préciser.

UAD est en première place on est d'accord mais tous n'ont pas encore dit leur derniers mots.

Citation : baborum

UAD est en première place

. c'est oublier que "natif" signifie "Intel". Dans la course aux Megaflops, il n'y a malheureusement plus de place pour d'autres constructeurs. Intel a tout bouffé et depuis longtemps.

Dans les éditeurs, et pas les moindres, qui ont basculé chez Intel (et retourné leur chemise), j'avais oublié Avid/digidesign et Merging dont les softs Protools et Pyramix (et tous les plugs qui vont avec) sont désormais natifs..

Citation :

 

La vitesse des transfert ne dépend pas (directement) du CPU, et surtout pas de la carte DSP. L'élément le plus important est la carte mère de l'ordinateur. Si vous avez une carte mère au rabais avec un chipset moisi la latence grimpera assez vite.

Donc si vous optez pour la solution carte DSP qui déporte une partie des calculs du CPU vers une carte de traitement dédiée, assurez-vous d'avoir une carte mère qui tient la route, et ça vaut pour tous les constructeurs de cartes DSP et aussi bien pour les PC que les MAC (l'utilisation d'une carte externe branchée par FireWire n'arrangera bien sûr pas l'affaire).

 

 Très intéressant, mais alors, quand on achète la carte mère quelles sont les caractéristiques à scruter en premier lieu pour avoir LA carte mère qui tient la route pour du déport DSP???

Wahooo je ne pensais pas déclencher une suite de messages vu que le topic semblait dater.

Est-ce qu'UAD pourrait faire tourner leurs plugins sur un CPU ?

La réponse est oui mais seulement s'ils décident d'en faire une implémentation. Techniquement parlant il n'y a pas vraiment de problème (c'est grosso-modo la même problématique que le portage d'un plugin de MAC vers PC, ou l'inverse).

Par exemple, Massey indique dans ses faq que le portage des plugins au format VST est envisageable (et envisagé sans donner de date) mais que pour l'instant il préfère se consacrer au support des plugin RTAS déjà existant.

Pour ce qui est du choix de la meilleure carte mère, il faut se palucher les tests de matériels informatiques ... Il faut que la fréquence de la carte mère soit élevée (pas seulement celle du CPU) et que les tests montrent que le chipset est de qualité. On pourra cibler des fabricants de cartes mères qui ont une bonne réputation, comme ASUS ou MSI.

Les cartes de calcul déportées externes sont à éviter : entre un bus FireWire ou un bus PCI-E, il n'y a pas photo. Perso ça me semble même être une hérésie (techniquement parlant).

Pour ce qui est de découper les transferts en plus petits paquets, pas sûr que ce soit la meilleure façon de réduire les temps de latences. S'il y a plus de paquet à envoyer, on se prend le coût d'accès au bus de données à chaque fois et les perfo s'effondrent (les données passent plus de temps à attendre la disponibilité du bus qu'à transiter).

Je ne suis pas au cœur de la bête, mais il me semblerait surprenant de voir la consommation du CPU grimper en flèche parce que l'on multiplie le nombre des requêtes d'accès au bus de données. Il me semble que la raison la plus plausible est qu'une partie des calculs n'est pas réalisée en déporté sur les DSP mais sur le CPU.

Mais bien sûr je ne suis pas dedans... C'est de la pure spéculation et je me plante peut-être complètement (avec un peu d'expérience professionnelle dans le domaine toutefois).

Mais c'est vrai que la latence est un faux problème. Ce que je voulais souligner est que quelque soit le fabriquant de carte ou le type de processeur/DSP utilisé, le problème de latence sera toujours présent et que ceci vient de l'architecture même de nos ordis (on ne peut pas blâmer UAD pour ça).

Si le but est de faire de la synthèse live sur un équipement portable avec une latence faible (indispensable), l'intérêt des cartes DSP est plus que limité (de toute façon, le proc sera chargé).

L'intérêt du calcul déporté c'est pour de la prod (mixage/mastering) en studio où on se fout "complètement" de la latence et où l'on veut avoir des plugin de bonne qualité et des traitements efficaces.

En aparté, il y a un truc intéressant qui est en train de mûrir gentiment c'est le calcul déporté sur carte graphique (le GPGPU pour General Purpose GPU). C'est le même principe que le calcul déporté sur cartes DSP (avec les mêmes contraintes sur la latence).

La carte graphique, avec une puissance de calcul brute bien supérieure au CPU (et aux DSP utilisés dans les cartes d'UAD), devient la cible techno pour le développement de plugin. Nvidia, par exemple, ouvre de plus en plus ses architectures et propose un langage (CUDA) pour coder sur leurs cartes.

Le GPU est la cible de choix pour les traitements massivement parallélisables (genre plusieurs instances de plugins...), et il se trouve que les opérations usuelles en traitement du signal sont aussi ceux que l'on utilise pour faire de la 3D (autrement dit, les jeux d'instructions des GPU collent très bien avec les besoins pour faire du son). Ca ouvre même une capacité de calcul assez monstrueuse.

Techniquement ça tient plus que la route mais commercialement c'est moins sûr (le concepteur de plugin retombe sur le problème de la piraterie). Mais quand on voit qu'une carte graphique est plus performante que la meilleure carte proposée par UA pour un coût 10 fois moindre... ça laisse rêveur (ça me fait penser à l'histoire du Lemur de JazzMutant et de l'iPAD de Mac).

Enfin tout ça pour dire à SampleHunter que l'horizon est peut être plus proche que les 4-5 ans :'-)

C'est qui se passe (découpage en plus petits paquets plus fréquents) quand on baisse la latence. D'où les accès à calculer plusfréquent, la gestion des échanges nombreux pour de petits paquets de données et le coup en CPU.

Baisser la latence pompe sur le CPU, avec une carte DSP et/ou une carte audio.

Pour le GPU c'est rigolo parce que la carte UAD-1 est un GPU détourné en fait (une puce video).

Et pour UAD cela n'allait nulle part et ils sont revenus vers les DSP traditionnels de type sharc.

Oui je sais bien que réduire la taille des paquets augmente mécaniquement le nombre interruptions à gérer et donc l'occupation du CPU. Mais j'ai du mal à croire que la gestion de ces interruptions puisse suffire à faire monter cette occupation à 55% du temps CPU comme le montre le test d'audiofanzine.

Pour en avoir le cœur net il faudrait avoir le taux d'occupation du bus de données.

Le proc de l'UAD-1 est un MPACT-2 et ce n'est pas un GPU mais un "media processor", un SOC (System On a Chip).

Ça ne m'étonne pas qu'ils aient laissé tomber ce type d'archi car il s'agit en fait un microprocesseur peu puissant avec à côté des fonctions "précâblées" développées en VHDL et intégrées en dur à côté du cœur du µproc qui ne peuvent pas être modifiées.

Le µproc n'est capable de gérer qu'un seul thread à la fois (ce n'est pas un multi-proc) et il a des capacités de calcul relativement limitées (même s'il permet de faire du vector processing).

L'intérêt d'un SOC ce sont les fonctions "précâblées" qui permettent de décoder un flux en temps réel sans charger le µproc (si le CODEC fait bien parti des fonctions précâblées !). Toutes ces fonctionnalités qui font l'intérêt d'un SOC ne servent à rien pour un plugin...

Mmm n'oublions que le calcul vectoriel est vraiment intéressant en audio. C'était le cas de l'altivec sur les G4 dans le temps qui avait permis de prendre une grosse longueur d'avance sur ce que proposait intel et AMD en audio, pour peu que l'unité soit exploitée par le code.

Bon ceci dit je suis d'accord cette histoire de 55% est super bizarre.

J'ai 2 UAD-2 duo et 2 UAD-1 dans ma machine, chaque type de carte fonctionne avec des delais de latence différents (à gérer donc pas le CPU), et sans plug natif mais à fond de plug UAD j'arrive à quoi ? à peine 10%...

Mon mon PC est un PC audio monté pour, qui ne fait que ça, avec un bios adapté mais quand même....

euh juste par curiosité, c'est quoi un bios "adapté" pour l'audio...?

avec 4 cartes UAD dans la machine, t'as jamais eu de problèmes ce conflits d'IRQ avec d'autes éléments?

OK, ça mérite des explications....

1) je viens du Mac, et je n'ai que des mac à la maison, sauf le PC du studio.

2) En juillet 2009 j'ai décidé d'acheter une nouvelle machine pour remplacer mon G4 de 99, qui bien que boosté par ses cartes UAD et creamware, s'enfonçait dans un puis d'obsolescence (encore sous OS9 par exemple avec VST5).

3) Je voulais garder mes cartes UAD, donc ports PCI, et rester en phase avec les nouveaux standards. Et ne pas avoir 3 malheureux ports PCIe. DOnc adios le Mac.

4) Hors de question de rentrer les merdes classique de PCiste.Je viens du mac je veux pareil: on branche et ça marche, BASTA. Je ne fais pas de l'informatique, mais de la musique.

5) lecteurs de Sound on Sound, j'ai contacté les gens de Carillon et de Direct Resolutions. Mon PC est i7 avec 3 DD, de la mémoire triple channel. Avec une carte UAD-2 duo preinstallée et cubase installé (j'avais déjà ma licence, juste à insérer mon dongle à l'arrivée). La mchien est monotache (pas d'ethernet, pas internet, pas de carte son interne, ou plus exactement, tout désactivé au plus bas niveau). Le tout en rack 19' insonorisé totalement. avec firewire et un chip texas instrument, etc.

IRQ ? Connais même pas...

6) au final pour une fraction du prix d'un mac et pas tellement plus cher qu'un bon PC ici (2000 euros, carte UAD-2 duo comprise et frais de ports inclus)

J'avais juste sous estimé le temps nécessaire pour se faire à XP (en 2009 seven n'était pas une possibilité, et Entre XP et Vista, y'avait pas photo), ça a été dur, c'est tellement pas ergonomique. Il faut 5 fois plus de clic et de mouvements de souris pour fair epareil que sous OSX et ça manque terriblement de raccourcis claviers. .

Aujourd'hui, je suis content ça tourne, et je referais le même choix comme on dit dans les bancs d'essai audiofanzine !

Citation de : Yu-man

euh juste par curiosité, c'est quoi un bios "adapté" pour l'audio...?

avec 4 cartes UAD dans la machine, t'as jamais eu de problèmes ce conflits d'IRQ avec d'autes éléments?

 

Le BIOS dépend de la carte mère. Je pense que l'idée c'est plutôt un BIOS "paramétré" pour de l'audio :

• En gros tu désactives toutes les fonctionnalités que ne servent à rien et qui peuvent nuire aux performances.
• Par exemple, tu désactives l'Ethernet (pas d'internet sur ta station de travail), la carte son intégrée, etc.
• Tu peux aussi désactiver la gestion "intelligente" de la consommation ; a priori si tu allumes l'ordi c'est pour faire de la prod et il va être sollicité en permanence.
• Tu peux tenter d'overclocker la RAM (attention de ne pas obtenir une machine instable).

Si tu coupes certains périphériques internes tu libères des IRQ, au total tu as 4 cartes + 1 carte vidéo... Si la carte mère n'est pas un vieux machin elle devrait gérer ça toute seule comme une grande. Et puis, normalement il y a au moins autant d'IRQ disponibles qu'il y a de slots sur ta carte mère.

@malhomme

Si tu en as l'occasion (et les moyens) je te conseille de regarder Windows 7, c'est Vista en fini . L'ergonomie est meilleure que celle d'XP mais surtout la gestion de la RAM est vraiment améliorée.

Tu as raison, j'y pense. Je pense à l'acheter dans un futur proche.

Xp bien que stable, me pose le problème évident de la limitation à 3 go et qq de mémoire gérée, un truc auquel Mac OS ne m'avait pas habitué.

Et 3 Go c'est un vrai souci avec mes banque de sons: j'ai acheté Halion Symphonic Orchestra et plusieurs banques de sons de chez SonicCouture (qui font jusque 2 Go). Et il me faudrait passer disons de 3X1 go à 3X3 Go...

J'ai prévu une partition pour, reste à rentrer dans

1) l'achat de Seven

2) découvrir l'OS qui doit êtr etrès différent de XP

3) reinstaller tout, acheter un VST bridge, commencer à galérer côté drivers, plug in pas portés etc.

--> Bref des jours de merde à bricoler et pas faire de la musique.

Du coup, je retarde....

J'ai une petite question pour les utilisateurs de carte UAD.

Le temps de latence apparaît à cause des transferts entre la carte mère et la carte DSP.

Si j'enchaîne des effets destinés à la carte DSP, les données de la carte mère vont être envoyées à la carte DSP qui applique chacun des effets les uns à la suite des autres, et le signal traité repart vers la carte mère pour être géré par le logiciel hôte.

Mais si je fais un sandwich (club huhu) d'effets "UAD", "natif", "UAD", "natif", etc. les échanges de données vont avoir lieu entre chaque tranche de  mon sandwich, multipliant ainsi les retards. Est-ce ce qui est observé par les utilisateurs ?

Ok pour dire que la pile d'effets n'est pas une pratique à défendre, mais je me pose la question pour un routage à travers des sends et des bus (gérés par le logiciel hôte, et donc côté carte mère).

Si j'ai un effet VSTi natif qui me produit un son traité par un plugin UAD (1 aller-retour carte mère / DSP), puis que j'envoie le résultat par un send pour appliqué un autre effet UAD (1 aller-retour carte mère / DSP), pour finalement mixer le tout vers un bus avec un dernier traitement de l'UAD (1 aller-retour carte mère / DSP) (ce qui me semble être loin d'un routage délirant).

Je vais au final voir la latence multipliée par 3 ?

(le test d'Audiofanzine ne dit pas si les effets sont enchaînés les uns à la suite des autres ou si le signal passe par un bus du logiciel hôte à chaque fois).

Bonne question, à laquelle je ne peux pas te répondre MAIS en réalité ce que tu décris est une situation de mixage standard...

Et comme dans ce cas, la latence on s'en fiche... (que le sons démarre 1/10 de seconde ou 3/10eme de secondes après que tu aies appuyé sur play n'a pas d'ilmportance...).

Du coup, même si la question est bonne, elle est de peu d'intérêt pratique....

Citation :

Si j'enchaîne des effets destinés à la carte DSP, les données de la carte mère vont être envoyées à la carte DSP qui applique chacun des effets les uns à la suite des autres, et le signal traité repart vers la carte mère pour être géré par le logiciel hôte.

je sais que c'est ce qui se passe dans un Pro Tools HD antre les plugs TDM et RTAS (je me rappelle que pour économiser des voix, le formateur nous disait de faire attentoin à mettre tant que faire se peut tous les plugs TDM en premier à suivre, puis ensuite les plugs RTAS...mais là c'est PT HD, un Soft qui est fait pour fonctionner avec les cartes CORE et ACCEL....

Maintenant je suis pas du tout sûr que ça se passe de même avec les cartes UAD vu que c'est fait pour fonctionner avec (presque) n'importe quel DAW....je suis pas sûr que ton DAW se rende compte que parce que y'a 3 plugs UAD à suivre sur une piste, il lui faille envoyer les DATA au point d'envoi du 1er plug et les rapatrier au point de retour du 3ème plug...je n'ai aucune preuve de ce que j'avance, mais c'est plutot un pressentiment: j'ai bien peur que même si tes 3 plugs UAD sont à suivre, ben le data fait 3 fois l'aller-retour...mais à vérifier...

...mais comme le dit Malhomme, on s'en fiche un peu quand on mixe, la latence n'est vraiment pas dérangeante...

dans le cas du PT HD, je suis pas du tout un pro du système, mais il me semble que le problème de l'ordre des plugs entre TDM (DSP) et RTAS (natif) est important à sureviller, car dans PT, le nombre de "voices" est limité, et de la même manière qu'une piste prend une "voice", l'envoi dans le bus TDM pour traiter par un plug TDM prend aussi une "voice"....donc par souci d'économie des voices sur de gros projets, on essaie de faire gaffe à ne pas les gaspiller à cause d'un mauvais agencement des plugs RTAS et TDM....avec la plupart des autres DAW, le nombre de voix est annoncé comme illimité, mais dépend en fait de la puissance du système...enfin je crois...

Pour répondre à Yu-Man, le DAW ne se "rend compte de rien" car c'est le plugin UAD qui se charge de faire les synchro de transfert.

Le DAW voit juste un plugin qui consomme très peu de ressource CPU, mais qui à un gros temps de latence.

Je sais très bien qu'en mixage/mastering on se moque de la latence, mais pour du live c'est rédhibitoire.

Si je pose la question c'est parce qu'UAD essaie d'étendre ses produits aux applications live et de sortir des studios de prod (d'où les dernières évolutions logiciels LiveTrack™ Low-latency live monitoring/tracking mode).

Déjà qu'il semblerait que la LiveTrack pose de nombreux soucis de stabilité des configurations, je me demande si en plus il est réellement efficace si l'on tente de déployer un routage pour du pré-mixage live (et la latence devient un vrai problème).

Tiens puisqu'on est sur le forum de l'UAD2 (que je possède en duo)

Citation de EraTom :

Le proc de l'UAD-1 est un MPACT-2 et ce n'est pas un GPU mais un "media processor", un SOC (System On a Chip).

Le proc de l'UAD2 n'est plus le même j'imagine, ce qui lui permet d'avoir cette puissance supérieure?

Hors sujet :

Bon j'essaie de vous suivre hein mais j'avoue que c'est un peu beaucoup technique pour mon piti niveau mais malgré c'est très intéressant. Je reste toujours scotché par le niveau de connaissance de certains AFien et des échanges qu'il peut se produire entre eux. Passionnant.

Honnêtement, je trouve que le choix du MPACT-2 était très bizarre :

• La plupart des fonction précâblées étaient inutiles (elles concernaient la décodage de vidéo MPEG2)
• Le cœur DSP à 125MHz associé aux fonctions précâblées était très moyen par rapport aux autres DSP plus "classiques".

En fait, un DSP est déjà un processeur spécialisé pour le traitement du signal (et donc audio), le MPACT-2 répond à un besoin très spécifique qui ne correspond pas vraiment à celui d'UA (enfin, d'après ce que j'en connais...).

C'est sans doute pour ça qu'ils ont fait un choix radicalement différent pour l'UAD-2 : un DSP SHARC 3ème génération en 32bits virgule flottante à 400MHz.

http://www.analog.com/en/embedded-processing-dsp/sharc/ADSP-21369/products/product.html

Il n'y a pas les "fonctions précâblées" d'un SoC mais des interfaces d'entrées / sorties dédiée à l'audio.

M'enfin, je me demande bien quel est l'intérêt de l'interface S/PDIF, des 16 PWM, etc. Si c'était pour faire une carte d'acquisition, ok, mais là le but est uniquement de disposer d'une grosse puissance de calcul pour soulager le processeur ; tous les échanges de données passent par le bus PCIe exclusivement...

En fait je ne comprends pas pourquoi ils ne choisissent pas des archi de ce genre :

https://focus.ti.com/docs/prod/folders/print/tms320c6672.html#samples

Ok il est 2 fois plus cher, mais on passe de 2.4 GFLOPS pour le SHARC à 40 GFLOPS pour le TI (un rapport d'un peu plus de 16, quand-même...).

Au lieu de mettre 4 SHARC, on met 1 DSP TI et ça reste 4 fois plus puissant (bon, ce n'est pas tout à fait vrai, mais pas loin)...

Hors sujet :

Ben perso je suis ingénieur en électronique avec une spécialisation en traitement du signal. Vivi, un bon gros nerd.

J'ai toujours pensé que le MPACT avait été une sorte d'effet d'opportunité: des gens qui le connaissaient, un gros stock acheté à pas cher...

Ceci dit, le  prix d'un sharc comme ceux des UAD-2 fait rire... Pour le commun des morteln qui n'achète pas en gros, on est à combien ? quelques  dollars à tout casser...quand on voit la différence de prix entre une UAD-2 solo et Quad...

Le spdif ça peut servir plus tard. Pense aux DSP de chez (ex) Creamware...

Hors sujet :

Citation de Malhomme :

Ceci dit, le  prix d'un sharc comme ceux des UAD-2 fait rire... Pour le commun des morteln qui n'achète pas en gros, on est à combien ? quelques  dollars à tout casser...quand on voit la différence de prix entre une UAD-2 solo et Quad...

Ha ben ça fait plaisir à lire...

Hors sujet :

Et oui...mais que veux-tu? c'est du biz avant tout hein...et puis c'est pour tout pareil: quand on voit à combien ça revient en pièces de se fabriquer un module hardware haut de gamme type 1176 et consorts...c'est l'jeu ma pauv' Lucette... ...perso, j'ai ni le temps, ni les connaissances, ni le savoir faire, ni l'envie tout simplement de me coltiner du DIY, et alors en ce qui concerne des cartes DSP, c'est même pas la peine d'y penser, c'est pire que de la science fiction pour moi...

Citation de : malhomme

J'ai toujours pensé que le MPACT avait été une sorte d'effet d'opportunité: des gens qui le connaissaient, un gros stock acheté à pas cher...

Ceci dit, le  prix d'un sharc comme ceux des UAD-2 fait rire... Pour le commun des morteln qui n'achète pas en gros, on est à combien ? quelques  dollars à tout casser...quand on voit la différence de prix entre une UAD-2 solo et Quad...

Le spdif ça peut servir plus tard. Pense aux DSP de chez (ex) Creamware...

Oui je vois tout à fait ce que tu veux dire avec l'effet d'opportunité, m'enfin les SHARC 2nde génération étaient déjà là et bien plus intéressants pour faire de l'audio.

En plus, pour avoir travaillé avec des MPACT, le compilo est une grosse bouze. Ils ont été obligé dans créer un vraiment spécifique pour la gestion des fonctions précâblées et tu te retrouvais avec une véritable usine à gaz au niveau de la gestion de conf (vi parce qu'en plus il y avait des versions différentes de ces fonctions, et donc de compilo).

Comme en plus il y avait assez peu d'utilisateurs, les bugs du compilateur étaient loin d'être tous réglés ; l'enfer.

Concernant le S/PDIF, voui peut-être avec une application UA en stand alone, mais dans un DAW... Enfin, là je n'en sais pas assez. Est-ce qu'il y a des hosts qui gèrent des flux S/PDIF entre les plugin VST ?

Le S/PDIF pour des I/O externes, pourquoi pas ça semble même assez évident, mais en interne dans un PC ?

Les proc SHARC sont autour de 50$ unité, le DSP TI que je montrais est à 99$ unité (par paquets de 1000). Je crois qu'UA peut se permettre d'acheter par paquets de 1000

Il ne faut pas non plus oublier le hardware qu'il faut mettre autour. Le SHARC ne gère par directement le PCIe, donc il faut ajouter un micro-contrôleur qui fera l'interface.

Le DSP de TI gère directement le PCIe... avec un gain en latence qui ne serait sans doute pas négligeable.

Ça me semble moins tordu de choisir un proc qui gère le PCIe et de lui adjoindre un µcontrôleur pour le S/PDIF (qui coûte que dalle) que faire l'inverse.

Non franchement, le seul point embêtant pour le TI, c'est le routage et la fabrication d'une carte qui doit fonctionner à 1.2GHz (au lieu de 400MHz pour le SHARC). Tu vas trouver moins de fabricants et ils seront sans doute plus chers, même si ces fréquences se sont démocratisées.

Sans rien enlever à la qualité des plugin d'UA (qui ne dépendent pas vraiment de la cible hardware), personnellement je trouve les choix matériels assez bizarres.

Bon allez, j'arrête de faire l'inspecteur des travaux finis, je ne travaille pas chez UA et je ne connais pas leurs contraintes (et donc je raconte sans doute de la merde).

Hors sujet :

 Intéressant quand même tout ça...

Nan mais tes remarques sont pertinentes...

Mais oui, à controleur égal, la différence entre une UAD-2 solo et une UAD-2 quad c'est 100-150 dollar de sharc (les controleur carte sont les mêmes, la carte est la même).

Pour une différence prix final de OUCH !

Je ne doute pas non plsu de l'effet marketing:

Les sharc actuels des UAD fournissent un différentiel de puissance de 2,5 selon UA.

OK.  x2,5 en tant d'années, c'est juste nul.

Ma première UAD-1 date de 2004-2005 je crois. en 5 ans, x 2,5 ?

Bof. Donc il doit y avoir un truc genre "pas trop vite, gardons de la puissance sous le pied".

Je pense que l'on se garde des truc comme ceux que tu cites pour une UAD-3 et je vois le message marketing d'ici "Et si vous n'étiez plus limité en puissance de calcul : voici l'UAD-3 !"

Citation de : malhomme

je vois le message marketing d'ici "Et si vous n'étiez plus limité en puissance de calcul : voici l'UAD-3 !"

Pour la maudite somme de 3500 € 

Citation :

Pour la maudite somme de 3500 €

   elle est belle celle la