マルチトラック：オーディオトラック機能

[sevenc-nanashi]

内容

声と同時にインスト音源などを流したいです。

Pros 良くなる点

同時に流したときの雰囲気がわかる

Cons 悪くなる点

実装がしんどい

実現方法

コメントに書きます

VOICEVOXのバージョン

0.20.0

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

（なし）

[sevenc-nanashi]

• 既存アプリ（1～3枚目）ではトラックのミニマップ的な画面からいじるのが主流

他ソフト

• 今のボイボにはトラック管理ミニマップ的なのがないのでこれは使えない
  • 実装すればオーディオトラックのデザインは楽になる

[sevenc-nanashi]

自分の考え：

• トラック一覧を歌唱トラック（仮称）、インストトラックに切り換えられるようにする
• 他ソフトの声も持ってきたい人もいると思うので可能ならインストは複数持たせたい

こんな感じ：

cc: @romot-co （デザイン周り詳しそうなので）

[Hiroshiba]

issue作成ありがとうございます！！！
ミニマップの例もすごく分かりやすいです。確かにミニマップが理想だよな～～～と感じました！！

音声トラック機能の追加はかなり望まれていると思います。
しかし一方でミニマップの実装はかなり遠い気もしています。

････波形の表示が一切ない、本当にトラックリストにトラックがあって音声ファイルを選べるだけのオーディオトラックとかって、使えないレベルで不便ですかね･････？
意外とこの簡単実装を先にやっちゃっても良い･･･かも･･･？

ちなみにUIだけでなく実装面でも課題があるかもしれません。
以前どなたか（ @sigprogramming さん？）にお伺いした記憶があるのですが、プレビュー音やレンダリングしたSequenceの音とインストの同期を取るのがだいぶ難しそうだみたいな話を聞きました。
理由は忘れたけどなんかずれる、みたいな感じだった記憶･･･（曖昧）

---

@sevenc-nanashi

インストトラックに切り換えられるようにする

こちらなるほどと思いました。
ソングとインストを分けて表示できると嬉しい理由ってあったりします･･･？
（とはいえ逆に混ざってたら嬉しい理由もあまり思いつかない。必要なUIの面積が小さいぐらい。）

[sevenc-nanashi]

････波形の表示が一切ない、本当にトラックリストにトラックがあって音声ファイルを選べるだけのオーディオトラックとかって、使えないレベルで不便ですかね･････？

うーん。例えばインスト音源の先頭に無音があったりすると何処から始まるのか判らないので、波形がないとキツイですね...（音を合わせるのに1拍ずつずらして再生して...みたいな感じになると思います）

ソングとインストを分けて表示できると嬉しい理由ってあったりします･･･？

今のデザインをあまり崩さない（=考える点を少なくできる）、ですね。
追記：あとtrackOrderとinstTrackOrderみたいにトラックの順序のstateを分割出来て若干実装するときに嬉しい気持ちがあります。

const state = { 
  selectedTrackId: (InstTrackId | SongTrackId),
  trackOrder: (InstTrackId | SongTrackId)[],
  songTracks: Map<SongTrackId, SongTrack>,
  instTracks: Map<SongTrackId, InstTrack>
}

みたいにするとsongTracksにInstTrackIdでgetしてバグらせる未来しか見えない...

[Hiroshiba]

例えばインスト音源の先頭に無音があったりすると何処から始まるのか判らないので、波形がないとキツイですね...

これ考えたのですが、波形の表示がないときついというより（聞けばわかるので）、拍子のタイミング合わせられないと不便（位置ずらしがないと不便）なのかなと感じました･･･。
波形を表示したUIが一切ないオーディオトラックは難しそうですね･･･。

今のデザインをあまり崩さない（=考える点を少なくできる）、ですね。

ソングとインストを同じトラックリストに表示し、かつトラックと同じ高さに表示する UIがある場合、確かに既存のデザインを崩さない（新しいコンポーネントを追加する）形になりそうですね！
ただミニマップがあればトラックリストを分割する必要がなくなるので･････難しいところですね･･･。

落としどころとして、トラックリストは混ぜて表示して、インストトラックをクリックした場合は波形用のコンポーネントが表示され、ソングトラックのところは空欄が表示される、とかどうでしょうか･･･？
何かの発想の足しになれば･･･。

追記：あとtrackOrderとinstTrackOrderみたいにトラックの順序のstateを分割出来るので若干実装するときに嬉しい気持ちがあります（まぁ面倒くさがるなという話ではあるけれど）

おっと、これちょっとわかってないです･･･！ 🙇
例えばTrack構造体にtypeを追加して、orderは: [TrackId]型にすれば特に問題なさそう･････？

[sevenc-nanashi]

そういえば音を合わせる例のスクショです：（3ノート目で最初のシンバルが入る曲、こんな感じにズレが確認出来る）

落としどころとして、トラックリストは混ぜて表示して、インストトラックをクリックした場合は波形用のコンポーネントが表示され、ソングトラックのところは空欄が表示される、とかどうでしょうか･･･？

波形表示の主な目的はソング側との同期なので、ソングとインストを同時に表示できないと波形で合わせるのが若干難しくなる...かも？（とは思ったけど意外とグリッドだけで十分かも知れない）

Track#type

色々なところでif (selectedTrack.type !== "sing") throw new Error("...")を書けば型上は問題はなくなるんですが、どこかで見落としが発生して、「これをやったらUIがフリーズした」みたいなコトになりかねないと思いました。

[Hiroshiba]

波形表示の主な目的はソング側との同期なので、ソングとインストを同時に表示できないと波形で合わせるのが若干難しくなる...かも？（とは思ったけど意外とグリッドだけで十分かも知れない）

ということはどうにかしてノートも同時に表示する感じ･･･？
グリッドだけで十分かもというのもたしかに。あるいは拍子のメモリがあれだけでも合わせられるかも。

色々なところでif (selectedTrack.type !== "sing") throw new Error("...")を書けば型上は問題はなくなるんですが、どこかで見落としが発生して

これは2つの型が全然違うので、意外とそうでもないと思ってます。
そもそもこんな感じの直和型？を考えていて、フィルタリングを忘れれば型エラーになる･･･はず･･･。

type Track = { type: "song", score: Score, styleId: StyleId} | {type: "inst", filepath: string}

あとId分けるとIdに関連してるChannelStrip等のMapも全部2つずつ作る必要が出てきてそれはそれで実装が大変かも。
ただまあ、致命傷ではないけど「インストだけミュートにする」機能があったときにフィルタし忘れる、とかはそこそこありえそう。

---

･･･トラックの開始タイミングさえ合わせられれば波形の表示はなくても最悪なんとかなる･･･気がするので、波形の表示は一切なくしてオーディオトラックに開始オフセット秒を持たせる･･･というのも一旦の苦肉の策としてありかも･･･？
（UI の実装がほとんどなくなるので実装難度がかなり下がる、という想定。）

[sigprogramming]

@Hiroshiba

以前どなたか（ @sigprogramming さん？）にお伺いした記憶があるのですが、プレビュー音やレンダリングしたSequenceの音とインストの同期を取るのがだいぶ難しそうだみたいな話を聞きました。
理由は忘れたけどなんかずれる、みたいな感じだった記憶･･･（曖昧）

インストがずれるのは、以下の画像のようにインストのスケジュールが間に合わなかった場合です。

（スケジューリングはメインスレッドで、実際の再生はWebAudioAPIのレンダリングスレッドで行われます）

現在は再生ボタンが押されたタイミングですぐに再生を開始するようになっているので（スケジューリングに余裕が無い）、Busyでなくても再生開始時に若干ずれが発生しています。

ずれを無くす方法としては、以下の3つがあると思います。

• 数百ミリ秒スケジューリングを行ってから再生を始めるようにする
  • DAWもバッファが十分に満たされてから再生を始めるようになっているはず
• スケジューリングが間に合っていない場合にwhenとoffsetを補正するようにする

  • const currentTime = audioContext.currentTime;
    if (currentTime > when) {
      offset += currentTime - when;
      when = currentTime;
    }
    audioBufferSourceNode.start(when, offset);

• AudioWorkletを使用してインスト再生用のAudioNodeを作る

[romot-co]

@sevenc-nanashi @Hiroshiba
こちらありがとうございます
どちらのご意見もわかるな…という感じです！

(ななしさんの画像、わかりやすい)

---

前提と主目的

なにをオーディオトラックに求めるかによって変わってきそうですが

• 伴奏と他の歌声の合成のみ
• 位置合わせをしたい
• DAWみたいな音声ファイルの切った貼ったなどはしない

という前提として：

