Hello,
Je me débrouille assez bien sur Puredata pour faire interagir, mixer de la vidéo... Spectacles, performances.
Le "hic" c'est que je souffre de plus en plus des ressource CPU que demande Pd...
Est ce que vous avez une idée si en me mettant à openframeworks ou autres, je gagnerais en performance?
Je sais que je devrais me retourner les manches mais bon... quitte à passez un peu de temps ds processing pour aborder le code en douceur.
Tout çà sur linux bien sur?
Puredata, openframeworks, processing?
Bien à vous.
Bernard
Hors ligne
si je peux me permettre
il y aussi un autre argument qui compte bcp pour moi c l'intuitivité.
créer une Gui + process en deux coups de souris est un avantage énorme
Hors ligne
Bien sur je ne perds pas de vue pd, au contraire!
C'est plutôt pour finaliser l'une ou l'autre idée et aller plus loin si le moteur me le permet...
Pd bouffe comme un fou en performance pour le vidéo, enfin c'est l'impression qu'il me donne!
Je tourne avec lui depuis 4/5 ans avec grand plaisir!
Donc vraiment je parle de gain de performance, pas de temps!
Dernière modification par nardel (2012-06-01 17:03:36)
Hors ligne
Pour ce qui est de la motivation: si je sais que les performances sont au rendez vous, je retrousse mes manches!
Pour acceder à Pd j'étais passé par Max/Msp qui était un rien plus accessible à l'époque point de vue vidéo (avec audio)
Ici je sais que c'est loin d'être "clefs sur porte" mais une valeur sur dans laquelle je peux me lancer, alors "même pa peur" comme dirait mon neveux, si tout çà, c'est laborieux, fallais pas commencer, que ce soit pd ou autre ...
Donc si l'un ou l'autre me font part de leur experience positive ( tjrs aux niveau performance bien sûr! ), je continue!
D'autres avis?
B.
Hors ligne
Salut nardel,
Je suis assez d'accord avec toi pour ce qui et de performances de PureData;
Cependant, comme dans tout types de programmation c'est aussi une question d'optimisation :
Par exemple, avec mon mac et 2 giga de ram, j'arrive à scratcher 2 films (640*360 en MPEG-4) en même temps, pendant qu'un 3eme tourne en boucle et que 5 buffer d'images en 512*512 tournent ensemble à 20 img/sec
Après, pour le traitement des effets, j'utilise les fameux shaders pour les couleurs, les transformations etc...
Ca tourne impec, par contre que du midi ou osc, pas de GUI ça fait tout lagger...
Tout ça pour dire que pour avoir essayé Cinder, le gain de performance existe, mais il n'est pas si énorme que ça si tu as bien optimisé ton système (Entrée=CPU, traitement et sortie=GPU[le plus possible...])
ArNO
Hors ligne
+1 pour avoir vu les patches dont parle nonononono tourner. Les pix_* bouffent énormément, pas le GPU
Hors ligne
peu d'effet de mon coté! zoom, superposition, gain, tout çà dans ds pdp/pidip ( supporte pas les shaders de ce que j'en connais)
Pour ma part comme exemple d'utilisation sur Portable Pc I7, 6g Ram :
- 3 mix de 2 videos zoomées mjpeg 320X240 (1 cpu par mix) mises l'une à coté de l'autre pour un écran de 920 x 240 avec 3 gem pour léger mapping + 3 preview de pdp_glx... osc pour synchro et patch séparé pour analyse sonore...
Ou encore mix de 2 videos mjpeg de 800x600 avec Zoom avec une synchro timecode 25 i/s précise avec preview.
çà marche pas mal du tout mais si je fais une lecture de vidéo HD 1920 en mp4 sur pdp_qt ou sur un lecteur d'exemple de openframwork c'est assez bluffant comme OF reste bien fluide, Pd galère...!
voilà d'ou part mes recherches!.
Hors ligne
Tu peux aussi bosser avec pd pour faire de l'interface, même si on dit pleinde mal de Tcl/Tk, mais ça a l'avantage de se mettre en oeuvre très vite et commander en OSC un autre soft/framework. Ca dépend de ce que tu veux faire...
Je seconde ce qui a été dit sur les shaders, spliter interface et process, fuire les pix_* comme la peste...
Dernière modification par pob (2012-06-02 22:33:47)
Hors ligne
pob a écrit:
Tu peux aussi bosser avec pd pour faire de l'interface, même si on dit pleinde mal de Tcl/Tk, mais ça a l'avantage de se mettre en oeuvre très vite et commander en OSC un autre sot/framework.
vraiment??
tu as déjà comparé le code qu'il faut écrire pour une GUI en GTK (ou Qt) par rapport à tcl-tk?
tcl-tk n'est même pas orienté objet... mmmh.
et tcl-tk est loin d'être le seul language à supporter OSC...
y
Hors ligne
As tu essayé le plug VLC?
J'ai pas fait encore mais peut-être que c'est la solution à tes problèmes???
Hors ligne
A vrai dire je n'ai pas vraiment de probleme, je cherche à avancer et je l'espere dépasser l'une ou l'autre limite.
Si d'aventure utiliser openframework pour installation/performance n'est pas interessant niveau gain de performance vis à vis de Pd, pas de prise de tête.
Commander des mixers à partir de PD en Osc, pas de soucis mais la question reste là :
"Est ce que le gain de performance vaut la peine d'aller voir par exemple du coté openframeworks?"
Selon mes premiers tests, je pense que oui mais j'aurais aimer l'avis de quelqu'un qui connais Pd et Of par exemple...
Je vais de toute façon reviser Gem + GPU, (peut 'etre larguer un peu pdp/pidip...? qui de plus ne fonctionne pas trop sur les dernieres version de Pd-extended)
Du coté VLC je ne vois pas trop comment mixer ou mapper dessus?
Merci pour vos avis ...Pour les performances je vais aussi poser la question sur le forum de Openframeworks, çà pourra peut etre m'éclairer.
Hors ligne
Yv,
je crois que pob ne parlait pas de programmer directement en tcl/tk, mais du fait que le GUI de pd est programmé en tcl/Tk :-)
VLC, c'est un bon lecteur de media, pas moyen de mixer, avec mplayer non plus même si c'est sympa à télécommander.
Une fois que tu travailles avec des shaders, peu importe finalement le fait d'avoir ou pas PD ou OF ou Python pour commander le tout, c'est une question de goût, d'aisance qu'on a acquis avec un langage compilé ou du dataflow, de la programmation graphique etc. Mais c'est clair que pdp/pidip, c'est pas intéressant à ce niveau. Gem ouvre déjà plus de possibilité, si on reste dans le cadre de Pd. Gridflow en entrouvre pas mal.
Hors ligne
oli44 a écrit:
VLC, c'est un bon lecteur de media, pas moyen de mixer, avec mplayer non plus même si c'est sympa à télécommander.
une petite précision par rapport à VLC :
libVLC est supportée par gem, voir :
http://codelab.fr/3296
autre chose, le message [open fichiervideo.mov< peut être complété de la manière suivante :
[open fichier.mov rgba 2<
le '2' à la fin c'est le backend que l'on veut utiliser pour décoder la vidéo, donc à chercher aussi peut être par la quel est la combinaison codec/backend la plus performante... (je retrouve pas le fil de dicsussion sur gem-dev ou IOhannes en parle...)
Hors ligne
La solution : openFrameworks.
Simple et facile a manier, il vous permet de découvrir le c++ facilement. Son fonctionnement est très très très similaire à processing.
Pour ce qui est du c++ , j'ai rapidement appris les bases sur le site du zero, et je me suis lancé
Je recommande d'essayer, de l'installer , de parcourir les tutos, le wiki oF, et de décortiquer les examples
Je connais pas pD, mais je peux te dire que vis a vis de processing, le gain de performance est monstrueux^^
Dernière modification par cgiles (2012-06-03 07:49:00)
Hors ligne
Comme dit un peu plus haut, une fois qu'on utilise le GPU au lieu du CPU pour calculer, les perfs sont peu ou prou les mêmes : après c'est sûr que passer de java aux shaders, ça doit faire du bien
Hors ligne
Pages: 1 2