還暦から始める萌え仕事

  デモで作ったポップコーンは、曲がオリジナルじゃないのと、背景にレゴの絵を使ってるんで、誰かにツッコマれると悔しいかなと思い、完全に権利がこちらにある曲を作る事に… 　レゴの背景は、ほとんどデファクトスタンダード的な気もしますけどね。 　まあそう言う事で、今年の１月に HTC vive で身体のモーションを取ってあった、ショパンの子犬のワルツのデータに、Leapmotion で指の動きを追加して、もう一つデモを作っておく事にしました。 　背景の方は、水辺の森とかかな？って思ってます！

 　背景も入れたバージョン完成。まあ、大体こんな感じでいいかな…

 　建物の外に木や池を設置しようとしてます。 　こないだも書いたけど、やっぱり水の揺れ表現のデータを追加すると、突如として重くなる～！ 　最終的には１フレームずつ書き出すから良いけど、やっぱ高速 PC でやりたいもんです。 　というわけで、窓の外に木と水を足した状態…

 　レゴのセットは完成。 　この後、天井をくっつけて、大きな窓の外には森や池や滝をセットする予定です。 　結構楽しくなってきた！ 　セットのスクリーンショット色々…

 　unity のアセットストアで背景に使える、結構実写っぽい素材を購入。 　レゴの背景と別バージョンで実写っぽいバージョンもいいかなあ？と思ったんだけど、これがまた、物凄い容量！ 　何度やっても unity がクラッシュしてしまう。スタジオの PC 使えば、容量とかもっとデカいのがあるんだけど、面倒なので、とりあえずレゴバージョンだけを完成させる事にしました。 　という事で、現在レゴ版背景の窓部分を検討中。枠組みだけをレゴで作り、ガラス部分は unity の素材で行ってみたらどうかと考えてます。

 　レゴの背景のセットを unity に移し替えるの完了！ 　全体に６角形の部屋にして４面がレゴ、残り２面にこれから大きな窓を追加予定。 　部屋、広すぎるかなあ？

 　前に作ったレゴの背景セットを並べてみて、ちょっとピアノとフミカを置いてみました。 　ちょ～っとゴチャゴチャするかなあと思い、色を整理して、もう少し単純化しようと思いました。

  昨日書いたように一昨年作ったレゴの背景を　unity に移し替えてます。 　ヘンテコの手順を踏むんだけど、順番を間違えなければ、結構簡単に変換可能。 　ただ広いサロンみたいなデザインだけど「広いサロンってピアノに対して、どのくらい大きいの？」と、部屋とピアノの縮尺率が分からん！ 　というわけで、適当な縮尺で配置して試してます。

 　演奏モーションの作成に関しては、なんとかなりそうな感じなので、次に演奏するステージというか、部屋を作ろうと思ってます。 　最終的にはCGと実写とトリック撮影を組み合わせたいけど、とりあえずはCGのみって事で… 　実は一昨年、一時的に出資者がいた時に、プログラムと 3D モデリングは専門家に任せて、私はそれが完成したら、映像を作ろうと思って、３Dモデルの為の背景の部屋データをレゴのデジタルデザイナーっていう、レゴ３DCGプログラムで組んでたんですよ。 　なので、今回はそれを使えるっていう。というか専門家に任せた分は全滅だったから、最初から製作費は全部私が貰ってチマチマ作り続けてた方が良かったという話もあったりして。 　まあ、文句を言っててもしょうがないので、とにかくレゴの背景はこんな感じ！

 　昨日書いた、鍵盤の色が変わるシカケが、データを記録した後で、プログラムを停止するとピンクになっちゃう件、専門家に相談してみました。 　そしたら、どうも unity 側の問題らしい説が…メモリー上に呼び込まれたデータが正しくデータとして残ってなくて消えちゃうみたいです。 　なので、専門家さんのアドバイスを受けて、色の変化は RGB + alpha チャンネルに分解して指定する事にしました。 　今のプログラムは「右手の親指で弾いた色はこの色に…」、みたいなテーブルが作ってあるので、そのテーブルに指定した色のマテリアルを RBG 値に変換するプログラムを書きゃいいんだな。 　やっぱ専門家に相談してみるもんです。 　だけど、今回は関係ないけど、例えば弾いてない鍵盤は豹柄で、弾いた鍵盤は花柄とかやりたい時はどうするんだろう？まあ、今んとこそういう予定はないから考えないどこう！

