Essays • • 13 min read

Why I Build Creative Technology: Music, Films, and Games From Pure Code

I make music, animated films, and games entirely from code. No GPU, no stock media, no samples. This is the cornerstone explaining why an engineer-philosopher builds ChipForge, Napkin Films, and Pixel Vault, and why the constraint is the whole point.

Why I Build Creative Technology: Music, Films, and Games From Pure Code

I make music with no recordings, films with no camera and no GPU, and games that fit in a single HTML file under 50KB. All of it comes out of code I wrote or directed. This page is the cornerstone for everything else on this site about creative technology: why I build it, what the three main projects actually are, and why the constraint I keep imposing on myself is not a limitation I tolerate but the design decision I'm most proud of.

The short version: I have spent fifteen years as a DevOps and platform engineer, and the same instinct that makes me want to understand a production system as a system, not as a pile of tools, makes me want to understand a song, a film, and a game as systems too. Not as outputs you buy or assets you license, but as things you can generate from first principles if you understand the principles deeply enough.

I describe myself as an engineer-philosopher exploring how humans live coherently inside increasingly complex technological systems. Creative technology is where that frame stops being abstract. It is one thing to argue that you should understand the systems you live inside. It is another to prove it by building a music engine, a film studio, and a game lab from nothing but mathematics and a text editor, and to ship the results.

The throughline: production from code, nothing borrowed

The three projects look unrelated from the outside. One makes audio, one makes video, one makes interactive games. Under the surface they are the same project run three times against three different media.

Each one starts from the same refusal. No samples. No stock footage. No GPU video models. No asset libraries. No recordings of real instruments, real voices recorded for purpose, or real footage shot with a camera. Every sound, every frame, every game mechanic is generated from code, sample by sample, pixel by pixel, rule by rule.

This is not nostalgia for doing things the hard way. It is a thesis. The thesis is that the interesting work in creative technology in 2026 is not in calling a media-generation API and accepting what falls out. The interesting work is in understanding the medium well enough to build the generator yourself, and then deciding, deliberately, what the generator is allowed to do. The constraint is where the design lives.

I'll take the three projects in the order I built them, because each one taught me something the next one needed.

ChipForge: a music engine made of mathematics

ChipForge is a music synthesis engine I built from scratch in Python and numpy. It started as a Game Boy audio chip emulator, a small exercise to reproduce the square waves and noise channels of a console I grew up with, and it kept growing until it became something much larger: a full synthesis engine with hundreds of instrument presets, nineteen synthesis types, twenty effects, vocal synthesis, and guitar amp simulation.

The rule it never broke is the one that matters. No samples. No recordings. No external audio libraries. Every sound is generated as a waveform, computed sample by sample, from the math up. A sine is a sine function. A plucked string is a Karplus-Strong physical model: you fill a buffer with noise and feed it back through a tuned delay, and the math decides what a string sounds like. An FM bell is a Yamaha DX7-style frequency modulation, two oscillators where one bends the other. A supersaw is a stack of detuned sawtooth waves doing the thing trance music has done for thirty years. None of it is a recording of an instrument. All of it is a description of how a sound behaves, expressed as numbers moving through time.

That distinction changes what the work is. When you sample an instrument, you capture a sound. When you synthesize it, you have to understand it. To make a convincing brass patch I had to learn what actually makes brass sound like brass: the per-harmonic envelopes, the way the upper partials bloom a fraction of a second after the fundamental. The engine forced me to learn the physics, because there was no shortcut available. There was no library to import. There was only the question of what the sound is, answered in code.

More than a hundred and forty songs have come out of ChipForge across EDM, soundtrack, rock, pop, and classical. They live on Bandcamp, and they exist because at some point an AI agent and I could sit at the API the engine exposes and compose, sequence, and export a finished track without ever recording a single sound. The agent writes a score. The engine renders it to a waveform. The waveform becomes a song. Nothing in that chain was borrowed from the physical world.

Why does this matter to anyone but me? Because it relocates the creative act. The creativity is not in choosing which sample pack to buy. It is in the decision space the engine opens: which synthesis type, which envelope, which effect chain, what the math should do next. When you build the generator, you own the entire decision space instead of renting a slice of it.

Napkin Films: animation directed by agents, rendered without a GPU

Napkin Films is the second run of the same idea, against video. It is a code-first animation studio where every film is a self-contained scene file, Python or HTML Canvas, that an AI agent can write, render, voice, score, and deliver in a single session. The tagline I keep coming back to is honest about the constraint: agent-directed animated short films, no GPU, no AI video generators, pure Python plus Canvas plus FFmpeg.

That constraint is doing a lot of work, and it is the opposite of what most of the industry is doing right now. The dominant move in 2026 is to prompt a video-generation model and accept whatever dreamlike, slightly-melting footage it produces. Napkin Films goes the other direction entirely. A stick figure walks into a scene and delivers something that moves you, and every frame of that stick figure was drawn by code I can read, on a machine with no graphics card doing any of the heavy lifting. The frames are deterministic. The same scene file renders the same film every time. There is no model hallucinating the in-between frames; there is a program deciding, explicitly, where every line goes.

The agents direct the performance, compose the score (using ChipForge, the first project feeding the second), and voice the characters. But the agents are directing a system whose rules are legible all the way down. A scene is one file. The audio is manifest-driven: the scene declares what needs to be spoken and when. Silent films are first-class, because audio is always optional. These are design principles, and they exist because I decided animation should be something you can write, fork, and understand, not something you summon and hope about.

