この記事では、どのようにしてチューナーを作成するアイデアを思いついたのか、それが何につながったのかについて説明します。 また、大学で取得したDSP（デジタル信号処理）の分野での控えめな知識と、それらがどのようにいくつかの問題の解決に役立ったかを共有します。 そしてもちろん、このプロジェクトの実装中に得たSwiftでのソースコードとプログラミングの経験を共有します。

背景

ギター用に自分のチューナーを書くというアイデアは、私が大学にいた10年ほど前のかなり前に思いつきました。 これにはいくつかの理由がありました。

• まず、それほど高品質のチューナープログラムはそれほど多くありません。一部は単に周波数を誤って決定するか、上部の弦で非常に不安定に動作します。 さらに、私が出会ったすべてのチューナーは、A440に事前に調整されています（ 最初のオクターブで 440 Hzに調整されている場合）。 ただし、C256の設定もあります（ 最初のオクターブまで 256 Hzに調整されています ）。 多くのチューナーはフレットのチューニングを許可していませんが、5〜7フレットで演奏する必要がある場合は、同じフレットで楽器をチューニングすることをお勧めします。
• 第二に、スライダー、スペクトルまたは周波数波形の形での設定の視覚化は、私の意見では、少し物理的です。 ツールによって生成された波がどのように直接見えるか-どれだけきれいか、またはその逆の歪みを示したかったのです。 視覚化と応答を視覚化します。
• 第三に、私は大学で得られたDSPの分野での私の知識を人類の利益に適用したかった。

一般的に、このアイデアは長い間頭にありましたが、ようやく空き時間、iOsデバイス、モバイル開発の経験があったので、今年しか実現できませんでした。

理論のビット

ヨーロッパの弦楽器に少し精通している人なら誰でも、各弦が特定の音に合わせられており、特定の周波数がこの音に対応していることを知っています。 音符と周波数の違いは、各音符に音楽的な機能があることです。 そして、この機能は、他の音に対する音の相対的な位置によって決まります。たとえば、 Cメジャーシーケンスのノートtoは、 トニックの役割を果たします。 メインで最も安定したサウンド。 この音符が少し動いた場合、その機能を失います。 抽出された音が音符に対応するためには、音符の間隔と周波数の比率の間の厳密な対応関係を観察する必要があります。 抽出された音と音符に記載された関数の対応は、弦によって生成される周波数の精度と安定性に依存します。



弦によって生成される音は何ですか？ アメリカの研究者であり作曲家のウラジミール・ウサチェフスキーが最初のシンセサイザーに提案したADSRモデルを使用すると、弦の音は何らかのエンベロープで変調された調和振動になります。 このエンベロープはADSRと呼ばれます。 4つの特徴的なポイントがあります：攻撃（ 英語の攻撃 ）、衰退（ 英語の減衰 ）、持続（ 英語の持続 ）、減衰（ 英語のリリース ）。











サステイン間隔は、周波数を最も明確に伝えます。 振幅はほとんど変化せずに変動します。 ギターが理想的な単調音を生成する場合、ADSRエンベロープを考慮に入れると、このような振動のスペクトルは狭いストリップの形になります。 このストリップの形状は、エンベロープスペクトルに対応します。











しかし、実際の機器は非線形振動プロセスを生成し、その結果、倍音と呼ばれる追加の高調波が現れます。











これらの倍音は、かなり潜行性のある仲間の旅行者です。 それらは基本音に勝り、周波数の決定を妨げる可能性があります。 しかし、それでも、通常、メイントーンは追加の操作なしで明確に定義されます。



したがって、これらの表現に基づいて、プログラムが動作するパスを概説できます。

1. 音波のフーリエ変換を計算する
2. スペクトルの基本音を見つける
3. ピッチ周波数を計算する

定在波について

通常、グラフ上の音は時間掃引として表されます。 横軸のゼロ点では、値は観測の最初の瞬間にあり、それぞれ1秒、2秒など後に観測される値になります。 この場合の測定プロセスは、左から右に均一に移動する架空のフレームとして想像できます。 このフレームは別の名前で呼び出すことができます：観測ウィンドウ（ 英語の観測ウィンドウ ）、観測間隔（ 英語の観測間隔 ）、時間ウィンドウ（ 英語の時間ウィンドウ ）-これらの用語はすべて同じことを意味します。











