ブログ書くの忘れてたので適当に書きたいことを書く
特に何か変わったわけでもないので適当に．なんかこういうこと多い．
ギターのベース音を検出する実験はとても良好で，3種類のギターを使って単音の場合は98%，和音の場合は95%以上の確率で検出できることがわかりました．検出率の低下は概ね弾弦したときの速度が足りずに，弦に触れている時間が長いからなんじゃないかなと．
これぐらいの検出精度なので，とりあえず論文誌に投稿出来そうだなということと，検証を全部やろうとすると，和音の方まで手が出そうにないので，ベース音検出を一生懸命やることになるんだなぁというところ．実験もまだ残ってるし，ひたすら弾くだけなのでいい加減指が疲れた．マメがやばい．
システムがメモリを適当に確保して，一斉に開放する処理が入るみたいで，一時的に処理落ちすることがあってつらい．全然わからない．実験をやる上ではそんなに困ることはないけれども．
最近，8月に備えて微妙に空いている時間を使いながら新しいことやってる．今までは，FBXなり，PMDなり，PMXなり，OBJなり，Colladaなり，既存のフォーマットに依存していて，それぞれのフォーマットに互換性がないところがネックだった．FBXのライセンスも泥沼っぽい．Mayaでモデリングして，それら公開用のデータを作ると，必ず何かで再生できないから困る．
ならば，一つのフォーマットに一極集中させてしまえば，あらゆるフォーマットで互換性維持できるし，DCCツール側での実装も1つのフォーマットだけでやればいい，って話になるので，例えば今まではUnityでPMD，PMX等々の実装が必要で，個々のフォーマットの定義が必要だったけれども，1つのフォーマットに一極集中させることで，Unityでも，UEでも1つのフォーマットの実装で，様々なフォーマットに対応できるようになる．
当然，色々な言語で書かなきゃならなくて，そうなると滅茶苦茶面倒くさいことになるだろうなぁと思い，あらゆるコードをJSONで書いておいて，あとでJSONを各種言語にコンパイルし直す，みたいなことをやってる．
スクエニのスクストで，JSONか何かを使ってコード生成をしていたのを思い出して，こういう作り方ももしかしてできるんじゃないかなぁとか思った．
でも，12月の論文誌に間に合うかなぁというところがむしろヤバそう．別にこういう実装は，何かを明らかにしているわけではないので，アンケート調査とかそういうのが必要になりそうで困る．こういう時は，ソースコードの量で比較する方法，実装時間が短縮されるならその時間で比較する方法などなどあるけれども，精度を計測したりする系より難易度が高い．
そう言えば，7月4日にGame Community Summit 2015で発表します．
FBX色々問題あるよねー，ということで，じゃあどんな方法があるのか議論します．この辺りはデベロッパ各社が独自のデータフォーマット用意してるのかなぁ，とCEDECの過去の発表思い返すわけですが，下請けの納品でFBX使ったりすると，ツールが違うときに限ってうまくいかない，というのをちらほら聞きます．このデータ抜けちゃうんだけど……というパターンもあったりして，かなり地獄な感じなので，回避する方法を考えたいなぁということで，こんなセッションになりました．
何書こうと思ったのか忘れた……．
