Endlessly repeating...

Kima video

12 April 2013

There's a video available now of the Kima project which I worked on with Eugenia Emets' Analema Group. I was happy with how it turned out on the whole although, like always, there are a tonne of additional things I wish I'd had time to get finished. This was the most complicated art project I've worked on in terms of collaboration with other artists and it's an experience I'd like more of.


Kima at Kinetica

18 February 2013

I'm please to announce that KIMA, a project I've been working on with the Analema Group, will be performed at the Kinetica Art Fair at the end of February. It's still work-in-progress so I can't post any video yet but if a blend of dance, singing, audio processing and reactive graphics is your thing then try to get along to one of the performances.


A quick intro to vim macros

9 January 2013

More of a note to self than anything but here's a quick introduction to macros in vim...

If you need to repeat a simple action in vim then you can easily do so by hitting the full stop key. The sequence A foo esc . . will result in the word foo being repeated 3 times (once typed in and twice repeated).

The simple repeating behaviour is helpful but it's no use if you need to repeat a series of actions involving motions - for that you need a macro. If you're anything like me you've already had an experience of macros when trying to quit vim and instead putting it into recording mode but bear with me, this can actually be useful. To start our simple example, enter a line of text then repeat that line a few times (yy to yank the line, 10p to paste it 10 times). I used the text "Every good boy deserves favour". Now go back to the start of the first line (gg) and decide on the change you want to make, I decided to change "boy" to "girl". Still in command mode enter qa to start recording into register a. Now carry out your change, move to the start of the next line, return to command mode and hit q to stop recording. In my example that meant doing w w c w girl esc j ^ q. Now it's a simple matter to repeat that by typing @a and of course you can repeat it multiple times by entering a number of repetitions followed by @a.


All the M's

25 February 2012

A jam I recorded last night using the Machinedrum, Monomachine, modular and Mono Evolver. Percussion's all from the Machinedrum, the drone running throughout is from the Mono Evolver (which did this so well that I've pretty much fully reconsidered selling it), the lead (such as it is) is from the modular and the Monoevolver's on bass.

24th Feb jam


Sound spaces

29 September 2011

More playing helper monkey from me. This time it was constructing a system of detectors to conjure up a space just from sound. Laura Tarjuman - whose project this is - made a video of the results. Technically this was pretty simple (most of the coding was done in about four hours) but it's an excellent demonstration of just how easy Processing and Arduino have made integrating software and hardware (a webcam and IR rangers in this case). It's a good time to be a hacker.


Recent doings

19 July 2011

It's been hell of quite around here recently so I figure I'd put in a quick post covering what I've been up to for the past couple of months (not blogging obviously). The main thing was a Reactable and Processing with Vanessa McKeown, a student at Chelsea College of Art & Design. There's a whole heap of information about that Vanessa's project blog. The main thing I learnt on this is that debugging problems relating to the detection properties of the Reactable (i.e. detected markers jittering and so on) is really time consuming and coping tactics need to be built into the software early on. We didn't do this and it caused a lot of bother as the deadline approached. If you're building a Reactable yourself, get it working a long way before your deadline.

More recently I've been helping out with Dimitris Mylonas' online colour naming system. I've learnt a lot about AJAX in the course of that, which is bound to come in handy for anything else I end up doing that's online and interactive in anything more than a superficial way. It was also good to apply Numpy to something new - so much better than Matlab. That project got a brief mention in The Economist.


A flexible OSC responder

17 February 2011

