Jackd, performances and harddisks

So you have your sample loading working in a separate thread to your realtime audio code and the interface i/o communication is also tucked away in it’s own thread. You have a lock free mechanism for communicating between all threads and still, sometimes – when loading data from disk jackd chucks your program off for blocking – usually during a live performance, and you have to fumble around restarting the audio server. What’s going on?

Well, it turns out that when your hard drive goes to sleep, the spin up resulting from a disk access request (such as mid-performance sample loading) can cause the kernel to block, which causes jackd to panic and either stop entirely or detach your client. This is even with jackd running with the –nozombies switch, so it must be the watchdog thread at work.

The solution is simply to prevent your drive spinning down when you are performing, by adding “hdparm -S 0 /dev/yourharddisk” to your live audio startup script. Thanks to ClaudiusMaximus for helping me fix this at Piksel – it’s been bothering me for ages.

Tampere building projections

Following on from the Pixelache Urban Projection Lab, we were invited to take part in the Tampere Architecture Week “Night of Lights” to brighten up a dark November Finnish evening. Luckily we didn’t have to brave the -12 degree temperatures the whole time, as we had some protection in the form of a temporarily repurposed shop front (complete with christmas tree).

Antti Jadertpolm improvised live paintings (live-photoshop), creating images on the surface of the building – making a dense jungle grow gradually while populating it with animals and characters from warmer places. Miska Knapek visualised energy use taking data from the local energy company and converting it into a particle system, along with wind movement visualisation and some more abstract pieces. I improvised some from-scratch fluxus livecoding, the idea was to try different approaches for using movement to camouflage or distort the surface of the building.

Here is a video we assembled of our exploits:

Piksel 2010 (un)stable

Piksel 2010 (un)stable was the 8th piksel, and the second time I’ve been lucky enough to participate. I was there to present Naked on Pluto and general livecoding duties.

I didn’t have as much time or energy to get involved with the other things going on as I’d have liked, so this is mainly a report on my activities. I did see a super talk by Audun Eriksen about the visual programming language scratch and it’s use for teaching kids to make games – very inspiring stuff.

Scratch was where I started with the idea for scheme bricks, so it was great that the next day Alex and I had the functional livecoding workshop, where people could get their hands dirty with some of our live coding performance ideas.

This was followed in the evening by a slub performance, where we got a little carried away by the responsive audience and the rather nice sound system. It’s always good to do performances with stuff you’ve done a workshop on earlier as the participants can put it in context (and tell other people what’s going on!). The image is a link to a video of the performance on giss.tv.

The next day was a switch to Naked on Pluto with Aymeric and a presentation where we discussed clouds, problems with social media, farmville and the intricacies of the facebook graph api.

(pictures thanks to Régine Debatty)

It was great to get questions from people who have tried playing the game before seeing our talk. Hopefully this can be the case as we discuss the project more widely.

NoP: What do we do with your data?

Now we have people playing the game, it’s a good time to explain what happens with your facebook data in more detail. Given the nature of the project it’s important for us to make this clear. Here is a diagram I’ve prepared for the presentation we are giving at Piksel at the weeked:

On the left is the naked on pluto server, the machine in the middle is your computer running the client in the browser, and on the right is facebook’s server.

The first thing to notice is that the NoP server doesn’t ever communicate with facebook directly. The other thing to notice is that we never write anything to your facebook account.

The client only passes your name and facebook ID number to the server, where it gets incorporated into the game world. This information is considered public by facebook so it’s a usual thing to do. We use it to pass back to other players, so they can see who else is playing. The facebook ID is used to get the right icon for the players, but we also use it to find the player’s in-game entity when they log in (they are unique – so two people with the same name can play).

All the other information you can see – your friends and their data, is displayed by your client based on the data read by your machine from facebook. None of this gets passed to our server or other players.

For more information on how this all relates to facebook privacy policy, see the plutonian clothing stragegy.

Originally blogged on the NoP site here.

LED tracking with a particle filter

Some LED bike light tracking using a particle filter:

I’ve been invited to do a lecture for Markku Nousiainen’s experimental course on computational photography next week, so I’ve been constructing some demos that display different computer vision algorithms based on the work I’ve been doing on Lirec. The idea is that they may serve as inspiration for how algorithmic understanding of images can be used for artistic purposes.

The code is part of the mysterious magic squares library.