新クラス設計API #370

qwerty2501 · 2023-01-09T07:29:55Z

関連 Issue

refs #280,#280 (comment)

qwerty2501

とりあえず実際のコード見たほうがイメージ付きやすいかと思ったのでつくりました
全体的にちょっと長めの命名にしてます

crates/voicevox_core/src/publish.rs

Hiroshiba · 2023-01-09T16:25:13Z

crates/voicevox_core/src/publish.rs

+pub struct Device {}
+
+/// スピーカーId,スタイルIdから音声合成モデルIdを取得する
+pub fn get_model_id(speaker_id: &SpeakerId, style_id: &StyleId) -> Result<SpeechSynthesisModelId> {}


これ便利そうですね！
たぶんModelを作成して初めてglobalメモリ上にmetasのデータが乗って、そこからmodel_idを引っ張ってくる形ですよね。
となると、Model.from_idとこっちのどっちが先なのかみたいな問題が出てきそうだなと思いました！

いや違います。これはビルトインのmodelを読み込む際にユーザーがmodel idを知るすべがないのでとりあえず作ったものですね
なのでmodel作成前に呼ばれることを想定しており、modelがビルトインじゃなくなったらこの関数は消そうかと思ってます

あーなるほどです！であれば問題はなさそうです。

（まあビルトインのモデルはunloadする方法はなくても良い派なので、この関数は最初からなしでも良いかも！）

仮にビルトインのmodelはunload提供しなかったとしても全loadせずに個別にビルトインのmodelを読み込みたい場合に必要ではないでしょうか？

それは必要だと思います！VVM対応したら自動的にその需要は満たせるかなと。

つまり（ちょっと話が進んじゃうのですが）こういうのを考えてます。
ビルトインも２種類あると思います。
１つが今のCOREみたくVVMがなく勝手にloadされてるパターンですが、こちらはunloadもloadも提供しなくて良いかなと。
もう１つが製品版のVVMファイルを全部loadされてるパターンで、これは「勝手にloadしない」ようにできる制御フラグを付けつつ、あとはVVMをload/unloadしてもらえればみたいな感じでいます。

VVMも全部入ってるものの提供を考えてました！
まあ個別にするかは置いといて、同ディレクトリにあるvvmファイルを全部読み込むかどうか、みたいなオプションになるんじゃないかなーと思っています。

それか今と同じでmodelsディレクトリ配下にあるVVMファイルを読み込むとかですかね。
しかしそうなるとファイルパス指定のAPIの価値があまりなくなってしまいますね
個別に読み込む際に使えそうですが、ユーザーがどのVVMを読み込めば目的のスピーカーを使うことができるか知る手段を提供するつもりでいますか？

目的のスピーカーというよりかは目的のスタイルですかね

modelsディレクトリでも良いと思います！（そっちのほうが良さそう）

知る手段

重要なことですが、良い方法が思いつかないですね･････。
全metas.jsonを書き下したREADME.mdを作るとか･･････。
せめて検討がつくよう、わかりやすいファイル名にしてあげたいですね･･･。

そうなるとファイルパス指定のAPIの価値があまりなくなってしまいますね

現ニーズは現APIなので、この視点だとパス指定周りとかは価値が薄いとは思います。
でもまあVVMを抜き差しできれば、例えば差分アップデートなど別の仕様も思いつけると思います！

get_model_idについては削除

qwerty2501 · 2023-01-21T04:35:23Z

今議論されているものについてAPIを最新に変更しました
とりあえずpublish.rsに書いていますが、実際の実装ではファイルを分けて実装する形になると思います

Hiroshiba · 2023-01-21T09:22:48Z

議論ありがとうございました！！
あと大きなのはVoiceModelファイルのファイル形式ですかね…？

qwerty2501 · 2023-01-21T09:59:17Z

そうですね。そこ決まったらとりあえずの仮実装はできそうです
実際に実装するのは他のPRのmergeされ具合を見てからになりそうですが

qwerty2501 · 2023-01-23T17:38:34Z

