ソング：フレーズのレンダリング処理をリファクタリング

[sigprogramming]

内容

以下を行います。

• PhraseRendererを追加
• QueryGenerationStageを追加
• SingingVolumeGenerationStageを追加
• SingingVoiceSynthesisStageを追加
• 以下の関数をphraseRendering.tsに移動
  • createNotesForRequestToEngine
  • shiftKeyOfNotes
  • getPhonemes
  • shiftPitch
  • shiftVolume
  • muteLastPauSection
• フレーズのレンダリング処理をPhraseRendererを使用して行うように変更
• フレーズの開始時間（startTime）をPhraseに持たせ、算出をフレーズ生成時に行うように変更
• PhraseStateにSINGER_IS_NOT_SETを追加
• 型を整理

レンダリングの流れ

1. 重なっているノートを除外
2. searchPhrasesを実行
3. 新しいフレーズまたは既存のフレーズに対して以下を行う
   1. シンガーが未設定の場合、stateをSINGER_IS_NOT_SETに設定
   2. シンガーが設定されている場合、以下を行う
      1. 新しいフレーズまたはstateがCOUND_NOT_RENDERの場合、レンダリング開始ステージを一番最初のステージに設定
      2. 既存のフレーズの場合、適切なレンダリング開始ステージを決定する
      3. stateをWAITING_TO_BE_RENDEREDに設定
4. 無くなったフレーズに対して、以下を行う
   1. シーケンスが存在する場合、シーケンスを削除する
5. stateがSINGER_IS_NOT_SETまたはWAITING_TO_BE_RENDEREDのフレーズに対して、以下を行う
   1. シーケンスが存在する場合、シーケンスを削除する
   2. ノートシーケンスを生成して登録する
6. stateがWAITING_TO_BE_RENDEREDのフレーズに対して以下を行う
   1. フレーズのレンダリングを行う
   2. シーケンスが存在する場合、シーケンスを削除する
   3. オーディオシーケンスを作成して登録する

関連 Issue

ref #2247

その他

[sigprogramming]

以下の関数と変数はsinging.tsのRENDERから持ってきたもので、ほとんど変更していません。

• createNotesForRequestToEngine
• shiftKeyOfNotes
• getPhonemes
• shiftPitch
• shiftVolume
• muteLastPauSection
• singingTeacherStyleId
• lastRestDurationSeconds
• fadeOutDurationSeconds

[Hiroshiba]

プルリクエストありがとうございます！

もしよかったら @sevenc-nanashi さんもレビューいただけると････！！

[Hiroshiba]

すみません、+-2000行が圧巻で、かつアーキテクチャ結構変わっているのでレビューの手がつけづらく 🙇
ということでいくつかお聞きできると･･･！

あ、質問に番号振ってますが、特に順番とかは意識しておらず、知りたい観点を分けてみた次第です！

1. どこから追っていくのがおすすめでしょうか 👀

RENDER()action？　src/sing/phraseRendering.ts？
上から見ていく？　render()から？　Stageから？

2. 既存のRENDER関数で行っていた処理の流れは変わったか

（ほぼ）変わってないという認識だけど念の為

3. phraseRenderingの責務範囲

PRのdescriptionに書いてくださってるレンダリングの流れの中のどこがどっちなのかわからない感じです！

RENDER関数側にも結構処理が残ってるので、「フレーズレンダリングの処理全部を移した」ということではなさそう？
キャッシュ用のキー作成部分・キャッシュする部分・エンジンリクエスト等はどちらかなど。
そもそもそういった一連の処理を行うのか、データの依存（順番）だけ制御するのかとか。

4. Stageとは

phraseごとに持つ？　メインプロセスが１つずつ持ってる？
ここがデータの依存関係をうまいこと解決する？
RENDER関数側からはあんまり気にしなくていい？

---

いろいろ聞いてしまってすみません！設計思想だけ教えていただけると･･･！
（どういう処理を追加・消えたのかや最終的に流れがどうなったかに加え、どういうやり方で整理をつけたのか知りたい感じです）

[sigprogramming]

@Hiroshiba
変更行数が多くなりすみません…

4. Stageとは

Stageは、エンジンリクエスト部分とその周辺の処理をまとめたもので、PhraseRendererが1つずつ持っています。
このPRで実装したステージは以下の3つです。

1. クエリ生成（フェッチ）ステージ
2. ボリューム生成ステージ
3. 音声合成ステージ

