Five minutes later, this brand-spanking new software has crashed. Hmmm. That sucks. Okay, try again. The damn thing crashes again. Hmmm. Well, apparently, it has something to do with font support; okay, avoid that, try again. “Your application has unexpectedly quit,” and so on for days. Try simple stuff, complicated stuff = crash. Cannot open any significant project from pre-Director 11. I give up. Report bugs. Move on to something else.

So I gave it a few weeks, figuring Adobe would solve the problems that are always hanging around as software goes out the door. I even try copying individual media and scripts by hand, avoiding their “updater” which has now just crashed for the gazillionth time. No luck. Or the thing appears to work for a few seconds, then crashes at some random moment. Try another machine, try a clean install, rinse, lather, repeat…

Finally, I go back to their website. Try the forums, no help there. Try another bug report, probably won’t answer just like a few weeks ago. Try technical support…what!? I have to f@#&§! pay forty dollars just to get help making a supported feature actually work!?

The notion that professional software is somehow more efficient, or (gasp) simply professional, is in the end just a hoax. The illusion that actually having paid for the software will somehow give you some service when it breaks? Yeah, right. To compare real-world experiences: last week I had a bug in OpenFrameworks; I just opened up the code, fixed it, and moved on. I lost maybe a few minutes. Where do I turn when I have a bug in Director? Their website is like a fortress. Oh, sorry, I meant so say a crypt…

I will be in Italy next week (from Saturday evening to Wednesday morning), in the Puglia region, for a mini-workshop (Monday afternoon + Tuesday morning) on the usual: code-based art, using development tools in an artistic context, interactive installations, and the type of work we do at the Atelier Hypermédia. Of note, I will be presenting the tools we use, and in that mix will be OpenFrameworks, which might be of interest. It unfortunately is a very short workshop (not even a real workshop if you ask me), so I wouldn’t suggest crossing Italy to come, but if you’re in the region or at the festival, drop by and we’ll talk about how these tools are used.

To be honest, I’ve never been to Italy, and when Seconde Nature invited to sponsor my trip, I said to myself why not? At least the context looks pleasant.

Here is a presentation in English, French and Italian (I cannot confirm the validity of the Italian translation ;-) :

Since 1998, The Atelier Hypermédia in Aix-en-Provence has been developing tools and procedures for creating art via algorithmic means, be it physical, networked, mediatic or social. This involves, principally, teaching young artists the nature of the most popular algorithmic machine — the digital computer — and exploring what sort of work can be created when we are no longer tied to pre-baked software. This short workshop will begin with a presentation of the Atelier’s tools and working methods, followed by an open discussion and demonstration for participants wishing to explore creative production in the domains of: code|art, networked objects, algorithmic media, experimental interfaces, and (last but not least) play. Time and space has also been reserved the following morning for participants wishing to spend more time exploring these tools in a practical context. Three open platforms for artistic production will be used during this mini-workshop: Processing, Arduino, and OpenFrameworks. To participate in the workshop please make a reservation at the Meeting Point.

Depuis 1998, l’Atelier Hypermédia à Aix-en-Provence conçoit des outils et méthodes de création artistique dans un monde de plus en plus traversé par la question de l’algorithme : que ce soit physiquement, à travers les réseaux, dans les médias, ou via les relations sociales. La plupart du temps, cette activité implique l’apprentissage des contours techniques et idéologiques des machines algorithmiques les plus utilisées aujourd’hui : les ordinateurs. L’objectif, par contre, n’est pas la technicité, mais plutôt l’exploration des nouvelles possibilités qui s’ouvrent dès lors que l’artiste refuse la posture du consommateur de logiciels. Ce court workshop, commencera par une présentation des méthodes et outils de travail de l’Atelier Hypermédia, suivi d’une discussion ouverte, accompagné de démonstrations pour des artistes voulant explorer la création artistique dans des domaines telles que : le code|art, les objets orientés réseau, les médias algorithmiques, les interfaces expérimentales, et enfin, les jeux. Du temps et de l’espace sera également consacré le lendemain matin pour les participants voulant passer plus de temps avec ses approches. Trois plates-formes ouvertes, conçues pour et par des artistes, seront utilisées pendant ce mini-workshop : Processing, Arduino, et OpenFrameworks. Pour participer au workshop, merci de bien vouloir réserver votre place au Meeting Point.

Dal 1998 l’Atelier Hypermédia di Aix-en-Provence (Francia) ha sviluppato delle utilità e dei metodi di creazione artistica in un ambiente, che si esso fisico, sociale, virtuale o mediatico, sempre più segnato dalla questione numerica e dagli algoritmi. Nella quasi totalità dei casi la padronanza di questi ambienti dall’apprendimento degli algoritmi e dalla padronanza dei software: in poche parole da una conoscenza approfondita del computer. L’obiettivo, tuttavia, non è il tecnicismo ma l’esplorazione delle nuove possibilità che si aprono nel momento in cui l’artista rifiuta il ruolo di consumatore passivo di software. Il workshop comincerà con una presentazione dei metodi e delle utilità di lavoro dell’Atelier Hypermédia; seguirà una discussione aperta accompagnata da dimostrazioni per gli artisti che vogliono esplorare la creazione artistica nei seguenti ambiti: codice/arte, oggetti in rete, media algoritmi, interfacce sperimentali, e i giochi. Per chi volesse approfondire, inoltre, queste tematiche potrà richiedere la continuazione del workshop nella mattinata del 27 maggio. Durante il workshop saranno utilizzate tre piattaforme libere: Processing, Arduino, et OpenFrameworks. Per partecipare al workshop è richiesta l’iscrizione presso il Meetng Point.