Rust化したときにはC APIしかなかったから同期処理だけにしてたけど、Python,将来的にはRustも公開することを考えるとRust実装とPython実装の部分についてはasync化できるところ(VVMファイルをオープンする処理とか)はasync化したほうがよいかも？ 🤔

@Hiroshiba @qryxip 意見聞かせてもらえますか？

Hiroshiba · 2023-01-24T09:59:21Z

良い設計がまだ浮かんで無いですが、面白いと思います！
オプショナルな立ち位置なのかなと思いました。

qryxip · 2023-01-24T11:50:33Z

RustのasyncはPythonのasyncに変換できたりしますし、そこからブロッキングなAPIに派生させることも普通にできるため、ありかとは思います。

qwerty2501 · 2023-01-24T13:02:24Z

APIを一度公開してしまうとあとから変えるのは難しいくtryするならいましかなさそうなのでやってみます。
decodeなどIOではないが時間がかかりそうな処理についても非同期にしたほうがいいですかね？

Hiroshiba · 2023-01-24T15:45:22Z

たしかにAPI変更に関してはおっしゃる通りかもです。
onnxruntimeの実行は同時にできるのかかなり怪しい気がしています。
仕様上問題ないのであればぜひという感じです！

qwerty2501 · 2023-01-24T18:24:28Z

onnxruntimeもそうですが、openjtalkも同時に実行すると壊れてしまうので今と同じように全体的にロックをかける必要はありそうですね
将来的にはそのあたりもロックなしにできるとよいですが

qryxip · 2023-01-24T21:50:17Z

そこはまあ!Syncの制約に任せていいんじゃないですかね。
~~Environmentをouroborosとかで抱えるか、VoiceSynthesizerの複数生成を禁じるかして。~~
Environmentの中身はArc<Mutex<_>>でしたね。ouroborosとかは不要でした。

qwerty2501 · 2023-01-25T01:31:46Z

そもそもEnvironmentについてはnew_session_builderでimmutable参照されてるだけなのでどちらにしろ不要かも

qryxip · 2023-01-25T01:43:18Z

そこはまあ、今(多分時間差で)↑のコメントをeditしましたがonce_cellに置いたままでもよいので、使いまわせるなら使いまわした方がいいんじゃないでしょうか。

qwerty2501 · 2023-02-07T18:13:07Z

@Hiroshiba engine互換APIためにstyle_idとvvmとは別にstyle_idとvvmファイルのパスの対応情報をまとめたファイル
と、すべてのmetas情報をまとめたmetaファイルが必要そうです

Hiroshiba · 2023-02-07T23:41:22Z

（ちょっと記憶が曖昧で変なことを言っちゃうかもしれません･･･。）

先に後者のこちらから

すべてのmetas情報をまとめたmetaファイルが必要そうです

これに関してはmetaファイルを用意しなくても、全VVMをloadしたSynthesizerのmetasを使えば良いのかなと思ってました･･･が、全modelをloadするので重そうですね･･･。

ファイルを用意しなくても、全VVMから全Modelを作って全Modelのmetasを集約する手もありそう･･･？
この形だとコード的に大変な感じでしょうか。

style_idとvvmとは別にstyle_idとvvmファイルのパスの対応情報をまとめたファイル

あーーー。これは必要になったstyle_idのModelだけloadするため、ですよね。
盲点でした。今の仕様だと、predict_durationやdecodeは各Modelに含まれるstyle_idを意識しなくて良い一方、loadはどのModelがどのstyle_idを持っているか把握する必要があって不便かもです･･･。

Modelを参照するだけのset関数と、style_idを指定して実際に読み込むload関数をSynthesizerに持たせるのはどうでしょうか。。
こうすればloadすることなく全Modelのmetasを得ることができて、style_idとvvmファイルの対応を別途用意する必要もなくなるかも･･････？

qwerty2501 · 2023-02-08T01:27:13Z

ファイルを用意しなくても、全VVMから全Modelを作って全Modelのmetasを集約する手もありそう･･･？
この形だとコード的に大変な感じでしょうか。

