voice versionという概念を導入する

[qryxip]

内容

VOICEVOXは学習更新や調整で、「同じスタイルでも音が変わる」ことがあります。そのため「古い音を利用したい」という需要が発生しうります(例1, 例2)。この需要に対応する機能として、ENGINEにはコアの差し換え及び複数コアの読み込みがありますが、これには後述する難点があります。そこで voice version という概念を導入し、過去版の固定や再現を簡単にできるようにする案です。

現在「声」の識別子は、例えばエディタ視点だとこうなっていると思います。

(EngineId, SpeakerUuid, StyleId)

ここに"voice version"という概念を導入し、

(EngineId, SpeakerUuid, StyleId, Optional VoiceVersion)

のようにします。具体的には、metasにおけるスタイルの下にvoice_versionというプロパティを追加します。またキャラクター下のversionはdeprecated扱いにします。

今のENGINEにある"core version"では駄目な理由

• 「コア」ではなくVVMで区別する方が利便性が高い。コアのバージョンにしておくメリットもユーザーには無いはず
• "core version"は現在「コアが出すmetasにおける、先頭のCharacterVersion」という意味になっている。これが不便であることは明らかとして、これを別の意味で置き換えることも混乱を招きうる

voice versionの具体的なデータ構造はまだ議論していません。個人的には、エディタレベルでユーザーにvoice versionの値を直接見せることも視野に入れた方がよいかなと思ってます。

• 連番による整数か？それとも"yyyy-mm"のような文字列か？それともUUIDか？
  • 先行配布のときは"n-beta.1"にしておく、という手もありそう
• OpenAPIの事情を一旦脇に置いておくと、実質的にオプショナルであるべきか？オプショナルの場合、 デフォルトではどういう扱いにするべきか？
  • VOICEVOX以外のエンジンのことを考えるとオプショナル一択
• ストリーミングでは「声は全く変わらない」といった感じだが、このときvoice versionは変化するべきか？

これまでの議論:

• （メモ）streaming生成用のtalk VVM voicevox_vvm#16 (comment)
• StyleVersionを作る voicevox_core#934

Pros 良くなる点

• 「古い声の復刻版」のVVMを提供できる
• それにより、エディタレベルでの声のバージョン切り替えの話が進みやすくなる

Cons 悪くなる点

実現方法

VOICEVOXのバージョン

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

その他

[Hiroshiba]

issue作成ありがとうございます！！
「voice versionがなぜ必要なのか」が抜けていたので書き足しておきました 🙏

個人的には導入の方針で良さそうに思います。
エンジンからはデフォルトで最新版を出力できるようにしたい気がするので、「どっちが新しいものか」を判別可能なversion名が良さそう。（UUIDが省かれる感じ）

年月にすると別の意味が生まれてしまいそうなので、やるならバージョンかな～と。

XかX.Yかで迷ってます！！
マイナーバージョンを導入して極端に声を変えるときだけX.YのXを変えるようにするか、メジャーバージョンだけにして毎回バージョンを更新するか･･･。
仮にサードパーティ開発者やVOICEVOXユーザーが「極端に声が変わらない更新時だけ自動アップデートしたい」みたいな要望がある場合はX.Yにすると良さそう。

うーーーーーーーーーーーーーん！！！！
極端に声が変わるときが来るのかも、そういう変更にこだわりを持つ開発者が現れるのかも不明ですが、とりあえず今のところX.Yかなーーーーーーー！！！！！！！！！
大きく音が変わる（はず）なときにX更新って感じで！！

[qryxip]

「voice versionがなぜ必要なのか」が抜けていたので書き足しておきました 🙏

これについて、私の方で更に書き加えておきました。diffが滅茶苦茶なことになっていますが…。
(やはりCRLF←→LFの問題？)
(追記: いやヒホさんがeditした後、私もテキストフィールド上でちゃんと編集した。となるとLinuxとかFirefoxのブラウザで書き込むと変なことになるとか？そんな馬鹿なとは思いますが)

[qryxip]

エンジンからはデフォルトで最新版を出力できるようにしたい気がするので、「どっちが新しいものか」を判別可能なversion名が良さそう

ですね。全順序を考えられるようにはした方がよさそう。ただマルチエンジンのこともあるし、エディタからは単純なstring | undefinedとして扱った方が身動きが取りやすいかなと思います。

X.Y

エディタで表示するとずんだもん（あまあま v2.0）みたいな感じになりそうですかね。特に問題なさそう…かな。SemVerで言うpre-releaseも考えてよさそう。

[qryxip]

オプショナル

これについては、既存のvvprojをどう扱うかというのも考えた方がよさそう。noneを"最新"と解釈するのか"不明"と解釈するのかによって扱いが変わってきそうな予感がします。

[追記] "不明"と解釈する場合、「各engineにおいてmetasはvoice_versionが全部完備しているか、全部noneになっているかのどちらかでなければならない」という制約を課したらマイグレーションはやりやすくなりそう…? でもユーザーにとってはわかりにくいような気も。

[Hiroshiba]

直感、エディタのことは考えなくて良さそうに思いました！

vvprojは容易に破壊的変更ができます。マイグレーションすれば良いだけなので。
あとエディタは「指定可能なバージョン一覧を表示できる」「今のバージョンが分かる」「バージョンを変えられる」ができれば良さそうで、APIさえあればなんとでもなりそうだな～と。

noneを"最新"と解釈するのか"不明"と解釈するのか

エディタにとっては最古のバージョンと解釈するので良いと思いました！仮に他に0.0があってもnoneの方が古い感じ。
今がnoneと同様と考えると、バージョンありのものが増えたらそっちのが新しいので。