voicevox_coreのクラス設計discussion #280

qwerty2501 · 2022-09-14T15:17:36Z

内容

#276 (comment) , #274 (comment) によりvoicevox_coreの C APIをオブジェクト指向に寄せたAPIにする必要が出てきて、そのための議論をしたいと考えています。
個人的には以下のようなクラスでC APIを考えてるのですがいかがでしょうか？
またpython APIについてもこのissueで議論したクラス設計を元にAPI設計を作りたいと考えてます。
今考えてるものとしてはversion,metas,supported_devices情報の取得はVoicevoxCoreクラスのstaticメンバ関数として実装しようと考えています。

struct VoicevoxCore;

VoicevoxCore* voicevox_core_new();

VoicevoxResultCode voicevox_core_initialize(VoicevoxCore* voicevox_core, VoicevoxCoreInitializeOptions options);

void voicevox_core_delete(VoicevoxCore* voicevox_core);

// staticメンバ関数のためVoicevoxCore のオブジェクトpointerは不要
char* voicevox_core_get_version();

// staticメンバ関数のためVoicevoxCore のオブジェクトpointerは不要
char* voicevox_core_get_metas_json();

// staticメンバ関数のためVoicevoxCore のオブジェクトpointerは不要
char* voicevox_core_get_supported_devices_json();

VoicevoxResultCode voicevox_core_load_model(VoicevoxCore* voicevox_core,uint32_t speaker_id);

bool voicevox_core_is_gpu_mode(const VoicevoxCore* voicevox_core);

//以下、同様にオブジェクト指向的にC APIを定義していく

voicevox_core_newとvoicevox_core_initializeは一緒にするべきかもしれませんがresultcodeの関係上分けようかと思ってます。
また現在のvoicevox_coreの関数のprefixは voicevox ですが、これもきちんとオブジェクト指向的な名前にすると voicevox_core にprefixがなると思い、 prefix を voicevox_core にしようと考えています。

その他

@sevenc-nanashi @shigobu お二人はvoicevox_coreのwrapperを作成されているように見受けられますのでぜひご意見をいただきたいです。

The text was updated successfully, but these errors were encountered:

shigobu · 2022-09-15T05:40:13Z

voicevox_core_newとvoicevox_core_initializeは一緒にするべきかもしれませんがresultcodeの関係上分けようかと思ってます。

できるなら、一緒のほうがいいと思います。
別にすると、initializeの要・不要がわからない問題が残ると思います。例えば、voicevox_core_load_model関数を使うには、voicevox_core_new関数でオブジェクトを作成し、voicevox_core_initialize関数で初期化する必要がありますが、voicevox_core_initialize関数を呼ばなくてもvoicevox_core_load_model関数を呼ぶことができてしまいます。newとinitializeを一緒にすれば、このような間違いは発生しなくなります。
initializeの要・不要をドキュメントに書くのでもいいですけど、間違いが起きない(起きにくい)仕組みにできるならしたほうが良いと思いました。

一緒にした場合の懸念点として、どのようにエラーを通知するかが有ると思います。
これに関しては他の関数と同様に、戻り値でVoicevoxResultCodeを返し、引数でVoicevoxCoreオブジェクトを返すのが統一感があって良いかなと思いました。
例えばこんな感じ。

VoicevoxResultCode voicevox_core_new(VoicevoxCoreInitializeOptions options, VoicevoxCore** voicevox_core);

sevenc-nanashi · 2022-09-15T07:29:44Z

自分も同意です。
また、実際に使うコードは

VoicevoxCore vvc = voicevox_core_new();
if(!voicevox_core_initialize(...))
  ...

のようにすぐ下でinitializeが呼ばれると思うので、それならまとめてもいいんじゃないかと思いました。

（Cは詳しくないのでコードが間違ってて変なことを言ってるかも…）

qwerty2501 · 2022-09-15T10:12:00Z