So it got me thinking about some other code songs:

Which was probably inspired by Joe Wecker’s DeCSS Decryption Song, which also has lead to this MIDI version of the DeCSS Decryption algorithm (for more information, visit David S. Touretsky’s Gallery of DeCSS descramblers).

On the purely cultural side of code, geeks, and computers, there’s always ytcracker and MC Frontalot:

Which led me to this song, which is kinda ok (euh, maybe not):

I could go on and on, but at least it gave me an excuse to link to this cheezy rock song which tortured us in the 80’s. To be honest, it isn’t really about the same kind of code, but who cares — I mean come on, check out that hair!

He and I chatted quite a bit during his residency, and I loved the work he produced there, especially this overloaded joystick.

So when the TWS asked me to write an accompagnying blurb to contextualize Antonin’s residency, I was more than happy to oblige. Here is the short text I wrote, followed by a few photos from Antonin’s work during his stay:

Antontin Fourneau, or the Double-Bearded Frenchman

When starting an artistic career, one of the biggest problems is what to do with all those annoying influences that inspired you in the first place? Borges resumed the problem as that of Hamlet’s ghost: how can the play go on, when all these annoying predecessors keep (literally) popping in their heads? A young artist should resolve these issues fairly quickly, and somehow Antonin Fourneau seems to have solved his artistic identity crisis through a very special secret ingredient: a sophisticated form of amateurism. Antonin’s hydra-monster of influences are very much infused with the energy of popular culture. What better context for inspiration then, than the supercharged japanese recycling-plant of all culture, continually giving birth to new definitions of comics, teenagers, gaming, pop, … But beyond recycling, beyond pop, and beyond the topical accuracy of video games as our future medium, there is an added impression of fun in all of Antonin’s work, a sort of sincerity that only an amateur could understand. “Amateur” — in the sense of lover or aficionado. A delightful ignorance of the cynical blasé of fancy contemporary artists negotiating their next posture. A favorite figure that continually returns in his work, is that of the bearded lady: that cliché of otherness that in its lack of sophistication somehow becomes its own caricature; except of course for the pre-adolescent child, who gazes upon it in rapturous wonderment. When I look at some twenty-odd buttons of all sizes joyfully scattered about a controller, I can only read in it a boyish call to the gaming industry: “please someone, come and bring some joy back into this stick”. In this way, Antonin has stolen that ladybeard and placed it on top of his own, thereby redefining his own — very French, and very devilish — form of a wink, which is both innocent and sophisticated, all at the same time.

I’ve been invited to speak tomorrow in Marseille for a conference series on the relationship between the art work (« l’oeuvre ») and its reception (participatory, interactive, relational). Anyone who knows me, knows my hostility to these terms, so for my part, I will be trying to politely move beyond them, which seem to me very tied to some old debates from the 80’s and 90’s, especially here in France. I will instead propose a model that includes interactivity but without situating it either at the work’s inception, nor at its terminus.

These conferences will be published later by the University of Provence.

• De nouvelles figures de l’artiste et de l’expérience sensible
• le 21 avril 2008
• « Appareillage informatique ou ancrage affectif : du concept d’Hypermédia au percept de Déposition sculpturale ? » par Julien Honnorat
• « Antagonisme et imbrication : au-delà de la notion d’interactivité » par Douglas Edric Stanley
• • La participation comme nouveau regard sur l’œuvre
• le 28 avril 2008
• « Le spectateur dans l’oeuvre : identification, distanciation, appropriation » par Nicolas Ferrier
• « Mythologies du spec’acteur des arts de la rue » par Anne Gonon
• • Quel devenir pour les politiques culturelles
• le 05 mai 2008
• « L’action publique culturelle et artistique à l’ère de la participation généralisée » par Fabrice Raffin
• « Les enjeux de la démocratisation culturelle à l’âge de l’œuvre participative : ou que reste-t-il du spectateur-sujet quand il devient co-auteur de l’œuvre ? » par Loïc Lafargue

I’m not sure I’ve found what I’m looking for in terms of legally embeddable fonts. It actually harder than you might think to find interesting, yet readable, open fonts. If you use this feature, be careful: you cannot embed commercial fonts as this would be the equivalent of distributing them and could get you into trouble. Some web designers have complained about this, but I actually think this is a Good Thing™. We need a more developed open type community — and no, embedding fonts in Flash is not a solution — and this will only accelerate that process.

Which reminds me — there’s this brilliant project currently in beta where you can “build, share, download” open typefaces: FontStruct over at the infamous FontShop. It’s a great service, even if it still needs a lot of work. You can even embed a flash example into your blog or webpage, as in the following Pixel Cube example:

I don’t know how long I’ll be using this font (it has a lot of issues), and for the moment I have yet to figure out how to single out browsers that do and do not support this feature, in order to create the right type relationships for those that do not. For the moment, I’m figuring most cannot see these fonts, and so the sizing is all wrong. But whatever the case I think it’s great to see a community tool perfectly in sync with this complex issue, and if you think my website is now even uglier than before, please give me some time to figure out how to deal with this (welcome) extra layer.

