Un réseau social distribué, c’est à dire décentralisé et interopérable.
Illustrations par Eugen Rochko
Décentralisé : Chaque serveur Mastodon est
totalement indépendant, mais capable d’interagir avec les autres pour
former un réseau social mondial.
Interopérable : Basé sur des protocoles web ouverts, Mastodon peut communiquer avec n’importe quelle autre plateforme qui implémente ActivityPub. Avec un seul compte, vous avez accès à tout un univers de médias sociaux — le Fédiverse.
Chaque serveur a ses propres règles, de contenus, de modérations etc. Choisissez celui qui vous convient le mieux : https://joinmastodon.org/fr/servers
La résidence SONOPTIC, dont nous avons fourni un compte-rendu ici pour les aspects collaboratifs, a été une période de production assez intense pour la Teamlaser composée de membres du Fuz et du /tmp/lab. Nous allons exposer ce travail afin que toutes et tous puissent profiter des outils que nous produisons via liens et explications.
La résidence SONOPTIC, dont nous avons fourni un compte-rendu ici pour les aspects collaboratifs, a été une période de production assez intense pour la Teamlaser composée de membres du Fuz et du /tmp/lab.
Nous allons exposer ce travail afin que toutes et tous puissent profiter des outils que nous produisons via liens et explications.
Si vous ne connaissez pas la brique logicielle centrale de notre système nommée LJ, lisez plus bas la note qui le concerne sans quoi vous risquez de ne pas comprendre certaines informations qui vont suivre.
Cette partie est un peu hardue mais nécessaire. Afin de piloter les lasers via du logiciel libre, nous avons besoin de toutes sortes d’utilitaires et de processus résidents, voici ceux sur lesquels nous avons travaillé dans le cadre de SONOPTIC.
Mise au point d’un système de génération de programmes utilisant les pipes UNIX
Présentée simplement, cette solution permet de produire des lignes de commande comme ceci :
L’exporteur envoie ainsi dans la base Redis (cas le plus courant) les données générées par le generateur puis passées par les différents filtres.
Cela est possible grâce aux pipes UNIX, les "|" qui se trouvent entre les programmes. Ce sont des opérateurs en ligne de commande qui transfèrent au programme suivant la sortie standard du programme précédent. Ainsi, le générateur produit une liste de point qui passe de filtre en filtre avant d’être exportée sur le réseau.
Cette solution offre plusieurs avantages :
elle simplifie la démarche de création de programmes pour LJ : on peut utiliser toutes sortes de programmes et de langages pour générer des tracés, tant qu’ils ont une sortie (output, fichier, osc, etc.)
elle offre une grande capacité d’adaptation et de variation : on peut passer les génerateurs dans toutes sortes de filtres.
Cette solution a été particulièrement utile lors de la résidence pour prototyper rapidement des programmes.
Mise au point d’un système de transmission des spectogrammes et informations de tempo temps réel
Afin d’avoir une réactivité aux environnements sonores, nous avons développé un logiciel qui effectue des analyses temps réel ensuite envoyées au server redis central. Ce qui permet à plusieurs générateurs de points d’utiliser une source commune d’analyse.
Originalement développée en python2, elle est devenue complexe à compiler sur Debian et nous allons la convertir en python3.
Cette solution a été particulièrement utile durant SONOPTIC, notammment pour les systèmes de particules.
Il y a une grande différence ce qu’on envoie aux lasers et ce que dessinent ces derniers : leurs moteurs (galvanomètres) sont très rapides et ont en particulier tendance à “arrondir les angles” si on ne force pas leur dessin.
Ce travail a abouti à un filtre permettant effectivement d’optimiser les points d’un tracé, ce qui impliquait de supprimer l’optimiseur existant de LJ sous peine d’avoir une trop grande quantité de points. Un travail intéressant mais que nous devons benchmarker et intégrer dans LJ pour qu’il soit vraiment utile.
Mise à disposition du logiciel LJ sous forme de VM
LJ est un logiciel avec de nombreuses dépendances, prévues pour installer sur une distribution debian.
Nous avons donc entrepris de le fournir sous la forme de machines virtuelles via Packer. Pour le moment, seule une image KVM est disponible mais d’autres pourraient être déployées à terme permettant de tester le logiciel sur différentes plateformes.
La nécessité de ces images n’a pas fait ses preuves durant la résidence, entre processeurs ne supportant pas la virtualisation et personne préférant simplement utiliser le script d’installation standard.
Les pistes créatives poursuivies durant la résidence
En partant en résidence, les idées ne manquent pas. Voici celles que nous avons effectivement exploitées sur place.
Création d’un générateur de points basé sur les trames OSC et UDP
En utilisant des protocoles temps réel assez répandus et en les passant dans notre chaîne de traitement à base de pipes UNIX, nous avons pu recevoir des participations externes décidées sur place.
Ce type de receveurs de flux est très intéressant et montre la capacité de LJ à s’interfacer avec des sources hétérogènes.
Création d’un jeu en Rust avec contrôle par joystick
La création d’un jeu codé avec le langage Rust était l’objectif d’une partie de l’équipe, qui a recodé un moteur physique simple pour créer un jeu de plateforme interfacé à LJ via un exporteur en pipe UNIX.
Création d’un générateur de points utilisant une interface de détection de mouvements
Un membre de l’équipe a travaillé sur l’exploitation dans un cadre laser d’une double caméra infrarouge capable de reconnaître les mouvements de la main. Associé à une génération de particules, ce générateur a pu être utilisé en live.
Création de programmes de tracés utilisant l’analyse de spectrogrammes
Plusieurs programmes basés sur les analyses spectrographiques ont été développés. Les formes simples, comme un spectrogramme défilant, ont rapidement été jugées insuffisantes. Un système de particules plus complexe et plus réactif a été jugé beaucoup plus intéressant par le public.
Application d’un programme de simulation de particules moléculaires
Une chercheuse en biologie moléculaire qui utilise le logiciel Netlogo pour ses représentations spatiales a sorti en mode texte des simulations qu’elle a envoyé sur les lasers.
Création d’un pilotage de playlists laser via le clavier
L’utilisation des programmes en ligne de commande est peu pratique dans le cadre d’une performance live : interrompre le programme, changer la ligne de commandes, corriger les erreurs de frappe éventuelles…
Pour changer rapidement de programmes, un programme pour piloter une “playlist” dans un terminal a été produit. Il permet de créer / éditer / sauver une playlist de commandes et autres usages pratiques liés à une performance live.
Ce programme a été fort utile lors des restitutions, offrant plus de réactivité et de contrôle rapide des lasers.
Utilisation du logiciel OpenFrameworks pour piloter les lasers
Une personne a fait des tests concluants de pilotage des lasers directement via un plugin du logiciel openFrameworks connu pour simplifier l’interconnexion avec toutes sortes de périphériques, environnemens 3D, etc.
Quelques recherches visuelles avaient été faites pour explorer des visuels filaires fonctionnant en 3D anaglyphique (lunettes colorées). Un filtre a été produit à cet effet mais les résultats sont peu probants.
N’ayant qu’un temps limité, nous avons du faire des choix. Voici les pistes qui n’ont pas été suivies.
Utilisation à distance de synthés nozoid via une interface en ligne
Une interface en ligne a été produite pour les synthétiseurs nozoids que nous avions utilisés lors de précédents festivals. Nous n’avons pas eu le temps de faire de live à distance durant la résidence.
Création d’un générateur de points utilisant de la reconnaissance vidéos temps réel
Pouvoir tracer en temps réel un flux vidéo était un de nos objectifs. Après avoir identifié la librairie pypotrace qui pilote potrace pour reconnaître des segments dans une image en noir et blanc, nous avons essayé de lire des images vidéo depuis ffmpeg, puis depuis opencv mais dans les deux cas le débit était trop lent pour être satisfaisant pour du temps réel.
Gestion d’une platine en USB pour simuler des scratchs laser
L’idée étant de “scratcher du visuel” nous avions apporté une platine DJ en USB mais malheureusement celle ci ne disposait pas d’une connexion USBMidi fiable et le projet a été remis à plus tard, le temps de trouver un périphérique fonctionnel.
Affichage de textes élaborés sur place
Nous avions dans l’idée de diffuser des textes avec les lasers, mais avons abandonné l’idée par manque de temps et par souci d’adéquation avec les pièces acousmatiques diffusées qui ne se prêtaient pas nécessairement à ce type de visuels.
Utilisation des données de spectogrammes dans les jeux vidéos pour réagir à la musique
Par manque de temps nous n’avons pas eu l’occasion d’implémenter au jeu vidéo les événements audio.
Création de générateurs de points et de filtres utilisant l’analyse de tempo
Bien que partiellement implémentée dans un filtre nous n’avons pas utilisé cette possibilité qui aurait été utile si nous avions joué sur des musiques plus rythmées.
Association vidéoprojections et lasers
Cette piste était transversale à d’autres (reconnaissance vidéo / shaders) mais nous ous n’avons eu ni le temps ni les moyens techniques de l’exploiter.
D’autres idées ont émergé lors de la résidence
Idées venues en discutant et en observant les résultats de nos expérimentations lors de la résidence.
Idées créatives
Utilisation de micros répartis dans l’acousmonium pour avoir chacun son analyse de spectre
L’idée générale étant d’initier de nouvelles expériences avec l’acousmonium de Module Étrange, nous avons réfléchi à comment spatialiser l’analyse audio pour répondre aux évolutions sonores visuellement.
Une des pistes serait d’utiliser plusieurs sources de captation pour la spectrogrammétrie : au moins quatre micros répartis dans l’espace.
Création de paysages visuels associés à l’acousmonium
Simultanément à une meilleure détection spatiale des événements sonores survenant dans un acousmonium, il nous a semblé intéressant de réfléchir à une proposition graphique où les lasers seraient projetés sur différents “écrans” également spatialisés.
Création de nouveaux filtres : optimisation spatiale des formes
Certains des programmes conçus sur place ne s’affichaient pas en “plein écran” avec les lasers. Un simple programme qui redimensionnerait automatiquement ce qui lui est envoyé pourrait être utile.
Création de nouveaux générateur à base de particules
Les générateurs de particules sont intéressants sur les plans graphiques et conceptuels. Nous avons eu plusieurs idées pour en produire : simulation de partages ADN, comportements mutualisés, paramètres modifiables en temps réel.
Partage des points, attracteurs, et répulseurs entre plusieurs générateurs
La génération de particule utilise fréquemment des objets invisibles qui attirent et/ou repoussent les particules. Il serait intéressant que différents programmes puissent partager ces objets pour faire interagir leur production.
Utilisation d’un “Director Pattern” pour gérer les événements à envoyer aux lasers
Les systèmes de générations de particules sont “passivement réactifs” : ils n’ont pas de conscience de leur agitation et du spectacle qu’ils produisent. Importer le concept de directeur utilisé en intelligence artificielle pour les jeux vidéo permettrait de mieux gérer la tension dramatique des programmes, par exemple en modifiant lui même les paramètres des générateurs de particules pour augmenter / réduire leurs paramètres, ou les (dés)activer.
Utilisation d’appareils USB à touches / sliders / potentiomètres pour modifier les programmes envoyés aux lasers
Nous allons certainement continuer à expérimenter les dispositifs tactiles permettant de contrôler en temps réel les programmes de génération de particules. Ce qui nous permettrait d’activer/désactiver des comportements, ou d’en modifier les caractériques.
Utilisation de Machine Learning / DNN pour générer des textes lus dans les pièces acousmatiques
Il pourrait être intéressant dans le cadre d’une collaboration avec des diffusions acousmatiques d’utiliser les recherches contemporaines menées dans le domaine de réseaux neuronaux avec apprentissage profond et le traitement de la voix. Ceci permettrait de générer des textes visualisables et “lus” par des interprètes synthétiques.
Reconnaissance et mise a disposition des elements d’un visage analysé sur smartphone en temps reel
Nous disposons d’une librairie qui Utilise la reconnaissance faciale et permet d’envoyer les points d’un visage aux lasers. Il reste à déterminer dans quel cadre cette génération de points serait pertinente.
Création d’un programme adapté à une perfomance scénique utilisant la lumière (jonglage, prestidigidation, cirque)
Traduire et retranscrire en temps réel un spectacle vivant en jouant sur les ressorts de la lumière et de l’ombre pourrait être une idée intéressante, sous réserve de trouver des artistes intéressé.e.s par la démarche.
Utilisation d’algorithmes audionumériques pour les analyses de spectrogrammétrie et les programmes de génération de points
Dans le domaine des différents types d’analyse spectrogrammétriques. Nous utilisons essentiellement la Transformée de Fourier pour l’analyse spectrale, mais il existe aussi entre autres :
Analyse du son non Fourier
Analyse par banque de filtres à Q constant
Analyse par ondelettes
Analyse du signal par distribution de Wigner
Analyse spectrale par autorégression
Dans le domaine des filtres audio numériques. Par exemple implémenter des phénomènes de réverbération, de passe haut / passe bas, de délai, etc.
Amélioration de la partie détection de tempo
Cette partie pourrait être très intéressante dans le cadre d’une collaboration avec des musiciens électro. Pour l’instant la logique et son implémentation est trop naïve. Nous pourrions utiliser des standards existants ou développer notre propre formule en la perfectionnant.
Technique
Analyse du code et des solutions utilisées par OpenLase pour le tracé des points et la vidéo temps réel
La solution OpenLase / Github qui dispose de bindings python semble atteindre des performances intéressantes dans différents domaines. Il serait judicieux de mener une analyse pour comprendre de quels processus nous pourrions nous inspirer.
Solutions d’optimisation des points afin d’améliorer le tracé
L’optimisation des tracés est un processus clé pour les lasers : trop de points et le tracé ralentit, pas assez et il devient imprécis. C’est l’objet de plusieurs recherches académiques et de diverses implémentations qu’il faudrait intégrer au mieux dans le système.
Creer un exporteur TCP en plus de celui via UDP
Afin de favoriser les lives à distance, un exporteur en TCP pourrait améliorer la qualité du transport pour les collaborations sur Internet.
Creer un exporteur vers le simulateur web
Le simulateur web nous permet de prévisualiser ce qui sera envoyé au laser. Une solution envoyant les listes de points dans une page html locale via websocket sans avoir besoin d’installer LJ serait intéressante.
Intégrer une synchronisation via des timecodes réseaux
La synchronisation de vidéos et de musiques est possible via des solutions de timecode comme MTC et SMPTE. L’idée serait de généraliser cette synchronisation dans les programmes laser, par exemple en utilisant le projet timecode generator disponible sur
Rappel : le logiciel LJ
Voici donc un point sur le logiciel LJ qui se trouve au coeur de notre système.
LJ est notre outil de pilotage des lasers. Il démarre des services qui s’interfacent entre les clients qui generent des points et le hardware (tracé par les lasers) :
Un serveur de websocket communiquant avec des pages web (voir plus loin)
Un serveur OSC proposant également l’interaction avec l’ensemble des fonctions disponibles
Une interface vers differentes synchronisations : Artnet, midi, Link.
Les tracers qui envoient les informations aux lasers (via etherdream)
Un gestionnaire qui relaie les informations entre les composants
L’un des nombreux avantages de LJ est son interface web qui permet de changer en temps réel les paramètres des lasers pilotés (taille, position, nombre de points par seconde, intensité, etc.) mais aussi de simuler les points qui sont envoyés au laser via un canvas HTML5.
Un aspect fondamental de LJ est l’ouverture à de nombreux protocoles, notamment pour recevoir les listes de points à tracer et le partage d’informations en temps réel. À cet effet, LJ utilise la base de données clef/valeur REDIS pour stocker les points qui seront envoyés.
Une note au sujet des licences : l’auteur original de LJ n’est pas un fan de licences et avait choisi une licence Creative Commons, malheureusement déconseillée pour les projets logiciels. Une discussion interne est en cours pour décider de la meilleure licence pour le projet (GPL copyleft ou MIT/Apache).
Discover how to install bots for Matrix, a fun and exciting federated protocol
Matrix is a fun and exciting federated protocol that we’re using more and more at /tmp/lab.
If you want to join the discussion, head to our riot channel and check it out!
Riot is a well-known web GUI for the Matrix protocol which could be defined as “a chat interface between IRC and Slack”. It’s cooler than IRC to some extend – backlogging is easier- and it is free software, not like Slack 🙂 Still, IRC, Slack and Riot have in common a capacity to use bots, and that’s what we’ll be drilling today: Matrix bots. Onward, my mechanical steed!
Note: Our privacy-aware assistance might interject here with some well founded critics of the Matrix ecosystem, which is not free enough as of now. Find here a list of concerns as a github issue tracker for more information.
Well, first, it’s python, which we like. Also, it’s actually well coded: Tulir Asokan -the author- did an impressive work at providing his own implementation of the matrix api which he plans to use to provide a number of bridges. It is modular, meaning that you can extend the functionnalities in a clean manner. And that leads us to hackability, writing your own plugins should be easy with maubot, more on that soon hopefuly.
Deploying Maubot on a server
Though maubot proposes a docker install, we were not fans of that for system administration reasons. So we’ve made an install script in bash you can find in this git project.
The maubot installer project
This install script should really simplify your job. Assign in the DNS a subdomain name -say botsinspace.example.com- to your server IP address and the installation should be as simple as
git clone https://git.interhacker.space/alban/maubot-installer.git
cd maubot-installer
bash install.sh
After indicating your chosen subdomain, you can go for default answers, including the matrix.org homeserver, and should be fine for the rest of this tutorial.
Et voilà ! You should have a maubot instance running with Letsencrypt on https://botsinspace.example.com
Creating your first bot
Once the maubot instance is up, understanding the maubot concepts will help you configure it.
Plugins
Plugins are the bots “brains”. They are python code and configuration files, ran in background by maubot. Ther are stored on the server as mbp files, which are archives using a zip compression.
Clients
Clients are the bots “physical presence”. They are in fact user accounts on matrix servers, no more no less.
Instances
Instances are associations of a plugin and a client. Once you have an instance, you have a bot!
Log in your maubot instance, click on the plugins “⊕” button. A big UPLOAD button (cf. screenshot) shows up, click on it, select a plugin zip file on your disk, and there you go !
The maubot plugin menu
Easy right?
Well except one thing: where do you get that zip file in the first place? From the github “Get a zip copy of the project” button of a plugin page? Well, nuhuh, nope, that won’t work. Maubot will reject that zip file. Why? The github zip file contains the file “in a directory” called “$projectname-$branch” and maubot expects files to be at the root of the zip archive. So, the right way to go is: ٭ Download a zip file from a plugin repository home page ٭ Extract it locally ٭ Enter the newly created directory ٭ Select all its files and sub-directories ٭ Create a new zip archive with these ٭ Upload that zip file to maubot.
Or if you will, plugins might available as “mbp” files in the “release” section of their github page. Sadly, they’re not always up to date, so you might be left with a manual job to do.
Option 2. Use the command line interface
Well seeing this could be a bit complex and annoying to repeat we came up with a script in the “maubot installer” project, called plugin-install.sh
You will need to use a config file or edit the variables at the beginning of the script for it to work though.
Once you’ve done it you just have to ٭ Run the script ٭ Select a plugin in the list ٭ Login (once only) with your maubot user and password ٭ And the script will call the “mbc” executable provided by maubot.
It is worth mentioning that some plugins might require a few additional dependencies. For example the trump plugin required to run an install command in the virtualenv of the project:
cd /opt/maubot
source bin/activate
pip install Pillow
But now, you should have at least one plugin available. Let’s head to the next stop.
Add a client
We won’t cover here the run-your-own-bot-factory approach, which requires running your own synapse server, in other word running your own matrix instance. So we will create an account on an existing server and retrieve its token used for interacting with the API.
We will use the default web interface https://riot.im/app and request a free matrix.org account.
The Riot.im home
You have to pick a username, for example rook_the_bot, which will provide a matrix identifier/address such as “@rook_the_bot:matrix.org” after creation.
The riot account creation interface
One your mail is validated, log in the web interface and head to the settings page to retrieve the token.
A Riot settings menu link
You will find it token at the end of the “Help & About” page: click on the <click to reveal> link, and copy the string that appears.
Riot token finally shows up!
Time to head back to your maubot instance, and click on the Client “⊕” button. Fill the requested informations : the username you created and the access token are mandatory. Validate.
The maubot client menu
And that’s it. You’re ready for the last stage.
Add an instance
Head your maubot instance and client on the Instances “⊕” button.
The maubot instance menu
Justpick a client and a plugin before validating.
And now you should have your first bot ready! Congratulations!
How to use your bot
Now if everything went well, you should be able to invite your bot in a room, using the matrix handle you created earlier, as in our example rook_the_bot@matrix.org.
Let’s say you created an “Instance” associating the dice “Plugin” to the rook_the_bot “Client” .
Once you invited rook_the_bot to your channel, simply type a !dice command. Your bot should after a while reply to you.
Each plugin has its own commands, and you can attach multiple plugins to a single client. But all commands use the front ! mark.
That’s it, have fun. And for questions or anything else… see you on matrix!
On ne présente plus le logiciel Wekan distribué sous license MIT, alternative bien connue à Trello, la référence en terme de Kanban.
Si vous avez sauté la case «Développement Agile», et que «kanban» ça ne vous dit rien, pas de souci : on vous explique.
C’est une méthode de développement on l’on prend des petits papiers qui représentent chacun une tâche. Puis on colle ces papiers dans les colonnes d’un tableau. En fonction des progrès du projet et de l’équipe, les papiers progressent de colonne en colonne, de “Todo” à “En cours” à “À tester” puis “Fini”, libre à vous de choisir le mode de tri et de circulation.
Wekan est une solution efficace pour virtualiser ce genre de tableaux. Développée avec Meteor, un framework Javascript orienté vers les applications temps réel et partagée, c’est assez fluide et rapide pour l’utilisateur et raisonnablement bien pensé en terme d’IHM comme on dit dans les écoles de développeurs sérieux, les autres diront UX.
De bonnes raisons de vouloir héberger son instance; dont acte avec https://wekan.interhack.space, une instance ouverte au public et plus précisément aux hackerspaces. Mais si l’utilisateur peut se réjouir du service, nous allons voir que côté hébergement la vie n’est pas si rose.
Nous avions déjà eu l’occasion d’auto-héberger un Wekan pour le /tmp/lab mais l’instance s’était avérée difficile à maintenir : elle plantait régulièrement et n’était pas mise à jour.
En lançant le projet nous avions donc en tête une meilleure prise en charge du monitoring et des backups, ce qui désormais nous est simplifié grâce à nos instances Proxmox, à Icinga2 et à Borgbackup.
Mais le plus difficile aura finalement été de trouver une solution d’installation qui nous satisfasse sur le plan de la sécurité et de la dette technique. Les options proposées par le projet n’avaient rien pour nous convenir. La pire est Univention dont le code n’est pas libre. Sandstorm est une solution libre (Apache) mais qui impose son environnement pour faire tourner de multiples applications dans un cadre fermé. Snap ne nous convenait pas dans le cadre de nos conteneurs LXC.
En conséquence, nous avons développé notre propre script d’installation pour Wekan qui vous permet d’auto-héberger en HTTP2/HTTPS votre instance Wekan sur Debian et qui se met toute seule à jour. Seule contrainte : utiliser une image Debian 9 Stretch, si vous voulez l’histoire complète c’est ici.
Nous aurions pu développer cette installation sous forme de script ansible mais l’expérience démontre qu’un script BASH est une solution bien plus conviviale pour des utilisateurs de tous niveaux.
Et vous noterez enfin que le code est hébergé sur l’instance git interhack car nous sommes en cours de migration depuis Github.
