（メモ）streaming生成用のtalk VVM

[Hiroshiba]

内容

project-streaming-talkというブランチにstreaming API用のVVMモデルを配置しています。
コア0.16.0なら読み込めるはずです。

とりあえずメモ用のissueです。

その他

仮にリリースしたらバージョンは0.2.0になると思います。

でもvvm内のmetas.jsonに書くバージョンは0.16.0辺りにしようと考えています 😇
このissueで書いてることと反します。

これはつい先日問題に気付いたためです。
前のコアのmetas.jsonに書いてる値は0.15.7（コアバージョンと同じ）が書いてます。
エンジンは２つコアがあった場合、latest側を初期値として読み込みます。
先日リリースしたvvmはmetas.jsonに0.1.0と書いてたので、同時に読み込むとこちらのバージョンがlatestじゃなくなってしまいます 😇

ということでとりあえず0.15.7より高い値にしようかなということで、今のproject-streaming-talkにあるvvmは0.16.0にしています。
本当にとりあえず0.16.0にしているだけなので、今後どうすべきかなど含め未検討です。
（今vvm内metas.jsonが0.1.0になってるのは、0.15.7にすべきかもしれない。全く一緒なはずなので。）

関連

• [0.16] streaming API系を一旦表に出ないようにする voicevox_core#970
• ストリーミング音声合成 voicevox_engine#1492
• ストリーミング処理の対応 voicevox_core#853

[qryxip]

「コアのバージョン」の識別ってこうなんですね。
https://github.com/VOICEVOX/voicevox_engine/blob/9c5e55fb49a7c928ec6ac08cd9c546df2e7377a0/voicevox_engine/core/core_initializer.py#L138-L139

ストリーミングVVMを0.16.0にするのは賛成です。

0.15.7にすべきかもしれない。全く一緒なはずなので。

一緒といってもそれを動かすコアとONNX Runtimeが違う（ONNX Runtime v1.13 → v1.17）という点はありそう。

今思い付いたジャストアイデアなのですが、コアのcompatible_engineから出るmetas()ではCharacterVersionを「コアのバージョン」で上書きする、という手もありそう…？いやCharacterVersionに二つの意味が生まれてカオスになりそうではありますが。

[qryxip]

VVM内のCharacterVersionにおいてデシリアライズ時にはオプショナルというふうにすれば、vvm_format_versionは1のままでよいはず？

[qryxip]

あ、駄目か。でもCORE側として1と2を両方サポートし続ければ、COREはv0.16のままでいられそう。

[Hiroshiba]

「コアのバージョン」の識別ってこうなんですね。

あっ！　そうか、エンジンはcore_versionになってるのか〜。
metas.jsonに書いてるバージョンは声のバージョンにしたくていろいろ考えてたんですが、そうかエンジンのAPIで露出している名前はcore_versionか･･･。

何にせよ、たしかにmetas.json内のバージョンは0.16.0で良さそう感。

0.15.7にすべきかもしれない。全く一緒なはずなので。

一緒といってもそれを動かすコアとONNX Runtimeが違う（ONNX Runtime v1.13 → v1.17）という点はありそう。

metas.json内のバージョンの方はなんとな〜〜〜く「バージョンが違ったら音が違う、バージョンが同じなら音が同じ」が良いかな〜と思ってるんですよねー
もしこの方針で行くとしたら、onnxruntimeのバージョン違いとか、なんならstream用のonnxなのかどうかとか関係なく同じバージョンのが良いよなぁと。

---

整理すると･･･

• たぶんENGINE APIのcore_versionはどっちかというとvoice_versionみたいのが良さそう
  • 音声のバージョンのこと。途中で音声が変わったスタイルも過去いくつかある
• core_versionとして、コアのバージョンを返し続ける意味はあまりなさそう
  • ユーザーニーズが有るのは声のバージョン
• とりあえず今まで通りmetas.jsonに書いて、返す運用を続けても良さそう
  • ただ実体はコアのバージョンから乖離していく
• あまりどうすべきかちゃんと定まってない･･･。
  • ENGINE APIのcore_versionをvoice_versionとかに改名する、あるいは名前そのままに意味を変更する･･･？
  • とりあえずぶっちゃけ過去の声を選べる需要が来る未来は知覚なさそうなので、一旦そのままでも良さそう 😇

[qryxip]

何にせよ、たしかにmetas.json内のバージョンは0.16.0で良さそう感。

ですね。

あっ！　そうか、エンジンはcore_versionになってるのか〜。 metas.jsonに書いてるバージョンは声のバージョンにしたくていろいろ考えてたんですが、そうかエンジンのAPIで露出している名前はcore_versionか･･･。

一応ですが、ENGINEが喋るspeakers/singersもCharacter.versionのままのはず。内部でのコアの区別およびユーザーから与えられるcore_versionへの返答がCharacter.versionベースになってしまうという感じですね。なのでどうにかする方法は一応ありそう。