• ノートを基準にした位置あわせ: オーディオの位置を調整する
• オーディオを基準にした位置合わせ: ノートの位置(発音タイミング)を微調整する

の2つが必要そうに思えます。

---

まずトラックリストについて:

1. 混在させる
2. 歌声とオーディオトラックで分割する

の2種類がありそうですが

• 切り替え式ではないほうが望ましそう

タブやスイッチなどで分離する意味はあまりなさそうに思えています
分割するにしても歌声の下に線を引いてその下はオーディオにする程度で、同一リスト上に表示してしまっていいんじゃないかと…！

---

波形表示について

• オーディオと歌声の両方で: 可能であればあったほうがよい
• 波形はなくとも: ノートに対しオーディオ範囲がわかる箱(クリップやリージョンと呼べばよさそう？)があり位置を調整できる必要がある

かと思います！

---

位置合わせにおいて

• 波形の有無は別として: ノート位置とオーディオの箱を同時に表示・操作できる必要がある
• オーディオ単体でいえば箱とオフセット指定があれば最低限いける？
• (今後？)ノートについても微調整機能が必要

ように思えます！

---

文字だけではわかりづらいので
この形でこちらでも叩き台を考えて議論してみられればと…！

[sevenc-nanashi]

タブやスイッチなどで分離する意味はあまりなさそうに思えています

元のUIを考えた時の記憶ですが：

• 前提：波形表示とトラックのUI上のY座標は完全に一致しているソフトが多い（少なくとも自分の知ってる全てのDAWはそう）
• しかしそれをボイボの今のUIに入れると（ミニマップを作らない限りは）Y座標=音階（歌唱トラック）とY座標=トラック順（インストトラック）が混在してしまう
  • やばい
  • SynthVみたいなミニマップを作れば歌唱トラックをY座標=トラック順にできるので問題ない
    • これはこれでミニマップを作らないとなのでしんどい
• ので、Y座標の意味を変えるスイッチを導入したい
• トラックの種類を切り替える操作に落とし込んだ

って感じです。

(今後？)ノートについても微調整機能が必要

ShiftやAltを押すとグリッド無視するのをよく見る気がします。

[romot-co]

@sevenc-nanashi

ので、Y座標の意味を変えるスイッチを導入したい
トラックの種類を切り替える操作に落とし込んだ

これはすごい納得です。
トラックリストで選択すれば切り替わればよさそう＝ドロップダウンなどにしてコンテキスト分ける(スイッチングコストかける)まではいらないかな…？ぐらいの感じで！

同時表示しないと位置合わせ自体が難しそうなのもあり
(どのようなものにするかはともかく)ミニマップ的なものはVOICEVOX単体でやる前提ならたぶん必要そう…

[Hiroshiba]

UIに関して

満たしたい条件が出揃ってきたなという雰囲気ですね！！

@romot-co さんのおっしゃる通り、オーディオもノートも位置調整するにはお互いが表示されていたほうが良く、
@sevenc-nanashi さんのトラック一覧をソング・オーディオで表示切替する案だと、この同時表示が満たされない点が惜しいところですね。

逆にトラックを混ぜて、ソング・オーディオそれぞれについて右側にノート列or波形を表示してあげる「ミニマップ表示モード」みたいなのを作ってあげれば条件は満たせるかもしれない。
でもなんか･･････これが最適解なのかぁ･･･？という気持ち。

同じこと繰り返しちゃうけど、オーディオの波形のUIは難しいので、まずはオーディオトラックだけ実装が無難かもしれない。

@sigprogramming さんのイベントのスケジューリングのずれに関して

詳しくありがとうございます！！！
ぶっちゃけ完璧にはまだわかってないです。。。 🙇

ちなみに解決策3つのうち、一番遅延が小さいはずなのは3番目のAudioWorkletを使用してインスト再生用のAudioNodeを作るでしょうか･･･？

[sigprogramming]

@Hiroshiba
一番遅延が小さいのは3番目ですが、信号処理部分を一から実装する必要があり大変かもしれないので、ひとまず2番目を実装して、再生開始時のずれが大きい場合は追加で1番目を実装するのが良いと思います。

[Hiroshiba]

なるほどです！！
1の方法（数100ms待つ）はおそらくかなりラグく感じる気もするので難しい判断になるかもですね…。
「機敏なユーザー体験」を実現するUIに求められる応答時間

一旦2が良いというのはなるほどです、賛成です！