This week Plot was supposed to be in the Pyrenées — riding rustic trains, going for walks in the mountains, playing with accelerometers and GPS, and watching The Sound of Music, Moloch and other mountain movies — but through various accidents we ended up transporting the entire mountain to Aix-en-Provence.

I’ve been doing a lot of writing, interviews, conferences, etc. that I haven’t been able to comment on from this blog because much of it has yet to be published. But today I just got word that one of these theoretical texts has finally been published, and ran on Radio Grenouille monday morning. It is a text I wrote for Marc Voiry on the subject of the “Myth of the moth: towards a mothology of computer science” (sorry, this just doesn’t translate). Marc wanted to reactualize Roland Barthes’ famous texts of the 1950’s — published in 1957 under the name Mythologies — and invited various thinkers to ponder the mythologies of today, and in some cases return to the mythologies of Barthes some 50 years later to see what had changed. It promises to be a great series considering those he’s invited, and should be a fun listen.

For my ten minute slot, I wrote/spoke about the mythology of the computer bug, and the relationship between one mythical moth and one mythical machine, and how their meeting constructed a mythology that informs us still today. It is an attempt to construct a “miteology” that allows for an epistemological reading of computer science, i.e. how its mythologies can inform us about its internal (logical, conceptual, political) contradictions. It’s about machines, compilers, interfaces, circuits, algorithms and how they relate to one poor moth still (to this day) mumified under a piece of transparent tape while exposed for all eyes to see at the Smithsonian.

Unfortunately, I’m a horrible reader, and pretty much incapable of reading my own damn text without stumbling all over the place. It is strange the degree to which writing and speaking French are two totally different activities for me. I learned the language so late, and yet have depended on it so intimately for practically all of my theoretical activity, and somewhere in that tangle of neurons I have two totally different understandings of the French language that are simply not compatible. I am just not comfortable reading out loud in French. Whereas the text itself was written quite joyously, with a certain sense of freedom; a feeling that I often feel when teaching, for example. But writing a text in French, and then reading it out-loud, just doesn’t seem to work. Pity. I quite enjoyed it.

So for those (like me) that can’t labour through my cracking voice that sounds as if its owner was just introduced to puberty, here is the original text :

• Le mythe de la mite : vers une mite-ology de l’informatique

Pourquoi devons-nous soigner autant toutes ces petites machines qui nous entourent ? Pourquoi faut-il dompter en permanence ces appareils qui n’arrêtent pas de pousser dans nos bureaux, dans nos maisons, qui rentrent jusque dans nos lits ? Pourquoi doit-on les rassurer pour qu’elles ronronnent sans piquer des crises et perdre tous nos précieuses données; les caresser dans le bon sens du poil pour qu’elles nous offrent leurs services tant convoitées ? Pourquoi la tâche d’opérer d’une machine informatique contemporaine ressemble autant aux labeurs du jardinier, qui doit désherber de manière cyclique son jardin pour qu’il pousse convenablement ? Et puis, la véritable question devant tout ceux qui n’arrivent pas à installer la dernier version de Word : est-ce qu’il sera toujours aussi difficile d’actuer ces machines ? Est-ce qu’elles ont toujours été si difficiles, si fragiles, toujours aussi enrageantes ?

Le terme de « bug », c’est-à-dire la « petite bestiole » qui encrasse la machine et l’empêche de fonctionner normalement, ne naît pas avec l’informatique, mais on peut affirmer à l’inverse que cette dernière est née incontestablement — dans une scène historique très précise — avec lui. Si le mot « bug » est entrée dans le vocabulaire populaire, c’est justement parce que l’informatique s’est popularisée — le « personal computer », qui arrive autant infesté de bestioles que toutes les machines qui l’ont précédé.

La première à mythologiser le rapport entre l’informatique et ses défaillances, c’est Grace Murray Hopper, programmeuse du premier ordinateur digne de ce nom — le Mark I, qui voit le jour vers la fin de la guerre en 1944 à l’Université de Harvard. C’est un détail inconnu pour beaucoup de français, mais parmi les premières algoristes historiques, trouvent deux femmes — Grace Murray Hopper et Augusta Ada Byron, comtesse de Lovelace, fille du célèbre poète, qui travaillait quelques cent ans avant Hopper sur la « Machine analytique » en assistant Charles Babbage sur la traduction de thèses mathématiques et sur la correction d’algorithmes pour sa machine qui restera pendant 150 ans inachevée. Pour sa part, Grace Murray Hopper travaillera sur la création de « compilateurs », c’est-à-dire les mécanismes de traduction des instructions lisibles par les êtres humains et qui doivent être traduites ensuite en un langage plus étrange — compréhensible presque exclusivement par la machine. Car écrire directement en langage machine — en 0 et en 1 –, est une exercice rarement supportable pour le commun des mortels, et même fatiguant pour les quelques exceptions comme Hopper qui maîtrisaient l’architecture de la machine avec sa logique particulière. Faciliter l’écriture des programmes permettraient à un plus grand nombre d’accéder aux capacités de l’ordinateur, et aiderait à écrire des programmes capables d’effectuer des actions de plus en plus complexes.

