More Modular Madness

Yesterday brought an announcement that Sound Transform Systems is offering a new module for the Serge. It’s called Kracken (yes, that’s bad spelling — it should be Kraken). It looks insanely cool. Sound Transform has no web presence, but you can read all about this stuff at Carbon111’s Serge hub.

My gear lust kicked in immediately. I sat down and tried to figure out what lineup of modules I’d need in a Serge. Before long I had come up with a design for a seven-panel system — probable cost, $30,000.

But wait, there’s more! A number of manufacturers sell Euro-rack modules whose capabilities are somewhat different from anything Sound Transform offers. Things like a CV recorder, a MIDI-to-CV converter, and a joystick that does vector mixing. Add another $8,000.

Am I about to go buy a system? Not this week, I think. Twenty years from now I might need that money very badly to pay for four months in a nursing home. You never know.

Having a modest proficiency with Csound, it occurred to me to try modeling a hardware modular system in software. The design challenges are interesting, the cost is $0, and Csound can do probably 98% of what a large modular can do, plus a few dozen things that it could never do.

Here are a couple of modest examples — not pieces of music, just audio clips. For the first one, I grabbed the code in an example in the manual, added a filter, adjusted some values, and came up with this oddly gargling alien voice:

[audio https://dl.dropboxusercontent.com/u/18276384/gargle.mp3]

To be sure, this isn’t a very sophisticated use of Csound. The point is, it uses five interpolating random number generators, each with its own range of values and speed of fluctuation. Even a large Serge would likely have no more than two or four random voltage generators and four lag processors for smoothing the randomness. You wouldn’t be able to control the rate with which new random values were generated, and you couldn’t do five random processes, not without buying more hardware.

Using the Csound duserrnd opcode, you can specify an arbitrary set of values and weight the probability that each of them will appear at the output. There’s probably a way to do that with the Serge TKB module, but to do three instances of it at once, you’d need three TKBs, and they cost more than $2,000 each. Here’s a nice little piece of ring modulation using three duserrnd instances, each drawing from its own table of probabilities:

[audio https://dl.dropboxusercontent.com/u/18276384/triple_ring.mp3]

The benefits of a software modular are hard to avoid. Even so, such a music system presents the user with a few little obstacles. I’m not sure yet how burdensome they may prove to be.

First, the process of creating a configuration of software modules in Csound is not intuitive. You have to stop the audio, write some code, and then start the audio again. A hardware system never stops producing signals, so the workflow is entirely different. (Csound 6 does have live coding, but with some limitations.)

Second, a good hardware modular has a lot of control points (knobs, switches, and jacks for patch cords). I have an old M-Audio Axiom-61 MIDI keyboard with eight sliders, eight buttons, eight knobs, and eight percussion pads. In a pinch, I could use the entire keyboard as a bank of 61 switches. But 16 sliders and knobs are not even close to the number of knobs that a hardware system would have. On top of which, in a hardware system you can see what each knob will do, because it’s physically located on the module it’s going to affect. My MIDI controls are unlabeled, and each of them could do anything that I happen to want. As a result, learning to play the Axiom interface in a musical manner, even after I’ve designed my system/instrument, would be more difficult.

The third problem, option paralysis, is allied to the first two. What do I want this slider to do? One slider can do five different things at once (or 20) if I want it to. In order to decide how to code its function, it helps to start with a musical idea. With hardware, you don’t need an idea — you just patch things together, twist a few knobs, and stop when you hear something cool.

Option paralysis is also triggered by the open-ended modular nature of Csound. With hardware, if you have four oscillators and two filters, that’s what you have. With Csound, you can pile up as many oscillators and filters as you happen to need. If an ADSR envelope won’t do the job, you can write one with a dozen segments. There are way too many choices.

A couple of years ago, I wrote a UDO (user-defined opcode) for Csound that models the Serge Universal Slope Generator. Modeling the Kraken — oops, I mean Kracken — as a UDO should be quite practical. But I’ll still need to have a musical idea about what I want to do with it.