@ihabdevteam/core 0.266.0 → 0.268.0

package/CHANGELOG.md

@@ -7,6 +7,105 @@ All notable changes to this project will be documented in this file.
 > 적은 글이라, 지금 이름으로 고쳐 놓으면 그 시절에 그 이름으로 받은 사람이
 > 제 이야기를 못 찾는다.
 
+## 0.268.0
+
+### 뜸이 **완전한 무음**이었다 — 소음은 뜸부터 깔린다 (말귀 요청 (74) 이어서)
+
+(74) 를 내고 나서 소음 쪽을 짚어 보니 **뜸 동안 소음이 안 났다.** `fadeInNoise` 가 `play`
+이벤트에서만 불렸으니, 소음이 **단어와 같이** 왔다.
+
+그러면 뜸을 둔 뜻이 없다. 뜸은 소리가 터지지 않게 두는 구간인데 거기가 무음이면, 단어가
+소음과 함께 들이닥치는 것은 그대로다. 사용자가 (74) 를 말할 때 기준으로 삼은 것도
+**"노이즈가 나오는 순간부터 재생바도 움직여야 한다"** 였다 — 그 순간이 단어와 겹치면
+기준 자체가 성립하지 않는다.
+
+**더 나쁜 쪽이 있었다. 감시가 뜸 한가운데서 소음을 껐다.** `useNoiseFade` 의 감시 타이머는
+"메인 `<audio>` 가 도나" 만 보고 두 번 어긋나면(약 0.8초) 소음을 내린다. 그런데 뜸 동안
+메인은 **멈춰 있다** — 앞 뜸에는 아직 `play()` 전이고, 뒤 뜸에는 이미 `ended` 다.
+**1000ms 뜸이면 800ms 에 소음이 꺼진다.** 소음을 켜기만 하고 이쪽을 안 고쳤으면 앞 뜸은
+"소음이 잠깐 났다 끊기는" 구간이 됐을 것이다.
+
+그래서 **둘을 함께** 고친다.
+
+1. 앞 뜸이 시작될 때 소음을 올린다. `play` 쪽 호출은 그대로 둔다 — `fadeInNoise` 는 이미
+   돌고 있으면 지금 볼륨에서 목표까지 이어 가므로(멀티소스 전환 때문에 그렇게 돼 있다)
+   두 번 불려도 안 끊긴다.
+2. 뜸 구간을 **재생 중으로 센다**(`padRef`). 감시 타이머 · 탭 복귀 · 소음 설정 변경 —
+   "메인이 도나" 를 묻던 **네 자리** 전부.
+
+시험은 **고치기 전에 실제로 빨개지는지** 확인했다(`test/useNoiseFade.test.tsx` 의 앞 뜸 ·
+뒤 뜸 둘). 거기에 "뜸이 끝나면 다시 걷는다" 를 함께 뒀다 — 그것이 없으면 앞 둘은
+**감시를 꺼 버려도** 통과한다.
+
+`test/audioPlayerPadWiring.test.ts` 에 **소음을 켜는 자리의 묶음**을 세는 문을 뒀다
+(`useNoiseFade` 넷 · `useTTSPlayback` 하나 · 재생기 둘). 그 결정이 흩어진 채로 자라면
+한 자리만 안 따라가서 소음이 났다 끊겼다 한다.
+
+> **실측은 아직 못 했다.** 놀이터에는 `NoisePlayerContext` 가 없어 홀로 선 재생기에 소음을
+> 걸 수가 없다. 이 판은 **코드를 읽어 길을 보고 시험으로 못 박은 것**이다 — 앱에서
+> 소음을 켠 채 앞 뜸을 주고, 소음이 누름 기준 몇 ms 에 올라오는지 재 주면 확인된다.
+
+## 0.267.0
+
+### 뜸이 **앱까지 닿지 않았다** — `TrainingStepListen` 이 가운데에서 끊었다 (말귀 실측)
+
+(74) 로 `leadInMs` · `tailMs` 를 재생기에 더해 0.266.0 으로 냈는데, 앱은 임시 자를 못 걷었다.
+**앱은 재생기를 직접 세우지 않는다** — 훈련 러너 여섯이 전부 `TrainingPagePopup.ListenStep`
+으로 짓고, 그 길은 `ListenStep`(`...rest` 로 다 흘린다) → `TrainingStepListen` →
+`TrainingStepAudioPlayer` 다. 끊긴 곳은 **가운데 하나**였다.
+
+`TrainingStepListenProps` 에 둘을 더하고 그대로 넘긴다. 기본 0 이라 안 주면 전과 같다.
+
+**글로 적지 않고 센다** — `test/trainingStepListenForwards.test.ts` 가 재생기 프롭 가운데
+`TrainingStepListen` 이 **스스로 정하는 것**(`ttsText`·`btnLabel`·`disabled`·`className` 등,
+까닭을 한 줄씩 적었다)을 뺀 나머지가 전부 지나가는지 센다. 재생기에 프롭을 새로 더하면
+그 이름을 대며 빨개진다. 안 넘기면 실제로 빨개지는지 확인했다.
+
+### 잇따라 나는 소리 사이는 **뒤 뜸 + 앞 뜸**이다
+
+`ended` → 뒤 뜸 → 다음 소리 실어 `play()` 앞에 앞 뜸, 차례가 그렇다. 앞뒤 1000ms 면
+소리 사이가 **2000ms** 다(같은지 다른지 맞히기의 1 → 2, 듣고 순서대로 기억하기의 세 소리).
+
+**실측으로 못 박았다**(2026-10-05, 놀이터 `#training-step` → `leadInMs · tailMs` 의 두 소리
+재생기, 새로 고친 뒤 진짜 클릭):
+
+    누름                     0
+    play   C02013         1951      ← 불러오기 + 앞 뜸
+    ended  C02013        15055
+    play   C19015        17058      ← 사이 2003ms (뒤 1000 + 앞 1000)
+
+**첫 소리만 다르다** — 앞 뜸이 불러오기 *뒤에* 붙으므로, 처음 누를 때는 불러온 시간이 더해진다.
+둘째부터는 소리가 이미 손에 있어 뜸만 남는다.
+
+> **남은 자리: 첫 누름의 앞 860ms 는 재생바가 아직 0% 다.** 같은 자리에서 60ms 마다 떠 보면
+>
+>     0      누름
+>     0~840  채움 0%            ← 불러오기·파형 준비
+>     757    loadstart
+>     790    canplay
+>     ~860   앞 뜸 시작 → 채움이 움직이기 시작
+>     1867   play
+>
+> 말귀가 짚었던 **2029ms 의 멈춘 재생바가 860ms 로 줄었지만 0 은 아니다.** 그 860ms 는
+> 뜸이 아니라 **불러오기**다 — 진행이 실제로 나아가지 않는 구간이라, 거기서 재생바를
+> 움직이면 거짓을 그리게 된다(그 구간에는 불러오는 중이라는 제 표시가 따로 있다).
+>
+> 줄이려면 **뜸과 불러오기를 겹쳐야** 한다 — 누르는 순간 앞 뜸을 시작하고 그동안 받아서,
+> 받기가 뜸보다 빠르면 누름 → 소리가 앞 뜸 길이로 수렴한다. 사람 귀에는 어느 쪽이든
+> 조용한 구간이라 바뀌는 것은 **길이뿐**이다. 다만 소음이 언제 올라오는지가 함께 움직이므로
+> (소음은 뜸 구간에 깔린다) 재서 정할 일이다. **안 했다** — 쓰는 쪽의 소리 길이를 바꾸는
+> 결정이라 값을 쥔 쪽에서 정하는 것이 맞다.
+
+### 기본값은 **0 으로 둔다**
+
+말귀 실측: 사용자가 화면에서 들어 보며 300 → 500 → 1000 으로 세 번 올려 **앞 1000 · 뒤 1000**
+에서 멈췄고, 까닭도 섞여 있다 — 문장 음원은 이미 앞 1500ms · 뒤 870ms 를 갖고 있어서
+(`se_training_resources/LIN_D/C19015.mp3` 8177ms 중) 단어에 앞뒤 1000ms 를 주면 문장과 비슷한
+결이 된다. 쓸 만한 값이다.
+
+그래도 **코어 기본값은 0 이다.** 0 이 아닌 기본은 이 프롭을 모르는 모든 쓰는 쪽의 소리를
+말없이 늦춘다. 값은 앱이 준다 — `<TrainingPagePopup.ListenStep … leadInMs={1000} tailMs={1000} />`.
+
 ## 0.266.0
 
 ### 단어 소리에 **앞뒤 뜸**을 둔다 — `TrainingStepAudioPlayer` (말귀 요청 (74))