Ouaip, un message à l'extérieur de l'abstraction, que tu remplis à coups de [set< et que tu charges avec un bang au chargement, ça devrait le faire...

[abstraction]x[settings<

ce dont te parlent dwan et rep, il me semble, c'est de mettre les messages qui conservent les paramètres à l'extérieur de l'abstraction.

Et pourquoi pas mettre ce que tu as à sauvegarder en argument de tes abstractions ?

kirobatz a écrit:

Et pourquoi pas mettre ce que tu as à sauvegarder en argument de tes abstractions ?

parce que mon midi learner apprend les paramètres midi après l'instanciation de l'abstraction.

C'est sûr que si à chaque fois que tu appelles ton abstraction, tu es obligé d'y rajouter un message ([abs]x[parametres<), c'est un peu relou. Par contre, s'il ne faut le faire qu'une seule fois pour toutes les abstractions, c'est mieux !
On peut imaginer une abstraction en deux parties : une qui fait effectivement le job ([midilearn 1 toto], envoyant ses paramètres via un [send toto]) et que tu déploies en plusieurs exemplaires, et l'autre qui reçoit les réglages de toutes les précédentes via un [receive toto], qui les stocke (dans un message ou un fichier texte, ou avec un [msgfile] ou autre liste indexée) et peut les renvoyer à la demande.
Sinon, il y a sssad...

Dernière modification par dwan (2013-02-20 13:27:34)

Ouaip, effectivement. Ça marche bien si tu rentres pas de paramètres exotiques comme du texte ou autre.

Je suis nouveau sur le forum, donc un p'tit s'lut à tous pour commencer!

Je suis un peu rouillé sur pd, car j'ai passé les dernières années sur SuperCollider. Je suis de retour sur pd pour un bon moment et quoi de mieux que faire un peu de support pour se rafraichir les idées et se perfectionner.

J'ai regardé le patch et j'ai un peu de difficulté à saisir l'idée derrière l'ensemble. Par contre, pour aller dans le même sens que Pod, je dirai que pour être de bonne qualité, il est certain qu'une abstraction doit être autonome et j'ajouterais même que dépendre d'un objet en dehors de l'extended tel que le /mtl/sign n'est pas très prope.

Si le patch a besoin de paramètres initiaux un loadbang ou initbang devrait suffire dans la majorité des cas. L'idée sus-mentionée de la table est également utilisé dans plusieurs circonstances. Un fichier texte indépendant entraîne des risques de dépendances non résolues et je le conseillerais que dans certains cas spéciaux. Personnellement, dans l'état actuel du projet, j'en profiterais pour repartir de zéro. C'est ce que je fais régulièrement, car cela me permet de reprendre la démarche tout en améliorant la propeté du code avant de sombrer dans un délir de fils qui devient très ennuyant à nettoyer dans un projet d'envergure.

D'autre part, l'idée d'un MIDI-learner me plaît bien, je dirais même qu'une suite d'outils pour l'apprentissage du MIDI pourrait s'avérer très intérressante pour moi qui devra enseigner pd dans un proche avenir. C'est un fait que pour une personne provenant d'un logiciel avec séquenceur et pianoroll intégrés ce n'est pas évident d'aborder le séquencage et le MIDI sous pd. De plus, chez les compositeurs de musique expérimentale on évite généralement la norme MIDI ce qui complique encore les choses. Bref, sujet très intéressant à développer.