Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

音声ライブラリを管理する機能をサポートする #21

Open
13 of 21 tasks
y-chan opened this issue Feb 19, 2023 · 22 comments
Open
13 of 21 tasks

音声ライブラリを管理する機能をサポートする #21

y-chan opened this issue Feb 19, 2023 · 22 comments
Labels
優先度:中 機能向上 要議論 実行する前に議論が必要そうなもの

Comments

@y-chan
Copy link
Member

y-chan commented Feb 19, 2023

経緯・目的

  • VOICEVOX 0.14.0 で エンジンのプラグイン化(複数のエンジンを同時に見れるようにする) #2 にて提案されていた構想がついにデプロイされ、VOICEVOX系エンジンのほぼすべての機能がVOICEVOXエディタ上で利用可能になりました。
  • しかし、VOICEVOX系ソフトがそれぞれ個別に実装を行っていたキャラクターインストール機能(COEIROINK)や、音声ライブラリインストール機能(SHAREVOX)は各エディタから利用するしかなく、完全な統合は出来ていません。
  • これを解決するために、VOICEVOXが音声ライブラリ管理機能を主導して開発し、各エディタに搭載されていた機能群を統合したいです。
    • 現状VOICEVOXがこの機能を利用する予定はないですが、Coreに後からライブラリをさせるようになったり、複数コアを利用可能にする #3 を通して利用したりするかもしれないので、VOICEVOXとして進めていくことはメリットになると思います。
  • ここで管理とは、具体的に3つの機能を指します。
    • ダウンロードリストからのインストール
    • ファイルからのインストール
    • アンインストール

目標

  • ネットワーク経由で音声ライブラリをダウンロード・インストール・アンインストールする機能を搭載する
  • 音声ライブラリをファイルからインストールする機能を搭載する
    • MYCOEIROINKなどのユーザー製音声ライブラリを刺せるようにしたり、公式が配布しているライブラリを音声ライブラリ管理ダイアログからではなくブラウザなどでダウンロードしてきて差し込んだりする役割として使う
    • API仕様を確定させる
      • インストールAPIにvvlibを投げる仕様にする、インストール機能の実装が前提
      • 音声ライブラリの検証API(インストールしようとしている音声ライブラリは正しい形式であるかなどの検証処理)
      • エディタで軽い検証を行う
    • エディタUIを作る
      • エディタUIを考える
        • 恐らく、音声ライブラリインストール機能と同じダイアログに統合されることとなる。
        • 音声ライブラリのインポート機能をどうするか?
          • ダウンロード可能なライブラリについては、あらかじめAPIから立ち絵・アイコンやボイスサンプル、利用規約などを取得出来るが、インポートする機能についてはそれが出来ない。
          • ファイルをエンジンに投げ、話者情報を取得するようにする?
          • 検証用APIにその役割を担わせる?
        • できる限り、ネットワーク経由の方で使うものと共通化した実装にした方が良さそう
    • 音声ライブラリファイル(vvlib)の設計を決める
      • vvlib_manifest.jsonの仕様策定
        • vvppのように、engine_manifest.jsonみたいなものが欲しい(インストール先のエンジンブランドの指定や、ライブラリのバージョン値などを埋め込んでおくため)
        • これに乗せる情報の仕様を決めておきたい
        • 例えば、どこにどの情報があるかなどをここに書き込んでしまうのもいいかもしれない。
      • (Optional?)ディレクトリ構造を決める
        • library_manifest.jsonのところに書いた通り、構造はすべて製作者のお任せにして、library_manifest.jsonに必要なファイルの情報をすべて書き込んでもらうのもいいかも
        • そもそもディレクトリ構造を決める必要はなくて(library_manifest.jsonが必ず存在することぐらいにしておいて)、各エンジンに処理をお任せしてしまう方針でもいいかも
      • vvlib_manifest.jsonとディレクトリ構造: 音声ライブラリを管理する機能をサポートする #21 (comment)
@Hiroshiba Hiroshiba added 優先度:中 機能向上 要議論 実行する前に議論が必要そうなもの labels Feb 19, 2023
@Hiroshiba
Copy link
Member

issue作成ありがとうございます!!
頑張っていきたいですね!!