1. compatible_engineから出るmetas()を加工する。VVM内のmetas.jsonはENGINEに囚われずに自由に
   • 「metasのversion」に二つの意味があるということになってしまいそう？
2. ENGINEからvoicevox_get_version()を叩き、ちゃんとした「コアのバージョン」を認識するようにする。OldCoreError時には旧来の認識方法
   • CORE C APIとcompatible_engineは綺麗に分かれてた方がよい気もするので、const char *versionとかを増設する？
   • 懸念として、挙動の破壊的変更にならないかというのがありそう。「コア」と「モデル」が不可分なものだとされているならセーフ、そうでなければアウト？

ENGINE APIのcore_versionをvoice_versionとかに改名する、あるいは名前そのままに意味を変更する･･･？

Character.versionもWeb APIのパラメータのcore_versionもそのままで、SpeakerStyle.voice_versionを増設するというのもありな気がしています。libtorch時代のずんだもんめたんを1とするような感じで。

---

なんかENGINEの話になってきたので。
CC: @nanae772, @tarepan

[Hiroshiba]

ああ、ここであまりエンジンの話をしないほうが良いですね
議論が散らかってしまった。

あくまでvvm内のmetas.json内のversionには何を書くか、だと思います。
んで結論は0.16.0！

（散らかってしまった他の方の整理）

エンジンどうするか
→ API引数のcore_versionの代わりにvoice_versionがあると良いかもだけど、そこまでの需要はないと思うのでどうもしない。（core_versionのままで良い）
→ エンジン側に「どうするか」「どうもしない」と自問自答したissue建てて即クローズしても良いかも（議題が散らかったので整理する意図）

コアどうするか
→ metas.json内のstyleごとにversionを生やしても良さそう
→ たぶんなくても問題ない、speakerごとのversionでなんとかはなる
→ 同じくissue建てて整理しても良いかも、こっちはopenのままでも良さそう

[qryxip]

Character.versionを0.16.0にするのには異論は無いです。なのでこのメモ用issueはcloseですかね？

→ エンジン側に「どうするか」「どうもしない」と自問自答したissue建てて即クローズしても良いかも（議題が散らかったので整理する意図）

もし仮に本気でやるのなら VOICEVOX/voicevox_project#21 も巻き込んだ話になりそうなので、voicevox_project側ですかね？

コアどうするか

→ metas.json内のstyleごとにversionを生やしても良さそう
→ たぶんなくても問題ない、speakerごとのversionでなんとかはなる

ENGINEから使われる関係上「声のバージョン」というよりはどちらかというと「コアのバージョン」として振る舞わないといけなさそうではありますが、まあ確かに十分そうではありますね。過去の声を使いたいという需要次第でしょうか？

→ 同じくissue建てて整理しても良いかも、こっちはopenのままでも良さそう

issue建てたところで、ユーザーからの需要が無い限り実装には進まない気がします。未来の私達がorg:VOICEVOX "voice_version"とかで検索すれば今話しているここに辿り着けそうというのもありますし、ぶっちゃまだissueも建てなくていいんじゃないかなーと思ってます。

[Hiroshiba]

たしかにissueは建てなくても良いかも。

未来の私達がorg:VOICEVOX "voice_version"とかで検索すれば今話しているここに辿り着けそうというのもありますし

まあvoice_versionというのを思いつけなくてひたすら探すことになるんですよねー
･･･もしかしてこのシンボル覚え続けられたりしますか？
だとしたら僕は抽象度高く物を覚える傾向にあるから場所で探す傾向にあるだけなのかも。
あるいは覚えないといけない量が多くてキャパオーバーになりやすいから整理したい、という話かも。

---

あとこちらも関係ある話かもなのでメモ！（リンクだけメモ）

• 複数コアを利用可能にする voicevox_project#3

[qryxip]

･･･もしかしてこのシンボル覚え続けられたりしますか？

一応いくつか考えていて、"Character.version"とか"voicevox_get_version"とかでも内容的に絞れそうかなーと。あとは"libtorch時代"とか。

[Hiroshiba]

なるほどです！！
ちょっとそういうシンボルは量が無限に増えていくので、シンボルを思いつかなくても後で取り出せるよう整理しておきたいって感じかなーと。
（僕はVOICEVOX全体で把握していかなくちゃいけないというのもあり、難しさを肌で感じているというのもありそう。）

[Hiroshiba]

まあでも気軽にorg全体で検索するのはとても良さそう。それでしばらく過ごしてみようかな

･･･と思ったけどこれ新規コントリビューターの方にはかなり酷ですね。。。
やっぱ関連情報は然るべき場所に整理していくほうが良さそう！

[qryxip]

まあ確かに。

issueにまとめなおすとしたらvoicevox_coreとvoicevox_projectのどっちがいいですかね？

→ エンジン側に「どうするか」「どうもしない」と自問自答したissue建てて即クローズしても良いかも（議題が散らかったので整理する意図）

というところまで含めるのならリポジトリ横断ということでvoicevox_projectの方がよさそうかなーと。