Mais avant de parler de la complexité, racontons l’anecdote que Grace Hopper aimait tant raconter, c’est-à-dire le jour du premier « bug » informatique. Les premières machines informatiques étaient de véritables monstres qui pouvaient occuper plusieurs salles entières. Elles étaient aussi grandes à cause des différents actionneurs mécaniques qui contrôlaient et executaient les instructions. Ces actionneurs occupaient non seulement de la place mais produisait énormément de chaleur et de bruit. Le 9 septembre 1947 — notre journée mythique – un véritable insecte, une petite mite, s’est glissée dans la salle du Mark I et croyant apercevoir le chemin menant à la lumière du soleil s’est incrustée dans les contactes de l’appareil, provoquant une panne général accompagné de la mort de l’insecte. Au départ, les ingénieurs pensaient qu’il s’agissaient d’une simple erreur humaine, c’est-à-dire d’un phénomène déjà décrit par Ada Lovelace quelques 100 ans auparavant où une erreur d’ordre ou de logique placée au début du programme empêcheraient la partie suivante de fonctionner. Mais après relecture des instructions on ne trouvait nulle erreur, ce qui les amenait à la deuxième phase d’investigation, la vérification de chacun des relais qui très souvent tombaient en panne à cause de l’effort physique de la machine. On l’oublie souvent, mais une machine informatique — bien qu’elle s’opère par grandes abstractions logiques dans son organisation diagrammatique — est toujours actionnée par un jeux de verrins physiques quelconques et en 1947 les défaillances étaient la plupart du temps dû au mauvais fonctionnements physiques des composants. C’est alors pendant la vérification un par un des relais de la machine, que l’équipe de Hopper découvre la mite coincée entre deux contacts en cuivre. Dans un geste dont le résultat est encore exposé aujourd’hui dans la partie du musée national américain dédié aux sciences — le Smithsonian — ces ingénieurs ont extrait la bestiole et l’ont scotché dans leur journal de bord accompagné par la légende, “1545 : Relais #70 Panel F (mite) dans le relais. Premier cas de découverte d’une véritable bogue.”

Nous ne pouvons pas insister assez sur la force mythique de cette anecdote. Même la langue française porte les traces de cette histoire : alors que le terme anglais « bug » est un héritage du français « parasite » — encore employé aujourd’hui en décrivant, par exemple, le bruit qui parasite un signal électrique –, ce terme a été réimporté en français sous la forme « bogue » pour décrire cette défaillance spécifique de la panne de fonctionnement /algorithmique/ de la machine informatique. Il ne s’agit pas d’un simple gêne, ou perte relative du signal; il s’agit d’une /panne/ de la machine dans tout son fonctionnement, ou dans le fonctionnement d’un aspect de la machine comme dans un logiciel qui « plante ». On est proche de l’idée d’un « arrêt » du mouvement de la machine, d’une dislocation ou de son déraillement, plutôt qu’un simple ralentissement ou affectation qualitative. Le scotch employé ce jour de septembre 1947 semble avoir scellé à jamais l’idée qu’une panne algorithmique est liée non pas à la faute de raisonnement dans l’écriture d’un programme — la véritable raison de la plupart de nos pannes –, mais plutôt à une violence introduite dans l’appareil depuis sa strate physique.

La force de tout mythe est de condenser un certain nombre de contradictions internes d’un phénomène quelconque à travers une figure qui raconte de façon synthétique l’histoire de sa conception. Le mythe est une histoire de naissance. Dans mon vocabulaire à moi, j’appelle ce moment « le talon d’Achille », faisant référence au mythe-matrice du trempage d’Achille dans la rivière Styx et de la trace des doigts de sa mère lorsqu’elle enrobait son fils par son nouveau pouvoir technologique. Le talon d’Achille associe à jamais la force constructive d’une technologie à sa déconstruction; autrement dit, le mode d’emploi qui explique comment monter la machine décrit également dans le même mouvement comment la démanteler.

J’y vois dans ce mythe de la mite, deux contradictions propres à l’informatique qui sont toutes les deux liées à la même racine ontologique, et que je définirai comme le problème d’attitude de la machine face à sa physicalité.

La première contradiction d’une machine algorithmique concerne la tension entre la couche matérielle ou /concrète/ de l’informatique, et sa couche /abstraite/ ou algorithmique. Quand nous décrivons un programme à une machine, nous décrivons un certain « comportement », c’est-à-dire nous lui donnons son « orientation ». Nous ne nous soucions pas forcément de tous les détails de son fonctionnement, et c’est Grace Murray Hopper qui a eu en premier assez de lucidité pour voir la force que l’abstraction pouvait apporter dans le maniement de l’appareil : à travers ses activités de recherche et de développement (menant à terme au langage COBOL), elle a montré que pour programmer une machine il faudrait mieux s’abstraire de son opération purement mécanique — la machine vu à partir de ses circuits –, et à la place lui communiquer plutôt par des grandes lignes. Malheureusement, c’est précisément dans cette abstraction des couches matérielles que les erreurs algorithmiques peuvent s’introduire, notamment dans l’approximation qu’elles font de la manière dont la machine exécutera ses tâches. Parfois les erreurs du programme peuvent venir d’un mauvais ordonnancement purement logique, par exemple le cas déjà décrit par Ada Lovelace en 1842 où le résultat d’un calcul serait demandé par un programme avant même que ce calcul soit lancé. Mais il existe un autre problème de conception des programmes et qui concerne le problème de la traduction de ces instructions algorithmiques (autrement dit le programme comme « Idée ») vers les rouages mécaniques qui doivent physiquement les actionner. Souvent la logique de ses deux couches sont très différentes, et demandent au programmeur (ou programmeuse) une grande gymnastique de la pensée pour maîtriser. On ne maîtrise jamais totalement la bête, d’où divers accidents historiques, comme celui du porte-avion USS Yorktown qui a resté en panne pendant trois heures à cause d’un zéro que Windows NT 4.0 n’a pas su calculer. D’autres erreurs algorithmico-matérielle sont souvent provoquées par la manière dont une valeur est stocké dans la machine : le calcul ne sera pas le même si on utilise deux octets, quatre pour stocker matériellement la valeur de PI dans un registre de la mémoire. Dans ces deux cas, les valeurs après la virgule, ne seront pas les mêmes. Le souci du programmeur est précisément cet endroit où la logique intellectuelle du programme rencontre l’interrupteur machinique qui doit l’actualiser — ce que le mythe de la mite représente sous la forme d’une rencontre de deux mondes ontologiquement incompatibles mais qui cherchent néanmoins à se communiquer. Car il est impossible, voire fatal, de parler avec la machine dans son langage pur.

