이제 ReaWwise가 출시되었으니 이 REAPER 확장을 제작한 과정에 대해 공유할 좋은 기회가 왔다고 생각했습니다. 두 부분으로 구성된 이 블로그 시리즈의 첫 번째 부분에서는 ReaWwise 프로젝트의 사전 제작 과정을 다루고 두 번째 부분에서는 이 확장의 개발에 대해 다루게 됩니다.
REAPER를 선택한 이유
게임 오디오 업계는 DAW에 대한 기대치가 높으며 아주 특별한 요구 사항을 필요로 합니다. 대부분의 DAW에서 작업 과정은 타임라인을 기반으로 합니다. 타임라인 기반 작업 과정을 어떻게 상호작용적인 부분에서 활용할 수 있을까요?
다음은 성공적인 게임 오디오 작업 과정을 위한 DAW를 만들 수 있는 몇 가지 요소입니다.
- 다양한 형식의 콘텐츠를 일괄적으로 내보내는 기능
- 커스터마이징할 수 있는 인터페이스 및 작업 과정
- 확장성
- 쉬운 오토메이션 혹은 스크립팅
- 빠르고, 가볍고, 뛰어난 휴대성
REAPER는 이 모든 조건을 충족합니다. REAPER를 제작한 회사인 Cockos는 커뮤니티의 목소리에 귀를 기울여 왔습니다. 바로 이것이 REAPER가 게임 오디오 요구 사항에 대한 DAW의 떠오르는 스타가 된 이유 중 하나일 것입니다.
ReaWwise 개발의 시작
저희는 한동안 REAPER 통합 제작에 대한 아이디어를 가지고 있었습니다. 몇년 전 칼 데이비스(Karl Davis, @karltechno)가 제작한 Reaper-Waapi-Transfer로 이 작업이 시작되었죠 (https://github.com/karltechno/Reaper-Waapi-Transfer). 이 프로젝트는 REAPER에서 Wwise로 오디오 파일을 전송하는 작업 과정이 가능하다는 것을 보여줬습니다. 저희는 이 아이디어를 더욱 발전시키고 접근성을 높이고 싶었습니다.
WAAPI 전송
REAPER가 게임 오디오 커뮤니티 사이에서 주목을 받고 있다는 걸 알고 있었고, 언젠가 변화에 따라야 한다는 것도 알고 있었습니다. 하지만 그 전에 먼저 커뮤니티의 사람들이 REAPER를 어떻게 사용하는지 이해하고 싶었죠.
사용 사례 이해하기
저희는 먼저 두어 개의 스튜디오에 있는 사운드 디자이너를 인터뷰하여 그들의 작업 과정, 콘텐츠 구성 방식, REAPER를 커스터마이징하는 방식을 이해하기 위한 연구를 시작했습니다. 이를 통해 관찰한 내용 중 몇 가지는 다음과 같습니다.
커스텀 사용자 인터페이스: REAPER는 유연성이 뛰어나지만 처음 형태 그대로는 게임 오디오에 최적화된 작업 과정을 제공하지 않습니다. REAPER를 원하는대로 만들기 위해 스튜디오가 사용자 인터페이스와 작업 과정을 커스터마이징하는 데 시간을 투자해야 하죠.
캔버스로 사용되는 타임라인: 대부분의 사용자들이 타임라인을 사운드 디자인을 위한 캔버스처럼 사용했습니다. REAPER는 타임라인 상에서 클립을 쉽게 가져오고 스케치하며 재정렬할 수 있습니다. REAPER는 마찰 없이 자유로운 형식으로 사운드를 디자인할 수 있게 해줍니다.
구역: 보통 타임라인 상에서 개별적인 영역을 구분하기 위해 구역(region)이 사용됩니다. 이 구역은 내보내기(export) 경계선과 대응하는 경우가 많습니다. 또한 메타데이터를 저장하는 데 사용되기도 합니다. REAPER 프로젝트에서 수십 개부터 심지어 수백만 개까지 달하는 구역 존재하는 경우는 흔한 일입니다. 또한 구역 이름이 렌더링 설정에서 사용될 수 있기 때문에 구역 이름에 대한 명명 규칙도 사용하죠. 뿐만 아니라 구역은 서로 다른 변형음과 버전 혹은 state/switch를 구별하는 데에도 사용됩니다. 예를 들어 발걸음 프로젝트에서 구역은 여러 변형음과 여러 표면(콘크리트, 잔디, 돌 등)을 포함할 수 있습니다.
트랙: 수평적 공간이 캔버스로 사용될 뿐만 아니라 수직적 공간은 정리를 위해 사용됩니다. 트랙은 데이터를 구조화하는 데 사용될 수 있습니다. 단순히 재생 시 오디오를 믹싱하기 위해 사용되는 것이 아니죠. 수백 개의 트랙이 담긴 프로젝트도 있고, 여기서 뮤트와 솔로 버튼이 프로젝트의 특정 부분을 포커스하기 위해 사용됩니다.
렌더링 설정: REAPER의 렌더링 설정은 처음에 꽤나 어렵게 느껴질 수 있지만 이 렌더링 엔진은 REAPER를 차별화해주는 기능 중 하나이기도 합니다. 와일드카드 시스템은 렌더링 엔진을 아주 강력하게 만들어주죠. 와일드카드는 한 번에 수백 개의 WAV 파일의 명명 규칙을 설정하고 일괄적으로 내보내는 데 광범위하게 사용됩니다.
구역 렌더링 매트릭스: 이 또한 어렵게 느껴질 수 있지만 구역 렌더링 매트릭스(region render matrix)는 렌더링할 트랙과 구역을 설정할 수 있게 해줍니다. 이 매트릭스를 사용하면 렌더링 시 프로젝트의 어느 부분을 함께 믹싱할지를 지정할 수 있습니다.
하위 프로젝트: 큰 데이터를 관리하기 위해 하위 프로젝트를 사용하는 스튜디오도 몇몇 보았습니다. 하위 프로젝트는 콘텐츠의 추상화 및 구성에 사용할 수 있습니다. 또한 하위 프로젝트는 대규모 팀에서 작업을 분할하고 소스 컨트롤에서 충돌을 최소화하는 데에도 유용하게 사용됩니다.
커스텀 스크립트: ReaPack과 다른 배포 시스템을 통해 다양한 스크립트가 이미 공개 제공되고 있지만 많은 사용자들이 자신만의 스크립트를 개발했습니다. ReaScript는 처음에 조금의 프로그래밍 지식을 필요로 할 수 있지만 여전히 REAPER를 커스터마이징하기 위해 접근성이 좋은 시스템입니다.
첫 번째 프로토타입
사람들이 REAPER로 무엇을 하고 어떻게 사용하는지 더 잘 이해한 후, 통합이 높은 수준에서 어떤 것을 할 수 있어야 하는지 정의하기 시작했습니다. 이에 따라 다음 두 가지 주요 목표를 결정했습니다.
- 렌더링된 WAV 파일을 Wwise로 가져오기.
- 렌더링된 파일로 Wwise 오브젝트 구조 생성하기.
또한 UX에 관한 몇 가지 목표도 있었습니다.
- 한 번 설정된 이후에는 반복 작업이 빨라야 함.
- 명명 규칙에 대한 강력한 제어력.
첫 번째 데모를 위해 'FS'라는 REAPER 프로젝트를 마련했습니다. 이 프로젝트에는 두 개의 구역과 두어 개의 트랙이 있습니다.
FS REAPER 프로젝트의 타임라인
두 개의 WAV 파일을 구역 마다 하나씩 생성하고 다음 와일드카드를 사용할 경우를 가정해보겠습니다.
- $project: REAPER 프로젝트 이름인 'FS'가 됨.
- $regionnumber: 구역 번호인 '1'과 '2'가 됨.
REAPER 렌더링 설정
이제 WAV 파일을 Wwise로 가져오기 위해서는 WAAPI와 ak.wwise.core.audio.import 함수(https://www.audiokinetic.com/library/edge/?source=SDK&id=ak_wwise_core_audio_import.html)를 활용하는 것이 확실한 방법이라고 느껴졌습니다. 이 함수는 Tab Delimited Text Import(탭으로 구분된 텍스트 가져오기) (https://www.audiokinetic.com/library/edge/?source=Help&id=importing_media_files_from_tab_delimited_text_file)와 핵심 코드가 같습니다.
이를 설명하기 위해 Random Container와 두 사운드를 정의하는 탭으로 구분된 가져오기 파일의 예시를 함께 살펴보겠습니다. 이 작업은 WAAPI에서도 실행할 수 있습니다.
|
오디오 파일 |
오브젝트 경로 |
|
C:\wave\REAPER\FS_GRASS_01.wav |
\Actor-Mixer Hierarchy\Default Work Unit\<Random Container>FS_GRASS\<Sound SFX>SFX_FS_GRASS_01 |
|
C:\wave\REAPER\FS_GRASS_02.wav |
\Actor-Mixer Hierarchy\Default Work Unit\<Random Container>FS_GRASS\<Sound SFX>SFX_FS_GRASS_02 |
이는 다음 계층 구조를 생성합니다.
Wwise에서 생성되는 계층 구조
이 후 REAPER가 와일드카드 시스템을 사용하여 WAV 파일의 이름을 지정할 수 있게 해준다면 비슷한 방법으로 Project Explorer에 나타날 Wwise 오브젝트의 이름을 사용해보는 것을 시도하는 것이 자연스럽다고 생각했습니다. 왜냐하면 궁극적으로 이들이 서로 어떻게든 관련이 되어야 했으니까요. 사용자들은 WAV 파일과 Wwise 오브젝트 모두의 명명 규칙을 제어할 수 있어야 합니다.
따라서 Object Path 열을 생성하는 와일드카드 레시피는 다음과 같습니다.
\Actor-Mixer Hierarchy\Default Work Unit\<Random Container>$project\<Sound SFX>SFX_$project_$regionnumber
이렇게 저희는 ReaScript 가 제공해야 하는 내용을 탐험해봤습니다. REAPER가 자신의 와일드카드를 Render settings가 아닌 임의의 문자열로 결정하도록 할 수 있는지를 알고 싶었죠. 하지만 불가능했습니다. 그래서 아주 시험적인 방법을 시도해봤습니다.
1. Render settings에서 file name 입력란 값을 백업합니다.
2. 요청된 Wwise Object Path를 Render settings의 file name에 설정합니다.
3. 렌더링된 파일 이름을 쿼리합니다 (더 이상 파일 이름이 아니라 결정된 Object Path임).
4. Render settings에서 이전의 file name 을 다시 회복합니다.
짜잔! 작업은 성공적이었습니다. 원래 여러 REAPER 와일드카드를 가지고 있던 Object Path를 결정할 수 있었죠. 하지만 이 방법을 그대로 사용하기엔 너무나도 시험적이었습니다. REAPER UI가 깜박이고, Render settings의 무결성이 손상되었습니다.
REAPER 팀으로부터의 도움
그래서 저희는 Cockos 팀에게 문의하여 저희 목표에 대한 도움을 얻고자 했습니다. 다음 내용을 문의했죠.
ReaScript에서 렌더링된 각 파일의 REAPER 와일드카드가 담긴 임의의 문자열을 결정할 수 있는 함수를 노출시켜줄 수 있을까요?
Cockos 팀은 너무나 빠르게 대응해주었고 이 기능이 담긴 빌드를 바로 제공해주었습니다. 저희도 이 빌드가 잘 작동한다는 것을 곧바로 확인했죠. 그리고 REAPER의 다음 버전에 이 새로운 기능이 추가되었습니다. Cockos의 존 슈와르츠(John Schwartz)와 저스틴 프랭켈(Justin Frankel)에게 진심으로 감사드립니다! 최고예요!
다음은 와일드카드가 담긴 또다른 가져오기 표현식을 오브젝트 경로로 결정하는 초기 프로토타입입니다.
ReaWwise의 초기 프로토타입
가져오기 후 다음 구조가 Wwise에서 생성됩니다.
ReaWwise에 의해 생성된 Wwise 계층 구조
이 시점에서 저희는 목표를 성취할 수 있을 것이란 확신이 들었습니다. 다음으로 해야 할 것은 추후 확장의 사용자 경험을 작업하는 것이었습니다.
사용자 경험 (UX)
그래서 저희는 사용자 경험 반복 작업을 시작했습니다. 초기 프로토타입처럼 코드에서 작업하지 않고, 대신 고정적인 모형을 사용해서 작업했습니다. 모형은 빠르게 반복 작업할 수 있다는 점에서 훌륭하죠. 저희는 이 확장에 대한 사용자 인터페이스의 초안을 시작했습니다. 관련된 여러 사람들과 논의를 거치고 두 주간의 반복 작업을 거쳤습니다.
다음은 저희 작업 과정의 결과를 보여주는 초기 콜라주 모형입니다.
개발 도중 제작한 ReaWwise의 모형
어느 시점에서는 더 많은 가정을 검토하고 실제 REAPER 프로젝트에서 여러 아이디어를 시험해보기 위해 코드로 돌아가기도 했습니다. 이번에는 WAAPI-transfer 코드에서 직접 새로운 프로토타입을 만들었습니다. 이 코드는 Visual C++ 구성, Win32 windows 초기화, REAPER 핸드쉐이크, WAAPI 커뮤니케이션 등이 이미 구현되어 있습니다.
ReaWwise의 또 다른 프로토타입
이 프로토타입은 반복 작업과 데모를 거치고 내부적으로 공유되었습니다. 이제 올바른 방향으로 가고 있다는 확신이 더 커졌죠. 이제 이 프로젝트를 현실화하고 로드맵에서 프로젝트를의 시간을 계획해줄 팀이 필요했습니다.
다음 글에서 계속됩니다.
이 블로그 시리즈의 마지막 부분이기도 한 다음 글에서는 이 확장의 개발을 집중적으로 살펴보게 됩니다. 프로토타입 후 어떤 일들이 일어났는지 알게 될 거예요. 이 부분은 ReaWwise의 주요 개발자인 앤드류 코스타(Andrew Costa)가 진행합니다.
댓글