JD-man 개발기록들

완성 및 마무리

JD-man — Mon, 4 May 2026 20:14:53 +0900

데모 영상

https://youtu.be/bxciA4DR3jc

[왼쪽 : 튜너앱 / 오른쪽 : GarageBand 튜너]

테스트 진행방식

튜너앱을 실행하고 기타를 오디오 인터페이스를 통해 맥북과 연결해 GarageBand의 튜너와 동시에 측정

결과

둘을 비교했을때 낮을땐 낮게 높을땐 높게 측정되는 경향은 일치

하지만 세밀한 수치에서 약간씩 차이가 나는데 앱에서의 수치가 좀 더 높게 나오는거로 보인다.

수치가 차이나는 이유에 대한 생각

측정 데이터 성질의 차이

튜너앱은 디바이스의 마이크를 통해 들어오는 소리로 측정하고

GarageBand는 픽업 신호가 들어가기 때문에 둘의 차이가 있다고 생각

마찰음 및 기타 픽업의 영향

줄을 피킹할때의 마찰음 때문에 그럴수도 있고

데모에 사용된 기타 픽업이 높은음을 좀 걸러준다던지 등 영향을 받았을 수도 있을거 같다.

데이터 후처리의 영향

소수점에서의 파악을 위한 Parabolic Interpolation 단계나

부드러운 애니메이션을 위한 smooth 처리 같은 후처리 단계의 영향이 있을 수 있다.

더 세밀한 보간법이나 데이터에 영향을 주지 않는 부드러운 애니메이션 방법이 필요

불안정한 수치에 대한 생각

튜너앱의 경우 마이크를 통한 데이터를 사용하다보니 주변 소음에 많이 취약하다.

최대한으로 조용한 환경에서 테스트 했음에도 튀는 수치들이 보인다.

조용한 환경 사용해야한다는 점 자체가 우선 큰 제약이다.

JUCE가 아니었어도 됐는지

지금와서 생각해보면 JUCE의 DSP 관련 코드를 사용하지 않았고

마이크 인풋 데이터를 가져오기 위해서만 사용했기 때문에 JUCE가 필요했나 생각이든다.

현재 데이터 흐름은

engine -> Tuner -> engine -> App

위와 같은데

AVFoundation이나 AVAudioSession 같은거 썼다면

JUCE가 없으니 engine은 필요가 없으므로

App -> Tuner -> App의 간단한 구조가 됐지 않았을까 생각이 든다.

하지만 앱은 UI를 위해서만 사용하고 싶고 그러면 소리 관련 코드가 없어야 하니

JUCE 사용은 충분히 의미가 있었다고 생각된다.

DSP보단 iOS에 집중된 느낌

튜너 기능을 구현하기 위한 코드보다는

기능별로 분리하기 위한 레이어 설계라던가

결과 데이터나 앱에서의 입력 데이터 주고 받기 위한 기능 개발이라던가

DSP보단 iOS 앱 개발을 위해 더 집중했다.

DSP 개발도 보통 그렇다곤 하는데 이번에 만들면서 완전 경험했다.

마무리 소감

앞으로의 DSP 공부 및 개발을 위한 중요한 경험이 됐다.

iOS 앱에 더 집중한다고 하긴 했지만 레이어를 나누고 구조를 생각하면서

앞으로 플러그인 개발할때 어떻게 구조를 잡을지 힌트가 많이 됐다.

YIN 알고리즘을 공부하면서 소리 데이터를 다루고 원하는 값을 얻기 위한

계산들을 학습하고 공부하면서 앞으로의 DSP 공부에 도움이 많이 될거라고 생각한다.

실제로 지금하고 있는 DSP 공부가 이전보다 많이 수월하고 편해졌다.

나의 마지막 iOS 개발이 될거 같고 그랬으면 좋겠다.

OctaFuzz 기획

JD-man — Wed, 29 Apr 2026 16:46:38 +0900

기획 목적 및 이유

직접 쓰려고 만든다.

내가 주로 사용하는 팀헨슨 플러그인에는 Octaver, Fuzz가 없는데

합주나 공연을 위해 저 두개가 필요한 실리카겔곡을 연습하려면

어쩔수없이 멀티이펙터를 켜야됐고 생각보다 많이 번거로웠다.

난 그냥 집에서 간편히 연습하려고 하는데 멀티를 켜기는 싫었다.

개발 기능

기본적으로 Octaver와 Fuzz가 필요하기 때문에 두 기능을 하나의 플러그인으로 만든다.