　一日更新が抜けてしまった！ 　昼間、買い物に出たら凄い雨で、家に帰ったら疲れてて更新を忘れました！ 　で、取り込みのタイミング合わせは上手く行きました。単に 60fps で取るだけだった（笑）。 　ただし、プログラムがショボいため、早い動きをすると取りこぼしがあるため、完成してるシーケンスを半速に落として、じっくり取り込んだ後で、取り込んだデータを倍速で再生するとタイミングも合うし、取りこぼれもないので OK！ 　だけど、今度は取り込んだ鍵盤の色がピンク色に…これはシェーダーのエラーが出た時に起こる色です。不思議な事にプログラムを動かしてる状態で、記録した色の変化を再生するとうまく行くのに、プログラムを１度でも止めてから再生すると、色がピンクになってしまふ… 　これもしかして、押した鍵盤の色が変更された時にインスタンス化されてないのが原因か？？？え～と、こういう場合どうすんだっけな…という所で力尽きた…

  波のプラグインのテストで、海上で波に揺られながらピアノを弾くバージョンを作ってみました。 　取り込みは、まだタイミングが合ってないので、最適値にする方法を探します！

  フミカのモーション取り込みは、昨日の方法で上手く行きそう。 　次にピアノをやってみたら、色々問題が… 　ピアノは鍵盤が動くだけだと味気ないので、弾いた鍵盤とその両隣の鍵盤の色が変わるようにしてます。この色の変化も unity recorder で取る場合には、MeshRenderer も取るようにすると、レンダリングする色の情報を記録できるんだけど、これが重い！っつ〜か動いてないのでは？という状態になります。 　どうもヒエラルキーで指定するとダメみたい。そこで、取り込みたい鍵盤を１０個くらいずつのグループに分けて、これのレンダリングデータを拾うようにすると、上手く行きました！ 　この後、フミカとピアノ全体の動きを取り込んでテストしてみます〜！

  フミカのピアノ演奏モーションだけど、元々は凄く軽くなるように作ってあって、少ししかない動きのポイントを IK を使って自動的に体全体に反映させてます。 　だけど、unity recorder は、それによって作られた全ての骨格の動きに、髪の毛の動きまで取り込もうとするので大変な事になっちゃってるんじゃないか？という考えに到達。 　そこで、記録を体全体なんて横着しないで、必要な動きのリグだけを指定して記録する作戦にしてみようと準備中。感触は、結構いい感じ！ 　unity recorder も、ヒエラルキー上にいる全ての動きを指定しつつ、その中から除外するリグが設定できると便利そうなんですけどね。

 Unity recoder にピアノ演奏のモーションを記録すると、１分半くらいでも、300Mbを超すサイズに〜！ 　一応、圧縮モードで書き出してるんだが… しかもサイズがデカいと再生もモッサリして使えん！ 　データを見ると、髪の毛の動きとかまで律義に拾ってるんで、モーション記録用に、いらないデータをカットした　３D モデルを作るか、下位ヒエラルキーを記録させるのはやめて、欲しいポイントのデータだけを、延々と指定して、記録するか… でもその場合、ちゃんと各々のデータはシンクするんだろうか？ 　悩みは尽きませんな。

  Unity で、フミカの演奏するピアノの周りに、エフェクトをかけて遊んでます。 　MacPro だと、軽快に動くみたい。とりあえず、海のエフェクトとか入れると、海上や海底の雰囲気になって、眺めてると癒されて、ついつい時間を忘れてしまう… 　こないだの森と一緒に表示すると、浸水したみたいになるけど、結構綺麗。 　座標問題は、一度モーションを書き出して、そのデータで再度フミカとかを動かせば問題ないはずなので、明日やります〜！

 　シャボン玉の動画が楽しかったので、波に揺られながらピアノを弾くのを作ってみようと思ったら、座標系で思わぬ問題が… 　今回のピアノの演奏は、体がどういう位置にあっても、指先は対応するピアノの鍵盤の座標を死守するようにしようとして、指先の座標だけ絶対座標（ワールド座標）にしちゃってたんですよ。 　ピアノの座標が固定されてる場合は問題なかったんだけど、ピアノ自体が波に揺られるような映像にしようとすると、鍵盤の座標が波で上下に揺れるわけです。 　そうすると、指先はピアノの鍵盤じゃなくて、画面上の絶対座標を死守するようになっちゃってるんで、ピアノが波で上に動くと、指先だけは同じ座標をキープしちゃうんで、手だけが元の場所においてけぼりを喰うという… 　簡単に修正できると思ったら、結構難しくて、指先が鍵盤にめり込まないようにするために、コライダーだの重力だのを使ってるんで、小手先の修正をすると、どんどんとドツボにハマって行く事が判明。 　う～む、どうしたものか…

 　と、タイトルの通りです。 　まあ、最初から水のシミュレーションは要素が多いから重いだろうとは思ってたんですけどね。 　試しにスタジオで使ってる MacPro で走らせてみたら、結構軽い気がする…かなり古い MacPro なんだけど、GPU とか GTX970 とか乗ってるせいか？ 　一応、軽そうな水の素材も手に入れたんで、この辺も試してみます。 　にしても、素材添付のデモシーンで、物体が水に飛び込んで沈んだ後、急に水中から何かに跳ね返されて空にすっ飛んで行く挙動をするんですけど…　重力の設定が変なのかなあ？？？

  　こないだの演奏モーションにシャボン玉を足してみました。結構楽しい！（音なしですけど） 　色んな効果を足して遊んでみよう！ 　カメラの移動やズームを含めた背景を iClone で作って、そのカメラの動きを unity に持って行って、unity が得意な分野は unity で合成ってのもありかも！

  Unity Recorder は、記録するだけなら結構簡単に設定できました。 　だけどやっぱりタイミングはズレるっぽい。遅れるならわかるけど、走るんだよなあ．．． 　補正できるかどうか、やってみないとわかりません。 　書き出すのをやめて Unity の中で背景も入れて完結させた方がいいのか？ 　心が揺れてます。

  Unity Recorder で、ピアノの鍵盤の動きをデータとしてレコーディングしてみました。 　一応、上手く行くけど、レコーディングした後で、いちいちファイルをレガシーモードに切り替えるのがだるい！ 　まあ、録音した後でちょこっとやるだけだから、そんなに面倒ではないですが．．． 　とりあえず、midi の最高音を受けるとレコーディングを開始し、最高音の一つ下を受けるとレコーディング停止になるようなスクリプトを書いてみました。これは結構うまくいきました。 　ファイルを見てみると、タイミングが微妙に遅れ気味になる気が．．．全体に均等に送れるんなら、再生速度を調整してつじつま合わせをすればいいんで、その辺を確認中。 　まあ、多少のズレには目をつぶるとして、そのズレがPCの処理能力のせいなのか？とか明日検証してみます。

  Unity の動きをキャプチャーするのに、Unity Recorder なるユーティリティがあるはずなんだけど、アセットストアでは削除されましたって出て、説明がなかったんですよ。 　なので問題あって配布中止なのかと思ってたら、そうじゃなくて Package Manager の方に移動してただけだっていう。これ知らなくて３日ほど無駄にしましたがね！ 　メニューバーの Window > Package Manager からさらに、Advance を選んで探すと出て来るっていう、ほとんど嫌がらせの世界．．． 　でも動かしてみたら、あっさり動きを読み込んでくれてます。自分で書いたスクリプトだと、イマイチだったんで嬉しい！ 　という事で、明日はこれ使って実験だ! 　しかし、こんな不親切な事やってたら、みんな Unreal Engine に行っちゃうぞ〜！Unreal Engine + Ryzen... いいかも．．．                                        

 　ピアノの鍵盤の動きを fbx フォーマットに書き出すべく、プログラミング続行中。 　大体当たりはついたので、明日には何とかしたいです！

 　　iClone でやるにしろ Unity でやるにしろ、最終的な映像を作るには、演奏モーションとピアノの鍵盤の動きをモーションデータとして書き出して作業した方が楽なはず。 　今の状態では演奏させるために、いちいち unity の受信プログラムを立ち上げ、さらに送信側の Mac の Logic を立ち上げて midi データを転送しなきゃいけないわけです。 　なので、受信プログラムが midi を受けて、フミカがピアノを演奏したら、その動きの全てを単純なモーションデータに変換して CG のプログラムで使うようにしようというわけ。 　という事で、unity でモーションの書き出しプログラム制作に挑戦中。人の形をした humanoid タイプの 3D データは Easy Motion Recorder ってソフトでなんとかなりそうなんだけど、ピアノは無理なんで、自主的にプログラムを作る事にしました。 　以前は unity に unity recorder ってのがあったらしいんだけど、なぜか今はダウンできません。方法はあるみたいなんだけど、自分でプログラム書いちゃった方がいいかな？とか思って、挑戦してます。

 　ピアノ演奏の背景は、透明感のある森とか水とか、そういうのをメインに持ってきたいと思ってます。 　で、iClone とか MMD とか Unity の背景アセットを比べてみると、iClone のマーケットプレイスにある素材は暗いのばっかなんすよね。 　abandon ナントカみたいに、廃墟の学校とか、廃墟の図書館みたのが多いです。なんかマイナー SF 同人誌か？みたいな… 　一番突き抜けて明るいのが MMD、次が Unity でしょうか？恐らく MMD はアニメっぽい作り方の素材が多いので、現実の背景より色の抜けがいいとか、そんな感じじゃないか？と思ってます。 　まあ、Unity の素材とか iClone にインポートするとか、方法は色々考えられると思うんで、あれこれ素材を探してみようと思ってます。MMD の素材は、流用すると問題起こったりしそうだから、使わないですけどね（でも MMD の素材が一番愛がこもってると思うんだが）。

 　演奏モーションの動画は、ほぼ取り込むことができたので、これに演出を加えた最終的な動画を、どうやって作るか検討。 　一昨日アップした動画も背景に森の絵は入ってるんですが、もっとちゃんとしたのにしたいわけです。 　理想は、フミカがロジャー・ディーンみたいな世界でピアノを弾いてる図。ロジャー・ディーンはイエスとかのアルバムジャケットを描いてる人で、Amiga のゲームパッケージのデザインなんかもやってます。 　で、この最終的な動画を作るためのツールとして、unity 上で作るか、iClone で作るか、悩んでます。 　いずれにしてもフミカとピアノの動きをデータとして書き出しておいた方が良いので、まずはフミカの動きを Easy Motion Recorder ってソフトでデータ化してみようと思ってます。

 　ちょうど、テストの動画が完成した所で、タイミング良く、新 LeapMotion が出ました！ 　まだ、本格的な販売じゃない感じだけど、手に入れる事はできるらしいです。今回のモデルでは、指の取得範囲が８５ｃｍと広くなってるので、２台使えば、８８鍵のピアノ全域をカバーできそう！ 　普通の曲なら１台でも十分音域がカバーできそうです。 　現在の LeapMotion だと、２オクターブ半くらい、安全に使える範囲として１オクターブ半くらいを想定してて、７台の LeapMotion をプログラムで切り替えながら使う事を考えてたんで、新しいのが出て、かなり便利になりそうです！ 　とりあえず、誰か人身御供の様子を見てですね！

 　もう SNS の方で告知しちゃいましたけど、動画はこれです！

  Unity の地形アセットを使って、背景入りデモ完成。 　フミカの演奏モーションのサイズは、fbx からコンバートしたグランドピアノを元に作ったら、このグランドピアノのサイズが、unity の基準と違ってたんで、背景の地形アセットに対して、物凄く小さくなってしまった！ 　「な〜んか、サイズ違うな」とは薄々気づいてたんだけど、自分をだまして作業してたら、ここに来て一気に問題が… 　地形アセットのサイズを変えるだけだと、草や木のサイズが変わらず、小さくした地形に、樹木がギュウギュウ詰めに… 　どうも unity は大量の樹木データの物理処理を軽くするために、この辺に制約を入れてるみたい。 　散々いじって、解決策を発見！本日は、ここで力尽きたので、公開用ビデオの作成は明日に〜❗️

 　鍵盤を押すと、その位置と周辺のキーの色が変わるプログラム完成！ 　最初、指毎に色が変わるようにしたんだけど、ゴチャゴチャしてチープになっちゃう気がするんで、右手と左手の２色だけとか、色の組み合わせをセレクトできるようにしてみました。 　やろうと思えば、ベロシティによって色の具合が変わるとかもできるけど、やり過ぎても誰も気が付かないでしょうね！ 　ただ、テンポの遅い曲なんかでは有効かもしれないんで、今後必要を感じたら修正しましょう。 　で、パーティクルも入れようかと思ったんだけど、ますますゴチャゴチャしちゃいそうなので、とりあえず置いといて、背景を入れてみようかと思ってます。 　なんか重くなりそうだけど…

 　押した鍵盤の色が変わるギミック作成中。 　例によって unity は一度インスタンスがどうのこうの、ってあるので、ついつい鍵盤に対してダイレクトにカラーコマンドを指定したくなっちゃうんだけど、それやるとエラーです。っていうか、そういうコマンド無いし… 　ネットの情報を参照しながら、キーのテクスチャーを変更して色を変えるようにしてみました。 　簡単な実験動画をば…

  ギミックとして、弾いた鍵盤の色が変わると綺麗かな？と思いプログラム検討中。 　単純に色を変えるだけなら簡単なんだけど、鍵盤が元々使ってたテクスチャとの兼ね合いを、どう考えるのが良いか、良く分からないので 検討中です！

