Jessica Nichenin — 2013-02-19 21:24:39

Comment sauvegarder à l'interieur d'une abstraction sans mettre dans un fichier text ???

Voici mon problème
J'ai fait un Midi CC Learner sous forme d'abstraction.
J'ai fait la sauvegarde en plaçant les valeurs dans des messages.
Mais forcement cela ne peut pas marcher dans le cas de l'abstraction.

Quelqu'un aurait il une idée sachant qu'il y aurait forcement n patches.

rep — 2013-02-19 22:39:03

tu as essayé avec des :
http://codelab.fr/up/Capture-d-ecran-2013-02-19-a-22.32.09.png
?

dwan — 2013-02-19 23:58:17

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<

Jessica Nichenin — 2013-02-20 06:55:29

c'est ce que je fais mais cela doit être une abstraction donc il peut y en avoir plusieurs CC Learner dans le même patch.
Et si on utilise les messages, il n'en sauvegarde qu'une instance et pas les autres.
Je suis bon pour la sauvegarde dans un fichier texte.

albdet — 2013-02-20 09:08:09

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.

http://codelab.fr/up/Capture-d-ecran-20022013-08-58-44-1.png

pob — 2013-02-20 10:32:50

Enfin, l'idée est un peu absurde à la base, non ? :)
Une abstraction est faite pour être réutilisée, elle ne comporte donc que des paramètres fixes qui dépendent du fonctionnement de base et des entrées/arguments pour l'ajuster à chaque utilisation.
Les variables sont appelées à la création des instances de ton abstractions et peuvent être modifiées en cours d'exécution.


Comme tout le monde le propose le plus simple c'est dans le patch parent d'avoir le mécanisme au dessus.
Si ça ne te plais pas de voir cette mécanique, tu la planques le [t f f] et le [set $1( dans une abstraction. Et si ça c'est encore de trop, tu encapsules le tout dans une sous-patch.

Autre solution, tu peux te fabriquer un mécanisme qui va sauver tes paramètres dans un fichier texte. Avec pour a ligne 1 les paramètres de l'instance avec l'argument 1, à la ligne 2 les paramètres de l'instance avec l'argument 2 etc.
Mais il y aura forcément un moment où tu vas devoir dire à l'abstraction quelle sont les valeurs à prendre.


Il y a peut-être un moyen de trafiquer un truc en patch dynamique, mais, je ne suis pas certain que ce soit un bonne idée. Je vois ça plus comme une porte ouverte à des plantages. Ca voudrait dire de trouver la ligne qui correspond à l'instance de l'abstraction (bon courage) et de modifier ses paramètres dans le fichier .pd du patch parent. Mouais...

kirobatz — 2013-02-20 10:38:12

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

Jessica Nichenin — 2013-02-20 11:18:00

je vous ajoute le patch
mais comme ce patch doit rejoindre la librairie mtl et que les autres patches ne sauvegardent jamais rien, il sera comme les autres.
Merci pour vos remarques

Jessica Nichenin — 2013-02-20 11:19:10

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.

pob — 2013-02-20 12:57:49

Ca demanderait un moyen de faire une nouvelle sorte d'instanciation d'objet, au croisement des abstractions et des sous-patchs. Ca serrait de pouvoir instancier cet objet de la même façon qu'une abstraction, mais que ce soit intégré au patch de la même façon qu'un sous-patch.

dwan — 2013-02-20 13:26:58

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...

nononononono — 2013-02-23 12:24:34

justement pourquoi pas proposer mettre tout ça dans une table  dans le main avec l'option save as content, ça fait le compromis avec le fichier texte?

dwan — 2013-02-23 14:11:00

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

nononononono — 2013-02-23 14:52:36

c'est bien pour ça que je le propose...

rdc182 — 2013-02-24 06:46:50

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.

jerome — 2013-02-24 10:52:39

Le problème de la mémorisation d'un état d'un patch ou d'une abstraction est récurrent dans pd. Il ne s'agit pas d'un problème anodin puisque chacun doit le fabriquer à chaque fois. Je crois qu'il existe un objet dans max/msp qui doit le faire, si c'est le cas pd a du retard.

Peut-être que le titre n'est pas très bien formulé. Il ne s'agit pas de sauvegarder à l'intérieur d'une abstraction, car les boites de stockage, [f], [symbol], [list] le font pendant toute la vie du patch. Il s'agirait plutôt de sauvegarder l'état d'une abstraction dans le patch parent pour appeler différents états des variables de l'abstraction. Si j'ai bien compris...

En résumé, soit on utilise des techniques de mémorisation pour chaque objet à mémoriser, et si on veut ajouter un objet qui mémorise l'ensemble de ces objets, soit on peut utiliser l'introspection de patch proposé par iemguts, mais je ne sais pas si c'est compliqué.

Il y a déjà eu quelques essais avec sssad et rradical/memento, quelques infos ici : http://puredata.hurleur.com/sujet-1531- … ave-module

Sur codelab, j'avais fait deux exemples avec des fichiers et l'objet [coll] :
http://jeromeabel.net/files/code/pd/pd- … t-coll.zip
http://jeromeabel.net/files/code/pd/pd- … preset.zip

En gros, si ce sont des données hétérogènes (symbol + nombre), une liste (sssad) ou un fichier est nécessaire, si ce ne sont juste des nombres, il faudrait utiliser simplement une table longue et enregistrer dedans le nombre de valeurs désiré avec un [until].

Exemple avec une table :
http://jeromeabel.net/files/code/pd/pd- … liders.zip

oli44 — 2013-03-07 20:36:29

salut

tof/param

rdc182: je suis à Montréal cette semaine, je joue vers Beaubien vendredi et samedi soir de la danse made in Pd

Blindekinder — 2013-04-02 22:31:58

salut,
deux abstractions que j'ai écrites il y a un moment... un des moyen que j'aurais aimé implémenter dans le midi learn, c'est de contrôler dynamiquement les arguments à partir de l'abstraction, mais je ne crois pas que ce soit possible.
donc j'ai utilisé des [message box(

[raf_ctlin n m] les arguments sont le range: le 0 - 127 est transformé en n - m. ça peut évidemment être des négatif, ou aller décroissant ( n > m ). Pour le learn, il faut donc lui coller une [message box( vide entre le premier inlet et le deuxième outlet. Le premier outlet est la valeur CC. Pour apprendre, le bouton vert, puis actionner le CC voulu. Le blanc le convertit en bang (chaque passage du midi de 0 à une valeur quelconque envoie un bang, si je me souviens bien).

[raf_volume] est un volume avec midi learn. Pareil, une message box pour garder les valeurs.
[raf_volume_st] pareil en stéréo, plus un canal pour le pan
ces deux derniers ont des défauts que je n'ai jamais pris le temps de corriger: la courbe de volume et de pan ne sont pas très correct si je me souviens bien. Il faudrait la passer en log, et utiliser la loi de la tangente pour le pan. Mais pour le midi ça tourne...

si ça peut aider...