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

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

Open
45 of 69 tasks
qryxip opened this issue Jul 22, 2023 · 38 comments
Open
45 of 69 tasks

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

qryxip opened this issue Jul 22, 2023 · 38 comments

Comments

@qryxip
Copy link
Member

qryxip commented Jul 22, 2023

内容

VOICEVOX COREのバージョン0.15をリリースするにあたってのタスクリストをここにまとめます。

Pros 良くなる点

changelogを書くために、一度ここにまとめていこうと思います。

  • APIが更新されます。
    • Python APIでは主要なAPiがasync化します。C APIでも並列実行をサポートする予定です。
    • 音声モデルはVVMファイルという形で扱われ、それらを実行時に明示的に読む形式となります。
    • その他諸々の改善/変更があります。
  • ONNX Runtimeのバージョンが上がります。

Cons 悪くなる点

  • APIに破壊的変更があります。

実現方法

タスクリストは随時更新します。

タスクリスト (オプショナル)

  • 以前のAPIをdeprecatedなものとして残す
    • C API
    • Python API

VOICEVOXのバージョン

N/A

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

  • Windows
  • macOS
  • Linux

その他

@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 22, 2023

[議論]となっているいくつかはこちらのコメントで少し議論が進んでいるのでメモ。
#497 (comment)
#497 (comment)

@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 22, 2023

exampleの案内もタスクに含めておくと良いのかなとちょっと思いました!
と思ったけどもうexampleは完成している・・・?

@Hiroshiba
Copy link
Member

Hiroshiba commented Jul 22, 2023

メモです!
inference_corestatusはやっているがかなり似ているので、どっちかに統一できると良さそうに感じました。
まあリリースまでにやるべきか微妙ですが、例えばタスクリストに書いておくのはいいかも?

- [ ] \[議論\] `inference_core`と`status`の役割が似ているのでどちらかに統一する?

開発者向けに、VVMのマニフェストの構造に関してのメモがどこかにあると良いなと感じました。

- [ ] VVMのマニフェストのデータ構造に関してメモをどこかに書く

(とりあえずissueの編集がコンフリクトすると良くないのでここにメモって書いています)


Pythonのテストを書くのもここに含めておくと良さそう?

- [ ] Pythonのe2eテストを書く

@qryxip
Copy link
Member Author

qryxip commented Jul 22, 2023

三つとも追加しました。

@Hiroshiba
Copy link
Member

追加ありがとうございます!
(editedになってない&見当たらないので、もしかしたら追加されてないかも・・・・・・?)

@qryxip
Copy link
Member Author

qryxip commented Jul 22, 2023

あ、確定してませんでした...

@Hiroshiba
Copy link
Member

実際に製品版のVVMを作ろうとしていたのですが、以前できていたことができなくなっていることに気づきました。
ということでissue立ててみました。時間ある時にやっておこうかなと思います。

マニフェストファイルって本来、対象がどういう情報を持っているかを外向けに公開するものな気がしてきました。バージョンとか名前とか。
だからどちらかというとmetas.jsonの方がマニフェストっぽくて、今manifest.jsonとなっているものはなんか別のものな気がしました。
時間あったらこの辺整理してもいいかもですね。。

@Hiroshiba
Copy link
Member

製品版のvvmファイルを作成したので共有です!
ここにあるディレクトにあるvvmファイルが読めるはずです。
https://github.com/VOICEVOX/voicevox_fat_resource/tree/main/core/model

このvvmを読めるコアをプレビュービルド中です。
https://github.com/VOICEVOX/voicevox_core/releases/tag/0.15.0-preview.5

@Hiroshiba
Copy link
Member

Hiroshiba commented Jan 10, 2025

downloderがVVMを持ってくるべきか、持ってくるとしてどうするかを議論するためのissueを作ってみました!
(Githubにsub issue機能があったので使ってみようかなと)

(後から探そうとしたとき用の検索用単語: ダウンローダー download )

