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

[sigprogramming]

内容

音素タイミングを調整できるようにします。

タスクリスト

• 仕様を決める
• 設計する
• 実装する
  • store周りを変更
  • ピッチ更新APIに対応する（ピッチ更新APIはエンジン側で実装）
  • プロジェクトファイル
    • 保存＆読み込み
    • マイグレーション
  • UIを実装

仕様と設計がまだ決まっていないので、本issueで議論できればと思います。
ひとまず以下の点（適宜追記します）：

• ノートを移動したときに音素タイミングが保持されるようにするかどうか
  • 推論された音素タイミングに対してオフセットの形で編集データを保持する？
  • 前後の音素タイミングと干渉する場合、どう補正するか
• ノートの歌詞を編集したとき、歌詞編集の前後で変わっていない音素のタイミングを保持するか
  （個人的に：これは保持しなくても良さそう）
• UIをどうするか
  • 音素タイミング調整エリアの位置
  • 音素の表示位置
  • ノートのタイミングを表示するかどうか
  • 波形を表示するかどうか（実装大変かもなので最初は無くても良いかも）
  • 編集方法（音素タイミングの線をドラッグなど）

Pros 良くなる点

• 音素タイミングが調整できるようになる

Cons 悪くなる点

• 特になし

その他

[sigprogramming]

仕様やUIについて考えてみました：

• ノートを移動したときに音素タイミングが保持されるようにするかどうか
  • なるべく保持されるようにしたい
  • ワークフローをノート編集→タイミング編集の一方向にしたくない
• ノートの歌詞を編集したときに音素タイミングが保持されるようにするかどうか
  • 保持しなくても良いかも
    • ノートの歌詞が変わる＝ノートの音素がすべて更新（リセット）される
• 編集データをどう保持するか
  • A：推論された音素タイミングに対してオフセットの形で編集データを保持する
    • 「ノートの位置」＋「推論結果」＋「ユーザーの編集」
    • ノートを移動して再推論が行われると微妙に音素タイミングがずれてしまう
  • B：ノートに対してオフセットの形で編集データを保持する
    • 「ノートの位置」＋「ユーザーの編集」
    • ノートを移動して再推論が行われたとき、推論結果が使用されず、場合によってはタイミングが不自然になるかも
  • ざっくりした編集の場合はAでも良さそう、オケを聞きながら微調整した場合はBになってほしいかも
    • 「子音を溜める、グルーブ感をだす、発音を調整する」などで、AとBどちらの挙動が嬉しいかを考える
  • AとBを混ぜるのも良いかも…？
  • 「母音のタイミング」と「子音の長さ」で持つのも良いかも
    • 「子音のタイミング」というより「子音の長さ」を変えたいということが多そう…？
• 音素タイミング調整エリアの位置
  • シーケンサーの上から下までタイミングの線を表示する必要はないと思う
  • 上はルーラー（再生位置、ループ範囲、拍子・テンポなど）でごちゃごちゃすると思うので、下が良いかも
• 音素の表示位置
  • 音素タイミングの線の右に表示が良さそう
• ノートのタイミングを表示するかどうか
  • ノートの開始タイミングと母音のタイミングのずれが分かるように、表示した方が良さそう
• 波形を表示するかどうか
  • 必須ではないが、表示された方がデザイン的には良いかも
  • 波形のエンベロープが見れたほうが調整しやすいかも…？
• 編集方法
  • タイミングの線をドラッグが直感的かも？

[Hiroshiba]

ちょっと思いついたポイントをコメントまで！！
（どれも強い意見ではなく、何かの参考になればと思ってのコメントです 🙏 ）

ノートの歌詞を編集したときに音素タイミングが保持されるようにするかどうか
保持しなくても良いかも
ノートの歌詞が変わる＝ノートの音素がすべて更新（リセット）される

僕もこの方針に賛成なのですが、よく考えたらピッチの方とボリュームの方は上流が変更されても編集データは保持される形なので、そこと使用感が変わることになることは意識してもいいのかもと思いました！
とりあえず一番いいと思うのを実装してみて、使用感がいまいちだったら再考する形が良さそうかも･･･！

編集データをどう保持するか

これめちゃくちゃ悩みますね。。。。。。。。。。
僕の中でどれが良さそうか全く定まっていませんが、考慮すべきポイントが思いついたので１つだけ。。

将来的に1ノートの中に複数の音素が入ることがあり得ると思います。
日本語だと母音が続くパターンとか、英語だと子音が続くパターンとか。
（日本語だと「わんw a N」とか、英語だと「すりーθ r í ː」とか）

音素の表示位置
音素タイミングの線の右に表示が良さそう

右か左どちらが良いか分からないのですが、将来的にBPMが拍子などを可変にした時にも線の横に文字を書くことになりそうで、そっちとも合わせられると良さそう感！

ノートのタイミングを表示するかどうか
ノートの開始タイミングと母音のタイミングのずれが分かるように、表示した方が良さそう

ノートのタイミングを縦線で示すと、それはそれで線だらけになりそうな気も少ししますね･･･！
でもやってみて問題なさそうなら問題なさそう！

[sigprogramming]

僕もこの方針に賛成なのですが、よく考えたらピッチの方とボリュームの方は上流が変更されても編集データは保持される形なので、そこと使用感が変わることになることは意識してもいいのかもと思いました！
とりあえず一番いいと思うのを実装してみて、使用感がいまいちだったら再考する形が良さそうかも･･･！

確かに使用感が変わりますね…
一旦保持される形で実装してみようと思います。

将来的に1ノートの中に複数の音素が入ることがあり得ると思います。
日本語だと母音が続くパターンとか、英語だと子音が続くパターンとか。
（日本語だと「わんw a N」とか、英語だと「すりーθ r í ː」とか）

