Irreducible Complexity

I love the idea of interactive fiction — that the author can create a tiny model world in which literally anything might happen, a world that readers have to actively engage with in order to discover its secrets. You can do this in very satisfying ways even with authoring systems that have been around for more than a decade. (Inform 6, for example.) What has happened in recent years is that the designers who are developing the authoring systems have been piling new layers of sophistication and complexity atop those older systems.

The result, with both TADS and Inform 7, reminds me a little of paintings by Hieronymus Bosch — fantastically jumbled and exciting, but there’s so much going on that you really can’t hope to grasp or absorb it all. In spite of industrious efforts to make these systems friendly, they have grown increasingly arcane and difficult to use.

Tonight I started working on the new edition of my Inform 7 Handbook. There’s a new version of Inform 7 (6E59) just out, so it’s time to update the Handbook. I haven’t even touched the new features of the program yet — I’m still fumbling with the stuff that doesn’t quite work right. There’s a bad bug that crops up, for example, if the player is on what’s called an enterable supporter (for instance, a chair) and examines the chair. I may have found an easy fix for it. I’m hoping also to find a fix for the word-end-apostrophe-in-a-title bug. (If you call your game Goin’ Home, the title will be printed out within the game as Goin” Home.) People who read the Handbook are going to want to know this stuff. (But see below.)

I started digging into the Inform 6 layer, which is buried deep within Inform 7. Since I learned I6 once upon a time, I can sort of see what’s going on in the .i6t files — but my goodness, there’s a lot of code there!

I’d like to become an expert in this system, partly because it might give me ideas for a new game, partly because I enjoy learning stuff, partly because I’d like the Handbook to be as good as possible, and partly because I’d like to fix the damn thing so it works the way I want it to!

I also have a diametrically opposed impulse to go back to Inform 6 and forget about Inform 7 entirely. That would be a stroll in the park, comparatively speaking. But one of the nice things about complex systems is that they suggest artistic effects that you might not think of otherwise. Technically, you can do absolutely anything in Inform 6 that you can do in Inform 7, at least at the level of the game itself. But it might never occur to you to craft your own code for scenes or relations, which are standard tools in I7, and if it did occur to you it would be more work to build these things yourself.

Inform 7 has, in addition, some slick environment features, such as the ability to output a basic website to support your game. To say nothing of the built-in Index. So ultimately, it’s worth putting some effort into mastering it, even though I feel, at times, that I’m wandering through the Garden of Earthly Delights.

Footnote: The problem with apostrophes at the ends of words in game titles (for instance, a game called Goin’ Home) was definitely reported prior to the build of 6E59. We were told that all bug reports had been closed out, but this one wasn’t closed out, it was blown off. See what I mean about the Garden of Earthly Delights?

Graham Nelson “explained” his failure to fix the bug by talking about the need to export bibliographic data. If true, this is a dandy example of the kinds of complexity that the developers are slogging through. Most authors could care less about bibliographic data, but it’s probably needed in order to get the game listed properly on the IFDB website.

I’m a little suspicious of that explanation, though. I could be wrong, because I’m not a real programmer, but it seems to me that the problem arises because the title of the game is being output to the window of the interpreter software at a point after Inform has been set up to process text to make quotation marks look standard, but before the routine has been set up that processes the text so as to interpret bracketed insertions, such as [‘], which produces an unambiguous apostrophe. I can’t quite imagine why it would be difficult to output the title at either an earlier or a later stage.

This kind of mess thoroughly drains my enthusiasm for Inform 7. Maybe an expert will suggest a way to fix it. Or maybe I7 is just plain broke. We’ll see.

Do You Know Where Your Limbs Are?

One of the annoyances of being over 60 — and it can range from trivial all the way to fatal — is that your arms and legs aren’t always where you expect them to be.

Maybe you’re walking. Maybe you’re opening a cupboard or setting down a hot casserole. At a certain moment, your brain sends a rapid and highly coordinated stream of messages to your muscles, exactly as it has been doing for years — but then, in the blink of an eye, something bad happens.

Any of a number of things might cause a malfunction. Maybe the brain module responsible for sending the stream of messages got a little mixed up and sent them in the wrong order, or failed to send one of them at all. Or maybe the limb didn’t move the way it usually does. That could happen because a joint is a little stiff or the muscle tissues don’t have quite enough blood flow for the cells to contract energetically. Maybe the limb moved flawlessly, but your torso wasn’t oriented at the angle you thought it was, or the object you were trying to manipulate wasn’t quite where your brain thought it was. Maybe the module in your brain that’s supposed to monitor feedback from the limb during the procedure was taking a little nap, so the feedback messages never got to the module that was sending the messages to the muscles.

For whatever reason, you have an oops.

This morning I jammed my little finger coming out the door of the gym. For no reason whatever. I had pushed open the door, and I was stepping past/around the door, but my hand didn’t completely clear the doorframe as I swung around it. Oops.