@shigobu @sevenc-nanashi そうですね。一緒にやるとするならそのような形になります。
しかしinitializeは何度も呼び出される想定であるとのことでした。
その場合 voicevox_core_reinitialize のようなメンバー関数をつくってそこで何度も呼び出せるような方式にすれば対応はできなくもないとは思いますが、そもそもinitializeを何度も呼び出される想定であることに違和感を覚えます。
なぜinitializeを何度も呼び出される必要があるのか、またinitializeのどの部分の処理が何度も呼び出す必要があるのか明らかにする必要がありそうです。
@Hiroshiba initilalizeが何度も呼び出されることを期待する理由とは何でしょうか？またそれは本当に必要でしょうか？

Hiroshiba · 2022-09-15T11:57:23Z

結論から言うと、コンストラクタと一緒にしちゃって良いかなと思いました！
initializeがある理由は、以前のAPIだとVoicevoxCoreクラスがなかったという歴史的経緯が大きそうです。

一応現状のinitializeがあった方が良い理由もいくつかあります。
それらも踏まえて考えを書きます。

まず、デストラクタを呼ばずにmodelを解放（GPUメモリを解放）できるのは需要が無くはないと思います。
が、これはどちらかというと作るべきはunload_modelなので（しかも必須級ではない）、やっぱりinitializeはなくて良いかなと思いました！

あとは同じくデストラクタ呼ばずにCPU・GPU版を切り替えが可能なことです。
これもどちらかというと需要があるのは切り替え用メソッドだと思いました（こちらも必須級ではない）。

一方、initializeを呼ぶ必要があるのはバグや面倒さにつながると思います。
総合すると、initializeとコンストラクタはくっ付けて良いと思います。
unload_modelやGPU CPU切り替え機能がなくなりますが、別にクラスインスタンスごと作り直しても良いと思うし、追々追加くらいで良さそうな印象です。

qwerty2501 · 2022-09-15T12:06:48Z

となるとRust側もくっつけて良さそうというかすでに new_with_initializeが存在しますね。

qryxip · 2022-09-15T14:59:26Z

ところでPyO3実装あたりで特に何も議論せずにstruct Internalをstruct VoicevoxCoreに変更したと思うのですが、今ならまだリネームする選択肢があるかなとふと思いました。例えばVoicevoxCoreSessionとか。

qwerty2501 · 2022-09-15T15:17:39Z

Sessionという単語はonnxruntime文脈のもので voicevox_coreのユビキタス言語としてはSessionは無いような気がします。
いやどうだろう・・・

Hiroshiba · 2022-09-15T15:52:32Z

どういうクラスになるのかまだ見えていないというのもあるので、いったんVoicevoxCoreのママでも良いのかなと思いました！

qwerty2501 · 2022-09-16T02:52:04Z

確かにドメイン設計からやるとなるとかなり時間かかっちゃいそうなので今回はVoicevoxCoreクラス単一で提供して良さそうですね。
しかし将来的にはちゃんとしたドメイン設計を行いそれを(内部の改修も含めて)元にしたAPIの提供をしても良さそうですね。

qryxip · 2022-09-16T15:27:39Z

versionやmetasやOptions系はどうしましょうか?

選択肢としては今のところ次の4つがあると思います。

型"VoicevoxCore"のstatic method (@qwerty2501 さんの案)

voicevox_core_get_metas_json() // C

voicevox_core.VoicevoxCore.metas()  # Python

モジュール"voicevox_core"の関数

voicevox_get_metas_json()

voicevox_core.metas()

1.の定数版

voicevox_core_metas_json

voicevox_core.VoicevoxCore.METAS

2.の定数版
```
voicevox_metas_json
```
```
voicevox_core.METAS
```

Hiroshiba · 2022-09-16T16:52:39Z

@qryxip
あ！そういえば、将来的な観点になるのですが、onnxモデルを読み込めるようになったときもAPIがあまり変わらないようになっていると嬉しそうです。
metasとonnxが結びついているので、load_model時にmetasの内容が変わりそうです。

この視点だと、metasは関数VoicevoxCoreのインスタンスメソッドか定数が良さそうかなと思いました。

･･･本当は１つのモデルに１つのクラスインスタンスを対応させるのが良いのかもとちょっと思いました。

qwerty2501 · 2022-09-16T17:01:24Z

metas関数はメンバ関数にしたほうが良さそうですね。

･･･本当は１つのモデルに１つのクラスインスタンスを対応させるのが良いのかもとちょっと思いました。

