Skip to content
RESONON

Sessions & Servers

When you live-code, the music is not in your editor. It is in a server: a resonon process that holds the session — every variable, track, instrument and pattern — and makes the sound. The editor is a client that sends it code. This page explains why it is built that way, and what follows.

The session outlives each evaluation

Section titled “The session outlives each evaluation”

Each evaluation runs against the same session, so what one evaluation defines is there for the next. That is what makes building a piece up line by line possible: you define a track once and then keep talking to it while the music plays.

Keeping the session in its own process also means the editor can come and go. Reload the window, reconnect, or connect from a terminal view: the music keeps playing, because nothing that plays it lived in the editor.

Most of the time you never see the server. The first evaluation in VSCode starts a local one if none is known, and the session starts empty.

Several clients, one session

Section titled “Several clients, one session”

A server has one session, and every client connected to it works in that session. A track one person defines is there for everyone else to send patterns to. There is one runtime and one transport, so two performers are playing the same piece, not two pieces at once.

That one model covers several ways of working: performers sharing a set, a teacher and a room working in one session, or one person with two windows — rehearsed code in one, experiments in the other. Display names and the output filter exist because, in a shared session, output needs an author.

A server is reachable from the network by default, which is what makes sharing possible without setup. A password, or binding to the loopback address, closes it.

A session runs one version of the language

Section titled “A session runs one version of the language”

A project pins the version of resonon it is written in, in its resonon.toml. The language server follows that pin per project, so two projects on different versions can be open side by side, each checked in its own language.

A live server can’t: it runs one version, the one pinned by the project it was started from. Code from a project that needs a newer version is refused rather than run in the wrong language. The server is never restarted to fit, because restarting would stop what is playing — the editor offers the restart, and it is yours to take. Code written for an older version runs, with a warning the first time.

Section titled “Related”