BH: Hi Tim, thanks for agreeing to do this email interview. I'll get started:
You've just released a new Shalmaneser album, TICKER, available for download at http://shaltunes.com. The tracks often have the intricacy of classic Planet Mu or WARP releases, and seem to share the same kind of hazy connection to house. It sounds as though sound design is a very important, but the structure of the tracks perhaps isn't the kind of thing people quickly associate with SuperCollider, the environment you used to create the album. Most SuperCollider works we hear tend to be freeform soundscapes, noise pieces or interactive sonic experiments--there's often a strong academic element there. Your music seems to be coming from a different direction, can you say something about how and why you've ended up using SuperCollider?
TW: Flashback to 1981: I'm 19 years old. Inspired by Tangerine Dream, Klaus Schulze, and Pere Ubu, and possessing spending money for the first time in my life, I troop down to the music store and buy the synthesizer with the most knobs on it, which turned out to be a Crumar DS-2. The first thing I discover is that I can't make those Allen Ravenstine sounds, no matter what I do. Eventually I figure out that this is because the Crumar doesn't allow you to modulate one audio-rate oscillator with another; you can only use the LFO. "Why won't it let me do that?", I ask, for the first but by no means the last time.
Forward to 2003: I've used analog modulars, Csound, and Max/MSP, but none of them have completely satisfied me. Then I read on some mailing list that SuperCollider had gone open-source, and one day when I'm home sick with a nasty cold I decide to download it and try it out. After a couple of hours I realize that I've finally found a tool that would stop me asking that question.
I started by using it for the electroacoustic music I do under my own name. Before long, I got the idea to do algorithmic beat slicing, which led to the material I produce under the name Shalmaneser. I didn't know there was already a third-party library called BBCut for that purpose, so I ended up reinventing the wheel a bit (but also doing some things differently).
So the short answer is that I came to my current style from academic electronic music, and carried over my use of SuperCollider from there. But one of the great things about SC is that it doesn't have a strong stylistic bias--it lets me do what I want to do rather than pushing me in a certain direction.
I do handle compositional structure a little differently, though. Originally, I designed my system for live performance, with controls to let me start and stop synchronized processes in real time. When I started making tracks, I began by writing scores in SC to mimic my live control moves with greater precision, which worked pretty well, but I eventually decided to use Pro Tools as the "tape deck." Now I work a bit like a documentary filmmaker, generating large amounts of raw material in SC and then editing/distilling it down to a tight composition in PT. This also allows me to add acoustic instruments and keyboard lines (also controlling SuperCollider) easily.
BH: Should we be imagining a main SuperCollider program that you use in different ways, or do you use a toolbox of smaller, single-purpose scripts?
TW: The latter. In fact, I often start completely from scratch and doodle around.
BH: Does your software resemble a conventional audio application in the sense of having a GUI or do you 'drive' it from a text console?
TW: For live use I have a screen that shows me what patches are selected, but that's it. If I need real-time control I map it to MIDI sliders.
BH: How distinct are the 'audio generation' and the 'arrangement' activities in your music making? Do you find yourself working for long stretches in one mode and then the other, or are you often switching back and forth between them, with a certain result in mind, as you put a track together?
TW: Between tracks I do a lot of exploratory coding, just messing around with stuff: "I've never used this UGen before, what's it like?" or "maybe the rhythm generator would be even cooler if..." or "let's granulate the radio today."
When I start a track, I'll typically use a few of these scripts as seeds. Some of them also get turned into patches that can be played from the keyboard. But I very quickly get into a back-and-forth mode as the track starts to take shape and demand its own custom material.
BH: I'm interested in the potential of non-realtime processing in SuperCollider stuff for implementing predictive 'look-ahead' audio file modification (but I'm having a bit of a hard time finding many basic examples of this kind of stuff). I wondered if you're using SuperCollider for any non-realtime processing;
TW: I never have. As you point out, there are a lot of interesting possibilities there.
BH: Could you describe one of the scripts that features on the new album, what it does and how you generally use it?
TW: Here's an example (from "Corpsicle Pulse") that's small enough to examine in detail. The idea is to take a drony metallic file and turn it into a rhythm. This is not code I would reuse; it's just a specific solution to a specific problem.
(
{
var tempo, clock, rates, accents, imp, mix, norm, env, accent, unaccent;
b = Buffer.read("...path to soundfile...")
// song tempo in bps
tempo = 125/60;
// sixteenth-note tick
clock = Impulse.ar(tempo * 4.0);
// accent values for rhythm
accent = 1.0;
unaccent = 0.75;
// This will subdivide the clock in a random pattern
rates = Demand.ar(clock, 0,
Dseq(
({[1.0, 4.0, 2.0, 1.0, 1.0, 1.0, 2.0, 2.0].scramble} ! 2).flat * 4.0, inf));
// This accents strong beats
accents = Demand.ar(clock, 0,
Dseq([accent, unaccent, unaccent, accent, unaccent, unaccent, accent, unaccent, unaccent, accent, unaccent, unaccent, accent, unaccent, accent, unaccent], inf)
);
// This drives the percussive envelope
imp = Impulse.ar(tempo * rates);
// Play back five copies of the drone file, slowed down to match
// the song tempo, but with drifting speed for chorusing effect
mix = Mix.fill(5, {
PlayBuf.ar(2, b.bufnum, 125/140 + BrownNoise.kr(0.01)) * 5.levelScale
});
// Remove the natural envelope of the drone
norm = Normalizer.ar(mix);
// Create new percussive envelope with drifting attack and
// decay values
env = Decay2.ar(
imp,
LinExp.kr(LFNoise1.kr(0.23), -1, 1, 0.005, 0.02),
LinExp.kr(LFNoise1.kr(0.3), -1, 1, 0.125, 1.0) * A2K.kr(tempo * rates).reciprocal * 4.0);
// apply to the drone
env * norm
}.play;
)
BH: Thanks for that. I think this is a great example for new SC users to study because it's self-contained and the comments make things very clear.
Is there a technique or idea you're currently excited about exploring in your future SuperCollider creations?
TW: NRT, as you mentioned, is one. I'm also interested in getting more into FFT processing, of which I've done very little, and Ambisonic processing for surround sound. Someday I'd like to do an installation with completely self-running code.
BH: Finally, is there any advice you'd offer to people just starting out in SuperCollider?
TW: Learn how to write classes. It's a bit arcane at first, but once you start creating reusable code, this will make your life much easier.
Join the sc-users mailing list. There's a lot of good information on there, and people are happy to help with questions, even newbie questions.
It's easy to get caught up in programming a grand unified system--there's always just one more thing to add--but don't forget to stop and make music once in a while!
BH: is there anything else you'd like to add?
TW: I'd like to mention that I have a whole bunch of music (electronic and acoustic) available at
http://doubtfulpalace.com.
Posts
