Laptop Orchestra: first jam

After a frenzied morning of coding last Thursday, Sam came up with a simple solution for programming beats on the fly.  Samples are loaded at the start of the session.  The tempo is also globally determined.  Each sample is associated with a line of text.  So, if we want a kick drum on every crotchet beat, we enter [[X]] into the line corresponding to that sample, creating a loop of one kick drum.  If we want a kick drum on only the first and third beats of the bar, say, we enter [[X _ X _ ]], which creates a longer loop, and so on.

Subdivisions of the bar can be easily created.  So for instance, [[X X] [_ X _]] yields two quaver hits on the first beat and a crotchet hit on the third.  [[X X X] [_ X _]] would yield triplet hits on the first beat, and so on.  I found this feature immediately appealing, having been accustomed to grappling with grid-based sequencers where changing the subdivisions of the bar required changes in the global properties of the visual interface.

Another really nice feature that Sam has built in is the facility to vary the volumes of the individual samples in an elegant way.  The samples automatically trigger at volume 9 when X is used as the input, but X can be replaced by any integer between 1 and 9 to vary the volume of the individual samples.

Fuelled by Diet Coke and chocolate Hob Nobs, we decided to have a go.  Sam’s machine was generating the audio, with my machine sending network messages to his via OSC.  It worked with surprisingly little heartache, but we quickly identified a few areas for improvement.

Firstly, once things got more than a little complex, it was hard to tell who was in control of what.  If Sam modified the kick drum pattern, say, it wouldn’t update on my screen, so I would have no visual clues as to who had been the last to modify the patterns, or for that matter as to what pattern was currently in operation.  Some kind of feedback mechanism is, we felt, necessary, so that we can feel that we have some sort of agency over the sounds that we’re respectively producing.  This might involve some system whereby we can tell:

1.    What messages have been sent?
2.    What is the current state of play?
3.    What samples are actually in use and what patterns are associated with each?

We also thought that it might be useful to have a system whereby we can name patterns and recall them with a label so that they can be recycled and used by other players.

We discussed using the strengths of the computer itself in a more systematic way, through incorporating a randomness function into the pattern selection or in some elements thereof.  The whole point of a computer ensemble is to do something sonically that can’t be done in traditional acoustic environments, which involves taking advantage of the technology in more authentic ways, we felt. 

Our priorities for the next session are as follows:

1.    Incorporate a log history of what has transpired in the session – this might be handy for recording sessions and analyzing them afterwards, which of course isn’t as immediately possible in the usual jam session;
2.    Think about having a window with the current status displayed, or some mechanism by which a user can query the current status;
3.    Incorporate a way of piping channels through effects in Supercollider, as well as master controls for effects;
4.    Incorporate panning and volume control, both at local and global levels; and
5.    Think about incorporating the Monome as an input device.