• argument humain
• pure data/ui
• plateforme web/lfo
• objets sonores
• drone/terroriste
• sélecteur motorisé de peluches (comme dans we feed the word)
• aquarium de poissons, rats, etc. comportements trackés “gentils”, “méchants”
• programmation IA embarqué pour les araignées

• PROGRAMMATION – ART (culture)
• CODE – MATIERE (physique/électronique/méca/info)
• CULTURE LIBRE
• ESPACE PUBLIC
• REALISER UN PROJET
• CONFRONTER A LA REALITE (captation, électronique, mécanique, etc.)

100h à répartir :

• 20h formation fablab (culture artistique+programmation, arduino, impression 3d, cnc-router, puredata, processing, openframeworks, …)
• 20h analyse / conception > cahier des charges / tâches / outils de développement
• 30h conception / prototypes : boucles de développement rapides > décisions
• 10h version alpha /tests grandeur nature
• 10h installation in-situ
• 10h documentation / mise au propre du code et ressources

Projet : œuvre à réaliser.

Techniques possibles : OpenFrameworks, opencv, opengl, webgl, …

• Gestion des données (parser)
• Visualisation des données
• Analyse vidéo (tracking)
• Commandes de motorisation

Pure Data : écrit en C, client/serveur, temps-réel. La bibliothèque graphique est tcl/tk, multiplateforme mais vieillissante. Le but de Miller Puckette : conservation d'un patch pendant 50 ans, gérer le temps-réel.

Pure Data extended contient Pure Data et y ajoute des bibliothèques dont certaines sont indispensables. C'est celui que l'on utilise.

Libpd est écrit par Peter Brinkmann et permet de réutiliser des composents préexistants (patch) au sein de n'importe quelle application, notamment écrite en : Java, CSharp, Objective C, Cplusplus, Python. Existe pour mobiles : pd-for-android, pd-for-ios.

L'ergonomie de Pure Data pose problème (voir les inconvénients de Pd) :

• Tcl/Tk est peu performant pour gérer le GUI, fortes latences et des bugs surviennent à cause de cela.
• de nombreuses fonctionnalités classiques n'y sont pas
• le processus de développement est lent et pénible, des développeurs abandonnent, d'autres proposent des forks car le constat est le même depuis au moins 2006.

En gras, les priorités “faisables”

• Multiplateforme
• Libre et Open Source
• Gui rapide : séparation du moteur et de l'interface graphique (voir les propositions). Notion de graphe audio (dsp tree). Parfois on utilise deux instances de Pd…
• Une fenêtre avec des panneaux plutôt que du multifenêtre partout…
• Presets, mémorisation de l'état des objets
• Survol : description des objets
• Undos
• Plus d'options pour les gui
• Scroll dans les sous objets et abstractions
• Fenêtre de preview vidéo gem integré dans le patch
• Lecture vidéo + son
• Piano roll et automation dans le temps sous forme de courbes…
• Zoom
• Agrandir les rectangles entrées/sorties
• Importer en svg, exporter en pdf, png
• Standalone ?
• Menu avec Icones, intégration facile des images dans les objets (zoom !)
• Connections facile 1 objet à plusieurs etc.
• Enregistrement vidéo, multi écrans

Voir aussi quelques exemples recensés ici

• Osbolètes : ZenGarden, desiredata, vibrez_pure
• pd2lork : vidéos
• libpd/interface html5
• Blender http://wiki.blender.org/index.php/Doc:2.6/Manual/Interface
• Max msp (Juce Framework) …
• Qt/tcl/gtk++
• …

Voir http://reso-nance.org/wiki/projets/plateforme-lfo/