Last weekend I played at this:

It was fun: I’ve been getting some positive feedback on my set over the last few days, and a certain number of people wanting me to run a new event sometime in the near future.

However, I ran into one limitation I’ve not previously encountered: lack of space for my controllers in the DJ booth. At most other events I’ve set up the DJ booth myself: and have mostly been playing alongside other laptop jockeys, so have always had space for MIDI gear. This time, however, the guys running the PA were all vinyl or CDJ users: and didn’t make any space for we laptop users to set up. This meant I ended up playing from the edge of the table: somewhat uncomfortably and unable to properly see the audience.

In response to this, I’ve come up with a Plan. I don’t really want to be moving turntables and so on around – since that will inconvenience other DJs: but I am working with a friend to build a portable wooden stand that will fit neatly over a Technics 1200 or anything smaller: and have space for my APC40 and LPD8. This will also resolve the height issue I tend to have with DJ booths: I’m a reasonably tall guy, so I often find leaning down to see my screen and use my controllers ends up giving me a sore back, and makes it hard to watch the dancefloor.

I’ll post pictures of the first prototype one it’s built. Looks like it might be as soon as this Friday.

One of the small but persistent issues I’ve had with Ableton is the default theme. It’s not bad for daytime and studio use, but it’s completely wrong for DJing. When you’re in a dark environment like a club, you don’t want your computer screen to be brightly lit up, as this makes it harder for your eyes to adjust when you’ve been looking at something else, and encourages you to spend lots of time staring at the screen, rather than interacting with your audience. It also casts an eery glow on your face, which is never sexy.

To avoid this, people working in dark environments tend to invert the default colour scheme on their computer. Instead of having dark text on a pale background, they have pale text on a dark background. This means far fewer pixels are lit up, so there is less overall light and the text stands out more. This is easier on the eyes (and frankly looks cooler).

Sadly, Ableton does not ship with any useable dark themes. There are some extras, but they’re basically just minor colour changes: and haven’t been designed for DJing use. It’s important that the key features are picked out in strong colours, so you can see what’s happening at a glance.

Thankfully, someone has written an Ableton Theme Editor, which lets you create custom themes for Ableton. You can also download other people’s themes: there are some good ones at http://forum.ableton.com/viewtopic.php?f=1&t=134087&p=1060306&hilit=themes#p1060306.

There is one minor limitation in Ableton’s theme engine, sadly. The default palette of colours for clips is quite bright: which works fine when the clip names are black – but is hard to read when they’re white. There are a few colours you can use that are readable, but it would be nice if Ableton added some darker clip colours for people with white-on-black themes.

The current theme I use for DJing looks like this:

I threw together a quick video over the weekend, explaining an audio processing technique I use to split audio into “high” and “low” frequency bands, and apply effects separately to each band. The cool part about this (as opposed to using high and lowpass filters) is that it’s a lossless separation: so it doesn’t change the audio stream in any way (until you apply effects, of course).

I’ve found this technique incredibly helpful when building DJing effects, as it allows me to utterly mutilate/phase/beat-repeat/flange the high frequencies of a track, without affecting the bass and kick in any way. One of the limitations of classic effects is that they apply to the entire audio stream, so they can make the kick messy or otherwise cause the energy of the track to drop. Isolating the bass and leaving it untouched avoids this problem entirely.

The other cool aspect of this technique is that I can sweep DJ effects over a frequency band. I’m quite fond of starting a flanger running on the very highest frequencies of my audio stream, and slowly sweeping the high/low cutoff down, until the flanger is affecting everything except the kick. This produces a sound not unlike a classic filter sweep (Xone92 or DJM-800 style), but without changing the overall frequency footprint of the track, lowering the volume or otherwise causing grief.

Lastly, it lets you do weird glitch effects that de-sync the audio streams. The simplest way of doing this is to apply a beat-repeat to the high channel, so the melody stutters while the bassline keeps going.

The video below explains the theory behind this technique, and shows how to set it up inside Ableton in about 30 seconds. Please don’t shoot me because my signal theory is grossly oversimplified.

You can download the Ableton Rack shown in this video from http://marshall-law.co.nz/audio/boywonder/Splitter.adg.

If you want to see some example DJ effects built on top of this rack, take a look on the Master channel of the latest version of my DJing Template..

http://www.vimeo.com/8805159

Just to be a difficult fellow, I recently changed from the venerable-and-fiendishly-complex ZShell to the lightweight, spiffy and pretty Friendly Interactive Shell.

It made me realise a few things. Primarily that shell development has been hamstrung by the perceived need to remain compatible with Bash, so while shells have become better, they’ve kept using ugly/outdated syntax, had awkward structures and been stuffed with unnecessary features.

The Fish design document has some interesting commentary on all this. Several things stand out to me, firstly the “law of orthogonality”:

The shell language should have a small set of orthogonal features. Any situation where two features are related but not identical, one of them should be removed, and the other should be made powerful and general enough to handle all common use cases of either feature.

Secondly the “law of minimalism”:

The shell should only contain features that cannot be implemented in a reasonable way outside of the shell. A large performance decrease, as well as some program complexity increase is acceptable in order to improve separation..

Both these principles are strongly compatible with development in Ruby, where consistency, readability and structural/syntatic elegance are prioritised over performance or mathematical elegance.

Thirdly (and my favourite), “configurability is the root of all evil”:

Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it.

Again, this meshes nicely with Ruby and Rails development. Ruby is what is termed “opinionated” software: it has strong implementation preferences and sensible defaults, explicitly discouraging manual configuration or non-standard implementations. One of the benefits of this is that consensus around best-practice can be formed (and enforced) more readily, and the overall Ruby code-base is much more consistent than that of other languages.

While these principles obviously only apply to specific families of development (although I suspect cases where they don’t apply are relatively specific; firmware, banking, etc), they’re very valuable in the right context. Software development has inherited a specific set of practices and concerns from previous generations of developers: but many historic problems are no longer concerns, and I think many historic priorities have proved to be long-term detrimental. This is partly a consequence of technological improvements (better languages, hardware, etc), but also I think a function of collective experience.

Garbage collection, dynamic typing, mutability and introspection are all code concepts that caused consternation when first introduced, but it’s become clear over time that the potential issues with these were over-emphasised, and the benefits of using them in the right contexts are large.

My favourite comparison is between SOAP and REST. While in an abstract sense, SOAP might be argued to be a more complete/extensive/engineered solution, REST is much more functional: being lightweight, simple, easy to implement and more elegant. As a consequence, since the introduction of REST there has been a proliferation of APIs using it: which are consistently formatted and have a low barrier to access. SOAP is characteristic of a previous generation of software design, whereas REST is fairly typical of more modern practices.

Obviously, like I stated above, these principles and changes only apply in some contexts, and there are many problems that need low-level solutions: but for the most part they’re quite sound.

This is mostly an exercise in making fun of Java

Last night I committed a new version of my DJ Template to http://github.com/willrjmarshall/AbletonDJTemplate

The primary new feature is the addition of a white-noise generator, that allows a DJ to cut gated and filtered white-noise patterns into the mix. It’s inspired by the Traktor template that’s demonstrated in the following video, but redone inside Ableton using native effects.

In addition to this, there is a set of new beat-repeat FX that are controlled by the Scene Launch buttons. These are quantized beat-repeats, that contain automation curves when held down.

I am hoping to produce a video that explains both these features over the next few days: although this is subject to available-time.