Ce qui nous amène à la deuxième contradiction constitutive de l’informatique : celle de notre accès à la machine, autrement dit l’interfaçage. Quelque part nous pouvons qualifier l’erreur de la mite d’avoir voulu interagir /directement/ avec la machine. Ce que ce mythe nous apprend, c’est qu’avoir voulu interagir avec la machine sans interface était à la fois fatale pour la machine et pour la mite. Ce conflit nous ramène bel et bien à la contradiction précédente, c’est-à-dire à cet étrange négociation permanente qui doit exister entre la matière et l’abstraction pour que l’informatique puisse fonctionner.

Informé par ces observations, je propose à une humanité de plus en plus imbriquée par contagion à l’informatique, un nouveau champ d’étude — celui de sa mite-ology, qui étudierait la mite informatique dans ce qu’elle aurait de constitutive pour le nouveau monde qui arrive. Au lieu de fuir le plantage ou le bogue, cette mite-ology la prendrait comme la limite constitutive, comme son ouverture. La mite-ology partirait du mythe de la mite comme l’annonce d’une nouvelle physicalité qui en permanence doit accompagner toute agorithmisation de notre polis — autrement nommé sa virtualisation. Pas de nouvelles abstractions, pas de monde soi-distant « virtuel », sans que parallèlement soit engendré des retour de bâton du monde physique qui doit accueillir et rendre compatible (ou incompatible) cette virtualisation. Pas d’algorithmisation du monde sans de nouvelles rencontres avec la mite : cette bestiole qui par curiosité et besoin cherche à créer de nouveaux circuits d’interaction avec le monde.

Yes, I am off to yet another workshop this afternoon. This time to the IAV in Orléans, a design school that is organizing all week a series of workshops, conferences, and presentations dealing with the theme La légèrté (lightness). This concept is obviously following in line with what is probably now 100% of the design schools in the world who have jumped onto the bandwagon of durable design. And yet while I’m thrilled with this turn of events, I wander into this new context with some trepidation; and so as usual I replied to their invitation with an amical quip, reworking the subject of “légèrté” into that of “orientation”, suggesting therein that oppositions such as light vs. heavy do not really grasp the current transformations of space, objects and subjects. In place of such dichotomies, I’m suggesting here that we rework Duchamp’s concept of the “inframince” (ultrathin), taking into account the new forms of re-orientation that are changing our contemporary polis.

On the practical side, this workshop will very much be keeping in line with my steady reorientation to the subject of phyiscalization, and as such we’ll be working with Arduino as much as with Processing.

Here is the full French description of the workshop. I should probably translate it, because there are some essential concepts in there for my current thinking on digital art and design, but I have to get on a train so you’ll just have to use your favorite translator if you can’t read it in the native tongue.

Proposons une nouvelle mesure : celle de la modularité des choses. Encore plus léger que la légerté, l’inframince n’est plus cet espace liminaire qui s’imaginait jadis comme le poids de la fumée — l’intangible comme une sorte d’ontologie indécise. Aujourd’hui l’inframince se définit plutôt dans l’hésitation du neurone avant de se décharger, c’est-à-dire à travers l’esprit intangible qui permet à des choses tangibles de se moduler. C’est le potentiel d’une ontologie à la fois matérielle et varible : « inframince » comme « l’orientation » des choses, « modularité » comme leur « ouverture » sur le monde.

Une approche « orientée » (du design, de l’art, peu importe) se déploit dans un monde physique de plus en plus capable de se réadapter « en fonction de … », « envers … », et « vis-à-vis … ». Pour ce workshop, nous tenterons une avancé vers ce monde en explorant ses machines programmables. Ces machines sont riches mais également complexes. Le but premier sera alors de dompter ses méchanismes modulaires. Pour y arriver, nous utiliserons principalement deux environments de création algorithmique — Processing et Arduino –, conçus tous les deux pour et par des artistes voulant rendre (plus) accessible la création modulaire.

L’intérêt de ces deux environements réside non seulement dans l’accès qu’ils donnent à l’intéractivité, la générativité, l’interfaçage ou la mobilité; ils sont surtout essentiels pour la continuité qu’ils permettent entre le monde des médias et celui de l’espace physique. Car pour nous il s’agit d’un seul et même continuum entre l’algorithme côté machine et son « expression » dans le monde physique. C’est dans ce sens que nous ne parlons plus du composition de l’objet mais de son orientation, c’est-à-dire de la façon dont un objet peut s’exprimer dans l’espace d’une installation à travers un programme informatique ou vice versa. C’est ce que nous appelons la « physicalisation » du monde algorithme.

