Kuro Kasetto Artist Profile: How to Build a Generative Composition Rig Around a Norns Shield

There is a click in this kind of recording that is not a drum machine. It is a solenoid — a spring-loaded metal plunger the size of a AA battery — hitting something thin and resonant, a tin lid or a bike spoke or the back of a cigar box, and it arrives a hair late. Not the same hair every time. The coil warms up, the spring loses a little authority, and the machine drifts away from the grid it was told to follow.

I went back to my own bench because of a Kuro Kasetto artist profile that came around sideways, the way the good ones do: photographs of mechanisms small enough to sit on a paperback, a Norns Shield in the signal chain, an Arduino doing the unglamorous work of turning note-on messages into voltage. I have built versions of this rig three times and thrown two of them away. This is what I got wrong, what the recordings themselves seem to be telling us, and the exact procedure I run now.

What a Norns Shield actually is

A Norns Shield is a small open-source sound computer you assemble yourself: a Raspberry Pi with a screen, three keys, three encoders, stereo audio in and out, and a Lua scripting environment on top. You load community-written scripts onto it and each one turns the same box into a different instrument — a generative sequencer, a granular looper, a delay that never repeats itself the same way twice. It matters for this kind of work because it does two things at once: it makes decisions on its own, and it speaks MIDI out over USB to whatever else you have built.

That second part is the whole trick. The Shield is the algorithmic half. The solenoid, the motor, the pencil taped to a music box — that is the half that fails in interesting ways. Neither is worth much alone. A generative script with no body to hit sounds like software. A solenoid with no composer behind it sounds like a fax machine.

What most people do

Most people — me included, for about eight months — install thirty scripts and audition all of them.

This is the hardware version of prompt-roulette. You spend an evening spinning encoder three through a script's parameters, hear something promising at minute two, keep spinning, and lose it. Every script has its own idea of what a parameter means, so you never build muscle memory in any of them. At the end you have forty recordings of Awake, all four minutes long, all fine, none finished.

The second common move is to quantize the mechanism. You get the solenoid firing, notice the strikes land unevenly against the norns audio, and reach for the fix: tighten the clock, remove the swing, add a fixed offset to compensate for actuator latency. The result is technically correct and sounds like a stapler. Solenoid latency is not a constant you can dial out — it changes with drive voltage, with duty cycle, with how long the coil has been working. Compensating for its average makes the fast passages early and the sparse passages late.

The third is capturing everything as a direct signal. The Shield's line out is clean and convenient, so you record that, and separately you resign yourself to the mechanism being "too quiet to mic properly." What you have then is a clean synth recording with a faint tapping in the room. The tapping was the piece.

What the evidence suggests

There are no controlled studies here, so I will say plainly what I am working from: a couple of hundred hours of this material, my own multitrack sessions, and the recordings from this scene that people actually keep replaying. Three patterns hold up.

The object is the arrangement, not the script. Swap the script and keep the tin lid and the piece still sounds like itself. Swap the lid for a ceramic tile and it becomes a different composition, even with the identical Lua running the identical seed. The generative layer supplies event density and pitch relationships; the physical object supplies timbre, decay, and the thing the ear actually latches onto.

The variance that reads as "alive" is mostly in the strike, not the schedule. When I have nudged solenoid hits back onto the grid in a DAW after the fact — same audio, corrected timing — the recordings stay charming far more often than my theory predicted. What survives is that no two strikes have the same attack: velocity varies with coil temperature, the plunger contacts at a slightly different point, the object rings from a slightly different place. Timing drift is the part everyone talks about. Timbral drift may be doing more of the work. I hold this one loosely.

Long capture beats good capture. These systems are interesting on the tail. The first three minutes are the script demonstrating its rules. The interesting minute is somewhere around eighteen, when the mechanism has warmed up and the algorithm has wandered into a corner of its own state space that you would never have programmed.

What I actually do

Nine steps. Set aside an evening for the first pass and a second evening for editing, because doing both at once is how you end up keeping the wrong ninety seconds.

1. Pick one script and stay with it for a week. Load it through maiden, the browser-based editor and package manager the Shield exposes on your network. When it worked: the script's name appears in the SELECT menu and you can name three of its parameters from memory by day three.
2. Set your clock source before anything else. In PARAMETERS > CLOCK, choose internal, MIDI, or Link depending on whether the Shield or your DAW is in charge. When it worked: the tempo readout stays put and does not jitter when you start playback elsewhere.
3. Route MIDI out to the mechanism. Most generative scripts expose a MIDI device and channel parameter; your Arduino (or whatever drives the solenoid) sits on the other end of that USB cable, listening for note-on. When it worked: the plunger ticks in time with the notes on screen, with a small consistent lag you are going to leave alone.
4. Give the mechanism room to fail. Do not compensate for latency. If anything, add a small random offset per hit — a few milliseconds, unquantized. Illustrative Lua, inside a script's note-firing coroutine:

clock.run(function()
  clock.sleep(math.random() * 0.012)  -- 0-12 ms of nothing in particular
  midi_out:note_on(note, 100, 1)
end)

When it worked: repeated eighth notes stop sounding stapled together and start sounding hand-played. 5. Mic the object, not the coil. Small-diaphragm condenser six to ten inches away, aimed at the resonant body rather than the point of impact, slightly off-axis. When it worked: solo the mic and you hear a bell with a click in it, not a click with a bell behind it. 6. Record long, on two paths at once. The Shield's TAPE page in the system menu writes stereo WAV to the device at its native 48 kHz; run your mics into a DAW at 48 kHz / 24-bit so everything lands at one rate. Twenty minutes minimum. When it worked: you have two files and you are bored by minute six, which is the correct feeling. 7. Sync the two paths with one loud hit. Fire a single hard strike at the top of the take, then line the transients up in the DAW afterward. When it worked: the waveforms snap into alignment and the mechanism stops sounding doubled. 8. Edit by subtraction. Listen once, mark the passage you rewind to, delete the rest without ceremony. When it worked: you are left with sixty to ninety seconds you did not design. 9. Bounce stems, not a mix. Mechanism, algorithm, room — three 48 kHz / 24-bit WAVs, named for what they are. When it worked: six months later a video editor can pull the room track down 4 dB under dialogue without asking you for a rerender.

That stem discipline is also why this workflow travels well into paid work. Audio you recorded off hardware you own has a clean provenance story that model output often does not — generator terms vary by platform and by plan, and they change. When a deadline eats the evening and you need a bed under the mechanical layer rather than a whole composition, an AI generator (ours or someone else's) is a reasonable tool for the bed; the strikes stay yours either way.

The question I can't settle

Here is where I run out of confidence. Every time I have separated the two variables — corrected the timing but kept the strikes, or kept the timing but normalized the strikes — the recordings that still moved me were the ones with intact strikes. That points at timbre. But I have never run it properly blind, and I have obvious motivated reasoning, because I like the idea that my machine's unreliability is expressive rather than only ugly.

So: when a solenoid makes us feel something a sequencer cannot, are we hearing when it hits, or how it hits — and would either of us pass a blind test on the difference?