PCO Plan 1.9.0: a Song Key tile, keys as notes, and AbleSet-shaped section chips #32

2026-09-27T11:18:49-04:00

michael commented

2026-09-27 11:18:49 -04:00

Three changes.

Section chips match AbleSet

The AbleSet strip on the Plan tile's current item used pills. It now uses the same rounded square (border-radius: 0.35em), tinted ground (--text at 8% over --panel) and transparent border the AbleSet module gives its own section pills, so the two read as one family.

The chip playing keeps its own ground rather than letting the row show through, so its progress fills against the chip instead of against the highlighted row behind it.

Song Key

A third entry in the ＋ picker: Song Key, the key of the item ProPresenter has live, as large as the tile allows. Sizes come from the tile itself (container units), like the AbleSet module's single readouts, so a 1×1 tile and a wall-sized one both read properly.

The song's name and the next keyed song under it — the next keyed item, so a talk between two songs is skipped.
Three settings, all loose (two toggles and a colour is under five, so no group — rule 8): Key, Song name, Next key.
No new connection: it reads the same streamed state the Plan tile does.

When the feed goes: if the ProPresenter feed that picks the item goes away, the key stays up — the band still needs it — but faded, and the tile's dot turns red saying it is the last item rather than the current one. Verified by disabling the ProPresenter module with the tile open.

Keys are written as notes, everywhere the module shows one

Planning Center stores keys as typed: Bb, F#m. Both tiles now show them as B♭ and F♯m — the Song Key tile's big value, its next-key line, and the Plan tile's item badge.

The notation lives in one file, key-notation.js, imported by both clients rather than each keeping its own copy of the parse. It leaves anything it does not recognise alone, so a German H or an empty key passes through untouched:

Planning Center	shown
`Bb`	B♭
`F#m`	F♯m
`Db7`	D♭7
`D`	D
`H`	H (unchanged)

In the Song Key tile the accidental and quality sit on the same line as the letter. I tried raising the accidental and shrinking the quality, which is how a key is normally set, but at tile sizes it read as two stacked characters rather than one word — worse at a glance from the back of a room.

Verified

Against all three mocks (Planning Center, AbleSet, ProPresenter), with a plan carrying a flat, a sharp-minor and a plain key, and two Song Key tiles side by side at different sizes and settings:

Plan badges read B♭, F♯m, D; the Song Key tile and its next-key line agree.
The shared notation checked across eleven inputs including odd ones.
The chips are rounded squares at the same 0.35em as AbleSet's, and the playing chip fills over its own ground.
Empty states: nothing live, not following ProPresenter, not configured, and the stale-feed case.
The existing 43 tests pass and the server log is clean.

🤖 Generated with Claude Code

Three changes. ## Section chips match AbleSet The AbleSet strip on the Plan tile's current item used pills. It now uses the same **rounded square** (`border-radius: 0.35em`), tinted ground (`--text` at 8% over `--panel`) and transparent border the AbleSet module gives its own section pills, so the two read as one family. The chip playing keeps its own ground rather than letting the row show through, so its progress fills against the chip instead of against the highlighted row behind it. ## Song Key A third entry in the ＋ picker: **Song Key**, the key of the item ProPresenter has live, as large as the tile allows. Sizes come from the tile itself (container units), like the AbleSet module's single readouts, so a 1×1 tile and a wall-sized one both read properly. - The song's name and the next keyed song under it — the next *keyed* item, so a talk between two songs is skipped. - Three settings, all loose (two toggles and a colour is under five, so no group — rule 8): **Key**, **Song name**, **Next key**. - No new connection: it reads the same streamed state the Plan tile does. **When the feed goes:** if the ProPresenter feed that picks the item goes away, the key **stays up** — the band still needs it — but faded, and the tile's dot turns red saying it is the last item rather than the current one. Verified by disabling the ProPresenter module with the tile open. ## Keys are written as notes, everywhere the module shows one Planning Center stores keys as typed: `Bb`, `F#m`. Both tiles now show them as **B♭** and **F♯m** — the Song Key tile's big value, its next-key line, and the Plan tile's item badge. The notation lives in one file, `key-notation.js`, imported by both clients rather than each keeping its own copy of the parse. It leaves anything it does not recognise alone, so a German `H` or an empty key passes through untouched: | Planning Center | shown | | --- | --- | | `Bb` | B♭ | | `F#m` | F♯m | | `Db7` | D♭7 | | `D` | D | | `H` | H (unchanged) | In the Song Key tile the accidental and quality sit on the **same line** as the letter. I tried raising the accidental and shrinking the quality, which is how a key is normally set, but at tile sizes it read as two stacked characters rather than one word — worse at a glance from the back of a room. ## Verified Against all three mocks (Planning Center, AbleSet, ProPresenter), with a plan carrying a flat, a sharp-minor and a plain key, and two Song Key tiles side by side at different sizes and settings: - Plan badges read B♭, F♯m, D; the Song Key tile and its next-key line agree. - The shared notation checked across eleven inputs including odd ones. - The chips are rounded squares at the same 0.35em as AbleSet's, and the playing chip fills over its own ground. - Empty states: nothing live, not following ProPresenter, not configured, and the stale-feed case. - The existing 43 tests pass and the server log is clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

