Novels are digital art too

April 12th, 2011

The striated and the smooth

Digital means discrete, and analog means continuous. Digital and analog support each other, as
Deleuze and Guattari put it:

… in the case of the striated, the line is between two points, while in the smooth, the point is between two lines.

When we speak, we articulate our vocal tracts in analog movements, creating discontinuities that the listener is able to segment into the digital phonemes, diphones and words of language.  Language is digital, as is clear when we write it with a typewriter.  The analog arrangement of ink on paper is woven into a perfectly discrete sequence of symbols, as our eyes saccade across them.  But we reconstruct the analog movements of speech when we read; even when we read silently, we add paralinguistic phrasing in our heads to aid processing of the text.  This analog phrasing is important, for example modulating the tone of voice with slight sarcasm tone can completely negate the meaning of what is said.  Prosody can convey far subtler emotional feeling that this.

A great deal of what is called `digital art’ is not digital art at all, and it seems many digital artists seem ashamed of the digital.  In digital installation art, the screen and keyboard are literally hidden in a box somewhere, as if words were a point of shame.  The digital source code behind the work is not shown, and all digital output is only viewable by the artist or a technician for debugging purposes.  The experience of the actual work is often entirely analog, the participant moves an arm, and observes an analog movement in response, in sight, sound or motor control.  They may choose to make jerky, discontinuous movements, and get a discontinuous movement in response, but this is far from the complexity of digital language.  This kind of installation forms a hall of mirrors.  You move your arm around and look for how your movement has been contorted.

This is fine, computers allow abstractions away from particular perceptual modes and senses, and so are quite good at translation between modes.  But computers really excel as machines for formal language, and so I hope the practice of hiding linguistic computation in `digital art’ will be a short lived fashion.

Pitter split

April 6th, 2011

More live coding, this time multitrack (oops added wrong one earlier, fixed now):

Some glitches, with audio and video falling out of sync at times… I quite like the results though, as it goes back in again somehow.

UPDATE, here’s another one, with tight time sync this time:

Pitter patter

April 4th, 2011

Experimenting with webcam overlay. Video recorded using gstreamer, source for screencaster here (screensave.c).

UPDATE, here’s another from a different angle to appease douglas.

Cyclic revision control

March 30th, 2011

There is something about artist-programmers, the way they’re caught using general purpose languages and tools in specific, unusual circumstances.  Many of the basic assumptions underlying the development of these general purpose systems, such as errors are bad, the passing of time need not be structured only minimised, standards and pre-defined plans are good, etc, often just don’t apply.  It’s not that artist-programmers can get away with being bad programmers.  Far from it, in my opinion they should be fluent with their language, it’s no good being baffled by syntax errors and spaghetti code while you’re trying to work out some weird idea.  However if you are following your imagination as part of a creative process, then established and fashionable software development methods often look arbitrary and inhibiting.

The last few days I’ve been thinking about revision control.  Revision control systems are really excellent and have a great deal to offer artist-programmers, particularly those working in groups.  What I’ve been wondering though is whether they assume a particular conception of time that doesn’t always apply in the arts.