可能ですが互換性守るならmetasはdll読み込み時にすでに用意できてる必要があるのでdll読み込みが相当遅くなります

Modelを参照するだけのset関数と、style_idを指定して実際に読み込むload関数をSynthesizerに持たせるのはどうでしょうか。。
こうすればloadすることなく全Modelのmetasを得ることができて、style_idとvvmファイルの対応を別途用意する必要もなくなるかも･･････？

前のやり取りだと新APIは読み込んでいるmetasのみ返す仕様にするとのことだったのですが常に全てのmetasを返すようにするということでしょうか？

qwerty2501 · 2023-02-08T18:20:40Z

ちょっと対応できそうかもなのでやってみます

Hiroshiba · 2023-02-08T21:45:44Z

前のやり取りだと新APIは読み込んでいるmetasのみ返す仕様にするとのことだったのですが常に全てのmetasを返すようにするということでしょうか？

あ、違います！
Synthesizerのモデル読み込み関数をなくし、モデル登録関数と読み込み関数を分けるニュアンスです。
実際のコードに近い形で書くと、load_model(model)をset_model(model)とload(style_id)に分ける感じを想像しています。

狙いは２つあって、１つ目の理由が読み込まなくてもmetasが分かるようにするためです。
setしたモデルからmetasを集約する仕様にすればできるはず。

もう１つの狙いは↓の解消です。
音声合成部分と読み込み部分でModelの扱いが同じでないのを解消する狙いです。

今の仕様だと、predict_durationやdecodeは各Modelに含まれるstyle_idを意識しなくて良い一方、loadはどのModelがどのstyle_idを持っているか把握する必要があって不便かもです･･･。

qwerty2501 · 2023-02-09T03:04:58Z

Synthesizerのモデル読み込み関数をなくし、モデル登録関数と読み込み関数を分けるニュアンスです。

公開APIとしてはload_model関数のみにしたほうが良いと思います。

狙いは２つあって、１つ目の理由が読み込まなくてもmetasが分かるようにするためです。
setしたモデルからmetasを集約する仕様にすればできるはず。

これはVoiceModelでmetasを確認できるので不要では

もう１つの狙いは↓の解消です。
音声合成部分と読み込み部分でModelの扱いが同じでないのを解消する狙いです。

これはunloadの振る舞いが不自然になる問題があるので解消しきれないと思います

qwerty2501 · 2023-02-10T01:10:25Z

@Hiroshiba 過去のやり取りでもunloadとの整合性が取れなくなる点について言及されてますね
#280 (comment)

Hiroshiba · 2023-02-12T03:25:26Z

これはunloadの振る舞いが不自然になる問題があるので解消しきれないと思います

あああ･･････。すみません、これ失念していました･･･。

うーん。unloadややこしい問題があるのでsetとloadに分けるのは難しいかなと思いました！
気持ちとしては、全部入りのSynthesizerがVoicevoxApiと同じようなインターフェイスになるのが良いのかなと（なんとなく）思っての提案でした。

…new_class_design

qryxip · 2023-05-21T08:42:54Z

コンフリクトを解消しました。マージ可能です。

つきましてはこのタスクリストに追加で入れるべき内容が無いかだけ、どなたかに見てもらえたらと思っています。
#280 (comment)

Hiroshiba · 2023-05-22T16:02:19Z

@qryxip ざっと見た感じ問題ないのかなと思いました！！
おそらくリリースは７月とかになると思うので、破壊的変更はしちゃっても大丈夫なので「以前のAPIをdeprecatedなものとして残す」はオプショナル的なタスクかなと思いました！！

Hiroshiba · 2023-05-22T16:03:49Z

いったんマージさせていただきます！
@qryxip さん、そして @qwerty2501 さん、ほんとにありがとうございました！！！

VOICEVOX#370 (comment) Co-authored-by: Hiroshiba <[email protected]>

qwerty2501 commented Jan 9, 2023

View reviewed changes

Hiroshiba reviewed Jan 9, 2023

View reviewed changes

qwerty2501 requested a review from Hiroshiba January 10, 2023 05:07