これ今のうちに対応するのがベストかもですね。voicevox_core_newを以下のような感じにすると対応できそう？

VoicevoxResultCode voicevox_core_new(
    uint32_t speaker_id,
    VoicevoxCoreInitializeOptions options,
    VoicevoxCore** output_voicevox_core);

その場合だとdecodeなどの関数はspeaker_idを受け取る必要はなくなりそうですね。

Hiroshiba · 2022-09-16T17:15:30Z

あ！とりあえずAPIとしての提供は実際に製品版がloadを使うようになってからでも良いかも･･･？
いや今からあっても良いかもですね！APIの設計確認もできそうですし。

その場合だとdecodeなどの関数はspeaker_idを受け取る必要はなくなりそう

モデルとspeaker_idは1:1対応じゃないのでspeaker_idは必要そう･･･？

いくつかの観点を思いついたので列挙してみます。

モデルはyukarin_s yukarin_sa decodeで１セットで、そのセットが複数ある
- ので、このセット（モデルセット？）を足したり消したりできると嬉しそう
1つのモデルセットは1つのmetasと対応
「用意されてるのを全部読み込む」方法が無いと不便そう

qwerty2501 · 2022-09-17T03:00:23Z

@Hiroshiba ちょっと思ったんですが、metas関数をメンバー関数にした場合、ユーザーはどうやってコンストラクタ関数に指定するspeaker_idを知ることができるんでしょうか？

qryxip · 2022-09-17T04:31:04Z

SupportedDevicesの方なんですがSupportedDevices::get_supported_devicesがORT依存のfallibleな関数なので、どうせならfallibleな関数としてそのまま_c_apiや_python_apiに持ってくるというのはどうでしょうか? VOICEVOX_RESULT_GET_SUPPORTED_DEVICES_ERRORというのもせっかくありますし。
(_c_api側はLazy<CString>の代わりにLazy<voicevox_core::Result<CString>>の形で保持)

Hiroshiba · 2022-09-17T13:25:12Z

@Hiroshiba ちょっと思ったんですが、metas関数をメンバー関数にした場合、ユーザーはどうやってコンストラクタ関数に指定するspeaker_idを知ることができるんでしょうか？

@qwerty2501 たぶん指定する必要がないはずです。そのspeaker_idはコンストラクタ内の何に使われる想定でしょうか 👀

qwerty2501 · 2022-09-17T13:26:29Z

@Hiroshiba 一つのモデルに一つのクラスインスタンスを対応させるにはspeaker_idを受け取る必要があると思ったんですが違うのでしょうか？

Hiroshiba · 2022-09-17T14:03:07Z

ちょっと考えたのですが、確かにspeaker_id的なものをどこかで指定する必要があるなと思いました。
どちらかというと、マッピングするための情報が必要そうに感じました。

いったん整理すると、現状の実装だと

１モデルセットの中には複数のspeaker_id（＝style_id）がある
それとは別にcoreが受け取るspeaker_idがある
include_speaker_id_mapで、coreが受け取るspeaker_idをモデルが持っているspeaker_idにマッピングしている
metas.jsonで、coreが受け取るspeaker_idとその意味（話者名やスタイル名）を対応付ける

という感じですよね。これを、１モデルに１metas.jsonにしたいなと考えています。
（僕が提案している形で、ここが認識ずれに起因してそう？）

となるとどうにかしてマッピングをしないといけないのですが･･････どうしよう･･･。

qwerty2501 · 2022-09-17T14:34:08Z

@Hiroshiba このコメントで以下のコメントがあったので、インスタンスコンストラクト時にモデルを識別できる情報が必要だと考えてそれがcore側のspeaker_idであると思ってました。コンストラクト時にload_modelするべきか是非はあると思いますが私はload_modelもコンストラクト時に行うものだと思っていました。 load_model は時間がかかるため関数を分けるべきという考えもありますが。

本当は１つのモデルに１つのクラスインスタンスを対応させるのが良いのかもとちょっと思いました。

またload_model時にmetasの内容が変わるとから読み込んだmodelに関連するmetas.jsonに内容が変わると考えてました。