複数音素（複数モーラ）の場合ですが、理想はSynthVのように音素の長さ（％）で保持かなと、SynthVを使っていて思いました。
音素の長さを％で持っておけば、ノートの長さが変わった場合でも、たぶん良い感じに編集データを適用できると思います。
でもUIが難しそう…
（SynthVはノートオフセットも変更することができて、「子音の長さを変えずに母音のタイミングを動かす」ということも可能で、編集しやすかったです）

音素の長さではなく音素のタイミングで保持する場合（ひとまず #2261 (comment) のBの形で考えています）は、母音のタイミングを基準にして保持すれば良い感じになるかも…？（以下の図のイメージ）

ノートのタイミングを縦線で示すと、それはそれで線だらけになりそうな気も少ししますね･･･！
でもやってみて問題なさそうなら問題なさそう！

線ではなくノートを模した矩形で示すのも良いかもです（色々試すのが良さそう）

[Hiroshiba]

複数音素（複数モーラ）の場合ですが、理想はSynthVのように音素の長さ（％）で保持かなと、SynthVを使っていて思いました。
音素の長さを％で持っておけば、ノートの長さが変わった場合でも、たぶん良い感じに編集データを適用できると思います。

はえーーーー
ノートの長さごとにデフォルトの子音の長さがあって、そこからどれぐらい伸び縮みするかみたいな値をパーセントで持ってる感じなんですね！！

音素の長さではなく音素のタイミングで保持する場合

おーーーわかりやすいです！！！

さっきのパーセントの考え方も適用できるかも？
ノートを伸縮させるとき、子音の長さの絶対値を転写するのではなく、元の子音の位置からの移動幅を伸縮して転写する感じにすれば･･･！

[sigprogramming]

さっきのパーセントの考え方も適用できるかも？
ノートを伸縮させるとき、子音の長さの絶対値を転写するのではなく、元の子音の位置からの移動幅を伸縮して転写する感じにすれば･･･！

ノート編集前とノート編集後の子音の位置が必要になる形だと、子音の位置は推論が必要なので、Undo/Redo周りで実装が大変になるかもです…！
編集後のノート位置、編集後のノートから推論された子音位置、音素タイミングの編集データの3つから各音素のタイミングが決まる形が（データの流れがシンプルになるので）良いかなと思います。
そして、ノート伸縮で編集データも伸縮させる場合、編集データをパーセントで持つことになると思います。

[Hiroshiba]

あ、たしかにです！
結果は同じだけど、音素タイミングの編集データを％で持っておくほうがずっとスマートですね！！！

[sigprogramming]

％で持つ形について考えてみたのですが、以下の課題がありそうでした。

• 子音は％で持って母音は絶対時間で持つ形になり、仕様・実装が複雑になる
• ノートの長さを変えると子音のタイミングが変わってしまう
  • 子音のタイミングが変わってもあんまり嬉しくないかも
  • 二重母音のときは（後ろの母音のタイミングが）％で変わってほしいかも

なので、一旦 #2261 (comment) のAかBの形で進めたいと思います…！

---

仕様・設計を考えてみました。
（ひとまずこの仕様・設計でstore周りを実装していこうと思います）

編集データの持ち方

type PhonemeTimingEdit = {
  phonemeIndex: number; // ノート内での音素の順番
  offset: number; // 単位は秒
  // TODO: 編集距離を計算できるようにphoneme: stringも持つ
};

type PhonemeTimingEditData = Map<NoteId, PhonemeTimingEdit[]>;

• 「ノートID」と「ノート内での音素の順番」の2つで、音素と編集データを紐づける
  • ノートを移動したときに音素タイミングが保持されるようにする
  • ノートの歌詞を編集したときに音素タイミングが保持されるようにする
• 推論された音素タイミングに対してオフセットの形で編集データを保持する（Aの形）
  • 実装が簡単なので

レンダリングの流れ

1. 以下をフレーズごとに行う
   1. 音素タイミング推論
2. 以下をトラック全体で行う
   1. 音素タイミング編集データを適用
   2. 音素が重ならないようにタイミングを調整
3. 以下をフレーズごとに行う
   1. ピッチ推論
   2. ボリューム推論
   3. 音声合成

音素タイミングを調整する処理の流れ

1. 各音素のフレーム長が1以上になるように後方から調整する（音素タイミングを変更）
   • 最後の音素は開始フレームではなく終了フレームの方を変更する
   • フレーズの最初の（pauseではない）音素の開始フレームがフレーズの開始フレーム+1以上になるようにする
     • フレーム長が1以上ではなくなるので、次の2.の調整で1以上にする
2. 各音素のフレーム長が1以上になるように前方から調整する（音素タイミングを変更）
3. フレーズ末尾のpauseのフレーム長が1以上になるように調整する（フレーズの終了フレームを変更）

[Hiroshiba]

UX的に%が良いか絶対的なオフセットが良いか、分かんないですね！！！！
ただ

子音は％で持って母音は絶対時間で持つ形になり、仕様・実装が複雑になる

これは間違いないと思うので、一旦オフセットで行く形に同感です！

AかBの形で進めたいと思います…！

Bの方だと「編集したかどうか」という状態を考える必要があるかもしれません。
「音素タイミングの編集をなかったことにする」操作も用意する必要が出てきたりと、結構ややこしいかも。
なのでAの方針でかなり賛成です！

---

仕様・設計も読んでみました！
問題は思いつかなかったです！！ 🙏

[sigprogramming]

@Hiroshiba
ありがとうございます！
実装中に問題に気づいたので、
#2261 (comment) の音素タイミングを調整する処理の流れを変更しました…！