Time was, there was a whole load of music on this site. Until I get round to designing a way to present all that again (or just dump it all on Soundcloud) I thought I'd throw up the links as posts. Part one is the miscellanea:
Rob Munro was kind enough to upload a recording of the set I played at The FleaPit last Thursday. Download it and have a listen if you weren't able to make it along.
I was pleased with how it went on the whole (and was offered another gig afterwards so it can't have sounded too bad). The main problem was that it took me a couple of minutes to settle into a groove which isn't ideal from the point of view of hooking people in who might be thinking about popping to the bar. I'm not entirely sure how to deal with this in the framework of improvising everything. The best idea I've had so far is to take a leaf out of the big book of chess and learn a bunch of opening gambits that I can quickly get going and then build on. Obviously this isn't really improvising any more but I think it'd be less constraining than turning up with an initial groove saved as a pattern.
On the technical side of things, I really want an arpeggiator function within the sequencer but I'm not sure how to implement this within the interface of the Launchpad just yet. Apart from that everything performed very well and I didn't run into any bugs despite the labyrinthine mess that the code as become.
When I first started to get into the nuts and bolts of sound generation (rather than tweaking someone else's plugins), I did what a lot of other people do and downloaded Pure Data. It's a great environment to start playing around in, you connect an oscillator block to a filter block to an output block and you've got a little subtractive synth and it's clear how the signal flows through it. That's absolutely great for learning how things work and, to my mind, Pd is one of the gems of open-source audio software. Having said that, Pd, Max/MSP and every other draw lines between the building blocks audio systems have a problem - spaghetti. The building blocks lend themselves well to simple signal flows but when you get a hankering to play with 16 operator FM it's not quite as easy to see how everything fits together and it requires a hell of a lot of mousing around to put the thing together. Sure there are ways to organize subsections and that helps a lot (and is good practice generally) but I tend not to start a project with a clear view of where I'm going so once things have gone a bit Italian it's too late. Take all this with a pinch of salt of course - there are people out there who do wonderful, complex work with Pd, I'm just not one of them.
Anyway, the point of that ramble was to say that there's a need sometimes for a more abstract approach than blocks and wires. That's where SuperCollider comes in. Programmers have been representing complex problems as text for many years now and SuperCollider brings that power to audio (without the need to take a degree level class in DSP). To highlight the power of text I wanted to share this little example that I wrote after being inspired by this example of data based reverberation.
SynthDef(\dataverb, { |t_trig, freq, amp = 0.5 att = 0.1, dec = 0.8, rtime = 0.04|
var steps = 24, d, a, w, f, sig, controlEnv;
d = (1..steps - 1).collect({|n| rtime * n}).addFirst(0);
a = (2..steps).collect({|n| amp / n}).addFirst(amp);
w = [0.5, 0.6, 0.7, 0.4];
f = [freq, freq * 0.999, freq * 1.001, freq / 2, freq * 1.5];
sig = Mix.new(
Pulse.ar(f, w, mul: EnvGen.kr(Env.perc(att, dec), DelayN.kr(t_trig, d, d), a))
);
controlEnv = EnvGen.kr(Env.new([0, 0], [d.last + att + dec]), doneAction: 2);
Out.ar(0, sig!2);
})
Those 12 lines of code represent 24 channels of a delay, an envelope and an oscillator all subsequently mixed down. The magic comes from SuperCollider's ability to take an array as one of the creation arguments of a sound generating block and create an instance of the block for each element of the array. In the example above the line
d = (1..steps - 1).collect({|n| rtime * n}).addFirst(0);
creates an array of 24 gradually increasing delay times. When this is provided as an argument to the delay block (DelayN.kr(t_trig, d, d)) you get 24 delays. No fuss, no patch cables. Want more? Just change the value of the steps variable. Want to individually filter each step, it's only a couple more lines of code.
To get an idea of what it sounds like have a listen to this:
If you haven't looked into the power of the SuperCollider language yet, I hope this inspires you to do so.
I made a decision a while back to focus on playing live rather than recording. I've spent a lot of time hunched over Cakewalk Sonar tweaking tracks and I daresay I'll go back to that mode again eventually (or if I'm lucky find a compromise) but right now I want to play. The downside of this is that it can be a bit tricky to explain to people what the hell it is my music actually sounds like. Fortunately, the endlessly helpful Rob Munro was kind enough to record a couple of the recent OpenNights so for anyone who's curious (and can't make it to a gig which is a much better option) here's some music...
I'll be playing at The FleaPit on Columbia Road, London, E2 on February 11th as part of one of OpenLab's OpenNIghts. Line-up and timing is TBC but turn up at around 7pm and you'll probably get to see Viktor Mastoridis, Rob Munro, Soviet Comonautics, Dave+Martin and me(!). Door tax is but a single beer.
I'm making slow but steady process with the camera simulation. The blurring effect I mentioned at the end of the first post on this is now in there using the low-pass filter code that I posted yesterday. I'm really happy with how that panned out so I thought I'd post another video and the code. I've used a bit of off screen drawing to do this which I don't recall being covered in the Processing documentation so I'll write that up for another post.
I still need to give some thought to how I'm going to make it react to sound. There are a lot of available parameters in an audio stream (amplitude, envelope, frequency content etc) and it's important to pick the right ones and process them correctly so that it's apparent to the observer that the musical events are driving the video but with the visuals still being pleasing in their own right.
In trying to further humanise my wobbly camera project I needed some of the parameters to change in a way that was linked but with one of the parameters responding at a slower rate. To do this, you need a low pass filter which will be familiar to anyone that's spent any time making electronic music (anyone else should follow the link). There are a few ways to implement such a filter but for my purposes a quick moving average version was good enough. This works by buffering it's inputs into a FIFO and output the mean value of the contents of the buffer (I wouldn't do a good job of explaining the maths behind this so I'm not even going to try). The degree of filtering can be changed by increasing or decreasing the length of the FIFO queue. Code for the filter class and a little example are below.
I was watching videos of neurons growing this morning (it's nearly work at least) and it occurred to me that it might be fun to get Processing to draw something similar. I had a whole plan worked out with branching, and making the strands repel one another, maybe a bit of L-system action. Not unusually when experimenting with Processing, I did a little bit of the plan, saw something pretty and got side-tracked, in this case by the trails of particles with brownian motion.
After watching the particles swimming around for a bit I remembered that a while ago I'd been thinking about simulating 'human' viewport movement as seen in a thousand and one mobile phone videos. Seen as I had the particles already they seemed like a good candidate to add the viewport stuff to. The result so far is below. I'm pretty happy with it so far, I'd really like to try and add some kind of simulated blur and make it reactive to sound and then I'll probably post the code.
I love Processing in a way that's almost unseemly for a gentleman and a programming language but there's something about Java that feels, how can I put this, a bit inelegant and crufty. Lots of braces, lots of type declaration and so on. That feeling put me on a search for a way to do cross-platform graphics in a tidier language. The options that I've come up with so far are:
scala -cp .:[path_to_processing]/lib/core.jar Test
Hopefully you should see a window with a black background containing a white rectangle.
I have no idea whether I'm going to like Scala or not (to be honest Python is looking more promising at the moment) but it'll be interesting to see whether it's an improvement on straight Java for the kind of code I'm writing.