　体の動きもついたポップコーンが完成！ 　VRM で、目の瞬きが認識されなくて、ほとんど半日潰れました！ 　なぜか MacBookAir に入れてある Windows で走らせると上手く行くという謎の現象… 　でも、まあなんとかなったので安心。次は鍵盤のギミックとかを作ります～！  

  演奏モーションのプログラムが、大体完成！ 　体の動きも大体再現できました。ただ、体の動きを取り込んだ時、右肩の座標データを取り損なってて、右肩が位置固定状態。でも、他が動いてると、気になりませんでした。 　というわけで、動きのデータを微調整して、明日アップしたいと思います。 　その後、鍵盤の色が変わるギミックと、背景の景色を足したら、関係者に見てもらおうと思います！

  画面上で動く動画サンプルはスクリーンレコードってソフトで取り込んでたんですけど、取り込み範囲が広いとコマ落ちがひどくなるので、話題の激安 hdmi 画面キャプチャーユニットを買いました。 　hdmi のパススルーが付いてると、いきなり値段が上がるので、パススルーなしの安いのと、hdmi の分岐ボックスを買いました。 　両方で２５００円くらい、果たして使えるのか？！ 　昔、mac II の 640x480 の画面信号を普通のテレビやビデオに出力するボードが、150万円もしたのが夢のようです！

 　今年の一月に取り込んだポップコーン演奏の体の動きデータを、なんの変換もなしに、現在のプログラムで走らせてみたら、首が後ろに回って、エクソシスト状態になりました。 　取り込みデータを正しいリグへの配置と正しい分解能で読み取れるようにプログラムの見直しをします～！ 　で、エクソシスト状態のフミカ（笑）

 　修正プログラムを完成させたので、midi シーケンサーからモデルの動きをコントロールしてる演奏動画のテストを作ってみました。 　これで、明日からは以前撮った体の動きのデータをくっ付けると、演奏してる風になるはずなんだけど、問題は体のデータのフォーマットを、今のモデルの動きのフォーマットに変換するのがうまく行くかどうかですね。 　で、動画…（今、見たら微妙に音と絵がずれてますが、これは blogger 側のシステムの問題）

 　指の動きのデータをさらに修正中。 　あれこれ試しながらやってるので、結構時間がかかってますが、慣れれば早くなるでしょう。 　明日には、なんとか両手の演奏を公開できればと思ってます！

 　修正用のプログラムが出来たので、試してたら、コントロールの番号を間違えてて、一部修正！ 　midi のデータ類は、最低値を１としてるわけで、例えば midi チャンネルの一番下はチャンネル１、コントローラーも一番若い番号は１番なんだけど、プログラムの内部的には、１番は０番として処理してるわけです。 　ここを勘違いすると、チャンネルやコントローラーの割り振りが一つずつ、ずれてっちゃうわけで、midi チャンネルの指定は間違えてなかったんだけど、コントローラーの指定を、間違えて０番から指定しちゃってたんで、修正データ作ってたらヘンテコな動きに！ 　というわけで、正しい値にデバッグして、一段落。再度データを作り出してみると、数値が上がったら音域も上がるとか、統一してないと、修正しにくいと気づいたんで、明日、ちょいと修正してみましょう。 　まあ、単にプラスマイナスを入れ替えるだけなんだけど、その部分の修正データは、もう一度作り直さねば…

