How Songcode fits together
A map of the parts. The instructions a model reads, the code it writes, the Songcode Audio Engine that plays it, and the ways in for assistants and other programs.
Songcode has four parts: a set of instructions, a language, an engine (the Songcode Audio Engine), and a server that passes text between them. This post is the map, and the longer posts about each part are linked where they come up.
One track, start to finish
You type a prompt in your browser. Our server puts our instructions in front of it and sends both to a language model. The model answers with code, and you watch the code arrive as it is written.
Your browser does the rest. It checks the code, and if the check finds a problem the track goes back to the model once to be fixed. Then the engine plays it. From prompt to sound follows the same trip one step at a time.
The instructions
A language model knows nothing about Songcode until it is told. Every request opens with the same document. It teaches the language, lists every sound the model may name, and sets out rules for mixing and groove. After that come a brief for the genre you picked and instructions for the length, then your settings, then your prompt.
Your prompt is a line or two at the end of several thousand words of ours. We trained no model to make this work, and We trained nothing sets out that claim and where it stops.
The code
The model’s answer is a track written in ode, a language we designed for songs. It names the stems, says what each one plays and where, and ends with a mix table. Anything that writes ode is an odist, and Songcode is the greatest of them, since it wrote the language.
The code is the track, and Songcode keeps it in no other form, so everything that changes a track changes its text. Drag a fader in the stems view and a number in the mix table changes. Draw a note in the note grid and it is written into that stem.
Everything that uses a track reads that text too: the engine, the exports, a shared link and the API. The files Songcode writes lists what you can take away.
The Songcode Audio Engine
The Songcode Audio Engine makes the sound, and it runs in your browser. It reads the code into the notes each stem plays, gives every stem its own channel with its own level and pan, and mixes the channels into one output. The sounds are synths, drum machines and sampled instruments.
Our server never handles audio. No recording of a track exists until you export one, and your browser renders the export as well.
Three ways in
The app is one way in. The Songcode API is a second, for your own code, and the Songcode MCP server is a third, for AI assistants. All three reach the same account and the same songs, and a track written through any of them gets the same instructions and the same check.
The API and the MCP server return no audio, because the server has none to give. Your code gets a track as code or MIDI, with a link that plays it. In an assistant that shows app widgets, the songcode player sits under the answer and plays the track in the conversation, using the same engine in your browser. The same player is on songco.de/mcp, where you can press play. A published track also has a small player that any site can embed.
Songcode does the writing through these two as well, on its own side: the assistant or your code asks, and Songcode writes the track. Without a plan it writes with your own model key, saved on the settings page or sent with an API call; on a plan it spends the plan’s weekly usage. The developer docs list every call.
Where each part runs
| part | where it runs | what it handles |
|---|---|---|
| the instructions | our server | text |
| the model | a model provider | text |
| the check | your browser in the app, our server for the API and the MCP server | text |
| the Songcode Audio Engine | your browser | sound |
| the songcode player | your browser, inside an assistant’s conversation | sound |