Troubleshooting

Troubleshooting

Hand-written, so it can fall behind. The device's face and the app's status lines change with the build; this page only changes when someone remembers. Where Live disagrees with what is written here, Live is right.

The status pill

The status strip along the bottom shows the first thing the app is waiting for, rather than making you combine two separate states.

	means	do
waiting for device	the app can't reach the device	check the device is still on a track in Live and the status line reads connected to Live
waiting for lom	the server is up, but Live isn't answering	give it a moment after loading the device; if it stays, see below
ready	the device and Live are both answering	nothing — the app is ready to work

The app retries the connection about once a second, so a device that comes back is picked up without reloading the page.

The device's face, in Live

Status says	it means
Starting…	the patcher loaded, Node hasn't booted
Waiting for Live	listening, but the handshake with Live hasn't completed
Connected to Live	working — normal, whether or not an app is attached

Stuck on either of the first two? Options ▸ Max ▸ Open Max Window. Every error and every timing line lands there. That's the first place to look for anything the app can't tell you.

Under Status, a row for each app that has connected — set[flow], visual[flow], chart[flow], master[flow] — in the order each first connected, with a dot that lights while that app is connected. A closed app's row dims rather than disappearing. An app that has no row, or whose row stays dim, after you've opened it never reached the device — that isn't the device being broken. And plus 1 more under the rows means something you may not know about is attached: an app past the fourth row, or a browser left on another desktop that is still connected, and still writing.

Common causes:

• Two copies of the device. Only one can run — they'd fight over port 17800. A second instance posts a warning rather than crashing, but nothing will connect to it.
• The three files got separated. SessionBridge.amxd loads bridge.js and lom.js from beside itself. If you moved only the .amxd, it will never get past Starting….
• The device was loaded before Live finished opening the set. Delete it from the track and drag it back on.

The log

The bug icon in the bottom status strip toggles it. It starts closed and opens itself when a new failure arrives.

Every write in this app reports there rather than throwing, so if a rename or recolor didn't take, the log is where it says why. Log text is selectable — an error message you can't copy is one you retype by hand.

Nothing appears in the grid

The empty state says Load the device in Live, then hit ⟳ in the header. If the set is loaded and you still see it:

• Check the status pill. It names the dependency the app is still waiting for.
• Press the sync icon to re-walk the set by hand.

The set normally loads by itself the moment Live reports ready. That happens once per session by design: a walk that fails leaves nothing loaded, and retrying automatically would hammer Live with the walk that just broke. So after a failed load, the sync button is the retry.

Swatches are missing

Live's 70 colors are compiled into the app, so there's nothing to derive and nothing cached — if the swatches are gone, the app was built without the table and the rail says so. Reinstall the device from Releases.

The grid disagrees with Live

The app follows what you do in Live by watching where Live's Session cursor goes — and, because you have to select a clip to edit it, by watching the clip it's sitting on. So moving a clip, and renaming, recoloring or deleting one where it stands, all reach the grid on their own.

All of that runs in the device rather than in the browser, so it keeps happening whether or not you have the page open — close every window and the device still knows your set, which is also how the Push encoder stays right with no browser at all.

On top of that it re-reads the whole set now and then, but only when what it holds has actually gone stale rather than every time you switch windows. A full read costs Live about a second of its attention, and spending one on every alt-tab to be told nothing changed isn't a trade worth making.

Two things still won't show up until it does look: a clip's length changed in Live, and a group folded or unfolded there. Live offers no way to be notified about either, so there's nothing to watch. sync is how you ask rather than waiting.

a clip appears in two places at once	the follow-along got it wrong. Press sync. Worth reporting — this shouldn't happen
a clip's length looks wrong	press sync. Live never says when a length changes
a group is folded here but not in Live	press sync. Same reason
the grid is stale after a lot of work in Live	press sync. It re-walks everything

A write no longer re-reads the set. That's what makes tagging and coloring feel instant, and the trade is that a write used to quietly catch up on your Live-side changes as a side effect. It doesn't now — sync is how you ask.

A song looks wrong

Most of these are the grid reporting something rather than failing:

mixed color on a header	some scenes of the song are colored and some aren't — see Color
values in amber	the song's scenes disagree about a fact. Both are shown rather than one being picked
part 2 of 2	the song appears in more than one run. A reprise, or two songs sharing a name
a song is missing entirely	its scene names don't match the convention — check Naming. Unmapped scenes are counted along the bottom edge
the bpm shows --- but the scenes have tempos	no scene name states a bpm, and neither does the song's first scene. A tempo further into the song is a change partway through rather than a fact about it, so it isn't shown. Type the bpm and Rename
firing a scene mid-song snaps the whole set's tempo	that scene carries its own Scene.tempo. Only a song's first scene should — select the song and press Apply tempo to song start, which clears the strays. The songs list flags songs that still have them
a song tag shows in amber	its scenes carry different tags. A tag describes the song, so they're meant to match

A rename or recolor did nothing

Check the count on the button before pressing it. Writes that would change nothing are filtered out, so recoloring a scene where every clip is already that color really does write zero — the count is honest rather than inflated.

If the count was non-zero and nothing happened, the log will have the error.

Undo didn't fully work

Two known cases, both by design:

• A scene that had no color can't be given none back. Live has no writable "no color". The log says how many scenes that affected.
• Reordering scenes has no undo at all. See Undo and The running order. Save before you reorder.

It's slow on a big set

Only the first load should cost anything. The device reads your set once, when it loads, and keeps track of it from then on — so opening the page, refreshing it, or opening a second window is instant however big the set is. If a refresh makes you wait through a full read every time, that's a bug worth reporting rather than something to live with.

The one thing that deliberately does read the whole set again is sync, because that button means "go and look".

Live stays usable while it reads. The read is broken into small pieces with a pause between each one, so Live keeps drawing and the progress bar actually moves instead of sitting still until the whole thing is done. It used to run in one go, which is why a big set used to lock Live up for the length of it.

That costs a little wall-clock — handing time back to Live means the read finishes later than it would if it hogged everything — and it's a trade worth making on any set big enough to notice.

One consequence: if you restructure the set while it's reading — add or delete a track or a scene — the read starts over. Half a read of the old set and half of the new one would describe a set that never existed, so it goes back to the beginning rather than showing you something wrong. It'll try three times before giving up and asking you to try again once Live has settled.

Every snapshot prints a phase breakdown to the browser console (⌥⌘I on macOS), plus a projection to a full-size set:

⏱ snapshot  243 clips · 100 scenes · 1041ms end-to-end
  lom: tracks / scenes / slot scan / clip reads
  lom: yielded     given back to Live between chunks
  v8 → dict        JSON.stringify + Dict.parse
  node getDict     Max dict → JS object
  wire + parse     payload size
  react commit
projection to 848 scenes (×8.5, linear): ~8.8s end-to-end

lom: yielded is the time the read spent deliberately not running, so Live could get on with drawing. It counts toward what you waited but not toward what the read cost — if the header ever says the walk restarted, that's the case above.

The counts along the bottom also show LOM walk and Slot scan times. Every phase is a linear scan, so the projection is honest.

If it's the grid rather than the walk, try the Narrow column width — fewer visible columns is less to render.

My interface has many outputs but only 1/2 is offered

Settings shows one stereo pair, and Cue output is stuck on None, even though the interface has eight or sixteen outputs.

This is macOS and the browser engine underneath the app, not the interface. Since mid-2026 the engine asks macOS for the device's preferred channel layout rather than its real channel count. Most interfaces publish a stereo layout — perfectly sensible for a pair of monitors, useless for a mixer whose outputs are separate destinations — and the engine takes it at its word.

The fix is an Aggregate Device, which does not publish a layout, so the real channel count is used:

1. Open Audio MIDI Setup (Applications → Utilities).
2. Press + at the bottom left and choose Create Aggregate Device.
3. Tick your interface in the list. Nothing else.
4. Give it a name you will recognise, such as Model 16 (all outputs).
5. In mix[flow], open Settings → Audio, choose that aggregate as the Output interface, and press Apply & restart audio.

Mix output and Cue output should now offer every pair the interface has. Set the mix to the pair feeding the room and the cue to the pair feeding your headphones — they cannot be the same pair.

The aggregate changes nothing about the interface itself, and other apps are unaffected.

Configuring a multichannel layout in Configure Speakers also works, but it describes your outputs as a surround speaker array, which is wrong for a mixer and caps out at eight channels.

Getting help

Bug reports go to Issues. Worth including:

• your Live version and OS
• what the device's Status said
• anything in the Max window (Options ▸ Max ▸ Open Max Window)
• the app's log, which you can select and copy