Three panels, one language. BROWSE the library · BUILD a custom pattern by hand (or from a photo, honestly assisted) · PLAY it at tempo.
The frames are live — tap the chips, the rows, the slots, the transport. Every frame is 390 pt wide at 1:1, so every size here is the size to type into SwiftUI.
1.1+ arc only. Nothing here touches the frozen 1.0 scope. Reconstructed sticking is flagged in the footer — verify against the PAS chart before it ships.
THE STROKE VOCABULARY
①BROWSEPAS families + the 27 existing accent grids, one row component
RUDIMENTS
—
Rows are one component. A true rudiment shows strokes on both sides of the rail; an accent grid from
AccentPattern.swift has no hand, so it renders exactly as the app draws it today — all above the rail,
dashes for sticking. That is the coexistence: an accent grid is a rudiment with nil hands.
Select a grid and ADD STICKING seeds the builder with its accents — 27 patterns become 27 starting points.
Gestures (mock shows the tap path). Tap a slot to select · swipe a slot up/down to cycle velocity ·
double-tap to flip its hand · drag across slots to paint one velocity. The inspector is the discoverable
path; the gestures are the fast one.
Four velocities, not two. ACCENT / TAP / GHOST / REST. Ghost is what moving-accent drills need (R2 §3);
REST closes the note already sitting in AccentPattern.swift:154-155 — "bare clave (silent non-hits) waits for
a .silent velocity in v2". One enum change, two open wants closed.
②bPHOTO ASSISTR3 Tier 2 — assisted, never automatic. Sub-flow of ②
‹
PHOTO ASSIST
BETA
THIS IS A DRAFT, NOT A TRANSCRIPTION
Your phone reads the page and proposes strokes. Every proposal starts unconfirmed.
Nothing saves until you have confirmed all of them. If it guesses badly, correct it in the builder —
you are never worse off than typing it in.
ON DEVICECAPTURED · PERSPECTIVE CORRECTED · VNDocumentCamera
STICKING R/LSTRONG
STROKE POSITIONSFAIR
ACCENTS >CHECK
FLAM / DRAGCHECK
Why the meters differ. R and L are single printed characters — that is text OCR, which Apple's Vision
framework is genuinely good at. Accent wedges and grace notes are shape heuristics on a photographed page:
no reviewed OMR tool, open-source or commercial, demonstrates strong accuracy on scanned and annotated
percussion pages (R3, §"state of OMR"). So the app says so, on the screen.
0/ 8 CONFIRMEDTAP EACH ? TO CONFIRM
Privacy posture unchanged. VisionKit capture + Vision recognition run entirely on-device. No
networking, no new API-access reason — the app's "Data Not Collected" label survives intact (R3, verified
against PrivacyInfo.xcprivacy). Cloud OMR would break that for accuracy nobody has demonstrated.
The gate is the design. SAVE stays disabled at 7/8. A drummer who must re-check every bar of an
"automatic" transcription has gained nothing over typing it; a drummer confirming an already-mostly-right
grid has gained real time. That reframe is R3's core finding, rendered as a disabled button.
③PLAYINGLive at tempo. Discrete cell lighting, bounded pulse
‹
PRACTICE
16TH
96BPM0 REPS
SINGLE PARADIDDLEPAS 16
LEADRSLOT—GESTURERLRR·LRLL
HEAT LADDER · OPEN → CLOSED → OPENGLOW
Read the shape, not the letters, from across the room. At 2 m the R/L glyphs are below acuity on any
phone (R1 §5.1). The rail silhouette — up for right, down for left — is a gross position code that survives.
STAND VIEW strips the chrome and takes the letters to 64 pt for the 1 m glance.
No sliding playhead. AccentTickLane.swift's own comment forbids it: per-tick publishes hop off the audio
timer and jitter. The current slot lights, the two behind it decay, nothing interpolates — which is also the
correct Reduce Motion behaviour for free. The beat ring is the only wide element that moves, and it
switches from brightness to scale above 180 BPM (R1 §5.4, WCAG 2.3.1).