[VST 개발] 전반적인 폴더 트리 구조 및 튜토리얼 따라하기 (1)

VST SDK 의 공식문서에서 제공하는 튜토리얼을 따라해보면서

전반적인 프로젝트 트리 구조와 신호를 받아서 어떻게 처리하는지 살펴보고자 한다

* 혹시나 이 글을 다른 누군가 보게 될지도 모르기 때문에, 참고해서 말을 하자면 나는 C++ 를 정석적으로 공부한 사람이 아니다
그리고 여기에 적고 있는 모든 글들은 혼자서 VST SDK 의 공식문서와 샘플들을 찾아 보면서 내 나름대로 터득하기 위함이다
그렇기 때문에 C++ 에 관련된 설명이나, 기본적인 구조는 정석적으로 공부한 분들의 조언을 구하길 바란다
그리고 내가 설명하는 개념이 틀릴 경우 언제든 댓글을 달아주었으며 한다(그러면서 나도 실력이 느는거니깐)
나야 계속 공부하면서 고치면 되지만 이 글을 보고 누군가가 잘못된 개념을 가지게 된다면 너무 슬플것같다

그럼 이제 하나씩 차근차근 살펴보도록 하자

초기 Generator 세팅은 다음과 같다

 

Audio Effect 로 설정하고, 트리 구조 파악을 위해 VSTGUI를 사용하지는 않았다

---

먼저 기본적으로 프로젝트를 생성했을 때, 자동으로 만들어지는 파일은 다음과 같다

 

XCode에서 만든 프로젝트를 열면, Header Files, Source Files, Resources 라는 이름의

폴더를 확인할 수 있고, 각 폴더는 다음과 같은 기능을 하는 것으로 보여진다

 

1. Header Files 에는 기본적으로 SDK 가 제공하는 클래스들을 선언해주거나,
사용자가 만들 파라미터들을 선언해주는 파일들로 구성되어 있다

 

2. Source Files 에는 실제로 VST가 구동될 때, 실행될 명령들로 구성되어 있다

 

3. Resources 는 VST에서 필요한 리소스(그림, 샘플 등)들을 저장해놓은 폴더이다

 

* CMakeLists.txt는 초기에 프로젝트를 만들때, 사용하는 빌드 명령어로 Project Generator 가 자동으로 만들어준 파일이다.

 

그리고 각 폴더에는 다양한 이름의 파일이 존재한다.

먼저, Header Files에 생성된 파일들부터 살펴보자

 

• cids.h : 전체 VST의 ID를 선언해주는 파일이다. ID란 VST 자체뿐만 아니라, VST 안에 포함되어 있는 모든 파라미터 값에도 적용될 고유 번호이다.
• controller.h : VST에서 사용하는 모든 파라미터(예 : 음량 슬라이더, 바이패스 버튼 등)의 초기화 및 상태, 동작 등에 대한 함수를 선언해준 파일이다
• processor.h : VST에서 사용하는 모든 프로세스(예 : 음량을 조절하는 기능, 전체 프로세스를 바이패스 설정/해제하는 기능)의 초기화 및 상태, 동작 등에 대한 함수를 선언해준 파일이다
• version.h : 현재 만들고 있는 프로젝트의 설명 및 버전 번호를 선언해주는 파일이다

다음에는 Source Files를 보도록 하자

 

• entry.cpp : 현재 프로젝트의 빌드시 진입점들을 작성해둔 파일로 보인다(이 부분은 불분명하므로 조금 더 공부가 필요하다)
• controller.cpp : 사용자가 파라미터를 만들고 이에 대해 어떻게 동작하게 할것인가 혹은 어떤 동작일 때, 어떤 명령을 수행할 것인가를 작성하는 파일이다
  (말이 어려운데, 간단하게 설명하자면 VST 에서 "보여지는 부분" 을 담당한다고 이해하면 된다)
• processor.cpp : 사용자가 오디오 신호에 대해서 원하는 동작과 상태에 대한 명령을 작성하는 파일이다
  (역시 간단하게 설명하자면 VST 에서 "들리는 부분" 을 담당한다고 이해하면 된다)