1. Octaver

파라미터는 oct + 1, -1, mix를 가진다.

POG 같은 소리가 나야하므로 플리포닉 트래킹으로 만들고

이를 위해서 크로스페이딩 딜레이 라인 또는 타임 도메인 그래뉼라 피치 시프팅 기법을 사용한다.

2. Fuzz

간단히 하나의 파라미터를 가지는 퍼즈로 만들려고한다.

어차피 EQ나 볼륨은 이후 이펙터나 앰프에서 조절하기 때문이다.

만들다가 이펙터 사용 전후로 볼륨차이가 너무 많이 나면 볼륨 파라미터는 추가할 수 있다.

3. 순서 변경

Fuzz -> Octaver의 순서를 기본으로 사용하겠지만

여러 실험을 하거나 다른 소리를 만들고 싶을 수 있게끔

위의 두개의 체인 순서를 변경하는 기능을 넣으려고 한다.

기술 스택

JUCE 및 C++을 이용하고 플러그인 형태로 만든다.

IDE는 Xcode를 사용

깃은 OctaFuzz 레포지토리와 기존의 DSP 모듈 레포지토리를 나눠서 관리하며

OctaFuzz의 프로젝트가 DSP 모듈 내의 Octaver, Fuzz 부분을 참조하는 방식

디자인

디자인이 문제긴한데...

JUCE 내의 UI를 사용해 그리기 보단

최대한 이미지 파일을 활용해 페달 모양으로 만들려고한다.

이 작업만 별도로 정리해야할 정도로 도전적인 경험이 될듯.

AI 활용

이번엔 개발하면서 처음으로

시작부터 AI를 사용해 프로젝트를 만들 생각이다.

이론부터 공부하고 코드를 작성하는건 지금 시대에는 맞지 않은거 같다.

이론 학습이 중요하므로 AI가 던져주는 이론과 코드를 학습해

이전과는 역으로 선개발후학습을 하려고 한다.

(안그러면 1년걸림)

개발 기간

사실 나에게 최우선은 개발보단 연습이다.

이제 시간이 많아져서 시간에 쫓겨 개발하기 보단

천천히 이론들을 학습하면서 개발할 계획

튜닝 모드 변경

JD-man — Thu, 23 Apr 2026 15:46:59 +0900

환절기에 골골대느라 2주를 날렸다.

꽃가루 알레르기, 비염, 감기 난리가 해가 갈수록 심해진다...

이 프로젝트의 마지막으로 추가할 기능인 튜닝 모드 변경 기능을 만들어봤다.

대상 주파수의 외부 주입

TunerResult JDTuner::getGuitarTunerResult(float frequency)
{
  if (frequency < 40.0f || frequency > 500.0f)
    return {result};

  // 1. 기타 6줄의 표준 주파수 배열
  float guitarStrings[] = {82.41f, 110.00f, 146.83f, 196.00f, 246.94f, 329.63f};
  const char *guitarNoteNames[] = {"6E", "5A", "4D", "3G", "2B", "1E"};
  
  // 이 주파수 배열을 이용한 주파수 검출...

}

기존은 위와 같이 함수 내에서 목표 주파수와 노트를 직접 입력해놓은 코드였다.

튜닝 모드를 변경하기 위해서는 이런 하드 코딩보단 외부에서 받아서 사용할 필요가 있었다.

프리셋 생성

  presetDictionary = {
    {"GuitarStandardE", {
      {82.41f, "6E"}, {110.00f, "5A"}, {146.83f, "4D"},
      {196.00f, "3G"}, {246.94f, "2B"}, {329.63f, "1E"}
    }},
    {"GuitarDropD", {
      {73.42f, "6D"}, {110.00f, "5A"}, {146.83f, "4D"},
      {196.00f, "3G"}, {246.94f, "2B"}, {329.63f, "1E"}
    }},
    
    // ...
  };

presetDictionary 프로퍼티를 만들고 튜너 생성시 초기화 되도록 만들었다.

이것도 별도의 객체로 만들어 놓고 싶었지만 지금은 거기까진 필요없어서 일단 이렇게 했다.

튜닝 모드 변경 메서드 구현

// JDTuner

void JDTuner::setTuningMode(const std::string& modeName) {
  auto it = presetDictionary.find(modeName);
  
  if (it != presetDictionary.end()) {
    targetNotes = it->second;
  } else {
    targetNotes = presetDictionary.at("GuitarStandardE");
  }
}

// JDTunerEngine

