Idea
Treat a web instrument as an app and turn the deck into a portable on-screen musical keyboard. Musicca maps the computer keyboard's top letter row to white keys and the number row to black keys, and every Musicca keyboard instrument (piano, synthesizer, ...) uses the same mapping. So one deckd layout of key: buttons drives all of them — and any other site that adopts the same "letters = white, numbers = black" scheme, just by adding that site's title token to match:.
This is purely keystrokes — no MIDI, no velocity. It falls out of the existing web-app layout + key: primitives with no daemon changes.
Done so far
-
layouts/musicca.yaml — one verified octave (F3–F4) as a two-row piano shape (white keys bottom, black keys top), matched by title:*Musicca*.
-
Mapping verified against the live site by driving a browser and dispatching each key:
| Note |
F |
F# |
G |
G# |
A |
A# |
B |
C |
C# |
D |
D# |
E |
F |
| Key |
q |
2 |
w |
3 |
e |
4 |
r |
t |
6 |
y |
7 |
u |
i |
-
Try it: focus a Musicca keyboard page and pin the client with ?layout=keyboard, or deckctl layout keyboard.
Next: a single-cell musical-keyboard widget (no grid)
The current layout is one button per key laid out on the uniform widget grid, which can't offset black keys onto the gaps like a real piano. Instead, consider a dedicated composite widget — a new kind, in the same spirit as the media widget — that renders a proper piano inside a single cell and owns its own internal layout:
- Black keys sit correctly between/above the white keys (the widget draws its own geometry, free of the grid's uniform cells).
- Each on-screen key fires the mapped
key: action, so the daemon side stays unchanged — this is a client rendering concern.
- Grid-independent: the widget takes one
grid: [x, y, w, h] placement like media does, and scales the keyboard to fill it.
- Opens the door to a cleaner, more playable surface on a phone than a row of same-size buttons.
Open questions / follow-ups
- Portability. Document how to add another same-mapping site (extra
match: token). Fretted instruments (ukulele/guitar) use a different mapping and are out of scope for this layout.
🤖 Generated with Claude Code
Idea
Treat a web instrument as an app and turn the deck into a portable on-screen musical keyboard. Musicca maps the computer keyboard's top letter row to white keys and the number row to black keys, and every Musicca keyboard instrument (piano, synthesizer, ...) uses the same mapping. So one deckd layout of
key:buttons drives all of them — and any other site that adopts the same "letters = white, numbers = black" scheme, just by adding that site's title token tomatch:.This is purely keystrokes — no MIDI, no velocity. It falls out of the existing web-app layout +
key:primitives with no daemon changes.Done so far
layouts/musicca.yaml— one verified octave (F3–F4) as a two-row piano shape (white keys bottom, black keys top), matched bytitle:*Musicca*.Mapping verified against the live site by driving a browser and dispatching each key:
Try it: focus a Musicca keyboard page and pin the client with
?layout=keyboard, ordeckctl layout keyboard.Next: a single-cell musical-keyboard widget (no grid)
The current layout is one button per key laid out on the uniform widget grid, which can't offset black keys onto the gaps like a real piano. Instead, consider a dedicated composite widget — a new
kind, in the same spirit as themediawidget — that renders a proper piano inside a single cell and owns its own internal layout:key:action, so the daemon side stays unchanged — this is a client rendering concern.grid: [x, y, w, h]placement likemediadoes, and scales the keyboard to fill it.Open questions / follow-ups
match:token). Fretted instruments (ukulele/guitar) use a different mapping and are out of scope for this layout.🤖 Generated with Claude Code