First BiLE Performance

BiLE, the Birmingham Laptop Ensemble, had it's first gig on Thursday, just six or eight weeks after being formed. We played at the Hare and Hounds in Birmingham, which is a well-known venue for rock bands, as a part of the Sound Kitchen series. There were two pieces on the bill, one called 15 Minutes for BiLE by BiLE member Jorge Garcia Moncada and we did a cover of Stucknote by Scot Gresham-Lancaster, which was a piece played by The Hub.

As a first performance, I thought it went rather well. There were the usual issues where everything sounds completely different on stage and the few minutes of sound checking does not give anybody enough time to get used to the monitor speakers. And time moves completely differently in front of an audience, where suddenly every minute gets much longer. But there were also the performing-with-a-computer issues: computers get terrible stage fright and are much more prone to crash. A few people did have their sound engines crash, so the first piece had a high pitched squeal for a few minutes, while messages flew on the chat window, reminding people to be quiet during the quiet parts. Actually, there was quite a lot of panic in the chat window and I wish I'd kept a log of it. (Later the audience said we all looked panicked from time to time. I always look panicked on stage, but it's not cool.) In the second piece, I forgot to tell my programme to commence sound-making for a bout the first three minutes. I haven't heard the recording yet, but I bet things sounded ok. Considering that most of us had never done live laptop performance at all before and how quickly we went from our first planning meeting to our first gig, I think we got a good result.

Jorge's piece was complicated but Stucknote seems deceptively simple, so we did not try running through it until the day before the gig. In retrospect, this was clearly an error, because the piece, like all structured improvisation, does require some practice to get the flow down. Of course, we'd all spent the requisite time working on our sound generation and I'd coded up some faders for me and the other SuperCollider user, with Ron Kuivila's Conductor quark, which is a very quick and dirty was of making useful GUIs. I'd tried out my part at home and it worked well and the sound I got was interesting, so I felt confident in it until I got to the practice and it crashed very quickly. I restarted SuperCollider and it crashed again. And again. And again. Half the time, it brought down the other SC user's computer also. And it was clobbering the network, causing the MAX users a bunch of error messages and a few moments of network congestion. MAX, usefully, just throws away network messages when there are too many of them, whereas SC does not seem to.

I could not figure out where the bug was and so, after the practice, I sat down to sort it out. And there was no sign of it. Everything was fine again.

Fortunately, this provided enough of a clue that I was able to figure out that I had created an infinite loop between the two SuperCollider programmes. When I moved a slider in the GUI, that sent a message to the network which effected the sound on the target machine and also caused Shelly's programme to update the GUI. However, the Conductor class always informs listeners when it's updated, no matter who updated it or how, so it sent a message back to the network informing everybody of it's new value, which caused my GUI to update, which sent a message to the network, ad infintum until I crashed.

I came up with a fix using a flag and semaphores:

                   Task({
                             semaphore.wait;
                             should_call_action = false;
                             cv = con[contag];
                             cv.input = input;
                             should_call_action = true; 
                             semaphore.signal;
                     }).play;
 

While this fix mostly works, it does bring up some interesting questions about data management across this kind of network. If we're all updating the data at once, is there a master copy of it somewhere? Who owns the master copy if one exists? In this case, as one person is making sound from it, that person would seem to be the owner of the data. But what if we were all sharing and using the sliders? Then we all own it and may all have different ideas of what it might actually be.

I'm writing a class for managing shared resources which holds a value and notifies listeners when it changes. The object that's changing it passes itself along to the method, so when listeners are notified, the changer is not. I haven't finished the class yet, so I don't have sample code, but I'm pondering some related issues.

Like, should there be a client version of this class for a local copy held on the local machine and a master version for the canonical copy on the network that everybody else is updating? Should a master copy of some data advertise itself on the network via the API and automatically listen for updates? Should they specify a way to scale values so it can also accepted changed inputs from 0-1 and scale them appropriately? If it does accept inputs/values in a specified range, should there be a switch for the clients to automagically build a GUI containing sliders for every master variable on the network? I think that would be quite cool, but I may not have time to code it soon, as our next gig, where we'll be playing a piece of mine, is coming up very soon on 29 of April and then there's a gig in May and then I suspect probably one in June and one in July (although not scheduled yet) and in August, we're going to NIME in Oslo, which is very exciting. Bright days ahead.