Alex McLean

Neural magazine interview on live coding (2007)

2012-05-26T18:34:47Z

Here’s an interview which appeared in the excellent Neural magazine in June 2007 (issue 27). A scan is also available.

Live Coding: I think in text
Alex McLean

Alessandro Ludovico: The term ‘live coding’ is usually meant to
describe the coding of music on the fly. It seems a process of
unveiling the (running) machine to manipulate it, resounding
accordingly. Which are your main concerns while performing live?

Alex McLean: When it’s good I have no concerns, and can just get on
with developing the music. I’m really just switching focus between
what Ade and Dave (the other ‘slub’ members) are doing and what I’m
adding to that. Whether I need to stop doing something to give them
room, or whether they’re reaching a conclusion with their stuff and I
need to get ready to take the lead with some new code.

AL: Live coding is “deconstructing the idea of the temporal dichotomy
of tool and product” as it’s stated in the TOPLAP website. So the
tool mutates in to a product. In your opinion is it regaining its
status of magmatic digital data? Or is it mutating into a hybrid
powerful machine-oriented code?

AM: I’m not sure what you mean by ‘magmatic digital data’. I think
though that live coding isn’t about tools or products, but instead
about languages and musical activity. Tool doesn’t really come into
it.

With the commercial model it goes:

[code] -> compiled -> [tool] -> used -> [music]

the dichotomy comes because the person making the tool is different
from the person making the music.

With livecoding it goes

[code] -> interpreted -> [music]

where the code is modified to change the music.

So the code and the music comes closer together by missing out the
tool stage. Of course the big secret about the commercial model is
that a lot of the music comes from the code, as compiled into the
tool. As Kim Casone says, "The tool is the message." Well in the
case of livecoding the tool isn't the message - there is no tool. The
code is the message! And the music is the message... And the music is
the code...

AL: And how do you feel the ambivalent code evolution / music so
generated? Is it a parallel (but conceptually linked) flow or a
digital cause/effect relationship?

AM: There is a feedback loop. The livecoder writes code, that makes
sound, which the livecoder hears and perceives as music, which they
then react to, by editing the code. The code is a kind of notation for
the music. Unlike traditional notation the code describes the sound
completely, because it is read by a formal interpreter that is in turn
described as code. Lovely!

AL: Changing the code while it runs seems similar to composing phrases
on the fly (as we humans are used to do). Do you think that live
coding has some 'semiotic' characteristics that can be compared to
poetry live improvising?

AM: No, but I believe it will go in this direction. In fact I have
become very interested in articulatory speech synthesis, which makes
sound from models of the human body. My current research project is
to apply techniques from speech synthesis to musical sounds, not
necessarily human-like sounds. There is rich history of people talking
about writing down musical sounds as 'vocable' words, for example
Canntaireachd for bagpipe and Bols for tabla sounds. I want to make a
synthesis system for livecoding so I can type the word
"krapplesnaffle" and have it turned into sound and immediately placed
into livecoded rhythmic structure. [http://speechless.lurk.org/]
contained my experiments towards this...

AL: Another key point of live coding performances it to have no backup
(MiniDisc, DVD, safety net computer). Is this meant to legitimate the
(eventual) accident as a part of the performance?

AM: Yes, a little danger is good, adding an edge to the performance
both for us and the audience... There are three of us though, and if
one of our systems go down the others can take over. Then the
audience has some fun watching our boot up procedure :)

AL: You also used to play live (as half of 'slub' band) with your own
'command-line music'. Why you choosed to use the minimal command line
interface? Which software was involved?

AM: Correction: since 2006 there are now three of us: Adrian Ward,
Dave Griffiths and myself Alex McLean. I use the UNIX shell because I
think in text. It's fast, there's a beautiful relationship between
data and code, and it's easy to recall and modify past actions - you
don't have to repeat yourself all the time like with GUIs. When
interactive commandline shells were first developed they were called
"conversational languages," part of a field of research called
"conversational computing." It's a shame that this terminology fell out
of use.

AL: What's 'moving' in your performance is not an arm that plays a
violin, but the shape of your algorithms, forcing your fingers to move
fast on the keyboard. Even if this is barely seen by the audience,
there's a gesture, more evident and theatrical than the usual laptop
performance. How important do you consider the gesture in your live
set?

AM: Well, livecoders always project their screens, so people can see
the typing gestures, which I think are really beautiful even if you
can't see the fingers that are typing them. Jaromil and Jodi's "time
based text" (http://tbt.dync.org/) highlight this really well. AS
there are three of us improvisers there are human gestures between us
too. I think all this is important, if you can see someone is on
stage, but you can't see any movement making the music, then there is
no performance.

