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)이라는 생태계 안에서 자리를 잡아 가는 느낌이다.

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

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

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

아두이노 자작품을 만들면서 얻은 교훈 - 코딩은 기다림이다!

소프트웨어 개발 절차는 보통 다음의 6가지 절차로 이루어진다고 한다.

1. 요구사항 분석(Requirement Analysis)
2. 시스템 명세
3. 설계(Design)
4. 프로그래밍(Programming)
5. 테스트(Testing)
6. 유지보수(Maintenance)

현재는 데이터 센터와 유사한 성격의 곳에서 일을 하고 있노라니 1번 단계, 즉 개발자가 사용자를 만나서 인터뷰를 수행하는 모습을 곁에서 많이 접하게 된다. 프로젝트의 성격이 단순하다면 이러한 6가지의 단계를 다 거칠 필요는 없고, 몇 가지 단계가 한꺼번에 뭉쳐서 진행되기도 한다.

아두이노 나도 응용 DIY 제품을 구동할 용도로 프로그램을 만드는 것도 비교적 단순한 소프크웨어 개발 절차라고 할 수 있다. 프로그램 코드를 저장하고기 위해 마련된 플래시 메모리의 공간이 32KB에 불과한 아두이노 나노에 채워 넣어야 하는 코드가 아무리 방대하고 복잡한들 그게 얼마나 되겠는가? 

C/C++ 문법도 잘 모르는 내가 아두이노 나노로 구동되는 MIDI sound module 제어기('Nano Ardule MIDI Controller')용 코드를 짜고 있다니 생각해 보면 정말 말도 안되는 일이다. 제어 대상은 본 블로그에서 여러 차례 소개했던 SAM9703 기반의 반주기 개조품(유튜브 링크).

그런데 그게 정말 현실에서 일어나고 있다. 필요한 기능을 챗GPT 대화창에 입력해 넣으면, 이를 실행하게 해 주는 .ino 파일을 생성하여 통째로 다운로드할 수 있게 만들어 주기 때문이다.

기다림은 바로 이 과정에서 필요하다. 챗GPT가 생각을 하고 코드를 짜 주는 동안 기다려야 한다. 문제는 이렇게 하여 제공한 코드가 항상 잘 컴파일이 되지는 않는다는 것이다. 중괄호를 빼먹는 것으로부터 선언하지 않은 변수나 함수가 쓰인다든지... C/C++을 잘 이해하는 사람이라면 아두이노 IDE에서 뱉어내는 에러 메시지만 보고서 금방 소스 코드를 수정할 터인데, 나와 같은 코딩맹(盲)은 에러 메시지를 그대로 복사하여 챗GPT에 붙여 넣은 뒤 문제를 파악하고 개선한 코드 파일을 다시 제공할 때까지 기다려야 한다. 

그런데 내가 봐도 똑같아 보이는 실수를 계속 반복하는 모습을 보고 있노라면 부글부글 속에서 뭔가 치밀어 오르는 답답함을 느낀다. 그러면 또 컴파일 중에 나오는 오류 메시지를 복사해서 제출하고, 기다리고... 그래서 코딩은 기다림이다. 지루한 반복 작업을 견디다 못한 나는 가장 마지막에 컴파일 및 작동에 성공한 코드 파일을 업로드한 뒤 여기에 추가 기능을 단계적으로 더해 나가는 방식으로 전환하였다. 너무 많은 양의 요구사항을 들이대면 실수를 많이 하는 것 같다. '잘 되고 있는 것은 건드리지 말아라'라는 식의 너무나 당연하고도 구체적인 요구를 때로는 해야 한다.

챗GPT는 마치 머리는 꽤 좋은데 가끔 딴생각을 하고 주위가 산만한 천재를 대하는 것 같다. 가끔 고집도 피운다. 그러나 조금만 마음을 가다듬고 생각해 보면 챗GPT가 없이 과연 내가 이런 취미 프로젝트를 단 한 발자국도 실현해 나갈 수 없었을 것이다. 그러니 다소 오류가 포함된 소스 코드를 반복적으로 토해 내더라도 무한한 인내심을 발휘해야 한다. 예를 들어 버튼을 한번 클릭할 때와 길게 눌렀을 때 서로 다른 동작을 하게 만드는 코드를 내 창의력과 검색만으로 짠다고 생각해 보라. 가당키나 한 일이겠는가. 1602 LCD, 4개의 LED, 5개의 버튼, 로터리 인코더... 시프트 레지스터 칩를 쓰지 않은 상태에서 아두이노 나노의 모든 입출력 핀을 전부 사용해야 하는 데다가, 메뉴 구성도 결코 단순하지 않기 때문이다.

끊이지 않는 버그, 머리를 쥐어뜯고 싶다!

테스트를 하는 과정에서 비합리적이거나 무리한 요구사항을 재정의하여 개선하는 일도 흔히 벌어진다. 모든 부품을 기판 위에 전부 올려서 배선을 한 날, 이것이 마지막 납땜이라고 호기롭게 자신했지만 그 뒤로 몇 번이나 회로 수정을 했는지 모른다. 코딩 역시 마찬가지다. 정의해 놓은 기능을 단계적으로 구현해 나가는, 즉 절대로 우회나 후진은 하지 않으면서 프로젝트가 진행될 것이라고 생각했으나 그것은 헛된 기대였다. 다시 중간 지점으로 돌아가서 기능을 다시 정의하는 일이 허다하게 벌어지고 있다.

현재 소스 코드의 분량은 700줄 정도이다. 마이크로SD카드에 데이터를 쓰고 읽는 기능까지는 아직 구현하지 못한 상태다. 바로 어제까지 작업하여 MIDI IN으로 들어오는 단일채널 키보드 신호를 MIDI 사운드 모듈의 2개 채널로 복제하여 보내는 것에 성공하였다. 채널은 서로 다른 악기(program)으로 할당해 둔 뒤, 버튼을 눌러서 어느 하나만 연주하거나 layer 또는 split이 가능하게 만들었다. Korg의 방식으로 말하자면 두 개의 프로그램으로 이루어진 심플한 'combi' 음색을 만들 수 있는 것이다. 보람이 느껴지지만 몸은 고단하다.

돌이켜보니 연기를 피우며 납땜을 할 때, 즉 하드웨어를 제작하던 단계가 훨씬 덜 고되었던 것 같다. 정신건강까지 고려한다면 하드웨어 제작단계가 건강에 미치는 영향은 코딩 단계보다 더 적은 것이 아닐까...

'몰입'은 즐거운 일이다. 그러나 몸과 마음을 너무 갉아먹을 정도라면 이야기는 달라진다. AI가 사람의 수로고움을 대신한다고? 어떤 측면에서는 옳다. 그러나 결과적으로 일을 더 하게 된다. 아무래도 다음번 글의 주제는 'AI가 촉발한 과몰입(또는 과노동)'이 될 것 같다.