という感じですよね。これを、１モデルに１metas.jsonにしたいなと考えています。
（僕が提案している形で、ここが認識ずれに起因してそう？）

私も１モデルに１metas.jsonになると考えてたのでこのあたりは認識合ってそうですね。
しかしその場合上で書いたとおりmetas関数はメンバー関数になるためコンストラクト時あるいは load_model 時に渡す modelを識別できる情報が必要なのに取得する手段がなくて困ってしまうなあという感じです。

となるとどうにかしてマッピングをしないといけないのですが･･････どうしよう･･･。

これは私と同じ悩みであると思うのですがいかがでしょうか？
対応策としては全modelのmetas情報を含んだjsonを用意し、static class関数として get_all_metas_jsonといった感じでコンストラクト前にmodelを識別できる情報(speaker_id?) をユーザーが取得できるようにする必要があるかも？
そのためメンバー関数としての voicevox_core_get_metas_json 関数と static class関数としての voicevox_core_get_all_metas_json 関数を用意する必要があるかも？

qwerty2501 · 2022-09-17T14:50:26Z

あとcoreのspeaker_id、整数型だけど他のIDと区別するためにもtype aliasでいいから独自型名で提供したほうが多少はマシになるかもですね。 C API側はtype aliasなので間違えて使われてもコンパイルエラーにさせることはできないですが、Rustサイドはnew typeパターンでコンパイルエラーにさせることはできそう

Hiroshiba · 2022-09-19T12:45:33Z

ぶった切っちゃってすみません、理想と現状や、話者から声まで多段になってる構造がかなりややこしい気がしたので、いったんまずドメイン知識を整理してみました。

話者：speaker
- ≒キャラクター。
声：voice
- 話者＋スタイルごとにユニーク。
スタイル：style
- 同じ話者での違う声質を表すもの。ノーマルとかささやきとか。
モデル：model
- 複数の声で音声合成できる。
- 現状だと声は0から始まる整数（とりあえず声IDと呼称）と対応する。
- 話者やスタイルと対応関係は一切ない
  - 同じモデルに複数話者が入っていることもあるし、同一話者の別スタイルが別モデルに入っていることもある。
話者ID：speaker_id
- 話者ごとにユニークな値･･･なはずだけど、現状だと声ごとにユニークな値になっている。
- 現状だと0から始まる整数。
話者IDのマッピング：speaker_id_map
- 話者IDとモデル・声IDを対応付けるもの。
- 現状だと各モデルは0から始まる整数で管理されているので、話者ID→モデルID＋声IDになっている。
メタ情報：metas
- 話者＋スタイルを話者IDを対応付けるもの。
- プログラム内で使うことはない、実際のユーザー向けの情報。

モデルは話者やスタイルと対応関係はないこと、本来話者ユニークになるべき話者ID（speaker_id）が声ユニークになっていることがややこしさの根幹かなと思いました。

これをもとに、一旦現状の相関図みたいなのを絵があると議論しやすそうなのですが･･･なにか便利なツールはないでしょうか･･･

qwerty2501 · 2022-09-19T13:14:19Z

mermaid 記法使えるのでこれで関係性を表すのはどうでしょう？
modelを識別する整数(ID)のことを声IDとされているようですがここはシンプルにmodel IDとしたほうが伝わりやすいかもしれません。

classDiagram
Class01 <|-- AveryLongClass : Cool
Class03 *-- Class04
Class05 o-- Class06
Class07 .. Class08
Class09 --> C2 : Where am i?
Class09 --* C3
Class09 --|> Class07
Class07 : equals()
Class07 : Object[] elementData
Class01 : size()
Class01 : int chimp
Class01 : int gorilla
Class08 <--> C2: Cool label

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ LINE-ITEM : contains
    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses

Hiroshiba · 2022-09-19T13:22:45Z

サンプル図の２つ目の図が良い感じそうです。ER図、なるほど。
UML図に慣れている方いらっしゃったらおまかせしたいかもです。

modelを識別する整数(ID)のことを声IDとされているようですがここはシンプルにmodel IDとしたほうが伝わりやすいかもしれません。

ここは認識のずれがありそうです。
ちょっと書き方ややこしかったかもなのですが、モデル内には複数の声があるので、そのモデル内の声を声IDと表記してみました。

