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

別キャラクターのエンジンを用意する #237

Closed
shirowanisan opened this issue Dec 19, 2021 · 23 comments
Closed

別キャラクターのエンジンを用意する #237

shirowanisan opened this issue Dec 19, 2021 · 23 comments
Assignees

Comments

@shirowanisan
Copy link
Contributor

shirowanisan commented Dec 19, 2021

内容

複数のエンジンで音声合成できるようにするために
「別キャラクターのエンジンを用意する」

関連
VOICEVOX/voicevox#429

要件

  • voicevox_engineとは別のエンジンを用意する
  • 別エンジンの要件
    • インターフェースはvoicevox_engineと共通である
    • voicevox_engineとは違うport番号で起動する
    • voicevox_engineとは違うspeaker_infoを持つ

結論

以下を満たすビルド済みパッケージを用意すれば良さそう。

  • voicevox_engine公式とは違うspeaker_infoフォルダを持つ
  • 公式とは違うport番号を持つ
  • engineはmockで良い

実現方法

以下のビルドをGithub Actionsに追加して、擬似サードパーティ製エンジンをGithub Releaseに含める。

  • サードパーティ製にみたてたエンジンをビルド
    • voicevox_engine公式とは違うspeaker_infoフォルダを持つ
    • 公式とは違うport番号を持つ
    • engineはmock

VOICEVOXのバージョン

0.9.0や0.10.0で追加したいマイルストーンです。

@Hiroshiba
Copy link
Member

良さそうです!! assignさせていただきました!

たしかにmockで良さそうですが、個人的には本番同等の機能を持ったCOEIROINKエンジンを作って頂くというのが良いのかなと感じています。
理由の1つは、将来的に作ることになるのであれば今作ると総合的に工数減りそうだからです。
もう1つの理由は、実際に音声合成できると開発のテンションが桁違いに上がるためです。

もちろんmockでも全く問題ないと思います!

@shirowanisan
Copy link
Contributor Author

shirowanisan commented Dec 19, 2021

@Hiroshiba
アサインありがとうございます!

個人的には本番同等の機能を持ったCOEIROINKエンジンを作って頂くというのが良いのかなと感じています。

こちら全然問題ありませんが「COEIROINKエンジン = espnetエンジン」なので以前以下のようなお話をしていたような。
COEIROINKエンジンを実装すると、公式的にespnetエンジンをサポートすることになりそう?

VOICEVOXの目的はユーザー数の最大化なのですが(まだドキュメントに書けてない)、音声ライブラリを気軽に足せるのは必ずしも良い方向に働くとは限らないと考えています。
まずは憧れを醸成してブランディングをしっかりしないと、なんか微妙みたいな抜けられない溝にハマり続けるかなと思っています。
なのでVOICEVOX的には、簡単に誰でもコアが作れる状態は、ブランドのコントロールが全くできなくなるので、意図的に避けるつもりです。(サードパーティならもちろんOK)(いまのところ)

すでに私のgitで「COEIROINKエンジン(espnetエンジン)」があるので、それを見れば誰でもvoicevoxで動くespnetモデルをCOEIROINKのように公開できる状態ではありますが、COEIROINKエンジンの実装方針に関して相談させてくださいー。

=======================================

  1. shirowanisamレポジトリでCOEIROINKエンジンモジュールを作り、サードパーティテスト用のビルドをするときにとってくる

メリット:

  • voicevox公式としてespnetエンジンをサポートしなくてよい。
  • voicevox公式としては、簡単に誰でもコアが作れる状態にはしていない。

デメリット:

  • shirowanisanレポジトリに依存する

=======================================

  1. voicevox_engineでCOEIROINKエンジン(espnetエンジン)モジュールを作りサードパーティテスト用のビルドをするときはCOEIROINKエンジンでビルドする

メリット:

  • サードパーティ用のビルドの管理をvoicevox_engineレポジトリ内で完結する(COEIROINKモデルのダウンロードは発生する)

デメリット:

  • voicevox公式としてespnetエンジンをサポートすることになる。
  • espnetを使えれば、簡単に誰でもコアを作れる。

=======================================

  1. mockでサードパーティテスト用のビルドをする

メリット:

  • サードパーティ用のビルドの管理をvoicevox_engineレポジトリ内で完結する