これらのステージがこの順序で保持されていることを前提に、フレーズレンダラーが各ステージの処理を呼び出す感じになっています。
キャッシュ用のキー作成部分・キャッシュする部分・エンジンリクエスト（の関数を呼ぶ）等はステージが行います。

以前はrender関数内にひと続きに書いていて、どこまでがクエリ生成に関係する処理で、どこからがボリューム生成に関係する処理なのかが分かりにくくなっていたので、ステージとして分割しました。

3. phraseRenderingの責務範囲

PhraseRendererはフレーズのレンダリング（各ステージの処理の実行）を制御する責務を負っています。
具体的には以下を行います。

• 各ステージの処理の実行が必要かどうかのチェックを行う
• 各ステージの処理を実行する前に、前回のレンダリング結果の削除を行う
• 各ステージの処理を正しい順序で実行する

例えば、ピッチの編集を行ったときは以下を行います。

1. 各ステージの処理の実行が必要かどうかをチェック
   → ボリューム生成ステージと音声合成ステージの処理の実行が必要
2. 前回のレンダリングで生成されたボリュームと音声を削除
3. ボリューム生成ステージと音声合成ステージの処理を実行

PRのdescriptionに書いてくださってるレンダリングの流れの中のどこがどっちなのかわからない感じです！

以下の2つはPhraseRendererが行う処理で、それ以外はrender関数が行う処理になります！

• 既存のフレーズの場合、適切なレンダリング開始ステージを決定する
• フレーズのレンダリングを行う

1. どこから追っていくのがおすすめでしょうか

ひとまずphraseRendering.tsの型定義を読んで、その後PhraseRendererと各Stageの実装を読んでいくのが良いと思います…！

フレーズレンダラーと各ステージは、SnapshotとPhraseからFrameAudioQuery等を生成しPhraseにセットするということを行っています。
queryGenerationStage.execute()の前後で変化するのは以下の3つです。他のステージも同様です。

• state.phraseQueries ←生成されたクエリがセットされる
• phrase.queryKey ←生成されたクエリのキーがセットされる
• queryCache ←生成されたクエリとそのキーがセットされる

state.phraseQueriesはキャッシュではなく（クリアするとバグります）、フレーズのクエリを保持します。
queryCacheはキャッシュ（どのタイミングでクリアしても問題ない）で、これまでに生成されたクエリを保持します。
ボリュームや音声も同様です。

2. 既存のRENDER関数で行っていた処理の流れは変わったか

以前は音声の再合成が必要な場合、フレーズ更新のタイミングで音声の削除を行っていましたが、このPRではフレーズレンダリングの直前で行うように変更しています。
また、track.singer == undefinedのときにphrase.stateがSINGER_IS_NOT_SETになるように変更しています。
それ以外はほぼ変わっていないはずです…！

[Hiroshiba]

ほぼLGTMです！！

解説ありがとうございます！！！よくわかりました！！

かなり初見で迷いやすいコードになっているので、ドキュメント足しを提案してみました。
あとはコードのちょっとした提案が主です！

そろそろdocs辺りにソング周りの全体設計を書いた方が良さそうという思いが強くなってきました。
処理の細かい部分は実装を見てもらうことにして、なぜこういう実装になっているのかを数行ずつで紹介していく、みたいなのを想像しました！

（ドキュメントではなく、コードのファイルの一番上に書いてもいいかも。）

[sigprogramming]

@Hiroshiba
レビューありがとうございます！
確かにそろそろドキュメントを書いていった方が良さそうですが、タイミング編集機能の実装のためにとりあえずで設計して実装した感じで、要件や設計についての議論をissueで行っていないので、もっと良い設計・モデルにするために議論を行った方が良いかもと思っています。
ひとまずこのPRの設計で一旦タイミング編集機能を実装できればと思います。

[Hiroshiba]

@sigprogramming ドキュメントに関して了解です！！

議論を重ねてより良いドキュメントを作ればというのもなるほどです！
ただよくよく考えると、設計を議論するためにはそもそも現状の設計を理解する必要があって、そのためにはなんだかんだ今の設計図があると便利かもです 😇 😇 😇
逆に最初は、新規の参入者の方が理解できるような良いドキュメントでなくても、ちょっとソング実装を知っていれば想像できるようなレベルのものでも良さそうかも。

再度レビューしたいと思います！

[Hiroshiba]

LGTM！！！

リファクタリングありがとうございます！！