The running order

The running order

This is the only thing in the app that can destroy work, and the only write with no undo on our side. Read Undo before using it in anger.

Three ways to reorder, for three different jobs — and a fourth, New show, that sets the order and deletes every song you didn't name.

Dragging one song in the grid

Drag a song header to move that whole run of scenes. An amber line shows where it lands, and the line carries the cost:

10 scenes · 84 clips copied · 10 deleted

That cost is on the drop line rather than in the log on purpose. There's no undo for this, so what's about to happen has to be readable while the mouse button is still down. A log line afterwards is too late to be a decision.

• A drag moves one run, not one song. A song can appear in several runs, each with its own header — dragging the one marked 2/2 moves the part you grabbed. Gathering both runs is something you can do by dragging one next to the other, but it won't happen as a side effect of grabbing one header.
• Dropping a song back where it already is does nothing at all. That's how most drags end, and the cheapest way to never delete a scene by accident is to not run.
• The drop clears your selection and your undo entry. Every scene index just came to mean a different row.

Fold the songs first with the hamburger in the first button group after the logo. It shares that app-only display group with the song-index toggle. A folded song is draggable, which is the whole point of folding — a hundred-song set becomes a table of contents you can reorder.

Dragging one scene

Drag a scene by its number to move that single scene. Same amber line, same rules, same lack of undo — a scene is a run of one, and it goes through exactly the machinery above.

The number is the grip rather than the whole row, because the row already means select and ⇧ already means extend; making the row draggable would have one gesture stealing from another. Clicking the number still selects the row — a drag and a click are different gestures.

If the scene you grab is part of a selection, the whole selection moves — including scenes that aren't next to each other. Grab a scene outside the selection and only that one travels.

Setting the whole order at once

The running-order icon at the right of Songs opens the running order. Build a sort hierarchy, drag songs into the order you want, or both — then Apply.

One row per song, however many runs it has, because a running order is written in songs. The draft is free — push it around as much as you like, nothing is written until you press Apply.

Sorting

+ level adds a sort rule. Each rule picks a field — Name, Tag, Key or BPM — and a direction, and the levels apply in order:

sort by   Tag  ↑
then by   Key  ↑
then by   BPM  ↓

Each level only breaks ties left by the one above it. That reads as: gather the covers together, order them by key so the set mixes, and inside one key put the faster songs first. It's the same rule a spreadsheet's multi-level sort follows, and it's why the order of the levels matters more than the fields in them. ↑/↓ on a level moves it up or down the hierarchy; × removes it.

Each field can be used once. Four levels is the whole set of them.

Three behaviours worth knowing:

• Songs missing that fact go to the end, in both directions. Reversing a sort changes the values, not whether the songs nobody has keyed yet interrupt every useful group.
• Songs still tied after the last level keep the order the set has them in. A partial hierarchy never invents a rule you didn't ask for, so sorting by Tag alone leaves each tag's songs in their current order rather than shuffling them.
• Dragging or nudging a sorted list turns it into a manual draft and clears the rules. The controls will never claim a hand-tuned order came out of them. Removing the last rule keeps its result as the draft rather than snapping back.

BPM sorts numerically, so 94 comes before 128 — except where a song's scenes disagree about it and the value reads 120 / 128, which sorts as text rather than pretending the first number is the song's answer.

Reset puts the list back the way the set has it and clears the rules with it.

Two consequences the modal says out loud rather than springing on you:

• Applying gathers a song found in more than one run. Its row says 2 runs → 1, and a line under the list names the songs it will collect. A reprise stops being a reprise, which is a real change to your set that nobody dragged.
• A scene the app couldn't read isn't in the list, so it travels with the song it currently sits after — or stays at the top if no song precedes it. The count is shown, per row and in total. The alternative, pinning it to the index it holds now, would cut a song in half the moment the songs above it changed length.

The cost is stated before it runs (18 scenes · 142 clips copied · 18 deleted), and applying closes the modal and clears the selection, because every scene index is about to mean a different row.

It goes to Live as one plan and one message, not a move per song. That's what keeps it a single entry in Live's own history — and a half-applied running order is the worst state this app could leave a set in.

Only the scenes that actually have to move do move. Moving one song out of a hundred costs what dragging that one song costs.

Starting a new show

New show, at the bottom of the running order, swaps it for a list that starts empty. Type tonight's songs in the order you'll play them; when you're done, the set holds those songs in that order and every other song is deleted.

Typing suggests the set's songs that aren't in the list yet. Matching ignores case; the exact title comes first, then titles that start with what you typed, then titles that contain it.

key	does
Enter	adds the highlighted suggestion (the first, unless you moved) and clears the field
↑ / ↓	moves the highlight
Backspace in an empty field	takes the last song back out
Esc	clears the field; in an empty field, closes the modal

Clicking a suggestion adds it too. Each row reads like the running order's — position, bpm, key, name, tag — and can be dragged, nudged with ↑/↓, or taken out with ×.

What is kept follows the running order's rules exactly:

• The picked songs, in the order you typed them, each song's runs gathered into one.
• A scene the app couldn't read goes with the song it currently sits after: kept if that song is in the show, deleted if it isn't. Unread scenes above the first song stay at the top.

Commit takes two presses. The first arms it, and the button says what the second will do — Delete 34 songs — press again. Any change to the list disarms it. Before either press, the line beside it states the cost and how many songs and scenes will be deleted. Commit stays disabled while the list is empty.

It goes to Live as one plan and one message, and the app sends the name of every scene it planned against. If the set changed in Live since — a scene renamed, added or removed — the bridge refuses the plan and nothing happens; take a fresh snapshot and commit again. If a copy fails partway, nothing is deleted: the set holds the new order's copies, some blank scenes and every original, and the log says so in red — tidy it up in Live.

Committing closes the modal and clears the selection. There is no undo here for the reason below, and this one deletes whole songs. Save your set before committing a new show.

Why there's no undo

Live has no "move scene" operation, so a move is build-then-delete: create blank scenes at the destination, copy every clip across, carry the scene's properties, then delete the originals.

The app's undo works by reading "before" out of the last snapshot — which holds every clip's name and color, and nothing that could rebuild a deleted scene's clips. So a move clears the undo entry rather than replacing it.

What it does instead is ask Live to group the whole move into one step in Live's own undo history. The log tells you whether Live agreed. That mechanism is undocumented, and this project treats it as unverified — so:

Save your set before reordering.