adminandClaude Opus 5.5
5c0d52da66
A rhythm game has to know how far a press lay from the beat. Input only kept that a key went down during a frame, so a press was known to a frame (16.7 ms) at best. Hit windows are ±20 to 50 ms. - Input and the game pointer keep the time stamp of each real press. Auto repeat of a held key does not count. - The new event node On key hit hears a key or a click. It gives the offset to the nearest point of the grid (beat, 1/8 or 1/16), with bar, beat and the heard second. A calibration input moves the press. - The SoundLibrary maps the press onto the heard song position through getOutputTimestamp, minus the limiter. Safari lacks it, there the audio clock minus the latency is wound back to the press. - Playbacks.times takes the heard second as a parameter, so the song position can be asked for a moment in the past. - A pattern with swing puts its grid points where the swing moves the notes. The end of a pattern without loop is no grid point. - A press older than 0.25 s when its frame comes is dropped, which covers presses during the toolbar pause. Exactly half way between two points counts as late for the first one. - Without music playing no event comes, as decided in the issue. - The 400 step test in tilemap-patch.test.ts gets a 30 s limit. It took 7.45 s in gate 761 while the suite shared the cores of stein2. Tests: 23 new unit tests (key-hit 19, sound-library 1, audio-switch 1, catalog and event count). 23 mutations, all red. e2e 65 ALL PASSED, 79 checks. In the new 65k7 three presses of H in one frame lie 4.4 and 4.1 ms apart, and so do their offsets. Without the time stamps all three get the same offset and only 65k7 goes red. Gate 5251 of 5252 green, the one red count in event-order.test.ts is fixed and checked on its own. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>