réactions à la news Microsoft plancherait-il sur un logiciel de MAO ?
- 73 réponses
- 33 participants
- 7 467 vues
- 35 followers

Banshee in Avalon

Lire la news
Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !

Anonyme

au lieu qu'une plateforme tiers se développe, splice, blend ou autre...
je pense pas que ca va (pas) casser la baraque ou changer la facon de faire de la musique, parceque il y'a ceux qui se detourne de plus en plus du pc, peut etre que les tablettes prennent de plus en plus de place et qu'on se retrouvera dans un marché fait de module et d'une tablette pour gerer le tout
Faut pas oublier que les laptop et encore plus les tours se vendent de moins en moins...
Ou alors, ce sera juste un soft d'appoint pour les surface pro qui deviennent de plus en plus des tablettes avec du calcul deporté dans le cloud
Dans oui, surement un garage band basique mais sympa, le seul interet ce sera peut etre d'optimiser windows et le hardware par consequent pour la gestion du son
[ Dernière édition du message le 27/09/2017 à 17:08:39 ]

sched



Mus'images


Reno-Theplankton

Ayant eu les deux pendant très longtemps je peut dire qu’un Mac quand il ne marche il ne marche pas mais un PC qui marche je n’en ai jamais croisé.

J’ai trop souvent vu des « bugs » et incohérences d’un niveau stratosphérique.
re


miles1981

