Je trouve que ton exemple marche très bien.
Il faudrait juste pouvoir changer dynamiquement le nombre de points de résolution, la taille, etc.

Il faudrait voir combien de points sont nécessaires.
Ensuite si c'est plus ou moins performants que mon système avec [repeat] et que les shaders.
Voir l'utilisation des shaders dans [gem.scope~], cela peut nous aider à comprendre.

Ensuite, il y a la question de la fréquence d'affichage. Je trouve que ce n'est pas évident de trouver les bons réglages. Il y a des effets de rémanences visuelles (deux courbes visibles), etc. Il y a trois ou quatre paramètres à régler :
- la fréquence de l'écran de l'ordinateur
- le framerate de gem
- et la fréquence de l'échantillonnage des valeurs en entrée.
- et peut-être aussi les dimensions de la courbe dans la fenêtre GEM et la largeur de la courbe.

Je pense qu'il faut renommer cette discussion, en mettant un ou plusieurs de ces termes. "courbe", "gem", "curve", "oscilloscope", "shader".

Au fait, tu n'arrives toujours pas à créer un objet [curve] avec plus de 8 points ?

Yep...

Juste pour dire que je n'ai pas résolu cette histoire de [curve ] avec plus de 8 points mais que, en m'appuyant sur le patch de nononononono j'ai un peu avancé sur la question de l'OpenGL... (merci, par ailleurs)
Quand j'aurais quelque chose de présentable je posterai...

Concernant ta suggestion de renommer ce fil différemment, Jérôme, je ne conteste pas sa pertinence...
C'est juste que sur Codelab, on ne peut pas changer le titre d'un fil, même si on en est l'auteur...

Ha ha...
Gros malin... je te rappelle que tu es modérateur de la section Pure Data...

Tout le monde n'a pas ce privilège... 

J'ai essayé de créer dynamiquement un oscilloscope avec l'objet [curve].

Le patch :
http://abel.jerome.free.fr/pd/oscillo/o … Curve2.zip

Dans ma configuration actuelle (WinXP et XUbuntu 10.04), j'ai un message d'erreur dès que je créé un objet [curve 31] avec un argument au dessus de 30.

Sinon, ça marche à peu près.
Mais :
1 - la limitation du nombre de points rend cet objet assez peu exploitable.
2 - je m'aperçois que la courbe change, les points ne sont pas sauvegardés en l'état comme un oscilloscope, la courbe se recrée.

Mon précédent essai [oscilloGemCurve] était meilleur :
https://gitorious.org/pd-gem-ui

L'objet [curve] semble donc moyennement approprié.

Prochaine étape : les shaders ?

Dernière modification par jerome (2011-07-01 19:24:13)

citation :

As-tu jeté un œil au sismographe de nonononono qui, pour le coup, reprend le même schéma que ton oscillo avec des [curve 2] mais en instruction OpenGL  ?

Je propose un oscilloscope [oscilloGL], basé sur le sismographe (http://codelab.fr/2593#p13137) :
http://abel.jerome.free.fr/pd/oscillo/oscilloGL.zip

Je ne me suis pas penché sur les optimisations du code openGL, car je n'y connais rien.

J'ai rédigé une petite comparaison de mon test avec [curve], l'abstraction [oscilloGemCurve] :
http://abel.jerome.free.fr/pd/oscillo/o … risons.txt

En gros, l'oscilloscope avec open GL a de biens meilleurs résultats quand il s'agit d'augmenter la taux de rafraîchissement de la fenêtre GEM. C'est donc un bon point. En effet [oscilloGemCurve] synchronise la lecture du tableau où sont stockées les données en entrée, avec un bang envoyé par la "GemList" donc par le gemhead en tête de la chaîne. Plus c'est rapide, plus le tableau est lu, donc plus le processeur travaille ... Peut-être y a t-il moyen de faire autrement pour le lire ce tableau moins souvent

Pour le projet de la valise pédagogique (https://gitorious.org/valise-pedagogique/), il faudrait faire des tests avec 16 oscilloscopes dans une même fenêtre pour comparer les performances, la fluidité, etc.

Dernière modification par jerome (2011-07-04 16:00:59)