non ce n'est pas que des pix et loin de là!

Il y a:
des pix_ (video / images .......)
part_ (systeme de particules bien sûr)
et des boîtes textes ...

Comment savoir si ces boîtes là sont géré par le processeur ou la carte graphique?

Ok génial je te remercie grandement pour cette réponse !!   Donc si je comprends bien, dans un premier temps, changer ma carte graphique pourrait déjà m'aider beaucoup ! Mais si d'autres ont des avis....

Ok merci Oli44...
Désolé de mon ignorance , mais que veut-tu dire par lancer une instance de Pd par fenêtre Gem?

Cela veut dire ourvrir Gem d'abord, puis Pd par la suite? Cela va gagner en performance? Dès que je rentre chez moi je teste ça!

Après de nombreux et laborieux test patch par patch, il s'avère que c'est principalement les systèmes de particules et le fond généré aléatoirement (pdp_plasma, que je convertie ensuite vers Gem avec un pdp2gem) qui sont de loin les plus lourds... Hors comme l'a précisé Olivier, les sytèmes de particule sont gérées par la carte graphique. Je pense que dans mon cas, mon GPU étant saturé, pure data utilise mon CPU en complément qui donc sature lui aussi quand je rajoute les autres patch....  Enfin pour le moment la meilleure explicaton que j'ai trouvé... à moins que qqn en a une meilleure?

Nicolas

J'ai remarqué : certains objets pdp_xxx sont bien lourds . Et donc des solutions de remplacement dans Gem sont préférables .
Cela dit avec des applis vidéo ne sachant traiter que sur un processeur il y a moyen de "piper" vers une autre instance . Entre autre avec les vloopbacks (linux only) . C'est ce que j'utilise avec gephex en divisant un patch lourd en 2 instances (et plus sur un quadricoeur) . Il semble que la dernière version de pd-extended intègre cette possibilité . Je n'ai pas testé vu que je suis encore en 0.42.5 . Il y a aussi l'object pdp_vloopback dans pidip 12-29 .
Si les modules vloopback sont pas disponibles dans votre distrib c'est ici (facile à compiler) :
http://www.lavrsen.dk/foswiki/bin/view/ … backDevice

Dernière modification par sakramh (2011-10-07 10:32:34)

Olivier a écrit:

Perso, je ne sais pas ouvrir plusieurs fenêtre GEM avec une seule instance.

Oui d'où l'idée de lancer plusieurs instances : pour avoir plusieurs fenêtres. Il y avait un début de proposition de code de multi fenetre dans le source de GEM, (par Tigital je crois (ça date)) mais Tigital comme on le sait n'a pu continuer et donc je crois que c'est en stand bye...
@space47 : plus généralement, lancer plusieurs instances de pd permet de distribuer les tâches sur chaque instance et donc de limiter les encombrements notamment du buffer audio. Mais ça c'était avant, aujourd'hui on se servirait plutôt de [pd~] pour ça je suppose.

Ok encore merci,

cependant, il n'est pas possible pour moi d'avoir plusieurs fenêtres Gem, tout doit être dans une seule fenêtre...

Utiliser une boîte [pd~] est moins gourmant qu'utiliser une abstraction?
Utiliser une boîte [pd] simule une nouvelle instance, au contraire d'une abstraction qui empile les tâches sur l'instance existante?

Nicolas

OK je comprends, et aussi peut-être utiliser une autre instance pd pour faire certains calculs....
ou bien comme le propose thierry, un second ordi pour les calculs....


j'essai dès que je rentre chez moi !