Merci pour ces remarques. J'ai ajouté les triggers. En revanche je ne sais pas encore si ça marche mieux car entre temps un autre problème est survenu. Il n'est surement pas lié au précédent mais je suppose qu'il risque d'être plus difficile à résoudre (le midi ne marche plus).

Normal !
Si tu suis ce qui arrive de ton inlet :
Première branche : [% 12] puis entrée froide du [- ]
Seconde branche : [% 12] puis [outlet]
Troisième branche : [% 12] puis [select] puis [12_15] puis entrée chaude puis froide de [pow] puis entrée chaude du [* ] (alors que tu n'as rien mis de nouveau dans l'entrée froide, puisque le [- ] du dessus n'a encore rien envoyé, c'est certainement là ton problème) puis [outlet]
Dernière branche : entrée chaude du [- ], puis entrée froide du [* ]

pob a écrit:

Moi j'inverserai les deux fils qui arrivent sur [* ].

Génial.

Avec le message de dawn j'avais compris le problème, mais je voyais vraiment pas la solution.

Donc merci pour les deux messages.

Entre les deux messages il m'est venu une autre question sur le sujet : si j'ai bien compris (pour une abstraction comme pour un objet) les outlet envoient leurs données de droite à gauche. A priori je suppose que cet ordre d'envoie est géré automatiquement par le programme (mais sinon il me semble que mon abstraction devrait continuer à être fautive).

pob a écrit:

http://fr.flossmanuals.net/puredata/ch018_le-flot-de-donnees

Et c'est en français...

Ma réponse est tardive, mais merci pour la piqûre de rappel.

J'avais plus ou moins déjà lu ce passage, puisque j'ai tenté de commencer avec ce manuel. Honnêtement je ne considère pas qu'il s'agisse d'un bon manuel pour débutants. Trop peu explicite pour être compréhensible lors d'une première lecture (trop dépourvu d'exemples par exemple). Quant à l'utilité d'une deuxième lecture, a priori je vois pas trop non plus. J'ai pu comprendre le passage cité mais j'aurais difficilement pu le retrouver seul (même si le contraire est théoriquement possible). Donc un manuel malgré lequel je n'aurais pas pu démarrer sans être aider sur ce forum.

Il est vrai que même avec un bon manuel, sans être aidé en général on n'arrive même pas à configurer un logiciel. Alors comme sans ça je n'aurais peut-être pas osé commencer, finalement pourquoi pas.

Voilà à quoi ressemble mon abstraction maintenant :



(Il en faudrait plus pour me vexer, mais j'espère qu'on va pas me dire qu'il aurait fallu mettre des trigger aux inlet de droites par exemple.)

dwan a écrit:

Pour un objet, habituellement oui : pour une abstraction, pas forcément. Et même pour un objet, ça dépend de ce qui sort des outlets : la gauche peut sortir un float en continu, et la droite uniquement un bang de temps en temps. les deux ne seront pas forcément synchrones et ordonnés.

A bien y réfléchir, le contraire serait illogique effectivement.

dwan a écrit:

Quant à diagnostiquer un patch via capture d'écran, il y a des limites...

Sûrement. En fait une question que je me pose :

Ne serait-il pas parfois plus simple d'utiliser un langage de programmation écrit. La programmation graphique avec  des fils a des avantages de lisibilité dans beaucoup de cas, mais peut-être pas dans tous, et, parfois, elle risque peut-être d'être plus répétitive ou plus longue.

J'ai une abstraction qui fait ça par exemple :



On ne voit pas tout mais on peut comprendre que ce qu'il s'agit de faire est visiblement simple, alors qu'il faut assez longtemps pour le dessiner. Et les modifications risquent d'être plus fastidieuses que s'il s'agissait de reprendre du code.

dwan a écrit:

Là ça me paraît évident, tu as un schéma qui se répète : inlet suivie d'un select auquel sont accrochés 15 messages. Chaque grappe commence à une note midi (je pense que c'en est une) de la forme x*10+2 et se termine à x*10+2+14.

Ce sont pas des notes midi non. De même qu'une note midi se distingue de la précédente par un intervalle d'un 12e d'octave, ici ce sont des intervalles d'un 118e d'octave qui sont numérotés. Et comme 118intervalles / 12touches ne tombe pas juste, ce qu'il s'agit de faire n'est pas aussi régulier qu'il ne semble sur la partie de fenêtre capturée. Il n'y a pas toujours 15 messages par exemple (parfois 16).

Voilà une capture d'écran du patch principal :



Je sais pas si on peut comprendre facilement ce que fait ce patch. Pour moi c'est évident (mais il y a environs 30 ans que j'ai envisagé de diviser l'octave en 118 parties égales, alors je sais pas si le fait que ce soit évident pour moi signifiera que ce soit évident pour tout le monde).

La présentation est assez "spider" mais j'ai compris seulement hier comment réaliser des connections sans fils (et j'ai pas trop envi de le modifier pour ça).

Le problème vient plutôt du fait que nous sommes encore très loin de ce que je voudrais faire (il s'agit donc d'un essai pas forcément représentatif). C'est à dire quelque chose qui produise à la fois une partition d'un style non classique, et le code midi correspondant.

Dernière modification par lionmarron (2013-02-08 15:55:12)

Juste au cas où, je confirme que ce que propose Dwan est on ne peut plus rationnel par rapport au patch de l'image 12-15.png

Concernant...

citation :

Ne serait-il pas parfois plus simple d'utiliser un langage de programmation écrit.

... tout à fait, PureData est un outils parmi d'autres pour arriver à ses fins.
Par ailleurs, il existe un moyen de tisser des patchs automatiquement (si tu as besoin de 1600 abstractions avec des arguments différents, il ne serait pas très raisonnable de les créer "à la main").
Cela s'appelle le patchage dynamique, mais il est important d'avoir certaines bases pour s'y pencher...

Bon courage...