Consider a live coder, writing software to generate a music performance.  In terms of revision control they are in an unusual situation.  Normally we think of programmers making revisions towards a final result or milestone, at which point they ship. For live coders, every revision they make is part of the final result, and nothing gets shipped, they are already the end users.  We might somewhat crassly think about shipping a product to an audience, but what we’re `shipping’ them isn’t software, but a software development process, as musical development.

Another unusual thing about live coding revisions is that whereas software development conventionally begins with nothing and finishes with a complete, complex structure, a live coder begins and ends with nothing.  Rather than aim for a linear path towards a predefined goal, musicians instead are concerned with how to return to nothing in a satisfying manner.  Indeed perhaps the biggest problem for Live Algorithms is the problem of how to stop playing.  The musician’s challenge is both how to build and how to deconstruct.

There are two ways of thinking about time, either as a linear progression and as a recurrent cycle or oscillation.  Here’s a figure from the excellent book Rhythms of the Brain by György Buzsáki:

“Oscillations illustrate the orthogonal relationship between frequency and time and space and time. An event can repeat over and over, giving the impression of no change (e.g., circle of life). Alternatively, the event evolves over time (pantha rei). The forward order of succession is a main argument for causality. One period (right) corresponds to the perimeter of the circle (left).” (pg. 7)

This illustrates nicely that these approaches aren’t mutually exclusive, they’re just different ways of looking at the same thing.  Indeed it’s normal to think of conventional design processes as cycles of development, with repeating patterns between milestones.  It’s not conventional to think of the code itself ending up back where it started however, but this can happen several times during a music performance, we are all familiar with chorus and verse structure for example, and performances necessarily begin and end at silence.

So where am I going with this?  I’m not sure, but I think there’s plenty of mileage in rethinking revision control for artist-programmers.  There’s already active, radical work in this area, for example the code timeline scrubbing in field looks awesome, and Julian Rohrhuber et al have some great research on time and programming, and have worked on non-linear scheduling of code changes in SuperCollider.

As far as I can see though, the revision control timeline has so far been treated as a linear structure with occasional parts branching and remeeting the main flow later on.  You do sometimes get instances of timelines feeding back on themselves, a process called backporting, but this is generally avoided, only done in urgent circumstances such as for applying security fixes to old code.

What if instead, timelines were of cycles within cycles, with revision control designed not to aid progression towards future features, but help the programmer wrestle their code back towards the state it was in ten minutes ago, and ten minutes before that?  Just questions for now, but I think there is something to be done here.  After all, there is something about artist-programmers, the way they’re caught using general purpose languages and tools in specific, unusual circumstances.

Languages are Languages – follow up

February 23rd, 2011

There are some interesting comments to my “languages are languages” post that I wanted to highlight — a disadvantage of blogs is that comments are often the best bit but are subservient to the posts they are on.  I also brought the subject up on the PPIG (Psychology of Programming Interest Group) mailing list, again prompting some enlightening discussion.

By the way, PPIG are holding a Work In Progress meeting here in Sheffield from the 18th-19th April.  A call for abstracts is out now.  Heartily recommended!

Languages are languages

February 18th, 2011

Ian Bogost has an interesting argument that computer languages are not languages,  but systems.

He starts off arguing that learning a programming language shouldn’t meet a curricular requirement for learning a natural language.  That’s a fair argument, except he does so on the basis that computer languages are not languages at all.

”the ability to translate natural languages doesn’t really translate (as it were) to computer languages”

It clearly does translate.  You can either translate literally from C to Perl (but not really vice-versa), or idiomatically.  It’s straightforward to translate from C to English, but difficult to translate from English to C.  But then, it’s difficult to translate a joke between sign and spoken language; that doesn’t mean that sign language isn’t a language, indeed sign languages are just as rich as spoken ones…  The experience of signing is different from speaking, and so self-referential jokes don’t translate well.

We can approach translating from English to C in different ways though.  We can model the world described in a narrative in an object oriented or declarative fashion.  A human can get the sense of what is written in this language either by reading it, or perhaps by using it as an API, to generate works of art based on the encoded situation.  Or we could try to capture a sense of expectation in the narrative within temporal code structure, and output it as music.

From the comments:

”If we allow computer languages, we should allow recipes. Computer codes are specialized algorithms. So are recipes.”

This seems to be confusing utterances with languages.  Recipes are written in e.g. English.  Computer programs are written in e.g. C.

“[programming code is] done IN language, but it ISN’T language”

You could say the same of poetry, surely?  Poetry is done in language, but part of its power is to reach beyond language in new directions.  Likewise code is done in language, but you can also do language in code, by defining new functions or  parsing other languages.

The thing is that natural languages develop with a close relationship with the speaker, words being grounded in the human experience of their body and environment, and movements and relationships within it.  Computer languages aren’t based around these words, but we can still use the same symbolic references by using those words in the secondary notation of functions names and variables, or even by working with an encoded lexicon such as wordnet as data.  In doing so we are borrowing from a natural language, but we could just have easily used an invented language such as Esperanto.  Finally the language is grounded in the outside world when it is executed, through whatever modality or modalities its actuators allow, usually vision, sound and/or movement.

… replacing a natural language like French with a software language like C is a mixed metaphor.

Discussing computer language as if it were natural language surely isn’t a mixed metaphor, if anything it’s just a plain metaphor.  But both have strong family resemblances, because both are languages.

The claim that computer languages are not languages reads as an attempt to portray computer languages as somehow not human.  Get over it, digital computation is something that humans do with or without electronic hardware, we can do it to engage fully with all of our senses, and we can do it with language.  Someone (who I keep anonymous, just in case) said this on a mailing list recently:

“Having done a little bit of reading in Software Studies, I was surprised by just how many claims are invalidated with a single simple example of livecoding.”

I think that this is one of them.

The tyranny of deadline extensions

February 7th, 2011

At least in my world, it has become normal and expected for deadlines to be extended by around a week. The only explanation given is something like ‘numerous requests by authors’. However I get the strong impression that the paper committees always intended to extend the deadline, and built it into their only schedules. So many conferences do this now that it is expected; I suspect that if a conference didn’t, they would get very few submissions.

There are particular conference seasons, and so often deadlines fall around the same date. This uncertainty can cause a lot of scheduling problems. It can also annoy those organised folks who work to original deadlines.

Most recently, a Monday deadline extension to the following Friday wasn’t announced until the Friday before. Until it was announced, I was wondering how much time I would be able to spend with my family over that weekend. To get around this kind of thing a couple of times, I have written to paper chairs a week or so before a deadline, politely asking whether their deadline will be extended, saying I have a tricky schedule. This worked once, although the other time I didn’t get a reply (unsurprisingly, the workload of a paper chair is unenviable).

So I propose a different approach; that deadline extensions are announced alongside the original deadlines, in the original call for proposals.

Obviously this makes no sense, but we (Nick Collins, Thor Magnusson and I) are trying it anyway in our call for video submissions, and it’ll be interesting to see how well it works. By pre-announcing the extension but being vague about what it will be, hopefully people will put the original deadline in their calendars and work to that. However while doing tricky scheduling they’ll be able to keep the extension in mind and avoid unwarranted stress…

Workshop output

February 7th, 2011

The Text live coding workshop went really well, surprisingly well considering it was the first time anyone apart from me had used it and (so I found out after) most of the participants didn’t have any programming experience. The six participants took to the various combinators surprisingly quickly, the main stumbling block being getting the functions to connect in the right way… Some UI work to do there, and I got some valuable feedback on it.

Once the participants had got the hang of things on headphones, we all switched to speakers and the seven of us played acid techno for an hour or so together, in perfect time sync thanks to netclock. Here’s a mobile phone snippet:

The sound quality doesn’t capture it there, but for me things got really interesting musically, and it was fun walking around the room panning between the seven players…

Text update and source

January 31st, 2011

I’ve updated Text a bit to improve the visual representation of higher order types (you’d probably need to full screen to view):

I won’t be touching this until after the workshop on Saturday.

I’ve also made the source for the visual interface available here under the GPLv3 free license. To get it actually working as above you’d also need to install my tidal library, Jamie Forth’s network sync, my sampler, the nekobee synth, and somehow get it all working together. In short, it’s a bit tricky, I’ll be working on packaging soonish though.

Test run of Text

January 28th, 2011

I’ve been rather busy writing lately, my PhD funding runs out in April, and I hope by then I’ll have finished and will be looking for things to do next.

I have had a bit of time to make Text, a visual language I mentioned earlier, a bit more stable, here’s a test run:

A bit of a struggle, partly due to the small screen area I gave myself for the grab, but also due to some UI design issues I need to sort out before my workshop at Access Space in Sheffield next week, on the 5th February. Access Space is a really nice free media lab, but will turn nasty unless I free the workshop software, so expect a release soon.

In case someone is interested, here’s the linux commandline I use to record a screencast with audio from jackd:


gst-launch-0.10 avimux name=mux \
! filesink location=cast.avi \
ximagesrc name=videosource use-damage=false endx=640 endy=480 \
! video/x-raw-rgb,framerate=10/1 \
! videorate \
! ffmpegcolorspace \
! videoscale method=1 \
! video/x-raw-yuv,width=640,height=480,framerate=10/1 \
! queue \
! mux. \
jackaudiosrc connect=0 name=audiosource \
! audio/x-raw-float,rate=44100,channels=2,depth=16 \
! audioconvert \
! queue \
! mux.