I’ve had a paper accepted to ICMC (International Computer Music Conference) in Belfast. My paper isn’t directly about livecoding but according to chatter on the TOPLAP list there will be a fair number of livecoding papers and performances around the conference, including a off-icmc livecoding event organised by Graham Coleman. Looking forward to the schedule appearing…
Just after that from the 29th August is the 3rd annual dorkcamp, a weekend in a field doing strange things with electricity. The previous camps were fantastic, I can’t wait.
Then probably the following weekend, 6th September will be the London Placard headphone festival, an intense evening of diverse back-to-back 20 minute performances over a bank of headphone distribution amplifiers (and no PA). Always extra-special and full of surprises, it looks like this will be a big one…
A brand new website:
The idea is that every month some instructions appear and passersby add
their implementations in code.
Please let me know of bugs / omissions / ideas!
Very early stuff but a rendering of the vocable word sebosebesusasobesebosebasusasobesebosebesusasobesobosebesusasobesebosebesusasobesebosebasusasobesebosebesusasobesobosebesusasobe is here.
(any website layout breakage is intentional)
The percussive beat you hear in the background is the excitation of the mesh, bursts of pink noise from the ‘b’s and white noise from the ‘s’s. The vowels control the ‘tension’ of the mesh.
The waveguide mesh ugen mentioned in my previous post and used here is now in sc3-plugins.
Here’s an interesting response to my earlier post about how test driven development does not necessarily apply to all problem domains. Ocean has some insightful things to say about creativity, but mischaracterises me as seeing constraints as undesirable.
In fact I agree that constraints are essential to creativity. Constraints form the walls of the creative space that a creative agent (here, the programmer) searches within and pushes against. My complaint was not against constraints in general, but in the assumption that when we’re talking about development, we’re talking in the context of writing quality assured business software.
Lets take livecoding as a example. A programmer stands on stage, and has to write some software to generate some music so that the people waiting in front of them has something to dance to. Imagine looking up from your code editor to see the expectant faces above. This particular problem domain is one I have found myself in as a member of slub, and already has plenty of constraints to guide my creativity without adding the extra artificial constraints of starting with some unit tests.
[edit: see comments for fine counter-example from dave (a fellow slub member)]
My MSc project is gradually coming to a close… I think I finally have some software that I could improvise with, which I’m going to give it a trial run at the dork camp next weekend. Still a lot of writing to do around it, and only a couple of full days left to do it in, but I think it’s doable.
The user interface for my system is basically GNU readline, a really nice, featureful way of working with lines of text so perfect for improvising line-based textual rhythms. I foresee many people suggesting pretty GUIs but hey… This project is all about the expressive power of letter combos, that goes for keypresses as well as vocables.
So I explained my msc project to Amy who explained it back far better than I could have; “… it’s controlled by a human who types the sounds the computer tries to make that sound like a human trying to sound like some electronic music”. So now I want to rename my soon-to-be-finished thesis “A system for humans typing sounds that a computer tries to make sound like a human trying to sound like a computer making music, with software that acts like a human doing so”.