What Does Live Coding Really Mean? Expanding Definitions Beyond the Screen
Week 1 reflection from “Decoding Tendencies in Live Coding: Exploring Notational Systems and Algorithmic Performance” at SFPC
I’m currently taking a 10-week class at the School for Poetic Computation that’s already challenging my assumptions about what live coding is and can be. The course is called “Decoding Tendencies in Live Coding: Exploring Notational Systems and Algorithmic Performance,” and after just the first reading—the introduction to Live Coding: A User Manual—I’m rethinking everything.
Where I Started
Before this class, my definition of live coding was pretty straightforward. I’d internalized something close to TOPLAP’s definition:
“Live coding (sometimes referred to as ‘on-the-fly programming’, ‘just in time programming’ and ‘conversational programming’) is a performing arts form and a creativity technique centered upon the writing of source code and the use of interactive programming in an improvised way.”
In practice, this meant tools like Hydra or Strudel—environments where you’re literally typing code in real-time to generate visuals or sound. I’ve taken workshops in both, and that text-based, improvisational approach felt like the core of what live coding was.
TouchDesigner, my main tool for generative work, occupied a strange middle ground in my mind. It’s node-based rather than text-based, so it felt like a cousin to live coding rather than the real thing. Sure, you can write Python or GLSL within TouchDesigner, and yes, you’re building systems and essentially creating your own visual language—but it’s a different way of thinking. The visual programming
paradigm shifts how you approach improvisation and real-time creation.
I even found myself recently feeling that live coding in TouchDesigner wasn’t “live” enough, which led me to build a Hydra-to-TouchDesigner interface. I wanted to code Hydra syntax within TD while still accessing all of TouchDesigner’s capabilities—a hybrid approach that felt more authentically “live” to me at the time.
The Line That Changed Everything
Then I hit this passage in the introduction:
“Live coding is about people interacting with the world, and each other, in real time, via code. Live coding is about making software live.”
Suddenly, the definition cracked wide open.
If live coding is fundamentally about real-time interaction with the world through code, then what about all the work I’ve been doing recently? I’ve been using TouchDesigner as a generative source for physical fabrication—pen plotting, Risograph printing, cyanotypes, and laser engraving. Each of these processes involves making decisions in the moment, responding to the output, adjusting parameters, capturing specific states of algorithmic systems.
By this broader definition, aren’t these live coding practices too?
Making Software Live vs. Making Software Live
What struck me most was the phrase “making software live” and how it contains a productive ambiguity. There’s making software perform live—the traditional understanding. But there’s also making software live on—preserving ephemeral computational moments as physical objects.
When I’m pen plotting a frame from a particle system, I’m capturing a fleeting state that will never exist again in quite that configuration. The live code generates the moment; the fabrication process makes it tangible, permanent, shareable beyond the screen.
This feels like a form of live coding that extends into physical space and persists in time. The interaction happens in real-time during creation—adjusting the generative system, choosing the moment to capture, sometimes even making decisions during the plotting or printing process itself. And when others encounter the finished work, they’re engaging with a frozen moment of a live system, a conversation stopped mid-sentence.
Questions Moving Forward
This reframing opens up new territories to explore:
If fabrication processes can be live coding, what makes something not live coding? Where are the boundaries?
How does the audience relationship change when the “live” moment is captured rather than witnessed in real-time?
What does notation mean in systems that bridge code and physical fabrication?
Can we think of the artifacts—the prints, the plots, the engravings—as scores or notations themselves?
I’m only one week into this class, and already my conception of my own practice is shifting. Maybe all along I’ve been live coding in ways I didn’t recognize. Maybe the definition was always more expansive than I realized.
More reflections to come as the course progresses.
This is part of an ongoing series documenting my journey through the SFPC course “Decoding Tendencies in Live Coding.” These reflections will eventually be compiled into zine form maybe?