Open y-chan opened 1 year ago
issue作成ありがとうございます!! 頑張っていきたいですね!!
インポートとインストールは意味合いが似てるので混乱しそうですね! たぶんインストールが「エンジンが返すダウンロードリストに載っている音声ライブラリを突っ込むこと」、インポートが「載っていないものを突っ込むこと」なのかなと思いました。 であればこの差分を仮の名称にしてしまうのが良いのかなと思いました!
「ユーザーモデルのサポート」とか・・・?
あと今のところ @sevenc-nanashi さんがPRを出してくださっていますが、そこにコメントをして機能を追加していくよりも、ちょっとずつ機能を区切ってPR・マージを高速に行うのが良いのかなと思いました! そのPRはどこまで実装すべきかを意識して進めていきたいですね!
インポートとインストールは意味合いが似てるので混乱しそう
確かに、ちょっと意味合いが似ているかもですね... サポートするのはユーザーモデルとも限らないので、「リストからインストール」と「ファイルからインストール」とかどうかなとか思いました。
今の状況であれば、特定の人にタスクが偏ってしまいそうなので、これを分散させたいのは同意です。 目標をもう少しタスクレベルまで落とし込みたいなと思いました...!
サポートするのはユーザーモデルとも限らないので、「リストからインストール」と「ファイルからインストール」とかどうかなとか思いました。
なるほどです。 そもそも最初からvvlibを実装する形にすれば、ダウンロードはただvvlib一覧を返すだけになって二度手間もなくなって概念もわかりやすくなるかも・・・?
最初からvvlibを実装する
良いと思います! インストールAPI自体がvvlibを展開するだけの機構になっていれば、流れがある程度共通化・統合できるので、分かりやすくなる上、管理のしやすさも上がると思いました...!
後でちょっとフローを図に起こしてみたいと思います:eyes:
良いと思います! 段取りなどおまかせします・・・!(判断困ったらいつでも頼っていただければ!)
こちらそろそろ動かしていけるかも? ガシガシ設計プロトタイプ&切り分けって感じでしょうか
すみません...! 最近忙しくて返答が遅くなりました...
とりあえずは設計かなと思っています! フロー図を用意したいのでもう少しだけ時間がかかりそうです...!
前回の返信からまた時間が空いてしまいました、申し訳ないです.... フローは以下のような感じで行こうかなと思います。(mermaidをうまく使いこなせてなくて、きれいではないですが...)
flowchart TB;
subgraph ネットワーク;
server;
end;
subgraph ディスク;
library_folder[ライブラリフォルダ];
end;
subgraph エディタ;
file_select[エディタ上でのvvlibファイル選択];
download[エディタ上でのvvlibダウンロード];
library_select[エディタ上でのインストール済みライブラリ選択];
end;
subgraph エンジン;
dl(downloadable_libraries);
il(install_library);
il2(installed_libraries);
uil(uninstall_library);
end;
dl-->download;
file_select-->il;
download-->il;
il2-->library_select;
library_select-->uil;
server-->dl;
server-->download;
il-->library_folder;
library_folder-->il2;
uil-->library_folder;
installed_libraries
に、アンインストールできるかの情報を含めたいかなと思いました。vvlib
になりそうなので、vvlib
の仕様を決めたいです。
library_manifest.json
に内包する方式にし、中のデータ処理は各エンジンにおまかせする方式で、十分に自由度を設定するのがいいかなと思いました。最低限欲しい情報は以下だと考えています。他に何か案があれば...!name
: 音声ライブラリの名前version
: 音声ライブラリのバージョンuuid
: 音声ライブラリのUUIDengine_name
: エンジンの名前engine_uuid
: エンジンのUUIDvvlib
の中身のうち、それらのデータを返す処理が必要そうかなと思いました。ただし、その場合vvlib
をエンジンに対して2回(データ抽出とインストール)投げることになるので、それを避けるいい方法を考えたいかも...?ついでに、インストール時のユーザーフローも作成してみました。
flowchart TD;
start[ライブラリ管理画面を開く];
select_file[vvlibファイルを選ぶ];
select_from_list[ダウンロード可能なライブラリを選ぶ];
details_library(ライブラリ内の立ち絵や音声サンプル提示);
view_tos(ライブラリ利用規約提示);
install[インストール];
start-->select_file;
start-->select_from_list;
select_file-->details_library;
select_from_list-->details_library;
details_library -->|次へ|view_tos;
view_tos-->install;
@y-chan 眺めてみました!!
フローは以下のような感じ
アプデフローも一応あると良いかもと思いました! あとフロー図と同じ用に実装・設計していくと良さそう?
installed_librariesに、アンインストールできるかの情報を含めたい
賛成です! このこと忘れちゃいそうですね。。
vvlibの仕様
ここの決めが次の工程って感じしますね!
rootでbrand_name
はあると表示に便利そうです!
あとengine_manifestの経験から、manifest_version
もあると便利かなーと。
あー あとvvlibからインストールするとなると、エンジンが持っている話者情報は全部必要かもです。。 サンプル音声・スタイル名称・スタイルID・立ち絵・アイコンなどなど。 ここにある情報を全部まとめる感じになりそう? https://github.com/VOICEVOX/voicevox_engine/blob/eee7f4a771c9e181ce58dd38a7ebe9e1ccb596dd/voicevox_engine/metas/Metas.py#L65
その場合vvlibをエンジンに対して2回(データ抽出とインストール)投げる
たしかに。パスを渡す感じでしたっけ、バイナリを渡す感じでしたっけ。 パス渡す感じなら、データ抽出用のAPI用意すれば全バイナリ読み出さなくても行けるので割とレスポンス素早いかも。
まあ、なんかvvlibだいぶ大変そうに思えてきました。。。 ジャストアイデアですが、vvlibやめて、自由なdownloadable_librariesのURLをエンジンに渡せるようにするとか・・・?
利用規約の提示
賛成です!
いろいろ決めるべきことが決まってないことに今気づきました...遅くなってすみません...
あまりにも分かりづらい全体図ができたのでとりあえず隠しておきます...
アプデフロー
エディタ上でインストール済みのものとバージョンと比較してインストール可能か判断する方式が良いかなと思いました。
flowchart TB;
subgraph ネットワーク;
server;
end;
subgraph エディタ;
download_select[エディタ上でのダウンロードするvvlibの選択];
confirm_download[エディタ上でのサンプルボイスや立ち絵と利用規約の確認];
download[エディタ上でのvvlibダウンロード];
end
subgraph エンジン;
dl(downloadable_libraries);
il(install_library);
il2(installed_libraries);
vl(validate_library);
end;
subgraph ディスク;
library_folder[ライブラリフォルダ];
end;
dl-->download_select;
server-->dl;
il-->library_folder;
library_folder-->il2;
download_select-->confirm_download;
vl-->il;
dl-->confirm_download;
confirm_download-->download;
download-->vl;
download-->il;
server-->download;
il2-->|downloadable_librariesと照らし合わせてアップデート可能か確認|download_select;
brand_name
manifest_version
良さそうです! 今の所こんな感じでしょうか。
name
: 音声ライブラリの名前version
: 音声ライブラリのバージョンuuid
: 音声ライブラリのUUIDbrand_name
: エンジンブランド (VOICEVOXなど)engine_name
: エンジンの名前 (VOICEVOX Engineなど)engine_uuid
: エンジンのUUIDmanifest_version
: マニフェストバージョンvvlibからインストールするとなると、エンジンが持っている話者情報は全部必要かも データ抽出用のAPI用意すれば
vvlibファイル周りが若干ネックなのは変わりないのですが、validate_library
API(仮名)をエンジン側に生やし、そこを通すと話者関連情報が得られるようにすれば良いかなと思いました。ここまでは今までの提案どおりなのですが、新たにvalidate_library
を通さないとライブラリがインストール出来ないようにするのはどうかなと思いました。これは、validate_library
の時点でエンジン側で音声ライブラリをキャッシュしておき、install_library
時はファイルを渡すわけではなく、library_uuid
などを使ってvalidate_library
時にキャッシュした情報からインストールするようにすれば、データの流れがある程度まとまって、処理の回数も減らせるのはないかなと思いました(全体図には少し反映しています)。
代わりに、インストールキャンセル時のためにdestroy_library
API(仮名)とかもはやしてあげる必要があるのが若干ネックかもです。
validate以外のことをするという点で、名前は変えたほうがいいとは思いますが、いい名前が思い浮かばず...
@y-chan
全体図
まとめてくださったの助かります、ありがとうございます!!
エディタ上でのサンプルボイスや立ち絵と利用規約の確認
が2回あるの、ちょっと不自然だけど仕方ない感じですねぇ。
ここはエディタも絡むので @sevenc-nanashi さんの意見も聞いてみたいかもです。
vvlibファイル周りが若干ネックなのは変わりないのですが、validate_library API(仮名)をエンジン側に生やし、そこを通すと話者関連情報が(略)
validateでデータが降ってくるというのはかなり挙動として謎ですが、ありかもと思いました。 キャッシュに関してですがそもそもzipなどからデータを取得するのは高速なので、ファイルパス指定であればキャッシュ不要にできそうに思いました。web APIとして変なのですが、まあ需要を考えるとこれでも良いかなという気持ちです・・・。 あるいは「仮登録(元validate)」で何かしらのIDを返し、その後ID指定して「インストール」・・・?
あとvvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃますね。VOICEVOXみたく全モデル把握してる場合は良いけど、ユーザーモデルの場合は不都合かも。(VOICEVOXの場合もNemoみたいなのは別途インストール可能にしたいかも) 大変な作業なので、優先度どうすべきなのか僕の中でまとまってないです。。
brand_nameとか
持たせたい値、良さそうに思いました! あと、エンジンのengine_manifest.json側に、対応しているライブラリのmanifest_versionをもたせたほうが良いかもとか思いました(supported_library_manifest_versionとか?)
エディタ上でのサンプルボイスや立ち絵と利用規約の確認
が2回ある
これは、グラフ上でエディタ上でのvvlibファイルの選択
からのものとエディタ上でのダウンロードするvvlibの選択
からのもので、データフローが違うために分けているのと、グラフ上の同じノードを使うと処理が分かりにくくなるから分けただけで、多分実際には同じ処理を使うことになり、それぞれの工程で1回だけになると思います...!
ファイルパス指定であればキャッシュ不要にできそう web APIとして変
私も、Web APIとしては変かなと思ったので、キャッシュ方式を考えていました。 ファイルパス方式だと、ディレクトリトラバーサルなどの、パス関連の問題が起きないかが少し気になるところですが、PCの外にAPIを公開しなければ問題にならないはずなので、一旦その方式でもいいかなと思いました。
vvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃう
うーん、これは特に問題ないのではと思っています。
今のところ、COEIROINKのユーザーモデル機能では、zipファイルにモデルやmetas.json
と合わせて、話者関連情報なども含めて配布する形になっているので、話者関連情報をセットで配布することをを必須にするのは特に大きく問題となる気はしない気がしています(エンジンには、モデルの配置と話者関連情報の両方を配置してもらうように設計してもらえばいいと思っているのですが、それ以外に私が把握できていない問題がありそうですかね...?)。
エンジンのengine_manifest.json側に、対応しているライブラリのmanifest_versionをもたせたほうが良い
これは確かにそうですね!エンジンが未対応のライブラリはインストールできないようにしないと、未対応の仕様に対応できずに変な動作が起きる可能性があると思うので、追加する必要はありそうだと思いました!
ファイルパス方式だと、ディレクトリトラバーサルなどの、パス関連の問題が起きないかが少し気になるところですが、PCの外にAPIを公開しなければ問題にならないはずなので、一旦その方式でもいいかなと思いました。
まあそうですよね・・・。 実際バイナリ投げるのを作ってみて、遅そうだったりキャッシュ方式が作れなかったりしたら再考するとか・・・?
vvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃう
うーん、これは特に問題ないのではと思っています。 話者関連情報をセットで配布することをを必須にするのは特に大きく問題となる気はしない気がしています
あれ、ちょっとわかってないので認識合わせしたいです。 OSS上のvvlibはスタイル番号やアイコンなどは含まず、各々のエンジンの独自仕様としてアイコンなどを追加してもらう、という理解で合っていますか・・・? 👀
VOICEVOXエディタはそもそも話者情報(SpeakerInfo)が必須なので、それをvvlib内かエンジン内に含める必要があるはず。 vvlibに話者関連情報を持たせない場合、エンジンがどこかからか話者関連情報を取得する必要があるのですが、そこどうしようかな~と。
実際バイナリ投げるのを作ってみて、遅そうだったりキャッシュ方式が作れなかったりしたら再考するとか・・・?
まあPoCを作ってみてどういうふうになるか見てみるのはわりとありだと思います! バイナリを投げる方式は一度SHAREVOXで作ったことがあって、動きそうではあったので、キャッシュ方式の検証APIを考えてもいいかも。
OSS上のvvlibはスタイル番号やアイコンなどは含まず、各々のエンジンの独自仕様としてアイコンなどを追加してもらう、という理解で合っていますか・・・? 👀
うーん、たしかにちょっと認識の齟齬がありそうです。
まず前提に、私自身はvvlibの仕様として話者関連情報は必ず含めなければならない仕様になっているべきではあると思っています。
ただ、それをlibrary_manifest.json
として同梱するかはちょっと検討した方がいいという意見でした。
多分、https://github.com/VOICEVOX/voicevox_project/issues/21#issuecomment-1485103760 の意見を見たときに、「話者関連情報もlibrary_manifest.json
として導入した方がいい」という意見として取ってしまったのが認識の齟齬の原因です...
なので、vvlib内にspeaker_info
フォルダを作り、そこにエンジンと同構造の話者関連情報を必ず導入するようにするといった仕様を決めちゃっていいかなと思います。
それであれば決まったフォルダを探索すれば話者関連情報を得られるので、以前例に上げたvalidate
APIにvvlibを投げて話者関連情報を得ると言ったことをしなくとも、エディタ側でも処理可能になると思います。
簡易的なバリデーション(話者関連情報の取得と、library_manifest.json
の検証)をエディタ側で行い、インストール時にエンジン側でしっかりとしてバリデーションを行えばフローも簡単化されていいかなと思いました。
あと、思ったのですがlibrary_manifest.json
じゃなくてvvlib_manifest.json
のほうがいいのかもしれない...?(engine_manifest.json
になぞらえるならlibrary_manifest.json
だと思いますが、VOICEVOXにおいてlibrary
は動的ライブラリ: core
の用語ではあると思うので)
あ、なるほどです!
library_manifest.json
に全部書くのはたしかに大変かもです。
まあファイル構造だけ定義した場合、vvlibを読む側はOS違いに対応したり、いろんな音声ファイル・画像ファイルの拡張子に対応したり、将来互換性確認のためにファイル存在を調べたりしないといけなくなるので、jsonにしといたほうが全体で見ると楽かも・・・?
うーん! でもエンジン側と共通化できるのは大きいし、ファイル構造定める方針で良い気がしました! 将来ファイル構造変えねばってなったときに再検討しますか。
エディタ側であるvvlibから情報得るの、良い気がしました! エディタ側の検証は、表示に必要な情報があるかのチェックくらいにしとくと楽そう。
library_manifest.jsonじゃなくてvvlib_manifest.json
どちらでも良いかなと思いました! どちらかというとvvlib_manifestが良さそうかなと。
エンジン側と共通化できるのは大きいし、ファイル構造定める方針で良い気がしました! 将来ファイル構造変えねばってなったときに再検討しますか。
今までファイル構造が変わったことは、スタイルごとに立ち絵が変更できる点ぐらいだったので、あまり神経質にならなくてもいいかなと思っています...!
表示に必要な情報があるかのチェックくらいにしとくと楽そう
そうですね、存在確認と、ファイル形式が問題ないかを検証するだけで、エディタ側で情報の表示が出来ると思うので、これでいいかなと思いました!
どちらかというとvvlib_manifestが良さそうかなと。
vvlib_manifest
で行こうと思います....!
全体像がある程度まとまったと思うので、検証APIをなくした全体図を再掲しておきます。
flowchart TB;
subgraph ネットワーク;
server;
end;
subgraph ディスク;
library_folder[ライブラリフォルダ];
end;
subgraph エディタ;
file_select[エディタ上でのvvlibファイルの選択];
extract_data[vvlibファイルの検証];
download_select[エディタ上でのダウンロードするvvlibの選択];
confirm_install[エディタ上でのサンプルボイスや立ち絵と利用規約の確認];
library_select[エディタ上でのインストール済みライブラリ選択];
download[エディタ上でのvvlibダウンロード];
end;
subgraph エンジン;
dl(downloadable_libraries);
il(install_library);
il2(installed_libraries);
uil(uninstall_library);
end;
dl-->download_select;
il2-->library_select;
library_select-->uil;
server-->dl;
il-->library_folder;
library_folder-->il2;
uil-->library_folder;
download_select-->confirm_install;
confirm_install-->|ダウンロードしてインストールの場合|download;
download-->il;
confirm_install-->|ファイルからインストールの場合|il;
server-->download;
file_select-->extract_data;
extract_data-->confirm_install;
il2-->|downloadable_librariesと照らし合わせてアップデート可能か確認|download_select;
この方向で不足しているAPIから実装していこうと思います...!
また、vvlib
の最低限仕様は以下のようにしたいと思います
xxx.vvlib # root
├─ vvlib_manifest.json
│ - name: 音声ライブラリの名前
│ - version: 音声ライブラリのバージョン
│ - uuid: 音声ライブラリのUUID
│ - brand_name: エンジンブランド (VOICEVOXなど)
│ - engine_name: エンジンの名前 (VOICEVOX Engineなど)
│ - engine_uuid: エンジンのUUID
│ - manifest_version: マニフェストバージョン
└─ speaker_info
├─ <uuid>
│ ├─ icons
│ │ └─ <x>.png
│ ├─ portraits # Optional
│ │ └─ <x>.png
│ ├─ voice_samples
│ │ ├─ <x>_001.wav
│ │ ├─ <x>_002.wav
│ │ └─ <x>_003.wav
│ ├─ metas.json
│ ├─ policy.md
│ └─ portrait.png
└─ ...
良いと思います!!
音声ライブラリのアプデの議論ってしてましたっけ。installと全く同じ経路にして、uuidが既存だったら上書きが良いのかなと思いました!
音声ライブラリのアプデの議論ってしてましたっけ。installと全く同じ経路にして、uuidが既存だったら上書きが良いのかなと思いました!
これで良いと思います!
メモです。 release-0.15で、エディタからのvvlib機能への対応情報表示をフィルタリングするようにしました。(まだ必ず非対応なため) vvlib機能が正式サポートされたら忘れずに解除できればと!
@y-chan
0.15のときにengine_manifestのsupported_vvlib_manifest_version
を消した(nullにした)のですが、これは引き続き消したままにしようと思います。
というのもまだ仕様が固まってなくて、どのバージョンが一番最初のバージョンになるかわからないので・・・。
manage_library
の方はtrueにするので開発には支障がないと思っていますが、最終的にリリースする時に入れ忘れないよう注意が必要かもです。
(まあ入れ忘れたとしても、一番最初に破壊的変更があった時に書けば問題ないと思います)
VOICEVOX ENGINE での議論場所: https://github.com/VOICEVOX/voicevox_engine/issues/536
経緯・目的
目標
supported_features
に音声ライブラリ管理機能について追加する voicevox/voicevox_engine#616vvlib
を投げる仕様にする、インストール機能の実装が前提音声ライブラリの検証API(インストールしようとしている音声ライブラリは正しい形式であるかなどの検証処理)vvlib
)の設計を決めるvvlib_manifest.json
の仕様策定vvpp
のように、engine_manifest.json
みたいなものが欲しい(インストール先のエンジンブランドの指定や、ライブラリのバージョン値などを埋め込んでおくため)library_manifest.json
のところに書いた通り、構造はすべて製作者のお任せにして、library_manifest.json
に必要なファイルの情報をすべて書き込んでもらうのもいいかもlibrary_manifest.json
が必ず存在することぐらいにしておいて)、各エンジンに処理をお任せしてしまう方針でもいいかもvvlib_manifest.json
とディレクトリ構造: https://github.com/VOICEVOX/voicevox_project/issues/21#issuecomment-1566022546