AFTERBEAT afterbeat-core, live

Scoremotoren, ikke en illustrasjon av den

Alt under kjører gjennom den samme koden som skal score en ekte dans på en ekte telefon. Ingen tall her er forhåndsdefinert — endrer du en kontroll, beregnes resultatet på nytt av afterbeat-core, akkurat nå.

Kamera og pose

getUserMedia + requestVideoFrameCallback · MediaPipe Tasks Vision (OSS)

Ekte kamerabilde, ekte skjelett fra en ekte modell — ikke MockPoseProvider. Klokkebeskrivelsen står Unknown med vilje: vi har ikke målt hvilken klokke presentationTime faktisk er forankret i på tvers av nettlesere, så denne kilden er alltid urangert. Se ADR-0004 og sprint 18 i Motion Proof-planen.

Kameraer ikke søkt
Miljø
Effekter

Kobler til økten …

Eksternt kamera (WHEP)
FPS (målt)
Jitter
Personer funnet
Bro til afterbeat-serverFrakoblet

Live fra telefonen

/ws/live · positurrelay, ikke video

Trykk Send live på telefonen, og Se live her. Det som sendes er normaliserte landmarks — cirka 1 kB per frame mot ~100 kB for et videobilde — og denne skjermen tegner dem med nøyaktig samme drawSkeleton og drawTrails som telefonen bruker. Scoringsveien (/ws/motion) er urørt: å se på kan ikke påvirke et resultat.

Ingen sender akkurat nå
Status
Frames/s
Video

Rytmefølging

find_motion_peaks + RhythmFollowing (egenbygget, ikke GPL)

Følger bevegelsen takten — uten et forhåndsdefinert beatmap. Knappene under sender et ekte 1D-signal (simulert håndhøyde over tid) til /api/rhythm/analyze, som finner ekte hastighetstopper og sammenligner fasen deres mot forventet slag.

Musikken

Web Audio API · sample-nøyaktig planlagt avspilling

Ekte avspilling planlagt med audioContext.currentTime, ikke setTimeout. BPM settes manuelt denne sprinten — bevisst scope, se sprint 21 i Motion Proof-planen. Start sesjon sender et lite ekte beatmap over broen og starter TrackClock::driving i backend synkront med det som faktisk spiller.

Scenen

CalibrationProfile → MotionFrame → evaluate_timing

Tre ting kalibreringen måler om en ekte spiller, gjort om til kontroller her. Se hvordan hver av dem påvirker figuren og målingen — ikke bare et tall i en tabell.

Tempo

120 bpm

Slaget spillet regner alt mot. TrackClock planlegger hvert treffvindu fra dette — dobler du farten, halveres tiden du har til å reagere.

Kroppsstørrelse

1.00×

Simulerer en høyere eller lavere spiller. Range måles mot spillerens eget komfortområde — en høy og en lav spiller skal score likt på samme relative utslag.

Sporingskvalitet

0.90

Dårlig lys eller occlusion senker denne. Under grensen (hentet fra MIN_OBSERVATION_CONFIDENCE, ikke gjettet her) blir resultatet Neutral — systemet mangler bevis, det er aldri spillerens feil.

Beatmapet

BeatmapRuntime · MoveEvent-vinduer plassert på en tidslinje

Hvert treff er et forenklet MoveEvent: hvilket slag det skal treffes på, og hvor mange millisekunder spilleren faktisk traff ved siden av. Plasseringen på linjen under er ikke dekorasjon — den er beregnet fra de samme tallene som sendes til serveren.

Kompilatoren

jsonschema (OSS) → validate_beatmap · ADR-0005

Et fullstendig beatmap som JSON, kompilert i to lag. Først skjemakonformitet — har det de feltene og typene beatmap.schema.json krever, sjekket av det åpne kildekode-biblioteket jsonschema. Består det, kjøres domenereglene — GDD-en og ADR-0005s gate-tetthetsregel. Et beatmap som feiler lag én sendes aldri til lag to.

Lydkilder

cpal + symphonia (OSS) · SPIKE-002 kildeenumerering

To ekte ting, ikke to påstander: hvilke lydenheter denne serveren faktisk ser gjennom cpal akkurat nå, og en symphonia-dekoding av en committet WAV-fil — beviser at nivå 2 i musikkstrategien (lokale filer) fungerer ende til ende.

Enheter

Dekoding

Inferensmotoren

tract-onnx (OSS) · ren Rust, ingen C++-binærfil

Ingen pose-modell finnes ennå — det krever et ekte kamera å verifisere mot, se ADR-0008. Dette beviser noe smalere og like viktig: at selve kjøremotoren virker. Grafen under er en ekte, committet ONNX-fil (y = x·2 + 1), lastet og kjørt av tract — samme motor som skal kjøre en faktisk posemodell senere.

Determinisme

run_directory(qa/golden/)

Kjernekravet i hele arkitekturen: samme innspilte bevegelse skal gi identisk score på Windows, Android og iOS. Dette kjører de forpliktede referansestrømmene mot dagens evaluator-kode og viser om det fortsatt holder.