Jake Robert Read

Log Machine Systems Stray Projects About RSS

Clangers and Bangers

  • systems

Werner Herzog does Music Machines

We had a fun week trying to make this off-the-research-piste project at Haystack this July. This was part of Haystack Labs 2023, and I had the pleasure of working with Christopher Taylor, Quentin and Ivana Dama.

In the Jewelery Studio at Haystack

About Composable Systems

I’ve always wanted to build some kind of prototyping kit for music machines. I’m not a musician myself but it seems that the medium is highly composable - meaning it’s hard to make permutations of a musical system that are fundamentally broken.

That seems like a crazy statement if you’re just interested in music making. I’ve spent a long while trying to build machine controller systems; i.e. for 3D printers, laser cutters, cutting machines and their ilk. We want their assembly, repair and modification to be playful, fun … inviting for newcomers. This is work towards the end that more amongst us might end up engaged in machines’ making and maintenance, and that as a result more could engage with the material world in a less alienating manner, or be more likely to sieze the economic means to do automation, precision fabrication, etc (and all that would entail).

In any case, when we build machine systems, there are lots of ways to break them. Things can go wrong pretty quickly, basically: machine systems are not very composable - that’s the whole challenge. On the other hand, music is composable - we can throw new things in the mix, improvise, bang on pots and pans etc, and nothing goes dangerously wrong.

Scheming on protocols, and schemas of keymaps.

What We Built

So we brought a kit of circuits for whacking (with solenoids) and thrumming (with transducers), and a new bus protocol we had been working on. None of which were especially finished.

Our ad-hoc pots-and-pans banger fixture.

The above, as deployed.

The results are evident in the video at the head of this page (and below); not wonderful, but kind of funny. I wanted badly to make something that would bring Christopher some joy as he played it, but I’m not convinced we managed it.

Christopher Taylor, virtuosic pianist (and talented programmer), banging and clanging.

I think Christopher did have a blast programming though - he helped debug our protocol, and invented the keymapping system we used (to translate midi from our keyboard into various solenoid-strokes).

What We Learned

This was a fun little misadventure on my part - and I even learned a few valuable things;

The world of Musical Systems Assembly is rich, and full of ad-hoc solutions that work.

I’m often complaining that the CAD/CAM/Machining world suffers from a lack of field mechanic-ness - i.e. the property (often found on i.e. farms, on the ISS, or amongst other infrastructure maintainers) that tools and systems are built, modified and maintained by those who use them.

In particular, I think that mechatronic systems present a barrier to this kind of work because their complexity is often large and those who use them (largely physical-world dwellers) tend not to intermingle with those who develop them (largely mathematics-loving, abstract-space dwellers). I suspect that CNC remains clunkly largely because of this.

There’s a much larger discussion in there, but the gist here is that musicians are good at making composable systems and their tools, which are authored largely by their own community-members, are awesome. I’m thinking puredata, MaxMSP, open sound control.

I’m thinking also about MIDI (~ three bytes per event), and Control Voltage (~ one volt per octave) - really slick, simple, and easily grokk’d protocols. It’s like, UTF-8 level extensibility.

One of the reasons these are so wonderful is probably that you don’t need to pull anyone’s code to start using them: they’re easy enough to understand that you can build their guts from-scratch in whatever system you want in a few hours. That might be difficult for embedded systems in general, but it might be critical.

Construction Kits need to deploy in a “Batteries Included” state.

We didn’t show up to this party with everything finished, we should have. That means earlier testing, and more scaffolding:

  • circuit should not be fragile
  • we shouldn’t have to wait for any 3D prints to finish before we can do stuff
  • systems should not require explainers

We already know most of this.

Construction Kits need out-of-the-box Examples

This is basically the same point as above; we should have four or five fun things to do with the kit before we leave the lab. They should work right away, and they should make what-all is going on behind the systems clear to everyone involved.


So, good to learn in practice what we suspected to be true, and to have some motivation to do a little better next time, scaffolding wise.

Huge thanks to Haystack for hosting us!