Salut à tous,
Je travaille sur un patch qui génère de l'image à partir du son et dont l'image réagis à un contrôleur midi (les plus attentifs d'entre vous noteront que mon patch est une version bricolé grossièrement du patch "je brouille l'écran" de Olivier (http://codelab.fr/2947)).
Le problème est que pendant que ce patch tourne, j'ai un sampleur audio et une table de mixage virtuel avec effets, et que donc du coup l'affichage de Gem rame et peine à atteindre les 20 frames seconde.
Je me tourne donc vers vous afin d'avoir quelques conseils pour optimiser les performances du patch (si cela est possible bien sur).
Dernière modification par Nomys_Tempar (2013-10-31 11:49:53)
Hors ligne
Bonsjours...
Ravi que ce patch te serve...
Ton [repeat ] indiques 77 892. C'est le nombre de fois, par frame, qu'est exécuté le bout de patch sous le [gemhead ].
Dans mon essai, j'étais autour de 8000...
C'est donc ici que ce trouve le gros de tes calculs...
A priori, c'est le GPU qui devrait en encaisser la majorité mais si ton sampler+mix sont dans la même instance, n'hésites pas :
1) à les mettre dans une autre instance
2) à utiliser [pd~ ]
et ce afin d'avoir des thread différents, donc de solicite des core différents...
Bon courage...
Et n'hésite pas à nous faire part de ton rendu final...
Hors ligne
Mon sampleur et mon mixeur ne sont pas gérer avec pd, mais avec jack/ladish et ladish gére pd.
Mais effectivement le nombre de points générés par frame semble être le plus lourd à géré pour le GPU mais vu que ta résolution était de 640x480 et que la mienne est plus grande je ne suis pas arrivé a diminuer le nombre de points généré. De plus j'essai d'avoir un rendu dense visuellement.
Du coup il doit y avoir de moyen de balancer avec les diviseur en sortie des counters pour diminuer le nombres de points nécessaire mais mes compétences en logique mathématiques (et en pure data tout court) ne sont pas suffisantes pour savoir si c'est ça ou pas
Après je n'ai pas très bien comprit comme fonctionnent les objets GEMgl vertex3d et GEMglcolor3d....
Dernière modification par Nomys_Tempar (2013-10-31 15:28:13)
Hors ligne
Du coup j'ai placé la génération des points dans un sub-patch, ça a un peu améliorer les choses, mais il faut que je teste un peu plus pour voir si ça va suffire ou non.
Hors ligne
Alors le sub-patch ne suffit pas.
J'ai diminué le nombre dans le repeat à 20 000 ce qui améliore beaucoup le framerate mais du coup j'ai besoin que mes points soient plus lumineux (ce qui est la raison pour laquelle j'ai augmenté le nombre à l'origine).
Le patch est fait pour être projeté en fond de scène donc il faut qu'il soit suffisamment lumineux et en gros soit j''augmente le nombre dans le repeat pour avoir plus de luminosité mais perd en framerate. Soit j'ai un bon framerate mais le nombre du repeat est pas assez important pour que mon patch soit assez lumineux.
Peut-être qu'en générant des points plus gros ?... Mais je n'ai aucune idée de comment faire.
Dernière modification par Nomys_Tempar (2013-11-07 16:06:49)
Hors ligne
Petite question Olivier :
D'où sort l'objet [range] que tu utilises dans jebrouillelécran2 ?
edit : Okaaaay, cet objet vient de la library flatspace qui a été abandonnée. L'objet scale dispo dans Gem ne remplace pas l'objet range. C'est l'objet scale dispo dans maxlib qui le remplace. Pour les différencier il faut donc utiliser la formulation [maxlib/scale] et là ça roule.
Dernière modification par Nomys_Tempar (2013-11-14 15:30:42)
Hors ligne
Moi qui fait des pieds et des mains pour ne pas me mettre à la programmation...
J'ai finalement pigé que [glVertex] était de l'opengl et que donc l'objet permettant de choisir la taille des points affichés était [glPointSize].
Ce qui règle mon proplème de luminosité ainsi que le lag d'affichage.
Je repasse d'ici quelque temps vous poster le patch définitif et un lien pour la vidéo de la performance live qu'il sert à accompagner
Dernière modification par Nomys_Tempar (2013-11-18 11:06:12)
Hors ligne