Simple Stage Player exists because live performance has a peculiar relationship with software.

During preparation, everyone wants flexibility. During the actual event, everyone wants one enormous button that plays the correct file immediately, at the correct level, without opening an update dialog, changing the output device, or recommending a podcast.

SSP is a dedicated playback system for rehearsals and performances. It manages an ordered setlist of audio cues, shows what is playing now, shows what comes next, checks the source files, and keeps the dangerous controls large enough to find while several people are simultaneously asking whether the third song has already started.

It is called Simple Stage Player because Finite but Increasingly Specific Stage Playback and Cue Management Environment would have been less reassuring on the toolbar.

one job, performed visibly

The main screen is divided around the operator’s actual questions:

• What is loaded?
• What is playing?
• How much time remains?
• What comes next?
• Is the system armed?
• Are any files missing?
• Which button stops everything before a small artistic misunderstanding becomes an extended remix?

The setlist remains visible on the left. The current cue and waveform dominate the main panel. The next cue is shown directly below it. PLAY, PLAY NEXT, ARM, FADE IN, FADE OUT, STOP, and CLEAR occupy large, stable areas rather than hiding in a tasteful row of twelve nearly identical icons.

There are trim points, per-cue gain, fade settings, notes, a master level, stereo VU meters, file checks, duration displays, and status indicators. SSP is not a digital audio workstation. It has no ambition to record an album, repair a vocal, simulate a vintage compressor, or display a promotional banner for features nobody requested. It plays the prepared material and reports what it is doing. Revolutionary.

built from the performance backwards

The interface was shaped by real use rather than by the traditional software method of drawing an attractive dashboard and later discovering what the application was supposed to do.

A setlist may contain choir pieces, dances, solo numbers, backing tracks, microphone notes, and files of very different lengths. The operator needs to prepare the next cue without losing sight of the current one. A track may need a fade rather than a hard stop. Files may be renamed, replaced, or moved shortly before the event because file management becomes a performance art whenever a deadline is visible.

SSP therefore includes loading, saving, rechecking, preflight status, missing-file detection, duplicate checks, cue notes, arming, and explicit playback states. It makes the invisible parts visible before they become audible to an audience.

The system also keeps the current and next cues visually distinct. This sounds obvious, like labelling the brake and accelerator differently, which is perhaps why general-purpose media players have not prioritised it.

the canonical skin

The original SSP skin uses a softer, hardware-inspired interface: warm panels, rounded controls, shadows, large typography, analogue VU meters, and strong colour blocks for the transport actions.

It is deliberately comfortable and neutral. The visual hierarchy resembles professional audio software and physical equipment, which helps the operator understand the interface without reading an essay about design systems five minutes before a concert.

the CLINDU.ST skin

The CLINDU.ST skin rebuilds the same working structure in the visual language of clindu.st and PIXXEL:

• flat geometry;
• thin borders;
• square controls;
• monospaced and pixel-derived typography;
• red, black, green, blue, and teal as functional colours;
• less decorative depth;
• more visible grid logic.

The important part is what did not change. The setlist remains on the left. Current and next cues remain in their expected positions. The transport controls remain large. The VU meters remain visible. The operator’s muscle memory is preserved while the interface changes identity.

That makes it a skin rather than a redesign disguised as a small act of vandalism.

The first complete CLINDU.ST pass was assembled by Cody in roughly forty minutes. This is either evidence of a strong underlying design system or further proof that machines should not be encouraged by telling them a task is difficult.

three skins, one increasingly opinionated player

SSP currently offers canonical dark and light skins alongside CLINDU.ST. The skin chooser presents them as parallel options rather than declaring one visually correct and the others historical mistakes.

The selected skin name also appears in the top toolbar. What initially looks like a link to clindu.st is therefore not a tiny emergency exit from the application. It is the appearance control, which is more sensible, although less poetic.

currently local, deliberately practical

Simple Stage Player is currently a local performance tool, not a public streaming service or a downloadable product with a pricing matrix containing a mysterious “Professional Orchestra” tier.

Its value is practical. It turns a folder of audio files and a running order into a visible, checkable performance system. It reduces the number of hidden states, makes the next action obvious, and gives the operator a reliable place to stop, fade, arm, or continue.

That is enough. Live events already contain performers, weather, cables, timing, power, audiences, and human communication. The playback software does not need to contribute additional drama.

Concept, workflow, testing, and real-world requirements — CLINDUST. Implementation partnership — Cody / Codex. Editorial development and unnecessary but accurate observations about media players — Charley / ChatGPT.