십억(B, billion)이라는 말을 일상적으로 하게 된 유전체 분야

유전체 분야에서는 billion(십억, 10⁹, SI 접두어로는 giga)과 peta('천조', 10¹⁵)가 낯설지 않은 단위다. 인간 유전체 한 세트가 약 3 빌리언 염기쌍이고, 대규모 유전체 데이터 저장소와 국가 단위 데이터 생산량은 이제 페타바이트(PB) 규모로 이야기된다. 유전체학은 생명과학 가운데 거대한 수의 단위를 일상적으로 사용하는 대표적인 분야다.

정확히 따지자면 기가와 페타는 무려 1백만 배의 차이가 난다. 중간에 '테라'(1조, 10¹²)가 놓인다.

다음의 사진은 내가 (주)제노텍에 근무하던 시절 촬영한 DNA 시퀀싱 룸의 모습이다. 아마 2002년쯤이 아니었나 생각된다. 당시 제노텍은 국내에서 모든 연구소와 기업을 통틀어서 가장 많은 대용량 시퀀싱 장비 (ABI Prism 3700 Genetic Analyzer 다섯 대)를 보유한 곳이기도 했다. 경쟁 제품으로는 MegaBACE와 RISA-384가 있었던 것으로 기억한다. 당시에는 오늘날의 일루미나 장비에서 보이는 flow cell이라는 개념도 없었고, 96-well plate 단위로 모든 처리가 이루어졌다.

ABI Prism 3700. 기계장치가 많아서 종종 말썽을 일으키고는 했다.

일루미나의 NovaSeq X 시리즈에 들어가는 25B flow cell에서는 single-end read로 환산하여 약 26-35 '빌리언' 리드(read)를 생산한다. 2 × 150 bp로 맞추었을 때 생산되는 분량은 약 8-10.5 Tb(테라베이스)이다. ChatGPT에게 물어보니 30× human genome whole genome sequencing(WGS)의 경우 플로우 셀 하나에서 약 64명 분량을 처리할 수 있다. 다음 사진은 마크로젠 송도글로벌지놈센터를 방문했을 때 얻어 온 25B 플로우 셀이다. 물론 시퀀싱이 다 끝난 뒤 폐기를 기다리던 것이다. 이거 하나의 가격이 얼마라고 했더라? 시약을 포함한 한 세트의 가격은 list price로서 16,000달러라고 한다.

이처럼 현대적인 DNA 시퀀싱 장비는 실험실이 아니라 첨단 반도체 제조 공장에 어울릴 모습을 하고 있다. 다음 사진에는 약 25년 전, 그러니까 거의 한 세대 전에 '대규모 시퀀싱 센터'에서 일상적으로 하던 일이 담겨 있다. 엄밀하게 말하면 이 사진은 DNA 시퀀싱 장비에 들어갈 template DNA를 뽑는 단계만을 소개하였다. PCR 머신에서 'BigDye'를 이용한 시퀀싱 반응을 하고, 반응물을 정제하는 등 몇 번의 단계를 더 거쳐야 비로소 ABI 3700에 로드할 수 있는 상태가 되었다. Capillary를 잘못 관리하여 마르게 하면? 누군가에게 혼난다!

한때 직장 동료였던 차선호 박사님의 젊을 때 모습.

Ultima Genomics라는 회사에서는 산업계에서 실제로 사용하는 원형 실리콘 웨이퍼를 sequencing surface로 이용한다. 다음은 Ultima Genomics의 장비에서 실제로 쓰이는 6인치 웨이퍼의 실물과 일루미나 25B 플로우 셀을 같이 놓고 촬영해 보았다.

웨이퍼 표면은 마치 거울과 같아서 천장에 설치한 에어컨이 그대로 보인다.

기술이 발전하면서 시퀀싱 장비 내에서는 움직이는 부품이 줄어들고 따라서 유지보수도 쉬워졌을 것이다. 마치 레이저 프린터의 토너를 교체하듯이 쉽게 수리가 이루어진다. 그러나 이것은 고객의 입장에서 그렇다는 것이고, 많은 비용이 드는 것은 어쩔 수 없다. 즉, 대규모 시퀀싱 장비가 등장하면서 고가의 유지보수 계약이 유전체 정보 생산비의 일상적인 일이 된 것이다.

25년 전에는 96개의 capillary를 동시에 돌리는 ABI 3700 다섯 대를 놓고도 '대규모 시퀀싱 센터'라고 불렀다. 이제는 손바닥만 한 플로우 셀 하나에서 수십 빌리언 개의 read와 수조 개의 염기가 쏟아진다. 한때 megabase가 큰 숫자였고 gigabase가 놀라운 숫자였지만, 이제 우리는 billion을 일상적으로 말하고 국가 단위의 데이터는 petabyte로 센다. 지난 한 세대 동안 유전체학에서 커진 것은 데이터의 양만이 아니라, 우리가 '크다'고 느끼는 숫자의 기준 자체였는지도 모른다.

4년 만에 해결한 iCON iKeyboard 5 NANO의 Code 10 오류 — 답은 이미 2020년에 있었다

2022년 9월, ThinkPad E14 Gen3를 구입한 뒤 이해하기 어려운 문제 하나를 만났다. 오래 사용하던 USB MIDI 키보드 컨트롤러인 iCON iKeyboard 5 NANO가 도무지 제대로 인식되지 않는 것이었다.

당시의 '삽질'은 다음 글에 기록해 두었다.

OneDrive 생태계의 일원이 되어 보기로 하다 - 조직 이름 바꾸기에는 성공하였지만... 그리고 iCON MIDI 키보드 인식 문제!

장치 관리자에 나타난 메시지는 다음과 같았다.

This device cannot start. (Code 10)

Insufficient system resources exist to complete the API.

처음에는 Windows 11의 문제라고 생각했다. Windows를 다시 설치해 보기도 하고 나중에는 Windows 10으로 내려서 시험하기도 했지만 문제는 해결되지 않았다. 더 이상했던 것은 같은 iKeyboard 5 NANO가 다른 환경에서는 작동한다는 점이었다. Linux에서는 정상적으로 인식되었고 FluidSynth를 이용한 연주도 가능했다. 예전 Windows 컴퓨터에서도 작동한 적이 있었다.

그러니 장치가 완전히 고장 난 것도 아니었다. 그렇다고 ThinkPad의 USB 자체가 망가진 것도 아니었다. 몇 년 뒤 구입한 iCON iKeyboard 8 Nano는 바로 그 ThinkPad에 연결해도 정상적으로 작동했다.

대체 무엇이 문제였을까?

2026년, 다시 시작한 삽질

2026년 8월 마지막 날, 이 문제를 다시 파보기로 했다. 이번에는 장치 관리자에서 노란 느낌표를 바라보는 수준에서 그치지 않고, Windows의 USB ETW(Event Tracing for Windows)를 이용하여 USB stack의 어느 단계에서 장치 초기화가 실패하는지를 추적했다.

문제가 발생하던 iKeyboard 5 NANO의 firmware는 V1.05였다. V1.05 장치를 ThinkPad에 연결하면 USB device descriptor와 configuration descriptor는 정상적으로 읽혔다. Windows UCX(USB Host Controller Extension)도 MIDI endpoint를 생성하려 했다.

문제는 그 다음 단계였다.

USB descriptor read
        ↓
UCX endpoint creation
        ↓
xHCI Configure Endpoint Command
        ↓
Completion Code 17: Parameter Error
        ↓
endpoint deletion and retry
        ↓
USB Composite Device start failure
        ↓
Code 10

즉 드라이버 파일이 없거나 잘못 설치된 문제가 아니었다. iKeyboard 5 NANO는 USB class-compliant 장치이고, Windows에서는 Microsoft의 표준 USB composite driver가 정상적으로 선택되고 있었다. 문제는 훨씬 아래쪽, USB host controller가 endpoint를 실제로 구성하는 단계에서 발생하고 있었다.

수상한 숫자 하나: 4

USB descriptor를 자세히 비교하다가 흥미로운 차이를 발견했다. iKeyboard 5 NANO V1.05의 MIDI OUT bulk endpoint descriptor는 다음과 같았다.

09 05 02 02 04 00 00
            ^^
       wMaxPacketSize = 4

반면 같은 ThinkPad에서 정상 작동하는 iKeyboard 8 Nano V1.06의 MIDI OUT endpoint는 wMaxPacketSize = 8이었다.

USB-MIDI 1.0의 MIDI Event Packet 자체는 4 byte이므로 wMaxPacketSize=4라는 값이 얼핏 보아 터무니없는 것은 아니다. 실제로 Linux와 일부 Windows 컴퓨터는 이 설정을 받아들였고 장치도 정상 작동했다. 그러나 문제의 ThinkPad에서는 이 endpoint를 xHCI controller에 설정하는 과정에서 Parameter Error가 발생했다.

펌웨어를 직접 고쳐야 하나?

공식 iKeyboard 5 NANO V1.05 firmware binary도 열어 보았다. 그 안에서 실제 USB endpoint descriptor를 그대로 찾을 수 있었다.

V1.05 @ 0x4044

09 05 02 02 04 00 00
            ^^

04를 08로 바꾼 실험용 firmware까지 만들어 두었다. 하지만 firmware를 직접 수정해서 장치에 쓰는 것은 이야기가 다르다. 잘못하면 멀쩡한 MIDI keyboard를 '벽돌'로 만들 수도 있다. 그래서 실제 flashing은 하지 않고 조금 더 조사하기로 했다.

그 판단은 옳았다.

그런데 V1.06 Beta가 있었다

iCON의 현재 firmware update 프로그램을 다시 살펴보다가 뜻밖의 항목을 발견했다.

iKeyboard 5Nano v1.05
iKeyboard 5Nano v1.06 (Beta)

내가 오랫동안 마지막 firmware라고 알고 있던 것은 V1.05였다. 제품 지원 페이지에서도 V1.05가 눈에 띄었기 때문에 그 이후 버전이 존재한다는 사실을 알지 못했다. 그러나 firmware updater가 읽어 오는 서버의 firmware.xml에는 V1.05와 함께 V1.06 (Beta)가 등록되어 있었다.

사무실의 정상 작동하는 PC에서 5 NANO를 V1.06 Beta로 업데이트했다. 그 뒤 문제의 ThinkPad에 다시 연결했다.

정상 작동했다.

USB Composite Device
Status  : OK
Problem : CM_PROB_NONE

iCON iKeyboard 5 Nano V1.06
Status  : OK
Problem : CM_PROB_NONE

같은 iKeyboard 5 NANO, 같은 ThinkPad E14 Gen3, 같은 Windows, 같은 USB hub였다.

바뀐 것은 firmware뿐이었다.

V1.05  → Code 10
V1.06  → 정상 작동

2022년에 처음 기록했던 문제가 4년 만에 해결되었다. 어이가 없네!

그리고 정말 4가 8로 바뀌어 있었다

V1.06을 설치한 뒤 Microsoft USBView를 이용하여 5 NANO의 USB descriptor를 다시 확인했다.

                         V1.05     V1.06 Beta
------------------------------------------------
MIDI IN  wMaxPacketSize     8          8
MIDI OUT wMaxPacketSize     4          8

공식 V1.06 Beta firmware binary도 직접 내려받아 조사했다.

V1.06에서는 firmware 내부 구조가 달라져 descriptor의 위치가 이동해 있었지만, 동일한 MIDI OUT endpoint descriptor를 찾아 비교해 보니 다음과 같았다.

V1.05 @ 0x4044
09 05 02 02 04 00 00

V1.06 @ 0x420C
09 05 02 02 08 00 00

더 흥미로운 점은 이 부분 앞뒤의 USB MIDI descriptor가 거의 동일하다는 것이다.

즉 내가 V1.05 실험용 firmware에서 바꾸려고 했던 바로 그 값, MIDI OUT endpoint의 wMaxPacketSize 4 → 8 변경이 공식 V1.06에도 실제로 들어 있었다.

물론 V1.05와 V1.06 사이에는 다른 firmware 변경도 존재할 수 있다. 따라서 이 한 바이트 변경만이 유일한 해결 원인이었다고 단정할 수는 없다. 그러나 다음 세 가지 사실은 서로 매우 잘 맞아떨어진다.

• V1.05에서는 xHCI Configure Endpoint 명령이 Parameter Error로 실패한다.
• V1.06에서는 같은 ThinkPad에서 장치가 정상적으로 시작된다.
• V1.06에서는 MIDI OUT endpoint의 wMaxPacketSize가 4에서 8로 변경되었다.

따라서 이 값의 변경이 USB host controller 호환성 문제 해결과 직접 관련되어 있을 가능성은 매우 높다고 생각한다.

그런데 왜 V1.05도 어떤 컴퓨터에서는 잘 작동했을까?

이것이 이 문제에서 가장 흥미로운 부분이다.

wMaxPacketSize=4가 USB 규격상 완전히 잘못된 값이었다면 모든 컴퓨터에서 실패했어야 한다. 실제로는 그렇지 않았다. V1.05는 Linux에서 작동했고, 다른 Windows PC에서도 작동했다. 이번 조사에서도 Intel USB controller를 사용하는 사무실 PC에서는 같은 V1.05 장치가 아무 문제 없이 인식되었다.

따라서 V1.05를 단순히 '고장 난 firmware'라고 부르는 것보다는 특정 USB host controller와의 compatibility problem을 가진 firmware라고 표현하는 것이 더 적절할 것 같다.

어떤 USB host/controller stack에서는 OUT endpoint의 wMaxPacketSize=4를 받아들였지만, 내 ThinkPad의 AMD xHCI 환경에서는 endpoint configuration 단계에서 이를 받아들이지 않고 Parameter Error를 반환했다. V1.06에서 이 값이 8로 변경되자 같은 ThinkPad에서도 정상 작동했다.

결국 이것은 단순한 Windows 11 문제도, MIDI driver 문제도, 하드웨어 고장도 아니었다.

오래된 device firmware와 특정 USB host controller 구현 사이의 호환성 문제였던 것으로 보인다.

그런데 답은 2020년부터 서버에 있었다

마지막으로 V1.06 Beta firmware가 언제부터 존재했는지도 궁금해졌다.

iCON firmware distribution server에서 현재 제공되는 iKeyboard_5Nano_V1.06.bin의 HTTP header를 확인해 보았다.

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 19376

Last-Modified: Mon, 27 Apr 2020 08:18:30 GMT
ETag: "b61ed912b107fc7af1a8de0873a6c2d2"

현재 제공되는 V1.06 Beta 객체의 Last-Modified timestamp는 2020년 4월 27일이었다. 물론 이것을 V1.06의 공식 발표일이라고 단정할 수는 없다. 해당 객체가 그날 재업로드된 것일 가능성도 있기 때문이다. 정확하게 표현하면, 현재 서버에서 배포되는 V1.06 Beta binary의 S3 객체 수정 시각이 2020년 4월 27일이다.

어쨌든 내가 이 문제를 처음 블로그에 기록한 것은 2022년이었다. 내가 문제를 기록하기 전부터 해결 firmware가 서버에 있었을 가능성이 매우 높은 셈이다. 그런데 일반적인 제품 지원 페이지에서는 V1.05만 눈에 띄었고, V1.06 Beta는 firmware updater가 읽어 오는 목록 속에 조용히 들어 있었다.

이걸 지금까지 몰랐다니.

기록을 위한 V1.06 Beta 정보

다운로드 URL은 언젠가 바뀌거나 사라질 수 있다. 따라서 URL뿐 아니라 파일의 식별 정보를 함께 남겨 둔다.

Product:
iCON iKeyboard 5 NANO

Firmware:
V1.06 (Beta)

Filename:
iKeyboard_5Nano_V1.06.bin

File size:
19,376 bytes

SHA-256:
7F4423D2EB2FBCF47584DAB4AF07B97968EA3A5AF7C74D56ADB89C510F2E96A9

Current firmware feed:
https://d2ff5pmy2hzqo1.cloudfront.net/firmware.xml

Current binary URL:
https://d2ff5pmy2hzqo1.cloudfront.net/iKeyboard_5Nano_V1.06.bin

S3/CloudFront Last-Modified:
2020-04-27 08:18:30 GMT

BIN 파일 자체도 별도로 보관해 두었다. URL은 언제든 바뀔 수 있지만 SHA-256 값은 나중에 파일의 동일성을 확인할 수 있는 좋은 기록이 된다.

또 한 가지 주의할 점이 있다. 예전에 배포된 firmware update 설명서에서는 사용자가 로컬의 .bin 파일을 직접 지정하는 방식이 소개되어 있었지만, 현재 사용한 iMap의 firmware update 인터페이스는 그 설명서와 달랐다.

현재 프로그램은 서버의 firmware.xml을 읽어 해당 장치에 사용 가능한 firmware version을 목록으로 제시하고, 사용자가 그중 하나를 선택하는 방식으로 보인다.

따라서 미래에 iCON의 firmware server가 없어졌을 때 보관해 둔 BIN 파일만으로 쉽게 복구할 수 있는지는 아직 확인하지 못했다.

결론

돌고 돌아 결론은 놀라울 정도로 간단했다.

고장 난 MIDI keyboard가 아니었다.
Windows 11만의 문제도 아니었다.
해결책은 공식 V1.06 Beta firmware였다.

그리고 현재 서버에서 배포되는 그 firmware의 timestamp는 내가 이 문제를 처음 기록하기도 전인 2020년이었다. 2022년에 시작한 문제를 2026년에야 해결했다. 그 과정에서 Windows USB stack의 ETW trace를 뜨고, xHCI Configure Endpoint command의 실패까지 추적하고, firmware binary에서 USB endpoint descriptor를 직접 찾아 비교하게 될 줄은 몰랐다.

처음에는 단순히 낡은 MIDI keyboard 하나가 작동하지 않는 문제였다.

그런데 끝까지 파고 들어가니 USB descriptor, host controller compatibility, firmware binary와 CloudFront의 오래된 파일까지 이어지는 작은 디지털 고고학이 되어 버렸다.

이래서 오래된 디지털 기기를 쉽게 버리면 안 된다. 가끔은 기계보다 해결책을 찾아내는 사람이 더 늦게 업데이트된다.

아직 남은 약간의 찜찜함

문제는 해결되었지만 한 가지는 아직 깔끔하게 설명되지 않는다.

사무실 PC에서 iMap V1.18을 이용하여 firmware update mode로 들어가면 iCON firmware upgrade v1.00이라는 장치가 정상적으로 나타나고, 그 다음 단계에서 firmware version을 선택하여 업데이트를 진행할 수 있었다.

그런데 같은 5 NANO를 ThinkPad에서 firmware update mode로 전환해 보니 해당 단계의 장치 목록이 비어 있었다. 현재 설치된 V1.06 Beta에서는 5 NANO 자체가 ThinkPad에서 정상적으로 작동하는데도 firmware update 과정에서는 다시 PC에 따른 차이가 나타난 셈이다.

이 현상의 원인은 더 이상 추적하지 않았다. Firmware update mode에서는 일반 동작 때와 다른 bootloader 또는 USB/MIDI configuration을 사용할 가능성이 있고, 그것이 ThinkPad의 USB 환경과 또 다른 호환성 문제를 일으키는 것일 수도 있다. 그러나 이것은 확인된 사실이 아니라 추측이다.

따라서 이번 조사에서 확실하게 말할 수 있는 것은 여기까지다. V1.05에서는 특정 host controller 환경에서 USB endpoint configuration이 실패했고, 공식 V1.06 Beta로 업데이트한 뒤에는 같은 ThinkPad에서 정상적으로 사용할 수 있게 되었다.

다만 이 오래된 장치의 USB 구현에는 host controller에 따라 행동이 달라지는 부분이 적어도 하나 더 남아 있는 듯하다.

어차피 이 모델에 새로운 firmware가 다시 나올 가능성은 매우 낮다. V1.06 Beta로 정상 작동하는 지금, 여기서 더 파고들 이유도 별로 없다. 해결은 되었지만 모든 의문이 해결된 것은 아니다. 그 정도의 찜찜함은 기록으로 남겨 두기로 한다.

Pattern Lab의 놀라운 진화

"Drum Patternology" 연구의 초기에는 이미 드럼 패턴 정보만 담고 있는 MIDI 파일을 작업 대상으로 했었다. 따라서 실제 곡 안에서 각 패턴이 어떤 관계에 있는지 분석하기는 어려웠다. 최근 들어 잘 알려진 팝송을 MIDI로 전환한 자료 뭉치를 분석하게 되면서 미처 생각하지 못했던 많은 것을 알게 되었다. 특히 '하나의 패턴은 두 마디'라는 원칙을 깨고 한 마디로 분석 단위를 낮추면서 하나의 곡 안에서 패턴이 어떻게 재사용되고 또 변형되는지를 보다 확실하게 파악할 수 있었다.

얼핏 생각하면 모든 패턴을 한 마디 단위로 잘게 잘라 놓을수록 그루브와 fill/break 사이의 문맥은 잃어버릴 것처럼 보인다. 그러나 더욱 진화한 PatternLab에서는 잘라낸 패턴을 다시 원곡의 시간 순서에 놓고 인접 관계를 분석하여 pattern transition graph를 생성한다. 분석 단위를 짧게 만든 대신, 패턴 사이의 관계를 별도의 층위에서 복원한 것이다.

앞으로 여러 곡의 transition 정보를 축적한다면, ARR 파일에서 패턴 체인을 만들 때 현재 선택한 패턴 뒤에 어떤 groove, fill 또는 break가 실제 음악에서 자주 이어졌는지를 확률적으로 제시하는 근거로 사용할 수도 있을 것이다. 물론 이것은 알려진 하나의 곡에서 나온 데이터일 뿐이다. 여러 곡을 거쳐서 분석하면 어떤 결과가 나올까? 실제로 여러 곡을 거쳐서 공통적으로 쓰이는 패턴은 현재까지의 연구에 의하면 그렇게 많은 것 같지 않다. 그리고 현실의 MIDI 파일 안에 들어 있는 노트  중 off-grid 상태인 것이 너무 많기 때문에 제대로 된 분석을 거치려면 보정을 거쳐야 한다. 

처음에는 원본 MIDI 파일의 타이밍을 인위적으로 보정하지 않은 상태에서 분석하려 했다. 그러나 현실의 MIDI 데이터는 그렇게 완벽하지 않았다. 미세한 off-grid가 서로 다른 패턴으로 인식되어 불필요한 long tail을 만들어 냈기 때문이다. 결국 원본은 그대로 보존하되, 일정한 허용 범위 안의 타격을 nearest grid로 옮긴 보정본을 별도로 만들어 분석하는 절차를 도입하였다.

그나마 다행스러운 것은 현재까지 만들어진 재생 시스템은 대대적인 수정을 거치지 않아도 1-bar 패턴을 수용할 수 있다. ADT/ADP v2.3이 매우 유연하고 개방적으로 설계된 때문일까. 

킴 칸스의 <Bette Davis Eyes> 분석 결과.

위 그림의 오른쪽에서 보인 그래프는 웹 브라우저 안에서 마우스로 각 노드를 움직일 수 있는 동적 그래프이다. 게다가 이 그래프는 SVG 파일로 출력할 수도 있다. 뿐만 아니라 condensed bar sequence(왼쪽)나 그래프 어느 것이든 해당 패턴을 클릭하면 재생이 이루어진다.

이어지는 분석 리포트에서는 패턴을 그루브 별로 그룹지어 보여준다. 예를 들어 반복하여 쓰이는 그루브와, 그 그루브의 모든 타격을 그대로 유지하면서 첫 박에 crash 하나만 추가된 패턴이 있다면 두 패턴은 별개의 패턴 ID를 갖게 된다. 그러나 음악적으로 이 둘을 완전히 독립적인 패턴으로 취급하는 것이 과연 합리적일까? 나는 첫 박의 crash가 기존 패턴 위에 부가적으로 얹힌 경우 이를 leading crash ornament로 보고 ORN의 일종으로 취급하려 한다. 원래 ORN은 특정 패턴에만 부속하여 타이밍 보정이나 flam 처리를 위한 것으로 정의하였다. 하지만 leading crash 같은 것은 다른 여러 패턴과 결합하여 사용할 수 있다. 그렇다면 ARR 파일에서 패턴의 레이어링도 허용하는 것이 옳다. 즉 ORN이 더 이상 특정 패턴에 종속된 부가 정보만을 의미하지 않고, 여러 core pattern 위에 재사용할 수 있는 독립적인 modifier vocabulary가 될 가능성이 생긴 것이다.

실은 오랜만에 BFD Player를 열어 보고서 '내가 지금 무슨 하찮은 일을 하고 있는 것인가'하고 한심하게 생각하고 있던 터였다. 상업적으로 만들어진 거대한 드럼 소프트웨어와 내가 취미로 만드는 시스템을 나란히 놓고 보면 당연히 그런 생각이 든다.

어제 업데이트한 BFD Player.

그러나 곰곰이 생각해 보면 내가 추구하는 것은 BFD와 경쟁하는 드럼 소프트웨어를 만드는 일이 아니다. 이미 존재하는 MIDI 음악에서 반복되는 리듬의 어휘를 찾아내고, 그것이 한 곡 안에서 어떻게 변형되고 연결되는지를 분석하여 다시 사용할 수 있는 형태로 만드는 것이 Drum Patternology의 관심사다. 목적이 다르다.

그러니 지나치게 실망할 일은 아니다. BFD가 좋은 드럼 연주를 제공한다면, Drum Patternology는 드럼 연주가 어떻게 조직되어 있는지를 알고 싶어 한다.

디지털 유산의 복원 — 내가 운영하는 깃허브 리포지토리가 6개로 늘어나다

새로 만들어진 sc-d70-win11-driver

'롤랜드 사운드캔버스 SC-D70을 Windows 11에서 제대로 쓸 수 없을까'라는 호기심을 충족하기 위해 약 이틀에 걸친 실험 끝에 성공에 이른 기록을 여섯 번째 리포지토리(sc-d70-win11-driver)에 남겼다. 이 작은 성취에 대해 여러 가지 의미를 부여할 수 있겠다. 무엇보다도 핵심은 드라이버 자체를 전혀 고치지 않았다는 것이다. 내가 그런 깊숙한 곳까지 건드릴 정도의 개발자는 되지 못한다. Vista x64 시절에 작성된 드라이버가 기능적으로 Windows 11과 근본적으로 맞지 않는다거나 하는 등의 문제는 없었다. 단지 Windows 11이 이 '낡은' 코드를 문 앞에서 거절하는 이유를 찾아내고 통과할 수 있도록 신뢰·서명·패키징 조건을 다시 만들어 준 것에 가깝다.

 “바이너리는 아직 기능한다. 최신 OS가 그것을 신뢰하지 않을 뿐이다”

Windows 11에서 나의 SC-D70은 USB 오디오 기기, MIDI 기기로서 정상적으로 동작할 뿐만 아니라 ASIO 검증도 통과하였다. 비록 샘플링 레이트는 48kHz를 넘지 못하지만, 2026년에도 충분히 실용적인 음악 장비임을 보여주었다. UEFI BIOS에서 Secure Boot를 끄고 'bcdedit /set testsigning on' 명령으로 Test Signing을 활성화했으니 Windows의 기본 보안 상태를 약간 낮추었지만, 필요 이상으로 보안을 해제하지 않았다. 즉, 다음의 세 가지 중요한 요소를 모두 만족하고 있다는 것이다.

• 원래 드라이버 코드는 고치지 않았다.
• Windows의 보안 메커니즘을 패치하거나 제거하지 않았다.
• 필요한 범위에서 Windows가 제공하는 테스트 신뢰 체계를 이용했다.

요즘 내가 필요 이상으로 몰두하고 있는 Ardule Drum Patternology와 SC-D70의 Windows 11 드라이버 실험은 얼핏 보기에 관련이 별로 없다. 하나는 오래된 MIDI 파일에서 드럼 패턴을 찾아내 분석하고 추상화하여 다시 사용할 수 있는 형태로 만드는 일이고, 다른 하나는 2000년대 초에 발매된 MIDI 음원 모듈을 최신 운영체제에서 작동하게 만드는 것이다.

그러나 두 작업을 아우르는 공통된 주제는 바로 디지털 유산의 복원(digital heritage restoration)이라고 생각한다. 옛것을 현대적으로 뜯어고치는 것이 아니라, 그 속에 남아있던 생명력을 확인하는 일에 더욱 가깝다. 

디지털 유산의 복원이란 작동하지 않게 된 옛것을 박물관에 전시하거나 수장고에 넣어두는 것이 아니다. 과거의 데이터와 코드가 오늘날에도 다시 의미를 갖고 작동할 수 있도록 그 연결고리를 다시 만들어 나가는 것도 중요한 보존의 방식이다. 낯선 드라이버 서명 체계를 이해하고 실험 절차를 세우거나, 수많은 MIDI 데이터를 분석할 도구를 만드는 과정에서 인공지능은 중요한 조력자가 되었다

새로운 것을 만드는 일도 중요하다. 그러나 사라질 뻔한 것들 속에서 아직 살아 있는 것을 찾아내고, 그것이 다시 움직일 수 있도록 연결해 주는 일도 그에 못지않게 흥미롭다. 그것이 내가 요즘 몰두하고 있는 일이다.

Not planned, just happened.

And only afterward did I realize that I had been restoring digital heritage all along.

Old digital soldiers never die. They just wait to be rediscovered.

Roland SC-D70을 Windows 11에서 다시 살려 보다 (2) — 2007년 드라이버를 2026년에 다시 서명하다

Windows 11 시대에 다시 살아난 롤랜드 사운드캔버스 SC-D70. ChatGPT와 함께 몇 시간 동안 시행착오를 거친 끝에 얻은 결과다.

앞 글에서는 2007년에 배포된 Roland SC-D70용 Windows Vista x64 드라이버가 Windows 11에서도 실제로 동작한다는 것을 확인하였다. Windows의 Driver Signature Enforcement를 일시적으로 해제하고 부팅하면 SC-D70이 정상적으로 인식되었고, MIDI PART A와 PART B는 물론 USB Audio 입출력까지 모두 사용할 수 있었다. 처음에는 Memory Integrity도 꺼야 하는 것으로 생각했으나, 다시 켜고 시험해 보니 그것 역시 문제가 되지 않았다. 결국 드라이버의 기능이나 Windows 11과의 실질적인 호환성보다는 오래된 드라이버의 서명이 현재 Windows의 요구 조건을 충족하지 못하는 것이 문제의 핵심인 것으로 보였다.

그렇다면 다음 실험은 자연스럽게 정해진다. 이 오래된 드라이버를 현대적인 방법으로 다시 서명하면 어떻게 될까? 물론 Roland의 소스 코드를 가지고 있는 것도 아니고 새로운 Windows 11용 드라이버를 작성할 생각도 없다. 여기서 말하는 '새 드라이버'란 기존의 2007년 드라이버 바이너리를 그대로 사용하되, 현재의 Windows Driver Kit(WDK)를 이용하여 새로운 catalog를 만들고 자체적인 테스트 인증서로 다시 서명한 드라이버 패키지를 뜻한다. 이것이 성공한다면 적어도 Windows가 제공하는 test-signing 환경에서는 매번 Driver Signature Enforcement를 일시적으로 해제하지 않고도 SC-D70을 사용할 수 있을 것이다.

19년 된 드라이버를 최신 WDK에 넣어 보다

먼저 Microsoft의 Windows SDK와 WDK를 설치하였다. 이번에 사용한 도구의 버전은 10.0.28000.0이었다. 원본 SC-D70 Vista x64 드라이버는 별도의 작업 디렉터리로 복사하였다. 여기에는 RDIF1012.INF, RDWM1012.SYS, RDID1012.CAT를 비롯하여 제어판과 오디오 기능에 필요한 DLL과 DAT 파일들이 들어 있다. 당연히 원본 파일은 별도로 보존하였다.

