nicolas @ uucidl

Luke Dubois: software for live performances

August 12, 2009 by nicolas, tagged programming and art_and_code, filed under commentary

A MAX/MSP/Jitter showcase by Luke Dubois.

Luke Dubois first tells us how he started using laptops and MAX/MSP in the context of a band – Freight Elevator Quartet, – replacing unreliable analog synthesizers with the cold digital precision of software audio synthesis.

This in itself however raised a question, a challenge that any live laptop performer faces: watching someone play on a laptop is not very exciting and pleasurable.

He qualifies live performances as transparent or opaque: transparency denotes how manifest the source and action of a performance are. A transparent performance clearly links actions and their results. And very often, the performance of operators behind their laptop suffers from a high level of opacity¹.

A laptop – unlike a musical instrument such as a violin – is a profane object. Audience members use it daily to communicate, listen to music, watch movies, compute their taxes or play video games. Its operation in itself raises the doubt that the performance really exists and what it consists of. After all, the performer could very well be checking their mails while an audio file is playing.

In summary, Luke Dubois characterizes a live performances according to:

  1. its opacity / transparency
  2. how profane / sacred is is perceived

I would add an additional axis to this list. Audio/visual/physical manifestations used throughout a performance have to be in harmony: how "physically consistent" the actions are with their results ; for instance, a great motion should result or respond to an equally powerful sound, and harsch visuals to distorted audio.

To increase transparency of the performance MAX/Jitter enables the laptop performer to manifest himself within other channels (controlling lights, video, even actual objects on stage) than audio only.

Regarding how profane a laptop is perceived:

Unfortunately adding a fruit on the cover of the laptop is not sufficient to make it sacred! In contrast, a violin is from the start made to be used during the "ceremony" and for its enjoyment. And as the doubt is raised that a performance is taking place, it needs to be dealt with with a proof: for example, interactivity with the audience such as letting it alter the visuals used in the performance.

Then as an introduction in the world of MAX, Luke Dubois shows live the typical "Hello, World" of MAX/MSP, a simple automata emitting a sequence of random notes².

At this point we drift off a little bit and his talk is starting to feel aimless, although he does a good job of introducing the basics and advantages (simplicity, enable musicians to program) of MAX and its various applications³.

¹ easily the most interesting topic he covered, in a too short and very superficial way. The problems of building enjoyable and meaningful performances. The problems caused and solved by the introduction of computers and videos in such performances. Those are very important topics to cover when you are interested in the use of code (and thus computers) in these contexts.

² at this point in his talk we were reminded by how our own attempt at generating musical structure from automatas. One big problem with automatas is that they never know when to stop. They always have enough energy to proceed to the next step and will never on their own stop producing whatever it is they were producing. Would introducing the concept of an energy source solve this problem? We doubt this would be sufficient. It seems however necessary, for no process in the world goes on continously and feel natural. (There are counter examples however.. What about the sun? What about rivers?)

³ we liked: his project with a performance artist who was instructed to do a 72 hours performance, in which she was playing the role of a woman preparing off before a date. The 72 hour performance was in the end to be accelerated down to a 72 minutes video. The performance itself thus had to be done as slowly as humanly possible — 60x slower? — The result would be at a realistic speed for the performer, and as a blurry show of colour for the background, as the piece is done outside.

ART+Code: Golan Levin ― Introduction

August 9, 2009 by nicolas, tagged programming, litteracy and art_and_code, filed under commentary

on software literacy

I’m kicking off a series of summaries and commentaries of the ART+Code conference talks. The conference was organized in Pittsburgh in March 2009. It presented many programming environments, with a focus on how programming tools might help more people, and in particular children learn programming.

ART+Code’s conference-founder Golan Levin is starting up by asking why¹ we should all be programming.

It starts with an observation: we interact with software more and more regularly; be it in appliances, on the internet, or even within administrations or work. As a consequence, software in general has taken an increasingly important place. Computer and software literacy has however not developed as much: while using software is a common activity, writing software is much less so.

In contrast with writing, most people don’t program for self-expression. The population has not made writing software part of everybody’s toolset. Meanwhile, with the exception of Free Software/Opensource, software has become more opaque and challenging than ever: you can’t pick it apart, like you can do with a hardware device.

Software litteracy is generally sought after in order to get a job, and in general for economical reasons.

And despite the pioneers who started writing artistic software in the early days of computer science in 1960 and beyond, software engineers and companies themselves do not acknowledge the existence of such programs.

For example, there is no category for "Artistic" software in Apple’s Application Store. Non-utilitarian or purely artistic software are largely ignored².

Demosceners know this problem too, as there’s no place for demos in the application store either, nor is the population in general aware of them.

This also shows a problem with distribution of such software. The demoscene has historically been a way to answer this: A set of — originally peer to peer, nowadays centralized — traditions and technical mechanisms to distribute purely artistic software.

In the context of the ART+Code conference each talk will show that one programming environments is not often separable from its community.

Programming for one’s own self expression is different from the more traditional view of solving computer science problems, or the "filing" type of applications prevalent nowadays in most companies.

For this reason and since they show no willingness to touch the general public, teaching programming should not be a monopoly of computer science departments³.

¹ talking about literacy, when we say of someone he is literate we do not simply mean he is able to read and write a few administrative letters. There is a certain expectation on the resulting works. The quality of the software we write should remain important even if programming becomes popular.

² save ifart or screensavers. Note that we group most games here amongst utilitarian software, although the boundary with artistic software is not so straightforward to define.

³ the early home computer demoscene played that role in the 80s and 90s in europe. Kids learned programming, motivated by the energy they saw in demos encountered in their use of computers: as they shared programs with one another, they would invariably encounter a demo amongst the pirated game disks. Today’s sanitized, heavily categorized software environment, the advent of the internet and the advent of online gated communities distanced end users from such serendipitous encounters.