Chimera Amp Matrix 개발기 Vol.1

1. 출발점 — “앰프를 하나 더 넣는 것”이 아니라 라우팅 자체를 악기로 만들기

Chimera의 출발점은 amp model의 개수를 늘리는 것이 아니었다. 기타와 베이스의 전체 신호를 한 앰프에 통과시키는 전통적인 구조, 두 개의 완전한 rig를 병렬로 섞는 구조, 그리고 주파수 대역을 나눈 뒤 각 대역에 서로 다른 amp/cab을 배치하는 구조를 하나의 제품 안에서 명확하게 전환할 수 있게 만드는 것이 핵심이었다.

따라서 1.0의 첫 번째 과제는 “좋은 앰프 소리”보다 먼저 세 모드가 실제로 다른 signal topology를 갖는가였다. Pre FX와 Post FX, amp voicing, IR workflow는 이 구조 위에 올라가야 한다. 라우팅 정의가 흔들리면 그 뒤의 모든 기능이 같이 흔들린다.

2. Classic, Dual, Matrix — 이름만 다른 세 프리셋이어서는 안 된다

현재 구현에서 Classic은 한 개의 full-range lane, Dual은 같은 입력을 두 개의 full-range lane에 복제한 뒤 병렬 합산한다. Matrix만 crossover를 사용한다. 기본 crossover reference는 대략 150 Hz와 1.2 kHz이며, 사용자가 두 지점을 움직이면 LOW / MID / HIGH의 실제 입력 범위가 함께 바뀐다.

3. 첫 번째 UI 실패 — 엔진은 달라도 화면이 같으면 사용자는 같은 시스템으로 읽는다

초기 테스트 UI는 세 개의 lane을 중심으로 빠르게 기능을 노출했다. 문제는 Classic, Dual, Matrix에서 화면 구조가 지나치게 비슷했다는 점이다. 모드는 바뀌는데 각 lane이 무엇을 받고 있는지, crossover가 어느 모드에서만 의미가 있는지, 왜 Classic에서 세 개의 컬럼처럼 보이는지가 명확하지 않았다. 기능은 들어 있었지만 routing affordance가 없었다.

수정 방향은 단순했다. Classic에서는 하나의 FULL-RANGE RIG, Dual에서는 FULL-RANGE RIG A/B, Matrix에서는 LOW / MID / HIGH BAND만 보이게 했다. Matrix에서는 각 band의 실제 입력 범위를 현재 crossover 값으로 표시하고, Classic/Dual에서는 crossover control 자체를 숨겼다.

4. Matrix에 4-band EQ를 그대로 넣었던 이유와, 결국 뺀 이유

초기 Matrix lane은 Classic/Dual의 amp control을 거의 그대로 상속했다. Drive와 Level뿐 아니라 Bass, Low Mid, High Mid, Treble, Presence, Resonance까지 각 band에 남아 있었다. 구현 면에서는 간단했다. 이미 존재하는 amp tone stage를 그대로 호출하면 됐기 때문이다.

하지만 Matrix는 입력 단계에서 이미 스펙트럼을 세 구역으로 제한한다. 예를 들어 LOW band만 받은 lane에 full-range 4-band EQ를 그대로 제공하면, 실제로 들어오지 않는 대역을 조절하는 knob가 생기고, crossover와 EQ의 역할도 화면에서 겹쳐 보인다. 컨트롤이 많아지는 것이 유연성처럼 보이지만, 실제로는 사용자가 현재 lane의 책임 범위를 파악하기 어렵게 했다.

4.1 Band Tone — crossover를 하나 더 만드는 knob가 아니다

대체한 control이 Band Tone이다. 이것은 새로운 band-pass filter나 세 번째 crossover가 아니다. 각 lane의 split 이후, amp distortion 이전에 놓이는 band-relative tilt다. 음수 방향은 band 내부의 균형을 어둡게, 양수 방향은 밝게 이동시킨다.

