Logic은 필요한 프로젝트 API를 안 열어

"'API가 있나?'가 아니라 '필요한 능력을 공식 계약으로 열었나?'를 물어야 해."

당연한 후보

Logic Pro는 호스트로 가장 먼저 떠오르는 후보야. 음악 제작에 강하고 아빠의 실제 음악 작업도 Logic에서 돌아가니 조건 1과 3은 유력해. 문제는 조건 2를 너무 뭉뚱그려 물으면 안 된다는 거야. Logic에는 Scripter, Audio Unit, control surface 같은 확장 표면이 실제로 있어. 다만 Apple의 공개 문서에서 Bonfire가 필요한 프로젝트 전체의 곡·트랙·클립·오디오를 읽고 조작하는 범용 프로젝트 모델은 찾을 수 없어.

확장 표면마다 맡은 범위가 달라

Logic Pro 확장 표면             공식 범위
---------------------           ---------
Scripter (JavaScript MIDI FX)   MIDI 이벤트 처리와 플러그인 파라미터
Audio Unit extension            오디오 생성·처리 플러그인
Control surface / Lua           하드웨어 컨트롤과 Logic 파라미터 매핑
범용 project object model       공개 문서에서 확인되지 않음

이 표면들은 가짜 문이 아냐. 각자 맡은 일을 하는 진짜 API야. 다만 Bonfire가 원하는 문과는 방향이 달라. Scripter는 MIDI FX 안에서 이벤트를 처리하고, Audio Unit은 오디오를 생성하거나 처리하며, control surface는 하드웨어 조작을 Logic 기능에 매핑해. 셋을 합쳐도 외부 sidecar가 지원된 계약만으로 프로젝트 전체를 탐색하고 학습 모델로 바꾸는 API가 되지는 않아.

판정은 기능 단위로 내려

그래서 결론을 'Logic은 API가 전혀 없어' 또는 '무슨 수를 써도 지을 수 없어'라고 쓰면 과장이야. UI 자동화나 비공개 포맷 역공학으로 무언가 만들 수는 있어도, 그건 깨지기 쉬운 별도의 선택이지. 정확하게 다듬은 판정은 이거야. Logic의 공식 확장 표면에는 Bonfire sidecar가 필요한 프로젝트 모델이 없다. 그러니 공식 지원되는 API만으로 오래 버티는 핵심 통합을 세운다는 조건 2는 통과하지 못해.

Code

Logic의 확장 표면. 진짜지만 필요한 범위와는 달라·text

Logic Pro 확장 표면             공식 범위
---------------------           ---------
Scripter (JavaScript MIDI FX)   MIDI 이벤트 처리와 플러그인 파라미터
Audio Unit extension            오디오 생성·처리 플러그인
Control surface / Lua           하드웨어 컨트롤과 파라미터 매핑
범용 project object model       공개 문서에서 확인되지 않음

=> 'API 없음'이 아니라 '필요한 프로젝트 기능 없음'.
=> 오래 버티는 Bonfire 핵심 통합이라는 조건 2는 실패.

Exercise

확장하고 싶은 호스트의 공식 표면을 전부 적고, 제품에 필요한 기능도 동사로 적어. 읽기, 쓰기, 관찰, 실행 가운데 무엇이 필요한지까지 나눠서 맞춰 봐. 'API가 있다'가 아니라 '필요한 동사를 공식 계약으로 할 수 있다'일 때만 조건 2를 통과시켜.

Hint

플러그인 API가 오디오를 처리한다고 해서 프로젝트 모델도 여는 건 아냐. 반대로 필요한 범위와 다르다고 그 API가 가짜인 것도 아니야. 이름이 아니라 공식 문서의 객체·속성·함수를 비교해.