Rebuilt the Rhythm Synchronization Test's audio detection algorithm. Solved the "zero tap problem" by switching from frequency-domain analysis to time-domain peak detection. Also made the test self-contained (no CDN dependency) and rewrote state management using a centralized app object instead of scattered global functions.
Audio detection approach: Claude initially recommended getByteFrequencyData() for beat detection — the standard approach for detecting audio content in a specific frequency range.
I tested the frequency-domain approach and found it returned zero for short taps. Frequency analysis assumes enough audio duration to build frequency content. Finger taps are transient — they last milliseconds. There's no time for frequency content to develop. The fix: getByteTimeDomainData() reads raw waveform amplitude. A sharp tap shows up as a spike regardless of duration. Switched to time-domain peak detection and the zero-tap problem was solved. AI's suggestion was technically correct for detecting sustained tones; wrong for detecting brief human taps. The difference required testing on actual data, not trusting the general case.
Previous test implementations used scattered global variables: let isRunning = false, let beatCount = 0, spread across functions with unclear ownership. Rhythm Sync introduced a centralized app object: all state lives in one place, mutation always goes through one path. This pattern was retrofitted to the other tests because it made debugging radically easier — you can log app and see the complete system state at any moment.
Evaluate suggestions against the actual data, not the general case. Frequency-domain analysis is the standard approach for audio detection — in the general case. But "short finger tap on a phone screen" is not the general case. The right tool requires knowing what the audio actually contains.
State management architecture has compounding effects. Fixing state in one test took a morning; having clean state in the next test from the start took nothing.
The Rhythm Sync test measures motor timing precision — the ability to synchronize physical movement with an external auditory beat. This is a distinct cognitive-motor function from reaction time or bilateral coordination. The microphone as the input sensor makes this measurement possible from any laptop. The quarter question broadens with each test.
Session 16: User testing with external testers. Apply what's learned to fix the remaining issues before M4 complete.