Hiroshiba mentioned this pull request Jan 20, 2023

voicevox_coreのクラス設計discussion #280

Closed

qwerty2501 force-pushed the feature/new_class_design branch from db09d19 to b3a8165 Compare January 30, 2023 11:56

qryxip mentioned this pull request Feb 5, 2023

C APIのE2Eテストを作る #424

Closed

3 tasks

qwerty2501 force-pushed the feature/new_class_design branch 2 times, most recently from a83538b to c3a0a76 Compare February 23, 2023 16:38

qwerty2501 changed the title ~~新クラス設計を元にしたAPIたたき~~ 新クラス設計API Feb 23, 2023

qwerty2501 marked this pull request as ready for review February 23, 2023 18:47

qryxip added 10 commits May 20, 2023 01:07

Black

3ccb826

Merge commit 'ff7b5a88865d684132f5995ff456273f7cf18f52' into feature/…

7d1a85d

…new_class_design

Merge commit 'da84ce389b760877eb5b17663f0fae758bafc64c' into feature/…

8e65db1

…new_class_design

Merge commit '546e1735e0719c70834e57546196f6a3377beef6' into feature/…

002010d

…new_class_design

Merge commit 'babce876011463927120e8cab908ad9eb160a2a2' into feature/…

e40f157

…new_class_design

Merge commit '406f6c41408836840b9a38489d0f670fb960f412' into feature/…

c0fd40d

…new_class_design

Merge branch 'main' into feature/new_class_design

dc54da2

voicevox_core.hをアップデート

24a2b62

Cargo.tomlのdiff部分を手動フォーマット

a12a709

無駄なasync {}を外す

3f66e61

Hiroshiba merged commit fb24f4f into VOICEVOX:project-vvm-async-api May 22, 2023

This was referenced May 22, 2023

project-vvm-async-api #497

Merged

間違ったchar*の解放を明示的に拒否する #499

Closed

[project-vvm-async-api] ドキュメントの表記ゆれを解消 #501

Merged

[project-vvm-async-api] いくつかのC関数を定数にする #503

Merged

qryxip mentioned this pull request Jun 5, 2023

[project-vvm-async-api] get_supported_devices_jsonをfallibleに #502

Merged

sevenc-nanashi mentioned this pull request Jun 8, 2023

タスクリスト VOICEVOX/voicevox_mobile#28

Open

23 tasks

qryxip mentioned this pull request Jun 13, 2023

[project-vvm-async-api] voicevox_{,synthesizer_}is_loaded_voice_model #523

Merged

qryxip added a commit to qryxip/voicevox_core that referenced this pull request Jun 13, 2023

voicevox_{,synthesizer_}is_loaded_voice_model

d7d1052

VOICEVOX#370 (comment) Co-authored-by: Hiroshiba <[email protected]>

qryxip mentioned this pull request Jun 16, 2023

[project-vvm-async-api] "buffer"をRustの世界で保持し続ける #525

Merged

qryxip mentioned this pull request Jul 22, 2023

[2月末リリース予定!] v0.16 #545

Open

69 tasks

qryxip mentioned this pull request Oct 25, 2023

voice_synthesizer.rs → synthesizer.rs #657

Merged

Hiroshiba mentioned this pull request Dec 2, 2023

[docs] ユーザーガイドを追加 #699

Merged

qryxip mentioned this pull request Dec 3, 2023

keep a changelog形式のchangelogを手書きする #704

Open

3 tasks

qryxip mentioned this pull request Sep 10, 2024

improve: rework VoiceModel #830

Merged

Hiroshiba mentioned this pull request Dec 1, 2024

feat!: Synthesizer::audio_queryをcreate_audio_queryに改名 #882

Merged

qryxip linked an issue Dec 18, 2024 that may be closed by this pull request

onnxruntimeのSessionを解放してGPUメモリをリフレッシュできる仕組みを作る #337

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

新クラス設計API #370

新クラス設計API #370

qwerty2501 commented Jan 9, 2023 •

edited by qryxip

Loading