@Hiroshiba
Copy link
Member

@qryxip さんと話して、

は対応しないことに決めました!
チェンジログとマイグレーションガイドを書かないということになります。
(マイグレーションガイドはリリース後に書いてもいいかも。要望次第?)

ということで後のタスクはサブタスクにちょくちょくなってる細々としたやつだけかも!!

@Hiroshiba
Copy link
Member

ダウンローダーがダウンロードするものを現状でレビューしてみました!
課題があったものはsub issue化しました!
課題がないと判断した点をメモコメント残しておきます。

  • ディレクトリ名がインターフェース名なのかインスタンス名なのか不揃い
    • 具体的に言うとonnxruntimeだけ具体的なライブラリ名で、他はc_api/dict/modelsと抽象的な名前になってる
    • そもそも抽象的な名前に寄せたい
      • voicevox_coreと書いてその中にMITライセンス文面があると、コア全部がMITだと勘違いされる可能性があるため
    • とはいえonnxruntimeディレクトリをどうすればいいのか思いつかない
    • なのでonnxruntimeだけ具体的なライブラリ名になってるという例外を設けたということでよさそう
    • まあどっちかというとライブラリの中でvoicevox_coreだけ例外という見方の方がいいかも。現状不明。
  • dictディレクトリだけ略称になってる
    • まあ衝突とか特にないし別に良さそう
    • どっちかというと「dictionary」の方が良さそうではある
  • dictディレクトリに、openjtalkの辞書のディレクトリだけが入ってる
    • データ構造だけ見ると不要なディレクトリになってはいる
    • けどディレクトリ名がないとこれが何なのかわかんないので、ディレクトリをかませても良さそう!
    • 可能ならバージョン名などが入らないディレクトリ名にしておくと、バージョンが上がってもexampleなどを変えなくて良いのでメンテナンス性が良い
      • 今はopen_jtalk_dic_utf_8-1.11みたいになってる、たぶん_dic_utf_8-1.11が要らなそう。
        • dicもdictディレクトリからわかるので
  • onnxruntimeディレクトリはいくつか課題がありそう
    • ORTという略称はおそらく避けた方が良さそう
    • ORT_LICENSEはvoicevox_onnxruntimeにとってどっちかって言うとサードパーティーなのでそっちに書いた方が良さそう
    • ORT_READMEは中で「このプロジェクトは MIT です」と書いているので、voicevox_onnxruntimeの規約と背反しそう
    • ただこれらはVOICEOVX COREに関係ないのでissue化は必要なさそう

@Hiroshiba
Copy link
Member

残ってるタスクについて、0.16時点での変更はマストではないけど、ちょっと考えたのでメモ:

OpenJtalkにすべきかOpenjtalkにすべきかについて、多分将来的に増えていったら「頭だけ大文字」という規則になる気がする。
ChatGPTとかTensorRTとかどうするのか考えるのめんどくさそう。
逆にものすごい長いのが来たら途中で大文字にしたくなるけど、そういうものはないような気もしました。
とはいえ今マストで変えなくても良さそう。将来何か増えた時に破壊的に変更するか考えれば良さそう!

@Hiroshiba
Copy link
Member

Hiroshiba commented Feb 5, 2025

Pythonのドキュメントを眺めてみました!
マストだと感じたタスクはなさそうだったので、issue化してません 🙏
提案が2つと、感想が2つ!

  • 提案
    • Synthesizerのcloseの説明があると良いかも
    • 非同期APIの説明が「非同期API」だけだけど、音声合成部分が並列に複数実行されないこともあると案内しても良いのかも。
    • でも条件がややこしいので一旦何も書かなくてもいいのかも。
  • ただのコメント
    • replace_phoneme_lengthが破壊的置き換えじゃないのはちょっと一般的じゃないかも。
      • でもまあ良い名前思いつかないし、これで良さそう!
      • あとPythonのstr.replaceとかも破壊的な置き換えじゃない。
    • ユーザー辞書は保存されているので、過去のバージョンのものが読み込めるように作る必要がありそう。
      • あとちなみにエンジンと互換性はなさそう(エンジンはMecabの型がほぼそのまま)。
      • まあ問題なさそう!