가장 먼저 해 본 것은 현재 WDK의 Inf2Cat이 2007년에 만들어진 이 드라이버 패키지를 받아들이는지 확인하는 일이었다. 기존 RDID1012.CAT 파일의 이름을 바꾸어 보관한 뒤 다음과 같이 새로운 catalog를 생성하였다.

& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.28000.0\x86\Inf2Cat.exe" `
  /driver:"C:\projects\SC-D70_Win11-TestSigned" `
  /os:10_X64

결과는 의외로 깨끗했다.

Signability test complete.

Errors:
None

Warnings:
None

Catalog generation complete.

2007년의 INF 파일을 특별히 수정하지 않았는데도 현재의 Inf2Cat이 오류나 경고 하나 없이 catalog를 만들어 주었다. 이것만으로 Windows 11에서 정상적으로 사용할 수 있다는 뜻은 아니지만, 적어도 드라이버 패키지의 기본 구조가 현대 WDK에서 거부될 정도로 낡은 것은 아니었다.

테스트 인증서를 만들고 드라이버에 서명하다

다음으로 PowerShell의 New-SelfSignedCertificate를 이용하여 코드 서명용 자체 인증서를 만들었다. 인증서 이름은 단순하게 'SC-D70 Win11 Test Driver'라고 하였다. SHA-256을 사용하였으며, 만들어진 인증서는 Local Machine의 인증서 저장소에 넣고 Trusted Root Certification Authorities와 Trusted Publishers에도 등록하였다. 이것은 어디까지나 개인적인 실험을 위한 test certificate이며 Microsoft나 Roland가 인증한 서명이 아니다.

$cert = New-SelfSignedCertificate `
  -Type CodeSigningCert `
  -Subject "CN=SC-D70 Win11 Test Driver" `
  -CertStoreLocation "Cert:\LocalMachine\My" `
  -HashAlgorithm SHA256

여기에서 한 가지 흥미로운 사실을 확인하였다. SignTool로 RDWM1012.SYS를 조사해 보니 이 파일 자체에는 embedded signature가 없었다. 원래의 드라이버 패키지는 catalog의 서명에 의존했던 것으로 보인다. 이번 실험에서는 Memory Integrity를 켠 상태에서도 사용할 수 있는지 확인하고 싶었으므로 SYS 파일 자체에도 테스트 서명을 추가하기로 하였다.

$SignTool = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.28000.0\x64\signtool.exe"

& $SignTool sign /v /fd SHA256 `
  /s My /sm `
  /sha1 $cert.Thumbprint `
  .\RDWM1012.SYS

여기에서는 작업 순서가 중요하다. SYS에 embedded signature를 추가하면 파일 자체가 달라지므로 그 전에 만들어 놓은 catalog에 기록된 해시도 더 이상 맞지 않는다. 따라서 SYS를 먼저 서명하고, 그 상태에서 Inf2Cat을 다시 실행하여 RDID1012.CAT를 새로 만들었다. 마지막으로 이 catalog에도 같은 테스트 인증서로 SHA-256 서명을 하였다.