void JDTunerEngine::setTuningMode(const std::string &modeName) {
  jdTuner.setTuningMode(modeName);
}

// JDTunerWrapper

- (void)setTuningMode:(NSString *)modeName {
  if (engine) {
    std::string cppModeName = [modeName UTF8String];
    engine->setTuningMode(cppModeName);
  }
}

튜너부터 시작해 engine, wrapper에서 각각 튜닝 모드 변경 메서드를 만들어

뷰에서 wrapper의 메서드를 사용하도록 만들었다.

뷰 구현

// enum
enum TuningMode: String, CaseIterable {
  case guitarStandard = "GuitarStandardE"
  case guitarDropD = "GuitarDropD"
  case bassStandard = "BassStadardE"
  
  var displayName: String {
    switch self {
    case .guitarStandard: return "Guitar Standard (E)"
    case .guitarDropD: return "Guitar Drop D"
    case .bassStandard: return "Bass Standard (E)"
    }
  }
}

// State...

@State private var selectedMode: TuningMode = .guitarStandard


// View...
     HStack {
          Text("Tuning Mode")
            .font(.headline)
            .foregroundColor(.white.opacity(0.6))
          
          Spacer()
          
          Picker("Tuning Mode", selection: $selectedMode) {
            ForEach(TuningMode.allCases, id: \.self) { mode in
              Text(mode.displayName).tag(mode)
            }
          }
          .pickerStyle(.menu)
          .tint(.white)
          .lineLimit(1)
          .fixedSize(horizontal: true, vertical: false)
          // 값이 변경될 때마다 C++ Wrapper로 전달
          .onChange(of: selectedMode, initial: false, { oldValue, newValue in
            if oldValue != newValue {
              wrapper.setTuningMode(newValue.rawValue)
            }
          })
        }
        .padding(.horizontal, 24)
        .padding(.top, 20)

열거형을 정의하고 (지금보니까 오타가 있는데 나중에 수정해야겠다) 간단한 Picker를 만들어 튜닝 모드를 변경했다.

결과

결과 영상

튜닝 모드까지 변경하는 기능을 만들었다.

마지막으로 실기기 테스트와 시연 영상 만들고 이 프로젝트는 마무리 예정!

마무리 포스트에 소감을 작성하겠지만 c++보다 iOS쪽 작업이 더 많았다...

얼른 마무리하고 다음 프로젝트로 가야지!!!

프로젝트 구조 변경 - 튜너를 외부로 분리

JD-man — Fri, 3 Apr 2026 20:19:42 +0900

변경 전 구조

위 이미지는 변경 전 구조이다.

UI를 제외한 나머지 레이어의 역할을 설명하면

DSP Engine Layer

주파수 검출을 위한 Yin 알고리즘을 실행시키고 Wrapper로 결과를 전달한다.

Wrapper Layer

튜너로 부터 받은 결과 값을 WrapperResult로 변경해 UI로 전달한다.

이 과정에서 cents값의 제한을 두게 하거나

smoothFrequency와 같은 데이터에 관여하는 코드가 포함되어 있다.

문제점 1 - Wrapper에서의 불필요한 코드

Wrapper는 c++에서 받은 값을 Swift로 전달하는 역할만 가지고 있어야 한다고 생각했다.

비즈니스 로직과 같은 데이터를 다루는 코드가 들어갈 경우 튜너 프로젝트와 Wrapper 둘다 수정해야하고

c++, Objective-C 간의 호환코드도 들어가 기능이 추가될수록 유지보수가 어려워 질거라고 생각이 들었다.

문제점 2 - DSP 코드의 재사용성

현재는 iOS 프로젝트만 만들고 있지만 안드로이드나 내가 만들 플러그인에도 해당 튜너 알고리즘을 사용할 경우도 생각하면

튜너 코드까지 iOS 프로젝트에 포함되어 있는 경우 각 프로젝트마다 튜너 코드도 다시 작성해야하는 문제점이 있다.

그리고 현재 프로젝트에서도 튜너쪽 기능을 추가하려고 하면 DSP Engine 쪽을 건드리게 되는데 이런 경우

순수한 튜너의 코드까지 건드리게 돼서 불리한점이 많다.

해결 방안

나만의 DSP 코드 레포지토리를 따로 분리하고 각 프로젝트에서 이 DSP 레포지토리에서

필요한 기능의 C++ 코드를 의존하는 방향으로 변경해

순수 DSP 코드를 건드리지 않으면서 각 프로젝트의 목적 및 기능에 맞게 개발하게 구조를 수정한다.