Nearly forty of these films are published now, on the Organic Arts YouTube channel and catalogued here on the blog. Some are dedications. One, a piece called Ceramic, is a dedication to Alan Watts. The films are short, strange, and deliberately humble in their visual vocabulary, a stick figure, a few shapes, a Canvas scene, and that humility is the point. When you strip the medium down to what code can honestly produce on a laptop, the emotional weight has to come from the writing, the timing, and the score. There is nowhere for spectacle to hide the lack of an idea.

This is where the engineer-philosopher frame earns its keep. A film made from a GPU model is a film you cannot fully account for; you do not know why frame 400 looks the way it does. A film made from a deterministic Python scene is a film you can account for completely. For someone whose whole professional life is about understanding systems rather than trusting opaque ones, that difference is not aesthetic. It is closer to a moral preference.

Pixel Vault: four hundred and sixty games, each one a single file

Pixel Vault is the third run, against interactivity. It is a rapid-prototyping lab for discovering game mechanics: hundreds of single-HTML-file experiments, each one organized by genre lineage and catalogued so that patterns can be discovered across the whole collection. The constraint here is the sharpest of the three. Every prototype is one HTML file, under 50KB, zero dependencies, playable in five seconds.

That constraint is not arbitrary. It is what makes the experiment possible. A game you can read in one file is a game you can reason about completely. A game under 50KB cannot hide behind an asset budget; the entire thing has to be the mechanic. Zero dependencies means there is no framework deciding anything for you; the rules of the game are the only rules in the file. Playable in five seconds means the idea has to announce itself immediately or it has failed. When every prototype obeys those four limits, you can run hundreds of them and compare them honestly, because they are all built the same way and they are all small enough to hold in your head.

The collection spans classic genre reconstructions, going back to games as old as the ones played around 2600 BCE, alongside two stranger tracks. One asks "what if AI had participated in designing this genre" and overlays a concept. The other lets AI be the sole designer, evolving mechanics from first principles with no human archetype to copy. The stated intent of the whole project is unreasonable on purpose: to find something the world has never seen or experienced. Not just something novel, but a core interaction that does not have a name yet. A human and an AI searching together for something neither could find alone.

That is the most direct statement of why I build creative technology that I have. The constraint, one tiny readable file, is not there to make the games small. It is there to make the search legible. You cannot find a genuinely new interaction if every prototype is a thousand files of framework code obscuring the one decision that matters. You can find it if every prototype is fifty kilobytes of pure mechanic, and you have four hundred and sixty of them to compare.

The constraint is the design, not the limitation

By now the pattern should be visible. The three projects are the same instinct applied to sound, image, and play:

  • No samples in ChipForge means you must understand the sound.
  • No GPU, no video models in Napkin Films means you must account for every frame.
  • One file, under 50KB, zero dependencies in Pixel Vault means the mechanic has nowhere to hide.

Each constraint removes the easy escape hatch, and what is left is the actual creative decision. This is the same lesson that fifteen years of platform engineering taught me, written about elsewhere in DevOps Beyond Automation: the value is not in the tools, it is in understanding the system the tools operate on. A creative technologist who only knows how to call a media API is in the same position as a platform engineer who only knows how to configure a dashboard. The moment the API gets better or cheaper, the skill evaporates. The understanding does not.

There is a second reason the constraint matters, and it is the part the AI conversation usually gets wrong. I work in agent mode constantly; AI agents direct films, compose scores, and design games across all three projects. I have written at length about how AI is changing software engineering and about how to keep engineering discipline when agents do the typing in AgentSpek. The thing I keep relearning is that agents are extraordinary at filling a space and terrible at deciding what the space should be. A media-generation model will give you infinite content and zero design. The constraint is how I supply the design. By deciding in advance that the music must be synthesized, the film must be deterministic, and the game must fit in one small file, I hand the agent a sharply bounded problem and keep the actual creative authorship for myself. The constraint is the part that is mine.

What this has to do with living coherently inside complex systems

I said at the top that I'm an engineer-philosopher interested in how humans live coherently inside increasingly complex technological systems. Creative technology is the proof, not the decoration.

We are entering a period where most media will be summoned rather than made. You will describe a song and receive a song, describe a video and receive a video, and never once know how any of it was produced, because the production happened inside a model nobody can inspect. That is a coherent way to live only if you are willing to be a consumer of systems you do not understand. I am not, and I do not think it is good for people to be.

So the projects are a small, stubborn argument in the other direction. You can understand the medium. You can build the generator. You can decide what it is allowed to do. The music can come from mathematics you can read. The film can come from code you can account for frame by frame. The game can be small enough to hold whole in your mind. None of this is about rejecting AI; the agents are deeply involved in all three. It is about keeping the human at the level of the system, directing it with understanding, rather than at the level of the prompt, hoping at the output.

That is why I build creative technology. Not to make the most music, the most films, or the most games, though the counts climb. I build it to keep proving, to myself first, that a person can still understand the systems they create, even as the systems get more capable, and that understanding them is what makes the work yours.

Continue reading

creative-coding chipforge napkin-films pixelvault generative-art constraint-driven-design engineer-philosopher cornerstone