qwerty2501 · 2022-09-19T15:19:37Z

@Hiroshiba あ、model IDと声 IDは別にありましたね。

UML図に慣れている方いらっしゃったらおまかせしたいかもです。

これについて理解度の浅い人間から図を作ってしまうと間違いだらけのものができてしまいそれもとに議論してしまうと最終型の図もreviewがもれてしまい間違った形になってしまうリスクが高そうだなと感じました。現に私は理解していないわけですし。
なのでまずhihoさんからご自身が考えていることを図に落とし込む必要があるのではないでしょうか？ mermaidが書きにくいまたは書き方がわからないということであればpngでもなんでも良いので好きな形で書いていただき、その後mermaidか管理しやすい形で誰かが書くというのが安全そうに感じました

Hiroshiba · 2022-09-19T16:33:44Z

なるほどです。ちょっと頑張って図を作ってみます。

Hiroshiba · 2022-09-19T17:55:08Z

図、まとめました！！
いろいろ試行錯誤が必要そうだったので、パワポで作りました。
https://docs.google.com/presentation/d/1ltsMERyNNcuVExJZunZRTI7WsqlP4cMSfFrmhXUwjG4/edit?usp=sharing

パワポの下の方に提案の形もあります！

qwerty2501 · 2022-09-19T21:45:57Z

@Hiroshiba ありがとうございます。よくわかりました。speakerが同じでもmodelが違う場合があるんですね
1model 1クラスインスタンスについてはユーザーが理解するのは難しいかもですね。しかしパフォーマンスから考えるとやったほうが良いかもしれない。

パフォーマンスを考えると一つずつ読み込んだほうが良いですが、一方でユーザーにmodelを意識させてしまうという問題点が存在します。
modelを意識させずに1modelずつ読み込む工夫はしたほうがよいかもしれません。

またコンストラクト前にmodelを識別できる情報は必要なためやはり voicevox_core_get_all_metas_json static 関数のようんばものは必要な気がするのですがいかがでしょうか？

また最後のAPI提案についてですが質問があります。

style_idについて本当はstyle uuidが良いとしているのにintとしているのはなぜですか？
VoiceOptionsは不要だと思います。OptionsはOptionalな引数を受け取るためのものですが、synthesis APIではspeaker_id,style_idともに必須であるためそのまま引数として受け取ったほうが良いと思います。もしくはVoiceを表現したいのであれば、単純に型名をVoiceとするか。

Hiroshiba · 2022-09-19T22:07:26Z

パフォーマンスを考えると一つずつ読み込んだほうが良いですが、一方でユーザーにmodelを意識させてしまうという問題点が存在します。

たしかに仰るとおりで、提案APIではモデルを読み込んだ後の扱いを考えていませんでした･･･｡

またコンストラクト前にmodelを識別できる情報は必要なためやはり voicevox_core_get_all_metas_json static 関数のようんばものは必要な気がするのですがいかがでしょうか？

コンストラクタ前にmetas情報が必要というのは同意なのですが、どうやってall_metas情報を得るのかがわからないでいます。
all_metasというと全モデルのmetas情報だと思うのですが、その「全モデル」をどうやって取得しているのかがわかっていません。
カレントディレクトリにある全てのディレクトリ直下のmetas.jsonを読み込むとか･･･？

style_idについて本当はstyle uuidが良いとしているのにintとしているのはなぜですか？

互換性維持のためです。

VoiceOptionsは不要だと思います。

なるほどです。Voice構造体、文字通り音声が入っていそうなんですよね･･･。VoiceTypeとかなら良いのですが･･･。
まあでもここは細かい箇所なので、とりあえず今議論しなくても良いかもと思いました。

Hiroshiba · 2023-01-20T07:50:53Z

新クラス設計API #370

で詳細が更に議論されています。
現状こんな感じかなというのをまとめてみます。

