Ok so it should be no secret by now that I’ve taken the lead on organising three algoraves here in London, and also two four AlgoRhythms events which are more or less monthly live code open mics, alongside I think nine meetups which are also monthly.
None of this would have happened without the support and help of others, so it’s definitely not all about me. This post is about how the bits that I did came together and what motivated it in the first place.
The genesis began on this very blog with the words:
“One obvious solution would be to organise an alograve myself, I’m not great at promoting, but it might come to that…”
I want to say that people were doing events, in fact several sprang up before I’d barely announced the algorave. In a short run there was an event at the Camberwell Crypt, a fakedac also at Corsica, and Peckham Digital made a welcome reappearance - they even did another one later in 2024.
how to run an algorave
This has been my approach, though obviously there are many different ways of going about it. I also had very little experience as a promoter (three small events many years ago) and proceeded mainly by guesswork and trying to make sensible choices.
- reach out to your peers
do they have advice, offers of help, notes from their own experiences, useful contacts?
In my case I was lucky enough to have all of those things. Which really helped get my leg in the door at Corsica who are notorious for ignoring basically everyone.
If you don’t have anyone - find some! There are bound to be some live coders in your vicinity somewhere - go to a meetup - or start one!
- find a venue
this was also really straightforward - I just used the same venue that previous algoraves had been held at in London.
For AlgoRhythms I had started checking out events at the sister venue of Corsica, The Carpet Shop in Peckham, and it spiralled from there as a way to do regular events with low overhead.
(For the meetups I started by using the same venue as Pattern Club and then switched to a suggestion by Evan who attended the first one.)
- ask some people to perform.
Don’t just ask your friends, ask people you don’t know too, and ask for recommendations. I targeted an even gender balance in this too, a rigid but effective way to avoid bias to some extent. Also consider the ages, ethnicity and backgrounds of who performs. I’ve never asked anyone how they identify in any category but you can get a feel for things and it will help avoid the audience being a monoculture too. How woke of me. One thing to avoid is booking everyone you can think of, especially if you’re intending to pay them all. Ask artists how long they would like to perform for and allow 10-15 minutes of changeover time. This also helps with resolving last minute technical issues.
- make a poster, or ask someone to make one
a lot of live coders are also talented artists so one of the acts will be able to do this, ask nicely and pay them if you can.
- Plan the event. less is more
be clear to performers about what the costs are, who will bear them and how much or how little anyone might get paid. Money changes everything (which is unsurprising as it was invented as a means of domination and exploitation) so an event like AlgoRhythms in which no cash changes hands really simplifies things. What I elected to do for the Algoraves which need to cover several hundred in venue fees is just say to everyone that we will split everything equally between us after costs, which seemed fair.
Some artists like to know who they will be paired with in advance - as in audio + visual.
I sent out showtimes a week before, this was decided by me alone, but of course anyone was free to swap around. Lucy Cheesman suggested staggering stage times between rooms, which was a great idea.
You might also want to ask for a ’tech-rider’ or tech-spec - in case anyone has tech requirements beyond an HDMI/line-out, for example a microphone.
- Take any necessary equipment - or ask others to.
This could include projectors which are pretty essential, ask around quite a few people have one they can lend. Foldable screens can be useful too.
- During the event:
allow time for soundchecks, but you may need to make sure this proceeds smoothly - 15 minutes should be enough to check levels and everything is working.
Check in with artists and attendees - ask people how they’re getting on, what they think - you can collect valuable feedback this way.
Stay calm - this is something I’ve struggled with a lot - it’s easy to get too excited and/or succumb to pressure. Remind yourself that you’re there to enjoy the event too and let any technical hiccups go - it’s all part of the fun.
People will jump in and help out, humans’ superpower is large scale collaboration!
decisions
For the sake of expediency, for some things I just take a decision on, while of course remaining open to input. Democracy is great and you can gain consensus informally on a lot of things - but more often than not you will have the opposite problem of people assuming you are ‘in charge’ and defer to you - I guess we are taught this our whole lives. Delegate where you can. People will do a great job when you let them.
My approach is that for an event to happen you just need one person who will do the things that otherwise would fall though the gaps and generally keep the ball rolling.
Encourage participation in the running of the event where you can, although have firm boundaries as required. If there is a possibility for conflict the best approach is to ‘fork’ - i.e. have independent events and help each other out more at arms-length.
A lot of my own decisions were based around sustaining events over the long term. What makes things most likely to succeed over multiple events - in terms of cost, effort etc?
Another choice was to be as permissive as possible - I never applied any definition of what live-coding is or isn’t and bent the rules eg. by occasionally having VJs do visuals that weren’t strictly ‘coded’ (this was actually a great move and no-one noticed, it’s still a very creative use of computing).
Leading isn’t about ordering anyone about - it’s about taking people with you. Explain your choices, ask for input, let others find their way too.
but why?
Well, I wanted to go to an algorave. And I wanted to perform at one. So in part the whole thing was driven by my own ego. But that’s okay, we all should honour our own desires - as long as it is not at the expense of others. These events have been a win all round.
and why London? Well it’s where I live. And why live here? I moved back to be closer to family. Sometimes the grind gets you down, but there are a lot of lovely people here too. Usually from abroad. Occasionally London bites you, gotta stay nimble yo. Sometime I might move further out somewhere, but for now I’m exploring possibilities. Doing my best not to get caught up in the traces, while geographically nestled up to the centre of The Spiders Web.
as a live coder
like any method of expression I guess - expect to grow and develop over a number of years as a live coder. (in fact don’t ever stop)
To enhance this process I continually test different techniques, challenge myself with from-scratch sessions when I’m brave enough, do as many performances as I can, listen to other coders, try different genres, etc etc.
There are many opportunities in London, if you want more where you are then reach out, we’ll do our best to help.
confidence
All too often I see people who are still in the process of building confidence. It took me years, even decades, to build my own. Which is a shame, but events like these can be a great way of seeing others’ confidence blossom - that’s actually a secret hobby of mine ;)
updated on: 21 / 6 / 2025