Se connecter
Se connecter

ou
Créer un compte

ou
FR
EN

Le pub des programmeurs

  • 1 927 réponses
  • 117 participants
  • 131 679 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
751

Citation :
Un truc qui promet beaucoup, c'est qu'alors que pour les CPU, il va falloir programmer en parallele, les GPU ont un modele plus simple pour programmer du numerique (les GPU utilisant les multi core depuis bien plus longtemps que les processeurs). Et la puissance des GPU evolue beaucoup plus vite que les CPU, aussi.



Voilà c'est exact ce que je voulais dire sur la raison de prendre des GPU meme si c'est plus cher ;)
La nouvelle génération de cartes graphiques à architecture unifiée arrive pour la rentrée de septembre , avec la sortie du R600 dans 15 jours arrivera aussi la nouvelle carte de chez nvidia.

Citation : En tout cas, à moins d'une machine virtuelle qui aura de toute manière besoin de savoir d'une manière ou d'une autre ce qu'elle peut paralléliser - et tout en audio ne peut pas être parallélisé -, utiliser le GPU pour tous les VSTs est impossible



Exactement là est le problème. Mais je ne connais pas assez l'architecture des VST pour savoir comment différencier les différents process.
Il faudrait faire un classement de ce qui gagne à être parallélisé, et ce pourquoi c'est plutot un fardeau.
Ensuite il faudrait voir comment transposer le traitement sur les cartes graph.
Il faudrait également regarder si on peut détourner les cartes graphiques pour traiter les samples qui y a en mémoire, pke la plupart des ttes neuves ont la possibilité de garder en mémoire les scènes de jeu vidéo les plus utilisées et calculer uniquement ce qui change. Appliqué à EWQLSO par ex, ca serait puissant :).
Après avoir traité ca, il faudrait voir comment faire l'aiguillage des process en temps réel sans perte importante de perfs à expliquer à la carte qu'est ce qu'elle doit faire. Le point où on peut perdre le plus est de devoir envoyer vers la carte, traduire, et faire revenir l'info.

cptn.io

752
La parallélisation des traitements au niveau global se fait par le séquenceur. Ensuite, au sein des VSTs, c'est à chacun de se débrouiller. Le problème est que même pour une machine virtuelle, il faudra recompiler tous les VSTs pour qu'ils puissent tirer partie des primitives parallèles - idem que pour Python, le calcul est rapide parce qu'on utilise derrière des primitives en C/C++/Fortran -. Donc ça signifie énormément de travail, et comme dit, tous les effets ne sont pas faits pour être parallélisé - un IIR est difficiliment parallélisable, contrairement à un FIR -.
Pour ajouter la partie rester en mémoire, il faudrait un changement complet de standard de plug-in - genre VST4 - et ça n'a d'intérêt que si les GPU ont un intérêt. Pour l'instant, c'est compliqué d'utiliser ça pour un développeur standard, et la précision n'est pas encore au rendez-vous. Ne pas oublier qu'on utilise autre chose que des additions/multiplications dans certains effets aussi, ça limite encore plus l'utilité d'un GPU.
753
Tiens, une serie de slides interessante de Tim Sweeny (le fondateur de Epic Games, la cie derrier Unreal Tournament) sur les limites des langages actuels pour les jeux video.

http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
754
Effectivement c'est intéressant, et très révélateur de ce à quoi sont confrontés les concepteurs de jeux. Les pauvres.. :oo:

Vers la fin, quand il dit:

Citation : If we are to program these devices productively, you are our only hope!


Est-ce que tu sais à qui il s'adresse? A des développeurs d'Haskell?
A man, a plan, a canal : Panama
755
Je suis pas d'accord sur les pauvres... En fait, j'ai vu ce lien poste par un gars qui dit comment il regrette que le premier langage qu'il ait appris soit le C, car selon lui, ca te force l'esprit a voir tout langage comme du C, eg du code qui tourche sur la machine virtuelle C (cad un PDP-11 tres rapide avec beaucoup de memoire).

Perso, je regrette clairement avoir appris le C en premier aussi. Je pense que c'est un des pires langages a apprendre en premier. C'est clairement utile, voire necessaire dans pas mal de cas, puis c'est inherent a Unix, qui reste quand meme la reference en OS.

Le pdf venant d'une universite, on pourrait penser qu'il s'adresse a des membres d'un labo en info.
756
Ca doit dépendre des gens, mais c'est vrai que tout le monde ne peut pas modifier sa manière de penser. Au moins maintenant les maths/infos commencent pas mal par du Caml, puis ensuite font du C - enfin, c'est parfois les 2 de front -, ils ont au moins un peu la philosophie fonctionnelle.
Le truc, c'est que ces slides font porter le gros poids sur le compilateur qui lui passe du fonctionnel - ce qu'il aimerait, en gros -, à de l'impératif en sous-jacent, et donc toutes les vérifications sont faites par l'interpréteur/compilateur.