インポートとインストールは意味合いが似てるので混乱しそうですね!
たぶんインストールが「エンジンが返すダウンロードリストに載っている音声ライブラリを突っ込むこと」、インポートが「載っていないものを突っ込むこと」なのかなと思いました。
であればこの差分を仮の名称にしてしまうのが良いのかなと思いました!

「ユーザーモデルのサポート」とか・・・?

あと今のところ @sevenc-nanashi さんがPRを出してくださっていますが、そこにコメントをして機能を追加していくよりも、ちょっとずつ機能を区切ってPR・マージを高速に行うのが良いのかなと思いました!
そのPRはどこまで実装すべきかを意識して進めていきたいですね!

@y-chan
Copy link
Member Author

y-chan commented Feb 21, 2023

インポートとインストールは意味合いが似てるので混乱しそう

確かに、ちょっと意味合いが似ているかもですね...
サポートするのはユーザーモデルとも限らないので、「リストからインストール」と「ファイルからインストール」とかどうかなとか思いました。

今の状況であれば、特定の人にタスクが偏ってしまいそうなので、これを分散させたいのは同意です。
目標をもう少しタスクレベルまで落とし込みたいなと思いました...!

@Hiroshiba
Copy link
Member

サポートするのはユーザーモデルとも限らないので、「リストからインストール」と「ファイルからインストール」とかどうかなとか思いました。

なるほどです。
そもそも最初からvvlibを実装する形にすれば、ダウンロードはただvvlib一覧を返すだけになって二度手間もなくなって概念もわかりやすくなるかも・・・?

@y-chan
Copy link
Member Author

y-chan commented Feb 25, 2023

最初からvvlibを実装する

良いと思います!
インストールAPI自体がvvlibを展開するだけの機構になっていれば、流れがある程度共通化・統合できるので、分かりやすくなる上、管理のしやすさも上がると思いました...!

後でちょっとフローを図に起こしてみたいと思います:eyes:

@Hiroshiba
Copy link
Member

良いと思います! 段取りなどおまかせします・・・!(判断困ったらいつでも頼っていただければ!)

@Hiroshiba
Copy link
Member

こちらそろそろ動かしていけるかも?
ガシガシ設計プロトタイプ&切り分けって感じでしょうか

@y-chan
Copy link
Member Author

y-chan commented Mar 12, 2023

すみません...!
最近忙しくて返答が遅くなりました...

とりあえずは設計かなと思っています!
フロー図を用意したいのでもう少しだけ時間がかかりそうです...!

@y-chan
Copy link
Member Author

y-chan commented Mar 24, 2023