Bien que cela ne soit pas l’objetif principal du workshop, ces expérimentations peuvent mener à terme vers l’argument implicit dans celui de la « légerté en design » : autrement dit le développement durable et le « poids » des interventions de l’homme. Pour nous, la réflexion sur la transformation du monde ne peut pas faire abstraction des nouvelles abstractions algorithmiques qui s’abattent sur nos territoires, y compris dans leurs dimensions politiques. Pour ne donner qu’un exemple, nous ne voyons pas dans le balisage du paysage uniquement des histoires de localisation, mais aussi de la gestion du territoire. Nous nous opposons en conséquence à toute idée de dématérialisation qui ne s’accompagnerait pas d’une réflexion sur la re-matérialisation; c’est-à-dire l’hypermatérialisation. C’est dans ce sens que nous parlerons d’une « orientation algorithmique » qui approche le monde non plus comme une série d’artefactes plus ou moins lourdes mais plutôt comme un territoire de choses en évolution constante capables d’être mesurées par leur modularité.

Puisqu’il est de la résponsabilité du designer d’être à la fois en phase et déphasé avec son temps, ce workshop propose de répondre à ces constats à travers des expériences concrètes avec les formes directement résponsables, et voir les réponses artistiques qui s’en suivent.

Hi. I’ll be in Bordeaux this week, in yet another workshop on how to make art using code. Here’s the official statement:

• Workshop Art du code par Douglas Edric Stanley
• professeur d’Arts numériques à L’école supérieure d’art d’Aix-en-Provence
• 25 étudiants (bases en informatique souhaitées)
• Préinscriptions au secrétariat de l’école

Introduction aux pratiques actuelles de la programmation dans le champs artistique. Initiation au logiciel open source Processing. (processing.org)

Artiste d’origine américaine, Douglas Edric Stanley est professeur d’Arts numériques à L’école supérieure d’art d’Aix-en-Provence où il intervient dans des champs tels que l’esthétique informatique, l’interactivité, la robotique, et la programmation, et dirige L’atelier Hypermédia, un atelier qui traite l’algorithme et le code en tant que matières plastiques. Depuis 1997, il a donné de nombreux workshops sur la programmation dans un contexte artistique pour divers institutions, universités et écoles d’art. Il a participé en tant qu’artiste à des expositions liées à l’art informatique, dont la Biennale ICC, Tokyo; le Festival Ars Electronica, Linz; ZeroOne/ISEA2006, San Jose; EnterMultimediale, Prague; Villette Numérique, Paris; Festival Némo, Paris; Ecoute, Centre Pompidou, Paris. En 2000, il a reçu une mention aux Prix Ars Electronica pour son installation à retour d’effort, Asymptote. Il est également chercheur au Laboratoire Esthéthique de l’Interactivité à Paris 8, où il travaille sur les trasformations de l’art face à l’algorithmisation du monde.

Of course, the library can’t do everything I want. For example, I need some pretty advanced sound capabilities, and I’m not sure the included sound functions — which do seem useable — will be robust enough. I might have to give up that library and switch to another one, or it might be the one place where I’ll have to barrel down into the registers, setup interrupts, deal with FIFO registers, etc. myself. But that’s fine, because everything else is so easy: generate the graphics in whatever — making sure you stay within a limited range of colors –, convert those images using one of the included tools (or make your own using Processing or whatever, it’s pretty easy), load that data into the sprite registers, and then let the DS do all the work: all you have to do is set the sprite’s x and y positions and the DS hardware does all the rest.

I’m still amazed at Nintendo’s hardware style. I always loved how the Gameboy and Gameboy Advance were just tiny little processors, surrounded by all these well-chosen chips dedicated to putting sprites and tiles on the screen, and generating the necessary beeps and boops. I’m all for specialized chips and processors, and I think think they’re going to be even more important as we move more as a society towards serious power conservation. So I love these crazy japanese designs and extreme efficiency. But it also amazes me the extent to which the DS is just a souped-up Gameboy Advance. It’s exactly the same strategy they came up with for the Wii: start with the previous platform (Gamecube), and tack an interesting interface onto it with some minor audiovisual improvements. Also, make sure there’s N64-style 3d graphics capabilities. This of course is great for me: all the original registers that I know all-too-well are still there, but with an added processor for handling the second screen, and new functions for handling Wifi, the stylus, and so on. There are also more sound channels, and even some of the old-skool Gameboy sounds are still hanging around (which is really tempting me right now in the current project). But again, I haven’t gotten around to the sound yet because that’s when the real work starts. For now, I’m just having fun finding new movements for the stylus.

It’s also interesting, after sitting through the (eye-opening) iphone sdk video, and now playing around with the DS touch interface, to see how far we have all come on physical gesturing, no matter what the input format. I’ve found myself adding a lot of iPhone-style touch gestures using the very limited input of the DS, which is very eerie for me, because a lot of these gestures hark back to efforts I made back in the 1990’s (remember when CD-Roms were all the rage?). These gestures take on new meaning for me, now that they’ve been placed into this new historical perspective offered by the Wiimote and the iPhone. For example, a lot of the work I did with Claude Faure (see video) was already playing with the physicality of the interface. This was quite clear to us, even then. But that said, this work takes on new meaning now that all these gestures have come of age — or are simply breaking out in all their pimply pubescent enthusiam (it all depends on how much you like or dislike these new semiotics).