AL: Performing live coding, you feel to purely "improvise"? Here, do
you feel a substantial difference with the improvisation music school?
If yes, which one?

AM: Improvisation is the creation of work while it is being performed,
so it's clear that livecoding is a form of that. I have had really
enjoyable improvisations with vocalists, guitarists, rappers and
drummers as well as other laptopists, so don't see much
difference. The only real difference is that livecoding is quite new,
and I think has a bit more developing to do...

AL: TOPLAP (whose acronym has a number of interpretations, one being
the Temporary Organisation for the Proliferation of Live Audio
Programming) is advocating live coding practices in different areas.
In its 'draft' manifesto it's written: "Programs are instruments that
can change themselves." Do you think that software is the ultimate
music instrument?

AM: No I don't. I think computer languages are great mediums for
making instruments though, and livecoding allows you to change those
instruments while you're playing them in some interesting ways. But
you can make amazing sounds with an egg whisk. Who am I to say that
Perl or Haskell is better than an egg whisk? In fact if I was to pick
an ultimate instrument I think the human voice would be it.

AL: The TOPLAP crew also stated that they advocate the "humanisation
of generative music." What's wrong with 'classic' generative music
software?

AM: According to Brian Eno, generative music is like making seeds and
sitting back seeing what they produce. There's nothing at all wrong
with this idea, I love gardening. But livecoding is something a bit
different - it's instead more like modifying the DNA of plants while
they're growing, by hand. In this way, generative music is nature and
livecoding is nurture, in fact it's possible to have a combination of
the two.

Slow

2012-05-23T10:25:37Z

Another cog

2012-05-20T20:58:30Z

Cog

2012-05-16T09:24:47Z

Starting to record music again..

Live interfaces: Performance, Art, Music conferece

2012-05-11T21:44:09Z

Happily we’ve been awarded some funding for a conference on live performance technology from Vitae Yorkshire! This will be a great start to my new position in ICSRiM. Here’s the call:

LIVE INTERFACES
Performance, Art, Music
http://icsrim.org.uk/liveinterfaces/

Date: 7th-8th September, 2012
Venue: ICSRiM, School of Music, University of Leeds, UK

CALL FOR PAPERS AND PERFORMANCES

Live Interfaces is a conference on live, technology-mediated interaction in performance. The conference seeks to investigate cross-disciplinary understandings of performance technology with a particular focus on issues related to the notion of ‘liveness’ in interaction.

Live Interfaces will consist of paper and poster presentations, performances and workshops over two days. Researchers, theorists and artists from diverse fields are encouraged to participate, including: digital performance, live art, computer music, choreography, music psychology, interaction design, human computer interaction, digital aesthetics, computer vision, smart materials and augmented stage technology.

We invite submissions addressing the conference theme of technology-mediated live interaction in performance, and suggest the following indicative topics:

- Audience perception/interaction
- Biophysical sensors
- Brain-computer interfaces
- Computer vision/real-time video in performance
- Cross-modal perception/illusion
- Digital dramaturgy/choreography/composition
- Digital performance phenomenology
- Gesture recognition and control
- Historical perspectives
- Live coding in music, video animation and/or dance
- Participatory performance
- Performance technology aesthetics
- Redefining audience interaction
- Tangible interaction

Paper submissions should be in extended abstract form, with a suggested length of 500 words. Please format all submissions using either the Word or LaTeX template available from the website.

Performance proposals should include a description of the performance and the live interaction technology used, as well as a list of technical requirements. Attaching recordings of past performances is strongly encouraged.

We hope to announce a journal special issue on performance technology following the conference as a publication opportunity for extended papers.

Extended abstracts must be submitted electronically via the website by midnight (GMT+1) on the 17th June 2012. All submissions will be subject to cross-disciplinary peer review, and notified of acceptance by 1st July.

Please address all queries to liveinterfaces@icsrim.org.uk

Key dates:

- 17th May – Submissions system open
- 17th June – Submission deadline
- 1st July – Notification of selected papers/performances
- 29th July – Camera-ready deadline for accepted papers
- 7-8th September – Conference

Registration will open nearer the date, with a fee in the region of £25, including lunch for both days.

Please keep an eye on one of the following for updates, including information on conference workshops and co-located events.

