Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

réactions à la news Microsoft plancherait-il sur un logiciel de MAO ?

  • 73 réponses
  • 33 participants
  • 7 467 vues
  • 35 followers
Sujet de la discussion Microsoft plancherait-il sur un logiciel de MAO ?
C’est en tout cas ce que laissent croire les offres d’emploi qui ont été postées par la firme à la fenêtre colorée cet été.

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 !
Afficher le sujet de la discussion
51
Je pense que ca va etre un garage band basique qui donnera acces a du son et des vst dans le cloud, en tout cas, si cette evolution du marché de la mao se confirme
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 ]

52
Bonne conclusion, ça tien la route ce que tu dis. ;)
53
Moi j'ai le sentiment que plutôt que de créer une Stan ou un truc sauce Garage band, il vont se pencher sur des instruments virtuels et des plugs d'effets. Il y a un marché grand comme une autoroute à ce niveau, et microsoft serait bête de ne pas en profiter. Créer une nouvelle Stan n'a pas un grand intérêt pour Microsoft, car d'autres savent déjà très bien le faire. Ou alors une Stan basique, mais des instruments virtuels plus actuels, et surtout, non natifs.
54
Citation :
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é.


icon_facepalm.gif Bah viens chez moi ...

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


re icon_facepalm.gif

"Tu connais pas Sheraf ? C'est un groupe, à l'époque, ils étaient number one ! "

Antres 808 :  Bandcamp - Facebook

Escape From Work EP en téléchargement libre sur bandcamp.

 

55
Citation de nan3200 :
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.
56
Citation :
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).

http://accordeonjazz.com/

57
Yep! ;)

"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

58
De toute façon un Mac sera toujours meilleurs qu'un PC .
59
Citation de alex.d. :

Ç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 ^^

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 ??

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 ^^
60
Citation de rahow :

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.

Citation de rahow :

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.

Citation de rahow :

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.
61
Question con : et pendant que le GPU calcule la réverbe à convolution de la mort qui tue, qui c'est qui s'occupe de l'affichage ? :-D

A+ :fleche:

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

62
Citation de kosmix :

... qui c'est qui s'occupe de l'affichage ? :-D


^___^ Je parle bien sur de faire ça avec CUDA/OpenCL, pas GLSL ^^


Citation de alex.d. :

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 ^^
63
Citation de rahow :

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

Citation de rahow :

- 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.
64
En résumé c'est une idée de merde :-D

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

65
Citation de alex.d. :
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)
66
Citation de rahow :
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.

[ Dernière édition du message le 18/10/2017 à 12:44:38 ]

67
Citation de miles1981 :

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 ^^;;

Citation de miles1981 :

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 ^^;;;

Citation de miles1981 :

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 ?
68
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...
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!
69
Citation de miles1981 :
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.

70
C'est classique, oui, mais lourd. C'est ce que fait ATK pour le multicanal a l'aide de libsimdpp.
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).
71
Citation de miles1981 :
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 ^^
72
On est d'accord, ca fait environ 10 ans. Le temps passe vite !
73
Au passage : zont l'air sympa tes plugs... justement j'avais pas d'expander ^^ :bravo:
74
Merci !
J'ai en projet de les mettre a jour avec JUCe a la place de WDL, mais pas encore eu le temps :(