The DS, the Wii, and the iPhone are important indicators on where we’re at on this subject. For example, there was a very prescient moment in the iPhone video (you’ll find it at 00:40:23) where the ‘undo’ function is converted from its previous semiotics of ctrl-z (remember F7=SAVE anyone?) into a simple shaking of the device itself. Okay, okay, I know what you’re thinking — this is just a gadget-geek-moment, a golly-gee-wow somewhere up there at the level of sophistication of the blink tag (thanks Netscape). And probably after we’ve all transformed into premature parkinson’s sufferers after shaking our iPhones all day — with some new neurological disorder similar to what keyboards did with carpal tunnel syndrome –, we’ll have had enough of all this goddamn gestural computing. But I still find it amazing to think that ctrl-z can be transformed so easily into a simple flick of the wrist. The same goes for the game they showed at 00:41:03, « Touch Fighter ». There, the iPhone itself is the joystick — uh, yeah, Douglas, I think that’s what the guy already says in the video — and it will be hard to go back after that realization, just as it is now hard to imaging gaming (and DJ’ing) after having played with the Wiimote.

Anyway, to get back to the development nitty-gritty, how do you develop for the DS from a Mac? Since I explained this already to Benoit this afternoon in the Atelier, I should mention it here for later reference. You need to:

• make sure you have installed xCode (free)
• follow the instructions of either: Nintendo DS development for Mac or PAlib Wiki Mac OS X (the later worked fine for me)
• download this PAlib xCode Project template and install as instructed (this will allow you to create a new PAlib project from the “New Project” menu in xCode)
• create a new project in xCode and “build” it
• find a workable emulator to test before loading the “program.nds” file onto the physical DS (no 100% solutions here — I’m currently using NO$GBA from Parallels running Windows inside of my Mac, since I was too lazy to get any other emulators working on my Mac)
• buy some sort of programmable cartridge for copying your program to the DS

I’ve had a few requests recently, asking me to write about various subjects — gaming, contemporary art, code aesthetics, interfaces, and some other subjects I declined to write about, simply because I had nothing to say. Ethan Miller wrote me yesterday to let me know that at least one of these has finally been published, namely an article I wrote for Switch a few months back, in response to the subject of their (then) upcoming issue entitled “re-purposing”.

As usual, I didn’t really answer the implied subject — artists re-purposing technology for artistic use. Instead, I more or less proposed re-purposing as the definition of contemporary technology itself, and therefore a larger epistemological issue beyond mere aesthetic concerns. Anyway, it has what I hope are some clarifications on how I read programming within the larger framework of temporal machines, and something about its ontological(ly variable) nature.

But there are some things that only the French can truly appreciate, and that you have to have something French in you to even understand. I often cite, as an example, one of my favorite French expressions (and there are many) : « Il a le cul bordé de nouilles » which basically translates as « he’s got an ass full of noodles ». Since I am apparently someone abounding in luck, I have on many occasions been attributed with a noodly ass. Now for those that cannot stand them — for example, the English — this is probably yet another example of what is so profoundly wrong with the French. Indeed, saying that someone has noodles, or perhaps worms (it all depends on your point of view), coming out of their ass does not mean that they are sick, or unhygienic, or just plain out of luck — in fact, it’s quite the opposite. Saying « il a le cul bordé de nouilles » means that you are lucky, and even more, you are overflowing with luck, as in look at that mass of lucky worms pouring out from your underside! Now what does all this mean? How can, for the French, the idea of noodles, worms, hemorrhoids (oh yes), or perhaps (if we take slang into account) good old fashioned penises, evoke someone being lucky — even more, someone being abundantly full of luck? This, my friends, is one of the mysteries of being French, and the mere (moral, even logical) ambiguity of it all: the quite decisively indeterminable nature of what the hell that possibly means is also very much part of the definition of what it is to be French.

Accordeons:

Gainsbourg, the « vieux dégeulase qui pue »

Gainsbourg, patriotic version:

Gainsbourg, le classique :

And while we’re on the subject of kidneys, how about hips?

Leading us of course to Dalida:

Perhaps that’s all it is, this idea of France, une chanson d’amour? — ah now there’s a cliché :

But they do love their « chanson populaire ». Before American Idol, there was L’école des fans…and Claude François:

Oh, Claude François is not heady enough for you? Ha! Even Gilles Deleuze admired him. And let us not forget, in our nostalgic tour de France, the required selection of famous French intellectuals:

Ah, that’s it. Freedom. Existentialism. Mai ‘68. Vive la résistance! But what would all that be without José Bové’s moustache?

And what would France be, without it’s laches, it’s cowards, its smug pretention?

Or, perhaps, none of that matters, and it’s all just about Carla. That is probably one place where we can all agree, only in France:

If you haven’t figured it out yet, I received my French nationality papers today. Since a lot of people have been asking me, I should make it clear that I now have two national songs, as the French do not require you to renounce your previous citizenship to become French. Qu’un sang impur…

To continue my recent work on protocols, I made this little checksum mosaic software for my new national song : La marseillaise. I haven’t exactly figured out what to do with this checksum image yet.

