@ihabdevteam/core 0.270.0 → 0.272.0

package/CHANGELOG.md

@@ -7,6 +7,86 @@ All notable changes to this project will be documented in this file.
 > 적은 글이라, 지금 이름으로 고쳐 놓으면 그 시절에 그 이름으로 받은 사람이
 > 제 이야기를 못 찾는다.
 
+## 0.272.0
+
+### 재생 속도가 **소리를 실을 때마다 지워졌다** (말귀 요청 (78))
+
+`HTMLMediaElement.load()` 는 **명세대로** `playbackRate` 를 `defaultPlaybackRate` 로 되돌린다.
+코어는 소리를 실을 때마다 `a.src = …; a.load();` 를 하는데 **그 뒤에 빠르기를 다시 거는 자리가
+없었다.** 게다가 빠르기를 보는 효과는 **값이 바뀔 때만** 돈다 — 값은 그대로 0.75 라 다시 돌
+일이 없었다. 그래서 **설정은 멀쩡한데 소리는 보통 빠르기**였다.
+
+말귀 실측: 훈련을 열 때 `playbackRate = 0.75`, 누른 뒤 `1`, 소리 길이 **583ms**(0.75x 면 ~780ms).
+청능훈련에서 **느리게 들려주는 것**은 흔히 쓰는 길이라 이 설정이 안 먹으면 쓸 수가 없다.
+
+**고친 것은 값 하나가 아니라 자리다.** `a.src = …; a.load();` 가 **다섯 군데**에 흩어져
+있었다 — 첫 재생 · 다음 트랙 · TTS 길 둘 · 번호 단추. 다섯 어디에도 빠르기를 다시 거는 일이
+없었고, 하나만 고쳤으면 나머지 넷에서 같은 일이 났다. **소리를 싣는 자리를 하나로 모은다**
+(`소리싣기`). 그 안에서 `defaultPlaybackRate` 를 먼저 세우고(`load()` 가 그것으로 되돌린다),
+실은 뒤에 한 번 더 건다(기본값을 못 세우는 환경 대비).
+
+`test/audioPlaybackRateSurvivesLoad.test.tsx` 가 **`load()` 를 부르는 자리 수**를 센다 —
+하나가 둘이 되는 순간 운다. 거기에 명세대로 되돌리는 `load()` 를 흉내 내 **빠르기가 살아
+남는지** 실제로 재는 시험 넷을 뒀다.
+
+> **문이 우는지 확인하다 한 번 속았다.** 고침이 두 겹이라 **한 겹만 걷으면 다른 겹이 가려
+> 준다** — "걷었는데 통과한다" 를 잠든 문으로 읽을 뻔했다. 나간 판의 결함을 **그대로
+> 되살려** 재니 넷이 빨개졌다. 두 겹짜리 고침을 지키는 문은 한 겹씩이 아니라 **결함
+> 그대로**로 재야 한다.
+
+## 0.271.0
+
+### 진행 사슬이 **틀이 느리면 스스로 말한다** — 개발 중에 한 번 (말귀 신고 (77) 을 좇다)
+
+말귀가 "재생바가 소리 중에 얼어붙고 **경계에서만** 뛴다" 를 재서 보냈다(요청 (77),
+0.267.0 은 촘촘했는데 0.270.0 은 성기다). 나도 놀이터에 앱과 같은 꼴(소음 켬 · 파형 끔 ·
+소리 둘 · 앞뒤 뜸)을 세워 재니 **똑같이 1초에 한 번씩 계단으로** 올라갔다.
+
+**두 각도로 파고 둘 다 깨끗했다.**
+
+1. **셈** — 틀을 손으로 돌려 틱을 몰았다(`test/useProgressTicker.test.tsx`, 다섯 개 새로).
+   앞 뜸 0→25%, 소리 25→75%, 뒤 뜸 75→100%, 뜸 0 이면 50%. **세 구간 모두 매 틀
+   나아가고** 경계에서 뒤로 안 튄다. (74)③ 은 그동안 순수 함수와 배선으로만 잡혀 있었고
+   "사슬이 세 구간을 지나며 실제로 움직이나" 는 아무도 안 봤다.
+2. **사슬이 끊기나** — 손잡이 효과의 치우기가 `stopTicker()` 를 부른다. 그 효과의 입력이
+   하나라도 판마다 새로 지어지면 **재생 도중 사슬이 끊기고**, 다음 구간까지 아무도 다시
+   안 걸어 **마커와 파형이 함께 얼어붙는다** — 신고된 모양 그대로다. 지금 코드는 안
+   끊긴다(`test/audioProgressChainRerender.test.tsx`). 끊기게 만들어 보면 빨개진다.
+
+**그러고 나서야 틀 세기를 달았다.**
+
+    101ms  left=100%  틀=0
+    1002ms left=100%  틀=1
+    2001ms left=100%  틀=2
+
+**1초에 틀 하나.** 숨은 칸에서 브라우저가 `requestAnimationFrame` 을 줄인 것이다. 이 사슬은
+**매 틀** 값을 쓰므로, 틀이 1초에 하나면 바도 1초에 한 번만 움직인다 — **값은 다 맞는데
+멈춘 것처럼 보인다.**
+
+그 한 줄을 먼저 알았으면 거기서 끝났을 일이라, **사슬이 스스로 말하게** 한다. 틀 사이가
+400ms 를 넘으면 개발 판에서 **한 번** 찍는다 — 몇 ms 인지와 함께, **칸이 숨었는지 보이는지로
+다른 말**을 한다(숨었으면 "지금 재는 값은 사람이 보는 화면과 다르다", 보이면 "같은 화면에서
+무거운 일이 도는지 보라"). 운영 빌드에서는 아무 일도 안 한다.
+
+**(77) 은 코어 결함이 아니었다 — 말귀가 틀 수를 달아 가름냈다(거둬들였다).** 같은 코드 ·
+같은 화면에서 두 번 쟀다:
+
+    틀이 도는 자리 (3초에 361틀 = 120fps)
+      966ms   left 0.339879%   틀=114    ← 뜸 시작, 여기서부터 촘촘히
+     1570ms   left 23.1873%    틀=186
+     2053ms   left 41.1992%    틀=243  ct=0.09   ← 소리 중에도 이어진다
+
+    틀이 안 도는 자리 (바로 다음 호출)
+      848ms ~ 2908ms   left 100%   틀=0          ← 내내 얼어붙음
+
+**틀이 0 이면 안 움직이고, 틀이 돌면 매끄럽다.** "경계에서만 뛴다" 도 틀이 1초에 한둘이라
+그 사이 값만 보인 것이었다.
+
+> **자료는 이미 답을 들고 있었다.** 신고에 "`left` 와 `clip` 이 **늘 짝을 맞춘다**" 가 적혀
+> 있었는데, 셈이 틀렸다면 **값이 틀리게** 나오지 짝을 맞춘 채 **덜 자주** 나오지는 않는다.
+> 짝은 맞는데 드물다 — 그건 셈이 아니라 **부르는 쪽**이다. 같은 줄을 양쪽이 반대로 읽었고,
+> 가른 것은 **틀 수 한 줄**이었다. 그래서 이 판이 그 한 줄을 사슬에 박아 둔다.
+
 ## 0.270.0
 
 ### 소리 한 번에 **낭독기가 말을 두 마디** 했다 — 알릴 값이 있는 것만 읽는다 (사장님 결정 (나))