feat: ピッチ生成APIでピッチの更新を行うようにする

[sigprogramming]

内容

ピッチ生成APIでピッチの更新を行うようにします。

関連 Issue

• ソング：音素タイミングを調整できるようにする #2261

その他

[voicevox-preview-pages]

🚀 プレビュー用ページを作成しました 🚀

• 📝 エディタ
• 📖 Storybook

更新時点でのコミットハッシュ：7b433db

[sigprogramming]

すみません一旦draftにしました！
phraseQueriesのf0を使用しているところが何か所かあったので、それらも変更します…！

[sigprogramming]

変更完了したのでdraft外しました！

[Copilot]

Pull Request Overview

This PR updates the pitch generation API to handle pitch updates and integrates the changes across the store and UI components.

• Added a new action FETCH_SING_FRAME_F0 to the store type and its implementation.
• Updated error handling and property references for pitch generation in singingStore.
• Modified the SequencerPitch component to use the updated pitch data structure.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/store/type.ts	Added FETCH_SING_FRAME_F0 with a spelling typo in parameter
src/store/singing.ts	Updated error messages and integration logic for pitch generation
src/components/Sing/SequencerPitch.vue	Updated to reference new pitch data properties

[romot-co]

LGTMです！！
コード上は特に問題は見つけられませんでした！

レンダリングの流れがなんというか美しい…

---

(もし暇であれば)
ちょっと元のIssueを詳細に把握していなかった…のですが
もし以下の理解に誤りがあればおしらせください！

• 前提: 音素のタイミングの変更機能を段階にわけて実装している
• 修正前: ピッチ生成ステージではクエリ生成時のf0を流用していた
• 問題: 音素タイミング編集と自動補正段でタイミングが変わるとピッチ他も変わるうるはずで、クエリ生成時のf0を流用できない(たぶん…)
• 修正後: フレーズのレンダリングのピッチ生成ステージにおいてAPIで/sing_frame_f0を利用したピッチのみの再推論を入れ、音素タイミング編集機能を実現できるように準備

[Hiroshiba]

LGTM！！！

実装ありがとうございます！！！

もしかしたらどこかの処理に抜け漏れがあったりするかもなんですが、ぶっちゃけわからない･････！
テストを書きたい気持ちもあるけど、例えばclone周りも含めるともはやどういうテストすればいいのかも若干わからない。。！

[Hiroshiba]

@romot-co さんのコメントですが、僕の理解と相違ないです！！

スコア　→　ピッチ　→　ボリューム　→　音声

という合成経路？に音素タイミングが増えて↓こうなって

スコア　→　音素タイミング　→　ピッチ　→　ボリューム　→　音声

スコア＋音素タイミング　→　ピッチが必要になった感じかなと！！

[sigprogramming]

@romot-co
その理解で問題ないです！
整理していただきありがとうございます…！

@Hiroshiba
設計について考えてみたのですが、
今の設計の問題点として、

• ステージが「生成処理」「store.stateの読み書き」「実行の管理」の3つを行っている
  • → 各ステージの入出力や実行順序が分かりにくく、結果としてレンダリンググラフ全体が把握しづらくなっている
  • → グラフの処理とstore.stateが密結合しているので、テストしにくい

というのがあると思っています。

また、レンダリンググラフ自体は複雑ではなく、

• レンダリングが必要なフレーズのみレンダリングする
  • → グラフの必要な部分のみ実行
• mutationを呼ぶ回数を極力少なくする（開発時に重くなるため）
  • → store.stateの差分更新（必要な部分のみ更新）
• レンダリングの進捗を表示する（SequencerPhraseIndicator.vue）
  • → グラフで実行が必要な部分をレンダリング前に確認（ハッシュを計算）

を実現するための処理で複雑になっているように感じています。

これを改善するために、

• 「レンダリンググラフの実行」と「store.stateの読み書き」を分ける
  • 「グラフのノードの入出力・キャッシュ」と「store.stateで持っているピッチなどのデータ」は分ける
• 「グラフの必要な部分のみ実行」ではなく「グラフは全て実行」にして、キャッシュがある部分を先に全て実行し、その後に残りの部分を実行するようにする
  • → 「グラフの必要な部分のみ実行」に近いことを実現できる

という設計に変更するのを考えていて、この設計だと

• グラフの処理がstoreに依存しなくなる
• 各生成処理の入出力が明確になる

ので、テストしやすくなるかもです。