Just over a month ago we ventured out for our first Improvizone appearance since June 2010. It is fair to say I had my feet up doing absolutely nothing during 99.5% of the down time between this event and the last. However, I did have a couple of innovations in the electronic drum department to bring to this most recent outing, involving my trusty six-year-old laptop doing a couple of things it had not done for me before.
Have a look at the three sections in my dashboard screenshot below.
In the middle is my delay time calculator which I knocked up a few years ago. This is an essential tool for converting an agreed number of beats per minute into a range of possible delay times, except I have not been able to make extensive use of it at gigs because it's been a while since I used a delay unit that let you dial in the delay time down to the nearest millisecond. I've been using some pretty remedial audio delay solutions in the last few years, but really I wanted something ultra simple. A pure delay. Put audio in, get audio out n milliseconds later, nothing else. I can do feedback via a mixing desk, with other effects inserted in the loop if I want. It struck me that an elementary delay should be available very cheaply. I already had one in the shape of an Alesis Microverb, but that tool is noisy and has poor delay time granularity (to the nearest 20ms). I never found one and gave up looking long ago.
So I wrote one. Introducing the Improvizone Command Line Delay, the section on the left of my dashboard. Observant technically aware readers will see it's a java application, to which you provide a delay time in milliseconds, and that's it. All it does is copy the input sound buffer to the output, delayed by the specified interval. The input comes from a pre-fade aux send on the mixing desk. The output goes to one of the regular inputs. This gives me all the control I expect from a normal feedback delay unit using knobs on the mixer.
Given the delay unit is running on a Windows laptop, and such machines have a habit of wondering off for a few moments and spending most of their CPU on something of no interest to their users, I need to build self-compensating behaviour into the unit for it to run reliably. Initially it takes the timing difference between the input and output audio buffer positions, and introduces the necessary delay as it copies a chunk of audio from one to the other. All being well it should then just copy samples directly, however it continually monitors the input to output latency. If I suddenly launch a greedy piece of software that steals too much CPU from the audio processing, the unit compensates by revoking a little of the delay it originally introduced. You can just about see that happening in the screenshot. It starts with the 577ms delay I entered, but later needs to pull back at little when, for no good reason, I launch Firefox.
That leaves the section on the right. By the looks of things it's a web page with two graphs of sinewaves at different frequencies. Those are actually animations. The waves move off to the left at frequencies determined by the vertical sliders and indicated above the graphs. The current value is where the line meets the right hand vertical axis, and is updated every second or so. The page sends each new value to a special web server running on the laptop. When the web server receives these values, it converts them to expression controller values and sends them via MIDI to my SPD-S drum module. These MIDI signals then modify, for example, the frequency and depth of a pitch shift effect on the SPD-S, or whatever effect I have set up for the current patch. I was very excited to get this working, and it proved to be awesome.
About the evening itself, there were a couple of new happenings. Firstly we welcomed our seventh live bassplayer, Jordan Muscatello, seated in front of me with his Orange amp and meshing seamlessly with our hypnotic ambient pulses. With him were regulars Mike and Os. Mike used his new Hughes and Kettner TubeMeister 18 amp, with ideally suited XLR DI connection. Os, despite making the journey on foot, brought pretty much everything he usually uses except a keyboard.
Secondly we made ourselves comfortable on the smallish stage of a new venue, The Alleycat Bar on Denmark St. Anticipating having to save space, I set up my kit in a narrower and more vertical arrangement than usual, with the SPD-S uppermost and the TD-6 pads underneath. It more or less worked, although I continued to find the SPD-S is much more suited to supplying subtle and unidentifiable-sounding beats than the TD-6, which is trying too hard to sound like real drums. I also have the balance wrong on the TD-6. Most of the sounds are at the right level, but all the snare drum sounds blow me off the stool. Maybe it's just my amp because I didn't notice it in the days before.
I may need to think of some better names for my new software tools. Command Line Delay collapses nicely into CLiDe, which I quite like, and the other one I'm thinking is the Midifier. I was expecting CLiDe to work out fine with no surprises. I was pretty thrilled to have tried the Midifier, because although I'm just using simple sinewaves here on two controllers, it feels like my first step towards generative electronic drum sounds. Sounds that change themselves, because I'm too busy.
My next bit of development for CLiDe is to introduce some mess into the delayed signal. I'm thinking some kind of distortion, or ring modulation, which sounds great with drums. Development on the Midifier involves extending it to send system exclusive messages to my other drum module, the Roland TD-6, and possibly to another drum sound module. Hopefully that will get me using that half of the kit more.
Meanwhile I have the audio from this session to work through and turn into downloads. If I'm as quick with this lot as I was with the last, we should all find ourselves enjoying the material for the first time well into 2014.