モデルを読み込める形にする
- モデルとは、何種類かの声で音声合成ができるファイルのこと（単体では合成不可）
- １ファイルにまとめる
- 要するに.onnxとmetas.jsonをまとめたファイル（製品版ではonnxは暗号化予定）
- Modelクラスにファイルパスを指定して読み込む
SynthesizerクラスにModelクラスを挿して音声合成できる形にする
- style_idを指定すれば、よしなに対応するModelを使って合成する
- onnxruntimeのSessionはSynthesizerクラスで持つ
未定
- モデルのバージョン違いがある場合どうするか
- モデルファイルの拡張子（候補はvvmとかssmとか）
- モデルファイルのファイル形式

Hiroshiba · 2023-01-21T10:10:11Z

モデルファイルのファイル構造についてはこちらで議論するのが良さそうでしょうか。
といってもおそらく２通りくらいかなとか考えてます。

モデルファイル・メタファイルが入ったzipにする
- 用意が簡単
- 実装はライブラリ依存
- いざというときはファイラーでzip展開するだけでデバッグできる
- ついでに圧縮もできる（ほぼ効果なかったですが）
- zipファイル特有のめんどくささはある（パス区切り文字とか、zip bombとか）
RIFF形式にする
- 実装が簡単
- 単純な機構なのでライブラリに依存しなくても実装可能
- ファイルの用意が多少面倒
- デバッグも多少面倒

個人的にはzipからバイナリを読めるようなライブラリでまあまあ良い感じのがあるなら、zip方式でいいかなと思ってます。
（エンジン側のVVPPファイルと同じ方式です）

qwerty2501 · 2023-01-21T10:29:25Z

まあzipでいいんじゃないですかね
Rust製ダウンローダーでもzipは解凍してるのでそのへんは問題ないでしょう

Hiroshiba · 2023-01-21T10:39:29Z

賛成です！
ファイル構造としてはこんな感じですかねぇ。

manifest.json 他のファイルのファイル名・バージョンなどが入ってる
　metas metas.jsonへのパス
　predict_duration モデルへのパス
　predict_intonation
　decode
　manifest_version 将来使うかも。最初はいらなそう
metas.json
各モデル.onnx
model/ モデルディレクトリ。あってもなくても良さそう

qwerty2501 · 2023-01-21T14:02:19Z

manifest.jsonとmetas.jsonって分ける必要ありますか？
また各ファイルパスについてはバージョンが同じならファイル配置固定化できるなら不要かもです

Hiroshiba · 2023-01-21T19:04:22Z

作る側的には、意味の異なる情報は分けたほうが管理しやすいので嬉しいです。
manifest.jsonは共通で、metas.jsonだけリプレイスする運用とかができます。
まあでも、どっちでも良いなら分けたいかなくらいの気持ちです。

ファイルパスに関しては拡張子が違うことを考慮してます。
こっちはonnxから別の何かに移ることもあると思うので、冗長性をもたせときたいです。

qwerty2501 · 2023-01-21T21:30:20Z

manifest.jsonは共通で、metas.jsonだけリプレイスする運用とかができます。
まあでも、どっちでも良いなら分けたいかなくらいの気持ちです。

これはスピーカーを新しく追加するときとかですか？

ファイルパスに関しては拡張子が違うことを考慮してます。
こっちはonnxから別の何かに移ることもあると思うので、冗長性をもたせときたいです。

これはmanifestにファイルパスを持たせずにmanifest_versionをもとに読み込むファイルパスを変えるでも対応できそうですがどうしましょうか？
manifest_versionは必須ではないとうことですがこれは同じvvmのスタイルが読み込まれているか判定するためのものではないということですかね

Hiroshiba · 2023-01-22T09:41:05Z

これはスピーカーを新しく追加するときとかですか？

新しくVVMを作る時とか、いっぱいあるVVMのマニフェストを刷新する時とか想像してました。
N回ファイル開いて修正して閉じてを繰り返すか、1回修正してN回コピーするか、みたいな。

これはmanifestにファイルパスを持たせずにmanifest_versionをもとに読み込むファイルパスを変えるでも対応できそうですがどうしましょうか？

確かにそうですが、ファイル名をコーディングするとテストやメンテが少し大変だったりしそうです。
あと製品版とOSS版でファイル拡張子が異なるので、２種類コードをメンテすることになって少し煩雑です。

manifest_versionは必須ではないとうことですがこれは同じvvmのスタイルが読み込まれているか判定するためのものではないということですかね