• macmain.cpp : XCode 프로젝트로 만들었기 때문에 이 파일이 생성되는 것으로 보인다. macOS의 CoreFoundation을 통해, 번들 정보를 제대로 전달하기 위함으로 보인다(이 부분은 불분명하므로 조금 더 공부가 필요하다)
  => 맥에서는 빌드하거나 배포할 때, 보안성을 위해 번들 식별자(Bundle Identifier)가 누구인지 파악하고, 승인되었는지 확인하는 작업을 한다. 아마 이것때문에 필요한 것으로 보인다.

대략 이런 구조로 되어있다. 나와 같은 초심자들이 보자마자 바로 파악하기엔 그리 쉽지 않다

바로 이해되지 않는 것들은 Class Reference 를 찾아보면서 이해하려고 노력하고 있다

아래 링크에서 궁금한 헤더 파일이나, 명령어를 입력하면 관련된 설명을 확인할 수 있다

https://steinbergmedia.github.io/vst3_doc/vstsdk/

VST 3 SDK: Introduction

---

이제 VST SDK 에서 제공하는 그림 하나를 보면서 찬찬히 살펴보도록 하자

 

출처 : https://steinbergmedia.github.io/vst3_doc/

이게 기본적인 VST3 프로젝트의 구성이라고 한다

VST3 프로젝트를 디자인할 때, Processer와 Controller 로 나누어서 설계하는 것을 추천한다고 한다

이게 무슨 말인가 싶어 원문을 찾아보면 다음과 같이 설명하고 있다

The design of VST 3 suggests a complete separation of processor and edit controller by implementing two components. Splitting up an effect into these two parts requires some extra implementation efforts.
However this separation enables the host to run each component in a different context, even on different computers. Another benefit is that parameter changes can be separated when it comes to automation.
While for processing these changes need to be transmitted in a sample-accurate way, the GUI part can be updated with a much lower frequency and it can be shifted by the amount that results from any delay compensation or other processing offset.

VST 3의 설계에서는 프로세서와 편집 컨트롤러를 두 가지 구성 요소를 구현하여 완전히 분리할 것을 제안합니다.

이 두 부분으로 효과를 분할하려면 몇 가지 추가 구현 노력이 필요합니다.
그러나 이러한 분리를 통해 호스트는 서로 다른 시스템에서도 각 구성 요소를 다른 컨텍스트에서 실행할 수 있습니다.

또 다른 이점은 자동화 시 매개 변수 변경을 분리할 수 있다는 것입니다.

이러한 변경 사항을 샘플로 정확하게 전송해야 하는 반면, GUI 부분은 훨씬 낮은 주파수로 업데이트될 수 있으며 지연 보상 또는 기타 처리 오프셋의 결과로 발생하는 양에 따라 이동할 수 있습니다.

파파고로 번역을 돌려보았다

무슨 소리인가 싶다(저건 영어를 잘하고 못하고의 문제가 아니다. 물론 난 영어를 못하지만)

 

요점은 간단하다.

Processor와 Controller 파트를 분리해서 설계하면 다음과 같은 좋은 점이 있다고 한다

1. 서로 다른 컨텍스트와 컴퓨터에서 실행 가능
: 쉽게 말해 DAW에서 우리가 만든 VST를 여러트랙에 걸었을 때, 혹은 그럴일은 없지만 Cubase, Logic, Ableton Live 를 모두 실행한 뒤, 우리가 만든 VST를 트랙에 적용했을 때 실행이 가능하다는 점

이런식으로 여러 트랙에 거는게 가능

2. 오토메이션할 때, 변화량을 분리할 수 있다

: 사용자의 의도에 따라 값이 자동으로 변화되는 것을 오토메이션이라고 한다. 예제는 아래와 같다

오토메이션 커브(화면 중앙 파란색)에 따라 오른쪽 Gain 플러그인의 Gain 항목이 변화한다

오토메이션시 변화량을 분리한다는 것은 아마 이런 의미일듯 싶다