That was minor. A friend of mine recently had an oops while walking around the corner of his vintage sports car, which was parked in the garage. His calf swung in a little too close to the sharp edge of the fender. The fender laid open a flap of skin, and he had to be rushed to the hospital.

You want to know why that old lady is driving 45 in the slow lane? It’s because she needs to go somewhere in her car. She doesn’t want to have an oops while behind the wheel. Far from being pissed off, you should be grateful that she knows how to be careful.


If it was easy, everybody would do it. That’s a motto that I’ve found to apply to quite a lot of human endeavors. Playing the cello, certainly — but also putting together a portable, yet highly functional workstation for playing microtonal electronic music. (Portable because I have some devious idea about being able to take this music out and play it for people.)

After struggling with the concept for a few days, I may have a first, very rough approximation. I’ve found that Csound can respond to MIDI input on the MacOS with low latency and good stability. In Windows, it’s a little glitchy, at least on my system. I haven’t yet tested whether it will play multiple notes on complex instruments in the Mac without spitting up. We’ll see.

One advantage of Csound is that it’s free and cross-platform. Another: It’s a very sophisticated audio programming environment. Yet another: Csound doesn’t try to enforce a 12-notes-per-octave tuning. You can devise whatever strategy you’d like for deploying pitches. The downside is, to create synthesizer sounds you have to write code. Likewise with composing: You get to type an event list. This is not an instantly gratifying activity.

I’m starting to see why drone music is so popular — not among listeners, perhaps, but among composers. You can generate a long piece more quickly if there’s a lot of repetition. Plus, it’s easier to conceive of a piece of music as an entirely intellectual process if it’s drone-based. Trying to remember a catchy melody long enough to type it into an event list is just a wee bit awkward.

Still, with the plentiful real-time inputs to Csound, a drone piece could be made very interactive. Hook up a bank of sliders and then stop and start loops by assigning them to MIDI buttons or keys. Yeah, this could be interesting.

The problem of mapping microtonal scales to a MIDI keyboard remains. I’ve written a simple Csound routine to trigger whatever pitches I’d like from the keyboard, and I can remap the keyboard to different pitches instantly, while playing. That’s the easy part. The hard conceptual work is figuring out what combinations of pitches I want to play from the keyboard, in pieces that I haven’t even written yet.

It’s like the old gag about the furnace repair man. He comes in, looks at the furnace, kicks it a couple of times, and it starts. He then hands the homeowner a bill for $100. The homeowner says, “That’s outrageous! A hundred dollars? All you did was kick it. I demand an itemized bill!” The furnace repair man takes the bill back and writes on it, “Kicking furnace, $5. Knowing where to kick, $95.”

Remapping pitches to the keyboard: easy. Knowing which pitches to play, and why, that’s more of a challenge.

Keys and Buttons

Gee, it sure would be nice if I had a workstation set up for playing microtonal music! I can play the music, sort of, with my PC and a conventional MIDI keyboard, but the latter is way less than ideal. When you play 31-note-per-octave music on a conventional 12-notes-per-octave keyboard, a single octave covers two octaves and a fifth. Try playing fast scales with that layout!

So tonight I went scouting around for alternate MIDI controllers.

It’s a pretty discouraging field. Button grids like the monome and Ohm64 have become fairly popular as controllers for Ableton Live. (I recently reviewed the Ohm for Keyboard.) But the buttons tend not to be velocity-sensitive. You can trigger stuff, but you can’t play expressively. Playing expressively, in the world of dance music where Live finds its most natural home, seems to be obsolete, if not actively looked down on. But I digress.

A couple of years ago I reviewed the C-Thru Axis, also for Keyboard. Its buttons sense velocity, but they have a very shallow key dip, which means that it’s hard to control the velocity data output using your fingers. And the layout of MIDI notes is fixed. What’s worse, the fixed assignments are redundant (several keys per MIDI note) in a 12-note-per-octave pattern, which is truly a disaster if you want to play microtonal scales.

C-Thru has recently introduced a stripped-down version, the Axis-49, in which you can give each key a separate MIDI note number. This is an improvement, because it lets you process the MIDI notes through an application like Max to create whatever scale layout you need. But there’s a downside: No mod wheel or assignable knobs, just a bare button grid.

Plus, I’m finding that Pd, a very nice freeware music programming system that I’ve written about in the past, has a fairly grotesque latency, on the order of 100ms, between MIDI in and MIDI out when used in a fast Windows 7 computer. Maybe it’s not quite as nice a program as I thought. (It’s hard to imagine Jim Aikin being too optimistic, but you never know….) I’d rather use Pd to process the output of something like the Axis-49, because it’s embarrassing to try to coax Cycling ’74 into giving me a free license for Max. They’d probably be willing to do it, but I’d feel sleazy asking.

I’m looking at the Starr Labs Z-Board. It might be just what the doctor ordered. Or not. I’m a little nervous about spending $3,000 on a piece of hardware that I’ve never seen, when no one that I know has ever used it.

