ScorePlayer TIL 4
기호가 반 칸씩 어긋나고, 그림 요소가 서로 겹치고, 고쳤다는 설명이 전달되지 않았다. 증상은 제각각이었는데 배운 건 몇 줄로 묶인다.
보정값이 쌓이면 값을 더 넣지 말고 기준을 의심한다
화면을 보다가 조표(곡 첫머리에 붙어 어느 음에 ♯·♭이 계속 붙는지 알려 주는 기호)가 제자리보다 반 칸 아래에 앉은 걸 짚었다. 첫 반응은 “그만큼 올리는 값을 하나 넣자”였다.
그런데 같은 종류의 보정값이 이미 여러 개 쌓여 있었다. 기호마다 하나씩. 그건 기호가 하나씩 이상한 게 아니라 앉히는 기준 자체가 틀렸다는 신호였다.
값을 하나 더 넣었으면 그날은 맞았을 것이고, 기호를 추가할 때마다 값이 하나씩 늘었을 것이다. 대신 기준을 바꾸자 그동안 쌓아 둔 보정값 아홉 개가 통째로 사라졌다.
판단 기준으로 삼을 것 — 보정값이 두세 개를 넘어가면 “하나 더”를 멈추고 기준을 다시 본다. 보정값의 개수는 대개 잘못된 기준의 증거다.
규격이 있는 자산을 사면 보정이 필요 없다
기준을 고치는 방법은 규격을 지키는 자산을 가져오는 것이었다. Bravura(악보 기호를 담은 무료 폰트)를 골랐는데, 이 폰트가 따르는 규격인 SMuFL(악보 기호 폰트가 기호마다 번호와 기준점을 똑같이 정해 두는 표준)은 기호마다 “악보에서 어느 줄에 앉는지”를 미리 정해 둔다. 그래서 줄의 좌표를 그대로 넘기면 제자리에 앉는다.
직접 맞추는 쪽과 규격을 사 오는 쪽의 값을 비교하면 이렇다.
- 직접 맞추기 — 당장은 빠르다. 기호가 늘 때마다 보정이 늘고, 크기를 바꾸면 다시 맞춘다.
- 규격 채택 — 하루 정도 걸린다. 그 뒤로는 기호를 추가해도 값이 안 는다.
여기서 확인할 게 하나 붙는다. 자산은 라이선스를 먼저 본다. Bravura는 SIL Open Font License(폰트를 앱에 넣어 배포·판매해도 되는 공개 폰트 라이선스)라 상업적으로 쓰고 앱에 넣어 파는 것까지 되는 조건이어서 채택했다. 만들다가 나중에 “이건 못 쓴다”가 되면 그때까지 맞춰 놓은 것이 다 헛일이 된다.
같은 값을 두 곳에서 각각 정하면 언젠가 어긋난다
왼손 음표 몇 개에서 기둥(stem — 음표 머리에 붙는 세로선)이 머리 왼쪽이 아니라 오른쪽에 붙어 있는 걸 짚었다. 기둥이 아래로 뻗으면 머리 왼쪽에 붙는 게 악보의 약속이다.
원인은 같은 성질을 두 군데서 따로 판단하는 코드였다. 기둥을 위로 뻗을지 아래로 뻗을지를, 빔(beam — 8분음표 여럿의 기둥 끝을 이어 한 묶음으로 보여 주는 굵은 막대)을 그리는 쪽은 묶음 전체를 보고 정했고, 기둥을 머리 어느 쪽에 붙일지는 음표 하나만 보고 정했다. 한쪽만 보면 둘 다 맞다. 어긋남은 두 판단이 만나는 자리에서만, 그것도 특정 조건에서만 드러난다.
이런 버그는 재현 조건이 좁아서 “가끔 이상하다”로 남기 쉽다. 원인을 찾고 보면 대개 “정하는 곳이 둘”이다.
그래서 규칙으로 세웠다 — 어떤 값에서 파생되는 것은 그 값이 정해지는 곳에서 같이 나오게 한다. 두 곳에서 각각 계산하면 지금 맞아도 나중에 갈린다.
여럿의 기준을 가장 튀는 하나에 맞추지 않는다
빔으로 묶인 음표들의 기둥 길이를 정할 때, 처음에는 가장 바깥에 있는 음표에 빔 높이를 맞췄다. 그 하나가 크게 벗어나자 빔 전체가 끌려가 옆 영역까지 침범했다.
기준을 평균으로 옮기고 예외만 필요한 만큼 보정하니 정리됐다. 이상치에 전체를 맞추면 전체가 이상해진다는 건 배치 문제에서 반복되는 모양이다.
같은 결의 문제가 하나 더 있었다. 화면에서 ♯ 하나가 마디 밖으로 삐져나오고 쉼표가 음표와 겹친 걸 짚었는데, 둘 다 자리를 정할 때 딸려 오는 것을 안 본 탓이었다. 마디선 위치를 잡을 때 음표 앞에 붙는 임시표(accidental — 그 마디 안에서만 음을 올리고 내리는 ♯·♭·♮)의 폭을 안 봤고, 쉼표 자리를 잡을 때 같은 시각에 놓인 다른 성부(한 오선 안에서 따로 움직이는 선율)의 음표를 안 봤다. 자리를 잡을 때는 “이것 하나”가 아니라 “이것과 같이 오는 것들”을 본다.
고쳤다는 말보다 전후 그림 한 장
다섯 가지를 고쳤다는 설명을 들었는데, 화면을 봐도 뭐가 달라졌는지 알 수 없었다. 고친 뒤 화면만 봤기 때문이다.
전과 후의 같은 지점을 위아래로 붙여 놓으니 설명이 필요 없었다. 고친 사람은 어디가 바뀌었는지 알지만 보는 사람은 모른다. 눈으로 확인해야 하는 작업은 결과를 비교 가능한 형태로 내놓는 것까지가 일이다.
요약
- 보정값이 두세 개를 넘으면 값을 더 넣지 말고 기준을 의심한다
- 규격이 있는 자산을 채택하면 보정이 통째로 사라진다. 대신 라이선스를 먼저 확인한다
- 파생되는 값은 원본이 정해지는 곳에서 같이 나오게 한다. 두 곳에서 정하면 언젠가 갈린다
- 여럿의 기준은 평균에서 잡고 예외만 보정한다. 이상치에 맞추면 전체가 끌려간다
- 눈으로 확인하는 작업은 전후 비교를 내놓는 것까지가 일이다