♪6月6日に雨ざあざあ♪  っと6月ですね。パンチマインドでハッピネスに過ごして、6月の陰鬱とした雰囲気も、がんばりましょ! がんばりましょ!

つくった

VOICEROIDにスプレッドシートに書かれた内容を読み上げたり保存したりするツール を開発しました。 以前から VOICEROIDを外部から操作してVOICEROIDの操作を楽にするプログラムは開発していたのですが、とりあえず形になりました。 思えば一番最初に思い立ったのは2014年の晩秋ごろでしたかね……。

なおして

台本を字幕でAfter Effectsに入れるスクリプトとプログラム を直しました。 上のツールで使った、Googleスプレッドシートの読み込み部分が使えると思って、使いました。

ソースコード管理ぐちゃぐちゃ問題

ScenarioScripterのリポジトリがとてもカオスなことになってしまっています。 適当なタイミングでモジュールごとにリポジトリを分割するなりフォルダ構成を変更すれば何とかなったのでしょうが、それができていない状態になっています。

具体的には以下のプロジェクトが一つのソリューションに一列に並んでいます。

  • 外から流れてきたメッセージを一括で受けて、アドインに一番いいタイミングで流すControllerプロジェクト
  • アドインのインタフェースなどがぶち込まれているプロジェクト
    • CeVIOアドインのためのプロジェクト
    • VOICEROIDアドインのためのプロジェクト (↑にあるインタフェースを実装するプロジェクト)
      • C#で書かれた、↑に書かれたプロジェクトと、↓に書かれたC++/CLI混合プロジェクトを浄化してつなぐプロジェクト
      • C++/CLIで書かれたWin32を駆使してボイロとお話しするプロジェクト
    • Wavファイルを扱うためのアドインプロジェクト
  • コントローラをREST API化してローカルネット上で使えるようにするプロジェクト
    • ↑のViewとなるプロジェクト
  • CUIでControllerを殴るプロジェクト
  • ScenarioScripterのライブラリプロジェクト
    • ↑のUIを作るプロジェクト
  • 上にあるプロジェクトの一部で使われるUtilityクラスをまとめたプロジェクト(解体中)
    • ↑のテスト
  • コントローラをサービス化して、常駐化するプロジェクト
  • 上にあるあれやこれをまとめてテストするプロジェクト

さらに別ソリューションにもカオスにいろいろ詰まっていって

  • AfterEffectsと連携するためのプログラムのランチャー
    • ↑のプログラム本体
      • ↑のランチャー
    • ↑のプログラムで使われるパーサー
  • ScenarioScripter本体
    • ScenarioScripterのExcel接続用プロジェクト
    • 同様にGoogle Spreadsheet用
    • 同UI
      • 同ランチャー

……と、めちゃくちゃなことになっています。これだけのプロジェクトをたった2つのリポジトリで管理しているんだから、 そりゃコミットログもぐちゃぐちゃになるわといった感じです。 また、プロジェクト名もちょこまかと変わっているので、それを格納するフォルダ名も不一致な状態になっていて、 久々に修正をかけようとすると、とりあえず混乱するところから始まります。 こんなのVCSじゃないわ! ログのついたファイルサーバよ!

とりあえずこいつらを細かい単位のリポジトリにぶった切って、サブリポジトリとかにして、小さい修正をしやすい状態にしたいです……。 NuGet化することで、プロジェクト間の依存は、かなり減らすことができたので、分解しやすい状態にはなったけれども……。 NuGet化、アドイン化する前の、プロジェクトを参照して利用してた時代の依存関係からすると、かなりすっきりしました。 小さい単位に区切ることができれば、ITSでのバグ管理も多少は楽になるのでしょうか……。 リポジトリを機能単位で小さく分割する → そもそもリポジトリが違うので機能ごとにコミットせざるを得なくなる → 巨大なコミットが潰せる → GitをGitらしく使えることが期待される ……?

わざわざランチャーを作っているのは、zipを展開した時に一番上にあるexeをクリックすればプログラムが動くというわかりやすさと、 binにdllをぶちまけて、zip展開直後のフォルダを見かけさっぱりさせるのが目的です。

VSでコードメイトリックスメトリックスを計算させたくても、なぜかエラーを吐いてメトリックスが計算できないという……。 いつ測ったか忘れましたが、前に測った結果だとSLOC1万行前後に、保守容易性インデックスが30切ってた気がします。やばい。 変更なんてこわくねぇ!!


デレステスクショ読み取り機をいい加減更新しないとなぁと思いつつも、 アイドルさんがバンバン増え、ホワイトリストが長くなるにつれて誤認識が多くなることを考えると、さぁどうしようと頭を悩ませています。 順当にいけば、デレステで使われてるフォントに似たフォントを使ってOCRの学習データを生み出して、それで認識させると、ある程度はマシになりそうですが……。

画面解像度16:9しか受け付けない問題や、GUIがいまだにない問題、これからアイドルさんが増えると更新が手間になる問題など、課題は山積みですね……。

妄言: ステータス画面を録った動画から自動でスクショを切り出すプログラムがあれば、スクショ更新作業が楽になりそうですが、mp4かぁ……、といろいろ頭を抱えてしまいますね。 動画をフレームで切り出して、がくしゅうそうちに食わせて、スクショっぽいか、スクショっぽくないかを判断させるとできそうですが、この上なくめんどくさそうです。

まずはデレステを再開するところから……。


ユーザが実際に利用する機能の8割は2割のコードで実現できる(だっけ?)という格言(だっけ?)が身に染みる現在です。