前回の返信からまた時間が空いてしまいました、申し訳ないです....
フローは以下のような感じで行こうかなと思います。(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;
Loading
  • まだアンインストールAPIができていないので、それの作成が必要になりそうです。ただ、必須級かと言われるとそうでもない気がするので、オプショナルでも良いかもしれません
    • アンインストールできない(プリインストールとかの)ライブラリを設定する必要があるかも...?installed_librariesに、アンインストールできるかの情報を含めたいかなと思いました。
  • データのやり取り単位がvvlibになりそうなので、vvlibの仕様を決めたいです。
    • 各エンジンごとに、内包したいデータが異なるはずなので、ライブラリに関する最低限の情報をlibrary_manifest.jsonに内包する方式にし、中のデータ処理は各エンジンにおまかせする方式で、十分に自由度を設定するのがいいかなと思いました。最低限欲しい情報は以下だと考えています。他に何か案があれば...!
      • name: 音声ライブラリの名前
      • version: 音声ライブラリのバージョン
      • uuid: 音声ライブラリのUUID
      • engine_name: エンジンの名前
      • engine_uuid: エンジンのUUID
  • ファイルからインストールする場合も、サンプル音声の試聴や、ライブラリインストール前の規約の確認フェーズがないと困るかなとちょっと思っているので、vvlibの中身のうち、それらのデータを返す処理が必要そうかなと思いました。ただし、その場合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;
Loading
  • 音声サンプルや立ち絵についてはどちらでも良いかもしれませんが、ライブラリ内に入っているものを知る(プレビューする)ための手段としてほしいかなと思います(ライブラリ名だけではわからないこともあると思うので)
  • ライブラリ利用規約の提示と同意は必要と思いましたが、いかがでしょうか?(特にユーザーモデルなどの場合は、トラブル防止のために「利用規約に同意してインストール」するボタンがあったほうが色々安心かなと思ったのですが、ユーザーが踏むステップの数は増えるので、UXは下がってしまうかも。)

@Hiroshiba
Copy link
Member

Hiroshiba commented Mar 27, 2023

@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をエンジンに渡せるようにするとか・・・?

利用規約の提示

賛成です!

@y-chan
Copy link
Member Author

y-chan commented May 7, 2023

いろいろ決めるべきことが決まってないことに今気づきました...遅くなってすみません...

あまりにも分かりづらい全体図ができたのでとりあえず隠しておきます...

全体図
flowchart TB;
    subgraph ネットワーク;
    server;
    end;
    subgraph ディスク;
    library_folder[ライブラリフォルダ];
    end;
    subgraph エディタ;
    file_select[エディタ上でのvvlibファイルの選択];
    download_select[エディタ上でのダウンロードするvvlibの選択];
    confirm_download[エディタ上でのサンプルボイスや立ち絵と利用規約の確認];
    confirm_install[エディタ上でのサンプルボイスや立ち絵と利用規約の確認];
    library_select[エディタ上でのインストール済みライブラリ選択];
    download[エディタ上でのvvlibダウンロード];
    end;
    subgraph エンジン;
    dl(downloadable_libraries);
    il(install_library);
    il2(installed_libraries);
    uil(uninstall_library);
    vl(validate_library);
    end;
    dl-->download_select;
    il2-->library_select;
    library_select-->uil;
    server-->dl;
    il-->library_folder;
    library_folder-->il2;
    uil-->library_folder;
    file_select-->vl;
    vl-->confirm_install;
    download_select-->confirm_download;
    vl-->il;
    dl-->confirm_download;
    confirm_download-->download;
    download-->vl;
    download-->il;
    confirm_install-->il;
    server-->download;
    file_select-->confirm_install;
    il2-->|downloadable_librariesと照らし合わせてアップデート可能か確認|download_select;
Loading

アプデフロー

エディタ上でインストール済みのものとバージョンと比較してインストール可能か判断する方式が良いかなと思いました。

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;
Loading

brand_name
manifest_version

良さそうです!
今の所こんな感じでしょうか。

  • name: 音声ライブラリの名前
  • version: 音声ライブラリのバージョン
  • uuid: 音声ライブラリのUUID
  • brand_name: エンジンブランド (VOICEVOXなど)
  • engine_name: エンジンの名前 (VOICEVOX Engineなど)
  • engine_uuid: エンジンのUUID
  • manifest_version: マニフェストバージョン

vvlibからインストールするとなると、エンジンが持っている話者情報は全部必要かも
データ抽出用のAPI用意すれば

vvlibファイル周りが若干ネックなのは変わりないのですが、validate_library API(仮名)をエンジン側に生やし、そこを通すと話者関連情報が得られるようにすれば良いかなと思いました。ここまでは今までの提案どおりなのですが、新たにvalidate_libraryを通さないとライブラリがインストール出来ないようにするのはどうかなと思いました。これは、validate_libraryの時点でエンジン側で音声ライブラリをキャッシュしておき、install_library時はファイルを渡すわけではなく、library_uuidなどを使ってvalidate_library時にキャッシュした情報からインストールするようにすれば、データの流れがある程度まとまって、処理の回数も減らせるのはないかなと思いました(全体図には少し反映しています)。
代わりに、インストールキャンセル時のためにdestroy_library API(仮名)とかもはやしてあげる必要があるのが若干ネックかもです。

validate以外のことをするという点で、名前は変えたほうがいいとは思いますが、いい名前が思い浮かばず...

@Hiroshiba
Copy link
Member

@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とか?)

@y-chan
Copy link
Member Author

y-chan commented May 13, 2023

エディタ上でのサンプルボイスや立ち絵と利用規約の確認が2回ある

