暇なので進捗報告

今日，12時ぐらいに起きて駅前の銀行で口座を開くつもりが，11時間も寝てしまったらしく著しく暇です．寝なければ起きる時間帯がずれるなんてことは幻想だった……．早めに口座を開かないと銀行振込で家賃を払わなきゃならず，コストが増えるばかりなのでどうにかしたい．

メインバンクは一応，地方銀行を使っていて，どうしても地方銀行だと色々と対応が悪いんですね……．かと言って，メインバンクを都市銀行に変えるのはなかなか手間のかかることで，クレジットカードとかでも色々と申請しなきゃならないので面倒くさいです．個人的には，もう少し地方銀行も日光が当たってくれるといいなぁとか思います．

そういうわけで，昨日は入試の後あたりにDanbooruの奴でEXIFにタグ情報を追加できるようにしました．Mini ExifToolというgemを使う予定だったのですが，内部的な文字エンコードに殺されてしまったので，Mini ExifToolが依存しているExiftoolというものを使ってみました．

ExifToolは，いわゆるEXIFの情報を見たり編集したりするためのツールで，基本的にコマンドラインからしか実行できないUNIXライクなCUIのシステムです．使い方はそれほど難しくはないです．おかげさまで，ExifToolを使ってからは速攻で実装することができました．

ちなみに，実装するまではUTF-8をなんとかUTF-16（UCS-2）に変換する方法に殴られてました．前に，UTF-8をUTF-16に変換する何かを作ったような気がしたのですが，さすがにそれをRubyで再実装するのは気が引けたので，なんとかライブラリの力に頼ろうと，IconvとかNKFだとかで頑張ってましたが無理でした（）　NKFのコマンドを呼び出せば直接変換できるのですが，RubyでNKFを呼びだそうとすると内部的にストップがかかってしまい手も足も出ません（）

そういうわけで，Danbooruのほうは，まずはということでタグから画像をクロールし，タグ付けする，というのを実装しようかなと思います．その次は，既にあるEXIFの付いていない画像をDanbooruで検索し，タグ付けすることをやろうかなと．ここまでやって実用的ですね．

ギターのMIDI変換の方ですが，Macとはいえども，マイクのAD変換がダメダメなようで，レイテンシが0.5〜0.8秒ぐらいあるんじゃないかと思うぐらい遅いです．

想定ユーザは基本的にDAWとかでDTMやってる人だと思うので，みんなDACぐらい持ってるだろという気持ちでASIOの出番です．

ASIOと言えば，高速なオーディオバッファを提供するためのドライバです．通常のオーディオバッファだとOSの低速なハードウェアやらソフトウェアやらドライバを介してしまうため，音声信号が対象のソフトウェアに届くまでのレイテンシが大きいです．このせいで，ギターを弾いてもいっこく堂のように遅れて聞こえてしまったり，変なノイズが走ってしまいます．

ASIOに対応したソフトウェアがあると，この音声信号の入出力を高速でできるようになります．ノイズも入らないし一石二鳥みたいな感じです．

そういうわけで，つい先ほどASIOのSDKをダウンロードしました．ASIOのSDKについて調べてみると，評価が軒並みサンプルコードらしいです．delete忘れたり，グローバル変数をゴリゴリ使っていたり，C言語とC++を足したような感じだったりと，評価がかなり酷いです．試しに中を覗いてみたのですが，まあWindowsAPIを使っているのでしょうがないなって感じでしょうか．

いや，でもdelete忘れはないだろ……とか思ってしまう次第で．このままSDKを使うとメモリリークが酷い可能性があるので，このASIOを使うためのサンプルコードを解析してモダンなC++に書き換えてしまおうとか思っています．そもそもの目的はどこ行ったって感じですが……．

最終的には，VSTプラグインにしたいと思っているので，このへんは避けて通れない道なんだろうとは思いますが，まあ頑張ってみることにします……．

（それか，もうこの辺は妥協することにして，ちゃっちゃと本体を作ってしまったほうがいいかもしれませんが．いずれにせよ，2日か3日ぐらい悩んでみることにします）

MMD Transporterのほうは，そろそろミクさんを作り始めてもいいんじゃないかな，って思うようになりました．今回はもっとポリゴン数少なくして作りやすくしようかなと……．

特に，Blend Shapeはポリゴン数多すぎてとても40個も表情を作れるような設計になってなかったので，これはちょっと反省したいなと．Subdivisionの結果はSmoothなんだから，Smoothかけていいだろとか甘いこと考えてたら案の定って感じでしょうか．

なので，今回はミクさんを作るとき，可能な限りローポリで作れるようにしようかなと思ってます．あと，ローポリってこともあるので，もしかするとAOマップで乗算する方法はうまくいかないような気がしています．汚い結果が出ることを考慮して，Mudboxで着色することも視野に入れようかなと．学生ならではのリッチな戦法でいきます．

あとは，テクスチャの書き方講座みたいなものを一生懸命見ながらって感じでしょうか……．

で，どうしてミクさん作らなきゃならないかというと，デザイナーさんが自由にモデリングしてセットアップした場合，Mayaはリニア編集の概念が抜けてないので，多種多様なトポロジのモデルデータが作られてしまいます．これはデザイナーさんごとに癖が異なるので，結局のところ万人のデザイナーごとにカスタムエクスポータを提供するなんてことになってしまうからです．

FBXなんてそうですよね．ツールごとの互換性のなさは，ツールに依存する部分もありますが，ツールごとに決められたワークフローで出力しないと失敗するわけです．

そうじゃなくて，ある程度コンテンツパイプラインとかワークフローをツールとして提供しないと，正確にデータを出力するということが難しくなってしまいます．

それに，MMDは一応付与ボーンでリグの概念を再現してるので，これを正確に出力するには，リガーごとの癖を吸収するようなコードを書かないとなりません．A社専用みたいな感じであればまだ簡単ですが，世界中を相手にすると莫大な量になるわけです．剛体ももちろん同じ話になります．

じゃあ，そういう自由さを犠牲にする代わりに，誰でも確実に出力させましょう，というのがMMD Transporterのコンセプトです．FBXの反省ですね．

もちろん，ワークフローを最適化するためのツールも付けようかな思います．Mayaのアセットの使い方がまだわかってないので，この辺はもう少し勉強する必要があるかもしれませんが．キャラクターについても使うか使わないかは少し迷います．ただ出力するためだけなのか，それともそれなりに実用的にMayaで使えるようなものなのかで，かなり設計は変わってくるんじゃないかなって思います．

どうでもいいのですが，ドクターの学費を引いて，あと10ヶ月ぐらいで残り予算が干上がりそうです．しばらく電子ピアノを買うのは控えたほうがいいかもしれません．部屋も片付いていませんし（）