@qryxip
Copy link
Member Author

qryxip commented Feb 9, 2025

Javaについても0.15.0-preview.16時点で既にあったと思うので、これもスキップするのは厳しそうに思えます。

ちょっとこれについて詳しく議論していなかったと思います。ユーザーの皆様方が一年前の時点でVVMという存在を割とご存知であったことを考えると、ちょっとこれを無視するのは厳しいのではないかと思いました。

私からの提案としては、Android用Javaのリリースを一旦停止するというのはどうでしょうか?つまりこうです。
[追記] こっちじゃなくてsoftprops/action-gh-releaseの方だった。

diff --git a/.github/workflows/build_and_deploy.yml b/.github/workflows/build_and_deploy.yml
index c91dd4be..3a2b9f5e 100644
--- a/.github/workflows/build_and_deploy.yml
+++ b/.github/workflows/build_and_deploy.yml
@@ -270,7 +270,7 @@ jobs:
             ${{ steps.build-voicevox-core-python-api.outputs.whl }}
           target_commitish: ${{ github.sha }}
       - name: Upload voicevox_core_java_api artifact
-        if: fromJson(needs.config.outputs.deploy) && contains(matrix.target, 'android')
+        if: fromJson(needs.config.outputs.deploy) && contains(matrix.target, 'android') && false
         uses: actions/upload-artifact@v4
         with:
           name: voicevox_core_java_api-${{ matrix.artifact_name }}

JavaはRustと違ってcargo add --git https://github.com/VOICEVOX/voicevox_core.git --tag 0.16.0みたいなことはできないはずなので、これで「Javaはリリースしていない」ことにできるかと思います。

0.15.0-preview.16のJavaなんか誰も使っていなかったというのであればよし。そうでなければそのときはそのときで、 #764 のあたりで復活させるということで。

@Hiroshiba
Copy link
Member

まあたしかにリリースしてないものとするのは難しいかもですねぇ…。
かといって隠すのも工数がかかる…。(あとexampleがある?)

このままビルドしたのが表に出ちゃうけどスルーして破壊的変更した0.17をしれっと出すか、
表に出た0.16java版はサポートしてないけど出して0.17アプデのときに破壊的変更点を列挙するか、
提案にある通りアップロードから外してexampleは「準備中です」みたいにするか、
ですかねぇ…。

外すのもありだと思いますが、他の案だと難しそうでしょうか?
難しそうであれば外しちゃいましょう…!!

@qryxip
Copy link
Member Author

qryxip commented Feb 9, 2025

リリースするんだったら #991#994 みたいなやつは織り込んでおきたいです。織り込むリソースがもう無いのであれば、 #994 の有様を見ても他に色々ありそうなので、バッサリ外してしまうのがいいのではないかと思ってます。

「Java APIをリリースする」みたいなissue立てて #764 のリンクを載せ、 #984 みたいなやつをsub issueにし、そのissue URLを各所に貼るのがよいかなと。

@Hiroshiba
Copy link
Member

Hiroshiba commented Feb 9, 2025

他に何も追加するものがなくなった(=0.16がリリース可能になった)ときにできる限りのことはできればと思います!

すみません勘違いしました!
javaを織り込むリソースは0.16にない、と考えて良いと思います!

qryxip added a commit that referenced this issue Feb 15, 2025
#872 をやった理由は互換性の確保であるが、よく考えたらそれは #941 で達成
できており、むしろ`pause_length: ()`みたいなことをしてしまったために互換
性の邪魔になっている。さらに#872でやっている百数行のコードは、実際に
VOICEVOX/voicevox_engine#1308 をやるときには用済みとなるようなものである
ため、丸ごとリバートしてしまうことにした。

Refs: #545
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants