Nerd developing at home, with the style of Nicolas de Staël, courtesy of Stable Diffusion
Working with Quasar (Vue.js based) is a bliss for Web UI / SPA / etc… development. Especially is you use Vite, for the speed of site build. I highly recommend it. Now vercel makes it super easy to host and test your app online.
Here is a little problem I encountered, so I’m sharing (so that the monster Internet search engines that swallow everything can index this little helper blog post).
Contrary to what you can find in Quasar Documentation, namely here, the vercel.json file content should not be:
(My pull request to quasar to fix this was accepted and is now fixed in their doc)
Basically it’s because you don’t know that it’s gonna be an index.html handling the traffic: it’s not. It’s the application residing at / that handles everything.
We’ve had some great talks this weekend and for once we recorded that!
Nizar Ouarti spoke about perception, natural and artificial with a nice introduction to Deep Learning.
Hedi Soula told us about a university research he participated in which aimed at recognizing amongst a group of birds every individual based on their song.
Thanks to Nizar and Hedi again for their time and kindness.
Here’s the audio + screencast recording of the talks, one after the other.
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).
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.
It’s all about CI these days: Jenkins, Buildbot, numerous SaaS service embedding these fine FLOSS and hoping for a recurring credit card based subscription,… and for a reason. Continuous Integration allow for quicker feedback, shorter dev iterations, better communication.
The principle is simple: as soon as their is a change in code, configuration, datasets, automatically retest the whole application and send automated output (and diffs from previous runs, dashboard, etc..)
Yet, Jenkins or else CI solution, everything takes time to setup. Here with this same principle of CI but with simple bash-one liner, here on Mac:
brew install fswatch
fswatch my_dev_script.py | while read a; do echo “========= Executing $a at `date +%Y%m%d-%H%M`”; $a; echo “========= Done $a”; done
Simple and Stupid right? As soon as the file is changed, fswatch (or inotifywait on Linux) will let the loop run and a new run of your code will happen. Soon enough, you’ll see that every development, no matter how small should always gets its CI.
Then you can go a bit further as when you code, you don’t necessarily always look at your terminal where CI is running. So actually you can track the runs with various metrics into a text/CSV file generated through your one-liner:
Date of run
PID (as it is often sequential)
Number of lines in your source code
Latest GIT commit hash
Number of lines in output
Number of lines matching (case insensitive) “error|warning|traceback|exception”
Input file name for your program
The sky is the limit (please pronounce with a thick Texan accent).
TL;DR if you’re lucky and everything is installed right and you don’t want to understand deeper, try:
vagrant init ubuntu/trusty64
vagrant up
First, let’s install Vagrant on the host computer (a MacOS X Mavericks here, using Homebrew Cask that can install binary install packages):
brew cask install vagrant
Then let’s create a directory where we’ll store the Vagrant related file for this host:
mkdir -p ~/dev/vagrant_trusty
cd ~/dev/vagrant_trusty
Create the shared folder
mkdir vagrant-docker
And let’s create this “Vagrantfile” file to describe our new VM in the Vagrant language:
Vagrant.configure(“2”) do |config|
config.vm.box = “trusty”
config.vm.box_url = “https://cloud-images.ubuntu.com/vagrant/trusty/trusty-server-cloudimg-amd64-juju-vagrant-disk1.box”
# we’ll forward the port 8000 from the VM to the port 8000 on the host (OS X)
config.vm.network :forwarded_port, host: 8000, guest: 8000
config.vm.synced_folder(“vagrant-docker”, “/vagrant”)
# add a bit more memory, it never hurts. It’s VM specific and we’re using Virtualbox here.
config.vm.provider :virtualbox do |vb|
vb.customize [“modifyvm”, :id, “–memory”, 2048]
end
end
Now it’s done, we can create the VM:
$ vagrant up
Bringing machine ‘default’ up with ‘virtualbox’ provider…
==> default: Box ‘trusty’ could not be found. Attempting to find and install…
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Adding box ‘trusty’ (v0) for provider: virtualbox
default: Downloading: https://cloud-images.ubuntu.com/vagrant/trusty/trusty-server-cloudimg-amd64-juju-vagrant-disk1.box
default: Progress: 0% (Rate: 1271k/s, Estimated time remaining: 0:08:32)
default: Progress: 1% (Rate: 1532k/s, Estimated time remaining: 0:07:15)
default: Progress: 41% (Rate: 1520k/s, Estimated time remaining: 0:04:10)
default: Progress: 81% (Rate: 1532k/s, Estimated time remaining: 0:01:18)
default: Progress: 84% (Rate: 1545k/s, Estimated time remaining: 0:01:06)
==> default: Successfully added box ‘trusty’ (v0) for ‘virtualbox’!
==> default: Importing base box ‘trusty’…
==> default: Matching MAC address for NAT networking…
==> default: Setting the name of the VM: vagrant_default_1407250776484_38665
==> default: Clearing any previously set forwarded ports…
==> default: Clearing any previously set network interfaces…
==> default: Preparing network interfaces based on configuration…
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports…
default: 22 => 2122 (adapter 1)
default: 80 => 6080 (adapter 1)
default: 8001 => 18123 (adapter 1)
default: 22 => 2222 (adapter 1)
==> default: Running ‘pre-boot’ VM customizations…
==> default: Booting VM…
==> default: Waiting for machine to boot. This may take a few minutes…
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying…
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM…
==> default: Configuring and enabling network interfaces…
==> default: Mounting shared folders…
default: /vagrant => /Users/user/dev/vagrant/vagrant-docker
==> default: Running provisioner: shell…
default: Running: inline script
==> default: You have not informed bzr of your Launchpad ID, and you must do this to
==> default: write to Launchpad or access private data. See “bzr help launchpad-login”.
==> default: Branched 13 revisions.
==> default: Bootstrapping Juju…
==> default: uploading tools for series [precise trusty]
==> default: Logging to /home/vagrant/.juju/local/cloud-init-output.log on remote host
==> default: Bootstrapping Juju machine agent
==> default: Starting Juju machine agent (juju-agent-vagrant-local)
==> default: Taking a nap to let state server come up…
==> default: Added charm “cs:trusty/juju-gui-3” to the environment.
==> default: Setting up Juju GUI dependencies…this may take a minute.
==> default: You can find the log in /var/log/juju-setup.log
==> default: You have not informed bzr of your Launchpad ID, and you must do this to
==> default: write to Launchpad or access private data. See “bzr help launchpad-login”.
==> default: Branched 25 revisions.
==> default: Taking a nap to let Juju Gui get setup
==> default:
==> default: Setting up transparent redirect for Juju-Gui
==> default: Redirecting localhost:80 to 10.0.3.77:80
==> default:
==> default: Executing: sudo iptables -t nat -A PREROUTING -p tcp –dport 8001 -j DNAT –to 10.0.3.77:80
==> default: Executing: sudo iptables -t nat -A POSTROUTING -j MASQUERADE
==> default:
==> default: From your browser on your hosts, you should be able to
==> default: access the GUI by going to: http://127.0.0.1:6080
==> default:
==> default: Your password is: XXXXXXXX
==> default: juju-gui start/running, process 13405
==> default: juju-gui start/running, process 13405
Watch out, your Vagrantfile is **not the only one** being used when bringing up a Vagrant box/instance.
When you get this:
~/dev/vagrant user$ vagrant reload
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 8001 is already in use
on the host machine.
To fix this, modify your current projects Vagrantfile to use another
port. Example, where ‘1234’ would be replaced by a unique host port:
Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn’t allow modifying port forwarding.
~/dev/vagrant user$
You are actually not only using the Vagrantfile from ~/dev/vagrant but also the one from your “box” distribution .box file which is typically located here:
Vagrant.configure(“2”) do |config|
# This Vagrantfile is auto-generated by ‘vagrant package’ to contain
# the MAC address of the box. Custom configuration should be placed in
# the actual ‘Vagrantfile’ in this box.
# Load include vagrant file if it exists after the auto-generated
# so it can override any of the settings
include_vagrantfile = File.expand_path(“../include/_Vagrantfile”, __FILE__)
load include_vagrantfile if File.exist?(include_vagrantfile)
So, go ahead and edit this file to remove the offending colliding forwarding port(s):
$ vagrant up
Bringing machine ‘default’ up with ‘virtualbox’ provider…
==> default: Importing base box ‘trusty’…
==> default: Matching MAC address for NAT networking…
==> default: Setting the name of the VM: vagrant_default_1401234565101_12345
==> default: Clearing any previously set forwarded ports…
==> default: Clearing any previously set network interfaces…
==> default: Preparing network interfaces based on configuration…
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports…
default: 22 => 2122 (adapter 1)
default: 80 => 6080 (adapter 1)
default: 22 => 2222 (adapter 1)
==> default: Running ‘pre-boot’ VM customizations…
==> default: Booting VM…
==> default: Waiting for machine to boot. This may take a few minutes…
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying…
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM…
==> default: Configuring and enabling network interfaces…
==> default: Mounting shared folders…
default: /vagrant => /Home/user/dev/vagrant/vagrant-docker
==> default: Running provisioner: shell…
default: Running: inline script
…
Type then:
vagrant ssh
And you will be connected.
Enjoy your Vagrant install of Ubuntu Server 14.04 LTS (Trusty Tahr).
Packaged with this Ubuntu Server 14.04 LTS (Trusty Tahr), you will get Juju and Docker pre-installed. This will enable you to connect to http://127.0.0.1:8001 to access Juju web UI.
So grepping this means you'll get plenty of matches from the data encoding image for the ICON. Chrome, it sucks.
So after exporing bookmark, you need to filter it first through some commands like:
sed 's/ICON=\"[0-9a-zA-Z\:\/\;\,\+\=\"]*//g' < ~/Documents/bookmarks_5_21_14.html > ~/Documents/nbookmarks_5_21_14.html
Oh, but why grepping? well, bookmark search sucks so hard in Chrome (it can’t search on keywords in the URL for example), that you do need to do this to be able to get along.
Why not use XML tools? Well… is it standard? NO. sed and grep are.
Bonjour à tous,
Une seconde rencontre autour de Pure Data aura lieu à la “Gaîté Lyrique”, jeudi prochain (le 20 octobre) dans le cadre des rendez-vous du tmp/lab.
Ces rencontres autour de Pure Data auront lieu désormais tous les jeudis soir vers 19h00. Elles auront pour objet de permettre l’échange des expériences, une incitation à pratiquer ensemble, les démos de projets en cours, des initiations ponctuelles sur la prise en main de l’environnement, des discutions autours de thématiques etc.
La Gaité Lyrique : 3 bis rue Papin 75003 Paris Métro : Réaumur-Sébastopol – Entrée libre…
Comme il a été précédemment annoncé, voici quelques unes des thématiques qui pourront êtres abordées :
– La synthese sonore, d’image…
– La parole, sa prosodie, son analyse, sa synthèse
– L’aléatoire, le chaos, le bruit
– Le morphing sonore : synthese croisée, vocoder, convolution…
– Les capteurs, l’interactivite, les interfaces, Arduino…
– La spatialisation sonore
– L’interaction Image <-> Son
– Pure Data et Processing
– Pure Data et Iannix
– La sonification, EEG…
nombreux langages ( C C99 strict C++ PAS gpc PAS fpc JAVA NICE JAR C# C#2 NEM ST ASM D FORT ADA BASH PERL PYTH RUBY LUA ICON PIKE PHP SCM guile SCM qobi LISP sbcl LISP clisp HASK CAML CLPS PRLG WSPC BF ICK ),
nombreux problèmes,
possibilité d’uploader ses programmes et de les valider,
A difficult issue with Rails is managing the installed gems between development and production environment.
Here is a little method i found to solve my gem comparison problems when i have a lot of different gems, let’s say between my development machine and the production environment at say DreamHost.
First I collect the installed gems on both machines:
[penguins]$ gem list –local > /tmp/dh.gem
…
devmachine:~/dev/web/ $ gem list –local > /tmp/a.gems
Then get this on the same machine (by scp) and run:
cat /tmp/*.gem | cut -d” ” -f1 | while read a; do echo $a; grep $a /tmp/*.gem; echo ; done | more
This will produce a nice diff of all gems:
$ cat /tmp/*.gem | cut -d” ” -f1 | while read a; do echo $a; grep $a /tmp/*.gem; echo ; done | more
abstract
/tmp/a.gem:abstract (1.0.0)
/tmp/dh.gem:abstract (1.0.0)
Julien Danjou will present a Workshop on Luaprogramming language at Fabelier, April 28th at 7pm . This Workshop will be hosted at “La Gaité Lyrique” (where )
Lua is a lightweight multi-paradigm programming language designed as a scripting language with extensible semantics as a primary goal. Lua has a relatively simple C API compared to other scripting languages. It’s used by World of Warcraft, the PSP, and many other projects.
A physical computing introduction will be presented by Metakinetik for the tmplab meeting at la Gaîté Lyrique, Thursday March 17th. Artist-technician Jason Cook will present basic examples using the Arduino environment and prototyping boards. Examples will include “hello world,” analog light and motor control using PWM, and use of analog sensors. Examples of artists and technicians currently working with the Arduino technology will be discussed. Where and how to acquire required materials will be addressed. Based on the response of participants materials will be suggested for a continuation of the workshop in the weeks to come. Amateurs and experts are equally welcome. Individual or group propositions for projects using the Arduino will be encouraged. Simple experimentation is also welcome. Please come ready to ask questions.
Une introduction informatique physique sera présenté par Metakinetik pour la réunion tmplab à la Gaîté Lyrique, le jeudi 17 Mars. Artiste-Technicien Jason Cook présentera des exemples de base en utilisant l’environnement de prototypage et de conseils Arduino. Des exemples incluent “Hello World”, commande analogique des lumières et des moteur à l’aide de PWM, et l’utilisation de capteurs analogiques. Exemples d’artistes et de techniciens qui travaillent actuellement avec la technologie Arduino seront discutés. Où et comment acquérir le matériel nécessaire sera adressé. Sur la base de la réponse des participants des matériaux seront proposées pour la poursuite de l’atelier dans les semaines à venir. Amateurs et experts sont également les bienvenus. Personne ou groupe de propositions pour des projets utilisant le Arduino seront encouragés. Une expérimentation de découvert tout simplement est aussi le bienvenu. S’il vous plaît venez prêt à poser des questions.
It is with great excitement that I am announcing the release of Milkymist 0.3. This release marks a significant milestone for the project: since now, it’s no longer tens of thousands of lines of code for nerds only. It’s also an actual MilkDrop implementation, rendering good-looking visual effects that EVERYBODY can appreciate.
But, see for yourself. If you have a Xilinx ML401 board, grab your JTAG cable and fetch a binary kit from the usual location. See the wiki for setup instructions. Put on some music, turn on random preset selection, and enjoy!
If you don’t have a ML401, here is a video for you to chew on before the Milkymist One boards are available:
PFPU modified to support the new TMU vertex format
Additional MilkDrop features in the demo firmware:
More wave modes
Borders
Motion vectors (experimental)
Texture wrapping
Random preset chooser
Fine-grained decay
If you want to discuss and keep instantly updated about the project, I encourage you to come and idle in the #milkymist channel on the FreeNode IRC network. See this page.
A workshop/coding party will take place at the /tmp/lab in order to finalize the porting of the OpenWrt Linux distribution to the Milkymist open hardware system-on-chip.
