abstractmachine

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 ;-)

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.

• Conference: Des idées et des arts
• Location: Amphithéâtre Charve, Université Saint Charles, Marseille
• Address: 3, place Victor Hugo 13003 Marseille
• Un séminaire du Master Médiation Culturelle des Arts, Université de Provence, Marseille
• Dates: 21, 28 April 2008; 5 May 2008
• Time: 17.00 - 19.30

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 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.

• Workshop : Plot à la montagne
• Location : Pyrenees Aix-en-Provence, France
• Artists : Fabrice Gallis, Guillaume Stagnaro, Jean + Cristofol, Douglas Edric Stanley
• Dates : 14 - 18 April, 2008

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.

• Reading : Le mythe de la mite: vers une mite-ology de l’informatique
• Text + voice : Douglas Edric Stanley
• Series : Mythologies 2008; Ma foi ! Croyances, religions, identités
• Producer : Marc Voiry
• Station : Radio grenouille, 88.8, Marseille
• Date : 9h30, 7 avril 2008
• Download : mp3-mythologie-stanley-bug

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.

• Workshop: L’orientation algorithmique
• Location: Institut d’arts visuels, Orléans, France
• Artist: Douglas Edric Stanley, www.abstractmachine.net
• Dates: 31 March - 4 April, 2008

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.

• Workshop: Art du code
• Location: l’École des beaux-arts de Bordeaux
• Dates: 19 | 20 | 21 March 2008

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.

I’ve been working with two very handy C++ development libraries over the last two weeks: OpenFrameworks and PAlib. We started working with OpenFrameworks in the Atelier hypermédia last week — I’ll write more about that later. As for the other library, most of you probably will never have heard of it: PAlib is a library for Nintendo DS homebrew development which I ignored for too long. Antonin told me about it ages ago, I should have listened. It’s been a godsend for getting back into development for the Nintendo handheld platforms. And it’s amazingly easy to use, once you’ve gotten everything configured correctly (see below).

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

• Article: Purpose Machines, Douglas Edric Stanley
• Journal: Switch 24

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.