소리꽃 KeyBloom TIL 18
공연 때 관객 화면에 파티클만 따로 띄우는 기능을 붙이며 나온 것들.
두 화면을 똑같이 만들기
결과물을 옮기지 말고 입력을 나눈다
두 번째 화면에 같은 그림을 띄우려고 처음 떠올린 건 한쪽 화면을 복사해 넘기는 것이었다. 그런데 화면 한 장이 수십 MB라 초당 수십 장을 넘기는 건 무리다.
대신 연주 정보만 넘기기로 했다. 어떤 건반이 언제 눌렸는지만 보내면 초당 몇 바이트다. 받은 쪽이 그걸로 자기가 직접 그린다.
같은 것을 두 군데서 보여 줘야 할 때 무엇을 옮길지는 선택이다. 만든 결과를 옮기면 확실하지만 무겁고, 만드는 재료를 옮기면 가볍지만 양쪽이 같은 방식으로 만든다는 보장이 있어야 한다. 재료가 결과보다 훨씬 작은 경우에는 대개 재료 쪽이 맞다.
같은 입력이 같은 결과를 내야 나눌 수 있다
재료만 넘기려면 양쪽이 같은 그림을 그려야 하는데, 파티클은 곳곳에서 무작위를 쓴다. 무작위가 섞이면 같은 연주라도 두 화면이 다르게 나온다.
그래서 무작위를 시드 난수로 바꿨다. 시드(씨앗값)를 주면 그로부터 정해진 수열이 나오는 방식이라, 시드가 같으면 같은 순서로 같은 값이 나온다. 두 화면이 같은 시드를 받으면 같은 그림이 된다.
덤도 있었다. 저장한 작업을 다시 열면 파티클이 미세하게 달라지던 것도 함께 사라졌다. 재현이 되니 저장·복원이 정확해진 것이다.
무작위를 쓰는 곳은 나중에 반드시 “왜 매번 다르지”라는 질문을 만든다. 무작위가 정말 매번 달라야 하는지, 아니면 그냥 규칙 없어 보이기만 하면 되는지를 처음에 구분해 두면 나중에 훨씬 편하다. 대부분은 후자다.
나중에 일어나는 일은 그때의 전역 상태에 기대면 안 된다
불꽃은 올라가다 나중에 터진다. 이 폭발이 그 순간의 공용 난수 상태를 쓰면, 두 화면의 처리 순서가 아주 조금만 달라도 결과가 갈린다.
그래서 폭발할 개체가 태어날 때 자기 시드를 하나 들고 있다가 터질 때 그걸로 새 난수를 만들어 쓰게 했다. 언제 터지든 몇 번째로 처리되든 같은 모양이 된다.
지연되는 일은 “그때 가서 주변을 보고 정하기”보다 “미리 정해서 들고 있기”가 안전하다. 주변은 그사이에 바뀐다.
충분한 선
더 낮출 수 있어도 충분하면 멈춘다
라이브 연주 지연을 줄이는 작업에서, ASIO(오디오 장비에 거의 직결하는 저지연 규격) 드라이버를 쓰니 12밀리초가 나왔고 버퍼를 조이니 6밀리초까지 내려갔다. 웹에서 쓰던 방식이 58밀리초였으니 열 배 가까이 좋아진 것이다.
여기서 더 내릴 수도 있었지만 멈췄다. 사람은 10밀리초 안쪽의 지연을 거의 못 느끼고, 더 조이면 소리가 끊길 위험만 커진다. 개선이 사용자에게 도달하지 않는 지점을 넘으면 그때부터는 위험만 사는 셈이다.
숫자가 계속 좋아지는 방향이 보이면 계속 가고 싶어진다. 어디까지가 사람이 느끼는 범위인지를 먼저 알아 두면 거기서 멈출 수 있다.
플랫폼에 따라 같은 기능의 값이 다르다
투명 배경 영상은 편집 프로그램이 바로 읽는 형식이 사실상 ProRes 4444(투명도까지 담는 영상 편집용 형식) 하나뿐인데, 애플 코덱이라 윈도우에서 유료 제품에 넣기가 껄끄럽다. 같은 형식이 맥에서는 운영체제에 정식으로 들어 있어서 아무 문제가 없다.
그래서 방향을 갈랐다. 윈도우는 무료 오픈소스 무손실 코덱인 Ut Video로 가고, 맥 버전을 내면 그쪽은 정식 ProRes를 쓴다. 맥 버전을 만들려면 코드는 그대로 쓰되 빌드와 노터라이즈(애플이 앱을 검사·인증하는 절차)는 맥에서 해야 한다는 것도 이때 알았다.
같은 기능이라도 플랫폼마다 비용과 제약이 다르다. “이 기능을 넣을 수 있나”가 아니라 “어느 플랫폼에서 얼마에 넣을 수 있나”로 물어야 계획이 선다.
사용자가 주는 것
우리가 기대하는 전제는 사용자에게 안내해야 한다
파티클 모양을 사용자 이미지로 바꿀 수 있게 했다. 모양만 가져오고 색은 앱 설정을 따르게 만들었는데, 시험해 보니 이미지가 아니라 색칠된 네모가 나왔다.
배경이 투명한 이미지를 전제로 만든 기능이었다. 배경이 불투명하면 사각형 전체가 “모양”이라 네모가 된다.
사용자가 파일을 올리는 기능에는 늘 이런 전제가 붙는다. 전제를 코드가 지킬 수 없으면 화면에서 알려 줘야 한다. 알려 주지 않으면 사용자는 자기가 뭘 잘못했는지 모른 채 기능이 고장 났다고 판단한다.
포커스는 마지막 만진 곳에 남는다
슬라이더를 조절한 뒤 숫자키나 스페이스가 안 먹혔다. 단축키가 입력칸에 포커스가 있으면 무시하도록 돼 있는데, 슬라이더를 만지면 포커스가 거기 남아서다.
조작을 마친 시점에 포커스를 놓아 주게 고쳤다. 화면에 조작 도구와 단축키가 함께 있으면 반드시 부딪히는 지점이라, 단축키를 붙일 때 같이 확인할 목록에 넣어 뒀다.
요약
- 같은 것을 두 곳에 보여 줄 때, 재료가 결과보다 훨씬 작으면 재료를 옮긴다
- 무작위는 정말 매번 달라야 하는지 처음에 구분한다 — 대개는 규칙 없어 보이기만 하면 된다
- 지연되는 일은 그때 주변을 보고 정하지 말고 미리 정해 들고 있는다
- 사람이 못 느끼는 지점을 넘으면 개선이 아니라 위험을 사는 것이다
- 같은 기능도 플랫폼마다 비용이 다르다 — “넣을 수 있나”가 아니라 “어디서 얼마에”로 묻는다
- 사용자가 파일을 올리는 기능에는 전제가 붙는다. 코드가 못 지키면 화면에서 알린다