Hacking Perl in Nightclubs
by Alex McleanAugust 31, 2004
I've found the experiences of dancing and programming to have a great deal in common. With both I am immersed in an abstract world of animated structures, building up and breaking down many times before finally reaching a conclusion. Indeed, when the operation of even the dullest data-munging computer program is visualized, for example in a debugger, it does seem to be dancing around its loops and conditions -- moving in patterns through time.
In other words, a musical score is a kind of source code, and a musical performance is a kind of running program. When you play from a musical score or run a program you are bringing instructions to life.
So a piece of composed music is like a Perl script, but let's not forget improvised music. The rules behind improvised music -- for example improvised jazz -- develop during a performance, perhaps with little or no predefined plan. Where is the comparison with code here? Well, how many times have you sat down to write some Perl without first deciding exactly how you were going to structure it? Perl is great for improvising. The question is, can you write improvised Perl scripts on stage? This article hopes to answer this question.
Consumer Software v. Live Programming
If music and software have so much in common, how do they commonly meet? Well, modern-day music is often composed not at a piano but at a computer. Here the limits of composition are defined by the creators of software, with musicians eagerly waiting for the next upgrade of their favorite music application. However, at the fringes of electronic music, you find musicians who are also programmers, writing their own software to generate their music. This is a diverse world, spanning and mixing all the genres you could think of, from classical cantata form to speed garage to dance hall. Very few of these musicians have chosen Perl to write their musical code, but this article hopes to encourage more Perl hackers to turn their tools to music.
A little about myself -- I'm a musician who for the last few years has used Perl as my only musical instrument. I've had some successes, with hundreds of people dancing to my Perl, jumping about to my subroutines, whooping as I started up a new script. To this end, I built a whole library of little compositional Perl scripts that I ran together to make music. However, when running my Perl scripts during a performance I grew to feel as if I wasn't really performing -- I was running software I'd written earlier, so to some extent the performance was pre-prepared. I could tweak parameters and so on, but the underlying structure was dictated by my software. So what's the alternative?
Over the last couple of months, I've moved toward writing software live, in front of an audience. If a programmer is onstage, then they should program! This may seem a little extreme, but I'm not the only one making music this way. This approach grew through a collaboration with Adrian Ward called "slub," and also from a fast-growing organization called TOPLAP, the Temporary Organisation for the Promotion of Live Algorithm Programming. Check http://toplap.org/ for more information.
I'll introduce my live-programming environment -- "feedback.pl" --later. First, I'll talk a little about writing code that generates music.
Generative Music in Practice
When I use the phrase Perl Music, I mean music that is generated live by Perl code. Instead of writing a melodic sequence by hand, a Perl Musician writes a Perl script that algorithmically generates a melody. When making music in this way, the composer is taking a step back from the music, working with the structure behind a composition rather than with the composition itself. This approach is often termed "Generative music."
Perl hackers know that programming is a creative endeavour. So instead of starting with someone else's software, why not start with nothing apart from some vague musical idea? Then sit down and start to express that idea as code.
Now, while musical Perl code doesn't have to be complicated, it doesn't have to make sense either, you don't have to plan on making anything that is at all readable the next day. Saying that, to take full advantage of any inspiration you have found, code needs to be written very quickly, so keen programming skills and good knowledge of Perl is of great advantage.
In any case, the most important thing is that your code makes a musical pattern that you judge to be good. Sometimes elegant mathematical forms sound good, other times unexpected bugs and chaotic nonsense produce the most interesting results.
Let's sidetrack to talk a little about how you might build an environment to make live Perl music, starting with a brief tour around some useful CPAN modules.
CPAN Music Modules
Sadly Perl isn't quite fast enough to be useful for synthesizing sounds directly. Instead we have to use Perl to trigger sounds by talking to other bits of software or hardware.
There are a fair few music related Perl modules to be found on CPAN,
perhaps the best known being the MIDI-Perl package by Sean Burke.
MIDI-Perl concerns itself only with the reading and writing of MIDI
files, which are a kind of musical score - this article is concerned
with making live music, not writing scores. However, if you do want
to create or manipulate MIDI files, the MIDI::Simple module in the
MIDI-Perl package is a great place to start.
As well as a file format for storing musical scores, MIDI also
provides a real time protocol for triggering sounds on synthesizers
and samplers in real time. If you have a MIDI compatible synthesizer
or sampler then there are CPAN modules to help you take advantage of
them; MIDI::Music for UNIX and Win32API::MIDI for Windows.
Software synthesizers are now commonplace and reliable, thanks to the increasing speed of computers and improving latency times of operating systems including the Linux kernel. Most music software is still controllable by MIDI, but for a faster and more modern alternative, have a look at Open Sound Control (OSC).
OSC is an open network protocol for music, and is well supported by the best free software music applications including pure-data, SuperCollider and CSound. It's most commonly carried over UDP, so you can use your existing TCP/IP network and Internet connection for OSC.
For sending and receiving OSC messages with Perl, install the
Audio::OSC package from CPAN. Here's an example of its use:
my $osc =
Audio::OSC::Client->new(Host => 'localhost', Port => 57120);
$osc->send(['#bundle', time() + 0.25, ['/play', 'i', "60"]]);
This example sends a message to port 57120 telling it to play number
60 in a quarter of a second's time. The OSC protocol doesn't define
the meaning of such commands, it's up to you to make sure that the
receiving application understands what the sending application is
asking of it. Later I'll show the use of Audio::OSC to talk to an
application called SuperCollider.
Ecasound is an excellent piece of software useful for live routing and
recording of audio. It supports LADSPA plug-ins, allowing you full
programmatic control over a wide range of effects such as noise
filters, reverb, chorus and so on. For full real time control over
ecasound, install the Audio::Ecasound module.
While not likely to have a place in a professional studio, Audio::Beep
is a fun way of making primitive, monophonic music. I'll use this in
an example later.
Finally, perhaps the most essential CPAN module for live music is
Time::HiRes. Unless your music is very intense, at some point you'll
want your script to pause before triggering the next sound. Normally
Perl only lets you sleep for whole seconds at a time, but Time::HiRes
offers a great deal more accuracy. Time is such an important issue in
music, that I've dedicated the whole of the next section to it.
Time
Time is central to music, and presents a few technical hurdles to jump. If you have more than one music-generating Perl script running at the same time, you'll want to keep them in sync somehow, and if you're playing with someone else, you'll need to keep in sync with them as well. You not only need to make sure all the different scripts are playing at the same speed, but also in phase - that is, everything needs to be able to work out when the start of the bar is. Further, at some point you'll want to change the speed of the music, especially if your crowd are looking a bit restless. And if you want to start up a new script while another is running, how do get it to start at the right moment?
Here's how I do it, in brief. I have a central time server called 'tm.pl', that stores the current bangs per minute (bpm), the number of bangs that have occurred since the script started, the number of bangs since the last bpm tempo change and the time of that change. It keeps this information up to date by referring to the system clock. By fetching these four simple bits of information it's possible for another Perl script to work out what it should be doing and when.
A 'bang' is like a musical beat, or the regular tick of a clock. Each Perl script keeps its own 'heart beat', an event that regularly calls a method called 'bang'. I put all my music generating code inside that 'bang' method. If it receives a bpm change from the server it schedules the change of speed at exactly the right moment.
Well, I say that but of course computers are volatile things, and so in practice events never happen at exactly the right moment. But as long as the math is right, any slight error is corrected, and so the scripts stay in synchrony.
Pages: 1, 2 |
