Delays and random drum synth

Andrew Booker 2008-11-25 23:26:58

Earlier in October we did an Improvizone gig in South Woodford, NE London. There were many enjoyable bits, all of which Os recorded as usual, and which one day, I promise, I will get round to mixing and uploading highlights to the list. Not only did Os record the gig, he also videoed a bit, and posted it here on the Darkroom site. We went down reasonably well with Jamie (the management), who suggested a possible a Sunday afternoon chillout session.

That could work very well. But first, we need a recharge. The four of us have played together several times, we've come up with some truly terrific stuff, and plenty of good things happened at this gig. And yet, I did not think much of it. It seemed to me we played well enough, but with none of the wonder or excitement from when we were first getting together and improvising cool things live. As Mike later put it, once more without feeling.

The first person I blame for this is myself. If I have one platinum rule for improvising in groups of musicians, it is keep each other interested. And yet I've barely programmed any new patches in my electronic drum kit since we started doing gigs in Feb 2007. However well I may be able to tell them apart through headphones, the patches I do have are all starting to sound the same through my amp. I need to come up with some surprises, and I've known this for a long time. For a while my approach was, take the same set of sounds and treat it with different effects to make them sound unrecognisable. This works in principal, except it means that by the time I get to a point of familiarity with my effects setup, it's probably time to change it.

The first thing I have to stop messing around with and settle on a proper technique is using a delay. When I have a good delay and a click properly in sync with each other, it's fantastic. When they disagree, it's a nightmare, and all I want is to be at home with a book and a brandy. When Os first started supplying me with a click track, I was either controlling my delays by typing numbers into a delay plug-in in Cubase, or setting them with the wheel on my Ensoniq DP4, both to the nearest millisecond. This worked very well when he and I agreed a tempo numerically, when I would look up a corresponding delay using my quick HTML page to convert bpm to ms delay time.

It definitely does not work if I start playing and leave Os to work out the bpm, especially now that I have regressed to controlling delays with an ancient Alesis Microverb, whose delay time I can only set to the nearest 20ms. This would be fine if I controlled the tempo and could simply start playing. But Os has to tap in the tempo for my click, which he does not monitor himself, and which I don't think he can adjust once it starts. It's never exactly right, and now I have a delay that I can't fine-tune, a mismatching click, meanwhile the rest of the band has started playing to me, because they know nothing about the click in my earphones.

You can hear this in the video Os took. We more or less get away with it, but the delay is too fast for the click, and there's nothing I can do about it. Oh, and listen especially for my very junior left foot missing a beat in a really nasty way at 3:26. After that it gets better and turns into quite a nice piece, but I can constantly hear the push-pull of the pulse as I try and serve the delay time and the click tempo, and occasionally scratch my nose. Especially obvious problems kick in at 5:09 when Os begins a half-tempo groove he sampled from me. It locks exactly with his click, but against my delays feels way behind the beat.

Blah and blah, excuses ad infinitum, what I really need is a breath of clean fresh air into my drum setup, which is the original subject of this article. I want a set of interesting drum sounds that are going to be variable enough without me having to resort to delays, and that are going to be a step away from my current set of programmed patches. One thing that has always irritated me about electronic drum manufacturers is their obsessive attempts to achieve the most realistic drum sounds possible. I don't want this. If I wanted real drums I'd bring a real kit. What I really want is fun sounds that don't resemble drums at all. And I want an easy way of mutating the sounds so they will always be unique.

Almost a year ago I had the idea of making some analogue effects using VCOs and bits to generally wreck the drum sound. I got a little way into it and almost assembled something onto veroboard. But playing with analogue electronics in an age when we all program stuff into computers is like having a wrist watch that needs a power supply.

Earlier this year in the spring I enjoyed some success with delving into video creation in C++, for projecting onto backdrops at Improvizone gigs. Fast-forward to the present, and I'm doing time-lapse photography using a webcam and my own capture software running on a laptop powered by solar electricity in my shed. This is a whole other chapter, about which I will go into more detail another time. Suffice to say I was reasonably successful with that project, which in turn gave me the idea of using C++ for randomly generating WAV files of weird drum sounds for loading into my Roland SPD-S sampler. I might have bothered to get further with this were it not such a crushing bore to load WAV files into my SPD-S. So a few weeks ago I had the idea of abandoning the WAV file approach, and writing software that would play randomly generated drum sounds in response to MIDI note-on messages. I would make my own control panel that would be easy to use with a couple of fingers of one hand that is also holding a drumstick.

The obvious route would be to write a drum synth plugin for Cubase, which I have used live as my MIDI sound generator. I may do this eventually, but I don't really like Cubase, and most MIDI-related software does not satisfy the requirement of being easy to control live with two drumsticks in your hands. Also, I like an opportunity to learn a few things when I write software... in this case, how MIDI and audio works in Windows, plus some practice at multi-threading (coders know what that means, the rest of you are lucky). The nice thing about C++ on Windows is that it's the language of the operating system, and many sound/MIDI tools available in their native form. They're not necessarily beautifully documented, but if you're prepared to poke around in the MSDN and try their Multimedia stuff, you'll find all the ingredients. The nasty thing about working in (unmanaged) C++ is that the GUI (Graphical User Interface) tools are really dated and clunky. Nobody uses C++ for GUIs these days unless they absolutely have to.

Anyway, I'm happy to say I've got somewhere with this project. It is the first time I've ever found a use for the MIDI implementation chart in the back of a manual. In fact, the SPD-S manual tells me exactly which bytes mean what in the incoming MIDI data. The hard part so far has been playing sounds in Windows, using DirectSound. Oddly, the default procedure is to play a sample in a loop. You load your sample into a buffer, issue a start command, then DirectSound notifies you when you reach a specified point in the sample, eg the end, whereupon you issue a stop command. If you don't, it keeps playing the sample in a loop. I'm using one buffer per MIDI note, where a MIDI note corresponds to a drum pad on my kit. But I only have one notification method, so when I receive a stop command, I have a little bit of fun working out which buffer is the one I need to stop, since the sounds for each pad are not all the same length.

All that is just through the internal soundcard. Who knows what fun I have in store trying to get this (a) to play through the external soundcard and (b) to be recorded in Cubase. So long as we have Os, I don't need to worry about recording, and provided I've got a good effects unit, I don't need Cubase either. The advantage of playing through an external firewire soundcard is that I'd get better latency, but it's already pretty impressive on the laptop, ie inaudible. I haven't measured it yet.

Meanwhile, my approach for generating the samples is pretty much as it was back in the summer when I first tried creating WAV files. I started just with simple sinewaves, but now I'm moving towards generating several waveforms of different frequencies and either adding, multiplying or frequency-modulating them together. I'm then writing them to the DirectSound buffer rather than to a WAV file. The trick is, as the waveforms get more complicated to build, to have them prepared in a queue, rather than trying to generate them with each stroke, which is too slow. This limits the responsiveness to velocity and expression controls in real time... but I'll worry about that later. For now, I just want to cue up some interesting sounds.

The interesting bit is using random number generation to slightly vary the sounds each time. So although I'm hitting the same pad, the sound is never exactly the same each time. The next interesting bit is to get the sounds to mutate over a period of time, so that they gradually move from one group of settings to another over several minutes. All automatically, without me having to do anything.

Darkroom: Some Of These Numbers Mean Something << | >> 2008 retrospective