A playlist is an ordered list of pointers. The song exists once, somewhere, and the playlist holds a reference to it. That model is exactly right for listening: the track never changes, there’s no reason to have it twice in a row, and reordering costs nothing.
Take the same model to a gig and it starts failing on the second song.
Three things a set does that a playlist can’t
The same song appears twice, and differs. A reprise. An opener that comes back at the end, shorter. Two occurrences of one song that need to be two different things, because one of them is four minutes and one of them is ninety seconds and a fade. A list of pointers has no way to express that — the second entry is the same object as the first, so any change to one is a change to both.
The gig version isn’t the chart version. You cut a verse for a short set. You write the key change into the chords because the singer is tired. You take the tempo down. You add a line at the top saying to hold the last chord and wait for the drums. None of that belongs in your library — it’s true for this set and no other.
And changing it must not touch the chart you keep. This is the one that decides the whole design. In a pointer model, an edit in the library reaches into every setlist the song is in, including other people’s, and rewrites the running order somebody is holding up on a stand. Nothing announces it. The person who made the edit was tidying up a chart at home on Tuesday and had no idea a set changed.
So the set holds copies
Adding a chart to a setlist in Chordisplay copies it. Title, artist, key, tempo and body, taken at that moment and written into the set. From then on there are two separate things: editing the chart never reaches the setlist, and editing the song in the setlist never reaches the library.
That single decision answers all three problems at once. Adding the same chart twice gives you two independent copies, so a reprise needs no special feature and no explanation — it’s just the song, in the set, twice, and you edit each one to be what it is. The set’s version can differ as much as you like. And it can differ without any risk to what you keep, because the thing you’re editing was never the chart.
The visible consequence is that there’s no button that resets a setlist song back to the chart, and that’s deliberate rather than missing. Re-adding the song is how you get a fresh copy of the library version. A reset button would be a second, quieter path by which a chart reaches into a set, which is the thing being removed.
What the band sees
A setlist belongs to one Owner, and access is given per setlist rather than per library. An Editor adds, removes and reorders songs and changes their tempo and arrangement for that set; they can’t touch the Owner’s charts, and can’t rename or delete the setlist itself. A Viewer reads the set and plays from it, and changes nothing. That distinction only became real once access moved to the setlist: the person building the running order and the person reading it on stage want different things.
The Owner also decides, per setlist, what an Editor may add songs from — nothing, one named category, or the whole library. Category is the interesting one, and it’s how one Owner keeps two bands’ repertoires in one library while giving each band only its own.
Everyone on a setlist sees the same version of every song, so an arrangement typed in at soundcheck is on five screens by the time it matters. Each song records who last saved it and when, which is the part you want when a chord has moved and you can’t remember agreeing to it.
The version you played
Exporting a setlist gives you the running order with that set’s own tempos and arrangements applied — not the library versions arranged into a list. What comes out is what you played, which is the only reason to export a set at all.
That’s the whole difference, and it’s smaller than it sounds: a setlist isn’t a view onto your library, it’s a document of its own that happened to start life as a copy of some of it. Everything else follows from taking that seriously.