スタイルのバージョンはmetas.jsonにあるのでそっち使うことになると考えてます。
manifest_versionが必須でないのは、最初だからでした。（manifest_versionが無いというバージョンにできる）
互換性考えて、あったほうが良いと思います！

このあたりはどれもAPIには現れないことなので、そこまで議論するようなことではない気もしました…！
あまり強い反対理由がなければサッと決めても良いかも？

qwerty2501 · 2023-01-22T13:42:40Z

運用のことを考えると分けたほうが良さそうですね
styleごとにバージョンをもつのかなと思ってますが、これはVVMに更新が入るとmetas.json中のバージョンが全て更新されるということでしょうか？

Hiroshiba · 2023-01-22T23:30:28Z

ですです、基本的に同一VVM内のスタイルのバージョンが全部上がる感じです。
であればVVMのバージョンでも良い気もしますが、まあ過去との互換性のためスタイルごとにバージョン振る形でまあ良いかなぁ…。

refs VOICEVOX#280

qryxip · 2023-05-13T13:52:55Z

#370 の"vvm-async-api"についてのタスクリストを作ってみました。

追記: #497に移動しました。

qryxip · 2023-05-13T13:58:27Z

↑このタスクリストですが、#370 マージ後にすぐmain ← vvm-async-apiのdraft PRを作ってしまって、そこにぶら下げるのはどうでしょうか? (ここにあると埋もれて探すのが面倒になりそうに感じました)

Hiroshiba · 2023-05-16T13:56:47Z

なるほどです、良いと思います！！
コンフリクトが解消し次第すぐマージしましょう！

Hiroshiba · 2023-05-20T16:11:57Z

@qryxip vvm-async-apiという名前だとブランチprotectにちょっと不便なので、project-vvm-async-apiというブランチ名に変更しました。
プロテクションもかけちゃおうと思います。

qryxip · 2023-06-06T14:33:11Z

そういえばpredict_duration/predict_intonation/decodeですが、ユーザーはあまり使わないと思うのでperform_predict_durationみたいな名前にした上でドキュメントにはlow-level/internalだということを書いておくのはどうでしょうか?

qryxip · 2023-06-06T14:35:57Z

あ、そういえばproject-vvm-async-apiだと3つとも既に消滅していますね。すみません忘れて下さい。

This was referenced Sep 14, 2022

metasとsupported_devicesの改善を行った #274

Closed

C APIの関数でinitializeが必要なのか不要なのかドキュメントに書いてほしい #276

Closed

Hiroshiba mentioned this issue Jan 20, 2023

Rustから直接VOICEVOX Coreを使いたい #388

Open

qwerty2501 added a commit to qwerty2501/voicevox_core that referenced this issue Jan 30, 2023

新クラス設計を元にしたAPIたたき

878b882

refs VOICEVOX#280

qwerty2501 added a commit to qwerty2501/voicevox_core that referenced this issue Feb 20, 2023

新クラス設計を元にしたAPIたたき

341b8b9

refs VOICEVOX#280

qwerty2501 added a commit to qwerty2501/voicevox_core that referenced this issue Feb 23, 2023

新クラス設計を元にしたAPIたたき

dd2bc51

refs VOICEVOX#280

qwerty2501 added a commit to qwerty2501/voicevox_core that referenced this issue Mar 6, 2023

新クラス設計を元にしたAPIたたき

2a72875

refs VOICEVOX#280

qwerty2501 added a commit to qwerty2501/voicevox_core that referenced this issue Mar 7, 2023

新クラス設計を元にしたAPIたたき

61babf8

refs VOICEVOX#280

qwerty2501 added a commit to qwerty2501/voicevox_core that referenced this issue Mar 8, 2023

新クラス設計を元にしたAPIたたき

8906f5a

refs VOICEVOX#280

Hiroshiba mentioned this issue Mar 15, 2023

音声ライブラリを同梱しない提案 VOICEVOX/voicevox#1251

Closed

y-chan mentioned this issue Mar 17, 2023

テキスト音声合成ライブラリの作成 VOICEVOX/voicevox_project#1

Closed