A keyboard with built-in software smarts, along the lines of the Buchla Thunder, would be super. I’ve always regretted that I didn’t buy a Thunder. These days, it’s far better to do the processing within the computer than to rely on the hardware instrument … but not if the processing introduces 100ms of latency.

Roger Linn has been working on something called the LinnStrument, but it may never go into production, because Amazon bought the company that makes the hardware finger sensor and then pulled the product off the market. Anyway, the LinnStrument interfaces directly with Max; it doesn’t output MIDI at all. And it senses pressure, not velocity, because it has no moving parts.

What would be ideal, I think, would be a tiered set of levers — four or five tiers. They could be somewhat shorter than the levers on a piano keyboard, but they should have the same key dip. I’m not sure what color scheme would be best, but it’s clear that the grouping of black keys in two’s and three’s (common in most alternate controllers) would have to go. Coloring is essential for visual grouping, but the scheme should avoid enforcing any particular bias in favor of one particular scale.

What I’m describing is, of course, the Janko keyboard. It was developed by Paul von Janko in the late 19th century. Many pianos have been built with Janko keyboards; you can see them in a few museums. Bluthner will even build a new one for you, reportedly, for a 7,000-euro surcharge. But I haven’t been able to find a currently manufactured MIDI Janko keyboard. A company in Japan was building one for a while, and may still be, but their website is only in Japanese, and the instrument is apparently some kind of home keyboard, not a MIDI controller.

The Theory of 31

The theory of harmony in 12-note equal temperament is pretty interesting, and not terribly complicated. (I’ve written a book about it, in fact — Chords & Harmony is available from Hal Leonard Publishing.) Being able to talk about how chords are built out of intervals is useful, because it lets us describe what we’re hearing.

So as I put together little musical sketches in 31-note equal temperament, I’m starting to think about the theory. You can check out a few of these sketches on my channel at SoundCloud, by the way.

In 31ET, there are four “black keys” between each “whole-step” pair of white keys, and two “black keys” each between E and F and between B and C. Constructing a physical keyboard would be difficult, and if we did it we wouldn’t want all of those keys to be black. We could color them purple, aqua, citrus, and salmon, I suppose. But for theoretical purposes, talking about “G purple” would be silly. We need to find a terminology.

I’m calling the smallest intervals chroma-steps. The distance from C to D or from D to E is five chroma-steps. The distance from E to F or B to C is three chroma-steps.

We might want to call the first note above C “C high.” This would be followed, in order, by “C sharp,” “D flat,” “D low,” and finally D. The note immediately above a white key is “high,” while the key immediately below a white key is “low.” The note two steps above a white key is that key plus “sharp,” while the note two steps below a white key is that key plus “flat.”

We could conveniently abbreviate these: C, C/, C#, Db, D\, D.

One oddity of this system of nomenclature is worth pointing out. C# is below Db — but E# is above Fb. E# is the same note as F\ (F low), while Fb is the same note as E/ (E high). This may seem obtuse, but it preserves the correct enharmonic spellings: If we’re in the key of C#, the major 3rd of a C# major chord will be E#, just as we’d expect. And the 3rd of a Db major triad (one chroma-step higher than C#) will be F natural, again just as we would expect.

I haven’t yet started thinking about the nomenclature for the many varieties of triads and seventh-chords, let alone suspensions and stacked voicings. Maybe the triad C-E\-G is a low major triad. But what about C-E\-G\? That’s even lower.

The names of the intervals are a thorny enough problem. We can preserve the old terminology of modes and say that there is no such thing as a major fourth or minor fourth, only perfect, augmented, and diminished fourths — but we have to add high fourths and low fourths to the list. But that’s potentially confusing. If the interval C-F/ is a high fourth, then so is the interval C\-F. Maybe we should say they’re big and small rather than high and low.

The reason to toy with these ideas is simple: I’m making the sounds already. If I have some terminology, it will be easier to think about what I’m doing. Translating the physical layout of a 12-note MIDI keyboard onto a 31-note scale is challenging enough. If I’m going to play a chord made of stacked intervals 12 chroma-steps wide (octaves, on the MIDI keyboard), it will be useful to say “these are narrow fourths.”

More About Tunings

Thanks to the improved workflow in QuteCsound, it’s getting easier to experiment with alternate tuning systems. Also, I’ve learned a couple of tricks for organizing Csound scores.

While enjoying the pure sounds of just intonation, I’ve been realizing that I don’t actually mind 12-tone equal temperament (12ET, for short). It has a beautifully developed harmonic language, which is not the case with any alternate tuning.

Also — and this is a subtle point — with equal temperament, you always know where you are. If you’re composing in just intonation, arbitrarily tiny micro-intervals can flit around like gnats, and every chord root will tend to grow a different forest of harmonic possibilities.

Csound has a very nice opcode (cpsxpch) for experimenting with equal temperaments. So last night I thought I’d play around  little with 31-tone ET. 19ET and 31ET are notable Read more