差分

このページの2つのバージョン間の差分を表示します。

--- 2024:07:21 [2024/07/21 19:41] – machiaworx
+++ 2024:07:21 [2024/07/22 02:12] (現在) – machiaworx
@@ 行 1: / 行 1: @@
 ===== プログラム =====
   * ライブコーディングツールの進捗
-  - サンプリング再生機能\\ 実装ずみ
+  - サンプリング再生機能\\ 再生バッファに枠を確保ずみ、サンプリングデータを引っ張ってくる処理はまだ。
   * 二次機能
@@ 行 20: / 行 20: @@
 ----
-  * オーディオとのバッファ遅延については短縮することができた。
+  * オーディオとのMIDIの再生遅延による演奏乱れについては軽減することができた。
   * Play状態の間にバッファを噛ませることにして、一定秒数以上経過したら改めてバッファを進めるようにした。
-  * ただ、これだと発音自体は行っているけどシーケンス自体が進まない状態になってしまうので、ちょっと遅延やノイズが出るようになってしまった。もう仕方ないかな。
+  * これだと発音自体は行っているけどシーケンス自体が進まない状態になってしまうので、ちょっと遅延やノイズが出るようになってしまった。これも対応済み。
-  * もう1個状態を入れてしまうというのは手としてはある。
+  * 細かく指定を入れていくことでどうにかなってきた。
-  * これを行うかどうかは正直どっちでもいい気がしてる。あくまでオーディオとサンプリングの遅延を補正するための手段なのでMIDIには関係ない。
+  * ただ、管理を別にしてしまった弊害として、MIDIとオーディオで同期が取れなくなってきてしまった。\\ 流石に、オーディオとMIDIでサイクルの半分フレーズがズレてきたのには笑ってしまった。
-  * ・・・と思ったけどMIDIの再生には関係ないので、これおかしくね？って思った。拡張が必要。
+  * ということであまり意味がないのかもしれないけど、バッファ更新タイミングでオーディオとMIDIのシーケンス位置について同期を取ることにした。これで再生が大きくおかしくなるのは避けられる。
+----
+  * また、MIDIの1個目の譜面が再生されないバグがあった。\\ 最初はデータが間に合ってないとかかと思ったけど、タイミングの調整を導入したら明らかに間に合っている状態で再生されないため、これはおかしいと調査を開始。
+  * 原因はなんてことはない、「再生可否を確認することなくデータを再生する一択」の処理になっていたことが原因だった。\\ このため、停止を行っても少しバッファが進んでいる状態でしかも1個目のデータが停止するのに鳴っている状態だった。
+  * 再生フラグをしっかり確認して鳴らすようにしたら回避可能になった。
+  * かなり完成度が上がってきてる。なかなか楽しい。
+----
+  * 追加
+  * 上記の多重化のおかげで、別のタイミングで再生情報が初期化されるバグがあったので除去してた。多分1時間くらいかかった。
+  * デバッグは、通常の処理に加えコールバック処理の最初・最後にブレークポイントやprintfを引っ掛けて、タイミングを確認する状態になった。
+  * 今までで一番厄介なバグだった・・・そこまでの蓄積がなければ泥沼にはまってたはず。
+----
+  * ノイズを低減させるために以下の資料を読み込んでみよう
+  * https://postd.cc/four-common-mistakes-in-audio-development/
+  * メインスレッドで言語のコンパイル処理が挟まっているので、これはやべえなと思って、マルチスレッド構造にしてコンパイル処理を別スレッドに流すようにした。
+  * メインスレッドはGUIでファイル参照の心配はほぼないんだけど、コンパイルするときにファイル読んでから行うようにしているので、GUI側でメモリ確保が挟まってしまうこと考えると、マルチスレッドにしておいたほうが安全かなと思い始めた。
+  * デバッグが大変かもしれないけど、基本的にはデータサーバ処理は別物にしているので、どうにかなると思いたい。
+  * で、Releaseでデバッグしてみたところ、うまくスレッド周りが終了しないことが発覚。何かと思ったら最適化によって正常に動かなくなっていたという。
+  * https://ameblo.jp/super-hk/entry-12678708771.html
+  * 危なかった・・・（汗