"When you own a hammer factory, you never actually pound any nails."
I'm starting to concentrate on making music with the tools I've developed. I have to thank Forrest and meriko, mostly, for the gentle nudgings to quit wanking with the code and actually apply it.
It's hard. We'll say for sake of argument that I'm working on an album. I know something about the overall shape of it. I have at least some basic idea of what three of the tracks sound like. I'm trying to get one of them nailed down and finished. It's probably track 2. Its working title is "Coast To Coast". (R'Lyeh turns out to be in the Pacific after all, so now the drive is westwards, but that's not important.)
I spent a day building structures in Mulch, getting sounds I liked, getting sounds that fit the feeling I was trying to create. Then I spent another day stripping it down to the essentials (Antoine de Saint-Exupéry: "You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away." This is applicable both to programming (hence the XP principle of Refactor Mercilessly) and to art. Then I started imposing some song-scale structure onto what was basically a loop. There are two problems with that structure at the moment: one, it's too homogenous (part 1: A B A C. part 2: D E D F. part 3: G H G I. etc. — once I put a structure on one of the parts I found myself copying analogous structure onto the others.); two, the transitions between parts are awkward. A live drummer would intuitively put a little fill on the end of a part to mark the transition; my drum parts switch drastically but the change goes unremarked.
The homogenous structure, I know I just need to rework. I have this tendency in my art to be meticulous for the first small fraction of a project, then lose focus and try and rush through the middle bit. I have to stop and go back and be careful through the middle. I can do this.
The transitions, I think I have a plan for, now. I'm just gonna cover the transitions with some unusual noise. (Okay, a lot of the song consists of unusual noise, so that's not as incongruous or sloppy as it might sound.) I had a candidate noise in mind, one I kept accidentally producing by saving the song-in-progress while it was playing. That was the sound of buffer underrun, when Audiomulch wasn't producing fresh sample data fast enough for the sound hardware, so the hardware kept playing the same 100-millisecond portion of the song over and over. It's a bit like a muffled machine-gun or jackhammer noise. It's used in more than one industrial track (though I can't think of any at the moment). I can't do the noise on demand in Mulch, and can't do it on the hard-disk-recorded version at all. I could write a plugin to do it. Really easily. But I was trying to use the tools I already have. I thought about various combinations of Mulch contraptions I could wire together to make an approximation to buffer underrun noise, but wasn't really inspired to experiement with it. So I just dropped it for a day, played some Grand Theft Auto, did some laundry. Tonight, while chatting with Forrest, I realized that I have more tools than just Audiomulch; I have a bass guitar. It doesn't make buffer underrun noise, but if I put it through some distortion and whomp on it, I bet I can get a noise which will fill the niche. And without writing any more code. Unfortunately I probably won't have a chance to try it for a few days...
The buffer underrun simulator does go into the pile of plugin ideas, though.
Progress has been slow on the audio projects recently. I'm trying to join the world of real software engineering practice, and something I've decided I need to learn about is the family of software development methodology known as Extreme Programming (hereafter XP, but please note that this has nothing to do with the recent Windows releases).
The basic deal with XP is that some people decided to experiment with taking software development practices which were generally believed to be Good Things and essentially "turning up the dial" on them. Automatic tests are good? Run the tests frequently, many times per day, after every substantial code change. Code review is good? Make code review constant by programming in pairs. Fixing bad code earlier rather than later is good? Rewrite bad code as soon as you see it. Writing unnecessary code sucks? Write the minimum code to do the thing you need to do and rewrite it only when your needs change, to avoid the possibility of doing work that never gets used. Short development cycles are less likely to slip, crash, and burn? Make the release cycle as short as you can, down to like three weeks. There's more that I won't go into; this isn't a tutorial on XP. Go here and here if you want to know more.
Some of the XP principles can stand alone, like the automated unit tests, but most of them are interlocked and only make sense as part of a whole way of life. You don't dare clean up ugly code, for example, without the automated test system in place, because you're liable to accidentally change the way something works.
The tests, in fact, seem like one of the cornerstones of the XP way, one of the few XP things I can straightforwardly do in my solo work, and so they're what I've been focusing on. I gots me a testing framework. I gots some automatic tests going. Unfortunately I have a large body of code already written for my audio stuff and only about 10% of the tests I need for it. I'm also learning that I'm not very good at writing tests. But I've been bitching about the sloppy code in the computer industry for so long that I have to bite the bullet and develop some good habits.
Ceej is actually responsible for pushing me over the edge into trying to learn XP. And not only does she not know it, she and I have never met in meatspace.
Besides the XP stuff, I spent a few hours today building a track up in Audiomulch. It's the theme music for driving across the country at speed in order to escape your past. I've been playing a fair amount of Grand Theft Auto, which is probably where the driving fast part came in. That, and everyone knows that R'Lyeh is in the Atlantic (yes, there's a connection). I need to rework some of the track setup. I think it's got potential though. I was slapping the headphones with my fingertips at 130 BPM as I fiddled with it, tapping my feet, bouncing around like a loon. I'm also constructing a sort of theme for multiple tracks. Album by Christmas. Cross fingers. At least an EP. Joel and I did an EP's worth of material in three or four days. Of course, he has talent and can play a guitar.
I wanted to get one more set of noises into the track. I bit the bullet and made Plark, my embryonic soft synth, take MIDI key event data. This is the first thing I've written that triggers notes in response to note-on events. It would be a milestone to brag about, except I did it in a half-assed make-it-kinda-work-for-now way. On the one hand I did embody the XP principle of "do the simplest thing that could possibly work" — it was simple and it mostly works — on the other hand I wrote some crap code that's going to have to come out like a rotten tooth, and I didn't even write any unit tests for it. I was "releasing my pig", a phenomenon which pair programming is supposed to defend against — both members of a pair won't usually be willing to release their pigs at the same time, especially with a teammate watching.
Writing tests for audio is hard. You try writing an objective test for "does it sound cool?" It's slightly, just slightly easier to write an objective test for "does it avoid sucking," as some forms of suck are programmatically detectable. Anyway, this revision of Plark is not going out for public consumption. It's not really Plark yet. It's baby Plark.
Acid reflux sucks, by the way.