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

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