したがって、フレームにより、測定プロセスがどのように行われ、どの瞬間がフレームの最初に表示され、どの瞬間が最後に表示されるかを理解できます。 これに基づいて、座標系とフレームを比較するとどうなるか想像できます。音波はグラフの右側に表示され、左側に消えたように感じます。 そのような波は進行と呼ばれます：











しかし、音波のそのような表現は有益ではありません。なぜなら、 波は非常に速く動くことができます。 私たちの仕事は、どういうわけか波を止めることです。 波が止まるためには、その速度が0に等しいことが必要です。 波には2つの速度があります。フェーズとグループです。2種類の定在波を取得できます。











グループ速度がゼロに等しい定在波は、そのエンベロープが常に1つの場所に残るという事実によって特徴付けられます。 しかし同時に、振動は止まりません-ゼロとハンプは横座標に沿って動き続けます。 明らかに、そのような波は私たちには適していない、なぜなら 興味深いのは、ADSRエンベロープの内部、つまり、サステインモードで振動が観測される瞬間です。



これを行うには、位相速度がゼロの別のタイプの定在波があります。











位相速度がゼロの場合、ノードとハンプは常に1か所に留まるため、高調波振動の形状を簡単に確認して、理想的な正弦波形状にどれだけ近いかを評価できます。 そのような波を得るためのアルゴリズムは明らかです：

1. ピッチ段階を見つける
2. 表示された波を位相ごとにシフトします

実装

マイク録音

実際、AppleはObjective-C / Swiftから多くの高レベルのマルチメディア機能を提供しています。 しかし、本質的に、サウンドの操作はAudio Queue Servicesを中心に展開されます。

Audio Queue Servicesは、以前にSound ManagerおよびOS Xで提供されていた機能と同様の機能を提供します。同期などの追加機能を追加します。 Sound ManagerはOS X v10.5で非推奨になり、64ビットアプリケーションでは機能しません。 Audio Queue Servicesは、すべての新規開発および既存のMacアプリのSound Managerの代替として推奨されます。

ソース

しかし、かなり高レベルのソリューションであったSoundManagerとは異なり、Audio Queue Servicesは、Swift Cコードを単純に繰り返す不器用なラッパーです。