Si microsoft met plusieurs dizaines de développeurs sur un logiciel (même un qu'ils ont achetés, exemple minecraft) c'est surtout pour 'privatiser' le code.
Microsoft des annees 90 n'est pas le Microsoft actual...
Contrairement a Apple qui a la tendance inverse.
Audio Toolkit: http://www.audio-tk.com/

impératricesissi

Et pourquoi?
Ce n'est qu'une supposition. Rien ne dit qu'il n'y aurait pas un autre "monopole". Et sinon, les histoires de bugs/incompatibilités avec les PC, franchement, c'est de l'histoire ancienne. Faut cesser avec cet argument. Depuis W7, tout beigne!
Oui ça aurait pu être pire mais après c'est un peu la philosophie de candide "Tout va pour le mieux dans le meilleur des mondes". Je n'ai pas encore atteint ce niveau de sagesse mais j'y pense

Après c'est vrais que les bugs il y en a moins mais il y en a toujours et c'est vrais que w7 était un de leur meilleur système (avec xp) mais w8 quelle catastrophe. Enfin pour moi c'est tout le contraire de ce qu'il fallait faire. Un fantasme de concepteurs détachés de la réalité...
Tout comme le winphone ou surface. Il ont des visions qui sont quand même très éloigné de la réalité (tout n'est pas mauvais mais quand on a leur force de frappe c'est quand même un peut navrant comme résultat).
Enfin attendons de voir si il sortent quelque chose. Car pour l'instant rien n'est sur.
Musikmesser 2013. PS je ne suis pas Romy je suis juste un Fan (du genre masculin).

Darkmoon


"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou

Pretextat


rahow

Ça peut être rentable pour de gros plugins qui bouffent beaucoup de ressources, comme un gros synthé ou une grosse réverb
Ouioui, de la grosse modélisation/convolution ! Si c'est juste pour un EQ, osef ^^
Mais là encore, il y a un hic : à faible latence, avec de petits buffers, tu vas encore passer un temps monstre en I/O vers le GPU ;
En quoi c'est différent d'avec une carte genre Protool HD ou UA ??
Meconnaissance totale de l'architecture des GPU...
Un peu quand même, si ^^ Pas au point d'aller moi-même coder des CUDA core il est vrai...
... et des algos audio
Oui là c'est vrai... mais si ces fameux algos audio tournent plus vite sur des machines munis de DSP, c'est qu'il doit surement y avoir masse d’opérations de bases ( + - * / ) qu'un processeur standard met trop de cycle à exécuter ^^

alex.d.

Citation de alex.d. :
Mais là encore, il y a un hic : à faible latence, avec de petits buffers, tu vas encore passer un temps monstre en I/O vers le GPU ;
En quoi c'est différent d'avec une carte genre Protool HD ou UA ??
Je ne sais pas comment sont faites les cartes Protools HD ou UA, mais un GPU est prévu pour transférer les textures (gros volume, osef de la latence) puis travailler sur son set de données locales. Alors que l'utiliser pour de l'audio temps réel, c'est passer son temps à lui envoyer plein de tout petits morceaux. Pas le même job.
Un peu quand même, si ^^ Pas au point d'aller moi-même coder des CUDA core il est vrai...
Ce que tu codes, c'est un kernel

Les cores, c'est ce qui exécute.
Oui là c'est vrai... mais si ces fameux algos audio tournent plus vite sur des machines munis de DSP, c'est qu'il doit surement y avoir masse d’opérations de bases ( + - * / ) qu'un processeur standard met trop de cycle à exécuter ^^
Un GPU n'est pas un DSP généraliste. C'est un processeur vectoriel prévu pour travailler sur de très gros vecteurs (avec des centaines d'éléments). C'est là qu'il obtient sa performance crête. Si tu le fais travailler sur un algo non-vectorisable, ou sur un algo vectorisable mais avec des blocs de 32, c'est plutôt tout pourri comme DSP dans ces conditions.
Il y a des DSP bien plus adaptés pour ce type de codes.

kosmix


A+

Putain Walter mais qu'est-ce que le Vietnam vient foutre là-dedans ?

rahow

... qui c'est qui s'occupe de l'affichage ?
^___^ Je parle bien sur de faire ça avec CUDA/OpenCL, pas GLSL ^^
Il y a des DSP bien plus adaptés pour ce type de codes.
C'est très surement vrai, et tes explications m'y font y voir plus clair, et puis sur d'autres forums ils mettent en avant des histoires de traitements parallèles.
Mais reste tout de même des choses qui me chiffonnent dans l'absolu...
- Normalement CUDA/OpenCL sont justement prévu pour faire du calcul autre que des données graphiques, comment ça se fait qu'il y ait pas de traitement DSP "standard" disponibles ??
- Dans le cas d'un plugin "simple", je comprend très bien la problématique (transfert vers le GPU plus lent que de calculer directement au CPU), mais dans le cas de plugin à traitement à la chaine multiples, genre multieffet velu ou ampli guitare (bonjour BIAS FX ^^) ---> à partir du moment ou la data serait déjà en vRAM, c'est pas quand même plus rapide à un moment de faire un maximum de traitements à la chaine dans le GPU avant de renvoyer ça au processeur ?
C'est marrant parce que ça me rappelle les discussions sur les transferts Fast/Chip RAM à l’époque de l'Amiga ---> je peux pas croire que tout ça ne soit pas devenu plus efficace entre temps, même pour des petits blocs ^^

alex.d.

- Normalement CUDA/OpenCL sont justement prévu pour faire du calcul autre que des données graphiques, comment ça se fait qu'il y ait pas de traitement DSP "standard" disponibles ??
Un GPU est un processeur conçu pour faire de l'affichage 3D (i.e. de l'algèbre linéaire sur de grosses matrices), qu'on peut détourner de son usage pour faire autre chose que de la 3D. Ça n'en reste pas moins un processeur conçu pour faire de l'algèbre linéaire, c'est-à-dire qu'il est vectoriel sur 1000 à 3000 coeurs. Chaque coeur, pris individuellement, est tout pourri ; c'est leur nombre qui fait leur force. Mais pour ça, il faut que ton calcul soit assez gros et parallélisable. Dans les plugins, il n'y à guère que les plugins avec des convolutions qui pourraient mériter un passage sur GPU. Et encore, une convolution, ça utilise essentiellement une FFT qui a une complexité en O(n.log n), c'est pas encore si bourrin, on n'est pas dans la zone où le GPU sera le plus à l'aise.
Si on regarde un peu ce que ça donne en GPU v.s. CPU sur de la FFT, on a par exemple ceci :
http://www.bealto.com/gpu-fft_benchmarks-1.html
le GPU passe devant le CPU pour une taille de bloc de 2^18. Alors je ne sais pas si psychologiquement tu es prêt à mettre tes buffers ASIO à 262144 (seulement 2.7s de latence à 96kHz) pour pouvoir profiter de ton GPU...
- Dans le cas d'un plugin "simple", je comprend très bien la problématique (transfert vers le GPU plus lent que de calculer directement au CPU), mais dans le cas de plugin à traitement à la chaine multiples, genre multieffet velu ou ampli guitare (bonjour BIAS FX ^^) ---> à partir du moment ou la data serait déjà en vRAM, c'est pas quand même plus rapide à un moment de faire un maximum de traitements à la chaine dans le GPU avant de renvoyer ça au processeur ?
Un GPU n'est pas prévu pour faire les traitement à la chaîne. Il est excessivement mauvais en séquentiel. Il est prévu pour faire les traitement en parallèle. Et pas n'importe quoi en parallèle de n'importe quoi : il est vectoriel, donc tout le monde fait la même opération en même temps sur une donnée différente. Une chaîne d'effets ou n'importe quel modèle dataflow ne rentre pas du tout dans le modèle vectoriel d'un GPU.

kosmix


Putain Walter mais qu'est-ce que le Vietnam vient foutre là-dedans ?

rahow

Et pas n'importe quoi en parallèle de n'importe quoi : il est vectoriel, donc tout le monde fait la même opération en même temps sur une donnée différente...
Ah ouai et en fait CUDA (contrairement à ce que je pouvais penser à la base) ne change en fait rien à ça... du coup c'est ou DSP genre Protool HD/UA/Wave, ou rien -____-
Ça reste extrêmement frustrant, parce que malheureusement chacun des constructeur reste dans son coin avec son propre format, alors qu'au moins si y avait un kit global (un 'OpenDSP') qui permettrait la compatibilité entre tous ces fabricants, tous les fabricants pourrait avoir un modèle de carte et les prix baisseraient/se démocratiseraient (et on se ferait moins chier à chercher des solutions alternatives de ce style)

miles1981

Citation de miles1981 :
Meconnaissance totale de l'architecture des GPU...
Un peu quand même, si ^^ Pas au point d'aller moi-même coder des CUDA core il est vrai...
Citation de miles1981 :
... et des algos audio
Oui là c'est vrai... mais si ces fameux algos audio tournent plus vite sur des machines munis de DSP, c'est qu'il doit surement y avoir masse d’opérations de bases ( + - * / ) qu'un processeur standard met trop de cycle à exécuter ^^
Je persiste. Tu n'as aucune connaissance de l'archi d'un GPU et clairement aucune d'un DSP qui n'est qu'un CPU avec quelques instructions dediees (qu'un CPU a maintenant). Croire que tout se qui tourne sur un CPU peut tourner sur un GPU, c'est juste...
Et pourquoi est-ce qu'il y a des DSPs alors que tout pourrait tourner bien plus efficacement sur un processeur actuel (surtout vu les multi-coeurs qu'on a)? C'est le dongle par excellence, et il y a aussi le fait que personne d'autre ne fasse tourner quoique ce soit dessus, donc pas de probleme parce que quelqu'un a decide de multithreader son plugin sans se poser la question des consequences sur les autres.
Audio Toolkit: http://www.audio-tk.com/
[ Dernière édition du message le 18/10/2017 à 12:44:38 ]

rahow

Je persiste. Tu n'as aucune connaissance de l'archi d'un GPU ...
Alex.d. vient justement de remplir mes blancs ^^ Comme je le disais, je pensais à tord que CUDA/OpenCL permettait d'utilisé le GPU comme un CPU, c'est clair que je me suis gouré, mais jamais j'aurais suggéré de dériver des shaders pour faire ça ^^;;
et clairement aucune d'un DSP qui n'est qu'un CPU avec quelques instructions dediees (qu'un CPU a maintenant).
Bein il serait peut être temps qu'ils s'en servent de ce "nouveau" jeu d’instruction ---> en fait ce que tu me décris est encore pire ^^;;;
Et pourquoi est-ce qu'il y a des DSPs alors... C'est le dongle par excellence, et il y a aussi le fait que personne d'autre ne fasse tourner quoique ce soit dessus...
Donc toi-même tu dis que les cartes DSP ont (aujourd'hui) un faible intérêt technologique et que tout est faisable avec les mèmes perfs sur du processeur X64 normal ?

miles1981

Dans mes futurs plugins, je vais sans doute commencer a exiger au moins SSE 4.1. Mais ca coupe d'une partie des utilisateurs potentiels.
Et oui, tout est plus ou moins faisable sur les procs actuels, surtout qu'il n'y a pas de pb de latence a communiquer les infos au DSP par pci-express!
Audio Toolkit: http://www.audio-tk.com/

alex.d.

Le probleme des nouveaux jeux d'instructions, c'est qu'il faut tout de meme que ca tourne sur les anciens ! Du coup, par exemple dans Audio ToolKit, pour les filtres travaillant sur plusieurs canaux en parallele, il y a un dispatch automatique en fonction de l'architecture. Le compilateur Intel fait aussi ca. Mais ce n'est pas le cas des compilos classiques (VS, XCode/clang ou gcc) pour le moment. Et donc tant que ce n'est pas generalise, il va falloir utiliser le moins-disant...
Seul icc le fait en automatique, mais tu peux le faire toi-même en manuel avec les autres compilos. Il suffit de compiler le kernel avec différents niveaux (SSE, SSE4, AVX, etc.) puis d'y ajouter un frontend qui teste les features du processeur et appelle la bonne version du kernel. C'est assez classique dans les gros codes de calcul.

miles1981

Pas pour rien que dans les gros codes de calculs, le compilateur Intel est tres utilise (en plus de ses capacites de vectorization et d'optimisation bien plus avancees).
Audio Toolkit: http://www.audio-tk.com/

rahow

Le probleme des nouveaux jeux d'instructions, c'est qu'il faut tout de même que ça tourne sur les anciens !
SSE 4.1 ça commence à faire un paquet de temps que ça existe !
à mes yeux ça reste plus rentable de changer de proc (dont la puissance peut servir à autre chose) plutôt que d'ajouter une carte DSP (cher et à compatibilité fermée)...
Pour dire les choses de manière globales, c'est surtout BIAS FX qui semble me prendre des ressources ---> vu comment il bouffe ils devraient même pas se soucier de sa compatibilité avec les procs < 2008 (bon après, si le truc est deja accéléré avec les jeux d'instructions additionnels que t'as cité c'est chaud -___-;; )...
Sachant que si on se fait un petit titre de hard rock tranquillos, on va bien avoir 3 instances du plug (1 basse/2guitares, sans compter les overdub) ---> bein si kkun de Positive Grid m'entends, SVP, utilisez tout ce que vous pouvez pour accélérer ce plug, jvous larguerais les XX euros supplémentaires s'il le faut...
en vous remerciant ^^

miles1981

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

rahow



miles1981

J'ai en projet de les mettre a jour avec JUCe a la place de WDL, mais pas encore eu le temps

Audio Toolkit: http://www.audio-tk.com/
- < Liste des sujets
- Charte