Salut;
Tu peut faire un [loadbang]-->>(chemin_du_fichier_relatif_au_patch)-->>[symbol]-->>[openpannel]
Tu peux aussi enregistrer tes modifs dans un fichier texte avec[textfile],[qlist], ou bien[coll], je te laisse regarder les fichiers help pour bien comprendre...

Salut Bouclettes,

il y a énormément de solutions. Si tes fichiers ne dépassent pas une limite de quelques minutes, tu peux utiliser le sampler des mtl abstractions, basé sur les arrays de Pd, que tu charges une fois au début, éventuellement avec un rechargement au début si tu dépasses la capacité en mémoire de ta machine, et que tu peux gérer par messages OSC, midi etc. Il sauvegarde tes niveaux, les pentes etc.  Par contre, il bloque ta machine au chargement (problème inhérent à l'objet arrays de Pd).

L'autre solution, plus pragmatique, que j'utilises le plus souvent, et qui te permettrait de ne pas perdre  le travail que tu as déjà réalisé, mais simplement de le réorganiser, serait d'appliquer l'architecture MVC à savoir Modèle Vue Contrôleur, à ton patch. Concrètement, cela signifie tu écris dans plusieurs patchs les fonctionnalités que tu as ici regroupées dans un seul, et que tu les fais communiquer entre eux par netsend/OSC/midi/pots de yaourts avec une ficelle.

En premier lieu, tu auras le Modèle , qu'on pourrait appeler le Moteur, ici tout ce qui tourne autour de [readsf~] (tu devrais d'ailleurs jeter un oeil à [readanysf~] d'August Black, qui fait ce qu'il dit!).

Ensuite, tu as la partie Contrôleur. C'est là que tu vas stocker les noms des fichiers que tu veux stocker (avec ssssad, coll, txt, qlist, BDD JSON, communication avec Python etc.) et organiser ce qu'on appelle des cues, des commandes d'actions pour le ou les Modèles. C'est également là que tu traites l'interaction homme-machine, en clair, que tu décides comment interpréter des clics, des notes ou contrôleurs Midi, des signaux de fumée, la reconnaissance de forme d'une caméra infrarouge, un marqueur quelconque.

Enfin, tu as la partie Vue ou Visualisation. Chaque fois que le Modèle reçoit un cue du Contrôleur, son état interne est modifié (ou pas en cas d'échec, fichier non trouvé par ex.). Il va alors envoyer à la Visualisation une mise à jour de son état, que la Vue va refléter. Typiquement, tu vas afficher le nom du fichier en lecture, la position de la tête de lecture, si il est mode boucle, oneshot etc. Tu peux également afficher la charge processeur, le niveau de liquide de freins.

En pratique, les parties Vue et Contrôleur sont souvent imbriquées, surtout quand tu as un écran tactile ou que tu travailles à la souris, ou que tu travailles avec une Réactable. Ce qui est important, c'est d'être conscient de cette architecture et de l'implémnter au niveau du code.

Personnellement, j'ai choisi de confier ma partie Contrôleur à du matériel externe au PC, entre autres pour envoyer des cues cf le super vieux truc de coller des bouts de scotch transparent avec dessous une icône ou du texte sur les notes d'un clavier midi ou les touches d'un clavier AZERTY, avec derrière des gates pour éviter de renvoyer 2 fois le même cue. C'est assez chouette entre autres parce que tu peux trouver tes repères dans la quasi obscurité sans avoir un écran de PC qui t'oblige à faire le focus loin de la scène et qui peut t'aveugler même régler au plus bas. Et puis c'est très chiant de manipuler une souris debout, comme on l'est souvent en conduite de spectacle.

Mais ta partie Contrôleur peut également être les messages issus de la Firmata d'un Arduino, venir d'un autre PC, d'un programme comme Gamuza.

Ce genre d'architecture a beaucoup d'avantages:
* tu peux faire du pseudo multithreading surtout avec un core i7
* si tu as la discipline de t'optimiser une bonne fois pour toute ton Modèle/Moteur, tu as moins de crashes
* si tu as la discipline de t'optimiser une bonne fois pour toute ton Modèle/Moteur et sa Visualisation, pour les spectacles suivant tu ne te préoccupes que du Contôleur (gain de temps et d'énergie)
*  si tu as la discipline de toujours isoler tes modifs de code à l'intérieur d'une partie seulement, tu répares les bugs plus facilement
* cela permet d'utiliser plusieurs programmes dans la même architecture, p.ex Supercollider pour le modèle audio, Pd pour le Contrôleur et Processing pour la Vue
* cela permet d'avoir une architecture décentralisée où tu as plusieurs Contrôleurs, plusieurs Modèles qui actualisent tous différentes Vues à différents endroits physiques, cela permet de se faire des télécommandes avec libPd sur ton téléphone par exemple, pour aller régler le son en salle et pas depuis la cabine, ou faire le focus de la lumière depuis le plateau, ce qui va plus vite. En conduite, cela permet au vidéaste d'avoir son affichage perso de ce qui se passse sur la machine qui gère le son ou la lumière, sans devoir être obligé de demander en chuchotant dans le noir "Tu es à quel cue?"
* cela permet progressivement de se passer d'une techno propriétaire le temps que l'équivalent libre mûrisse. Ex: pour la vidéo, tu utilises Pd, mais pour le son tu utilises encore Live. Si tu isole Live dans un Modèle audio, avec lequel tu communiques en Midi, tu as le temps de te programmer ton Modèle audio et la vue qui va bien avec Pd qui comprendras les mêmes messages que Live. Du coup,
tu gardes le même Contrôleur, tu n'as pas à tout réorganiser.
* cela permet de frimer dans les repas en ville en annonçant que tu as une régie MCV, ou MVC, enfin je sais plus... Buvons un coup, même s'il est pas encore midi...

