abstractmachine

4 June, 2008

Young, old, furry, slippery

Filed under: workshop, atelier hypermedia, abstractmachine, code, physicalization — Douglas Edric Stanley @ 08:29 am

Starting tomorrow, I’ll be spending two days participating in Fing’s Université de printemps (Spring University) entitled Plus longue la vie (A Longer Life). As you can tell by the subject matter, it’s about aging and the role of new technologies in the life of seniors, which is great for me because it adds yet another piece to the puzzle that I’m currently working on. Last year, plot worked with France Cadet, the Hacking Lab, Christian Graff and the students of the ESAA on interfacing with electric fish (cf. Workshop Mormyrophone™). Some interresting ideas emerged from that workshop, most notably Games For Mormyridae (cf. Mormyre-Pong) as well as biological random number generators. That’s the slippery part, and feeds nicely into the whole process of physicalization which I have been working on recently, especially the idea of biological computing using insects, à la crickets and moths. Also thanks to France, I will most probably be working sometime next year on making games for primates (Games For Gorillas). More on that later, but that’s the furry part. Also in progress, an ENIAROF for redesigning our anarchic form of play for the younger set. So it is only natural, now, that I turn my attentions to the question of abstract machines and play in the context of the ever-extending lifespan. Although all of the ateliers intersect the type of work I do, I’ll be participating in the atelier entitled Un habitat confortable et modulable, facilitateur de vie. The rest of the time I’ll probably just be napping because there is a lot of blah blah blah planned, which I have very little time or patience for.

31 May, 2008

Director[11] = #@§!

Filed under: rant, abstractmachine, code — Douglas Edric Stanley @ 14:26 pm

Ok, so now I’m really pissed. So I’ve bought the damn upgrade, simply because I have so many old projects languishing on this dying platform. I’ve also been getting email from people because some of these projects are online, and no longer work; and instead of saying, “Macromedia, er Adobe, couldn’t move its sorry ass for over two years to get this software working on your platform,” the alert instead says, “please contact the author,” which in its tone suggests that somehow I’m the one who can’t manage my own projects. Okay, okay, so that’s the way software works, fine. So I get the upgrade, figuring I’ll finally fix these problems.

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…

19 May, 2008

Workshop in Puglia

Filed under: atelier hypermedia, live, abstractmachine, code — Douglas Edric Stanley @ 14:12 pm

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.

8 May, 2008

Magic Marker versus Magic Screen

Filed under: rant, abstractmachine, code — Douglas Edric Stanley @ 23:44 pm

Also known as: Perceptive Pixel’s multi-touch marvel is no match against Tim Russert’s felt-tip pen. My favorite part is actually all the noise Russert makes as he drags out his chart ;-)

28 April, 2008

Dear diary…

Filed under: atelier hypermedia, abstractmachine, narcissus, code — Douglas Edric Stanley @ 22:14 pm

Just added a Twitter feed to my blog. I’ve been resisting for a while now, but finally gave in. I like how I can just grab bits and pieces of conversations, emails, code, ideas, documentation and so on, and throw them into the mix. And the size is right. Let’s try to give it a few weeks before giving up again. That, or before I plug my randomizer into Twitter… hey there’s an idea.

20 April, 2008

Conference

Filed under: atelier hypermedia, live, abstractmachine, code, concept — Douglas Edric Stanley @ 14:43 pm

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

18 April, 2008

Embedded Fonts

Filed under: atelier hypermedia, abstractmachine, code, design — Douglas Edric Stanley @ 17:17 pm

I’m currently playing about with Safari 3.1’s embedded font feature. It’s great, and about time. If you’re reading this blog directly from my website and with Safari 3.1+ then you know what I’m talking about. Otherwise, you’ll just have to wait until Firefox and Explorer catch up.

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.

14 April, 2008

Plot’s Mountain Getaway

Filed under: workshop, atelier hypermedia, abstractmachine, code, plot — Douglas Edric Stanley @ 09:31 am

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.

Plot Voyager Map

9 April, 2008

Le mythe de la mite

Filed under: thesis, abstractmachine, code, concept, podcast, physicalization — Douglas Edric Stanley @ 21:07 pm

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.

30 March, 2008

L’orientation algorithmique

Filed under: workshop, live, abstractmachine, code, physicalization — Douglas Edric Stanley @ 11:45 am

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.

Next Page »