　手のひらの位置や角度を midi コントロールで微調整するプログラム完成！ 　これで明日、ポップコーンの後半部分も作ってみましょう！ 　だいぶ見えて来た！

 　指の位置の微調整を midi のコントロールからやる部分は完成。 　今度は、手のひらの位置データの微調整部分を書いてます。これが出来たら、今年の頭に作った頭や肩の位置の動きのデータを、はめ込んでみて、体全体で演奏してるようにする予定。 　そこまで行ったら、ちょっと鍵盤とかにシカケをしつつ、背景に木とかのデータを入れてカッコ良くしたいなあ、と思ってます。 　森のある街のデータは iClone にあるんで、これの unity へのエクスポートライセンスを買って、unity 内で完結できるかどうかテストしたひ。 　そこまでやると、動きが重くなるかなあ、とも思ってます。これはプログラム上の解決策は分かってるんだけど、作業がめんどくさくてやってないんですが、根本的に速い PC があれば、そのまま行けたりして… 　そこで気になるのが、やっぱ Ryzen 9 とかのプロセッサーですよねえ。私の周りではまだ、いじってる人がいないんだけど、インテルに脅威を与えてる Ryzen…　使ってみたい！

  演奏モーションの指や体の位置を微調整するデータのテーブルを作成中。 　こないだも書いたように、これが物凄く大変です。でもなんとか… 　モーションの微調整ツールが出来たら、演出用プログラムを書いて、それを使って人に見せられるようなデモを作って、関係者に見てもらうつもりです。 　ようやくここまで来た！

 指や体の位置を修正するテーブル作成中。 　基本的な動きは、細かく指定できるように、分解能が高いピッチベンドのデータを使い、修正には、分解能の低いコントロールデータを使ってます。 　ピッチベンドは分解能が高い代わりに、1つのポートで１６個しか使えず、コントロールは分解能が低い代わりに１つのポートに１６x１２０個使えます。 　でも midi 2.0 が普及すれば、こんな事考えずに、もっと高い分解能で沢山のチャンネルが使える事になるわけで、悩ましい問題です。 　ところで、テーブルプログラムを作ってたら、なんかいらない条件分岐が所々にあったりして、こういうのも削除してます。たぶん、初期に実験するのに、特定の条件で作動させるようなテストをしてた時の名残りが残っちゃってるんだろうな…

 　指の位置や、手のひらの角度とかを補正するため、LeapMotion のキャプチャーとは別に、シーケンサーでコントロールできるようにテーブルを作ってるんだけど、これが頭こんがらがって大混乱です。 　指や手のひらのパラメーターは、場所によって角度データを使ったりポジションデータを使ったりしてるんで、それをちゃんと整理してテーブル化しないといけないし、使う場所によって変化させる数値の幅が違うんで、これもテーブルに入れるべきか？とか考え出すと、話がどんどん複雑になってしまう。 　どうまとめたらいいか、悩んで１日がたってしまいました。 　明日はなんとかカタをつけたいです！

 　プログラムは大体出そろったので、Popcorn の前半部分を演奏させてみました。 　まあ、色々文句はあるかもしれなけど、結構いい感じかと思ってます！

 　こないだ amazon Fire TV を入れたんだけど、プライムで見られるビデオに「のだめカンタービレ」のアニメ版があったので見てみました。 　で、この中のピアノを弾くシーンでも、やはり演奏してない状態の手の指はピアノの鍵盤の上に軽く乗せる状態で待機してるように描かれてました。 　という事で、待機中の指は、できるだけ鍵盤の上に乗せておきたいんだけど、LeapMotion や、モーショントラッキングデバイスでは鍵盤上に指がいるかどうか？の決定的なパラメータはないわけなんで、この辺はある程度妥協するしかないです。 　ただし、予算をかければ、鍵盤上の指の位置情報を拾い出せる midi インターフェイスがあるんで、まあ将来的には、この辺を完璧にしよう！という事で、現時点では、今の状況で進めたいと思います。

 　相変わらず、指の形を良い感じに持ってくのに微調整をしてます。 　演奏データの指の動きを見てて分かったのは、指が演奏待機状態の時、多くのケースで指は鍵盤上に置いている事。 　LeapMotion でトラッキングした指のデータだけだと、どうしても鍵盤から指が浮いてしまうので、指がある程度鍵盤に近くなったら、重力をオンにして、指が鍵盤の上に軟着陸するように設定したいんだけど、どうも、重力の設定がうまく行かん… 　プログラム的には合ってるんだけど、どうも動きがハッキリしないです。 　もう少し頑張ってみよう…

 　動きを確認するのに、さらに MacBookAir の core i7 を Boot Camp の Windows で動かしてテストする事に。 　速度の速いマシンでないと、指の動きが揺れるのが、プログラム上の問題なのか、PC の処理が遅いために起こっているのかが判断できないためです。 　プログラム上では、指の位置を常に監視して、微調整してるんで、指定した座標を通り越した時に、正しい位置に補正したり、また通り越したり、を繰り返すわけです。 　だけど、これが物凄く小さな動きで、しかも速度が早ければ、見ため的には止まって見えるはずなんだけど、その辺が遅い PC だと判断しかねるわけです。 　という事で４台の PC に囲まれて作業中です！

  Leapmotion で、ポップコーンの演奏データをシーケンサーに取り込んで、それを再生しつつ、指の動きを見てみました。 　midi から note on が来て、鍵盤が下がり始めたら、ガッチリ指先が鍵盤にロックしないと、フラフラして不自然に見えるので、その辺のプログラムを精査してみようと思います。