http://puredata.hurleur.com/sujet-1531- … ave-module


c bien fait
surtout lorsqu'on a compris !!!

Re,

du coup j'ai refait tout mon patch avec ces nouvelles infos. Oli44, j'ai essayé de partir sur cette architecture MVC mais j'ai eu du mal à saisir les limites de chaque partie, notamment entre VU et contrôle. Du coup, c'est toujours un seul et même patch.
J'y ai remplacé [readsf~] par [readanysf~] qui est vraiment très bien du fait notamment des nombreuses infos qu'il donne sur le fichier et sur les possiblités de contrôle qu'il offre (pitch, pause, etc...)
Mais après avoir essayé quelques fois le nouveau patch mon ordi s'est mis à ventiler plutôt fort, ce qui ne m'était pas habituel durant l'utilisation de Pd. Et sur certains fichiers, readanysf fait carément planter Pd laissant le ventilo fonctionner même lorsque je n'utilisais plus l'ordi (un macbook pro en l'occurence) pendant un bout de temps.
Après recherche dans le moniteur d'activité, des occurences de Pd étaient encore en fonctionnement après fermeture forcée du logiciel. Et une fois quittées, le ventilo se calme.

Avez-vous déjà eu des soucis avec readanysf~? Avez-vous une idée d'où cela peut provenir? Y a-t-il des formats de fichier, des noms de fichiers qu'il ne supporte pas?

Merci de votre aide.

bouclettes

Merci pour les infos, chouette la radio sous pure data!!
Mais le plantage persiste. Sur un fichier en particulier, un son que j'ai enregistré, pas récupéré sur internet.
C'est un son aiff, rien de particulier mais quand je le lis avec readanysf, il le lit une fois et Pd plante. Je suis obligé de le forcer à quitter et ensuite d'aller fermer l'instance de pd toujours présente dans le moniteur d'activité et qui monopolise le processeur.
Il suffit que j'ouvre ce fichier sous audacity, que je le réexporte au même format sans rien modifier et il peut être lu correctement.
Problème d'encodage? J'aimerais bien comprendre pour savoir comment éviter de planter pure data en pleine régie.

OK c'est l'impression que j'avais. Merci, au moins j'ai une petite idée d'où peuvent venir les problèmes. Et puis de toute façon, pour une régie je pourrai tester les fichiers en amont et là pas de surprises.
Par contre il va falloir que je planche un peu sur l'informatique pour pouvoir utiliser les solutions que tu m'as donné!!

Un pas de plus vers une régie opensource!!
A tout hasard je joins le patch. Je prends volontiers les conseils, les critiques.
Il n'est pas fini, certaines choses ne fonctionnent pas comme je voudrais et quelques sous patch ne sont pas achevés.
Et puis sait-on jamais, il y a peut-être quelqu'un que ça intéressera, tout ou partie.


bouclettes

un petit côté psycho-rigide en effet

l'abstraction transport sert pour les 2 voies, elle lance ou arrête la lecture d'une scène et pas seulement d'une voie. Je dois avouer que je me suis pas mal inspiré de Live.

import unauthorized ajouté! Par contre, euh..., equal_power_pan~... je serai bien incapable de te dire où il se trouve.

Pour les abstractions, tu veux dire que ça me simplifierait l'écriture du patch?

Merci pour le coup d'oeil!

bouclettes