music_note 온라인 메트로놈 (탭 템포) star

대부분의 브라우저 메트로놈이 어긋나는 이유

JavaScript로 메트로놈을 만드는 가장 직관적인 방법은 setInterval(playClick, 60000 / bpm)입니다. 몇 초 동안은 잘 작동하지만 — 곧 어긋나기 시작합니다. setInterval이 보장하는 것은 콜백이 요청한 지연 시간보다 더 일찍 실행되지 않는다는 것뿐이며, 실제로 얼마나 더 늦게 실행될 수 있는지는 전혀 보장하지 않습니다. JS 메인 스레드는 페이지가 수행하는 모든 작업 — DOM 업데이트, 레이아웃 계산, 가비지 컬렉션 — 과 공유되며, 이 중 어느 것이든 대기 중인 타이머를 수십 밀리초 지연시킬 수 있습니다. 대부분의 UI 코드에서는 이것이 눈에 띄지 않지만, 메트로놈에서는 치명적입니다. 이번 박자에서 40밀리초 늦고 다음 박자에서 10밀리초 늦는 클릭음은 단순히 어긋난 정도가 아니라 귀로 들릴 만큼 흔들리며, 이를 기준으로 연습하는 연주자를 적극적으로 헷갈리게 만듭니다.

연주자가 메트로놈에 의존하는 이유는 정확히, 외부 기준 없이는 일정한 시간에 대한 인간의 지각이 신뢰할 수 없기 때문입니다 — 이는 1815년 요한 멜첼(Johann Maelzel)이 태엽식 버전을 특허 등록한 이래로 이 장치가 존재하는 이유 자체입니다. 스스로 어긋나는 소프트웨어 메트로놈은 그 목적 자체를 무너뜨리며, 해결책은 더 영리한 타이머가 아닙니다. requestAnimationFrame을 포함한 모든 JS 타이머는 동일한 메인 스레드 병목을 공유합니다. 진짜 해결책은 JavaScript에게 정확한 순간에 소리를 내달라고 요청하는 것 자체를 그만두는 것입니다.

룩어헤드 스케줄링: 이 메트로놈이 정확함을 유지하는 방법

이 도구는 과거 구글 크롬 Web Audio 팀에 몸담았던 크리스 윌슨(Chris Wilson)이 널리 인용되는 글 "A Tale of Two Clocks"에서 널리 알린 패턴을 사용합니다. 스케줄링 로직과 사운드 타이밍을 완전히 분리하는 방식입니다. Web Audio API의 AudioContext는 샘플 단위로 정확한 시계를 가진 자체 오디오 스레드에서 동작하며, 이는 JavaScript에 AudioContext.currentTime으로 노출됩니다. 그 시계 기준으로 미래 시각을 지정해 osc.start(t)를 호출하면, 오디오 엔진은 그 순간 메인 스레드가 무엇을 하고 있든 상관없이 정확히 t 시점에 소리를 재생합니다 — 정확한 박자에 맞춰 "깨어날" 필요가 전혀 없었던 것입니다.

메인 스레드가 하는 일은 오직 장부 기록뿐입니다. 약 25밀리초마다 스케줄러가 앞으로 100밀리초 안에 있을 박자를 확인하고, 각 박자에 대해 정확한 미래의 currentTime 값으로 osc.start()를 호출합니다. 이 루프는 대략적으로만 제시간에 맞으면 되기 때문에 일반적인 지터(jitter)는 들리는 문제를 전혀 일으키지 않습니다 — 소리 자체는 여전히 샘플 단위로 정확하게 예약되어 있기 때문입니다. 각 클릭음은 약 30밀리초 길이의 오실레이터 파열음이며, 각 마디의 첫 박자에서는 더 높은 음으로 재생되어 귀로 들리는 강세를 만들고, 대응하는 시각적 펄스와 동기화됩니다.

탭 템포는 다른 문제를 해결합니다 — 읽을 악보가 없는 음악의 BPM을 찾는 것입니다. 박자에 맞춰 탭하면 도구가 탭 사이의 간격을 측정하고 60000 / averageIntervalMs로 변환합니다. 최소 두 번의 탭이 필요하며, 최근 탭들의 평균을 내면 작은 타이밍 오차가 완화됩니다. 2초를 넘는 간격이 생기면 시퀀스가 초기화되는데, 이는 대개 박자가 크게 느려졌다기보다 놓쳤음을 의미하기 때문입니다.