- 분리하지 않을 경우

(오디오 입력) -> (음량 변화량 측정 및 GUI 변경) -> (프로세스에 직접 값 전달) -> (프로세스 실행) -> (오디오 신호 음량 변화)

 

: 이렇게 될 경우 큰 문제는 없어 보이지만, 문제는 프로세스에 직접 값 전달을 하게 될 경우, 프로세싱 되는 순간에 값을 처리하고 다시 넘겨주어야 한다는 점이 문제가 된다.

 

이게 나같은 초심자들에게는 어렵고 복잡한 개념이기 때문에 차근차근 보아야 한다.

먼저, 프로세스는 값을 지속적으로 전달해주어야 한다. 그래야 끊김없이 변화를 유지할 수 있다.

그렇기 때문에 가급적 다른일을 시키면 안된다

그런데 위의 도식에서 굵은 글씨들이 모두 하나의 프로세스에서 실행된다면 어떻게 될까?

아마 이렇게 일을 할 것이다

 

1. 음량 변화량을 측정하면서 GUI의 변화가 필요하다 (대략 이 수행 시간이 1초가 든다)

2. 이 값을 프로세스에 전달한다 (대략 이 수행 시간이 1초가 든다)

3. 프로세스는 이 값을 실행한다 (오디오 버퍼에 작성한다. 대략 이 수행 시간이 1초가 든다)

 

각 프로세스 하나를 통과하는데 약 3초의 시간이 든다.

문제는 귀로 듣는 프로세스인 3번이 매 오토메이션이 바뀔 때 마다, 2초씩 딜레이가 되어 실행되는 것이다.

그렇다면 실제로 귀로 듣는 프로세스는 끊겨서 들리는 듯이 제대로 재생이 되지 않을 것이다.

(요것에 대한 실험은 나중에 진행해보도록 하자)

---

- 분리된 경우

(오디오 입력) -> (GUI 변경) -> (값을 저장)          <- Controller 에서 담당

                                                        |

                                               (저장된 값을 참조) -> (프로세스 실행) -> (오디오 신호 음량 변화)

 

*이 도식은 모바일에서 깨져보일수 있으니, 가급적 데스크탑 모드로 보는 것을 권장한다

 

: 이렇게 될 경우 Controller 에서 GUI 변경과 값을 저장해주고, 이 값을 프로세스에서는 참조해서 가져오기만 한다.

즉, 오디오 버퍼에 작성할 때, 발생하는 다른 잔업이 줄어들게 되며 결과적으로 끊김없이 제대로 재생이 된다

 

그렇기 때문에, Controller 와 Processor를 분리해서 설계하도록 권장하고 있다는 것으로 이해된다

(사실 이러한 개념은 웹 개발시 많이 듣던 MVC 같은 개념과 맥락은 비슷하다고 본다. 그러나 웹에서는 서버 통신이나 GUI의 동작이 끊기질 않아야 하기 위해 절차들을 나눠놓은 것이라면, 오디오에서는 듣는 것을 끊기게 하지 않기 위해, GUI와 Audio를 분리해둔 것이라 생각한다)

---

생각보다 양이 많아진것 같다.

사실 이러한 개념은 본격적인 VST의 구조에 대해서 설명하는 글을 작성할 때 쓰려고 했는데...

모르겠다. 어짜피 누가 볼 것도 아니고, 본다해도 VST에 관심이 있는 사람들만 보겠지

매번 느끼는 거지만 한국뿐 아니라 전세계적으로 오디오 프로그래밍은 주된 분야는 아니다.

그리고 하는 사람들도 정말 극소수이다.

그래도 누군가는 해야하고, 지속적으로 이 분야의 사람들이 생겨야 한다고 본다.

뮤지션은 음악을 만들기 위해 VST의 활용을 공부하고, 프로그래머들은 뮤지션을 위해 VST 자체를 공부해서 만드는 거니깐.

결과적으로 좋은 음악을 만들기 위해 아주 약간의 도움을 주는 것이라 생각한다.