co.re.echo.es

I have a sort of casual fascination with infrastructure – factories, power stations, spillways, and so on.  This extends to the internet:  data centres, underwater cables, and core routers.

“Core router” is not just a perfectly Gibsonian term – they’re the routers that most data runs through when going from place to place and network to network.  And seeing this is not hard, though it is picky:  the traceroute command will tell you where you went to get to a place.

You can thus, if you really want to, trace from your computer to all (actually only most) 4,294,967,296 address, from 0.0.0.0 to 255.255.255.255.  This will mean that your computer will go through those core routers over and over and over again.

So, I made a thing that does this, and then turns those traceroutes into music, as one does.  It is called CORE ECHOES, after those routers,  and it is both pretty mellow and suspiciously good, if I do say so myself.  It will also play for something like eight thousand years.  (And!  There’s now a recorded version here.  )

In order to make a thing play for longer than the human race has had writing, I’m relying very much on AWS and Heroku, which will for sure both be around for another few thousand years.  Specifically, I have a process on AWS that is slowly sending out traces, and then logging them to a Redis queue on Heroku.  Heroku then acts as web server, returning the current trace to the JavaScript client.

There’s a timing concern, too:  there’s a second process on AWS that keeps track of how long each trace should play for, and then turns the page of the piece by removing the current trace from the queue.

This has about a million race conditions – but they’re very slow race conditions, so things will probably be OK.  In theory, a series of very short traces could run the queue out of data before a next very long trace can log…but that is a risk I am prepared to take.

All the mapping and synthesis is handled in JavaScript – really, the mapping should happen on the server side, and the client should only do the synthesis, but c’est la vie.  The synthesis is all in WebAudio – there are three sine waves, each with their own pretty-simple signal chain.  I was trying to both do something simple and backgroundy, and get a sense of bleeps and bits and ones and zeroes moving around.

Each IP generates a single pitch, a duration that it runs for, a time between notes, and the length of each note.  This gives an ever-changing minimalist sort of pulse, as the three IPs build up and vary.

The duration is deterministic:  take the sum of the digits of the first three parts of the IP, then divide by four to get a nice sort of time.  The other parameters work in the same manner.  The pitch is taken mod 24, and so on.

The mapping was initially much more complex, but it turns out that there are a lot of IPs, so making them deterministic is probably OK.  An obvious mapping improvements would be to relate the time for each IP to match the time that the trace takes – but that gets into tricky regex issues.  I’m happy with the synthesis, though I am sure that I will regret not making the server more robust.