Website: http://icsrim.org.uk/liveinterfaces/
Facebook: http://facebook.com/liveinterfaces/
Twitter: http://twitter.com/liveinterfaces/
Identica: http://identi.ca/liveinterfaces/

Planning committee:
Alex McLean, University of Sheffield, University of Leeds (from August)
Kate Sicchio, University of Lincoln
Maria Chatzichristodoulou, University of Hull
Scott Hewitt, University of Huddersfield
Ben Dornan, University of Sheffield
Stephen Pearse, University of Sheffield
Phoebe Bakanas, ICSRiM, University of Leeds
Ash Sagar, York St Johns University

Senior advisor:
Kia Ng, Director of ICSRiM, University of Leeds

Supported by Vitae Yorkshire, the University of Leeds and the Arts and Humanities Research Council

Computer Music Journal – Special Issue on Live Coding – Call for Submissions

2012-04-24T12:52:08Z

I’m guest editing an issue of the Computer Music Journal on live coding together with Julian Rohrhuber and Nick Collins. Really excited about this already, despite the submissions deadline being some eight months away from now.. The call for proposals is below.

We are excited to announce a call for papers for a special issue of Computer Music Journal, with a deadline of 21st January 2013, for publication in Spring of the following year. The issue will be guest edited by Alex McLean, Julian Rohrhuber and Nick Collins, and will address themes surrounding live coding practice.

Live coding focuses on a computer musician’s relationship with their computer. It includes programming a computer as an explicit onstage act, as a musical prototyping tool with immediate feedback, and also as a method of collaborative programming. Live coding’s tension between immediacy and indirectness brings about a mediating role for computer language within musical interaction. At the same time, it implies the rewriting of algorithms, as descriptions which concern the future; live coding may well be the missing link between composition and improvisation. The proliferation of interpreted and just-in-time compiled languages for music and the increasing computer literacy of artists has made such programming interactions a new hotbed of musical practice and theory. Many musicians have begun to design their own particular representational extensions to existing general-purpose languages, or even to design their own live coding languages from scratch. They have also brought fresh energy to visual programming language design, and new insights to interactive computation, pushing at the boundaries through practice-based research. Live coding also extends out beyond pure music and sound to the general digital arts, including audiovisual systems, linked by shared abstractions.

2014 happens to be the ten-year anniversary of the live coding organisation TOPLAP. However, we do not wish to restrict the remit of the issue to this, and we encourage submissions across a sweep of emerging practices in computer music performance, creation, and theory. Live coding research is more broadly about grounding computation at the verge of human experience, so that work from computer system design to exposition of live coding concert work is equally eligible.

Topic suggestions include, but are not limited by:

Programming as a new form of musical exploration
Embodiment and linguistic abstraction
Symbology in music interaction
Uniting liveness and abstraction in live music
Bricolage programming in music composition
Human-Computer Interaction study of live coding
The psychology of computer music programming
Measuring live coding and metrics for live performance
The live coding audience, or live coding without audience
Visual programming environments for music
Alternative models of computation in music
Representing time in interactive programming
Representing and manipulating history in live performance
Freedoms, constraints and affordances in live coding environments

Authors should follow all CMJ author guidelines, paying particular attention to the maximum length of 25 double-spaced pages.

Submissions should be received by 21st January 2013. All submissions and queries should be addressed to Alex McLean <alex.mclean@icsrim.org.uk>

We have no idea what we are doing: exclusion in free software culture

2012-04-10T14:28:02Z

The following is a live post which includes some strong statements which I might temper later. If anyone asks, I do know what I’m doing and understand recursion just fine.

There’s an interesting thread on the eightycolumn mailing list on gender and exclusion in free software, which has prompted me to write up some thoughts I’ve been having on why programming cultures have such a problem with diversity.

In particular, I have come to the conclusion that programmers have no idea what they are doing. Actually I think it is generally true; people have no idea what they are doing. We all do things anyway, because knowledge and practice can be embodied in action, rather than being based entirely on theory. But we find this idea uncomfortable somehow, so come up with somewhat arbitrary theories to structure our lives. For example floor traders have algorithms that they follow when making their decisions, but if they take them too seriously the result is a market crash, because they are following models rather than ground truths. (World leaders are also known to externalise their decisions when confronted with the unfathomable, with catastrophic results.)