D'ailleurs, il y a certains points dans la diapo qui me font penser qu'ils devraient penser à essayer Python :D
757
Je pense pas que ce soit possible pour python, le langage est tout simplement trop dynamique pour permettre ce genre de choses. OCAML est certainement beaucoup plus proche a ce niveau la. Mais la taille des communautes n'est pas la meme...
758
Salut les gars et desole si j'interfere dans vos discussions assez haut niveau.
J'ai passé déjà pas mal de temps à chercher et je ne trouve rien qui couvre mon besoin.
Je cherche à developper un petit plug VST (dans un premier temps; peut être AU pour macosx dans un deuxième temps).
juste un petit synthé qui pioche des sons sur la becane pour les rejouer sous des impulsions midi.
J'aurais bien aimé trouver un tuto pour démarrer avec qq petits example de code c++ et visual mais je suis resté bredouille; je suis un peu perplexe devant la multitude des architectures disponibles (csound, portaudio, synthmaker, juce...pfff) et devant le peu de forum ou de retour d'infos sur les usages de ces couches.
Pareil pour l'aspect ihm (Wxwidgets, asseca, ...)
Si quelqu'un peut éclairer ma lanterne sur une façon simple de démarrer
merci
759
Portaudio c'est jouable mais il, te faut visual .net, sinon c'est la misère à faire tourner (et les exemples sont quasi tous sur visual). Mais il te reste à intégrer l'IHM. Chez nous on tourne avec portaudio et QT en interne, mais je ne dirais pas que c'est le plus simple.

Sinon tu as juce, Wolfen a torché un vst assez rapidement avec. Et l'ihm est intégrée.

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

760
Et JUCE gère l'AU aussi ...
Hop, un lien pour aider: http://www.rawmaterialsoftware.com/juce/
My name is john, '_' john.
761
Juce est très simple d'accès en effet. Le code est bien documenté.
Par contre faut compiler soit même la dll de Juce avec le sdk windows. Disons que la mise en route du tout peut prendre avec les téléchargements plusieurs heures.
En tout cas pour moi, j'ai mis deux jours avant de compiler mon premier VST...
J'avais pas l'habitude de développer sous windows mais vu le nombre de mails que j'ai reçu sur Juce et la mise en place de l'environnement de dev, je pense que je suis pas le seul à m'etre battu avec visual studio et les linkages...

http://soundcloud.com/bat-manson

762
Non mais le probleme c'est plus l'environnement windows qu'autre chose. C'est toujours pareil, tant que tu fais ce que MS fait ce qu'ils veulent, c'est a dire aujourd'hui .Net, ca marche. Au dela de ca... Depuis Visual Studio 2003, il est extremement difficile de faire du dev win32 en pur C++ (pur C est quasiment impossible, le support C99 etant encore tres pauvre, meme sous visual studio 2005), c'est logique vu la strategie de MS.

Tu ajoutes a ca un environnement extremement peu flexible en ligne de commande, avec la philosophie typique windows de fournir 5000 outils pour faire la meme chose plus ou moins, et ca rend le truc extremement complexe pour sur. C'est extremement difficile de faire quoi que ce soit de portable avec l'environnement de dev windows.

La, je suis particulierement enerve parce que l'implementation de open/close est totalement bugge sous windows, et leurs fonctions CreateFile/OpenFile sont d'une complexite effarante. Pour ouvrir un fichier sous windows, il faut faire


hFile = CreateFile(TEXT("myfile.txt"), // file to open
GENERIC_READ, // open for reading
FILE_SHARE_READ, // share for reading
NULL, // default security
OPEN_EXISTING, // existing file only
FILE_ATTRIBUTE_NORMAL, // normal file
NULL); // no attr. template


Et apres on essaye de nous faire croire que windows n'est pas fondamentalement condamne a etre rempli de trous de securite... Tant que ce genre de fonctions seront utilisables...
763
Je suis d'accord avec ton analyse de la source des difficultés que j'ai rencontré.
Disons que le sdk VST de Steinberg (nécessaire pour Juce de toute façon) a moins de dépendances que Juce, et qu'on n'a pas à rapatrier tout le .net.
A priori, cela semble plus facile de compiler le VST sdk que Juce.

CreateFile ??? arf, c'est un truc de malade cette syntaxe. Faire un createFile, avec comme flag OPEN_EXISTING, sémantiquement c'est quand meme super boiteux.

