search

VOICEVOX / voicevox_core

無料で使える中品質なテキスト読み上げソフトウェア、VOICEVOXのコア
https://voicevox.hiroshiba.jp/
MIT License
866 stars 117 forks source link

`kana: bool`をやめ、"_from_kana"を復活させる #577

Closed qryxip closed 1 year ago

qryxip commented 1 year ago

内容

経緯: https://discord.com/channels/879570910208733277/893889888208977960/1123249926143475722

関連 Issue

ref #545

その他

このPRはCおよびPythonのAPIを破壊的に変更します。 (追記) あとJavaも

Hiroshiba commented 1 year ago

ここら辺の辺りに関して、実装が振動しないようにするために議論をコピーしておこうと思います！

結論としては

--- qryxip — 2023/06/27 22:54 COREの0.13→0.14でtts_from_kana()がtts(kana=True)のようになりましたが、今からでもfrom_kanaを復活させるのはどうか、というのを考え始めてます。 なんというか、ユーザー視点でも[string, boolean]というよりは{ japaneseText: string; } | { kana: string; }を投げている感じの方が理解しやすいんじゃないかとドキュメントを書き始めて思ってきました。あと「Open JTalk抜きのSynthesizer」の挙動も説明しやすくなるんじゃないかと思っています。 追加の利点としてC APIのAudioQueryOptionsとAccentPhrasesOptions (↓)を消滅させられると思います。 ```rs typedef struct VoicevoxAudioQueryOptions { bool kana; } VoicevoxAudioQueryOptions; typedef struct VoicevoxAccentPhrasesOptions { bool kana; } VoicevoxAccentPhrasesOptions; ``` --- ヒホ — 2023/06/28 00:22 正直ユーザー目線だとそっちのが良いとは思います！！ 開発目線だとまあ今からわざわざ変えなくても良いかも、とも思います。。。 * オプション消える代わりにfrom_kana用関数が３つ増える * ドキュメントもほぼ同じ説明を３回書くことになる 「Open JTalk抜きのSynthesizer」の挙動の説明はどこ変わるのか気になります。 API周りだけ考えると、ライブラリ利用者視点ではkanaの扱いが明確なので１００点中プラス２～３点、ライブラリ開発視点だとメンテナンス対象が倍になるのでマイナス５～６点ってところかなぁ。。（片方のAPIだけ変更してもう片方忘れちゃうとか起こる） インターフェイス周り以外の実装がどう変わるか次第！ --- qryxip — 2023/06/28 01:10 開発視点でマイナスが入るとは考えていませんでした... (むしろ実装側のことを考えてこの考えが浮かびました) ドキュメントで日本語テキストとkanaの2通りの「使い方例」を書き、「textというパラメータは何なのか」を説明し、実装もこうなっていることを考えると3×2に増やした方がすっきりすると思ってました。 https://github.com/VOICEVOX/voicevox_core/blob/00c43153d42032ad3044ebf9e780d6af5c3f2bf0/crates/voicevox_core/src/publish.rs#L197-L203 片方のAPIだけ変更してもう片方忘れる、というシナリオがすぐに思い浮かばなかったです。例えばどういうのを...? （画像） > 「Open JTalk抜きのSynthesizer」 「Open JTalk無しだと日本語のテキストは受け付けられない。つまりoptions.kana = trueでなくてはならない」→「Open JTalk抜きではこの関数は使えない」 のようにシンプルになると思いました。ただよく考えると文章量についてはあんまり変わらないかも。 --- qryxip — 2023/06/28 01:45 > インターフェイス周り以外の実装 voicevox_core#497の方に書いたようにSynthesizerをSynthesizer<()> | Synthesizer>とし、Synthesizer<()>からは_from_kanaの方のメソッドしか生えないようにすれば実装の見通しがよくなるんじゃないかと思ってます (C/Python APIの方では"OpenJTalk is missing"的なエラーを用意しておけばお茶を濁せると思います) --- ヒホ — 2023/06/28 02:15 なるほどです！！　kanaのときはOpenJTalkが要らないという認識が漏れていました。 「変更しない方がいい」から、「どっちもあり」くらいの気持ちになりました。 ドキュメントに関しては、「詳しくはこっちのAPI見てください」という手もあるかもです。 ただドキュメントは何書くかの共通認識作らないと話が合わないかもです。議論してもいいですが、とりあえずkana=Falseのドキュメント書いて共通認識作るのどうでしょう？無駄にならないはず。 > 片方のAPIだけ変更してもう片方忘れる、というシナリオ 例えばAPIドキュメントを一部コピペすると思うのですが、その修正を片方だけして片方忘れるのが怖いかなと！ ただこれは片方のドキュメントをもう片方が参照する（「詳しくはこっちのAPI見てください」）形にすれば問題ない気がしました！ あとはまあ、エンジン側と実装が乖離するのが少し気になるくらいです。 総合してどっちもありかなと！