Salut,
J'ai commencé à travailler sur la transposition des objets d'interface de puredata vers GEM.
C'est dans l'idée de me déplacer dans les paramètres qui couvrent plus de surface que mon bureau.
Quand on demande à Puredata de redessiner ses objets d'interface c'est très lourd. Finalement GEM le fait bien mieux.
Donc voici les premiers objets, il m'en reste quelques uns.
Je cherche un moyen de dessiner un secteur de disque. J'ai pas réussi autrement qu'avec des gemframebuffer, c'est le marteau pour écraser une mouche...
J'ai tenté de le faire avec un polygone mais je n'arrive pas à lui faire colorier l'intérieur en passant pas le point central : ça fait une forme concave et après avoir tenté pratiquement tous les modes de tracé, je ne sais pas trop quoi faire...
Je me dis que je vais finir par faire des secteurs comme les lames d'un éventail et les faire tourner depuis le centre. Pareil c'est un peu lourd comme solution.
Pour l'instant :
fader horizontal
fader vertical
bang
toggle
grid
rotary
Et bientôt !
number box
text box (cliquable ou non)
image
cadre / canvas
ligne
radio selector h/v (patch dynamique ?)
graph
J'imagine qu'il y a déjà des librairies, mais là j'ai fait ça selon mes besoins.
Dernière modification par pob (2010-08-10 09:50:11)
Hors ligne
Salut, en effet j'avais déja commencé une librairie d'abstraction pour reproduire les objets pd dans gem http://raphael.isdant.free.fr/pure_data … ions04.zip
Je souhaitais l'agrémenter d'une boîte texte proche de l'objet "entry" mais pas eu le temps...
astucieux ton objet rotary
Hors ligne
Merci.
Dans cette version le rotary déconne dans certains patchs chez moi. Le potard s'inverse. J'ai pas trouvé d'où ça pouvait venir. Il a fallu changer un truc dans le premier gemframebuffer... Petit bug...
Je préfèrerais me passer des gemframebuffers, ça serait plus léger et parfois moins instable.
Dernière modification par pob (2010-07-19 00:08:19)
Hors ligne
Ben tout bonnement il suffisait de couper le secteur en deux et faire deux polygones qui ne sont pas concaves. L'idée est venue alors que je venais d'éteindre la lumière, une fois de plus ! Et pour éviter de trop y penser en m'endormant, j'ai rallumé et j'ai torché le truc en dix minutes.
Restent à faire :
number box
radio selector h/v (patch dynamique ?)
graph
sélecteur de couleur (soit le modèle Adobe/Gimp avec une bande, soit le modèle Painter avec le cercle et le triangle)
Dernière modification par pob (2010-08-10 09:50:34)
Hors ligne
Les choses avancent.
Reste plus que l'affichage d'un array/table à faire. Eventuellement éditable à la souris.
Si vous avez d'autres idées...
J'ai un dernier truc à faire sur sélecteur de couleur de type HSV. J'y ai dajà passé deux grosses journées et comme c'est pas forcément primordial, j'ai laissé un peu décanter pour revoir ça plus frais.
donc maintenant disponibles en plus des précédents éléments :
- "numbox"
- sélecteur radio horizontal et vertical
- un grid avec deux points avec éventuellement une ligne entre les deux points (pour faire les niveaux des blancs et noirs par exemple).
- boutons rotatifs pour pan classique et à 360°
- cadre et boîte colorée
Regardez le fichier texte si vous voulez connaître les paramètres de créations et les entrées/sorties.
N'hésitez pas à vous en servir. Il faudra sans doute adapter un peu selon la résolution de votre écran ou vos applications.
Il y a sans doute un objet créateur d'objets à faire pour simplifier le travail de création d'interface. Une fois qu'on commence à faire du patch dynamique, ça donne pas mal d'idées ! C'est ce que je retiens de ma soirée passée à bosser sur les sélecteurs radios.
Hors ligne
Pour donner une petite idée du rendu...
en plus grand : http://www.flickr.com/photos/pob31/4877121153/
Il y a encore quelques trous à combler en adaptant certains objets ou en créant des neufs, mais l'essentiel est ici.
Côté ressource c'est en permanence plus gourmand que l'interface de base de Puredata sauf quand de façon dynamique dans le patch on déplace un GOP (graph on parent) où à ce moment c'est bien plus intéressant d'être dans GEM. Et puis quand il y a trop à dessiner, il ralentit tout simplement. Reste à voir comment tout ça va se comporter avec la connexion netsend aux patchs de rendu vidéo (sur un second ordi) et audio sur la même machine mais sur l'autre noyau du processeur...
Dernière modification par pob (2010-08-10 02:58:09)
Hors ligne
pob a écrit:
Côté ressource c'est en permanence plus gourmand que l'interface de base de Puredata sauf quand de façon dynamique dans le patch on déplace un GOP (graph on parent) où à ce moment c'est bien plus intéressant d'être dans GEM.
Salut, ouais de mon point de vue ce système est intéressant à partir du moment ou gem speede vraiment plus de tcl/tk... si c'est pour avoir un gain minime voire pas de gain l'intérêt est limité...
Pourquoi exactement tu veux te passer de tcl/tk ? Ou autrement dit qu'est ce que t'apporte gem qui te manquait auparavant ?
Hors ligne
Salut,
Je suis bien d'accord avec toi. Mais je tente le coup quand même. Il faudra sans doute faire des compromis au final comme souvent.
Ce qui m'a poussé à faire ce travail c'est que j'ai saturé mon écran avec des boutons et des prévisualisations pour la partie image. Je ne peux pas vraiment faire sans. Et là il faut que je me fasse une partie son en plus ! Alors j'ai tenté de planquer des trucs utilisés moins fréquemment avec un GOP dont je fais varier la position, mais à chaque changement il y a un très gros pic d'occupation CPU car il redessine tout le sous-patch correspondant (avec une trentaine de toggle, quelques des sélecteurs radio et bang et une vingtaine de faders). GEM est carrément plus gourmand en moyenne, mais sans ces pics. Je crains que sur cette machine légère qui servira aussi pour le son ce soit une source de problèmes. A confirmer.
Je pourrais avoir deux ou trois fenêtres de Tcl/tk et jongler entre elles, certes... Mais bon les Alt-Tab pour chercher la bonne page, c'est pas forcément très pratique pour aller vite dans l'obscurité. De plus j'ai besoin de certaines infos en permanence, genre les images chargées. Du coup je me suis permis cette possibilité dans ce que j'ai fait dans GEM.
Et puis il y a la possibilité de faire un sélecteur de couleur HSV, c'est pratique même si ce n'est pas essentiel. C'est sans doute faisable comme objet dans pd, mais pas à partir des objets de base. J'en suis pas forcément à coder mes propres objets pour le moment et vu l'échéance du 28 août, j'ai pas le temps pour me construire ça...
Je fais un peu la chasse à ce qui bouffe du temps machine pour pas grand chose. Pour cela je pense que je vais virer tous les objets [text2d] ou [text3d] qui sont assez moches niveau rendu des typos et en plus l'antialiasing de [text2d] est assez gourmand. Donc je ferais une capture d'écran avec sur chaque page tout à sa place et je me servirai de cette image en arrière-plan. C'est pas pratique pour les modifs, mais je conserverai un patch avec les objets textes pour faire évoluer au besoin.
Au final tout ça va dépendre de l'intégration avec le patch de contrôle et le patch audio. Et puis si c'est pas efficace au final, tant pis, j'en reviendrai à Tcl/tk de façon pragmatique.
Au final une fois que le patch son sera créé et surtout stabilisé je penserai à trouver ou fabriquer une interface adaptée. Mais tant que c'est en maturation c'est pas une très bonne idée de trop investir dans du hardware.
Je termine de transplanter l'interface. Il reste deux objets à écrire, un totalement trivial (un rectangle qui change de couleur et qu'on peut déplacer, l'autre un aperçu de format d'image (aspect ratio) dont j'ai déjà dû écrire la formule, et puis le sélecteur HSV à terminer (avec une formule à la con à débugger) avant d'être prêt pour tester ça de façon appliquée.
Hors ligne
Pour moi, l'intérêt principale de me passer de tcl/tk... c'est que ce n'est pas très très sexy...
Ce qui m'étonne, donc, Pob, c'est que tu aies conservé cet aspect en passant dans Gem...
Mais bon, c'est un choix comme un autre...
Je n'ai pas regardé si tu as publié tes objets sous licences libres...
Mais si c'est le cas, mon point de vue c'est que ton travail est une base sérieuse pour obtenir des interfaces "grand publique"...
Chouette...
Hors ligne
Je viens de tester en modifiant le nom des quelques abstractions qui gèrent le texte... L'effet niveau consommation CPU est monstrueux. On passe sur un Core2Duo LV à 1.6GHz de ~65% avec Antialiasing (joli), ~50% sans antialiasing (moins joli et surtout un peu moins lisible), à ~20% sur le noyau qui fait tourner Puredata.
Donc, il n'y a pas à tortiller, il faudra faire une capture d'écran avec les étiquettes et placer cette image en fond de page pour chacune des trois.
A ce moment, le lissage et l'utilisation à peine plus élevée du CPU vaut la peine.
Hors ligne
Olivier, merci pour les encouragements.
J'ai pas mi de licence, je ne vois pas comment j'en rajouterai une par dessus celle des outils de base, je n'ai écrit que des abstractions en fait. Je pense donc que c'est cette licence qui prévaut, non ? Et si je voulais pas qu'on utilise ce que j'ai fait je ne l'aurai pas posté ici, voire... j'utiliserais Max !
J'ai fait des modifs dans les objets et j'en ai créé d'autres (play, stop, pause, loop, rec) depuis la dernière archive. Dès que j'ai fait ceux qui me reste à faire, je mettrait tout à jour ici.
Oui, c'est pas très joli Tcl/Tk... On est tous assez d'accord. J'ai pas trop changé pour ne pas trop gréver le petit proc' et le chipset intel qui fait le rendu vidéo. Il sera toujours temps de mettre quelques bitmaps par-ci par-là une fois la base posée. Là, je suis un peu dans l'urgence.
Le premier truc qui va changer c'est les boutons Bangs. Le reste ne me déplaît pas trop. Je verrai pour mettre des dégradés sur les faders. Faire des boîtes avec des coins arrondis, pourquoi pas. Mais il faut écrire l'objet pour l'intégrer dans GEM. Ca dépasse mes compétences actuelles.
Par contre un truc que j'imagine faisable pour moi, c'est un objet qui permettrait de choisir le type d'élément, le placer, le dimensionner et régler ses différents attributs, ses entrées send/receive. Avec une prévisualisation avant validation. Ce qui me paraît plus compliqué c'est de pouvoir éditer à posteriori...
Dernière modification par pob (2010-08-10 13:44:12)
Hors ligne
Une fois que j'aurai un peu de temps, je ferai une visualisation de fichier son avec zoom et éventuellement un truc du genre Comparisonics (R).
http://www.comparisonics.com/gallery.html
C'est utilisé dans Samplitude ou Sequoia et franchement, c'est génial pour voir à quoi ressemble le contenu d'un fichier son.
En gros il faut faire une FFT. A chaque bande de fréquence correspond une couleur dans le spectre (bleu violet - graves à jaune-rouge - aigus). On mélange les couleurs et on normalise. Plus c'est bruiteux et plus c'est gris. Plus c'est saturé et plus il y a une fréquence dominante. Il faudrait un objet d'analyse et un d'affichage pour plus de souplesse.
Mmm... vivement que j'ai le temps de m'y pencher...
Dernière modification par pob (2010-08-10 13:59:23)
Hors ligne
Salut Pob,
ton porjet me parait très intéressant, Jérôme Abel a déjà débuté une interface de la sorte , qui cependant ne prend pas du tout de CPU. Je crois que le problème du CPU réside dans le choix de la carte graphique. Personellement, je fuis comme la mort les chipset intel, et je n'utilise que que du nVidia (mais alors que du nVidia!). En tout cas le patch de jérôme tourne à 5-10% de CPU sur un Mac Mini, et idem sur mon LAtitude d630 , les deux en core2duo pas hyper véloces, en résolution 1680x1050 sur le second écran.
Hors ligne
A propos de la licence:
c'est pas innocent d'en mettre une, pas tant pour mettre la même que celle de Pd, parce que tu passer en proprio du code écrit avec un programme libre, en tout cas persone ne t'en empêche, que pour que tu en sois réellement crédité, que ça permette à ceux qui souhaite continuer à faire évoluer ton projet de le faire, et surtout ne pas permettre que quelqu'un le privatise.
La GPL est pas mal pour ce genre de projets.
Dernière modification par oli44 (2010-08-11 10:52:38)
Hors ligne