One line, one soundtrack

The audio in my games does not come from a sound library. It comes from a pipeline that generates it on demand — instrumental tracks, menu loops, stingers, ambient beds — by driving a generation service, polling the render until it is ready, and pulling the finished audio down as MP3, WAV, or video. The point of building it as a pipeline rather than clicking through a web app is what the pipeline can plug into.

The generation-and-download core is deliberately isolated from the interfaces around it, so the same code backs three front doors. There is a Rich-formatted CLI for batch and scripted use, a small local web UI for browsing and listening, and — the one that matters — a callable engine that other tools invoke directly. A game build can ask for a victory sting in one line and get back a file path to drop into the project. The asset goes from 'does not exist' to 'in the build' without a human opening a browser.

It is honest about failure, which a pipeline feeding a build has to be. When generation does not complete, it passes the upstream message straight through instead of masking it behind a generic error, and Pydantic models keep the responses type-safe across the service's quirks. It is around four thousand lines of Python on httpx, Click, and FastAPI, single-operator and local, authenticating against an existing session that needs the occasional refresh — the one moving part.

The shape is the same one I keep coming back to: a pure core with the interfaces bolted on at the edge. Build the engine first, then give it as many front doors as the work wants. The CLI and the web UI are conveniences. The callable engine is the reason the games have a soundtrack without a sound designer in the loop.