When it comes to programming, there are all manner of pseudoscientific theories for software development, but humans really lack the powers of introspection to know what programming is and how we do it. That’s a pretty wonderful thought, really, that we can construct these huge systems together without understanding them. However when you’re learning programming, it can result in a pretty scary leap. We have mathematical theory from computer science, and the half-arsed broken metaphors around object orientation, and the constraints of strict interpretations of agile development (which no-one actually adheres to in practice), and learners might get the impression that somehow internalising all this theory is essential before you can start programming. No it isn’t, you learn programming by doing it, not by understanding it! Programs are fundamentally non-understandable.

As an example, I seriously doubt whether we can really grasp the notion of recursion, at least without extensive meditation. But we don’t have to, we just internalise a bunch of heuristics that allow us to feel our way around a problem until we have a solution that works. In the case of recursion, we focus on single cases and terminating conditions, but I don’t think this is understanding recursion, it’s using a computer as cognitive support, to reach beyond our imagination.

Another example is monads, computational constructs often beloved by Haskell programmers. It’s fascinating that those new to Haskell gain an intuition for monads through a lot of practice, then come up with a post-hoc theory to structure that intuition, and then invariably write a tutorial based on that theory. However that tutorial turns out to be useless for everyone else, because the theory structures the intuition (or in Schön’s terms, knowledge-in-action), and without the intuition, the theory is next to useless.

Anyway, returning to my actual point.. To learn programming is to embark on years of practice, learning to engage with the unknowable, while battling with complex and sometimes unhelpful theory. With such barriers to entry, no wonder that it seems so very easy to exclude people from developer communities. Of course this just means we have to try harder, and I think part of this involves rethinking programming culture as something grounded in engaged activity as well as theory.

Live Notation first performance

2012-04-05T05:59:34Z

A couple of weekends ago I collaborated on a performance with Hester Reeve at the LoveBytes festival for the Live Notation project.

As I was struggling with my new “smoothdirt” live coding language, Hester moved around the cinema carrying out actions including with bells, pebbles in her mouth and a large rock. This aspect seems like a form of live ritual; developing rituals while following them. We had decided that the performance should be an engagement through sound, and without any technologically mediated connection beyond microphone and loudspeakers.

I used a wireless keyboard with the cinema as my screen, and had planned to move around more while playing with the multi channel sound in the cinema, but the audience was unexpectedly large, and so I settled in the seats at the front. This meant I missed out on seeing much of what Hester was up to, and the interaction was just through sound.

This was an experimental performance in that there was no rehearsal and it was certainly possible that it could have been a failure. It wasn’t that in my eyes, but I wish I could know what the audience’s experience of it was, good and bad. For me it was a struggle, but in the way that it should have been for a research performance — I was learning a new way of working, with new software I have written but have not yet properly understood. I think the experience was similar with Hester, whose work had not foregrounded sound in this way before. I wonder how much of this the audience picked up on.

In the end time passed very quickly for me, and at some point Hester completed her live work and decided to sit next to me, while I brought the music to a conclusion. The music by the way was intended to shift between “grid-based” techno and smoother textures, using the quadrophonic system to contrast and integrate these themes. This is what I’m writing smoothdirt for, and I’m really happy that I got enough of my ideas working to form the basis of my part of this performance.

Most of all though this collaboration is opening up a broader understanding for what performing with programming languages means. We’ll be discussing this, alongside perspectives from the “other side” of live artists, at an event in London on April 19th, I’m really looking forward to seeing where all this leads.

Fellowship

2012-03-22T23:35:36Z

I’m excited to be joining Kia Ng in the Interdisciplinary Centre for Scientific Research in Music (ICSRiM) within the faculty of Performance, Visual Arts & Communications (PVAC) for the new academic year, as a two year fellowship.

I’ll be a research fellow in Human/Technology Interface, a research strand supported within the cross disciplinary Culture, Society & Innovation Hub.

All very central to my interests, the ideal context for developing embodied approaches to live coding, perhaps. I’m really looking forward to getting started, although it won’t be for another four months or so..

smoothdirt

2012-03-14T17:19:24Z

I’ve got some sounds out of my new live coding system, codenamed “smoothdirt”. Here’s an mp3 for you. The sounds are triggered with some C and structured and scheduled with some Haskell. Plenty more to do, but already really happy hearing embedded juxtoposition of timescales, smooth multichannel panning (2 channels in this test, but I’m playing on a quadrophonic cinema soundsystem at lovebytes) and sample accuracy, which I test at the end by playing a kick drum sample a lot.

My new representation also allows me to treat musical structure as both a discrete pattern and a continuous signal, which I’m very happy about, but haven’t explored the depths of yet..

Anyway with a few tweaks and effects it’ll be ready for the algorave in London this weekend.