これは、グラフ上でエディタ上でのvvlibファイルの選択からのものとエディタ上でのダウンロードするvvlibの選択からのもので、データフローが違うために分けているのと、グラフ上の同じノードを使うと処理が分かりにくくなるから分けただけで、多分実際には同じ処理を使うことになり、それぞれの工程で1回だけになると思います...!

ファイルパス指定であればキャッシュ不要にできそう
web APIとして変

私も、Web APIとしては変かなと思ったので、キャッシュ方式を考えていました。
ファイルパス方式だと、ディレクトリトラバーサルなどの、パス関連の問題が起きないかが少し気になるところですが、PCの外にAPIを公開しなければ問題にならないはずなので、一旦その方式でもいいかなと思いました。

vvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃう

うーん、これは特に問題ないのではと思っています。
今のところ、COEIROINKのユーザーモデル機能では、zipファイルにモデルやmetas.jsonと合わせて、話者関連情報なども含めて配布する形になっているので、話者関連情報をセットで配布することをを必須にするのは特に大きく問題となる気はしない気がしています(エンジンには、モデルの配置と話者関連情報の両方を配置してもらうように設計してもらえばいいと思っているのですが、それ以外に私が把握できていない問題がありそうですかね...?)。

エンジンのengine_manifest.json側に、対応しているライブラリのmanifest_versionをもたせたほうが良い

これは確かにそうですね!エンジンが未対応のライブラリはインストールできないようにしないと、未対応の仕様に対応できずに変な動作が起きる可能性があると思うので、追加する必要はありそうだと思いました!

@Hiroshiba
Copy link
Member

Hiroshiba commented May 16, 2023

ファイルパス方式だと、ディレクトリトラバーサルなどの、パス関連の問題が起きないかが少し気になるところですが、PCの外にAPIを公開しなければ問題にならないはずなので、一旦その方式でもいいかなと思いました。

まあそうですよね・・・。
実際バイナリ投げるのを作ってみて、遅そうだったりキャッシュ方式が作れなかったりしたら再考するとか・・・?

vvlibに話者関連情報を持たせない場合、エンジン側が知らないvvlibは追加できない、という感じになっちゃう

うーん、これは特に問題ないのではと思っています。
話者関連情報をセットで配布することをを必須にするのは特に大きく問題となる気はしない気がしています

あれ、ちょっとわかってないので認識合わせしたいです。
OSS上のvvlibはスタイル番号やアイコンなどは含まず、各々のエンジンの独自仕様としてアイコンなどを追加してもらう、という理解で合っていますか・・・? 👀

VOICEVOXエディタはそもそも話者情報(SpeakerInfo)が必須なので、それをvvlib内かエンジン内に含める必要があるはず。
vvlibに話者関連情報を持たせない場合、エンジンがどこかからか話者関連情報を取得する必要があるのですが、そこどうしようかな~と。

@y-chan
Copy link
Member Author

y-chan commented May 27, 2023

実際バイナリ投げるのを作ってみて、遅そうだったりキャッシュ方式が作れなかったりしたら再考するとか・・・?

まあPoCを作ってみてどういうふうになるか見てみるのはわりとありだと思います!
バイナリを投げる方式は一度SHAREVOXで作ったことがあって、動きそうではあったので、キャッシュ方式の検証APIを考えてもいいかも。

OSS上のvvlibはスタイル番号やアイコンなどは含まず、各々のエンジンの独自仕様としてアイコンなどを追加してもらう、という理解で合っていますか・・・? 👀

うーん、たしかにちょっと認識の齟齬がありそうです。
まず前提に、私自身はvvlibの仕様として話者関連情報は必ず含めなければならない仕様になっているべきではあると思っています。
ただ、それをlibrary_manifest.jsonとして同梱するかはちょっと検討した方がいいという意見でした。
多分、#21 (comment) の意見を見たときに、「話者関連情報もlibrary_manifest.jsonとして導入した方がいい」という意見として取ってしまったのが認識の齟齬の原因です...

