cmus

What it is

cmus (C* Music Player) is a small, fast, keyboard-driven console music player that has been the gold standard for “serious music playback in a terminal” for years. It is small, fast and powerful by design: no mouse, no chrome, every action a keystroke, a single compact status line, and a deep library that scales to tens of thousands of tracks. It is the most mature and most-copied console-music-player UX in the corpus, and its three durable ideas — numeric view-switching, the one-line status bar, and library-vs-queue separation — are directly reusable for the Toneline (and the Deckline runtime generally).

UI / layout

• Seven views, switched by the number keys 1–7:

  1. library (the artist/album tree)
  2. sorted library (a flat, sortable track list)
  3. playlist
  4. play queue
  5. browser (filesystem)
  6. filters
  7. settings

  One keypress jumps between whole working modes — no menus, no window management. This is the cleanest precedent in the batch for KN-86’s “one key, one surface” navigation.

• Track list with metadata columns — artist / album / title / duration laid out in aligned columns, the standard music-library presentation.

• A single compact status/command bar at the bottom carrying playback position, volume, repeat/shuffle flags, and player state — all the transport state in one row, no separate header.

• vim-like modal control + a : command line — navigation keys for movement, single letters for transport, and a : command mode (:add, :save, :set …) for everything else. The command line is where power lives; the keys are where speed lives.

Audio / architecture

• Pluggable output backends (ALSA/Pulse/JACK/etc.) and broad format support, with gapless playback — tracks run into each other with no silence, which matters for any continuous-listening or DJ-style use.
• Library and queue are separate concerns. The library is the durable collection; the play queue is the transient “what’s next” list you build and drain. A dedicated player engine sits behind both. This separation — the catalog is not the playlist — is the architectural idea worth carrying.

Toneline-relevance (and Deckline note)

cmus is not a sequencer, so its value to the Toneline is UX scaffolding, not music modeling — but the scaffolding it offers is exactly what a portable music workstation needs around its sequencer core:

• Numeric view-switching (1–7) is the navigation model for the Toneline’s surfaces. A music workstation has several distinct working surfaces — sequencer/arrangement, phrase library, voice/patch editor (FM-operator params), browser, settings. Bind each to a digit on the Sweep’s number half so the operator jumps between them with one key, exactly as cmus does. This pairs cleanly with waves.md’s F-key view switching — pick numeric (cmus) for the Toneline because the right-half digit cluster is already there.
• The one-line compact status bar is the Toneline transport row. Tempo (BPM), current bar/beat, playing/stopped, current phrase/pattern, mute state — all in a single firmware-owned row. KN-86 already reserves Row 0 (status) and Row 24 (action) for exactly this kind of chrome (Canonical Hardware Specification); cmus is the reference for cramming full transport state into one dense, readable line. On the device the same fields can mirror to the CIPHER-LINE status strip.
• Library/queue separation maps to phrase-library vs play-queue. The Toneline’s saved phrases (the durable collection on the cartridge SD) are the library; the live performance queue (what plays next — cf. line’s sp/lp queue in line.md) is the queue. cmus is the precedent for keeping those two lists distinct: you curate a library, you perform from a queue.
• vim-modal + : command line as the power surface. The Toneline already has a typed-command surface (the line-style phrase prompt / KEC Lisp REPL). cmus shows the value of a : command line alongside single-key actions — keys for the fast common path, a command line for the long tail (:bpm 120, :save set1, :voice fm-bass). The Deckline’s TERM-key REPL is already this command line; cmus validates pairing it with single-key transport.

Deckline note: the compact-status-bar design and numeric view-switching are general Deckline runtime patterns, not Toneline-specific. Any Deckline surface with multiple modes (the bare-deck HUD’s tabs, a multi-pane cart) benefits from cmus’s one-key-per-view discipline and one-row-of-state status line.

Single-color adaptation

cmus is already a monochrome-friendly ncurses app — its entire UI is text in columns plus one status row, and it reads fine with no color at all. For KN-86:

• The column-aligned track list ports directly to the 80×25 amber grid; alignment and whitespace carry the structure, not color.
• The active view / now-playing row uses inversion (amber-on-black flips to black-on-amber) rather than a highlight color — the standard single-color selection cue.
• The status bar packs its fields by position and fixed-width formatting (120BPM 03:12 ▶ PHR:bass-A), exactly as cmus does, needing only character and position, never hue.

Image

Source: GitHub social card for cmus/cmus. The app’s signature look is the column track list above a single dense status/command line, with views switched by number keys.

Notes

• The three takeaways are small and durable: numeric view-switching, one-line status bar, library-vs-queue. None are music-specific; all three strengthen the Toneline’s shell around its sequencer.
• Cross-link waves.md — the F-key view-switching cousin (waves uses F1–F4; cmus uses 1–7). The Toneline can adopt either; cmus’s numeric model fits the Sweep’s digit half best.
• Cross-link line.md — cmus supplies the player/library shell; line supplies the sequencer core. The Toneline is, roughly, cmus’s UX discipline wrapped around line’s phrase engine.
• Cross-link pulsedeck.md and aethertune.md — fuller-featured TUI players in the same family; cmus is the minimalist, most-copied baseline they build past.