func AudioQueueNewInput(_ inFormat: UnsafePointer<AudioStreamBasicDescription>, _ inCallbackProc: AudioQueueInputCallback, _ inUserData: UnsafeMutablePointer<Void>, _ inCallbackRunLoop: CFRunLoop!, _ inCallbackRunLoopMode: CFString!, _ inFlags: UInt32, _ outAQ: UnsafeMutablePointer<AudioQueueRef>) -> OSStatus
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Swiftには低レベルのコードからの利益はないため、オーディオキャプチャは補助Cコードに任せました。 バッファ管理のマイナーコードを省略した場合、レコードのセットアップは、AudioQueueNewInput関数を使用してAQRecorderState構造体を初期化することです。

  void AQRecorderState_init(struct AQRecorderState* aq, double sampleRate, size_t count){ aq->mDataFormat.mFormatID = kAudioFormatLinearPCM; aq->mDataFormat.mFormatFlags = kLinearPCMFormatFlagIsPacked | kLinearPCMFormatFlagIsSignedInteger; aq->mDataFormat.mSampleRate = sampleRate; aq->mDataFormat.mChannelsPerFrame = 1; aq->mDataFormat.mBitsPerChannel = 16; aq->mDataFormat.mFramesPerPacket = 1; aq->mDataFormat.mBytesPerPacket = 2;// for linear pcm aq->mDataFormat.mBytesPerFrame = 2; AudioQueueNewInput(&aq->mDataFormat, HandleInputBuffer, aq, NULL, kCFRunLoopCommonModes, 0, &aq->mQueue); DeriveBufferSize(aq->mQueue, &aq->mDataFormat, (double)count / sampleRate, // seconds &aq->bufferByteSize); for (int i = 0; i < kNumberBuffers; ++i) { AudioQueueAllocateBuffer(aq->mQueue, aq->bufferByteSize, &aq->mBuffers[i]); AudioQueueEnqueueBuffer(aq->mQueue, aq->mBuffers[i], 0, NULL); } aq->mCurrentPacket = 0; aq->mIsRunning = true; aq->buffer = Buffer_new(32768); aq->preview_buffer = Buffer_new(5000); AudioQueueStart(aq->mQueue, NULL); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データの記録は、HandleInputBuffer関数を介して行われます。 Buffer_write_intsを呼び出すと、データがintからfloatに変換され、さらに処理するためにバッファーに保存されます。

  static void HandleInputBuffer ( void *aqData, AudioQueueRef inAQ, AudioQueueBufferRef inBuffer, const AudioTimeStamp *inStartTime, UInt32 inNumPackets, const AudioStreamPacketDescription *inPacketDesc ) { struct AQRecorderState* pAqData = (struct AQRecorderState*)aqData; if(inNumPackets == 0 && pAqData->mDataFormat.mBytesPerPacket != 0) inNumPackets = inBuffer->mAudioDataByteSize / pAqData->mDataFormat.mBytesPerPacket; const SInt16* data = inBuffer->mAudioData; Buffer_write_ints(pAqData->buffer, data, inNumPackets); Buffer_write_ints(pAqData->preview_buffer, data, inNumPackets); if (pAqData->mIsRunning == 0) return; AudioQueueEnqueueBuffer(pAqData->mQueue, inBuffer, 0, NULL); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パフォーマンスの問題とSwift

当初、アイデアはSwift言語を100％使用することでした。 一般的に、私はそうし、Accelerateライブラリの実装が使用されたFFTを除くSwiftのすべてのコードを書き直しました。 しかし、奇妙なことに、Swiftバージョンはプロセッサ時間の95％の領域で大きな負荷を発生させ、信号処理の遅延によりレンダリングが非常に遅くなりました。



もちろん、この形式では、アプリケーションは使用に適していないため、すべての信号処理をAccelerateライブラリーに完全に転送する必要がありました。 しかし、この後でも、負荷は依然として高いままでした。 1つのパスのみを必要とする配列を使用して、これらの操作をCに転送する必要がありました。 線形ランタイム。 説明のために、SwiftとCで同じコードを示します。

  class Processing{ ... func getFrequency() -> Double { var peak: Double = 0 var peakFrequency: Double = 0 for i in 1..<spectrum.count/2 { var spectrumValue: Double = p->spectrum[i] var f: Double = fd * i / spectrum.count if (spectrumValue > peak) { peak = spectrum[i] peakFrequency = f } } return peakFrequency } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

  double get_frequency(p* processing){ double peak = 0; double peakFrequency = 0; for(size_t i = 1; i < p.spectrumLength / 2; i ++){ double spectrumValue = p->spectrum[i]; double f = p->fd * i / p->spectrumLength; if (spectrumValue > peak) { peak = spectrum; peakFrequency = f; } } return peakFrequency; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、1秒間に20コールの頻度のサイクルでアレイを簡単に通過しても、デバイスにかなりの負荷がかかる可能性があります。



おそらくこれはSwiftの最初のバージョンの問題でしたが、最終的にはビット単位の操作を実行するすべてをSwiftから完全に除外する必要がありました。 そのため、Swiftでは、配列の作成、Cで記述された補助ライブラリへの引き渡し、およびOpenGL ES 2でのコードのレンダリングを担当する担当者は1人だけでした。



しかし、Swiftは役に立ちましたか？ もちろん、高レベルのタスクに関しては、Swiftはこの罰金に対処します。 コードの記述ははるかに快適であり、最新の構文では、セミコロンが一定でなく、多くの直感的で便利な構文糖が必要です。 したがって、Swiftを使用するといくつかの問題が発生するという事実にもかかわらず、一般的に、この言語は非常に優れているように見えました。

マイク感度の問題

そのため、Cでコードの一部を書き換えた後、ギターをチューニングできる瞬間が近づいているように見えました。 しかし、その後、私はまったく考えなかった別のトラブルが発生しました。 iPhoneのマイクは、スペクトルの低周波部分をひどくカットします。 もちろん、スマートフォンのマイクは理想とはほど遠いものと想定しましたが、すべてがはるかに悪いことが判明しました。 閉塞はすでに200 Hzで始まりました。











ギターのチューニングに関しては、このような周波数応答の妨害により、6弦のチューニングが不可能になります。 周波数は約80 Hzです。 この弱体化により、基本音は周波数160 Hz、240 Hzなどの高調波で沈み始めます。











この問題に対する2つの可能な解決策をすぐに概説しました。

• 0.5の周波数の基本周波数で双子が現れる場合、これは基本音が消音されていることを示し、結果の周波数を調整して1 / 2fにする必要があります。
• ユーザーが弦のトーンよりわずかに高い周波数をカットするローパスフィルターで倍音を抑制することができます

最初のオプションはもっと面白そうだ。なぜなら、 ユーザーの追加の努力は必要ありませんでした。 それにもかかわらず、彼は完全に裕福ではなかった。 多くの悪い状況につながりました。 たとえば、主周波数がマイクによって非常に強くカットされ、その最初の高調波の1〜2％のレベルになることがありました。 さらに、 ギターのレゾネーターは非常に非線形なデバイスであるため、2番目、3番目、さらには4番目の高調波が振幅で競合し始めると、状況がしばしば発生しました。 これにより、トーンはメインのトーンよりも4倍高くキャプチャされるという事実に至りました。



原則として、これらの問題はプログラムで解決できます。 失望の主な原因は、ギターの倍音が非常に大きく動くため、それらを調整しても±0.1 Hzの精度が得られないことです。 これは明らかに、メイントーンがかなり安定した周波数の弦によって設定されるという事実によるものであり、逆に、高調波は主にギターボディの振動のためにサポートされ、弦の音中に数ヘルツずれることがあります。



したがって、最初の決定は、より予測可能で利便性の低い決定のために放棄されなければなりませんでした。 そのため、ローパスフィルターの周波数応答はほぼ次のようになります。







カットオフ周波数の右側の障害物は倍音を抑制し、ピッチが再び広くなるようにします。 信号対雑音比のこの全体的な低下の代価は支払われ、その結果、精度はわずかに低下しますが、許容範囲内です。

精度とパフォーマンス

デジタル信号処理では、観測ウィンドウのサイズを選択するタスクが常にポップアップします。 大きな観測ウィンドウを使用すると、より多くの情報を収集して、信号パラメーターの正確で安定した推定を行うことができます。 一方、これは、一度に多数のサンプルを保存および処理する必要があるという事実に加えて、信号処理の比例遅延に起因する多くの問題を引き起こします。



同様に、Accelerateでは、32,768サンプルを超えないシーケンスのスペクトルを計算できます。 しかし、このような数のカウントは、スペクトル内の周波数グリッドのステップが約1.35 Hzであることを意味します。 一方で、これは、たとえば、 440 Hzの周波数を持つ最初のオクターブ 、つまり 開いている最初の文字列（最も細い）で取得されるノート。 しかし、6番目の文字列では、そのような間違いは致命的です。 たとえば、 大きなオクターブのmiと、大きなオクターブの間にあるのは 3 Hzだけです。 つまり 1.35 Hzのエラーは、トーンの半分のエラーです。







それにもかかわらず、この問題の解決策は非常に簡単ですが、時間周波数分析のフルパワーも示しています。 なぜなら 数秒の信号を蓄積することは不可能であるため、フーリエ変換を繰り返して基本周波数のスペクトルの値を蓄積できます。 数学的には、結果は基本周波数で1.35 Hzのフィルターを処理するのと同等です。 複雑な読み取り値が16個しかないため、結果の精度を16倍にできます。 最大約0.08 Hzで、わずかに正確な±0.1 Hzです。







つまり、基本音の値に関する情報がない場合、時間枠を5秒に増やして、±0.1 Hzの精度を取得し、163840サンプルを処理する必要があります。 しかし、以来 0.743秒の時間枠では、1.35 Hzの精度で周波数推定値を作成できます。より正確な推定値を得るには、2.7 Hzのサンプリングレートで非常に狭い帯域からサンプルを蓄積するだけで十分です。 このためには、2.7 Hz * 5 s = 13.75の複雑な読み取り値（または丸めてマージンを取って取得する場合は16）で十分です。

音符と周波数の一致

このタスクは、Swiftでは非常に簡単に解決できます。 サポートされているツールとマッチングルールに関するすべての情報を入力する特別なTunerクラスを作成しました。 これらの計算はすべて、2つの式「baseFrequency * pow（2.0、（n-b）/ 12.0）」および「12.0 * log（f / baseFrequency）/ log（2）+ b」に基づいています。

ここで、baseFrequencyは440 Hzまたは256 Hzの基本周波数であり、bはからsubcontractまでの整数のノート番号です。



コードは非常に中国語です：

 class Tuner { ... init(){ addInstrument("guitar", [ ("Standard", "e2 a2 d3 g3 b3 e4"), ("New Standard", "c2 g2 d3 a3 e4 g4"), ("Russian", "d2 g2 b2 d3 g3 b3 d4"), ("Drop D", "d2 a2 d3 g3 b3 e4"), ("Drop C", "c2 g2 c3 f3 a3 d4"), ("Drop G", "g2 d2 g3 c4 e4 a4"), ("Open D", "d2 a2 d3 f#3 a3 d4"), ("Open C", "c2 g2 c3 g3 c4 e4"), ("Open G", "g2 g3 d3 g3 b3 d4"), ("Lute", "e2 a2 d3 f#3 b3 e4"), ("Irish", "d2 a2 d3 g3 a3 d4") ]) ... } ... func noteNumber(noteString: String) -> Int { var note = noteString.lowercaseString var number = 0 var octave = 0 if note.hasPrefix("c") { number = 0; } if note.hasPrefix("c#") { number = 1; } ... if note.hasPrefix("b") { number = 11; } if note.hasSuffix("0") { octave = 0; } if note.hasSuffix("1") { octave = 1; } ... if note.hasPrefix("8") { octave = 8; } return 12 * octave + number } func noteString(num: Double) -> String { var noteOctave: Int = Int(num / 12) var noteShift: Int = Int(num % 12) var result = "" switch noteShift { case 0: result += "c" case 1: result += "c#" ... default: result += "" } return result + String(noteOctave) } func noteFrequency(noteString: String) -> Double { var n = noteNumber(noteString) var b = noteNumber(baseNote) return baseFrequency * pow(2.0, Double(n - b) / 12.0); } func frequencyNumber(f: Double) -> Double { var b = noteNumber(baseNote); return 12.0 * log(f / baseFrequency) / log(2) + Double(b); } func frequencyDistanceNumber(f0: Double, _ f1: Double) -> Double { var n0 = frequencyNumber(f0) var n1 = frequencyNumber(f1) return n1 - n0; } func targetFrequency() -> Double { return noteFrequency(string) * fretScale() } func actualFrequency() -> Double { return frequency * fretScale() } func frequencyDeviation() -> Double { return 100.0 * frequencyDistanceNumber(noteFrequency(string), frequency) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

定在波の可視化

楽器の音波の形状を見ることができる定在波については、すでに書いたように、アルゴリズムはまったく簡単です-波長は見つかった基本周波数から計算され、位相が推定され、その後、見つかった値からシフトが行われます データは補助プレビューバッファから取得されますが、メインバッファとは異なり、蓄積されません。 つまり 「 タンブリングウィンドウ 」アルゴリズムに従って動作します。

  double waveLength = p->fd / f; size_t index = p->previewLength - waveLength * 2; double* src = &p->preview[index]; //            double re = 0; double im = 0; for (size_t i = 0; i < waveLength*2; i++) { double t = (double)2.0 * M_PI * i / waveLength; re += src[i] * cos(t); im += src[i] * sin(t); } double phase = get_phase(re, im); //     double shift = waveLength * phase / (2.0 * M_PI); //   //     double* shiftedSrc = &p->preview[index - (size_t)(waveLength - shift) - (size_t)waveLength];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

外観

内蔵プレーヤーに基づいて作成した外観とナビゲーションは、トラックを切り替える代わりに、ストリングの切り替えが発生します：

おわりに

Swift / Cアプリケーションの開発パス全体には約2か月かかりました。 アプリケーションの実装は非常に困難であることが判明しました。 第1に、スマートフォンのパフォーマンスには依然として多くの課題が残されており、高級言語での「直接的な」ソリューションは、ユーザーによる日常的な使用にはまったく不適切であることが判明しています。 第二に、サウンド処理のトピックは、iOの開発者の間で非常に人気がないため、情報を少しずつ収集する必要があります。 これはおそらく、モバイルアプリケーション向けに開発する際のUIに関連しないトピックに関するものです。 第三に、SwiftはCデータと十分に通信できますが、とにかくこの開発方法はひどく不便であり、ひどく労働を消費します。



記事が非常に重要であることが判明したという事実にもかかわらず、多くの微妙さと微妙なニュアンスは未解決のままでした。 アプリケーションのソースコードが理解できない点を明確にするのに役立つことを願っています。



github.com/kreshikhin/scituner



ソースコードには、MITライセンスが付属しています。 したがって、目的のコードセクションまたはプロジェクトコード全体を安全に使用できます。