The great news from all this activity, is that Stéphane showed up for our latest session Sunday afternoon with a working version of the Processing OpenCV library running on Windows. This was just in time for the two-week long rehearsals we started today, in order to finalize Wolf Ka’s latest dance piece. Since Wolf wanted to run everything off of a PC, it was a good excuse to give our OpenCV library a second real-world test run before unleashing it onto the wild. Especially since we have to have this piece ready by early April.

We found a few crazy things just in time, and will probably find a few more, but so far everything is running great, almost immediately, even better than I expected, and we were able by the beginning of the first afternoon to start working on the dance+algorithms, as opposed to plugging things in and banging on the machines. I’m thrilled as to how quickly you can get a full kick-ass tracking program up and working with an absolute minimum of code. Totally cool, that. It’s all in line with the attitude of offloading the ugliness — Processing-style — and just getting to work on the essentials; but not too much, making sure not to dumb things down.

We’ve also taken the opportunity of going through all the original OpenCV examples and documentation, compiling directly in C/C++ through GCC, just to understand how the library works at the most basic level. As it turns out, it’s not all that hard, but we’ve just started a new phase of this research, so we’re still only just getting started — which is pretty exciting for me because I’ve already begun to imagine million little crazy things I can do with this library. Anyway, things like face tracking are an absolute shoo-in for the first beta release (thanks Guillaume), as well as movie import (.avi), and some simple brightness/histogram magic for treating images — either before you analyze them, or just because you want a fast Photoshop style filter inside of Processing. We’re also working on object tracking, but I haven’t gotten around to Kalman predictive filters, as was suggested here in the comments, but I’ll get around to it — it’s just a question of figuring out how the various available examples approach the problem and making it a natural integration into Processing. A lot of Stéphane’s and my work have involved debating how to make the whole process very Processing-like, both simple & modular.

Oh, I should mention that the rehearsals with Wolf are taking place at the beautiful Pavillon Noir, the national dance center recently created by/for Angelin Preljocaj. If you’ve visited Aix-en-Provence recently, you should know what I’m talking about, it’s absolutely unavoidable. Since this time we are working with dancers, it nice to be in an actual dance studio, as opposed to some dingy basement at the Art School.

I should also mention that I have two great students with me, Stefan Schwabe who is currently on loan this year from the design school in Halle, and Fabien Artal, a veritable personnage of the Atelier over the last three years. I’ve been lucky these past few sessions to have a steady stream (but small enough to be manageable) of extremely competent students who transfered to the school with a very specific understanding of what it is we’re trying to accomplish, which is very important in my case, since the Atelier Hypermédia is not always the easiest thing to explain to an art student. It is actually thanks to this current push of students that we have been able to take on some of the more ambitious projects of the Atelier.

I’ll be in Le Havre for the next two days, participating in the colloquium on “Speculative Aesthetics”, which in reality just means a meeting of the various multimedia professors of french art schools. This will be the seventh meeting of this type, the first beginning in 2000 at the Villa Arson in Nice.

While it is not yet clear where and when exactly I will be talking, I hope to discuss with my french colleagues a certain number of subjects, most of them revolving around open teaching: i.e. using the network to share techniques, documentation, and as a tool for collaboration on projects. This involves Processing, Arduino and eventually OpenFrameworks, but also the tools we use to document our activities using these platforms, and their technical documentation.

Here are some screenshots from « C’est toi la patate !? », the design-it-and-build-it-as-fast-as-you-can « installation ludique » we created in just under 4 days during the PlayVision workshop. The main goal of this installation was to use our still-in-construction Open Computer Vision library for Processing in a real-world context and see if it could hold up. Conclusion? So far, so good.

The idea is very simple. You stand in front of a screen which acts as a surveillance-system/mirror. If you hold a part of your body still, the computer will take a picture of it and detach it from the rest of your body. Once you have detached the body part, you can play with it by moving your body around. The installation stores many body parts, leaving a sort of weak memory trail which (re)connects the successive players to one other over time.

We called it an « installation ludique » in response to an idea put forth by Jean-Baptiste Labrune during the opening Transatlab brainstorming session. I had been talking about Huizinga’s and Caillois’ theories around games and play, and Jean-Baptiste suggested we also keep in mind Winnicott’s theories around free play. The idea of a game open enough for the rules to more or less emerge during gameplay appealed to us greatly. This is one of the reasons there is no real specific goal to our « game », outside of the fairly obvious constraints of the interactive algorithm itself and the behavior required to achieve whatever it is you want to do. Jean-Baptiste also insisted that this model of gameplay has a power relation: it could be suggested that those who generate the rules, are exceptions to them.

Unsurprisingly, most people have been playing with the mirror from a purely narcissistic desire: fascinated by the pure game of self-recognition. Mirrors, apparently, still fascinate us. However, very quickly (in fact, almost immediately), people figured out that you could tell stories with it, and even salacious ones at that. By detaching your fingers in a suggestive manner and pushing them into suggestive configurations of body parts, one can in fact construct a compelling little marionette play, albeit a somewhat simplistic one. Funny that those two configurations — reflection and storytelling — should both be so immediately compatible in an interactive context, so easy to tap into. There is a great word for this which I used back in my pre-doctoral thesis on interactivity, namely « relation ». Relation, in French, can mean both a relation (in the English sense of relationship) and the act storytelling, i.e. the process of relating something to someone else. Interactivity, I wrote back then, was often about relation: what story is constructed in the liminary space generated between the player and the machine?