La solution la plus simple. Patch joint.
Sinon il faut éditer des fichiers textes avec des index ( lignes numérotées ).
Personnellement, je ne m'y suis jamais collé.

Effectivement, ça marche bien , mais peut-être plus pénible à éditer rapidement.
à coup de $1 $2 $3 $4 $5 ...

Dernière modification par albdet (2013-02-21 00:29:27)

Merci pour les réponses. Il y a quelque chose d'intéressant dans toutes. Mais je me suis surtout inspiré de la première :

dwan a écrit:

Regarde du côté de sssad : http://puredata.info/downloads/sssad
Mais vu que tu as l'air de galérer en anglais, ça va pas être facile.

sssad est vraiment compliqué comme abstraction, Impossible de comprendre comment elle fonctionne, mais avant de tenter de l'utiliser j'ai essayer de comprendre, et en la regardant je me suis dis que dans un premier temps des objets comme [textfile] et consoeurs suffiraient peut-être.

Je n'ai pas réussi à comprendre la différence entre [textfile] et [qlist], mais j'ai compris que ces objets permettent d'écrire un fichier texte sur le disque, et c'est ce qui m'a fait retenir cette solution.

Enregistrer les paramètres en même temps que le patch est intéressant même si ça ne marche que pour une configuration, et je ne savais pas le faire, mais le but étant de pouvoir enregistrer beaucoup de configurations, même si dans un premier temps je me contente de sauver une seule configuration, pour que ce soit utile il faut vraiment qu'elle soit dans un fichier séparé. Dans un second temps, et le plus souvent, ces configurations devraient être calculées par un programme écrit en C.

Comme je suis pas trop fort côté programmation j'aurai peut-être du mal à programmer le son (j'ai déjà du mal à ouvrir une fenêtre graphique pour envoyer des résultats ailleurs que sur le terminal), alors si je peux me contenter d'écrire dans des fichiers lisible par un patch PureData, il se pourrait que ça supprime une partie du problème dès le départ.

Pour l'instant, là où j'en suis c'est que je peux enregistrer ou lire sur le disque, mais une fois récupérer ce qui est sur le disque je peux seulement l'envoyer sur la console de PureData, je parviens pas à le récupérer ailleurs.
Ça ressemble à ça :



Lorsqu'on vient de rentrer des données le |print( permet de les envoyer sur la console, et, pour autant que j'ai pu comprendre, le |bang( permet de les envoyer par les sorties de [textfile], à gauche tant que la liste n'est pas fini, à droite dès qu'elle est fini (et alors ce qui sort est un bang).

Le problème c'est que lorsque le fichier vient d'être chargé il n'y a que le |print( qui marche, le |bang( ne prend pas la liste au début mais probablement à la fin, et il envoie directement un bang.

J'espère avoir bien expliqué le problème et je sais pas si quelqu'un verra une solution. A tout hasard j'envoie le patch en pièce-jointe.

et pour sortir du print dans la console tu peux utiliser l'objet [route].

Pour textfile et qlist la différence est dans les messages d'entrée, le qlist permet entre autre de gérer le tempo.

c'est quoi ce truc ?!!!!!! absurde ! ou lutôt drôle .....
je t'ai mis une ransformation radicale de ton patache... autrement pour le [coll] of course, save en dur dans fichier, en plus à chaque ligne tu peux choisir ton rang idéal pour save ou tu dois pour chaque instrument avoir plusieurs états... mais bon tu paraissais si sûr de toi...


et aussi pour tes séries : pd est quand même hyper-orientée objet : donc un moteur d'envoi et ensuite un abstract (donc un objet) avec une incrémentation par variable)..... pas plus digest que cela... Il y a que deux process à patcher.

Dernière modification par philippe boisnard (2013-02-24 20:05:12)

Bah! Ne tiens pas rigeur des exclamations de philippe, ce n'est que l'effet de surprise. Moi aussi en voyant ton code j'ai réagis de même, mais avec un accent québécois : "C koi s'tosti d'affaire là".

Bref, pas mal du tout le [flush( sur [msgfile]. Ça simplifie grandement le routage comparativement à un textfile.

lionmarron a écrit:

Peut-être pas. Le fait est que je me suis trompé en disant que je voulais sauver des nombres de 0 à 11 (c'était de 0 à 29). Cela étant ce qu'il s'agit de faire est simple, et il n'y aura pas de nombre plus grand que 29, donc (au cas où ce serait ce que tu voulais dire) je crois pas utile d'enregistrer les numéros de lignes dans un tel cas.

C'est un peu confus ton projet. Perso, je n'ai pas réussi définir ce que tu essais de programmer comme outil? Un synthé, un séquenceur, un MIDI controller pad, etc?

Pour les problèmes avec ton patch, tu crées un nouveau dossier nommé ugly_code et tu y mets ton patch avec la mention ne pas ouvrir avant le 1 janvier 2025. 

Blague à part, la solution avec le msgfile me semble interressante à explorer, je ne connaissais pas. Pour la gestion des presets et le routage avec textfile je t'ai trouvé un site qui détail assez bien la procédure. En anglais malheuresement, mais le patch preset-manager.pd parle de lui-même.
http://gregsurges.com/programming/prese … -pure-data

Merci pour les détails de ton projet. Ton terme MIDI Key expirimentor donne un bon aperçu de l'idée générale.

Concernant le terme presets. À la base la meilleure traduction en français serait probablement "configuration d'usine". Dans la pratique le terme presets peut effectivement prendre plusieurs formes. Habituellement, c'est produit le final qui permet de se faire une idée du système. Dans l'état actuelle de ton projet le terme "paramètres" est très bien, il s'agit simplement de bien définir la chose. Un bon truc c'est regrouper les divers paramètres en ensembles cohérents. Par exemple, les paramètres du synthé, les paramètres du séquenceur, les paramètes MIDI, etc.

lionmarron a écrit:

Sinon je voudrais faire quelque chose qui fonctionne à partir d'un code texte, c'est-à-dire la façon de Lilypond plutôt qu'à la façon de PureData (mais qui serait pour le reste à peu près à l'opposé de Lylipond, sinon j'aurais écrit "plutôt qu'à la façon de Finale ou de Sibélius"). Evidemment ça sera pas non plus aussi sophistiqué.

Pour bien cadrer la discussion, l'expression "faire quelque chose" n'est pas très explicite. Ici on parle sans doute de la manière de séquencer ce qui n'a rien à voir avec la sauvegarde des paramètres bien qu'une partition (fichier) peut agir sur les paramètres. Donc, Lylipond c'est surtout adapté pour le rendu graphique de partition, mais je comprend ton idée. Les objets textfile et qlist de puredata sont avant tout conçu pour séquencer. Étant un simple format txt tu es complètement libre d'organiser le format à ton goût.

Pour "ugly code" ça se traduit très mal en français, mais habituellement ça ressemble au genre "c'est quoi ce truc ?!!!!!! absurde ! ou lutôt drôle ....."

En terminant, si la question de sauvegarde des paramètres te semble pas très claire pour le moment, tu peux très bien utiliser
temporairement la technique présenté par dwan dans le patch exemple-sauvegarde.pd Ça peut te permettre d'avancer sur les autres fonctions pour mieux revenir sur la question de sauvegarde plus tard.

Dernière modification par rdc182 (2013-02-25 09:38:44)