michael changed title from ~~PCO Plan 1.9.0: a Song Key tile, and AbleSet-shaped section chips~~ to PCO Plan 1.9.0: a Song Key tile, keys as notes, and AbleSet-shaped section chips

2026-09-27 11:27:55 -04:00

michael added 4 commits 2026-09-29 14:58:12 -04:00

PCO Plan 1.9.0: a Song Key tile, and AbleSet-shaped section chips 4e5b60e82b

**Song Key**, a third entry in the ＋ picker: the key of the item
ProPresenter has live, as large as the tile allows. It is set as a note —
B♭, F♯m rather than Bb and F#m — with the song's name and the next keyed
song under it. All three are tile settings: the colour, the name and the
next key. There is no new connection; it reads the same streamed state the
Plan tile does.

The accidental and the quality sit on the same line as the letter. Raising
the accidental read as two stacked characters at tile sizes, which is worse
than plain at a glance from the back of a room.

When the ProPresenter feed that picks the item goes away the key stays up —
the band still needs it — but faded, and the tile's dot says it is the last
item rather than the current one.

**The section chips** on the Plan tile's current item are rounded squares
now, with the tinted ground and transparent border the AbleSet module gives
its own section pills, so the two read as one family. The chip playing keeps
its own ground so its progress fills against the chip rather than against
the row behind it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Keys read as notes on the Plan tile's badge too 06066529bc

The item badge still showed Planning Center's raw "Bb" and "F#m" while the
Song Key tile beside it showed B♭ and F♯m. One module should not spell the
same thing two ways.

The notation moves into key-notation.js and both tiles import it, rather
than each keeping its own copy of the parse: the day one of them changes,
they all should.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Centre the text in the song-section chips 32180bf299

The chips looked top-heavy, and measuring said so: the capitals sat 5.12px
below the top of the chip and 4.22px above the bottom. Uppercase text has no
descenders, so the font's descent allowance below the baseline is empty
space the letters never use, while the gap between the ascender line and the
cap height sits above them.

The padding is now a touch shallower on top and deeper below, which puts the
letters themselves in the middle: 4.67px above, 4.68px below. In em, so it
holds wherever the tile's text size is set.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Centre the NOW tag; the type badge was already fine ece2c0a2c3

Re-measuring the badges properly changed the answer. The earlier reading
that said the type badge sat 0.52px high was measuring the wrong glyphs: it
fed the canvas the element's raw text ("Song", "Media") while the page
renders text-transform: uppercase ("SONG", "MEDIA"), and a lowercase 'd' or
'g' has an ascender and a descender the capitals never draw.

Measured against the text as actually rendered, the type badge is within
0.10px of centred and wants nothing. The NOW tag was the one off, by 0.59px,
the same way the section chips were. So: the badge padding added in the last
commit is reverted, and the NOW tag gets the correction instead.

That line now reads, in px off centre: NOW 0.01, type badge 0.10, key badge
0.16, section chip -0.01.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

michael force-pushed claude/pco-song-key from d24a050193 to ece2c0a2c3

2026-09-29 14:58:12 -04:00

Compare

michael merged commit 9ca301b4be into main

2026-09-29 14:58:57 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: michael/ProdDash#32