& $SignTool sign /v /fd SHA256 `
  /s My /sm `
  /sha1 $cert.Thumbprint `
  .\RDID1012.CAT

SignTool의 /pa 옵션으로 SYS와 CAT를 각각 검증한 결과 두 파일 모두 오류 없이 검증되었다. 이로써 원본 드라이버의 코드는 그대로 두면서 2026년에 만든 SHA-256 test signature를 가진 새로운 SC-D70 드라이버 패키지가 만들어졌다. 엄밀히 말하면 새로운 드라이버를 개발한 것은 아니다. 2007년의 드라이버를 현재의 Windows 개발 환경에 맞추어 다시 패키징하고 test-signing한 것이다.

Windows 11을 Test Mode로 부팅하다

이제 실제로 Windows가 이 패키지를 받아들이는지 확인할 차례였다. 여기에는 중요한 대가가 하나 있다. Microsoft가 정식으로 서명한 production driver가 아니므로 Windows의 Test Signing 기능을 사용해야 하고, 이를 위해 이 컴퓨터에서는 UEFI의 Secure Boot를 꺼야 했다. BitLocker가 활성화되어 있다면 UEFI 설정을 변경하기 전에 복구 키 등의 문제를 먼저 확인해야 한다. 내가 실험한 PC의 C: 드라이브에는 BitLocker가 설정되어 있지 않았다.

Secure Boot를 끈 뒤 Windows에서 다음 명령으로 상태가 False임을 확인하였다.

Confirm-SecureBootUEFI

그 다음 관리자 권한의 PowerShell에서 Test Signing을 활성화하였다.

bcdedit /set testsigning on

평범하게 재부팅하자 Windows 11 바탕화면 오른쪽 아래에 Test Mode라는 표시가 나타났다. 이것은 오류 메시지가 아니다. 현재 Windows가 Microsoft의 production signing 정책을 충족하지 않는 테스트 서명 드라이버를 개발 및 시험 목적으로 받아들이도록 설정되어 있음을 나타내는 표시이다. 이 실험에서는 Memory Integrity는 계속 켜 두었다.

마지막까지 순조롭게 진행되지는 않았다

처음에는 이렇게 만든 RDIF1012.INF를 곧바로 pnputil로 설치하였다. 그런데 Windows는 새 드라이버를 설치하지 않았다. 이미 Driver Store에 들어 있던 기존 Roland 패키지와 INF가 사실상 동일하기 때문에 기존 oem76.inf가 이미 설치되어 있고 최신 상태라는 판단을 내린 것이다. 장치 상태를 확인해 보니 여전히 Code 52, 즉 서명 문제를 나타내고 있었고 signer도 여전히 Roland Corporation으로 표시되었다.

해결 방법은 간단했다. SC-D70을 USB에서 분리하고 기존 Roland 패키지를 Driver Store에서 제거한 다음, 우리가 새로 만든 test-signed 패키지를 다시 넣었다. 내 컴퓨터에서는 기존 패키지의 게시 이름이 oem76.inf였으므로 다음과 같이 하였다. 이 oem 번호는 컴퓨터마다 다를 수 있으므로 그대로 따라 쓰면 안 된다.

pnputil /delete-driver oem76.inf /uninstall /force

cd C:\projects\SC-D70_Win11-TestSigned
pnputil /add-driver .\RDIF1012.INF

이번에는 드라이버 패키지가 실제로 새로 추가되었다. 재미있게도 삭제하면서 비어 있던 번호가 다시 사용되어 새 패키지 역시 내 컴퓨터에서는 oem76.inf가 되었다. 따라서 oem 번호 자체가 중요한 것은 아니다. 중요한 것은 Driver Store에 있던 기존 Roland 패키지를 제거하고 새로 test-signing한 패키지가 들어갔다는 점이다.

SC-D70을 다시 연결하고 장치를 검색하였다. 결과는 이번에는 달랐다.

Status  Class          FriendlyName
------  -----          ------------
OK      AudioEndpoint  IN(Roland SC-D70)
OK      MEDIA          Roland SC-D70
OK      AudioEndpoint  OUT(Roland SC-D70)

실제 프로그램에서도 확인하였다. Roland SC-D70 PART A와 PART B가 모두 나타났고 양쪽 포트로 MIDI 데이터를 보내 정상적으로 연주할 수 있었다. MIDI IN/OUT도 사용할 수 있었으며 Windows의 오디오 장치로 SC-D70을 선택했을 때 USB Audio도 정상적으로 재생되었다. 앞 글에서 Driver Signature Enforcement를 일시적으로 해제했을 때 확인했던 기능들이 이번에도 그대로 살아났다.

그냥 재부팅해 보았다

마지막 시험은 단순했다. 아무런 고급 시작 옵션도 선택하지 않고 Windows를 평범하게 재부팅하였다. 앞 글에서 사용했던 Driver Signature Enforcement의 일시적인 해제도 하지 않았다. Windows 11이 다시 올라온 뒤 SC-D70을 확인하였다. 장치는 정상적으로 인식되었고 PART A와 PART B가 모두 보였다. USB Audio도 정상적으로 작동하였다.

결국 성공하였다. 2007년의 RDWM1012.SYS 코드를 수정하거나 새 드라이버를 작성하지 않았다. 원본 SYS에 현대적인 SHA-256 test signature를 추가하고, 그 상태에서 catalog를 다시 만들어 같은 인증서로 서명했을 뿐이다. 그런데 그것으로 2026년의 Windows 11에서 정상적인 재부팅을 거친 뒤에도 SC-D70의 USB MIDI와 USB Audio 기능을 지속적으로 사용할 수 있게 되었다.

물론 이것을 'Windows 11용 정식 SC-D70 드라이버'라고 부를 수는 없다. 현재 PC는 Secure Boot가 꺼져 있고 Windows의 Test Signing이 활성화되어 있다. 바탕화면에도 Test Mode라는 표시가 나온다. Memory Integrity는 켜 놓은 상태로 정상 동작했지만, Secure Boot를 포기하고 테스트 서명 커널 드라이버를 허용하는 것은 일상적인 Windows의 정상 보안 상태와 같지 않다. 따라서 이 설정을 일반 사용자에게 상시 사용하라고 권하기는 어렵다. SC-D70을 가끔 사용하는 경우라면 Secure Boot와 정상적인 서명 정책을 유지하고, 필요할 때만 Driver Signature Enforcement를 한 번의 부팅에 한하여 일시적으로 해제하는 방법이 보안 측면에서는 더 나을 수도 있다.

그래도 이번 실험에서 확인한 사실은 꽤 분명하다. SC-D70이 Windows 11에서 작동하지 않는 이유는 적어도 내가 시험한 범위에서는 드라이버의 기능이 낡아서가 아니었다. 2007년에 만들어진 Vista x64 드라이버는 19년 뒤의 Windows 11에서도 USB Audio와 두 개의 MIDI PART를 제대로 다룰 수 있었다. 최신 WDK의 Inf2Cat도 이 패키지를 오류나 경고 없이 처리하였다. 문제는 오래된 하드웨어나 오래된 코드 자체라기보다는 그 코드를 신뢰할 것인가를 결정하는 현대 Windows의 서명 체계에 있었다.

이제 남은 질문은 기술적인 것이라기보다 제도적인 것에 가깝다. Secure Boot를 다시 켜고 Test Mode도 사용하지 않으면서 이 드라이버를 정상적으로 로드하려면 Microsoft가 신뢰하는 production 수준의 서명이 필요하다. 그러나 이 드라이버는 Roland가 만든 것이므로, 개인적으로 다시 서명하여 시험하는 것과 정식 서명을 받아 공개적으로 배포하는 것은 전혀 다른 문제이다. 실제로 그 단계까지 가려면 Roland의 동의와 Microsoft의 현재 드라이버 서명 절차를 검토해야 할 것이다.

원본 드라이버의 날짜는 2007년 1월 22일이고 버전은 1.0.0.0이다. 2027년이면 이 64비트 드라이버도 20주년을 맞는다. 여기까지 왔으니 20주년을 맞아 정식으로 다시 서명된 SC-D70 드라이버를 볼 수 있다면 재미있겠다는 생각도 든다. 그것이 실제로 가능한지는 아직 모르겠다.

일단 이번 실험의 결론은 이것으로 충분하다. 2007년의 드라이버는 아직 작동한다. 2000년에 출시된 SC-D70도 아직 작동한다. 새로 만들어야 했던 것은 드라이버 자체가 아니라, 2026년의 Windows가 그것을 다시 믿어 볼 수 있도록 해 주는 서명이었다.

으아! ASIO 드라이버도 살아났다. 다음은 Tracktion Waveform Free의 Settings 화면이다. 테스트 버튼을 눌렀을 때 반가운 '삐~' 소리가 남을 확인하였다.

단순히 오래된 커널 드라이버가 간신히 로드된 게 아니라 당시 드라이버 패키지가 제공하던 MIDI + WDM Audio + ASIO라는 상당히 완전한 기능 스택이 Windows 11에서도 살아났다!

앞으로 무엇을 할 것인가

연속하여 작성한 두 편의 글은 내가 실제로 Windows PowerShell에 입력한 명령어와 화면 출력을 충실히 반영하여 만든 step-by-step 가이드는 아니다. 따라서 이 일에 관심을 갖고 재현해 보려는 독자를 위해 보다 친절한 문서를 만들 필요가 있다. GitHub에 나의 여섯번째 리포지토리인 Roland SC-D70 on Windows 11(sc-d70-win11-driver)를 만들고 상세한 설명과 함께 ps1 스크립트를 마련하여 업로드하기 시작하였다.

---

Reviving the Roland SC-D70 on Windows 11, Part 2: Re-signing a 2007 Driver in 2026

The original 64-bit Windows Vista driver for the Roland SC-D70, released in 2007, remains functionally compatible with Windows 11, but its legacy signing no longer satisfies current Windows driver-signing requirements. In this experiment, the original driver binary was left unchanged at the source-code level and given a new SHA-256 test signature using current Windows SDK/WDK tools. A new catalog was generated with Inf2Cat and signed with the same self-signed test certificate. With Secure Boot disabled, Windows Test Signing enabled, and Memory Integrity left enabled, the repackaged driver loaded successfully after an ordinary Windows 11 reboot. Both MIDI PART A and PART B, as well as USB audio input and output, operated normally. This is not a production-signed Windows 11 driver, but the experiment shows that the principal obstacle to using the SC-D70 on current Windows is the modern driver trust and signing policy rather than a fundamental incompatibility of the original 2007 driver code.

Roland SC-D70을 Windows 11에서 다시 살려 보다(1) - 2007년 Vista 64비트 드라이버는 아직 살아 있었다

2020년 8월 31일에 촬영한 나의 롤랜드'ED' SC-D70.

Roland SC-D70은 2000년 무렵에 출시된 Sound Canvas 계열의 사운드 모듈이다. 단순한 MIDI 음원 모듈을 넘어 USB를 통한 MIDI와 디지털 오디오 입출력을 함께 지원한다. 특히 USB MIDI로 연결하면 PART A와 PART B라는 두 개의 독립적인 MIDI 포트를 사용할 수 있으므로 32파트 멀티팀버 음원으로 활용할 수 있다.

문제는 세월이다. SC-D70은 이미 20년을 훌쩍 넘긴 장비이고 Roland가 제공했던 Windows용 드라이버 역시 오래전에 지원이 끝났다. 최근에는 DIN MIDI 단자를 별도의 USB-MIDI 인터페이스나 구형 키보드 컨트롤러에 연결하여 SC-D70을 사용하고 있었다. 이 방법으로도 일반적인 MIDI 음원으로 사용하는 데에는 별 문제가 없지만 USB 직결에 비하면 몇 가지 불편함이 있다. PART A에만 접근하게 되어 SC-D70의 32파트 기능을 온전히 활용하기 어렵고, 전원을 켤 때 버튼을 동시에 눌러 MIDI 모드로 전환해야 하는 번거로움도 있다. 흥미로운 것은 Linux에서는 SC-D70을 USB로 연결하는 데 별 문제가 없다는 점이다. 그렇다면 Windows 11에서도 어떻게든 USB 기능을 되살릴 수 있지 않을까?

사실 2022년에도 비슷한 일을 했었다

나는 2022년 4월에 이미 SC-D70을 다시 꺼내 Windows 10에서 사용해 본 기록을 남겨 놓았던 것이다(음악 작업 환경 바꾸기 (2022년 4월 26일)). 당시 글에는 Vista 64비트용 드라이버를 이용하여 Windows 10에서 SC-D70의 녹음과 재생이 정상적으로 작동했다고 적어 놓았다. 당시에는 특별한 문제 없이 설치가 되었었던 것으로 기억한다. 그러나 Windows 11이 되면서 이 드라이버는 설치는 되지만, 강화된 드라이버 서명 정책 때문에 정상적으로 로드되지 않는다.

Vista x64용 원본 드라이버를 다시 구하다

조사해 보니 Roland가 과거 배포했던 SC-D70의 Windows Vista 64비트용 드라이버가 존재했다. 파일 이름은 SC-D70_win_vista_x64.zip이고 버전은 1.0.0.0, 날짜는 2007년 1월 22일이다. 놀랍게도 이 오래된 드라이버 파일은 2026년 현재에도 Roland의 서버에서 직접 다운로드할 수 있다.

현재 다운로드되는 URL은 다음과 같다.

http://lib.roland.co.jp/support/en/downloads/res/1812426/SC-D70_win_vista_x64.zip

주의할 점은 HTTPS가 아니라 HTTP를 사용해야 한다는 것이다. https://로 시작하는 주소로는 다운로드되지 않았지만, http:// 주소로 접속하면 원본 ZIP 파일을 정상적으로 내려받을 수 있었다. 압축을 풀어 보니 INF, SYS, CAT 파일은 물론 ASIO 관련 DLL과 Control Panel까지 들어 있는 완전한 드라이버 패키지였다.

INF 파일에는 SC-D70의 USB hardware ID인 USB\VID_0582&PID_000C가 명시되어 있었고, 더욱 흥미로운 것은 MIDI 포트 정의였다.

Roland SC-D70 PART A
Roland SC-D70 PART B
Roland SC-D70 MIDI OUT

Roland SC-D70
Roland SC-D70 MIDI IN

즉 SC-D70의 USB 연결에서 제공되던 PART A와 PART B 기능이 원래 Windows 드라이버 안에 그대로 들어 있었다. 새로운 Windows 11용 MIDI 드라이버를 처음부터 만드는 것보다 이 드라이버를 어떻게든 다시 실행시키는 것이 훨씬 합리적인 접근으로 보였다.

Windows 11에 원본 드라이버를 설치하다

Windows 11의 관리자 권한 PowerShell에서 다음과 같이 드라이버를 설치했다.

pnputil /add-driver RDIF1012.INF /install

뜻밖에도 설치 자체는 아무 문제 없이 이루어졌다. Windows 11은 이 오래된 INF를 받아들였고 Driver Store에 정상적으로 추가했으며, 실제로 연결된 SC-D70에도 해당 드라이버를 연결했다.

드라이버 패키지를 추가했습니다.
게시된 이름: oem76.inf
드라이버 패키지가 장치에 설치됨: USB\VID_0582&PID_000C\...

그러나 장치 상태는 Error였다. 처음 확인했을 때에는 Problem Code 39 (CM_PROB_DRIVER_FAILED_LOAD)와 0xC000007B가 나타났다. 드라이버 패키지를 설치하고 장치에 연결하는 데까지는 성공했지만 실제 커널 드라이버가 로드되지 않은 것이다.

Memory Integrity와 오래된 드라이버

Windows 11에는 Memory Integrity, 즉 메모리 무결성이라는 보안 기능이 있다. 이는 HVCI(Hypervisor-protected Code Integrity)의 사용자 인터페이스 이름으로, 가상화 기반 보안 기능을 이용하여 커널에서 실행되는 코드의 무결성을 보호한다. 2007년에 만들어진 드라이버는 이런 현대적인 Windows 보안 환경을 고려하지 않았으므로 이것이 원인일 가능성을 확인해 보기로 했다.

Windows 보안의 장치 보안 → 코어 격리 → 메모리 무결성을 시험적으로 끄고 재부팅하였다. 그러자 오류의 형태가 달라졌다.

Problem Code: 52
CM_PROB_UNSIGNED_DRIVER

Problem Status: 0xC0000428

이번에는 원인이 훨씬 명확하게 드러났다. 오래된 Roland 드라이버의 디지털 서명을 현재 Windows가 커널 드라이버용으로 받아들이지 않는 것이었다. 중요한 것은 Memory Integrity를 끄는 것만으로는 SC-D70이 작동하지 않았다는 것이다. 보안 설정을 하나 낮추었음에도 드라이버는 여전히 Code 52 상태였다.

드라이버 서명 적용을 한 번만 해제해 보다

다음으로 Windows의 고급 시작 옵션을 이용하였다. 명령 프롬프트 또는 PowerShell에서 shutdown /r /o /t 0을 실행하면 Windows 복구 시작 화면으로 들어갈 수 있다. 그 뒤 문제 해결 → 고급 옵션 → 시작 설정 → 다시 시작을 선택하고 7번: 드라이버 서명 적용 사용 안 함(Disable Driver Signature Enforcement)을 선택하였다. 이 설정은 영구적으로 Windows 보안을 변경하는 것이 아니라 해당 부팅 세션에서만 적용되는 임시 옵션이므로 다음에 정상적으로 재부팅하면 원상 복구된다.

SC-D70이 살아났다

Windows가 다시 올라온 뒤 장치 상태를 확인했더니 이번에는 완전히 정상 상태였다.

OK   MEDIA          Roland SC-D70
OK   AudioEndpoint  IN(Roland SC-D70)
OK   AudioEndpoint  OUT(Roland SC-D70)

MIDI 프로그램을 실행하여 포트를 확인하니 출력에는 Roland SC-D70 PART A, Roland SC-D70 PART B, Roland SC-D70 MIDI OUT의 세 포트가 나타났고 입력 쪽에도 SC-D70의 MIDI 포트가 정상적으로 나타났다. 가장 중요한 PART A와 PART B를 각각 시험해 보았는데 둘 다 정상적으로 작동하였다. 따라서 DIN MIDI를 통한 우회 연결에서는 사용할 수 없었던 SC-D70의 두 MIDI 포트를 Windows 11에서 USB 연결로 온전히 사용할 수 있게 되었다. 즉 32파트 MIDI 기능이 다시 살아난 것이다.

SC-D70의 두 파트가 전부 보인다(MidiEditor).

USB Audio도 정상 작동한다

MIDI만 되는 것도 아니었다. Windows의 사운드 설정을 열어 보니 SC-D70이 정상적인 오디오 장치로 나타났고, OUT(Roland SC-D70)을 Windows의 출력 장치로 선택하여 실제 오디오를 재생해 보니 소리가 정상적으로 출력되었다. 따라서 이번 실험으로 확인한 것은 단순한 USB MIDI 호환성 정도가 아니다. 2007년의 Windows Vista x64용 Roland SC-D70 드라이버가 Windows 11에서 실제로 로드되었고, USB MIDI와 PART A/B를 통한 32파트 MIDI는 물론 Windows USB Audio 출력까지 정상적으로 작동하였다. USB Audio IN/OUT endpoint도 정상적으로 생성되었다. ASIO와 실제 Audio Input 녹음 기능은 아직 별도로 시험하지 않았다.

USB Audio로 작동하는 모습. 유튜브에서 래리 칼튼의 'Smiles And Smiles To Go'를 재생하고 있다.

드라이버가 낡았다기보다 서명이 낡았다

이번 실험에서 가장 재미있는 점은 여기에 있다. 처음에는 오래된 SC-D70을 Windows 11에서 사용하려면 새로운 USB MIDI 드라이버를 만들어야 할지도 모른다고 생각했다. 그러나 실제로는 그렇지 않았다. 2007년에 만들어진 64비트 Roland WDM 드라이버 자체는 Windows 11에서도 여전히 동작한다. 적어도 이번 실험에서 확인한 직접적인 장애물은 드라이버 코드 자체의 호환성보다는 오래된 디지털 서명과 현대 Windows의 커널 드라이버 서명 정책이었다.

처음에는 Memory Integrity를 끈 상태에서도 서명 오류 때문에 드라이버가 로드되지 않았고, 그 상태에서 Driver Signature Enforcement까지 일시적으로 해제했을 때 비로소 드라이버가 정상적으로 로드되었다. 여기까지만 놓고 보면 Memory Integrity와 드라이버 서명 검사를 모두 해제해야 하는 것처럼 보일 수도 있었다. 그러나 두 보안 기능 중 어느 것이 실제 장애물인지 구분하려면 변수를 하나 더 분리할 필요가 있었다.

Memory Integrity를 다시 켜고 시험하다

그래서 추가 실험을 하였다. Windows 보안에서 Memory Integrity를 다시 ON으로 설정하고 정상적으로 재부팅하여 이 보안 기능을 원상복구하였다. 그 다음 다시 Windows의 고급 시작 옵션으로 들어가 Driver Signature Enforcement만 이번 부팅에 한하여 해제하였다. 즉 이번에는 Memory Integrity ON + Driver Signature Enforcement OFF라는 조건이었다.

결과는 예상보다 좋았다. SC-D70은 아무런 오류 없이 정상적으로 올라왔고 PowerShell에서 확인한 관련 장치는 모두 OK 상태였다.

OK  MidiEndpoint    Roland SC-D70
OK  SoftwareDevice  Roland SC-D70
OK  SoftwareDevice  Roland SC-D70 MIDI IN
OK  SoftwareDevice  Roland SC-D70 PART A
OK  SoftwareDevice  Roland SC-D70 PART B
OK  SoftwareDevice  Roland SC-D70 MIDI OUT
OK  AudioEndpoint   IN(Roland SC-D70)
OK  MEDIA           Roland SC-D70
OK  AudioEndpoint   OUT(Roland SC-D70)

MIDI 프로그램에서도 PART A와 PART B가 모두 그대로 나타났으며 실제 MIDI 재생도 정상적으로 이루어졌다. Windows의 USB Audio 역시 문제없이 작동하였다. 따라서 Memory Integrity는 이 오래된 SC-D70 드라이버의 동작을 방해하지 않는다는 사실을 실제로 확인할 수 있었다. 적어도 이 시스템에서 SC-D70을 사용하기 위해 Memory Integrity를 끌 필요는 없다.

Memory Integrity는 계속 켜 두어도 된다

이 결과는 보안 측면에서도 반가운 일이다. Memory Integrity는 단순히 오래된 드라이버를 귀찮게 검사하는 옵션이 아니다. Windows의 가상화 기반 보안 기능을 이용하여 커널 영역에서 허가되지 않은 코드가 실행되거나 커널 메모리가 변조되는 것을 어렵게 만드는 보호 기능이다. 이를 끈다고 해서 컴퓨터가 곧바로 위험한 상태가 되는 것은 아니지만, Windows가 제공하는 중요한 커널 수준의 방어층 하나를 제거하는 것은 분명하다.

처음에는 문제를 진단하기 위해 Memory Integrity를 잠시 껐지만 결과적으로 그럴 필요가 없다는 것을 확인하였다. Memory Integrity를 다시 활성화한 상태에서도 SC-D70의 USB MIDI와 USB Audio는 모두 정상적으로 작동한다. 따라서 이 설정은 계속 ON으로 유지하면 된다. 반면 현재 SC-D70의 동작 여부를 결정하는 것은 Driver Signature Enforcement였다. 이것을 일시적으로 해제했을 때 드라이버가 정상적으로 로드되었고, 다시 정상 부팅하면 서명 검사가 자동으로 활성화되어 구형 드라이버가 다시 차단될 것으로 예상된다.

결국 남은 문제는 하나

이제 문제는 상당히 단순해졌다. 하드웨어 호환성 문제도 아니고, Vista 시대의 64비트 WDM 드라이버가 Windows 11에서 실행되지 않는 것도 아니며, Memory Integrity와의 충돌도 아니었다. 남은 장애물은 2007년 Roland 드라이버의 디지털 서명을 현재 Windows 11이 정상적인 커널 드라이버 서명으로 받아들이지 않는다는 것이다.

현재 사용한 Disable Driver Signature Enforcement는 기술적인 검증에는 훌륭하지만 일상적인 해결책은 아니다. 이 설정은 해당 부팅 세션에만 적용되므로 SC-D70을 사용할 때마다 Windows 복구 메뉴로 들어가 이를 선택해야 한다. 그렇다고 Windows 전체를 Test Mode로 사용하는 것도 썩 만족스러운 해결책은 아니다.

따라서 다음 과제는 더욱 명확해졌다. Memory Integrity를 포함한 Windows 11의 정상적인 보안 기능은 가능한 한 그대로 유지하면서, 2007년 Roland SC-D70 드라이버를 정상 부팅에서도 지속적으로 사용할 방법을 찾는 것이다. 현재의 방법으로는 SC-D70을 사용할 때마다 Windows의 고급 시작 옵션으로 들어가 Driver Signature Enforcement를 일시적으로 해제해야 한다. 드라이버 자체가 Windows 11에서 정상적으로 동작한다는 사실은 확인했으므로, 이제 남은 질문은 이것이다. 2007년의 원본 드라이버 코드는 그대로 두고 현대적인 방법으로 다시 서명한다면, 이런 일회성 부팅 절차 없이도 SC-D70을 사용할 수 있을까?

그러나 오늘 확인한 것만으로도 충분히 재미있는 결론을 내릴 수 있다. 2000년에 출시된 Roland SC-D70은 2026년의 Windows 11에서도 USB MIDI와 USB Audio로 잘 작동한다. PART A와 PART B를 모두 사용할 수 있고 Windows의 USB Audio 출력도 정상적으로 동작한다. 더구나 추가 실험을 통해 Memory Integrity를 끌 필요조차 없다는 것도 확인하였다. 하드웨어가 죽은 것도 아니었고, 19년 된 Vista용 드라이버가 완전히 쓸모없어진 것도 아니었다. 드라이버의 코드보다 그동안 Windows의 문지기가 훨씬 엄격해졌을 뿐이다.

그렇다면 여기까지 온 김에 한 걸음 더 가 보기로 했다. 최신 Windows Driver Kit를 이용하여 이 오래된 드라이버를 다시 패키징하고 test-signing한다면 어떻게 될까? SC-D70은 아직 은퇴할 때가 아니다. 물론 리눅스에서는 이야기가 달라진다. USB 케이블만 꽂으면 최신 리눅스에서도 잘 작동하기 때문이다

이 실험은 다음 글에서 계속한다.

---

Reviving the Roland SC-D70 on Windows 11: A 2007 Vista x64 Driver Still Works

The Roland SC-D70, introduced around 2000, provides both USB MIDI and digital audio interfaces, including two independent MIDI ports, PART A and PART B, for 32-part multitimbral operation. Although official Windows support for the device ended many years ago, an original Roland Windows Vista x64 driver (version 1.0.0.0, dated January 22, 2007) was tested on Windows 11 in 2026. Windows 11 successfully installed and associated the driver with the SC-D70 but refused to load it normally because of current kernel driver-signing requirements. When Windows was booted once with Driver Signature Enforcement temporarily disabled, the original driver loaded successfully. Both PART A and PART B were fully functional, and USB audio playback also worked normally. A further test showed that the same MIDI and audio functions continued to work with Windows Memory Integrity enabled, demonstrating that Memory Integrity itself does not need to be disabled for this legacy driver. The remaining obstacle is therefore the acceptance of the driver's 2007 digital signature under the current Windows 11 kernel driver-signing policy, rather than fundamental incompatibility with the hardware, the driver code, or Memory Integrity. The next challenge is to find a practical way to load the original driver during normal Windows startup while retaining the standard security configuration of Windows 11.

약간의 독서 기록

 

케어리스 피플 - 책임, 공감, 원칙이 사라진 거대 플랫폼 기업의 세계 

이 책의 저자인 새라 윈윌리엄스는 뉴질랜드 출신의 메타(구 페이스북) 전직 임원이다. 이 책은 메타 내부의 권력과 위선적 이면을 강력히 고발한 용기 있는 책이다. 전 직장에서 있었던 일에 대해서 이렇게 상세하게 내부 고발을 하고 있으니 당연히 메타 측으로부터 소송이 들어올 것을 예상하고 쓴 것일게다. 세상을 연결하여 개방과 협력을 끌어내겠다는 멋진 표어가 있지만 어디까지나 기업은 기업이다. 테크 기업의 막대한 영향력 아래 어려움을 당하는 사람이라든가 사측의 무리한 요구로 힘들게 일하는 내부 직원들에게는 소홀하고 부주의한 사람들, 그게 바로 이 책의 제목이다.

정책은 왜 실패하는가 - 대한민국 정책 생태계의 민낯과 가능

실패를 최소화하는 정책 설계의 4대 기준(380쪽)은 다음과 같다.

1. 바람직함(Desirability)
2. 현실성(Feasibility)
3. 지속 가능성(Sustainability)
4. 수용성(Acceptability)

어제 있었던 '칼자루를 쥔 사람들과의 회의'에서도 희망을 읽을 수 없었다. '교수'라는 강력한 민원인 앞에 우리는 늘 무력하다. 우리는 그 민원인들과 한자리에서 현실성과 지속 가능성 등을 놓고 논쟁할 기회조차 갖지 못한다. 대신 칼자루를 쥔 사람이 민원사항을 전달하며 우리를 죄인 취급할 뿐이다. 수행 주체인 우리는 항상 해명이나 자아비판을 해야 한다. 걸핏하면 감사 받을 각오를 하라는 말을 들으며 일을 하고 싶지는 않다.

정책 설계의 블랙박스 안에는 누가 계신가요?(288쪽)

광장 비판 - 민주주의에 대해 우리가 말하지 않는 것

Ardule의 중심이 된 두 대표 도구: MIDI Player와 Drum Studio

Ardule Drum Patternology 프로젝트를 진행하면서 많은 도구를 만들고 개선하여 왔다. 무엇보다도 중요한 일은 제대로 된 이름을 붙이는 것이다. 개별 스크립트의 이름, 프로젝트를 대표하는 이름... 무엇 하나 가볍게 생각할 수 없었다.

이제는 다음의 두 가지 도구를 대표 자격으로 내세우기로 마음먹었다. 

Ardule MIDI Player는 Standard MIDI File을 재생하면서 채널별 연주와 드럼 롤을 웹 GUI에서 확인할 수 있는 프로그램이다. 별도의 Python 환경을 준비할 필요 없이 Windows용 배포 파일(v0.1)을 내려받아 바로 실행할 수 있도록 FluidSynth와 General MIDI 호환 SoundFont까지 함께 묶었다.

Ardule Drum Studio는 드럼 패턴을 보고, 듣고, 편집하는 self-contained HTML 도구(v0.4.6)이다. HTML 파일 하나만 내려받아 웹브라우저에서 열면 되며, 스마트폰에서도 쉽게 실행이 된다. 44개의 기본 패턴이 들어 있으며, Ardule에서 정의한 ADT(Ardule Drum Text) 패턴과 ORN sidecar 파일도 불러올 수 있다. 패턴을 이어붙여 곡 단위로 만드는 것도 가능하다. 

출처: https://github.com/jeong0449/Ardule

두 프로그램은 모두 웹 GUI로 작동하며, 설치 절차가 번거롭지 않다. 즉, 파이썬 인터프리터나 FluidSynth 및 사운드폰트 파일을 사용자가 별도로 설치하지 않아도 된다. 

프로그램의 완성도를 높인 것에 그치지 않고 GitHub의 문서도 그에 맞추어 체계화하였으며, 실제 작동 모습을 보여주는 소개 영상도 유튜브에 올렸다(링크). 그동안 만들어 온 분석 스크립트, ADT/ADP/ORN 포맷, 패턴 컬렉션 등의 결과물이 이제 조금씩 하나의 'Ardule 드럼 패턴학' (Ardule Drum Patternology)이라는 생태계 안에서 자리를 잡아 가는 느낌이다.

이렇게 함으로써 다른 사람에게 내가 무엇을 만들고 있는지  복잡한 설명 없이 화면(심지어 휴대폰 화면으로!)과 한두 문장으로 쉽게 설명할 수 있게 되었다.

깨지지 않는 원칙은 없다

오늘도 '드럼 패턴학' 이야기를 조금 더 해보려 한다. 그저께까지 만든 분석용 스크립트가 완벽하고, 그것을 이용해서 어제까지 매만진 패턴은 다시는 고칠 일이 없을 것이라고 생각했었다. 그러나 그러한 기대는 몇 시간 가지 않는다. 새로운 아이디어가 계속 샘솟는 것이 아니라 바라볼수록 부끄러운 구석이 눈에 뜨인다. 

"도저히 이대로 놔 둘 수가 없다!"

그래서 스크립트를 고치고, 데이터 뭉치를 다시 처리하기를 반복한다. 스크립트는 오류가 줄어들고 새로운 기능을 품는 것으로 끝나지 않고 아예 인수(argument) 체계가 다시 세워진다. 예를 들어 작업 대상 파일 하나를 인수로 제공하였다가 이제는 아예 디렉토리를 통째로 제공하는 것이다. 이렇게 함으로써 파워셸 수준에서 반복문을 돌릴 필요가 없게 되었다.

드럼 패턴 분석 작업의 제1원칙은 MIDI 원본 데이터는 손을 대지 않는 것이었다. 분할 후 추상화를 거치지만 타이밍 정보는 절대 손을 대지 않으려고 하였다. 특히 드럼 머신용 패턴이라는 이름으로 돌아다니는 MIDI 파일은 완벽할 것으로 기대했었다. 그러나 꼭 그렇지만도 않았다. 노트 단위로 그리드에서 벗어나는 것이 있어서 눈물을 머금고 tick을 가감하여 그리드에 맞추는 일이 벌어졌다. 

Flam을 처리하는 일은 한층 더 어려웠다. 1 마디 16 스텝, 즉 16분음표 간격으로 노트를 나열하는 체계에서 만나는 grace note는 거의 대부분 스텝을 32로 세분하면 정상적인 음표처럼 취급할 수 있다.

그러나 이렇게 패턴을 잘게 나누니 그리드 위에 표시하면 장식음 + 주 음표의 관계가 선명하게 드러나지 않는다. PDF 파일로 돌아다니는 원전이 있어서 'F'로 표기된 flam을 명확히 파악할 수 있었고, 스크립트 수준에서 이를 자동으로 검출하게 만드느라 무척 애를 먹었다. 

드럼 패턴 책자를 옮겼다는 MIDI 파일도 혹시 '제작자'의 실수가 있었던 것은 아닐까하는 생각이 들 때가 있다. 위에서 보인 그림 중 왼쪽의 악기명을 살펴보면 심벌에 해당하는 것의 약어는 CY-C이다. Crash 심벌이라는 의심이 들지만, 실제 MIDI 파일엣는 ride로 바뀌어 있었다. 마디 시작 위치에서 한번 타격하는 것은 ride보다 crash가 더 어울린다. 하지만 그렇다고 하여 이를 MIDI로 'transcription'한 결과물이 명백히 틀렸다고 볼 수도 없는 노릇이 아닌가. 그래서 그냥 두기로 했다.

원칙을 잘 수립하고, 침습 또는 비침습척 처리를 하는 경계를 잘 기록해 두며, 모든 것을 자동화에 맡기지 말고 반드시 눈이나 귀로 확인하는 버릇을 들이는 것. 그것이 신뢰할 수 있는 데이터를 만드는 과정이다.

네 번째 드럼 패턴 코퍼스 — 현실의 MIDI는 이상적인 상태는 아니었다

 

Corpus(코퍼스)는 원래 라틴어로 ‘몸’ 또는 ‘전체’를 뜻하며, 오늘날에는 특정한 목적을 위해 체계적으로 모아 놓은 자료의 집합이라는 의미로 널리 쓰인다. 특히 언어학에서 corpus는 실제 문장과 발화 자료를 대규모로 모아 언어의 사용 양상, 단어의 빈도, 문법적 패턴 등을 분석하기 위한 말뭉치를 뜻한다. 요즘의 AI, 특히 대규모 언어 모델 시대에는 이러한 말뭉치가 기계가 언어의 패턴을 학습하고 평가하는 중요한 데이터 자원이 되면서 더욱 익숙한 용어가 되었다.

하지만 corpus라는 말이 언어 자료에만 한정되는 것은 아니다. 음악정보학에서도 일정한 원칙에 따라 수집·정리된 음악 자료의 집합을 corpus라고 부를 수 있다. MIDI 연주, 악보, 음원, 리듬 패턴 등이 모두 연구 목적에 따라 corpus가 될 수 있다. 중요한 것은 파일이 단순히 많이 모여 있다는 사실보다는, 일정한 기준으로 선별·정리되어 서로 비교하고 분석할 수 있는 자료 집합을 이룬다는 점이다.

이런 의미에서 Ardule Drum Patternology에서는 여러 출처의 드럼 자료를 분석하고 공통된 방식으로 추상화하여 각각의 drum pattern corpus를 만들고 있다. 여러 corpus는 다시 하나의 Ardule Drum Pattern Collection을 구성한다.

이번에 그 네 번째 drum pattern corpus를 완성하였다. 이 corpus의 원재료는 2025년 11월 MidiDrumFiles.com에서 공개적으로 접근할 수 있었던 80개의 MIDI 파일이었다. 즉 이 80개 자체를 Ardule의 네 번째 corpus라고 부르는 것이 아니라, 이들을 선별하고 정제하여 공통 형식의 drum pattern으로 만든 결과물이 네 번째 corpus이다. Ardule에서는 원본 MIDI 파일을 재배포하지 않고, 분석과 추상화를 거쳐 만든 ADT/ADP 패턴을 collection으로 공개한다.

이번 작업은 앞선 세 corpus보다 훨씬 어려웠다. 이미 만들어 놓은 ADC Toolkit을 그대로 적용하기 힘들 정도였다.

먼저 분류부터 문제였다. 파일 이름에는 Contemporary, ethnic, folk뿐 아니라 12bar, 34time, 68time처럼 기존의 표준 장르 체계에 맞지 않는 이름이 많았다. 실제 음악을 듣고 임의로 장르를 새로 붙이는 대신, 이번 corpus에서만 사용하는 CON, ETH, FOL, TBR, THF, SXE 등의 코드를 만들었다.

dance 10개와 world 5개는 너무 포괄적인 분류라서 처음부터 작업 대상에서 제외하였다. 이후 timing 해석이 애매했던 ethnic17.mid도 제외하여 80개의 source MIDI 중 최종 64개를 패턴 제작에 사용하였다.

ethnic17.mid의 패턴랩 리포트(링크). 빨갛게 테두리를 두른 원(노트)은 그리드에서 벗어난 것이다.

더 큰 문제는 timing이었다. 원래 Ardule의 원칙은 MIDI를 2-bar pattern으로 자르고 drum note를 slot으로 추상화하더라도 note-on time은 건드리지 않는 것이었다. 그러나 이번 자료에는 몇 tick씩 밀린 note, 특정 instrument group 전체의 systematic shift, 고립된 off-grid note 등이 발견되었다.

문제가 있는 MIDI 파일은 ChatGPT에 직접 업로드하여 event 수준에서 조사하였다. 주변 grid와 반복 구조를 비교하고 필요하면 직접 들어본 뒤, 명백한 오류라고 판단한 것만 systematic correction 또는 nearest-grid snap으로 보정하였다. 총 20개 파일이 이러한 tick correction을 거쳤다. 보정 여부를 확신하기 어려웠던 ethnic17.mid는 억지로 손대지 않고 제외하였다.

일부 파일의 처리 과정은 따라서 다음과 같았다.

source MIDI
    ↓
ChatGPT-assisted inspection & tick correction
    ↓
corrected MIDI
    ↓
ADC Toolkit / PatternLab
    ↓
2-bar segmentation & slot abstraction
    ↓
ADT / ADP

이번 작업을 통해 PatternLab 자체도 개선되었다. 예를 들어 note가 전혀 없는 마지막 빈 마디가 하나의 패턴으로 export되는 문제를 발견하여 수정하였다. adc-patternlab.py로 만든 분석 리포트도 함께 보존했으므로 off-grid note의 상세 내용은 개별 HTML report에서 확인할 수 있다. 최종적으로 ORN 대상은 없었다.

2-bar로 분할한 뒤에는 slot abstraction 결과가 동일한 패턴도 중복으로 제거하였다. 이렇게 선별 → timing 보정 → 분할 → 추상화 → 중복 제거를 거쳐 64개의 source MIDI로부터 270개의 새로운 drum pattern을 얻었다. 이 270개가 Ardule의 네 번째 derived drum pattern corpus이다.

앞선 세 corpus에는 총 1,318개의 패턴이 있었다. 이번 270개를 더하여 Ardule Drum Pattern Collection은 이제 4개 corpus, 총 1,588개 패턴이 되었다. 이제 중복 제거, 유사도 계산, 군집화, 대표 패턴 선정, 장르별 특징 비교가 가능하다. 단순한 수집을 넘어, 드럼 패턴 사이의 구조와 관계를 탐구할 단계에 들어선 것이다.

이번에 얻은 것은 270개의 패턴만이 아니다. 잘 정돈된 자료에서는 보이지 않았던 예외들이 실제 legacy MIDI에서 쏟아져 나왔고, 그 과정에서 ADC Toolkit도 훨씬 단단해졌다.

네 번째 corpus는 Ardule Drum Pattern Collection의 새로운 구성원이자, ADC Toolkit의 제대로 된 stress test였다.

1,318개의 드럼 패턴이 Fluid Ardule로 들어왔다

라즈베리파이 3B(+ I2S DAC), 아두이노 우노, 그리고 몇 가지 주변부품을 이용하며 만든 Fluid Ardule은 원래 사운드폰트 기반의 DIY MIDI 사운드 모듈을 목표로 하였었다. '전원을 넣고 건반을 연결하여 눌러대면 소리가 난다'는 기본 기능을 갖추게 되면서 MP3, OGG 등 음원 파일 재생과 인터넷 라디오 등 일반적인 음악 감상용 도구 역할도 자연스럽게 추가하였다. 라즈베리파이는 작은 컴퓨터로서 일정 수준의 성능을 갖추고 있기 때문이다. 만약 라즈베리파이 5를 썼다면 성능은 훨씬 더 좋았을 것이다.

여기까지 오니 자연스럽게 드럼 패턴 플레이어 기능도 넣고 싶어졌다. Ardule 패밀리의 가장 초기 작품이었던 Nano Ardule, 즉 아두이노 나노에 부품을 붙여 만든 기기에서 활용하기 위해 공들여 만든 패턴 파일을 활용하면 될 것이라 생각하였다. 이를 위해서 인터넷에 공개된 드럼 MIDI 파일을 분석하여 2-bar 단위로 잘라 다듬고 장르에 맞추어 이름과 일련번호를 붙인 뒤 독자적인 포맷의 파일 체계(ADT/ADP)를 만드는 등 고된(?) 작업을 했었다. Fluid Ardule에 아주 기본적인 드럼 패턴 재생 기능을 구현해 놓았더니 ADT/ADP의 포맷을 개선해야 할 필요성이 대두되었다.

이에 따라서 기존의 v2.2를 수정하여 v2.3을 고안하였고, MIDI 파일에서 패턴을 분리하여 ADT/ADP로 정리하는 툴킷을 대대적으로 뜯어 고쳤다. v2.2 시절의 툴킷은 GitHub의 Nano Ardule 프로젝트에 속해 있었으나, 이번 작업을 통해서 아예 Ardule이라는 프로젝트로 독립하였다. 이렇게 하여 다음의 세 개 프로젝트가 각각 고유한 성격을 갖게 되었다.

• Ardule - Drum Patternology 생태계 그 자체. 주로 ADT/ADP 파일을 만드는 과정에 필요한 스크립트와 패턴 아카이브로 구성. 패턴 재생/편집 및 체인 재생용 application 포함(웹GUI, 7.69 MB, v0.4.2).
• Nano Ardule(드럼패턴/MID 재생기 및 모듈 컨트롤러) - Arduino Nano(Every 포함)로 만든 하드웨어와 구동용 펌웨어.
• Fluid Ardule(DIY synth이자 일종의 미디어 스테이션?) - 라즈베리 파이 3B로 만든 하드웨어와 리눅스 기반 OS 및 파이썬 스크립트.

ADT/ADP의 새로운 버전이 확립되어 이에 맞추어 만든 1,318개의 패턴이 마련되었으니 이를 Fluid Ardule에서 연주하게 만드는 것은 별로 어렵지 않았다. 여기에 더하여 TFT-LCD 모니터에서 패턴 섬네일을 표현하도록 만들었다. 패턴의 이름(아래의 예에서는 RCK_0011)으로는 장르 정도를 표현할 수 있을 뿐이라서, 직접 소리를 듣거나 눈으로 패턴을 관찰하여 이것이 groove인지 break인지 판단하는 것이 효율적이다. 

Stop 버튼 위에 패턴 섬네일이 표시되었다.

실제로 Fluid Ardule에 복사해 넣은 패턴은 'instant-200 collection'에서 추출한 182개 패턴의 거의 전부이다. PDF로 만든 패턴북도 있다.

세 프로젝트는 드럼과 MIDI라는 공통의 축을 통해 매우 강하게 연결되어 있다. 어느 하나에서 생긴 필요가 다른 프로젝트의 기능 개선으로 이어지고, 그 결과가 다시 처음의 프로젝트로 돌아오는 매우 긍정적인 관계를 이루고 있다. Nano Ardule에서 시작한 드럼 패턴 파일은 Fluid Ardule에서 다시 필요해졌고, 그 과정에서 ADT/ADP가 개선되었으며, 이를 위한 분석·변환 도구가 성장하면서 독립된 Ardule 프로젝트가 탄생했다. 부수적으로 지나치게 복잡한 성격을 띠었던 Nano Ardule 프로젝트는 하드웨어와 펌웨어 위주로 훨씬 단순해졌다. 그리고 Ardule에서 정비된 패턴과 새로운 ADP v2.3은 다시 독립 application을 통해 패턴의 재사용을 용이하게 하였으며, Fluid Ardule의 드럼 플레이어를 훨씬 풍부하게 만들었다.

앞으로는 'Pattern of the week' 같은 것을 통해서 널리 쓰이는 드럼 패턴을 소개할지도 모른다. RCK_0011은 일종의 accession number처럼 관리될 수도 있다. 지금은 GitHub에서 모든 자료를 flat file처럼 제공하고 있지만, 앞으로는 부가 정보와 함께 체계적으로 제공할 수도 있다.

필요에 따라 기능을 하나씩 덧붙이는 방식이므로 자칫 개발이 무질서해질 수도 있다. 이를 어느 정도 막아 주는 것이 미리 작성하는 '명세서'이다. 구현에 앞서 데이터 구조와 동작 원칙을 문서로 정리하고, 이를 바이브 코딩의 기준으로 삼는다. 실제 코드는 AI의 도움으로 빠르게 만들어지더라도, 무엇을 만들 것인지에 대한 규칙은 먼저 사람이 정해 놓는 셈이다.

명세서가 개발 시간을 크게 단축시킨 사례가 패턴을 연결하여 곡 단위의 정보를 저장하는 ARR(Arrangement)이다. 처음에는 패턴을 마우스로 끌어다 놓아 조립하는 별도의 GUI를 구상했다. 그러나 ARR 명세서를 만들고 보니 구조가 워낙 단순하고 명확해서 굳이 복잡한 편집기를 만들 필요가 없었다. 텍스트 편집기만으로도 충분히 곡의 구조를 작성할 수 있었고, 이를 읽어 체인을 재생하는 도구를 구현하는 것으로 목적을 달성할 수 있었다.

결국 명세가 먼저 만들어지면 코드는 오히려 단순해질 수 있다. Ardule 패밀리에서 최근 반복해서 경험하고 있는 일이다.

Ardule 드럼 플레이어, 이제는 self-contained HTML로 발전하다

생성형 AI에서 지시문으로 원하는 이미지(원형 엠블럼)를 만들어 내기는 참 어렵다. 아직도 내 의도를 100% 반영한 이미지를 얻지 못하였다.

자체 포맷으로 만들어진 ADT/ADP 드럼 패턴 파일을 컴퓨터에서 재생하기 위하여 파이썬 기반의 별로 친절하지 못한 CLI 재생기를 만든 바 있다. 이를 사용하려면 PC에 파이썬을 설치해야 하고, 파워셸과 같은 터미널 창을 열어서 명령어를 일일이 타이핑해야 한다. PyInstaller 등으로 .exe로 패키징할 것이 아니라면 이러한 번거로움을 벗어나기 곤란하다.

원본 MIDI 파일의 드럼 패턴 분석 보고서는 HTML 형식이다. 패턴을 시각화한 이미지 자료가 들어가고, 약간의 수고를 더하여 FluidSynth + SF2 기반의 재생 기능까지 성공적으로 넣었다. 그러나 이를 이용하려면 터미널 창에서 작은 서버 스크립트를 구동해야 한다.

챗GPT와 대화를 나누며 시행착오를 거친 끝에 드럼 샘플(오디오)이 아예 내장된 HTML 기반의 패턴 재생기를 만들어 버렸다. GeneralUser-GS.sf2에서 대표적인 드럼킷의 오디오 샘플을 꺼내어 HTML 안에 임베드한다? 이게 된다는 것이 놀랍다. 더군다나 무손실 압축포맷인 FLAC을 사용하면서 HTML 파일의 크기는 25MB(최초 개발 버전)에서 7.6MB로 줄어들었다. 25MB를 넘으면 웹 인터페이스를 통해 GitHub에 올리기 곤란하고, 이러한 상태로는 다운로드하여 쓰기에 다소 파일 용량이 큰 것도 사실이다.

첫 버전에서는 ADT 파일을 마우스로 끌어다 넣거나 직접 선택하여 로드하도록 만들었으나, 이어진 개선판에서는 아예 활용성이 높은 44개 패턴을 HTML 파일 내에 넣어 버렸다. 나의 GitHub 프로젝트 웹페이지에서 파일 하나(ardule-drum-player.html)만 다운로드 받으면, 데스크톱이든 휴대폰이든 드럼 패턴을 재생할 수 있다.

Ardule Drum Player의 스크린샷. Favicon까지 임베드하였다. 8월 13일에는 패턴 편집 기능까지 넣은 Ardule Drum Studio(beta)를 공개하였다. 

재생기의 기본 기능을 구현하는 데에는 채 두 시간이 걸리지 않았다. 참으로 놀랍다! 사용법도 매우 쉬워서 매뉴얼이 필요하지 않다.

이 과정을 통해 드럼 연주 정보의 데이터과학적 접근에 대해서도 많은 것을 알게 되었다. 설마 나와 같은 작업을 한 사람이 세상에 나 혼자뿐이겠는가? 예를 들어 Groove MIDI Dataset(GMD)은 Google Magenta 연구진이 2019년에 공개한 인간 드러머의 실제 연주 데이터셋이다. 전문 드러머 등을 전자드럼으로 연주하게 하여 약 13.6시간, 1,150개의 MIDI 파일과 22,000마디 이상의 드럼 연주를 수집했으며, 장르·템포·박자표·beat/fill 등의 메타데이터도 함께 제공한다. 일반적인 정형 드럼 패턴 모음과 달리 GMD의 중요한 특징은 실제 연주에서 발생하는 미세한 타이밍 차이(microtiming)와 타격 강도(velocity)를 그대로 담고 있다는 것이다. 따라서 GMD는 단순히 ‘어떤 드럼을 어느 박자에 치는가’를 기록한 패턴 자료라기보다 인간이 하나의 리듬을 실제로 어떻게 연주하는가를 기록한 데이터에 가깝다. 이러한 특성 때문에 인간적인 드럼 연주의 생성과 복원, groove transfer, 스타일 분류, 자동 드럼 전사 등 다양한 연구에 활용되고 있다.

GMD와 이를 활용한 연구가 사람이 드럼을 어떻게 연주하는가에 초점을 맞춘다면, Ardule Drum Patternology는 그 연주에서 어떤 패턴을 추출하여 어떻게 기술하고 비교할 것인가에 초점을 맞춘다. GMD에서는 정확한 그리드에서 조금 앞서거나 뒤처지는 microtiming과 세밀한 velocity 차이가 인간적인 groove를 구성하는 중요한 정보이며, 실제로 이를 학습하여 quantized beat를 다시 인간적인 연주로 만드는 연구에 활용한다. 반면 Ardule은 다양한 MIDI 드럼 자료를 공통된 subdivision, slot, accent 구조로 추상화하여 재사용 가능한 drum pattern object로 만들고, 필요할 경우에만 세부 timing 정보를 ORN과 같은 별도 계층에 보존한다. 따라서 Ardule Drum Patternology의 관심은 연주를 사실적으로 재현하는 데 그치지 않고, 서로 다른 시대와 출처와 장르의 드럼 데이터를 같은 표현 체계 위에 올려 무엇이 같은 패턴이고 무엇이 변형이며, 어떤 리듬 어휘가 반복해서 등장하는가를 분석·비교·교환할 수 있게 하는 데 있다. 즉 GMD가 performance를 데이터로 만든 것이라면, Ardule Drum Patternology는 performance와 MIDI 자료에서 pattern이라는 연구 가능한 객체를 만들어 내는 것에 의미가 있다.

지금까지 총 세 세트의 drum pattern corpus를 분석하여 GitHub의 collections 아래에 정리하고, 이로부터 총 1,318개의 드럼 패턴을 집대성하였다. 그러나 패턴을 모으는 것 자체가 끝은 아니다. 이들을 일정한 방식으로 벡터화하고 심층 분석하면 패턴 사이의 거리를 계산하여 동일하거나 매우 유사한 패턴을 찾아낼 수 있고, 중복을 정리하거나 서로 다른 자료에서 반복해서 등장하는 리듬 구조를 발견할 수도 있다. 더 나아가 충분한 학습·참조 자료가 확보된다면 패턴의 특징만으로 장르를 추정하고 라벨을 부여하는 것도 시도해 볼 수 있을 것이다. 이를 위해서는 GMD(Groove MIDI Dataset)를 비롯한 양질의 corpus를 추가로 분석하여 비교 대상을 넓힐 필요가 있다. 재료는 부족하지 않다. MIDI로 기록되거나 변환된 드럼 연주 정보는 이미 세상에 널리고 널렸다. 이제 필요한 것은 그것을 수집하는 일을 넘어, 서로 비교하고 분류하고 해석할 수 있는 드럼 패턴 데이터로 바꾸는 일이다.

Drum Patternology, 그것은 생명정보학과 묘하게 닮았다. 자료를 모아서 정리하고 노이즈를 제거하며 라벨을 붙인다. 서로 비교 분석이 가능하도록 독자적인 포맷에 맞게 추상화를 거치고 시각화 방안도 마련해 본다. 추상화 과정에서 손실되는 정보를 담기 위한 별도의 장치를 꾸민다...

그러나 어쩌면 나는 바퀴를 재발명하느라 애쓰고 있는지도 모른다. 남들이 이미 다 해 놓은 일?

정답이 없는 질문

 책임을 묻기 위해 사실을 확인하는 것과, 책임질 사람을 찾기 위해 사실을 확인하는 것은 전혀 다른 일이다.

전자는 먼저 무슨 일이 있었는지를 확인한다. 문제가 있었다면 원인이 무엇인지 살펴보고, 어떻게 바로잡을 것인지 고민한다. 그 과정에서 잘못된 판단이나 명백한 태만이 확인된다면 그때 책임을 묻는다. 사실의 확인이 먼저이고 책임은 그다음이다.

그러나 후자는 순서가 거꾸로다. 문제가 발견되는 순간부터 누가 책임져야 하는지를 먼저 찾는다. 사실을 확인하는 질문도 문제의 원인을 이해하기 위한 것이 아니라 책임자를 특정하기 위한 방향으로 흘러간다.

이런 조직에서는 질문에 정답이 없다.

“이 사실을 알고 있었습니까?”

몰랐다고 하면 관리자가 그것도 파악하지 못했느냐고 질책한다. 무능과 관리 소홀의 증거가 된다. 알고 있었다고 하면 더 곤란하다. 알고도 지금까지 아무 조치를 하지 않았느냐고 묻는다. 이번에는 방치와 직무유기의 증거가 된다.

몰랐으면 무능이고, 알았으면 직무유기다.

이런 질문이 반복되면 사람들은 질문의 의도를 학습한다. 질문을 받았을 때 사실을 정확하게 설명하는 것보다, 이 답변이 나중에 누구의 책임으로 돌아갈지를 먼저 생각하게 된다. 솔직하게 문제를 드러내는 것이 위험해지고, 새로운 사실을 발견하는 것조차 부담스러워진다.

결국 질문은 정보를 얻기 위한 수단이 아니게 된다.

무슨 일이 일어났는지를 이해하기 위한 질문이 아니라, 그 일의 책임을 누구에게 귀속시킬 것인지를 결정하기 위한 절차가 된다. 문제를 해결하기 위해 책임을 묻는 것이 아니라, 책임을 묻기 위해 문제를 들여다보는 것이다.

겉으로 보면 둘은 비슷하다. 둘 다 질문하고, 자료를 요구하고, 보고를 받는다.

그러나 하나는 문제를 해결하기 위해 사실을 찾고, 다른 하나는 책임질 사람을 찾기 위해 사실을 찾는다.

그 작은 순서의 차이가 조직의 문화를 완전히 다르게 만든다.

허리가 아파도 달렸다

일년에 두 번 정도 갑자기 허리가 아플 때가 있다. 이는 타고난 척추분리증 때문이다. 대학원생 시절 갑자기 일어나기도 힘들 정도로 허리가 심하게 아파서 병원을 간 뒤에 내가 이러한 선천성 질환을 갖고 있다는 사실을 알게 되었다. 증세가 심하면 가끔 한의원 신세를 지기도 하지만, 대개는 이틀 정도 지나면 저절로 나아진다. 하지방사통까지 생기지는 않는다.

지난 주말, 세면대에서 면도를 하던 중이었는지 이를 닦는 중이었는지 어쨌든 꼿꼿이 서서 뭔가를 하고 있는데 갑자기 허리가 삐끗하는 소리와 함께 통증이 밀려오면서 자세가 무너지고 말았다. 세면대를 부여잡고 거의 주저앉을 수준이었다. 허리가 아플 때에는 몸의 형태도 이상해진다. 통증은 늘 허리의 왼쪽 부분에 온다. 아플 때에는 허리도 그쪽으로 휘어진 모습을 관찰할 수 있다.

허, 이거 또 시작이네.

가까스로 몸을 추스리고 천안으로 문상을 다녀왔다. 자동차를 운전하는 정도는 큰 문제가 없으니까. 집에 돌아와서는 등산용 지팡이를 찾았다. 나머지 주말 외출은 지팡이에 의지했고, 일요일 저녁에는 그냥 누워버렸다.

월요일 아침, 지팡이를 짚고 출근을 하였다. 의자에 앉아 있다가 일어나는게 정말 고역이었다. 허리에 힘을 주고 일어서면 통증이 한결 덜하다. 관절이나 척추에 문제가 있지만 주변 근육과 인대를 단련하여 버티는 사람도 있다는데, 아마 힘을 주면 덜 아픈 것이 그런 꼴일 것이다.

오후가 되어 갑자기 통증이 한결 줄어들었다. 요추가 제자리를 찾았나? 지팡이도 필요가 없었고, 이만하면 저녁 달리기를 해도 문제가 없을 것 같았다. 그래서 퇴근 후 또다시 5km를 달렸다. 

달리면서 척추에 충격이 가해지므로 척주 전방 전위증이 생길지도 모른다는 합리적인 우려를 할 수도 있다. 몇 년 전에 건강검진에서 요추 CT를 찍었던 것 같다. 요추가 약간 앞으로 밀려났다는 진단을 받은 것 같기도 하다. 다음에 기회가 되면 다시 촬영을 해 본 뒤, 현재 상태의 운동을 그대로 유지해도 되는지 상담을 해 봐야 되겠다.

오래된 드럼 패턴 MIDI의 출처를 추적하다

이 글은 GitHub에서 운영하는 프로잭트인 ADX Drum(현재는 Ardule Drum Patternology로 명칭 변경)의 README 문서에 최근 새롭게 고쳐 쓴 문서를 국문으로 번역한 것이다. 패턴 분석 작업에 쓰인 MIDI 파일의 출처를 나름대로 탐색한 이야기이다.

---

Ardule Drum Patternology를 개발하면서 참조한 드럼 패턴은 주로 인터넷을 통해 오랫동안 유통되어 온 Standard MIDI 형식의 드럼 패턴 파일들이다. 이 프로젝트에서 사용한 자료는 Cakewalk 포럼에 공개된 460 Free GM MIDI Drum Patterns 에서 구했다.

압축 파일을 풀어 보면 세 종류의 GM 드럼 패턴 MIDI 모음이 들어 있다. 남아 있는 여러 흔적을 종합하면 이 자료들은 과거 FivePin Press라는 출판사에서 판매 또는 배포했던 것으로 보인다. 다만 정확한 저자, 제작자, 배포 경로를 명확하게 확인하기는 쉽지 않다.

이 가운데 두 묶음은 프랑스의 드럼 머신 패턴 저자인 René-Pierre Bardet의 저작물과 관련이 있는 것으로 보인다. Bardet는 다음 두 권의 책으로 잘 알려져 있다.

• 200 Drum Machine Patterns
• 260 Drum Machine Patterns

Bardet의 책들은 드럼 머신이 대중화되던 시기에 리듬 패턴을 하나의 재사용 가능한 음악적 단위로 정리하고 보급하는 데 상당한 역할을 한 자료로 보인다. 두 책은 지금도 중고 인쇄본을 구할 수 있으며, 인터넷에는 PDF 형태의 디지털 사본도 여러 경로를 통해 유통되고 있다.

그런데 실제 자료를 하나씩 대조해 보니 출처 관계는 생각보다 단순하지 않았다.

260개의 패턴은 Bardet의 책과 매우 잘 일치한다

Cakewalk 포럼에서 구한 MIDI 자료 가운데 260개의 패턴으로 이루어진 묶음은 Bardet의 260 Drum Machine Patterns에 수록된 패턴과 직접 비교했을 때 구조와 순서가 매우 잘 일치했다. 따라서 이 MIDI 모음과 Bardet의 책 사이에는 명백한 연관성이 있다고 판단할 수 있다.

흥미로운 점은, Archive 형태로 남아 있는 FivePin Press의 당시 설명에서는 René-Pierre Bardet라는 이름이 전혀 언급되지 않는다는 것이다. 따라서 이 MIDI 파일들이 FivePin Press에서 Bardet의 책을 공식적으로 MIDI화하여 판매한 것인지, 제3자가 별도로 '전사'(transcription)한 뒤 FivePin Press 자료와 함께 유통된 것인지, 혹은 이후 재배포 과정에서 서로 연결된 것인지는 현재 자료만으로는 확정하기 어렵다.

200개의 패턴은 출처가 훨씬 더 모호하다

문제는 200개의 패턴으로 이루어진 MIDI 모음이다. 처음에는 자연스럽게 Bardet의 200 Drum Machine Patterns를 MIDI로 옮긴 자료일 것이라고 생각했다. 그러나 실제 자료를 비교하면서 이상한 점이 발견되었다.

인터넷에서 Bardet의 200 Drum Machine Patterns라는 제목으로 널리 유통되는 PDF를 확인해 보면, 첫 두 페이지(표지와 목차)는 분명 Bardet의 책이다. 그런데 그 이후 대부분의 본문은 전혀 다른 책으로 바뀌어 있다.

그 책은 Ray F. Badness의 Drum Programming: A Complete Guide to Program and Think Like a Drummer이다. 어떤 과정에서 이런 혼합 PDF가 만들어졌는지는 알 수 없지만, 동일하거나 유사한 파일이 오랫동안 인터넷에서 재배포되면서 Bardet의 200 패턴 자료를 찾는 데 상당한 혼란을 일으키고 있는 것으로 보인다.

Badness의 책 9쪽에 실린 그림.

물론 Badness의 책 자체는 매우 훌륭하다. 전통적인 드럼킷의 구성과 연주법으로부터 드럼 프로그래밍까지 매우 유용한 정보를 충실하게 담고 있으며 실용적인 설명과 예제가 풍부하여 지금 읽어도 가치가 있다.

그러나 중요한 것은 이 책의 내용이 Cakewalk 포럼에 공개된 200개의 MIDI 패턴과 일치하지 않는다는 점이다. 결국 현재까지 확인한 자료만으로는 파일명이 2로 시작하는 이 200개의 MIDI 패턴이 어떤 인쇄물에서 비롯된 것인지 확실하게 밝힐 수 없었다.

27 Instant Rap Patterns도 저자가 불분명하다

세 번째 묶음인 27 Instant Rap Patterns 역시 비슷한 문제를 가지고 있다. 패턴 자체는 정상적으로 사용할 수 있지만, 현재 확인 가능한 자료만으로는 원래의 저자나 편집자를 신뢰성 있게 특정하기 어렵다.

출처보다 중요한 것은 실제 데이터였다

이러한 출처의 혼란에도 불구하고 이 MIDI 자료들은 Ardule Drum Patternology 개발 과정에서 대단히 가치 있는 데이터셋이었다. 단순히 패턴을 복제하는 데 사용한 것이 아니라, 실제 MIDI 드럼 데이터가 어떤 방식으로 만들어져 있는지를 관찰하고 분석하는 자료로 활용했다.

이를 통해 리듬의 반복 구조뿐 아니라 MIDI 타이밍, subdivision, velocity 차이, 패턴의 변형, 그리고 미리 설계한 규칙에 잘 들어맞지 않는 예외적인 연주까지 실제 데이터 속에서 확인할 수 있었다.

특히 이런 실제 자료를 대량으로 분석하는 과정은 Ardule Drum Patternology의 패턴 추상화 방법과 표현 체계를 검증하고 수정하는 데 큰 역할을 했다. 어떤 규칙이 이론적으로 가능하다는 것과 수백 개의 실제 MIDI 패턴을 제대로 설명할 수 있다는 것은 전혀 다른 문제였기 때문이다.

그래서 이 MIDI 파일들을 ‘역사적 참조 데이터’로 취급한다

현재 Ardule Drum Patternology에서는 이 오래된 MIDI 파일들을 특정 책의 공식 디지털 판본으로 간주하지 않는다. 대신 historical reference dataset, 즉 역사적 참조 데이터셋으로 취급한다.

260 패턴처럼 실제 책과의 관계를 직접 비교하여 확인할 수 있는 경우에는 그 연관성을 기록한다. 반면 200 패턴이나 27 Instant Rap Patterns처럼 출처가 명확하지 않은 경우에는 확인 가능한 정보만 남기고 저자나 원전을 단정하지 않는다.

같은 이유로 Ardule Drum Patternology의 패턴 ID 역시 과거 MIDI 파일의 번호 체계를 그대로 계승하지 않는다. 대신 원본 MIDI 파일명, 원본 내 위치 등의 정보는 메타데이터로 보존하여 어디에서 유래한 패턴인지는 추적할 수 있도록 한다.

결국 이 오래된 MIDI 자료의 가치는 그 출처가 완벽하게 정리되어 있기 때문이 아니라, 오히려 수십 년 동안 실제 음악가와 프로그래머들이 사용하고 공유해 온 현실의 드럼 패턴 데이터라는 데 있다. Ardule Drum Patternology는 바로 그 데이터를 분석하고 추상화하여 현대적인 소프트웨어와 임베디드 시스템에서 다시 사용할 수 있는 형태로 만드는 데서 출발했다.

드럼 패턴 에디터의 진화, TUI에서 웹 GUI로!

PatternLab이 만들어진 뒤 드럼 패턴이나 MIDI 파일 재생 등의 기능이 모듈 형태로 추가되면서 새로운 아이디어를 떠올리고 이를 실제로 구현하는 속도가 점점 빨라지는 것을 느낀다. 최근에 있었던 가장 획기적인 개선은 사용자 인터페이스를 웹 기반으로 전환하였다는 점이다. 말 그대로 '대전환'에 해당하지만 개발 자체는 그다지 어렵지 않았다. 불과 6개월 전만 하더라도 CLI에서 APS.py의 텍스트 기반 UI를 구현하느라 얼마나 애를 먹었던가? 하지만 웹 브라우저에서 다채로운 그림을 포함하는 패턴 분석 리포트를 만들고, 분할한 각 패턴의 소리에 추상화를 적용한 뒤 원본과 더불어 각각의 실제 소리를 들어보고 싶다는 욕구를 충족해 나가는 과정은 그렇게 고생스럽지 않았다.

아래 이미지를 보라. 위의 것은 반년 전에 만들었던 aps.py(Ardule Pattern Studio)이고, 아래는 오늘 머리에 떠오르는 아이디어를 바이브 코딩으로 순식간에 구현한 웹 GUI 기반의 패턴 편집/재생기인 adx-web-editor.py이다. PowerShell에서 파이썬 스크립트를 실행하면 웹 화면이 뜸과 동시에 FluidSynth가 구동되면서 웹 GUI에서 조작한대로 사운드폰트 기반의 음성 합성이 일어난다. 이전에는 전혀 생각하지 못했던 방식이었다.

APS.py를 개발하느라 고생했던 순간들이 갑자기 한심하게 느껴지기 시작하였다. 왜 그때는 웹 GUI를 사용하려는 생각을 못했을까? 오로지 CLI에서 curses 라이브러리를 써서 텍스트 기반의 UI를 짜는 것이 가장 간단한 방법이라고만 생각했었다. 지금은 HTML, CSS, JavaScript만으로도 패턴 편집기와 재생기, 앞으로는 ORN 편집기와 패턴 체인 편집기까지 자연스럽게 구현할 수 있다는 사실을 깨닫고 있다.

나의 '개발 일지'를 전문가가 들여다 본다면 정말 기형적이고 희한하면서 비능률적인 방식으로 개발을 이어오고 있다고 평가할지도 모른다. 이론적 배경이나 경험 없이 그저 필요한 때마다 문제를 해결하면서 기능을 하나씩 쌓아 올렸기 때문이다. 실제로는 인공지능 덕분에 지시문을 던지고 검증하며 개선점을 찾아내는 일만 하는 셈이지만. 

어설프기는 해도 최근 생산성이 갑자기 높아졌다는 느낌이 든다. 이는 초기부터 ADT, ADP, ORN 등의 파일 형식과 슬롯맵, 액센트 체계 등을 명세서 형태로 표준화해 둔 때문일 것이다. 안정적으로 기반이 구축되면서 새로운 프로그램은 그 위에 모듈을 하나씩 얹듯이 빠르게 개발할 수 있게 되었다.

지금의 ADX 프로젝트는 더 이상 개별 프로그램들의 집합이 아니다. PatternLab, MIDI Inspector, ADX Player, 그리고 Web Editor는 하나의 공통된 데이터 구조와 명세를 공유하는 생태계로 성장하고 있다. 아이디어를 떠올리고 이를 실제 도구로 구현하는 시간이 계속 짧아지고 있다는 점에서, 이제야 비로소 플랫폼다운 모습을 갖추기 시작한 것 같다.

드럼 패턴 추상화(abstract)의 손익 계산

인터넷에서 구한 ALLSTARS.MID('The GS All-Stars, Live!')라는 파일은 1990년대 Roland가 자사의 GS 음원을 홍보하기 위해 배포했던 전설적인 번들 데모라고 한다. 물론 나는 바로 어제까지 ALLSTARS.MID라는 곡을 전혀 알지 못하였다. 웹 기반의 재생기인 Chip Player JS에서 이를 감상해 보자(GitHub). 이 애플리케이션은 고전 비디오 게임 음악 및 칩튠 포맷을 웹 브라우저에서 실시간으로 재생해 준다. ALLSTARTS.MID는 사이트 내 재생 목록에 이미 등록되어 있으며, 로컬 PC의 음악 파일을 로드하여 재생하는 것도 당연이 가능하다.

DOS 화면을 연상시키는 고풍스런 재생기 Chip Player JS. Visualizer 기능은 실로 놀랍다.

인터넷을 뒤져 보면 이렇게 특정 기기의 성능을 한껏 자랑하기 위해 만든 MIDI 파일이나 유명한 대중음악을 MIDI로 옮긴 것들이 많다. 이를 나의 ADX 플랫폼에서 분석하면 재사용 가능한 non-redundant 드럼 패턴으로 축약할 수 있을 것으로 기대하였다. MIDI 파일의 표현력은 매우 우수하지만, ADX 플랫폼에 활용하려면 목적에 맞는 정보만 남기고 나머지는 과감히 생략하는 추상화(abstraction) 과정이 필요하다.

ADX 플랫폼에서는 크게 세 가지의 추상화가 이루어진다.

• Instrument abstraction - 수십 종의 GM 드럼 악기를 12개의 대표 슬롯으로 통합한다.
• Temporal abstraction - 자유로운 MIDI 타이밍을 16-step, 8T(T=triplet), 16T 등의 subdivision grid로 정규화한다. 다른 추상화와는 달리 타이밍이 어긋난 노트를 그리드에 맞추기 위해 억지로 이동하지는 않는다.
• Velocity abstraction - 1~127의 연속적인 velocity를 rest 포함 4단계 accent(6단계는 검토 중)로 변환한다.

추상화를 통해 무엇을 얻었는가? 패턴 비교가 쉬워지고, 사람이 쉽게 읽을 수 있으며, 저장 공간도 줄어들었다. 또한 검색과 분류가 쉬워졌다. 그러나 이를 통해 잃은 것도 있다. 연주의 미세한 타이밍, 세밀한 다이내믹(velocity 0~127), 악기의 개성 등이다.

MIDI 파일로부터 드럼 채널을 추출한 뒤, 패턴을 분석하여 그 결과를 제공하는 PatternLab은 하루가 다르게 발전하고 있다. 이를 이용하여 몇 가지 MIDI 파일을 분석하면서 새로운 사실을 많이 발견하였다. 다음은 ALLSTARS.MID를 PatternLab으로 분석한 보고서의 일부이다. 대부분의 note는 파란색을 띠고 있지만, 그리드에서 벗어나거나 ghost note(현재로서는 기준 velocity 이하인 것을 후보로 판정)인 경우 다른 색으로 표시하였다. 왼쪽 패턴 카드의 노랑-주황-빨강으로 표시된 tom 타격에 주목하라.

"Rushing or dragging?"

영화 <위플래시>의 테런스 플레처 교수가 다그치면서 하는 무시무시한 대사가 떠오른다. 물론 아래 이미지에 보낸 'off-grid' 노트는 의도적인 것이다. PatternLan은 이를 추상화(여기에서는 시간적 양자화)에서 어긋난 이벤트로 표시하지만, 실제로 들어보면 이러한 미세한 앞섬(rushing)과 늦춤(dragging)이 연주에 생동감과 그루브를 더해 준다.다. 

16 subdivision에 딱 맞게 tom을 치면 도저히 그 느낌이 나지 않는다.

자체 정의한 ORN 파일을 쓰면 거의 모든 예외적인 노트를 수용하여 재생하도록 만들 수 있다. 그러나 ALLSTARS.MID를 분석하면서 예외적인 상황이 너무나 많음을 확인하였다. 이 MIDI 파일은 패턴 재사용 목적이 아니라 GS 음원의 우수함과 표현력을 최대한으로 끌어내기 위해 만든 것이니 당연히 그럴 수 있다. 하지만 이를 과도하게 추상화하면 작곡가/연주가의 의도를 훼손하기 쉽다. 그렇다고 해서 MIDI 파일 수준의 세부적인 정보를 그대로 유지한다면 ADX 플랫폼의 단순함이라는 최대 장점이 사라진다.

바로 이 지점에서 추상화의 손익계산이 시작된다. ADX는 드럼 패턴의 본질을 추출하기 위해 여러 악기를 12개의 슬롯으로 통합하고, 시간을 일정한 그리드로 양자화하며, 연속적인 velocity를 몇 단계의 accent로 단순화한다. 이러한 추상화는 패턴을 비교하고 분류하기 쉽게 만들어 주지만, 그 대가로 연주자가 의도적으로 만들어 낸 미세한 타이밍과 다이내믹의 일부는 잃게 된다.

흥미로운 점은, 잃어버린 정보가 반드시 중요하지는 않다는 것이다. 오히려 대부분의 경우 추상화된 패턴만으로도 원래의 리듬적 특징은 충분히 유지된다. 반면, 이번 예제처럼 그리드에서 살짝 벗어난 몇 개의 note를 발견하면 원본 MIDI를 다시 들어 보고, 왜 연주자가 그렇게 표현했는지 살펴보게 된다. PatternLab는 단순히 양자화를 수행하는 도구가 아니라, 추상화 과정에서 무엇을 잃고 무엇을 얻는지를 눈으로 확인하게 해 주는 분석 도구인 셈이다.

많은 사람들이 추상화를 "정보 손실"이라고 생각한다. 그러나 소프트웨어 공학에서 추상화는 복잡성을 줄이는 가장 강력한 도구라고 한다. ADX 생태계는 실제 연주가 아니라 음악이라는 정보를 전달하기 위해 만든 것이다. 악보가 하나라고 해서 모든 사람이 다 같은 스타일로 연주하는 것은 아니다.

추상화를 통해 정보를 일부 잃었지만 그 대가로 패턴의 비교, 분석, 검색, 교환, 재생이라는 새로운 가능성을 얻었다. 잃은 정보 중 정말 필요한 것은 ORN이라는 sidecar 파일을 통해서 되살릴 수 있다. 

추상화는 단순화가 아니라 목적에 맞게 정보를 재구성하는 과정이다.

그리고 ALLSTARS.MID는 학습용으로는 아주 좋으나, 재사용 목적의 패턴 추출용으로는 너무 까다롭고 복잡한 드럼 연주 정보를 갖고 있다.

검증은 보는 것에서 시작한다—ADC PatternLab 개발

PatternLab 결과물(실제 분석 보고서: 6BLUES, 6RANDB)

Type 0 MIDI 파일(.MID) 형태의 드럼 연주 패턴 데이터를 나의 '드럼 패턴학(Drum Patternlology)' 생태계에 집어넣기에 앞서서 파일 전체를 사람의 눈으로 확인하고 싶다는 생각이 들었다. 이 욕심을 실물로 구현한 것이 바로 adc-patternlab.py이라는 파이썬 스크립트이다. 스크립트의 이름은 (Drum) Pattern Lab, 즉 드럼 연주 패턴을 분석하는 실험실이다. 이 도구를 이용하여 커맨드라인에서 분석을 실시하면 HTML 결과 파일이 만들어지는데, 이를 웹 브라우저에서 열면 MIDI 이벤트 데이터를 있는 시각화한 화면과 매트릭스 형태로 변환한 화면을 전환하며 볼 수 있다. 철저히 비침습적으로 구동되며, 원본 MIDI 파일의 2-bar 단위 분할과 ADT/ADP 전환은 다른 도구가 맡는다.

Subdivision 분석을 통해 straingt/triplet-8/triplet-16을 구별하는 알고리즘도 실 데이터로 계속 테스트를 거치면서 더욱 고도화되었다. 처음에는 노트의 시작 시간(Note On Time)만 참고하였으나, 노트의 길이(duration) 또한 꽤 좋은 힌트가 됨을 알게 되었다. 패턴을 처음 생성했던 사람이 만약 DAW에서 작업을 했다고 가정해 보자. 셋잇단음표 체계의 리듬이라면(예: 블루스 또는 셔플), 삼등분 체계의 그리드를 만든 뒤 거기에 음표를 채우지 않았겠는가. '스윙'이라는 이름의 파일 안에 각 비트마다 킥과 스네어를 한 번씩만 타격한 패턴이 있다고 가정하자. Note on time으로는 스트레이트인지 트리플렛인지 알 수가 없다. 그러나 note duration이 1/3박자라면 triplet-8임이 명백해진다. Tick으로 계산해도 되지만, duration이 한 박자의 몇 %인지를 보는 것이 더 간단하다.

메타데이터, 즉 파일 자체에 붙어 있는 장르명 힌트도 매우 강력한 근거가 된다.

다음 그림은 작년말에 어설프게 만들었던 패턴 이미지이다. 지금 생각하면 대단히 부끄러운 수준이고 오류도 많았다. 그러나 이런 어설픔이 쌓이고 쌓여서 최근 며칠 동안 급격한 발전을 이루었다. Fluid Ardule에서 드럼 패턴 재생을 해 보겠다고 옆길로 새지 않았다면, 과거의 부족함과 오류를 발견하지 못한 상태로 그냥 방치하였을 것이다.

Pattern Lab은 단순한 시각화 도구를 넘어 grace/ghost note 및 flam 후보까지 찾아낸다. 최종 결정은 사람의 몫이다. 구현이 가장 시급한 flam이 경우 별도의 sidecar file을 써서 ADP 파일의 재생 시에 원래의 연주 의도를 그대로 표현하게 만드는 초기 테스트에도 성공하였다. 한 마디를 16 또는 24 스텝으로 추상화한 나의 드럼 패턴학 생태계에서 flam의 구현은 애초에 불가능하다고 생각했었으나 전혀 그렇지 않았다. 그러나 실제로는 그렇지 않았다. ADP는 최대한 단순하게 하되, 연주에 맛깔스럽게 양념을 치는 부가 정보는 sidecar file로 보완하면 단순한 스텝 기반 패턴에서도 실제 연주에 가까운 표현이 가능했다.

이처럼 PatternLab은 단순히 MIDI 파일을 읽어 보여주는 프로그램이 아니라, 사람의 눈으로 데이터를 검증하고 알고리즘을 개선하는 실험실(Laboratory) 역할을 담당하고 있다. 결국 좋은 자동화는 충분한 관찰에서 시작된다. PatternLab 역시 "먼저 본다. 그리고 이해한다. 그 다음에 변환한다."는 원칙 위에서 조금씩 진화하고 있다.

데이터 분석을 통해 음악 장르에 따라서 널리 쓰이는 드럼/타악기 세트(12개 이내)를 다음과 같이 확정한 것도 큰 성과이다. 약간의 추상화를 거치면 GM 드럼 표준 배열에서 12개로 충분하다!

Slot map definition. 원본에 해당하는 JSON 파일은 여기에 있다.

[부록] Subdivision 판정과 confidence 계산

PatternLab은 드럼 패턴의 subdivision을 단순히 음표가 놓인 위치만으로 결정하지 않는다. 현재 구현에서는 각 후보에 대해 note-on 위상, note duration, 입력 MIDI 파일명에 포함된 힌트를 종합하여 점수를 계산한다. 비교 대상은 straight-16, triplet-8, triplet-16이다.

가장 중요한 근거는 note-on의 위상이다. 각 타격이 한 박 안에서 16분음표 격자에 가까운지, 8분 셋잇단음표 또는 16분 셋잇단음표 격자에 가까운지를 조사한다. 이 위상 분석이 전체 판단의 중심이며, 최대 약 70%의 가중치를 갖는다. 박의 시작점과 정확한 반박 위치처럼 straight와 triplet에 공통으로 나타나는 지점은 판별력이 없으므로 증거에서 제외한다. 또한 flam으로 추정된 선행 grace note도 subdivision 판정을 흐리지 않도록 분석 대상에서 제외한다.

Note duration은 보조 증거로 사용한다. 음표 길이가 16분음표, 8분음표 또는 4분음표 계열에 가까우면 straight 후보에 점수를 주고, 1/3박·2/3박 또는 1/6박 계열에 가까우면 해당 triplet 후보에 점수를 준다. MIDI 드럼 파일에서는 note duration이 연주 의도를 정확히 반영하지 않는 경우도 많으므로, 이 항목의 영향은 최대 약 22%로 제한하였다.

파일명도 제한적으로 참조한다. 예를 들어 파일명에 straight, 16th, 16beat가 있으면 straight 후보에, shuffle, swing, triplet, 8T, 16T가 있으면 해당 triplet 후보에 추가 점수를 준다. 다만 파일명은 잘못 붙을 수도 있으므로, 실제 note-on 위상보다 우선하지 않는 보조 정보로만 사용한다.

세 종류의 근거를 합산한 뒤 가장 높은 점수를 얻은 후보를 1위, 그다음 후보를 2위로 정한다. 최고 점수가 너무 낮으면 unknown, 1위와 2위의 점수 차이가 작으면 mixed로 판정한다. 명확한 승자가 있을 때 confidence는 다음과 같이 계산한다.

confidence = (1위 점수 - 2위 점수) / (1위 점수 + 2위 점수)

이 값은 단순히 1위 점수가 얼마나 큰지를 나타내는 것이 아니라, 1위가 가장 유력한 경쟁 후보를 얼마나 확실하게 앞서는가를 나타낸다. 예를 들어 1위가 0.80, 2위가 0.20이면 confidence는 0.60이다. 반면 1위가 0.80이라도 2위가 0.70이면 confidence는 약 0.067에 불과하다. 즉, 절대 점수가 높더라도 두 후보가 팽팽하면 낮은 confidence가 부여된다.

이러한 계산은 subdivision 판정을 절대적인 정답으로 선언하기 위한 것이 아니다. PatternLab의 역할은 사람이 전체 MIDI 파일을 검토하기 전에 가장 가능성 높은 격자를 제안하고, 애매한 패턴을 낮은 confidence로 표시하여 재검토가 필요한 부분을 드러내는 데 있다.

드럼 패턴 데이터의 추상화와 정규화

드럼 연주 기능을 고리로 하여 과거(Nano Ardule, 과거라고 해 봐야 너무나 가까운 반년 전이지만)와 현재(Fluid Ardule)의 통섭이 일어나고 있다고 아주 좋아하고 있었다. 그 즐거움은 며칠 가지 않았다. 과거의 작업 결과물이 완벽하지 않았음을 깨닫는 계기가 되고 말았으니까. 고쳐야 할 곳이 꽤 많아져서 약간은 망연자실한 상태이다.

Nano Ardule 개발 시절에 내가 확립해 둔 드럼 패턴 체계는 오직 4박자를 위한 것이었다. 4박자만큼은 아니더라도 널리 쓰이는 3박자(예: 왈츠), 그리고 5박자나 7박자 같은 비정형 박자를 다루려면 드럼 패턴 체계 자체를 근본적으로 뜯어고쳐야 한다고 생각하고 있었다. 그런데 막상 Fluid Ardule에 드럼 재생 기능을 넣으면서 살펴보니 과거에 만든 체계가 꽤 견고하고 합리적이라서 3박자나 비정형 박자를 처리하는데 별다른 문제가 없었다. 

게다가 더욱 까다롭게 생각했던 flam 처리도 sidecar 파일 방식으로 어렵지 않게 구현할 수 있었다. 이러한 결과에 만족하면서 flam이 포함된 왈츠 패턴 하나를 재생하고 있는데 tom 소리가 빠져 있는 것이 아닌가? 분명히 이미지로 만든 패턴 정보에는 low 계열의 tom을 3박째에서 2회(8분음표) 두드리고 있는데 처리가 끝난 ADT/ADP에서는 소리가 들리지 않는다.

원본 MIDI 파일에는 분명히 노트가 남아 있었다. 원인을 찾아 보았다. Tom 계열의 노트를 처리하면서 누락이 된 것이었다! 현재 사용하는 12개 slot 정보는 다음과 같다.

SLOT0=KK@36,KICK
SLOT1=SN@38,SNARE
SLOT2=CH@42,HH_CL
SLOT3=OH@46,HH_OP
SLOT4=LT@45,TOM_L
SLOT5=MT@47,TOM_M
SLOT6=HT@50,TOM_H
SLOT7=RD@51,RIDE
SLOT8=CR@49,CRASH
SLOT9=RM@37,RIM
SLOT10=CL@39,CLAP
SLOT11=PH@44,HH_PED

Tom은 High-Middle-Low로 그럴싸하게 배열해 놓았지만, 노트 번호를 미련하게 할당한 것이다. 원본 MIDI 파일에서는 노트 번호 43번으로 low tom(실은 high floor tom)이라고 기록되어 있었는데, 내가 쓰는 슬롯 정보에서는 이 번호가 슬그머니 사라진 것이었다. 

Rack tom의 가장 낮은 것이라 해도 floor tom의 high보다는 높은 소리를 내는데, 타악기 명의 앞부분만 보고서 애초에 tom 할당 체계를 잘못 잡은 것이다. Nano Ardule 개발 당시에 만든 스크립트(adc-mid2report.py)를 고쳐서 모든 노트에 대한 분석을 해 보라고 하였다. 이 분석 작업에는 35개의 MIDI 드럼 패턴 파일이 투입되었다.

> python .\260728a_adc-mid2report.py ..\patterns\original-midi-files\
============================================================
Directory: ..\patterns\original-midi-files
MIDI files found: 35   processed: 35   errors: 0
============================================================

Note-On Frequencies (all channels, no grouping):
  total note_on events: 13625
  ch  note  count
  10    36      3244
  10    37       294
  10    38      3009
  10    39        84
  10    42      4160
  10    43       504
  10    44       408
  10    47       652
  10    50       266
  10    51       756
  10    56       248

GM Drum Note Frequencies (channel 10, no grouping):
  note  GM instrument                 count     percent
    36  Bass Drum 1                       3244    23.809%
    37  Side Stick                         294     2.158%
    38  Acoustic Snare                    3009    22.084%
    39  Hand Clap                           84     0.617%
    42  Closed Hi-Hat                     4160    30.532%
    43  High Floor Tom                     504     3.699%
    44  Pedal Hi-Hat                       408     2.994%
    47  Low-Mid Tom                        652     4.785%
    50  High Tom                           266     1.952%
    51  Ride Cymbal 1                      756     5.549%
    56  Cowbell                            248     1.820%
  total: 13625

실제 데이터에서는 43(High Floor Tom)-47(Low-Mid Tom)-50(High Tom)을 tom 계열의 노트로 사용하고 있다. 그런데 내가 만든 slot 체계에서는 45(Low Tom)-47-50이었다. 널리 쓰이는 43번이 아예 사라지도록 잘못 설계한 것이다. 근거가 되었던 계산적 드럼 패턴학('computational drum patternology' - 아마도 내가 처음 쓰기 시작한 말)에서 잘못된 분석을 하는 바람에 tom의 대표음을 엉뚱하게 배치하는 결과를 초래하였다. 추상화(abstraction)과 정규화(normalization)를 제대로 하지 않는 값을 치르고 있는 셈이다.

올바른 계산적 드럼 패턴학을 위해서는 추상화를 통해 실제 악기의 사용 현황을 조사해야 한다. 그 다음에는 성격이 비슷한 악기를 그룹화한 다음, 정규화를 통해서 각 그룹에 대해 가장 대표성이 높은 악기를 대표 노트로 선택한다. 그런데 오늘의 분석 작업에서는 총 11개의 노트가 쓰였다. 즉, 12개라는 slot 제한을 초과하지 않았다. 따라서 악기를 그룹으로 묶거나 대표 노트를 고를 일도 없었던 것이다. 

물론 앞으로 더 많은 데이터를 분석해 봐야 하겠지만, 오늘의 작업만으로도 실제 데이터가 어떤 경향이 있는지를 충분히 파악할 수 있었다.

과거의 잘못을 들추어냄에 따라서 해야 할 일도 많아졌다. Nano Ardule의 온갖 유틸리티 스크립트를 고쳐야 하고, ADT 안에 하드코딩되어 있던 슬롯 정보도 바꾸어야 하며, 패턴 이미지 파일도 개정하여  GitHub에 올려야 한다. 하지만 오늘이라도 알게 된 것이 어디인가? 

음악과 관련한 취미 코딩을 하면서 추상화와 정규화를 실천하게 된 것을 다행으로 여겨야 하겠다. 음악, 납땜, 코딩, 데이터 분석... 겉으로 보기에 별로 관계가 없어 보이는 일들이 한데 어우려져서 뭔가 산출물을 만들어 내고 이와 더불어 조금씩 나아지고 있는 듯하다.