y-chan mentioned this issue Apr 15, 2023

モデル構造変更(フレームレベルピッチの調整可能化)に伴うバージョン・エディション管理に関する議論 VOICEVOX/voicevox_project#26

Open

Hiroshiba mentioned this issue Apr 15, 2023

VOICEVOXにおける各ドメイン用語の定義書制作がしたい VOICEVOX/voicevox_project#27

Open

This was referenced May 22, 2023

project-vvm-async-api #497

Merged

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

Merged

Hiroshiba closed this as completed in #497 Jul 22, 2023

voicevox_coreのクラス設計discussion #280

voicevox_coreのクラス設計discussion #280

Comments

qwerty2501 commented Sep 14, 2022 • edited Loading

内容

その他

shigobu commented Sep 15, 2022

sevenc-nanashi commented Sep 15, 2022

qwerty2501 commented Sep 15, 2022

Hiroshiba commented Sep 15, 2022

qwerty2501 commented Sep 15, 2022

qryxip commented Sep 15, 2022 • edited Loading

qwerty2501 commented Sep 15, 2022

Hiroshiba commented Sep 15, 2022

qwerty2501 commented Sep 16, 2022 • edited Loading

qryxip commented Sep 16, 2022 • edited Loading

Hiroshiba commented Sep 16, 2022 • edited Loading

qwerty2501 commented Sep 16, 2022

Hiroshiba commented Sep 16, 2022

qwerty2501 commented Sep 17, 2022 • edited Loading

qryxip commented Sep 17, 2022 • edited Loading

Hiroshiba commented Sep 17, 2022

qwerty2501 commented Sep 17, 2022

Hiroshiba commented Sep 17, 2022

qwerty2501 commented Sep 17, 2022 • edited Loading

qwerty2501 commented Sep 17, 2022

Hiroshiba commented Sep 19, 2022 • edited Loading

qwerty2501 commented Sep 19, 2022

Hiroshiba commented Sep 19, 2022 • edited Loading

qwerty2501 commented Sep 19, 2022 • edited Loading

Hiroshiba commented Sep 19, 2022

Hiroshiba commented Sep 19, 2022

qwerty2501 commented Sep 19, 2022

Hiroshiba commented Sep 19, 2022 • edited Loading

Hiroshiba commented Jan 20, 2023

Hiroshiba commented Jan 21, 2023 • edited Loading

qwerty2501 commented Jan 21, 2023

Hiroshiba commented Jan 21, 2023

qwerty2501 commented Jan 21, 2023

Hiroshiba commented Jan 21, 2023

qwerty2501 commented Jan 21, 2023

Hiroshiba commented Jan 22, 2023 • edited Loading

qwerty2501 commented Jan 22, 2023

Hiroshiba commented Jan 22, 2023

qryxip commented May 13, 2023 • edited Loading

qryxip commented May 13, 2023 • edited Loading

Hiroshiba commented May 16, 2023

Hiroshiba commented May 20, 2023

qryxip commented Jun 6, 2023 • edited Loading

qryxip commented Jun 6, 2023

qwerty2501 commented Sep 14, 2022 •

edited

Loading

qryxip commented Sep 15, 2022 •

edited

Loading

qwerty2501 commented Sep 16, 2022 •

edited

Loading

qryxip commented Sep 16, 2022 •

edited

Loading

Hiroshiba commented Sep 16, 2022 •

edited

Loading

qwerty2501 commented Sep 17, 2022 •

edited

Loading

qryxip commented Sep 17, 2022 •

edited

Loading

qwerty2501 commented Sep 17, 2022 •

edited

Loading

Hiroshiba commented Sep 19, 2022 •

edited

Loading

Hiroshiba commented Sep 19, 2022 •

edited

Loading

qwerty2501 commented Sep 19, 2022 •

edited

Loading

Hiroshiba commented Sep 19, 2022 •

edited

Loading

Hiroshiba commented Jan 21, 2023 •

edited

Loading

Hiroshiba commented Jan 22, 2023 •

edited

Loading

qryxip commented May 13, 2023 •

edited

Loading

qryxip commented May 13, 2023 •

edited

Loading

qryxip commented Jun 6, 2023 •

edited

Loading