VST Maker
비공식 커뮤니티 스킬입니다. 여기에 언급된 플러그인, 신스 또는 프레임워크 벤더가 제작하거나 보증하지 않습니다.
신뢰도 태그 읽는 방법:
- (V: 출처) 명명된 출처에서 확인함.
- (R) 경험 법칙 또는 취향. 측정과 청취를 통해 테스트할 시작 값이며, 절대적인 규칙이 아닙니다.
태그가 없는 사실은 표준 관행이지만 릴리스에 의존하기 전에 반드시 검증해야 합니다.
0. 기본 원칙
- 제작 전에 물어볼 것: 플러그인 유형(신스, 이펙트, 컨트롤러), 대상 OS(Linux, macOS, Windows), 포맷(VST3 우선; CLAP 또는 LV2는 선택), 색상 팔레트(절대 가정하지 말고 사용자가 없으면 중립적인 기본값 제공), 라이선스(1번 항목 참고).
- 무료 오픈소스 플러그인은 오프라인에서 동작해야 함: 계정, 라이선스 서버, 설치 또는 실행 시 다운로드가 없어야 함. 플러그인에 필요한 모든 것은 번들로 제공.
- 소리가 좋다고 귀로 주장하지 마세요. 측정하고(12번 항목 참고) 사용자의 귀가 최종 판단을 내리도록 하세요.
- 모든 숫자는 인용하거나 테스트하세요. 수치가 경험 법칙일 때는 "미확인"이라고 말하세요.
- 사용자가 프로그래머가 아닐 때는 한 번에 한 단계씩 진행하세요. 먼저 짧은 답변을 하고, 요청 시 자세히 설명하세요.
1. 프로젝트 설정 및 라이선스
- JUCE는 이중 라이선스입니다: JUCE 라이선스와 AGPLv3. 유료 JUCE 플랜이 없으면 AGPLv3로 사용해야 하며, AGPLv3는 소스 공개 외에도 더 많은 것을 요구합니다(V: JUCE 포럼, 직원 답변). 사용하는 버전의 현재 JUCE 라이선스를 선택하기 전에 읽고, 어떤 것이 적용되는지 사용자에게 알리세요. 요금제 가격이나 수익 한도를 기억에서 말하지 마세요.
- CMake를 사용하세요. 윈도우 없이 단위 테스트할 수 있도록 DSP 코드는 JUCE GUI 타입과 분리하세요.
- VST3를 먼저 빌드하세요. CLAP과 LV2는 선택 사항입니다: 둘 중 하나를 약속하기 전에 현재 JUCE 문서와 clap-juce-extensions를 확인하세요.
- 호스트가 VST3를 스캔하는 위치(V: Steinberg VST 3 Developer Portal, Plug-in Locations):
- Linux:
$HOME/.vst3/우선, 그 다음/usr/lib64/vst3/,/usr/lib/vst3/,/usr/local/lib64/vst3/,/usr/local/lib/vst3/. - macOS:
~/Library/Audio/Plug-ins/VST3/(사용자),/Library/Audio/Plug-ins/VST3/(전역). - Windows:
C:\Program Files\Common Files\VST3\(전역),%LOCALAPPDATA%\Programs\Common\VST3\(사용자, 주로 개발용). - 호스트는 특정 Processor UID에 대해 발견된 첫 번째 플러그인을 우선 순서대로 스캔하여 사용합니다.
- Linux:
2. 실시간 안전성
processBlock은 하드 데드라인이 있는 높은 우선순위의 오디오 스레드에서 실행됩니다. JUCE 문서에 따르면 UI와의 상호작용은 절대 불가능하며, 코드는 가변 블록 크기를 처리할 수 있어야 합니다(V: JUCE AudioProcessor docs).
오디오 스레드에서 절대 해서는 안 되는 작업:
- 메모리 할당 또는 해제 (new, delete, malloc, 벡터나 문자열 증가,
juce::String생성) - 다른 스레드가 보유할 수 있는 락 획득 (std::mutex, CriticalSection)
- 파일, 네트워크 또는 콘솔 I/O
- UI 또는 MessageManager 호출
- 예외 던지기 또는 알 수 없는 실시간 동작이 있는 것 호출
대신:
prepareToPlay에서 할당하세요(샘플레이트는 재생이 중지될 때까지 일정하게 유지됨; 블록 크기는 힌트일 뿐이며 문서에 따르면 호스트가 이를 초과할 경우를 대비해 방어적으로 프로그래밍해야 함)(V: JUCE docs).releaseResources또는 소멸자에서 해제하세요.- 락-프리 큐(
juce::AbstractFifo) 또는 아토믹을 사용하여 다른 스레드와 통신하세요. UI는 Timer로 아토믹을 폴링하거나 오디오 스레드에서 AsyncUpdater를 트리거합니다. processBlock상단에juce::ScopedNoDenormals를 배치하세요; 함수가 반환될 때까지 활성 상태로 유지되므로 헬퍼 함수에서 반복할 필요가 없습니다(V: JUCE 포럼 합의, 공식 문서 아님). 또한 피드백 경로가 비정규값으로 붕괴되지 않도록 설계하세요.- 추천 자료: Ross Bencina, "Real-time audio programming 101: time waits for nothing" (여기에 인용되지 않음, 이 스킬이 작성될 때 가져올 수 없었음).
3. 파라미터 및 상태
AudioProcessorValueTreeState를 사용하세요: 호스트 자동화, 실행 취소 및 상태 저장이 함께 제공됩니다.- 게인, 주파수, 믹스 또는 딜레이 타임에 도달하는 모든 파라미터를 스무딩하세요(
juce::SmoothedValue). 그렇지 않으면 지퍼 노이즈와 클릭이 발생합니다. - 값이 샘플당 스무딩되지 않는 한 블록당 한 번 값을 로컬 변수로 읽으세요.
- 모든 파라미터에 안정적인 문자열 ID를 부여하세요. 릴리스 후에는 ID 이름을 바꾸거나 순서를 변경하지 마세요: 저장된 프로젝트와 자동화가 손상됩니다. 새 ID로 새 파라미터를 추가하고 상태 버전 번호를 유지하세요.
- 상태나 프리셋에서 로드된 모든 것을 검증하세요: 범위를 제한하고, 알 수 없는 키는 무시하고, 크기나 개수를 절대 신뢰하지 마세요.
- 프로세서(DSP 및 상태)를 편집기(UI)와 엄격히 분리하세요. 프로세서는 편집기 창이 닫힌 상태에서도 완벽하게 실행되어야 합니다. VST3 자체는 플러그인을 프로세서와 컨트롤러로 나눕니다(V: Steinberg VST 3 튜토리얼, "Code your first plug-in").
- JUCE가 감싸고 있더라도 알아두면 좋은 VST3 사실(V: 동일 튜토리얼): 파라미터는 항상 0.0에서 1.0으로 정규화됩니다. 호스트가 자동화할 수 있도록 automatable 플래그를 설정하세요. 하나의 처리 블록에는 동일한 파라미터에 대한 여러 변경 사항이 포함될 수 있으므로, 수동 프로세서는 큐를 올바르게 처리해야 합니다(튜토리얼은 마지막 변경만 적용하는데, 이는 단순화된 것입니다). 입력이 무음이면 무음 플래그를 설정하고 준수하며 출력 버퍼를 지우세요. 지원되지 않는 버스 레이아웃은 추측하지 말고 거부하세요. 입력이나 샘플이 없을 때도 보류 중인 파라미터 변경을 적용하세요.
더 많은 VST3 아키텍처 사실(V: Steinberg VST 3 Developer Portal, API 문서):
- 프로세서는 컨트롤러가 로드되지 않은 상태에서도 작동해야 하므로 DSP 상태는 편집기에 절대 의존하지 않습니다.
process()와setProcessing()은 오디오 스레드에서 실행될 수 있습니다: 할당 금지. Initialize와 terminate는 UI 스레드에서 실행됩니다.- 버스 및 스피커 배열은 플러그인이 비활성화된 동안에만 변경할 수 있습니다. 비활성 버스를 포함한 모든 버스에 버퍼를 제공하세요. 입력 및 출력 버퍼는 메모리를 공유할 수 있으므로 맹목적으로 출력을 지우지 마세요.
- 노트는
process()에서 이벤트로 도착합니다. 파라미터 변경은 파라미터 큐를 통해 샘플 정확도로 도착합니다. 템포와 트랜스포트는 프로세스 컨텍스트에서 도착합니다. - GUI-투-호스트 편집은 beginEdit, performEdit, endEdit 순서로 UI 스레드에서만 사용합니다.
- 상태 복원 시 프로세서가 먼저 복원됩니다. 그런 다음 컨트롤러가 컴포넌트 상태를 수신하며 핸들러 콜백을 실행해서는 안 됩니다.
process()에서 비공개 프로세서-투-컨트롤러 메시지를 보내지 마세요. UI 스레드 또는 데이터 교환 API를 사용하세요.- 유닛은 파라미터를 그룹화합니다. MIDI 매핑 인터페이스는 MIDI CC를 파라미터에 매핑합니다.
- 필요할 때 읽을 포털 페이지: Parameters and Automation, Workflow Diagrams, Multiple Dynamic IO(sidechain), VST 3 Units, Data Exchange.
4. 성능: CPU, RAM, GPU
- 최적화하기 전에 측정하세요(12번 항목 참고).
- CPU (R): 블록 단위로 처리하고, 파라미터가 변경될 때 계수를 미리 계산하고, 내부 루프에서 샘플당 분기와 가상 함수 호출을 피하고,
std::pow,std::exp,std::sin을 반복 또는 테이블이 더 빠르게 측정되는 곳에서는 샘플당 사용하지 마세요. - RAM: 한 번만 사전 할당하고, 보이스 간에 웨이브테이블과 테이블을 공유하고, 큰 버퍼는
releaseResources에서 해제하세요. - GPU 및 UI: 편집기가 표시되고 전면에 있을 때만 그리세요. 숨겨지면 타이머, 미터 및 캔버스 애니메이션을 일시 중지하세요. 오디오, 자동화 및 MIDI는 계속 실행됩니다. 다시 그리기 속도를 제한하고 더티 영역만 다시 그리세요(R). 명백히 필요하고 Linux에서 테스트된 경우에만 GPU 렌더링을 사용하세요.
- 숨겨지거나 닫힌 편집기는 프레임당 작업을 계속 실행해서는 안 됩니다.
5. 레이턴시
- 플러그인이 오디오를 지연시킬 때마다
setLatencySamples로 실제 레이턴시를 보고하세요("도입하는 샘플 지연 수", V: JUCE docs): 룩어헤드 리미터 또는 컴프레서, 선형 위상 필터, 오버샘플링 필터. 호스트에서 보고가 적용되는지 확인하세요. - 악기는 노트온부터 소리까지 0 레이턴시를 추가합니다.
- 선형 위상 오버샘플링 필터는 레이턴시를 추가합니다. 최소 위상 필터는 추가하지 않지만 위상을 변경합니다. 의도적으로 선택하고 문서화하세요.
juce::dsp::Oversampling은 자체 레이턴시를 보고합니다. 이를 보고하세요. - 리버브와 딜레이의 경우
getTailLengthSeconds를 올바르게 유지하여 호스트가 테일을 자르지 않도록 하세요.
6. 음질
앨리어싱
- 기본적인 톱니파와 구형파는 나이퀴스트 위에 고조파를 가지고 있어 비고조파 노이즈로 접힙니다. 수정 방법: 대역 제한 스텝 방법(BLEP 계열), 차분 다항식 파형, 옥타브당 대역 제한 웨이브테이블, 또는 오버샘플링.
- 발표된 방법: 차분 다항식 파형; 저자들의 청취 모델 평가 결과 4차 방법이 그랜드 피아노의 전체 범위에서 지각적으로 앨리어싱이 없는 것으로 나타났습니다(V: Välimäki, Nam, Smith, Abel, IEEE TASLP vol. 18 no. 4, 2010).
- 모든 비선형성(왜곡, 새츄레이션, 웨이브폴딩, 하드 클리핑)은 앨리어싱을 생성하는 새로운 고조파를 만듭니다. 비선형 단계 주변을 오버샘플링하거나 역도함수 기반 안티앨리어싱을 사용하세요. Zavalishin은 웨이브셰이핑의 안티앨리어싱을 다룹니다(V: "The Art of VA Filter Design", 섹션 6.13).
- 발진기 코드를 눈으로 보는 것이 아니라 측정을 통해 앨리어싱을 테스트하세요(12번 항목 참고).
필터
- 모델링된 아날로그 필터의 경우 제로-딜레이-피드백(토폴로지 보존 변환) 구조를 사용하세요. 이 책은 3장(섹션 3.9, 제로-딜레이 피드백), Moog 스타일 래더는 5장, 피드백 루프 포화는 6장에서 다룹니다(V: Zavalishin, "The Art of VA Filter Design", rev. 2.1.0, 목차).
- 일반 EQ 및 유틸리티 필터에는 바이쿼드를 사용하세요. Audio EQ Cookbook(R. Bristow-Johnson, W3C Working Group Note 2021)은 로우패스, 하이패스, 밴드패스, 노치, 올패스, 피킹 EQ 및 셸프를 제공합니다(V).
- 컷오프와 레조넌스 변경을 스무딩하고, 컷오프를 나이퀴스트 아래로 제한하고, 레조넌스를 극단에서 안정적으로 유지하고, 높은 레조넌스가 볼륨을 튀지 않도록 레벨을 보상하세요.
부드럽고 거칠지 않게 (R, 프로듀서들의 관행에서 비롯됨; 각각 테스트)
- 거친 느낌은 일반적으로 앨리어싱, 하드 클리핑, 상중역의 강한 레조넌스 피크, 너무 많은 필터링되지 않은 고역에서 비롯됩니다.
- 로우패스가 완전히 열린 채로 리드 사운드를 만들면 너무 밝게 들릴 수 있습니다. 밝은 리드의 경우 약 12kHz의 시작 컷오프는 사용자가 보고한 취향 값이며 규칙이 아닙니다.
- 필터 피드백 루프 내부의 새츄레이션은 아날로그 스타일 필터가 부드럽게 들리는 일반적인 이유입니다(V: Zavalishin은 피드백 루프 포화를 다룹니다; 지각적 주장은 R입니다).
- 매우 작고 느린 모듈레이션은 정적인 톤을 생생하게 유지합니다. 예를 들어 몇 센트의 피치 드리프트가 있습니다. 선택하기 전에 변환하세요: 0.1%는 약 1.7센트, 1%는 약 17센트이며, 17센트는 명확히 들을 수 있는 디튠입니다. 디튠이 목표가 아니라면 낮은 쪽을 유지하세요.
- 두꺼운 사운드는 레이어링, 디튠 확산이 있는 유니즌, 서브 오실레이터, 스테레오 폭에서 비롯됩니다. 모노 호환성을 확인하세요(L과 R을 합산하여 웅웅거리거나 상쇄되는 소리가 없는지 듣기).
게인 스테이징 및 DC
- 넉넉한 헤드룸으로 내부 체인을 float으로 실행하세요. 체인 내부에서 절대 클리핑하지 마세요. 유일한 클리퍼나 리미터는 출력에 의도적으로 배치하세요.
- 비대칭 비선형성 이후에는 낮은 단일 자릿수에서 수십 Hz 범위의 부드러운 하이패스로 DC를 제거하세요(R); 12번 항목의 DC 측정으로 확인하세요.
- 프리셋 전환 시 레벨이 튀지 않도록 프리셋 음량을 일치시키세요(9번 항목 참고).
7. 신스 디자인
- 보이스: 모든 보이스를 사전 할당하고, 노트온에서 절대 할당하지 마세요. 폴리포니를 상수 또는 사용자 설정으로 만드세요. 짧은 페이드아웃으로 보이스를 스틸하고, 하드 컷은 절대 하지 마세요.
- 엔벨로프: 클릭을 방지하기 위해 최소 어택과 릴리즈를 수 밀리초로 사용하세요. 재트리거 시 0에서가 아닌 현재 레벨에서 시작하세요.
- 유니즌: 시작 위상을 무작위 또는 확산시키고, 디튠 확산 곡선, 스테레오 확산, 보이스 수에 따라 증가하지 않는 레벨 보상을 사용하세요.
- Supersaw: Roland JP-8000 Super Saw는 서로 디튠된 7개의 톱니파 발진기를 닮은 것으로 설명됩니다(V: Wikipedia, Roland JP-8000). 상세 분석이 존재합니다: Adam Szabo, "How to Emulate the Super Saw"(KTH, 2010) 및 Alex Shore(2013), 두 자료 모두 해당 페이지에 인용되어 있습니다. 숫자를 추측하는 대신 디튠 곡선과 믹싱에 대해 읽어보세요.
- 드리프트 및 아날로그 느낌: 보이스 당 피치와 컷오프의 느린 랜덤 모듈레이션, 작고 상관관계가 없음.
- 상용 슈퍼쏘 신스에서 볼 수 있는 아이디어, 학습용으로만 사용하세요. 자체 코드와 디자인을 작성하고, 제품의 코드, 외관, 이름 또는 프리셋을 절대 복사하지 마세요(R, 귀와 측정으로 확인):
- 발진기당 하나의 느린 LFO, 결합된 움직임이 들릴 정도로 반복되지 않도록 황금비와 같은 무리수 비율로 주파수를 간격을 둠.
- 디튠과 드리프트 깊이를 함께 조정하는 하나의 "드리프트" 매크로, 두 번째 페이지에 미세 컨트롤 제공.
- 자체 컨트롤로서의 키트래킹 하이패스(JP-8000 스타일 슈퍼쏘 사운드는 하나를 사용함).
- 선택적 2x 또는 4x 오버샘플링 필터; 오버샘플링 레이턴시를 호스트에 보고하세요.
- 미터의 dB 스케일, 보이스당 스테레오 확산, 사이드체인 가능 이펙트 확인: 사용자가 알아차리는 일부 제품의 격차.
- MIDI: 블록 내 각 MIDI 이벤트의 샘플 위치를 사용하여 노트가 샘플 정확도로 시작되도록 하세요. 피치 벤드(기본 범위 2세미톤, 설정 가능), 서스테인 페달, 올-노트-오프, 릴리즈가 있는 노트 오프를 처리하세요. 악기가 리드 또는 베이스 지향적이라면 모노, 레가토 및 포르타멘토를 제공하세요.
- 웨이브테이블: 옥타브 또는 피치 범위별로 대역 제한; 지퍼 노이즈를 피하기 위해 프레임 간 크로스페이드; 보간(선형은 저렴하고, 고차는 CPU 비용이 많이 들며 앨리어싱을 측정하세요).
8. FX 디자인
- 컴프레서 및 리미터: 스무딩된 어택과 릴리즈로 로그 도메인에서 검출하고, 게인 스무딩을 적용하고, 자동 또는 수동 메이크업을 추가하고, 룩어헤드가 있으면 레이턴시를 보고하세요. 체인 끝의 리미터는 인터-샘플 안전을 약속하는 경우 트루-피크 또는 오버샘플링된 천장이 필요합니다.
- 멀티밴드: 밴드가 합쳐질 때 플랫하게 유지되도록 Linkwitz-Riley 크로스오버로 분할; 각 밴드를 처리하고; 재결합하세요. 크로스오버의 위상 일관성을 유지하고 추가된 레이턴시를 보고하세요.
- 딜레이: 분수 딜레이 보간, 피드백 경로의 댐핑 필터, 템포 동기화, 핑퐁, 덕킹, 그리고 발주하지 못하도록 피드백 제한.
- 리버브: 피드백 딜레이 네트워크 또는 Dattorro 플레이트 토폴로지(J. Dattorro, "Effect Design Part 1", JAES 1997); 테일에서 고역을 댐핑; 금속성 울림을 피하기 위해 딜레이 라인을 약간 모듈레이션; 프리딜레이, 디케이, 댐핑, 크기 및 믹스를 노출.
- 리드에 대한 일반적인 시작 관행, 귀로 테스트(R): 리버브 리턴을 200~300Hz 정도의 하이패스로 저역에서 빼내고, 테일의 고역을 롤오프하고, 적당한 믹스를 사용하세요.
- 코러스, 앙상블, 페이저
… [번역을 위해 잘림]