Je me pose quand même la question de TclTk... Est-ce bien raisonnable de faire une interface avec les objets d'interface de Pd ? Je me dis que GEM est peut-être plus souple pour de l'affichage dynamique... Qu'en pensez vous ? J'ai une bonne grosse interface qu'il va falloir faire pour notre projet de régie interactive multimédia et à part pour des problèmes de lettrage qui marche très mal dans GEM, je pense m'orienter vers cette solution. Ca peut-être plus contraignant dans le sens où il faut vraiment faire la communication entre les deux univers qui ne se cause pas aussi nativement que les objets d'interface en TclTk de Pd.

Effectivement, ça pose plusieurs problèmes :
- conso processeur que ça engendre. Franchement si yavait pas que windows qui ne disposait pas de [pd~], je dirais "on s'en fout, let's go en full pd, en plus ça reste bricolable". Mais vu la relative monothreaditude actuelle de pd, j'ai pas envie qu'un zoom sur la timeline fasse faire des scroutchs à mon patch.

- justement, l'évolutivité : tout le monde ne maîtrise pas les datastructures (moi le premier d'ailleurs, ça et les pointeurs = beurk), d'accord, mais tout le monde est-il capable de traficoter du Tcl/Tk ? Si ça restait full pd ça serait cool.

- justement, le fait que ce soit une autre fenêtre (genre Gem). Ça me dérange. Et si j'ai envie d'intégrer la timeline à mon patch ? Honnêtement une timeline séparée c'est pas terrible ergonomiquement parlant.

De mon point de vue : la timeline doit être intégrable à un patch (même fenêtre, salut GEM !), séparable au besoin, et si ça reste du pd c'est cool (mais je suis pas totalement non plus contre l'idée d'un gui-plugin en Tcl/Tk, du moment que ça reste intégrable )

Sinon pour la prise d'infos et le retour sur le patch, fouiller du côté de SSSAD peut-être ?

Remarque au sujet de [pd~]. Effectivement, cet objet est absent de Pd version Windows. Ca permet de faire du multithread, mais, et c'est un gros MAIS, c'est un processus bloquant. C'est a dire qu'il fonctionne à la même vitesse que tout le reste si les sous-patchs [pd~] ont une action à terminer tout le reste du patch attend.
Le seul moyen d'avoir du multithread non bloquant, c'est de faire des instances reliées par [netsend]/[netreceive] ou OSC.
A partir de là il est plus que nécessaire de faire des instances séparées si on a des grosses mises à jour d'interface.

@ pob >> yep >> c'est comme cela que l'on peut gérer deux gros patches sons et image

bon j'ai retroué une autre time line existant sur pd => c'est pd live,

http://code.google.com/p/pdlive/downloads/list

non seulement c'est bene bene à voir et à utiliser, mais l'exemple time line est interressant, c'ets en gui, mais bien foutu, par contre il y a pas toutes les possibilités que nous avons levés.

Petit test exemple orienté piano roll avec des structures basiques. Il faut toxy pour l'édition sur la timeline, mais pas pour la lecture.

Dernière modification par kirobatz (2012-01-24 20:14:32)

Oui très belle cette timeline...

Allez je m'y colle aussi.

j'avais besoin d'une conduite pour gérer sous titres, son et vidéos d'un spectacle.
j'ai fait un truc comme ça, bien évidemment peu soigné et pas documenté, mais qui marche pas mal.

Dernière modification par jyg (2012-01-24 23:40:16)

@ jean-yves : bravo !!!

Excellent, l'automation ! Pour économiser le cpu on peut désactiver son rendu pendant l’acquisition (avec un toggle sur le plot). Mais ça perd de l'intérêt dans l'exemple. Avant de te lire j'avais jamais pensé à des array en x/y pour des automations.

En plus, avec quelques routines genre pivot de Gauss on peut trier les éléments pour les avoir en x croissants dans l'array, et en récupérant des double-click à la sortie du struct c'est tout à fait envisageable d’insérer des nouveaux points. Par contre, vlà le travail bête et méchant...