デメリット:

  • 実際のサードパーティ音声合成を開発中に体験できない

=======================================

理由の1つは、将来的に作ることになるのであれば今作ると総合的に工数減りそうだからです。

これはCOEIROINKに限ると自分の工数しか変わらない?のでお気になさらず。

@Hiroshiba
Copy link
Member

ニュアンスとしては1が近いイメージでした!
でもたしかに、サードパーティ用のテストエンジンが実際にサードパーティにあると、エディタの開発が大変そうですね…。

なので、3でも良いかなと思いました!
engineのGithub Actionsにmockエンジンビルド用のコードを実装する感じでしょうか👀

@shirowanisan
Copy link
Contributor Author

なので、3でも良いかなと思いました!

了解です!

engineのGithub Actionsにmockエンジンビルド用のコードを実装する感じでしょうか

そうですね。あまりGithub Actionsは詳しくないのですが、
以下のビルドをGithub Actionsに追加して、擬似サードパーティ製エンジンをGithub Releaseに含めるのが良いのではと思いました。

  • サードパーティ製にみたてたエンジンをビルド
    • voicevox_engine公式とは違うspeaker_infoフォルダを持つ
    • 公式とは違うport番号を持つ
    • engineはmock

@Hiroshiba
Copy link
Member

はい、そちらの流れで良いかなと思います!
たしかvoicevox_engineは何もしなければmock用の画像が用いられるはずなので、そちらが利用できるかもです。

@amamama
Copy link
Contributor

amamama commented Dec 19, 2021

このissueに関しての質問なのですが,ここに書いて大丈夫でしょうか

私は最近VOICEVOXを知ったためこれまで音声合成ソフトを触ったことがなく,またpython関連の知識も殆どない状態なので,頓珍漢なことを質問していたら訂正してください.

