First the Nuts, then the Bolts

Having been slightly encouraged by an offhand comment in an email from Roger Linn, I’m thinking a bit more about how one might design a modular synthesizer in software. Not that it hasn’t been done before, but I may have a slightly different take on the concept.

Reaktor may be the ultimate software modular, in some sense. Open up the patch and it’s like a box full of wires running every which way. Creating your own instrument in Reaktor is not impossible for mere mortals — I’ve done it — but like Csound, Reaktor is basically a programming environment. It has a lot in common with Pd, and bears precious little resemblance to a hardware modular.

Reason comes closer to being something an untutored musician can deal with. It even looks like hardware. But while it’s amazingly deep and versatile, Reason embodies a few odd limitations. No support for microtonal tuning, for instance, and precious little in the way of processing for control signals. Really, Reason is a music production environment, not a single integrated instrument.

I suspect there would be a place in the world for a software synthesizer that actually looked and behaved like a hardware modular. The closest thing I’ve seen are a couple of ARP 2600 clones (from Arturia and Way Out Ware). But while I have a lingering affection for the 2600, it having provided my first exposure to sound synthesis, it’s not exactly a modern or forward-looking design. No, a lot more could be done with this concept.

Here’s the tricky bit, though: I’m not a real programmer. So how exactly would I go about creating a working prototype? How would I learn enough about programming even to attempt it? I’m not saying this is impossible — I’m just saying, I’m not sure how I would do it.

A working prototype would need, first, a whole bunch of synthesis code, and second, a graphic user interface. I probably know enough about Csound to create a working synthesis engine, and by using Processing with the Control.P5* extension, I can probably create a usable interface. For a prototype, Processing can send OSC messages to Csound. This approach is a bit messy, and it would be a lot of work, but up to a point I think I can probably manage it.

Up to a point. Though Csound is incredibly powerful, it has a couple of holes in its feature set. It lacks, for instance, an envelope generator with real-time control over the lengths of individual segments, and that’s certainly a feature that musicians might want or expect in an instrument that seriously attempted to model a hardware synth. In Csound, all of the time values and curvatures of an envelope have to be specified when the envelope is initialized, before it starts running.

It occurs to me, naturally enough, to wonder whether I might be able to figure out how to create a new Csound opcode that would make those parameters accessible to real-time modulation. Csound is written in C, and I used to know a little C. But this is where I hit the wall. I have no idea how to download the Csound source code, much less how to compile it after editing it. Apparently the repository is managed by a DVCS called git. I got git. After posting a message to the Csound mailing list, I learned that the instructions on the SourceForge page for getting Csound through git have a typo. Oops. So now I have the source code. I can probably find a C compiler somewhere too. The instructions on how to compile Csound (and instructions do exist) assume, however, a far greater level of understanding of computer science than I possess as a fumble-fingered hobbyist programmer.

Learn online? Sure, great idea! But where would I start? You’ll find any number of tutorials online that will tell you how to write an if/else block, or create an object with public and private methods. I don’t need to know that stuff, what I need to know is the big picture: how to put the pieces of the puzzle together.

Even if there were a good college nearby with a crackerjack computer science department (there isn’t), I wouldn’t want to sit through two years of classes in order to gradually piece together what I need to know. It shouldn’t take more than a month or two to get myself up and running — but at the moment I don’t even understand how to tie my track shoes. Running is not on the agenda.

Using git and a C compiler are not the only challenges that I’m staring at in perplexity. In theory, it’s possible to run Csound within Processing using an extension called csoundo, which was written by Jacob Joaquin. This might be a great deal more tidy than running Processing and Csound side by side and relying on OSC communications. But I can’t get csoundo to run in Processing, neither in Windows nor in MacOS. There may be a problem with where I put the .jar file — or it may be something else entirely. I have no ghost of a clue.

These problems are not simply time-consuming. They also sap one’s enthusiasm for the project. If I’m sitting here in the evening and I would like to work on the project, but I don’t know how to get past a roadblock, I’m liable to end up playing Free Cell instead.

Hell, I’d be willing to pay a consultant to set up my system. An expert could probably do it in two or three hours. But where would I find a consultant? Yeah, I emailed a guy who teaches computer programming at the local community college. He answered the first email by saying he’d get back to me on Monday, when he was back in his office. Since then, nothing.

I’m pretty sure there’s a solution. But I don’t know what it is.