요약하면 DSP 부분만 외부로 빼내기

작업

DSP 코드만 모아놓는 레포지토리를 별도로 만들고

튜너 코드를 그 폴더에 이동 시켰으며 jucer에서 해당 코드를 참조하도록 수정했다.

앱과 튜너 프로젝트 모두 헤더 경로 설정이 필요했으며 개발환경 설정의 경험이 있어 어렵지 않았다.

변경 후 구조

프로젝트 내의 Engine Layer가 외부의 DSP 코드에 의존하게되며

이 프로젝트의 경우 외부 DSP 코드의 튜너만을 참조해 사용하게 된다.

이렇게해서 순수 DSP 코드는 특정 프로젝트에서 개발하더라도 유지가 가능해졌고

다른 프로젝트에 재사용 가능하게 됐다.

이후 작업

Wrapper 코드에 있는 데이터 관여 코드를 Engine으로 넘기고

Wrapper는 최대한 C++쪽의 결과를 앱으로 넘기는 기능만 남겨

더 세밀한 역할 분리 작업을 할 예정이다.

UI 수정

JD-man — Sun, 15 Mar 2026 17:30:26 +0900

개선 이전

개선 전 화면

개선 전 디자인은 숫자 밖에 모르는 공돌이 인간이 만든 테스트용 화면 같다.

출시까지 고민하고 있는 만큼 조금 더 상용 앱 같은 느낌으로 수정하고 싶었다.

후보군

제미나이의 3가지 개선안

사실 위에서말한 숫자밖에 모르는 공돌이 인간이 나임.

그래서 제미나이에게 디자인 개선안을 물어봤다.

1번

미니멀리즘을 추구하는 나는 정말 마음에 드는 디자인이다.

군더더기 없이 깔끔하고 이후에 기능 추가하기에도 좋아보인다.

2번

6현 기타의 헤드가 전부 저런 모양이 아니며

이후 7~8현 기타의 튜닝도 만들어보고 싶은 생각이 들어 패스

3번

그래프와 슬라이드 전부 좋았지만

렌더링 리소스가 너무 많이 들어서 배보다 배꼽이 더 커보였다.

그냥 빨리 튜닝하고 다른거 해야할건데 이거 때문에 핸드폰이 뜨거워지면 안될거 같았다

그래서 패스

최종 선택 - 1번 디자인

최종적으로 1번이 선택됐다.

물론 이 디자인 그대로 한건 아니고 최대한 가깝게 구현하려고 했다.

데이터 및 상태값은 그대로 사용했으므로 UI만 수정하면 됐다.

그냥 스유 UI 코드라서 딱히 정리할게 없다.

결과

개선 이후

지금보면 빨간색과 파란색으로 굳이 나눠야 싶긴 하지만

+, - 상태를 나타내기에 직관적으로 좋아보여서 그냥 놔두려고 한다.

아래에 있는 슬라이더는 디버그 모드에서만 생기는 슬라이더다.

시뮬레이터에서 UI만 확인하고 싶은데 폰에 빌드하기 싫어서 만들었다.

미니멀한게 내 스타일이고 이후 내가 붙이고 싶은 기능이 있을때

큰 디자인 수정없이도 가능해보인다.

최종적으로 기능 테스트를 몇번 더 하고 성능을 개선하고 출시를 고려해봐야겠다.

플러그인 만들때도 느낀거지만 여기 DSP쪽도 결국 UI 노동인거 같다...

정확도 개선 2 - 1차 IIR 필터

JD-man — Wed, 11 Mar 2026 20:51:59 +0900

문제점

마이크를 사용하는 앱이므로 어지간하면 조용한곳에서 사용하겠지만

마이크로 들어가는 소리는 단순히 기타 줄의 소리만 들어가는게 아니다.

1. 배음

기타 줄에서 나오는 파형은 여러개의 파형의 합쳐져 있다.

6번 줄(82.4Hz)을 예로 들면,

정배수인 164.8Hz(2배음), 247.2Hz(3배음), 329.6Hz(4배음) 등의

고음역대 소리가 동시에, 치는 순간에는 원래 음보다 더 강하게 튀어나온다.

2. 피킹음

피킹시 피크(Pick)가 줄을 긁는 고음역대의 쇳소리도 들어갈 수 있다.

3. 주변 소음

TV를 틀어 놓거나 하는 주변 소음도 어느정도 있을 수 있다.

해결방식 - 1차 IIR 필터

이런 여러소리가 같이 들어가는 상황에서 최대한 기타 줄의 음역대의 영역으로 가져오기 위해

필터가 필요하고 이럴때 간단한 로우패스 필터를 사용하면 도움이 된다.

이론

현재의 결과값을 현재의 입력값 x[n]과 바로 직전의 결과값 y[n-1]을 가중치 알파를 통해 더한다.

모든 샘플을 돌면서 계산하게 되므로 결국 y[n]은 위와 같은 식으로 나오고 이전 값이 지수적으로 영향을 미쳐

지수 이동 평균이라고도 한다.

알파 값을 0.2라고 가정하면

새로운 소리의 반영 비율이 20%밖에 안돼서 갑자기 날카로운 고주파 소리(빠르게 진동하는 파형)가 확 들어와도, 80%의 과거 데이터가 끌어내린다.
결과적으로 빠르게 변하는 고주파(배음, 잡음)는 억제되고, 천천히 변하는 저주파(기타의 기본음)만 살아남는다.
기존 음의 영향력은 샘플이 진행될수록 점점 약해져 완만하게 필터링이 가능하다.

코드 적용

// JDTunerEngine.h
  private:
  
  // ...
  
  // 로우패스 필터용 변수
  float prevLpfOut = 0.0f; // 필터의 이전 출력값을 기억
  float lpfAlpha = 0.2f;   // 필터 강도 (0.0~1.0, 작을수록 고음을 더 강하게 깎음)
  
// JDTunerEngine.cpp

// ...
void JDTunerEngine::collectData(const float* datas, int numSamples) {
  for (int i = 0; i < numSamples; ++i) {
    // 로우패스 필터 적용
    float filteredSample = lpfAlpha * datas[i] + (1.0f - lpfAlpha) * prevLpfOut;
    prevLpfOut = filteredSample;
    collector.push_back(filteredSample);
  }
}
// ...

헤더쪽에 private으로 필터 관련 값을 정의한다.
이전값을 저장하는 프로퍼티를 만들어서 줄바꿈시 기존 줄값을 저장하는거에 대한 걱정이 있었으나
위의 예시를 봤을때 10칸의 데이터만해도 2%만 영향을 주므로
4000개 이상의 버퍼 단위로 다루는 현재 상황에선 줄바꿈시 기존 줄의 값이 남아있어도
큰 영향이 없고 심지어 아예 영향이 없는 수준이어서 연속성을 위해 프로퍼티를 사용하는 방법으로 했다.

결과

불필요한 고음역대와 잡음을 최대한 필터링하는 방식을 적용해

정확도를 더 개선했고 DSP에서 자주 사용되는 1차 필터를 학습했다.

지수 이동 평균 방식은 합연산을 이용해 메모리 관리에 용이한 알고리즘으로

플러그인 만들때도 사용해본적이 있었던 만큼 다시 학습하고 사용해봐서 좋았다.

정확도 개선 1 - Parabolic Interpolation

JD-man — Wed, 11 Mar 2026 20:02:55 +0900

문제점

현재의 pitchTau은 int 타입으로 정수값으로만 계산된다.

따라서 V 형태로 정수 사이값이 고려되지 않은 선형적으로 계산된 값이고 자연스럽지 않다.

그래서 tau값 기준으로 -1, +1을 포함한 3개의 값을 지나는 포물선을 가정하고 최소값 위치를 구하는

Parabolic Interpolation이 필요하다.

이론

위의 포물선이 있다고 가정하고

현재의 tau값을 0이라고 가정하고 양 옆 점이 위와 같다고 하면

위 식을 이용해 연립방정식을 계산하면

c는 베타이기 때문에 위의 결과가 나온다.

식 A와 B를 더하면 a, 빼면 b를 구할 수 있다.

맨 처음 가정한 포물선 방정식을 이용하고 이를 미분해서 최소값이 나오는 x 값을 구하면 위와 같다.

앞서 구한 a와 b 값을 대입하면 x 값을 구할 수 있고 tau를 0이라고 가정했으므로

이 값을 tau에 더해주면 선형적으로 구해진 tau 정수값에서 소수점까지 보정된 값을 구할 수 있다.

적용된 코드

        // 3. Parabolic Interpolation
        if (tau > 0 && tau < (collectorSize / 2) - 1) {
          float alpha = normalizedDifference[tau - 1];
          float beta  = normalizedDifference[tau];
          float gamma = normalizedDifference[tau + 1];
          
          float denominator = alpha - 2.0f * beta + gamma;
          if (denominator != 0.0f) {
            pitchTau = tau + 0.5f * (alpha - gamma) / denominator;
            break;
          }
        }

기존 pitchTau 값을 int에서 float으로 타입을 변경하고

tau에 보정값을 결과값으로 사용하도록 코드를 수정했다.

정수값만 사용했을때보다 그 사이의 소수점 사이값도 모두 사용하므로

튜너의 정확도도 향상되고 변화된 음정을 cents 단위로 더 잘 파악할 수 있게 된다.

DSP 쪽에서 다루는 불연속적인 샘플들을 연속적인 선으로서 파악하게 하는 중요한 보간법이라고 하는데

이번에 잘 공부해서 적용했다!

구조 개선 2 - 비동기스트림

JD-man — Tue, 10 Mar 2026 20:55:39 +0900

현재 구조 및 문제점

현재 구조는 튜너쪽에서 계속 오디오 입력을 받아 결과를 계산하고

뷰쪽에서 Timer를 통해 0.1초마다 Wrapper를 통해 튜너의 결과를 사용하는 방식이다.

private let timer = Timer.publish(every: 0.1, on: .main, in: .common).autoconnect()

// ...

.onReceive(timer) { _ in
  guard let wrapperResult = wrapper.getTunerResult() else { return }
  result = wrapperResult
}

튜너의 기능을 본격적으로 사용하고 있든 말든

뷰쪽에서는 Timer로 계속 호출해 낭비가 생긴다고 판단해

튜너에서 값이 실제로 업데이트 될때마다 뷰를 업데이트 하는 방식으로 구조를 변경하려고 한다.

구조 후보

1. 델리게이트

iOS 앱에서 만들때 객체간 데이터 교환시 자주 사용되는 패턴이다.

하지만 뷰 하나밖에 없는 프로젝트에 비해 프로토콜 및 인터페이스 선언 등 불필요하게 볼륨이 커질거 같아 패스

2. 콜백

델리게이트를 사용하지 않는다면 클로저를 자주 사용하니 떠올릴 수 있는 방식이지만

콜백 지옥에서 탈출하고 싶고 약한 참조 등 메모리 관리가 까다로울거 같아서 패스

3. 비동기 스트림

SwiftUI도 사용하고 있고 modern concurrency를 사용하는게 성능상으로도 좋고

메모리도 안정적일거 같아서 채택

작업 과정

1. 튜너쪽 c++ 콜백 생성

std::function<void(TunerResult)> onResultReady;

헤더쪽에 Wrapper로 데이터를 넘긴 콜백 함수를 만든다.

형태는 std::function<반환타입(파라미터타입)> 변수명 이다.

    this->result = result; 
    collector.clear(); 
     
    // 데이터 처리가 완료되면 등록된 콜백 실행 
    if (onResultReady) { 
      onResultReady(result); 
    }

튜너의 구현부쪽에는 맨 마지막에 해당 콜백 함수를 실행시키는 코드를 추가한다.

2. Wrapper쪽 콜백 생성

@property (nonatomic, copy) void (^onResultUpdate)(WrapperResult *result);

헤더쪽에 Swift쪽으로 값을 넘겨줄 콜백을 만든다.

void (^이름)(매개변수) 형태는 Objective-C의 고유 문법이며, Swift에서는 클로저로 인식한다.

    
    // init....
    __weak typeof(self) weakSelf = self;
    engine->onResultReady = [weakSelf](TunerResult tunerResult) {
      [weakSelf getTunerResult:tunerResult];
    };
  }
  return self;
}

- (void)getTunerResult: (TunerResult) tunerResult {
  WrapperResult *result = [WrapperResult new];
  result.frequency = tunerResult.frequency;
  
  float clampedCents = fmaxf(-50.0f, fminf(50.0f, tunerResult.cents));
  result.cents = clampedCents;
  result.noteName = [NSString stringWithUTF8String:tunerResult.noteName.c_str()];
  result.isMatched = std::abs(clampedCents) <= _centsLimit;
  
  // 튜너로 값을 받아 뷰로 넘긴다
  if (_onResultUpdate) {
    dispatch_async(dispatch_get_main_queue(), ^{
      self->_onResultUpdate(result);
    });
  }

구현부쪽에서는 튜너 결과값을 정리해 콜백을 실행시키는 코드를 추가한다.

3. Wrapper의 AsyncStream화

extension JDTunerWrapper {
  var resultsStream: AsyncStream<WrapperResult> {
    AsyncStream { continuation in
      self.onResultUpdate = { result in
        guard let result else { return }
        continuation.yield(result)
      }
      continuation.onTermination = { @Sendable _ in
        self.onResultUpdate = nil
      }
    }
  }
}

Swift 파일을 만들고 Wrapper를 extension해 AsyncStream을 만든다.

단순히 WrapperResult값을 받아서 continuation으로 yield하는 코드다.

뷰쪽에서 이걸 받아서 상태값을 업데이트 해주려고 한다.

4. 뷰에서 task 사용

    .task {
      // wrapper의 asyncstream 사용
      for await newResult in wrapper.resultsStream {
        self.result = newResult
      }

onReceive 코드를 삭제하고 task 코드로 수정해 비동기 스트림을 사용한다.

결과 및 추가 개선 방향

튜너의 주파수 및 노트 검출 성능에는 영향이 없지만

프로젝트의 구조를 개선해 Timer의 부정확한 타이밍 또는 불필요한 호출을 제거하고

진정한 결과값의 변화를 사용하고 표시하게 됐다.

더 확실한 타이밍에 뷰를 업데이트 하기 위해서

1. 일정 입력 볼륨값일때만 튜너 작동하기

2. 기존 결과값과 다른 경우에만 표시하게 하기

와 같은 작업도 필요해보인다. 이건 다음 포스트에...

구조 개선 1 - 데이터 관리 + 테스트 영상

JD-man — Mon, 9 Mar 2026 20:54:20 +0900

문제점

- (float)getFrequency {
    return engine->getResult().frequency;
}

- (NSString *)getNoteName {
    TunerResult res = engine->getResult();
    return [NSString stringWithUTF8String:res.noteName.c_str()];
}

- (float)getCents {
    return engine->getResult().cents;

현재 Wrappper쪽 코드를 보면 튜너 결과값의 각 프로퍼티 당 메서드 하나를 사용해 사용하고 있다.

튜너쪽 c++ TunerResult 구조체의 변동에 따라 이쪽 코드를 유지보수하기 까다로워보여

Swift쪽에서도 데이터들을 하나로 묶어서 관리할 방법을 생각했다.

해결방식

1. 클래스 정의

#ifndef WrapperResult_h
#define WrapperResult_h

@interface WrapperResult : NSObject
@property (nonatomic, assign) float frequency;
@property (nonatomic, assign) float cents;
@property (nonatomic, copy) NSString *noteName;
@property (nonatomic, assign) bool isMatched;
@end

#endif /* WrapperResult_h */

WrapperResult라는 새로운 클래스를 정의했다.

왜 클래스냐?? 라고 하면 NSString * 때문이다.

미개한 objc는 구조체 안에 참조 타입이 있으면 안된다.

그래서 처음에 구조체로 만들었다가 각종 에러를 맞고 클래스로 변경했다.

2. Wrapper 헤더 및 구현 수정

@property (nonatomic, assign) float centsLimit;

- (WrapperResult *)getTunerResult;

우선 헤더쪽 코드는 간단하게 하나의 프로퍼티와 메서드만 남도록 했다.

centsLimit은 isMatched 계산을 위한 값이다.

private이므로 구현코드에서는 앞에 _를 붙여야 한다.

- (WrapperResult *)getTunerResult {
  auto engineResult = engine->getResult();
  auto cents = fmaxf(-50.0f, fminf(50.0f, engineResult.cents));
  
  // new 사용해서 초기화하는 코드를 사용해야함
  WrapperResult *result = [WrapperResult new];
  
  result.frequency = engineResult.frequency;
  result.cents = engineResult.cents;
  result.noteName = [NSString stringWithUTF8String:engineResult.noteName.c_str()];
  result.isMatched = std::abs(cents) <= _centsLimit;
  return result;

맨 위의 3개의 코드가 하나의 메서드로 합쳐지고 객체의 프로퍼티 관리로 변경됐다.

뷰에서는 이 메서드 하나만 호출하면 되므로 유지보수가 편해졌다.

여기에서 WrapperResult * 객체 생성시 [WrapperResult new]를 꼭 사용해야한다.

3. 뷰 코드 수정

      let currentCents = max(-50, min(50, wrapper.getCents()))
      self.cents = currentCents
      self.noteName = wrapper.getNoteName()
      self.frequency = wrapper.getFrequency()
      self.isMatched = abs(currentCents) <= centsLimit

///////////////////////////////////////////////////////////////////////////
위에서 아래로 코드 변경

     guard let wrapperResult = wrapper.getTunerResult() else { return }
      result = wrapperResult

onReceive쪽 코드가 위에서 아래로 간단하게 변경됐다.

튜너 결과 쪽에서 프로퍼티가 하나 추가됐다면 Wrapper쪽에서 메서드 하나가 추가되고 뷰 쪽에서 여기 코드도 수정되어야 한다.

하지만 지금 구조로 변경후 Wrapper 쪽에서 WrapperResult 객체 생성 메서드만 수정하면 되도록 유지보수가 용이해졌다.

트러블슈팅

objc에서 사용하거나 반환하는 포인터들은 Swift에서 기본적으로 Optional이다.

컴파일 당시엔 빌드가 정상이지만 런타임시 객체를 못찾아서 크래시가 나온다.

Text(result.noteName ?? "---")

뷰 코드 쪽에서 이런 코드가 있는데

WrapperResult의 noteName이 NSString * 으로 포인터다.

이 값이 Swift에선 기본적으로 옵셔널이라 빌드 후 첫 뷰 렌더링때 값을 못찾아서 크래시가 나왔다.

onReceive에서 반환되는 값도 WrapperResult * 로 포인터라서 옵셔널 바인딩을 해줬다.

결과 및 다음 스텝

정상 빌드되고 튜너 기능도 정상 작동한다.

다음 스텝은 뷰쪽에서 Timer를 사용해 튜너 결과값을 가져오는 구조가 아닌

튜너에서 결과값이 변경될때 그 값을 사용하는 반응형으로 수정하려고 한다.

뷰쪽에서 Timer를 사용해 원하지 않은 타이밍에 계속 튜너 값을 사용하기보단

실제로 값이 변경될때 사용하는게 맞는 구조라고 생각해서 진행하려고 한다.

방식은 여러가지가 있겠지만 최대한 최신 문법을 사용하는 방향으로 진행하고 싶다.

테스트 영상

기존에 가지고 있던 튜너와 같이 테스트를 진행해봤는데

정상적으로 감지하고 현재 음이 표시됐다!!

튜너는 진동을 받는 방식이고 앱은 소리를 받는 방식이라

약간의 오차가 있지만 원하는 기능이 제대로 실행되는걸 확인했다!!!

테스트 결과!!

튜너 UI 구현

JD-man — Sun, 8 Mar 2026 19:26:34 +0900

디자인은 AI에게 맡겼다.

그냥 만들어 달라고 했는데 내 스타일대로 심플하게 잘 나왔다.

튜너 뷰 UI

주요 코드

            // 움직이는 바늘
            VStack(spacing: 0) {
              Triangle()
                .fill(isMatched ? Color.green : Color.blue)
                .frame(width: 12, height: 12)
              Rectangle()
                .fill(isMatched ? Color.green : Color.blue)
                .frame(width: 2, height: 20)
            }
            .offset(x: CGFloat(cents) * 3) // 1센트당 3포인트 이동
            .animation(.interactiveSpring(response: 0.3, dampingFraction: 0.6), value: cents)

cents 값이 필요했던 이유다.

offset을 사용해서 cents값에 따라 튜너 바늘이 움직이게 해놨다.

BAD ACCESS 에러

간헐적으로 발생하는 BAD

BAD EXCESS인줄 알았는데 BAD ACCESS였다.

접근이 불가능하다는 에러인데 왜 EXCESS라고 생각했지??

암튼 가끔 이 에러가 발생하면서 크래시가 나왔는데 원인은 튜너쪽 TunerResult의 noteName이

char* 여서 그랬다. Objective-C에서 c++의 주소값을 가져오려다 실패한것.

그래서 값복사를 사용하는 std:string으로 변경했다.

struct TunerResult {
  float frequency;
  std::string noteName;
  float cents;
};

juce_Audio_ios Assertion

또 assert가 발생

튜너 뷰를 만들면서 마이크 권한 코드를 빼서 나왔던 assert 였다.

info.plist에는 마이크 관련 내용이 있는데 코드에는 없으니 나오는거였다.

앱에서의 문제 같은데 이걸 JUCE에서 assert 처리 한게 신기했다.

다음 작업

결과 영상을 보면 튜너가 정확한건지 의심이 든다.

0.0값도 너무 자주 나오고 값이 너무 튀는 느낌이 든다.

다음 작업은 튜너 성능을 테스트하면서 안정적으로 개선하는 것이다.

어려운 작업이 될거 같은데 이 과정에서 배우는거도 많을거 같다.

UI가 나온걸 보니 거의 다온거 같고 얼른 끝내고 싶다.