現状,voicevoxのエンジンはサーバ機能とTTS機能が別れておらず( #119 (comment) ),このissueはサーバ機能も合わせてサードパーティ製のエンジンを実装しようとしているように思えます.
質問は,何故このような決定を下したのか,すなわち,何故サードパーティ製エンジンにサーバ機能とTTS機能を同梱させるような判断をしたのか( VOICEVOX/voicevox#429 (comment) ) です.
これはpythonを知らない私の妄想になるのですが,インターフェースが共通ならサーバ部は既存のengineを流用し,engineで使用するTTS機能のみのpythonライブラリ(のようなもの?)をプラグインとして開発し,voicevox_engineに追加するような設計もありなのでは?と考えています.もし以前にこのようなことを検討したことがあり,Pros/Consが書いてあるリンクなどがございましたらご教示いただけますと幸いです.今,私の頭は完全に「プラグイン派」に偏っているのでバイアスなしにこの選択の良い箇所を知りたいと思っています.

サーバ機能とTTS機能を同梱させることの問題点として,

  • 公式とは違うport番号を持つ2つのサードパーティ製エンジンを同時に利用しようとした場合,開発者が安易なポート番号を使用すると(50022,50023など)衝突してしまう可能性があります.
    対策として設定ファイルなどでポート番号を指定するといった方法でこれは解決できますが

    • 更なるサードパーティ製エンジンを導入する場合は新しいポート番号が被っているかを確認しなければならない
    • 設定ファイルを共有しようと思ったときに共有先のvoicevox使用者が別のサードパーティ製エンジンを使用していてそのポート番号と被る可能性がある

    などといった問題があるため,この解決策はあまり良いとは言えないと考えています.これが些細な問題かどうかは主観によると思いますが,私は無視すべきではないと考えています,

つまり,上記のような決定をしたからにはこれらを軽微なデメリットと考えているか,これを上回るメリットが有るはずであり,それを聞きたい,というのが私の質問です.
長文失礼いたしました.

@Hiroshiba
Copy link
Member

Hiroshiba commented Dec 19, 2021

@amamama 理由は色々ありますが、現状の実装から工数最小で実装できるというのが大きいです。
頂いた質問はとてもおもしろい内容だとは思うのですが、このissueに直接関係がないので、続きは新しくissueを作成してください!

@amamama
Copy link
Contributor

amamama commented Dec 19, 2021

@Hiroshiba 返信ありがとうございます.理解しました.

@Hiroshiba
Copy link
Member

@shirowanisan こちらどうでしょう・・・?👀

@shirowanisan
Copy link
Contributor Author

@Hiroshiba すみません。年末年始にあまり時間が取れず遅れています。
今週中にプルリク作成いたしますmm

@shirowanisan
Copy link
Contributor Author

@Hiroshiba
すみません。Githubアクションに擬似サードパーティ製エンジンを含める構想をしました。

  • voicevox_engine公式とは違うspeaker_infoフォルダを持つ
    • githubアクションのincludeを増やし、ifでspeaker_infoの差し替えをしないようにする
  • 公式とは違うport番号を持つ
    • defaultのportをenv.ymalのようなものから読み込むようにする
    • githubアクションのincludeを増やし、ifでenv.ymalのportを書き換える
  • engineはmockにする
    • githubアクションのincludeを増やし、ifでcoreを入れないようにする

これにより、mac-cpu-mock, windows-cpu-mock, linux-cpu-mockのような新たなビルドがリリースにできあがるイメージです。

しかし、今思うと当初はCOEIROINKエンジンでサードパーティテストをしたいモチベーションでやっていましたが、mockの場合は、わざわざ作成せずとも良いのではと思いました。

run.exeにport引数を与えることで違うportで起動できるのため、これをサードパーティ制と見立てた方が、github actionやreleseページが綺麗なのではと考えた次第です。

// 50021で起動。
.\run.exe 

// 50022で起動。サードパーティ制に見立てる。
.\run.exe --port 50022

VOICEVOX起動時にバックグランドで「サードパーティrun.exe」を自動で起動するような形を実装するならば、「mock-engine」が必要になる可能性もあります。
しかし、現状の設計では、VOICEVOXフォルダ内に「サードパーティのrun.exeを含んだ全てのファイル」を含めるのは、パッケージの重複などにより難しいように思います。
そこで、「VOICEVOXのenvの設定にサードパーティhost, port」を追加したあと、「COEIORINKonVOICEVOX.exe」や「サードパーティrun.exe」を起動している状態で、「VOICEVOX.exe」を起動してもらうのが現実的かと思いました。

以上の理由で、.\run.exe --port 50022をサードパーティ制に見立てるので十分に思いますが、どうでしょうか。

@Hiroshiba
Copy link
Member

なるほどです!
個人的には、 #237 (comment) の 1(COEIROINK run.exe 作成)が最高だったのかなと思いました!

run.exeを別ポートで立ち上げても確かにデバッグできそうですが、キャラクターが全く同じなためキャラ重複が正しい挙動なのかバグ由来なのか判別できないのが課題になりそうです。
かといってたしかにmock engineを作るのは、既存のエンジンのビルド用コードと構成になじませる必要があるため手間がかかりすぎそうな気がしています。

目的をちょっと振り返ってみると、「COEIROINKエンジンをVOICEVOXからも利用できる」というのが僕個人としては一番到達したいことでした。
@shirowanisan さん自身もCOEIROINKエンジンでサードパーティテストをしたいモチベーションとのことなので近かったのかなと感じています。

となると、もう初手からCOEIROINKエンジンを作成して頂いちゃって、そのエンジンを借りてエディタ側を開発すると、楽しくて、かつゴールまでが最短なのかなと感じました。

最短だと感じている理由は、VOICEVOXエンジンとCOEIROINKエンジンの仕様違いを吸収するコードをVOICEVOXエディタ側に実装できるためです。
COEIROINKエンジンを今のVOICEVOXエディタから利用しようとすると、モーラごとの音高などの取得APIが無いという仕様違いがあると思います。
ここはVOICEVOXのエディタで吸収できるようにしたいと考えています。音高を取得できない場合は操作できないようにするロジックをエディタに実装する感じです。
実際のCOEIROINKエンジンがあれば正確かつ高速に実装できそうです。

COEIROINKは今熱くてお忙しいかもですが、いかがでしょうか・・・?👀

@shirowanisan
Copy link
Contributor Author

@Hiroshiba なるほどです。
では「擬似サードパーティ製エンジン」用意は.\run.exe --port 50022で対応できるとし、
本issueは「COEIROINKエンジンのpreview版作成」を目的とします。

具体的には
#237 (comment)
の「1」の実現を目指しますね。

まずは、私のgithubレポジトリでCOEIROINKコアモジュールを作成し、
voicevox_engineではCOEIROINKコアモジュールを取得する形にして、
voicevox_engineの改修は最小限になるようにしたいと思います。

そして、forkした私のレポジトリ「shirowanisan/voicevox_engine」のreleaseに
「COEIROINKエンジンのpreview」を置くことを目指します。

ここで、「COEIROINKエンジンのpreview」は「VOICEVOX/voicevox_engine」のreleaseにもあった方が良いでしょうか?
その場合は、「VOICEVOX/voicevox_engine」のgithub Actionを修正するプルリクを作成します。

COEIROINKは今熱くてお忙しいかもですが、いかがでしょうか・・・?

個人的には頑張りたいと思っていますが、いつも作業が遅くなってしまい申し訳ありません💦
上記の改修で問題なければ、2週間程度でやれるように頑張りたいと思います。どうかよろしくお願いします。

@Hiroshiba
Copy link
Member

ありがとうございます!!

まずは、私のgithubレポジトリでCOEIROINKコアモジュールを作成し、

了解です!
もし作成が難しそうであれば、VOICEVOX側の技術であればなんでもお答えできると思うので聞いて頂けると!

forkした私のレポジトリ「shirowanisan/voicevox_engine」のreleaseに「COEIROINKエンジンのpreview」を置くことを目指します

ゴール感一緒です!

「COEIROINKエンジンのpreview」は「VOICEVOX/voicevox_engine」のreleaseにもあった方が良いでしょうか?

こちら、意図をお聞きしたいかもです。
一応VOICEVOXの開発的には、インターネットのどこかからダウンロードできればOKなのでmustではないという感覚ですが、僕が認識できてない良さそうなことがあれば教えて頂けると・・・!

上記の改修で問題なければ、2週間程度でやれるように頑張りたいと思います。どうかよろしくお願いします。

問題なさそうです!
本当に感謝しています、なにとぞよろしくお願いします!!

@shirowanisan
Copy link
Contributor Author

「COEIROINKエンジンのpreview」は「VOICEVOX/voicevox_engine」のreleaseにもあった方が良いでしょうか?
こちら、意図をお聞きしたいかもです。

こちらはヒホさんがイメージしている形の認識を合わせたかったので、色々な可能性を確認したく、質問させていただきました。

一応VOICEVOXの開発的には、インターネットのどこかからダウンロードできればOKなのでmustではないという感覚ですが、僕が認識できてない良さそうなことがあれば教えて頂けると・・・!

こちらで認識があっているのであれば、私としても問題ありません。
では、こちらの形で進めさせていただければと思います。

私もVOICEVOXにはとても感謝していて、COEIROINKがVOICEVOXに貢献できるよう頑張りたいです。
よろしくお願いします。

@Hiroshiba
Copy link
Member

なるほどです、ありがとうございます!ぜひその形で進めて頂ければと思います。
まだまだ目標まで多くの工程がありそうですが、ぜひ完成させたいですね・・・!よろしくお願いします!

@shirowanisan
Copy link
Contributor Author

@Hiroshiba
お疲れ様です。

とりいそぎ、今のvoicevox_engineのmasterからcoeiroink_engineを作成しました。
https://github.com/shirowanisan/voicevox_engine/releases/tag/c0.2.0+v0.10.preview.0
「COEIROINK-CPU-c0.2.0+v0.10.preview.0.zip」を解凍し、「run.exe」を起動することで動作します。

一旦、coeiroink coreモジュールはbranchに直書きし、github actionもまだ対応できていません。
また、coeiroinkは今のところwindowsのみの対応となっています。
いずれ、この辺りも整備していければと思っていますが、現状の要件では「COEIROINK-CPU-c0.2.0+v0.10.preview.0.zip」で満たせているのではないかと判断しました。

その他、ご要望があれば対応します。
よろしくお願いしますmm

@Hiroshiba
Copy link
Member

@shirowanisan
ご用意頂きありがとうございます!!

現行のVOICEVOXエディタと(無理やり)結合して動かしてみました!
ちゃんと動きそうです、ありがとうございます!!

voicevox.2022-01-24.01-40-10.mp4

ちょっとまだ設計しきれてないのですが、エンジンができること・できないことをリスト化して受け取るAPIみたいなのを用意していただくかもしれません。(例えば「話速変更が可能か」とかです。)
こちらどういうリストがあると良さそうでしょうか?

あとはロゴとか、エンジンIDのAPIとかも必要になるかもです。
他にこれあったら良さそうなAPIとかありそうでしょうか・・・?

@shirowanisan
Copy link
Contributor Author

shirowanisan commented Jan 26, 2022

@Hiroshiba
エンジンを確認してくださりありがとうございます!無事に動いたみたいで安心です!

エンジンができること・できないことをリスト化して受け取るAPIみたいなのを用意していただくかもしれません。

はい、こちら問題ありません。
むしろ私としても早くVOICEVOXのプラグイン化を実現したいと思っているので、できることを協力させていただければと思います。

こちらどういうリストがあると良さそうでしょうか?

あまり新しいアイデアが出ていないかもしれませんが、ひとまずまとめてみました。

  • 下バー部分に関して、以下の対応・未対応機能(COEIROINKではアクセントはありますが)
    • アクセント
    • イントネーション
    • 長さ
  • 右ウィンドウに関して、以下の対応・未対応機能
    • 話速
    • 音高
    • 抑揚
    • 音量
    • 開始無音
    • 終了無音
  • 設定画面に関して、以下の対応・未対応機能(optional)
    • デフォルト周波数
      • どういう形がVOICEVOXと共存できるか難しいですが、COEIROINKは44.1kHzになる可能性があります

あとはロゴとか、エンジンIDのAPIとかも必要になるかもです。

こちらも問題ありません。確かにエンジンのiconなどが表示されると楽しいですね!

他にこれあったら良さそうなAPIとかありそうでしょうか・・・?

うーん、今上げたもの以上のことはすみませんがパッと思いつきませんでした。
またアイデアが出れば共有させていただければと思います。

自分は開発速度が遅くて申し訳ないのですが、voicevox_engineの追加実装が必要ならば自分も協力できると思います!
どうかよろしくお願いしますmm

@Hiroshiba
Copy link
Member

列挙ありがとうございます、参考になります!!
ちょっとリリース等で立て込んでしまっているのですが、近いうちにどういう方針にしたいか決めたいのでまた相談させてください!!

@Hiroshiba
Copy link
Member

@shirowanisan おまたせしました!!
ちょっとタスクを整理すると、こんな感じかなと思いました。

  • エンジン側に、対応しているパラメータを取得できるAPIを作る
  • エディタ側で、非対応なパラメータに合わせてUIを非表示にする
  • 「エンジンのデフォルトの周波数を使う」というオプションを追加する

ちょっと追加で相談したいのが1つあります。
非対応のパラメータに値が含まれた状態でエンジン側にデータが渡ってくるのは不都合だったりしますか?👀

例えば、話速変更に非対応なエンジンであっても、QueryのaudioSpeedに何らかの値(1.0とか2.0とか)が含まれて渡ってくる感じです。
普通の設計なら、非対応になりえるパラメータはオプショナルにしておいて、非対応の場合はnullが来るみたいなのが普通かなと思うのですが、
こうするとちょっとエディタ側にundefinedableな変数が大量発生してしまい、現状のエディタのコード(コンポーネント化が未整備)だとかなりしんどいことになりそうなんですよね。

なので一旦、非対応のパラメータであってもオプショナルにせず、実態が渡ってきてしまうようにして、エンジン側には無視していただくというのを考えているのですが、どうでしょう・・・?

@shirowanisan
Copy link
Contributor Author

@Hiroshiba

ちょっとタスクを整理すると、こんな感じかなと思いました。

はい、そちらがあるとサードパティに備わっている機能がユーザにも伝わり、サードパーティを作っている側からするとすごく助かりそうです!

非対応のパラメータに値が含まれた状態でエンジン側にデータが渡ってくるのは不都合だったりしますか?

こちら、他のサードパーティ参加者はわかりませんが、私としては、ただ使わないだけなので不都合ないです!
実装コストが高そうなのでオプショナルにする必要ないと思います。

@Hiroshiba
Copy link
Member

エンジンのプラグイン化プロジェクトを管理しているこちらのissueに上記内容を追記してみました!

ということで本issueは目的達成なのでcloseしたいと思います。
@.shirowanisan さんありがとうございました!!
引き続き良いものが作れるよう一緒に頑張れればと思っています・・・!

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

3 participants