なので、vvlib内にspeaker_infoフォルダを作り、そこにエンジンと同構造の話者関連情報を必ず導入するようにするといった仕様を決めちゃっていいかなと思います。
それであれば決まったフォルダを探索すれば話者関連情報を得られるので、以前例に上げたvalidateAPIにvvlibを投げて話者関連情報を得ると言ったことをしなくとも、エディタ側でも処理可能になると思います。
簡易的なバリデーション(話者関連情報の取得と、library_manifest.jsonの検証)をエディタ側で行い、インストール時にエンジン側でしっかりとしてバリデーションを行えばフローも簡単化されていいかなと思いました。

あと、思ったのですがlibrary_manifest.jsonじゃなくてvvlib_manifest.jsonのほうがいいのかもしれない...?(engine_manifest.jsonになぞらえるならlibrary_manifest.jsonだと思いますが、VOICEVOXにおいてlibraryは動的ライブラリ: coreの用語ではあると思うので)

@Hiroshiba
Copy link
Member

Hiroshiba commented May 27, 2023

あ、なるほどです!

library_manifest.jsonに全部書くのはたしかに大変かもです。
まあファイル構造だけ定義した場合、vvlibを読む側はOS違いに対応したり、いろんな音声ファイル・画像ファイルの拡張子に対応したり、将来互換性確認のためにファイル存在を調べたりしないといけなくなるので、jsonにしといたほうが全体で見ると楽かも・・・?

うーん! でもエンジン側と共通化できるのは大きいし、ファイル構造定める方針で良い気がしました!
将来ファイル構造変えねばってなったときに再検討しますか。

エディタ側であるvvlibから情報得るの、良い気がしました!
エディタ側の検証は、表示に必要な情報があるかのチェックくらいにしとくと楽そう。

library_manifest.jsonじゃなくてvvlib_manifest.json

どちらでも良いかなと思いました! どちらかというとvvlib_manifestが良さそうかなと。

@y-chan
Copy link
Member Author

y-chan commented May 28, 2023

エンジン側と共通化できるのは大きいし、ファイル構造定める方針で良い気がしました!
将来ファイル構造変えねばってなったときに再検討しますか。

今までファイル構造が変わったことは、スタイルごとに立ち絵が変更できる点ぐらいだったので、あまり神経質にならなくてもいいかなと思っています...!

表示に必要な情報があるかのチェックくらいにしとくと楽そう

そうですね、存在確認と、ファイル形式が問題ないかを検証するだけで、エディタ側で情報の表示が出来ると思うので、これでいいかなと思いました!

どちらかというとvvlib_manifestが良さそうかなと。

vvlib_manifestで行こうと思います....!

@y-chan
Copy link
Member Author

y-chan commented May 28, 2023

全体像がある程度まとまったと思うので、検証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;
Loading

この方向で不足している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
     └─ ...

@Hiroshiba
Copy link
Member

良いと思います!!

音声ライブラリのアプデの議論ってしてましたっけ。installと全く同じ経路にして、uuidが既存だったら上書きが良いのかなと思いました!

@y-chan
Copy link
Member Author

y-chan commented May 28, 2023

音声ライブラリのアプデの議論ってしてましたっけ。installと全く同じ経路にして、uuidが既存だったら上書きが良いのかなと思いました!

これで良いと思います!

@Hiroshiba
Copy link
Member

Hiroshiba commented Jan 20, 2024

メモです。
release-0.15で、エディタからのvvlib機能への対応情報表示をフィルタリングするようにしました。(まだ必ず非対応なため)
vvlib機能が正式サポートされたら忘れずに解除できればと!

@Hiroshiba
Copy link
Member

@y-chan
0.15のときにengine_manifestのsupported_vvlib_manifest_versionを消した(nullにした)のですが、これは引き続き消したままにしようと思います。
というのもまだ仕様が固まってなくて、どのバージョンが一番最初のバージョンになるかわからないので・・・。

manage_libraryの方はtrueにするので開発には支障がないと思っていますが、最終的にリリースする時に入れ忘れないよう注意が必要かもです。
(まあ入れ忘れたとしても、一番最初に破壊的変更があった時に書けば問題ないと思います)

@tarepan
Copy link
Contributor

tarepan commented Mar 18, 2024

VOICEVOX ENGINE での議論場所: VOICEVOX/voicevox_engine#536

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
優先度:中 機能向上 要議論 実行する前に議論が必要そうなもの
Projects
None yet
Development

No branches or pull requests

3 participants