A lot of my ideas involve generating musical information (notes, triggers, continuous control data) in one language (I'll refer to this as the controller for convenience) and then passing that to SuperCollider to make some noise with. That approach raises the question of where to put the intelligence in that system. Either the controller processes everything into musical information and SuperCollider acts as a 'dumb' synth or the controller can send a load of numbers without semantic meaning to SuperCollider which can then figure out what to do with them. To my mind, a logical way to choose which system to use is to look at whether you want to change the controller setup or the SuperCollider setup more often. If you're changing the SuperCollider setup frequently then doing more processing at that end makes sense as it reduces the need for the controller to know about the synth architecture. In my case, I'm writing a lot more controllers at the moment so I've put the more of the note generation logic at that end. This means I can swap controllers easily without having to fiddle with the SuperCollider code.

To assist with all that, the following OSC responder code offers a useful amount of flexibility. It takes an OSC message, interprets the first string as the name of a synth to be instantiated and then adds the subsequent pairs of strings and numbers as parameters to that synth. What you can't do easily with this method is subsequently control the created synths so make sure that they free themselves (doneAction:2 in an EnvGen for example) unless you want a huge pileup.

o = OSCresponder(nil, "/controller", {
    arg t, r, msg;
    var synthName, synthArgs;

    // first argument is the synth name
    synthName = msg[1].asSymbol;

    // remove the first two elements of OSC message, these contain 
    // the path and synth name
    1.do({|i| msg.removeAt(i)});

    // create a new array to hold the synth arguments
    synthArgs = Array.new(msg.size);

    // for the remaining elements of the OSC message go through and convert the first
    // of every pair to be a control name and add the second as the control data
        arg item, i;
        if(i.even, {synthArgs.add(item.asSymbol)}, {synthArgs.add(item)});

    // create the new synth
    Synth.new(synthName, synthArgs);

Get started with MacVim and scvim

16 February 2011

I made the switch from TextMate to MacVim about a month ago now and unlike my previous attempts to switch to Vim the change seems to have stuck this time. Of course once you find an editor you like there's a desire to use it for everything you can and that meant getting scvim working. Here's how it's done...

  1. Download a copy of the SuperCollider source from the SourceForge page
  2. Open up Terminal and cd to supercollider_source/editors/scvim
  3. The manual install instructions in the scvim readme are good so have a quick read of that
  4. Copy the executables from the bin directory to /usr/local/bin
  5. Copy the ftplugin, syntax and indent directories to ~/.vim. If you're using Pathogen (and I'd recommend that you do) then create an scvim directory in ~/.vim/bundle and move the aforementioned directories there instead
  6. Copy the scclasses directory to ~/Library/Application Support/SuperCollider/Extensions. At this point I renamed the scclasses directory to something less generic but you don't have to
  7. cd to /usr/local/bin and run ln -s /Applications/SuperCollider/sclang sclang
  8. To generate the help files you'll need to install links and unrtf, the easiest way to do this is through MacPorts
  9. After you've got links and unrtf, run scvim_make_help -l -c -s /Applications/SuperCollider/Help
  10. scvim makes a lot of use of the function keys so quickly have a look at the keyboard options in system preferences and make sure that the option about using F1, F2, etc as standard function keys is set
  11. Next step is to edit .scvimrc so open that up in (presumably if you're reading this) vim
  12. Uncomment lines 33 and 34 (let g:sclangTerm = "open -a /Applications/Utilities/Terminal.app" and the subsequent line)
  13. Save your changes to .scvimrc
  14. Enter :source ~/.scvimrc in vim
  15. Open a new file in vim called test.sc. The important bit is the .sc extension, this will prompt vim to load the SuperCollider commands
  16. Enter :SClangStart in vim, hopefully a terminal window will come up showing the usual SuperCollider post window stuff
  17. At this point you should be able to run SuperCollider commands as normal. Try entering s = Server.local.boot and hitting F6, hopefully the server will boot.
  18. You can review the rest of the shortcuts that scvim adds by having a look at ~/.scvim

DFM1: A filter for SuperCollider

26 January 2011

I've just finished uploading a new ugen for SuperCollider called DFM1. It's a port of Tony Hardie-Bick's DFM1 filter, which is a great sounding, overdrivable, self-oscillatable, incredibly detailed model of an analog filter. Full source code is available, so if you've got an interest in DSP coding it'd be an excellent example. If you just want to make some strange noise it's pretty damn good for that as well. You can download DFM1 from here.


Livecoding with SuperCollider: Learning to crawl

20 January 2011

Via @mclduk I've finally found a tutorial for TempoClocks in SuperCollider that I can get my head around. To celebrate and to help me remember it, here's a very quick example of some livecoding...

First we need a synth:

SynthDef(\beep, {
    arg freq = 440;
    var sig;
    sig = SinOsc.ar(freq, mul:0.2);
    sig = sig * EnvGen.kr(Env.perc(0.1, 0.5), doneAction:2);
    Out.ar(0, sig);

I'm not going to bother explaining all of that because it's out of the scope of the tutorial, suffice to say it makes a short beeping sound and then frees itself.

The idea of this method of livecoding is to use a TempoClock to call a function every beat. The function can be modified while the clock is running and so we have livecoding. The first thing we need is an empty function:

a = {}

Exciting eh? Next we need a TempoClock:

c = TempoClock(2)

The argument is the clock's rate, in this case 120bpm (the argument is beats per second, 2 * 60 = 120). Next thing is to tell the clock to call our empty function every beat:

    0, //evaluate this immediately
        arg ...args;
        args[0].postln;    // arg[0] is the beat number
        a.value(args[0]); // pass the beat number to our function
        1.0               // do it all again on the next beat

If you evaluate that you should see a number counting up in the post window.

The next step is to make our function do something:

a = {Synth(\beep)};

Evaluate that and you should hear a beep every half a second. Congratulations, you just livecoded!

a = {Synth(\beep, [\freq, 480])};

Yeah, ok that's not all that exciting but it was a breakthrough for me. It'd be nice if we could do something at a different interval than every beat. Fortunately, we're passing the beat number to our function.

a = {
    arg beat;
    // if beat number is even play a high note
    if(beat % 2 == 0, {Synth(\beep, [\freq, 440])});

    // play a low note every beat
    Synth(\beep, [\freq, 219]);

I'm not going to get into the modulo operation but suffice to say it's hugely useful for subdividing counters like this. You can also access external data in our function:

~notes = [50, 52, 56];
a = {Synth(\beep, [\freq, ~notes.choose.midicps])};

The contents of ~notes can be changed on the go as well. None of this is particularly groundbreaking but if you've never played around with this stuff it'll hopefully get you from sitting to crawling.