Tone pivot은 고정된 “500 Hz” 같은 숫자가 아니라 현재 crossover로 정의된 band의 기하평균 중심을 따라간다. 따라서 crossover를 옮기면 LOW/MID/HIGH의 실제 범위뿐 아니라 Tone이 기준으로 삼는 pivot도 같이 이동한다. Classic/Dual의 기존 full-range EQ parameter는 지우지 않고 상태를 보존해, 모드를 왕복할 때 세팅이 소실되지 않도록 했다.

5. “내 PC에서 컴파일됨”을 넘어서 — 빌드 파이프라인도 제품의 일부로 만들기

첫 bootstrap PR은 폐기하고, main에서 다시 시작한 PR #2를 v1.0/rebuild로 만들었다. 목표는 코드를 쌓는 것이 아니라 사용자가 실제로 실행할 수 있는 테스트 artifact까지 한 번에 재현하는 것이었다.

Windows에서 unsigned development binary가 Chrome/SmartScreen에 경고되는 문제도 여기서 드러났다. 이 단계에서 code signing까지 완료된 상용 배포물로 위장하지 않고, README에 unsigned test build임을 명시하고 SHA256을 함께 내보내도록 했다.

6. 첫 완전 성공 지점 — Run #111

Run #111에서 Windows, Ubuntu, macOS 세 job이 모두 build와 CTest를 통과했다. Windows에서는 VST3/Standalone을 묶은 Chimera-Amp-Matrix-1.0.0-test-win64.zip과 SHA256 manifest가 생성되었다. 이 지점에서 처음으로 “소스가 있다”가 아니라 다른 머신에서 빌드되고, 테스트되고, 사용자가 내려받아 실행할 수 있는 1.0 test artifact가 있다고 말할 수 있게 됐다.

7. 성공 직후 다시 깨뜨리기 — 최신 Run #112의 Windows regression

#111 이후 Matrix의 full-range EQ를 Band Tone으로 바꾸고, mode별 control visibility와 label을 다시 설계했다. Ubuntu와 macOS에서는 최신 code가 build 및 CTest를 통과했고, Windows도 binary build와 UI snapshot 생성까지 성공했다. 그러나 Windows의 ChimeraUITests가 “Wrong controls for routing mode”로 실패했다. 그 결과 packaging step은 의도대로 중단됐다.

이 실패는 현재 기록 시점에서 닫히지 않은 상태다. DSP smoke test인 ChimeraTests는 통과했기 때문에 핵심 오디오 엔진이 컴파일되지 않는 문제가 아니라, 바뀐 mode-specific UI 계약과 Windows UI test의 기대 조건 사이에 회귀가 생긴 것으로 좁혀져 있다. 다음 작업은 snapshot만 보고 넘기는 것이 아니라 어떤 control visibility/state expectation이 새 설계와 어긋났는지 수정한 뒤 다시 green build를 만드는 것이다.

8. 현재 설계 위치와 Vol.2로 넘길 것

Vol.2의 우선순위는 기능 목록을 더 늘리는 것이 아니라 현재 계약을 먼저 안정화하는 것이다.

• Windows ChimeraUITests의 routing-mode visibility regression 수정 및 #112 후속 green build 확보
• crossover 이동 시 band sum, phase, level consistency를 자동 측정하는 테스트 강화
• lane latency / oversampling / merge alignment 검증
• Pre FX / Post FX를 실제 module chain으로 확장하면서 mode별 책임 범위 유지
• amp/cab voicing과 IR workflow를 “모델 수”가 아니라 repeatable reference와 A/B validation 기준으로 발전

Source Links

• SpectralForge — Chimera Amp Matrix repository
• PR #2 — Chimera Amp Matrix 1.0 rebuild
• GitHub Actions Run #111 — first all-platform green/package checkpoint
• GitHub Actions Run #112 — current Windows UI-test regression