qwerty2501 left a comment

Hiroshiba Jan 9, 2023

qwerty2501 Jan 9, 2023

Hiroshiba Jan 9, 2023 •

edited

Loading

qwerty2501 Jan 10, 2023

Hiroshiba Jan 10, 2023

Hiroshiba Jan 17, 2023 •

edited

Loading

qwerty2501 Jan 17, 2023

qwerty2501 Jan 17, 2023

Hiroshiba Jan 17, 2023

qwerty2501 Jan 21, 2023

qwerty2501 commented Jan 21, 2023

Hiroshiba commented Jan 21, 2023

qwerty2501 commented Jan 21, 2023

qwerty2501 commented Jan 23, 2023

Hiroshiba commented Jan 24, 2023

qryxip commented Jan 24, 2023

qwerty2501 commented Jan 24, 2023

Hiroshiba commented Jan 24, 2023

qwerty2501 commented Jan 24, 2023

qryxip commented Jan 24, 2023 •

edited

Loading

qwerty2501 commented Jan 25, 2023

qryxip commented Jan 25, 2023 •

edited

Loading

qwerty2501 commented Feb 7, 2023 •

edited

Loading

Hiroshiba commented Feb 7, 2023 •

edited

Loading

qwerty2501 commented Feb 8, 2023 •

edited

Loading

qwerty2501 commented Feb 8, 2023

Hiroshiba commented Feb 8, 2023 •

edited

Loading

qwerty2501 commented Feb 9, 2023 •

edited

Loading

qwerty2501 commented Feb 10, 2023

Hiroshiba commented Feb 12, 2023 •

edited

Loading

qryxip commented May 21, 2023

Hiroshiba commented May 22, 2023

Hiroshiba commented May 22, 2023 •

edited

Loading

新クラス設計API #370

新クラス設計API #370

Conversation

qwerty2501 commented Jan 9, 2023 • edited by qryxip Loading

関連 Issue

qwerty2501 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hiroshiba Jan 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hiroshiba Jan 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

qwerty2501 commented Jan 21, 2023

Hiroshiba commented Jan 21, 2023

qwerty2501 commented Jan 21, 2023

qwerty2501 commented Jan 23, 2023

Hiroshiba commented Jan 24, 2023

qryxip commented Jan 24, 2023

qwerty2501 commented Jan 24, 2023

Hiroshiba commented Jan 24, 2023

qwerty2501 commented Jan 24, 2023

qryxip commented Jan 24, 2023 • edited Loading

qwerty2501 commented Jan 25, 2023

qryxip commented Jan 25, 2023 • edited Loading

qwerty2501 commented Feb 7, 2023 • edited Loading

Hiroshiba commented Feb 7, 2023 • edited Loading

qwerty2501 commented Feb 8, 2023 • edited Loading

qwerty2501 commented Feb 8, 2023

Hiroshiba commented Feb 8, 2023 • edited Loading

qwerty2501 commented Feb 9, 2023 • edited Loading

qwerty2501 commented Feb 10, 2023

Hiroshiba commented Feb 12, 2023 • edited Loading

qryxip commented May 21, 2023

Hiroshiba commented May 22, 2023

Hiroshiba commented May 22, 2023 • edited Loading

qwerty2501 commented Jan 9, 2023 •

edited by qryxip

Loading

Hiroshiba Jan 9, 2023 •

edited

Loading

Hiroshiba Jan 17, 2023 •

edited

Loading

qryxip commented Jan 24, 2023 •

edited

Loading

qryxip commented Jan 25, 2023 •

edited

Loading

qwerty2501 commented Feb 7, 2023 •

edited

Loading

Hiroshiba commented Feb 7, 2023 •

edited

Loading

qwerty2501 commented Feb 8, 2023 •

edited

Loading

Hiroshiba commented Feb 8, 2023 •

edited

Loading

qwerty2501 commented Feb 9, 2023 •

edited

Loading

Hiroshiba commented Feb 12, 2023 •

edited

Loading

Hiroshiba commented May 22, 2023 •

edited

Loading