// Node Based Tool Design
I spent an evening this week back in Max/MSP, patching boxes together on a canvas, watching numbers and audio move from one to the next in something close to real time.
A look at node based tool design: what it actually is, where you’ve probably already met it, the patterns that keep showing up wherever someone builds one of these, and why the same shape might be the best way to work with AI itself.
Also: modular synths, Mark Fell on why he builds his own tools inside Max/MSP, and why a shader node in Blender is doing the same basic trick as a mixing desk.
Your own tools
One of my favourite musicians, Mark Fell, writes about this at length, in his PhD thesis and later in his book Structure and Synthesis. He puts it plainly: “Typically for example I build systems within MaxMSP that I then interact with to promote non-predetermined results.” Rather than start from scratch every time, he constructs the performance environment for a piece of music inside Max using a selection of reusable patches he’s built over time.
Edgard Varèse once said he dreamed of “instruments obedient to my thought.” Fell dreams of the opposite: tools “with specific functions and properties within which thought and practice are galvanized in response to wider social and cultural contexts.” In his words, the technology “does not so much function as a means of expressing the contents of one’s imagination, but a means of constructing one’s imagination.”
I agree with him. It’s why I keep coming back to Max/MSP even when there’s a faster way to get the same sound out of a plugin. The patch is slower. It’s also entirely mine, decision by decision, wire by wire.
The patch
Most software asks you to write instructions and run them in order. Line one, then line two, then line three. Node based programming replaces that with a graph. Each box does one small thing. Multiply this. Delay that. Read this file. Render this shape. You wire the output of one into the input of another and the graph runs continuously, reacting whenever new data lands at an input.
The proper name for this is dataflow programming. No top of the file. No line one. Just a network, and whatever order the data happens to arrive in.
The lineage
Max/MSP calls its documents “patches” because the metaphor is literally patch cables. Miller Puckette built the first version at IRCAM in the 1980s, for composers who wanted to route audio the way they’d route it on a modular synthesizer, except in software. That lineage still shows up across the whole space. Boxes standing in for modules. Cables standing in for patch cords. Signal running left to right, or top to bottom, depending who designed the canvas.
Where you’ve seen it
Max/MSP and its open source cousin Pure Data are the classic examples, both built for audio and interactive media. TouchDesigner does the same job for real time visuals, VJing, installations, anything that needs to react live. Move into 3D and VFX and you get Houdini’s procedural node networks, or the shader and geometry nodes built into Blender. Game engines have their own version too: Unreal’s Blueprints let you script gameplay logic without writing C++. Architects and product designers doing parametric work reach for Grasshopper, a node graph that sits inside Rhino. And the same idea has quietly taken over general purpose automation: Node-RED, n8n, Zapier’s newer flow view. Boxes and wires under the hood, whatever the landing page calls it.
The shape keeps repeating across industries that have almost nothing else in common.
Patterns
Once you’ve used a few of these tools the same handful of design decisions start turning up. A graph of boxes and wires runs into the same problems whoever builds it. Convergent evolution, mostly. Here are fourteen of them.
Canvas
Before any of the other patterns, there’s the canvas itself: an effectively infinite surface you pan and zoom around, empty until you put something on it. No fixed page size, no scroll bar in the usual sense, no top or bottom. Every one of these tools starts from the same premise, and it’s easy to treat that as inevitable until you compare it to a text editor’s fixed column or a spreadsheet’s grid. Give someone empty space first, and the patch grows into whatever shape the work actually needs.
Node
The box itself, the thing you’re actually looking at on the canvas: a name, an icon or colour indicating its type, and enough of its key parameters visible at a glance to tell you what it’s doing without opening anything. Houdini, Blueprints and TouchDesigner all call this a node, TouchDesigner drawing a careful distinction between the node (the box on the canvas, its flags, its position) and the operator (the underlying functional type it holds). Max calls the same thing an object box. Whatever the name, it’s the atomic unit everything else in this list is built to help you manage: colour it, group it, search for it, right click it, fold it up, inspect it live, snapshot it, bypass it.
Connector
Every node has a small socket on its edge, one for each input, one for each output. TouchDesigner calls it a connector. Blueprints calls it a pin. Max calls it an inlet or an outlet, depending on which side of the box it’s on. It’s the only part of the node you’re actually allowed to touch when you’re making a connection, a fixed point that’s always in the same place relative to the box, so your eye and your mouse both learn where to go without thinking about it.
Wire
The line itself, running from one connector to another. TouchDesigner calls it a wire. Max calls it a patch cord, in keeping with the whole modular synth metaphor the software is built on. Houdini and Blueprints mostly just say wire too, informally. It’s the one element on the canvas whose only job is showing that a relationship exists: this output feeds that input, full stop. Delete it and nothing about either node changes, only the connection between them does.
Colour coding
A wire in TouchDesigner is coloured by what’s flowing through it. Blue for numbers, green for textures, magenta for audio. Houdini and Blueprints each do their own version of the same thing. Once you’ve learned the code you can read a patch at a glance, before you’ve traced a single wire. Colour coded electrical cable, applied to a screen instead of a wall.
Grouping
Patches get messy fast. Fifty boxes and a hundred wires stops being a diagram and starts looking like a plate of spaghetti. Every one of these tools ends up growing some way to cluster a set of nodes together: a coloured frame with a title, something you can collapse or move as a single unit. It’s a small feature. It’s usually the thing that decides whether you can hand a patch to someone else, or open your own from six months ago and still understand it.
Comments
Grouping clusters nodes together. Comments explain them. Houdini, TouchDesigner, Blueprints and Max all let you drop a plain text box anywhere on the canvas, unattached to any node: what this section does, why a value is set the way it is, a reminder to fix something later. No functional purpose at all. Just a note to your future self, or to whoever opens the patch after you.
Object browser
Every one of these tools eventually grows a way to drop a new node without hunting through a menu. Houdini’s Tab menu. Unreal’s right click search box, the first thing any Blueprints tutorial teaches you to reach for. Max’s object browser. You start typing what you want and a list of matching nodes appears, arrow down, enter, done. No mouse required until the node’s already sitting on the canvas. Doesn’t sound like much until you’re forty nodes deep and reaching for a submenu every ten seconds.
Contextual menus
Right click a node and the options change depending on what it is. A math node offers different things to adjust than an audio node, which offers different things again to a geometry node. Max, Houdini, TouchDesigner and Blueprints all work this way: the same gesture, right click, but the menu that appears is specific to the object underneath the cursor, its parameters, its help file, its own particular set of adjustable things. Each node knows how to explain and adjust itself, rather than routing everything through one enormous settings panel for the whole application.
The subpatch
Once a patch gets big enough, every one of these tools lets you fold a cluster of nodes into one box and give it a name. Max calls it a subpatch, or a bpatcher if you want your own interface on the outside. Houdini calls it a digital asset. Pure Data calls it an abstraction. Whatever the name, the idea is the same: hide the wiring, expose a handful of inputs, and that fifty node mess becomes one box you can drop into any other patch like a plugin. It’s how a boxes and wires tool avoids collapsing under its own complexity as a project grows. The graph stays a graph. It just gets levels.
Live inspection
TouchDesigner shows the actual value ticking along a wire when you hover it. Houdini pops open a spreadsheet of the geometry sitting at any node without leaving the graph. Look at the wire mid patch and you can see exactly what’s flowing through it, without running anything separately. Turns debugging from a guess into a glance.
The minimap
Once a patch gets big you lose the edges of it, scrolling and zooming to find the node you’re after. Most of these tools grow some version of a minimap, a tiny thumbnail of the whole graph in the corner of the screen with your current viewport marked as a box you can drag around. Blender has one for its node editor. Unreal has one for Blueprints. Architecture diagrams solved this decades before any of this software existed: when the map gets too big for the window, draw a smaller map of the map.
The snapshot
Parameters drift as you work. You nudge a value to test something and forget to nudge it back. TouchDesigner and Ableton’s Max for Live both let you save a snapshot: the state of every parameter in the patch at a point in time, recallable with one click, morphable between two snapshots if you want a slow transition rather than a jump. The node based equivalent of a preset on a synthesizer, except the synthesizer might be an entire generative visual system with four hundred parameters buried three subpatches deep.
The bypass
Every node has an on switch you can flip without deleting the node. Houdini calls it a bypass flag. Blueprints lets you disable a node from the right click menu. Max has a toggle you can wire straight into a patch to mute part of the signal chain live. The point is the same everywhere: a way to ask what the patch does without that one step, without losing the step, rewiring around it, or breaking anything downstream that depends on it still being there. The undo button’s quieter cousin.
Fourteen patterns, four different industries, four different decades of software, and barely any contact between the teams who built them. A canvas of boxes and wires keeps needing the same handful of things: room with no edge to run out of, a box that shows what it is without opening it, a fixed point to plug into, a line with nothing to do but show the connection, a way to read the whole thing fast, a way to cluster it, a way to label it, a way to build it without reaching for a mouse, a way to reach into one node without opening a menu for the whole application, a way to fold it up, a way to see inside it live, a way to find your place in it, a way to try something without committing to it, and a way to switch a step off without losing it. Design a node based tool and you’ll rediscover most of this list whether you meant to or not.
Data driven systems
Music and VFX are the obvious home for all this, but the reason node based UI works has nothing to do with sound or pixels. It works because a data driven system is illegible by default. Information moves between modular components, one function calling another, one API calling another, and none of it is visible unless you go looking for it in a log file or a debugger.
A node graph makes that flow visible. You can see the shape of the system, not read about it in a diagram someone drew once and never updated. And because everything is wired rather than hardcoded, you can pull a cable out and put a different one in. Try a variation. See what breaks. Put it back. Legibility of the flow, and the ability to wire and rewire to experiment, in the same interface.
Product as graph
Digital products are heading the same way. Personalisation engines, feature flags, pricing rules, recommendation logic: increasingly a set of modular components wired together behind the screen, reacting to what a customer just did and to whatever the business currently wants to optimise for that week. The system changes shape more often than most roadmaps admit. A rule gets added. A flag flips. A new signal gets patched into the personalisation logic three sprints after launch, and half the team never finds out it’s there.
Spreadsheets and backlog tickets both start straining once a graph gets that tangled. Legible, wireable, live: the same qualities Max/MSP and Houdini spent forty years quietly perfecting for people improvising with sound and light. I think that shape is about to matter for a very different kind of improvising. Designing and configuring a product like this is going to need an interface built for graphs, not documents.
The AI patch
It’s already starting. ComfyUI treats a Stable Diffusion pipeline as a graph: load model, sample, upscale, save, each step its own node. n8n, already mentioned above as general automation plumbing, now ships nodes for chaining LLM calls the same way. Early days, and mostly aimed at generating images rather than building the AI powered software itself, but the shape is turning up before most people have made the argument for it.
The same argument applies to AI, maybe more urgently than anywhere else. Most of us are given a chat window and told to describe what we want in plain English, which is exactly the kind of black box interface this whole piece has been arguing against: no visibility into what’s actually happening between prompt and output, no way to isolate one step and inspect it, no way to reuse a working combination without copying a paragraph of instructions into a new conversation and hoping it still works the same way.
The better answer, I think, is Fell’s answer, applied one level up: use AI to build the tools you use to work with AI. Break the job into a graph. One node extracts the data. One transforms it. One calls a model with a specific, narrow, tested prompt. One validates the output before it’s allowed to reach the next node. Wire them together, watch the data move between them, swap one node without touching the rest.
It’s the same fourteen patterns from earlier in this piece, aimed at a new kind of component. Colour the wires by data type, so a hallucination prone text field is visibly flowing somewhere it shouldn’t. Bypass a step to test the pipeline without one particular model call. Fold a working combination into a subpatch and reuse it like a plugin instead of a paragraph you keep retyping. A node based system gives a data driven AI pipeline the same things it gives a modular synth patch: legibility, and room to keep experimenting with something that behaves unpredictably by nature.
I'd love to tell you more.
Previous Journal Post
// The Docs Are the Memory
Every new Claude session I started for a project had no memory of the last one. That’s the fact this whole setup is built around.
The system behind this website, a homelab, and a couple of other projects. Claude and an Obsidian vault, four notes per project instead of a chat log, and a folder connection that lets Claude read and write them directly.
Also: a document that went stale for a day, and a scheduled task that didn’t survive its first day.