Archive for the ‘livecoding’ Category

« Older Entries

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

Tuesday, April 24th, 2012

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>

Posted in livecoding | No Comments »

Live Notation first performance

Wednesday, April 4th, 2012

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

Live Notation _MG_6692

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.

Live Notation _MG_6684

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.

Live Notation _MG_6817

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.

Live Notation _MG_6824

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.

Posted in livecoding | No Comments »

smoothdirt

Wednesday, March 14th, 2012

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.

Posted in haskell, livecoding | No Comments »

PhD Thesis: Artist-Programmers and Programming Languages for the Arts

Wednesday, February 22nd, 2012

With some minor corrections done, my thesis is finally off to the printers.  I’ve made a PDF available, and here’s the abstract:

We consider the artist-programmer, who creates work through its description as source code. The artist-programmer grandstands computer language, giving unique vantage over human-computer interaction in a creative context. We focus on the human in this relationship, noting that humans use an amalgam of language and gesture to express themselves. Accordingly we expose the deep relationship between computer languages and continuous expression, examining how these realms may support one another, and how the artist-programmer may fully engage with both.

Our argument takes us up through layers of representation, starting with symbols, then words, language and notation, to consider the role that these representations may play in human creativity. We form a cross-disciplinary perspective from psychology, computer science, linguistics, human-computer interaction, computational creativity, music technology and the arts.

We develop and demonstrate the potential of this view to inform arts practice, through the practical introduction of software prototypes, artworks, programming languages and improvised performances. In particular, we introduce works which demonstrate the role of perception in symbolic semantics, embed the representation of time in programming language, include visuospatial arrangement in syntax, and embed the activity of programming in the improvisation and experience of art.

Feedback is very welcome!

BibTeX record:

@phdthesis{McLean2011,
    title = {{Artist-Programmers} and Programming Languages for the Arts},
    author = {McLean, Alex},
    month = {October},
    year = {2011},
    school = {Department of Computing, Goldsmiths, University of London}
}

RIS record:

TY  - THES
ID  - McLean2011
TI  - Artist-Programmers and Programming Languages for the Arts
PB  - Department of Computing, Goldsmiths, University of London
AU  - McLean, Alex
PY  - 2011/10/01

Posted in haskell, livecoding, music, papers, rant, texture, visualisation, vocable | 5 Comments »

Motivation

Wednesday, February 15th, 2012

Now here’s an hour well spent, Bret Victor giving a talk on “Inventing on Principle”:

He demos some really nice experiments in live interfaces, including some javascript live coding with a nice implementation of time scrubbing.  He uses this great work as an illustration for his main point though, which is about why he has done these things. He puts forward a vision of the inventor as someone who isn’t motivated by building a career, making a startup, or engineering challenges in industry or research, but clear moral principles.

Among others he mentions Richard Stallman, which reminded me of the MOTIVATION file that comes with emacs.

Anyway watch it — I’m going to watch it again before commenting further..

Posted in livecoding, rant | 2 Comments »

Live notation

Monday, January 30th, 2012

I’m really excited to be working with Hester Reeve on a project funded by the AHRC digital transformations call, bringing together live artists and live coders for a dialogue, hopefully leading to new ideas and approaches within both fields.  Live artists work with their body as a medium, and live coders work with abstract symbols, and it will be fascinating to see how these seemingly completely different practices approach one another.

The project is called Live Notation: Transforming Matters of Performance, and the first event will be a performance involving Hester and I on Thursday 22nd March as part of the soon-to-be-announced LoveBytes festival (more on that in my next post).  We are not sure what we will do yet, except it will be in a large cinema and involve sound-based dialogue in some way.  It will be an experimental performance (as in risky and prone to failure) and we’ll learn something whatever happens.

Later on we will be holding workshops leading to a big conference/performance event around June/July.

Posted in events, livecoding | No Comments »

Events and things

Friday, August 26th, 2011

Had a really great time at dorkcamp, and have a couple of more things coming up…

Despite now living in three different cities, slub will manage to perform together on 30th September in La Maison Rouge Paris, as part of the Sony CSL 15th anniversary. Really looking forward to this one.

Then on 28th October I’m honoured to be invited by Aarhus University to give a talk on Artist-Programmers.

On the 15th March 2012 I’m doing some kind of live coding performance at the Life Centre in Newcastle although details aren’t set for that yet.

I’ll also be co-organising another dorkbotsheffield in the next month or so.

That’s it for now..

Posted in events, livecoding | No Comments »

Pitter patter

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

Posted in haskell, livecoding, music | 3 Comments »

Cyclic revision control

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

Posted in livecoding, rant | 7 Comments »

Workshop output

Monday, 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…

Posted in haskell, livecoding, music, texture, visualisation | No Comments »

« Older Entries