Sur l'ouverture en lecture, que vient foutre la sécurité (à NULL d'ailleurs) ?
(je vais me documenter, c'est étrange tout de même). Enfin bref...

http://soundcloud.com/bat-manson

764
Pour le flag d'attributs de sécurité, sur le site de krosoft on peut trouver :

Citation :
pSecurityAttributes :
[in] Ignored; set to NULL.



Ben c'est cool, passer un flag tout le temps qui sert à rien, que du plaisir...
Et sur le dernier flag aussi :

Citation :
hTemplateFile
[in] Ignored;



Ouais, super, joli travail messieurs. Je reconnais que c'est pas la joie, et que tu dois passer ta vie dans les documentations...
Bon courage !

http://soundcloud.com/bat-manson

765
Les raisons sont a chercher du cote de la compatibilite, je suppose. Mais c'est sans fin... Je l'ai deja cite, mais je pense que la meilleure explication du truc est donne dans le celebre MS lost the API war de Joelonsoftware: https://www.joelonsoftware.com/articles/APIWar.html
766
Nonconforme > vous utilisez Qt pour des plug-ins VST ?
767
Je ne fais pas de plugin VST mais j'utilise l'ASIO/portaudio/QT dans un de mes softs (mesures labo).

Mais je ne vois pas ce que ça aurait de gênant d'utiliser QT et VST ?

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

768
C'est possible, mais il faut à priori utiliser un QSolution de Trolltech pour faire pouvoir construire sur un widget dont on ne récupère qu'un handle, d'où ma question :)
769
Ouaih, bah là je ne suis clairement plus compétant, je ne m'occupe que très peu de cette partie. :clin:

Affiliation : Dirigeant Fondateur d'Orosys - Two notes Audio Engineering

770
Je comprends pas non plus le probleme d'utiliser QT et VST ? VST gere la partie "audio", tu as un protocole entre la partie audio et la GUI, et le fait que ce soit VST ou CoreAudio, QT ou win32, ca ne joue pas ?
771
Oui. VST ne décrit que les échanges hote - plugin et au sein du plugin : moteur audio et GUI.
Après, tu prends ce que tu veux pour faire la GUI ou le moteur audio...(modulo le bon format de sortie audio pour le sequenceur).

VST est un format de plugin relativement simple. Le seul problème est arf...le midi. Faudrait ptet passer à autre chose un de ces quatres, genre OSC non ?


Hors sujet :
ça y est j'ai enfin compilé mon premier plugin firefox embarquant la lib fmod...arf, ce fut horrible. 4 heures pour compiler l'exemple, 3 pour y ajouter fmod correctement..et l'impression à la fin que tout cela aurait pu etre fait en dix minutes avec une doc respectable et des exemples mis à jour.
Y'a 3 articles du forum de mozilla qui explique pas à pas comment modifier les sources pour compiler les exemples. Ils auraient pas pu changer les fichiers du svn, non ? En plus l'aspect cross plateform tellement cool mon c*l. Les fichiers sources sont à modifier en fonction de la plateforme utilisée...

http://soundcloud.com/bat-manson

772
VST donne aussi la méthode d'accès aux fenêtres avec la classe AEffectX. Or on ne récupère que le handle vers la fenêtre du plugin, et comme dans Qt, il n'y a pas moyen de créer une fenêtre autrement qu'avec un QWindow, ce n'est pas possible.
773
Je ne suis vraiment pas expert. J'ai donc regardé un peu le code du wrapper de Juce VST pour gérer les fenêtres. C'est pas si simple et même bien documenté cela a l'air complexe...peut être que cette piste peut t'aider à wrapper Qt.

Ensuite pourquoi Qt quand tu as Juce qui permet l'export en VST, audio unit et Ladspa sans rien changer d'autre qu'un include, qui est de plus cross plateform ?
C'est vrai que les VSTs sont gros en sortie (genre 3 Mo), surement du à une mauvaise option de compilation de ma part...

Les fonctions de UI sont en tout cas très simple et puissantes, te permettent de faire le state of the art of the GUI.
Après je ne connais que très peu Qt, et vraiment pas assez pour connaitre ses qualités vis à vis de Juce. J'aime pas faire des GUI de toute façon.

Il y a quelques bons synthés commerciaux qui utilise Juce, comme les derniers de chez image line (toxic III et poizone si je ne m'abuse, le reste étant du delphi !). C'est un gage de qualité il me semble, au vu de la qualité générale de leur interface.
Et puis tu as en plus toute une batterie de fonctions pour interpréter le midi, des choses comme des fonctions freqToMidi, isNoteOn, getVelocity...

Le genre de chose qu'on peut attendre d'un framework pour faire des VST en résumé.

http://soundcloud.com/bat-manson

774
Petite question : quelqu'un connaît un bon logiciel sous Windows pour faire des figures avec LaTeX ? Pour l'instant, je me sers de OpenOffice et de Inkscape, mais même avec des formats vectoriels j'arrive pas à obtenir quelque chose de super propre...

Merci les gens !

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

775
Moi j'utilise inkscape, les svg sont convertis en eps avec inkscape puis en pdf avec eps2pdf pour pdflatex. Par contre, l'eps ne gère pas plusieurs niveaux de transparence, ce qui peut être un peu embettant. Mais c'est propre ;)