Skip to content
RESONON

Server & Collaboration

Every live Resonon session runs on a server — the actual runtime that holds your tracks, instruments, and patterns and makes the sound. Your editor is just a client talking to it. Most of the time the server is invisible: pressing Cmd+Enter in VSCode spins one up for you. But once you make it explicit, the same model gives you collaboration — several people, several windows, one shared session.

Running a Server

Section titled “Running a Server”

Start one from a terminal:

Terminal window
resonon server
[server] Listening on 0.0.0.0:5555

By default it binds to 0.0.0.0:5555, so it’s reachable from other machines on your network. Bind to 127.0.0.1 to keep it local, or pass a name so it’s easy to spot when discovered:

Terminal window
resonon server --server-host 127.0.0.1          # this machine only
resonon server --server-name "studio"           # a friendly name
resonon server --midi-port "IAC Driver Bus 1"    # wire up MIDI on startup

The full set of flags lives in the CLI Reference.

Finding Servers

Section titled “Finding Servers”

A running server announces itself over the local network with a UDP broadcast, so clients on the same network can find it without you typing an address. In VSCode these show up in the sidebar’s Servers view labelled Discovered.

If discovery can’t reach a server — a different subnet, a firewall blocking UDP — add it by hand. In the editor that’s Add Server… (host and port); from the command line you point a client straight at it:

Terminal window
resonon view mixer --host 10.0.0.5 --port 5555

Sharing a Session

Section titled “Sharing a Session”

Several clients can connect to the same server at once, and they all share one session. A track or variable defined by one person is immediately visible to everyone — there’s a single runtime, and every client is talking to it:

// Anyone connected can keep talking to this track —
// they don't redefine it, they send it new patterns.
drums << [bd _ sd _, hh*8];

That shared state is what makes Resonon collaborative. Two people can build different parts of the same piece, an instructor and a room of students can work in one session, or you can simply connect from a second window to keep your performance code and your experiments apart.

Display Names

Section titled “Display Names”

Each client picks a display name, shown in the status bar and alongside output so you can tell who ran what. Set it with the resonon.client.name setting or the Set Display Name command; if you don’t, your system username is used.

Output Filtering

Section titled “Output Filtering”

With several people evaluating into one session, the output panel gets busy. Use Toggle Output Filter (Own / All) to switch between just your own evaluations and everyone’s.

Password-Protected Servers

Section titled “Password-Protected Servers”

For a session you don’t want open to the whole network, require a password:

Terminal window
resonon server --password "hunter2"

Clients then supply it when they connect (the --password flag on resonon view, or the prompt in the editor). You can also set it out-of-band with the RESONON_SERVER_PASSWORD environment variable, which resonon server falls back to when --password is omitted.

Where to Use It

Section titled “Where to Use It”
  • Collaborative performance — several performers, one evolving session.
  • Teaching — everyone watches and edits the same runtime.
  • Multi-window — connect twice to keep rehearsed code and live experiments separate, both driving the same sound.

Next Steps

Section titled “Next Steps”

You can run a session others join. Next, see when live coding isn’t the right tool at all — and you’d rather render a finished file.