還暦から始める萌え仕事

　小指～人差指までの４本の動きの具合は、だいたいこんな感じでしょうか？ 　動きの微調整の数値変更は midi キーボードのコントロールチェンジのボリュームを、各種要素にアサインして設定しました。 　midi キーボードのコントロールで、数値設定するルーチンは、結構便利だから、ユーティリティとして残しておこう！ 　というわけで、本日の進捗動画…

　右手の指の開き具合、閉じ具合等々を、一番見た感じよくするために最適値を探してます。 　左手が結構うまく行ったのは、LeapMotion に左手をかざしながら、右手でマウスやキーボードを操作して、数字を簡単に変えられたからなのかも… 　で、右手でも数字を簡単に調整できるようにと、midi の コントロールチェンジを使って midi キーボードのボリューム類から数値を調整できるように、プログラムに手を加えました。 　なんか数値を調整してると、突然 midi キーボードからのコントロール類を受け付けなくなるんですよ。 　midi のインプットを他の midi モニタープログラムと取り合いしてるのかも…とかって思って、散々調べてたら、そうじゃなくて、たんに midi の USB ケーブルをハブを経由して PC についでたから、読み取りが不安定になってたと判明。 　結構、いい USB ハブを使ってたから大丈夫かと思ってたら、こいつが原因でした。 　というわけで、LeapMotion に手をかざしながら、midi コントロールチェンジをグリグリ動かして、最適な状態を探している日々です。先は長いか？

　通信で手や指のデータを転送できる事は分かったので、指の動きが綺麗に行くように微調整中。 　左手は、だいたい OK なんだけど、右手の指の形がイマイチ決まらない。手を握ると、潰れたグーの形になってしまう。これを整えたいんだけど、中々うまくいかんです。 　って言うより、左手がなんで上手いこと行ってるのか謎だったりして。偶然うまいポイントを見つけられたから？？？ 　というわけで、今日はあきらめて、明日、再挑戦したいと思います。 　これからの予定は、右手の指の動きを整える事。両手の親指の動きの調整。 　まだ先は長いです～…

　こないだ出てた、両手を動かすと、指は動くけど片方の手の動きが止まるバグの原因を発見！ 　親指のパラメーターを増やしたのに、それをチェックするのを忘れてたので、トンデモナイ値のデータが入って来て、それをハネる時にタイミングがズッコケてたのと、フレームレートを落として実験してたのを、高速で動かすようにレートを上げたら、非力な Core i5 の PC でも、ちゃんと表示しました。 　ま、バグ修正した部分は、もしかしたら今後またトラブルかもしれないけど、やってる事は理解したので、対処はできるでしょう。 　というわけで、本日の結果ビデオ…

　やっぱり、早い PC で動きを確認した方がいいかいな？ってな事で、MacBook Air に BootCamp で Windows 入れてます。 　以前も入れてあったんだけど、あまり使い勝手が良くないので消しちゃってたんだけど、今回はそんな事言ってられないし。 　果たしてちゃんと使えるのか？

　昨日は LeapMotion で手の動きも取得して、受信側に送ってみたんだけど、今日、両手を送るようにしてテストしてみたら、微妙に問題が… 　片方の手の時は問題ないんだけど、両手になると、どちらか一方の手の動きが止まってしまう。ただビデオをよく見てみると、手の位置の動きは止まってるけど、指先は動いているので、何か転送のアルゴリズムに勘違いがある気がします。 　もっとも、とっても受信側に core i5 の年代物の遅い PC を使ってるのも原因の一つではあると思います。これが早ければ、つっかかりがあっても、気が付かないくらいの速度で動きを処理しちゃうかも… 　早い PC も、もう一台あるんだけど、MacPro なんで、動作音がうるさいもんで使ってないんですよね。core i5 の PC は音が静かなんで、非力だけどプログラム組んでるだけなら問題ないっていう… 　という事で、例によってビデオの左上は LeapMotion でトラッキングしてる PC、右下は、それを受信してる PC の画面です。受信側の下の赤いランプがついてるのが LAN で midi を受信してる状態のインジケーターです。

　midi 経由のトラッキングデータ転送の続き。 　まずは LeapMotion で拾った手のひらの角度と指データをまとめて転送してみました。 　まだ受信側の指の開き具合とかの数値を調整してないので、ちょっと変ではありますが。 　左側が LeapMotion で手をトラッキングしつつ、それをフミカの 3D モデルに適用して動かしている所。 　右側が、それを midi 経由で受信して、動きを再現してる所です。

　親指の位置データを細かくしたり、LeapMotion でも、手のひらの位置を取得して転送するようにしたんで、データのフォーマットの種類が増えたんだけど、それを受信する側も当然、プログラムの種類が増えるわけです。 　前は、各指に対して、for ループで順番に位置データを割り当ててたんだけど、親指だけ種類が増えたんで特例措置が必要になったり、手のひらのデータのために別途配列を準備して、それを初期化したりしてたら、整然としていたプログラムが汚くなってきた！ 　まあ、元々専門家じゃない上に、色々実験しながらプログラムを拡張してきたからコードは凄い汚い上に、さらに混乱が… 　あってると思って、プログラムを走らせてみると、配列アレイがオーバーフローしてたりして、どう始末をつけるかが悩みの種です。 　全部、特例にして if 文の嵐にしてもいいけど、それもみっともないですしねえ。 　という事で、明日こそ！

　昨日の LeapMotion のキャプチャーソフトで、フミカの手の動きをキャプチャーし、それを midi データ化して、midi Lan でもう一台の PC に転送して、受信側のフミカを動作させてみました。 　こないだ、LeapMotion の手のひらの動きとか親指の動きのデータを追加して、データの転送フォーマットを変えたのに、まだ受信側は、それにフォーマットを対応させてないので、転送はされるけど、動きはメチャメチャです。 　一応、プログラムをトレースしてみると、出力してるデータの順番はあってるはずなんで、今度は受信側のプログラムを調整して、送信側と同じような動きになるように挑戦してみたいと思います。 　というわけで、テストビデオ。 　左側が LeapMotion でトラッキングしてる PC の画面、右側がそれを受信してる PC の画面です。

　LeapMotion で指の動きと一緒に、手のひらの動きも取得するようにしました。 　昨日書いたように、手のひらは最終的には Vive トラッカーで取得する予定です。 　手のひらの位置は位置と角度の２つで取得してるんだけど、unity は、画面に表示されるデータをプログラム上で扱おうとすると、値の持ち方が違うので困ります。 　一番有名なのは角度のデータが、画面上ではオイラー角で xyz の典型的な形式なのに、プログラムしようとすると、突如として xyzw の４つになるクォータニオンの扱いになるので、これを変換するのに大混乱。たいがいの人が最初にぶつかる難関のようで、unity の質問掲示板でも必ず出て来る質問項目ですよね。 　その他にも画面上の角度は０度を中心に±１８０度で表示されるのに、プログラムで拾って確認してみると、３６０度以上の数値も出てきちゃいます。おかげで、これを監視するようにしとかないと、データがオーバーフローしちゃう事があります。 　という事で、テストしてる所の動画。

　LeapMotion で手を握ってグーの形にした時に、指の形がイマイチ揃わなかった問題を解決。 　グーにした時の親指問題は、ほぼなんとかなり、小指が内側に入り過ぎて不自然になるのも解決（したと思う）。 　LeapMotion の SDK のドキュメントを見てみたら、手を握っているかどうか？っていう判定パラメーターがあるのを発見！ 　これを使うと、手をグーに握った時の握り具合が 0-1 の間の数値で返されます。当然パーの時は 0 が返って来て、強く握るにしたがって 1 に近づいて行きます。 　というわけで、このパラメーターを使って、値が１に近くなるほど、小指の位置が少しだけ外側に出るようなバイアス設定をして解決。 　ついでに LeapMotion の手のひらの位置も取得するようにして、簡易的に手の動きを再現できるようにしときました。 　指以外の手の動きは LeapMotion じゃなくて、Vive トラッカーでトラッキングするつもりなんだけど、トラッカーとか付けるの面倒くさいので、テストする時の手の位置は LeapMotion で取得する事にしました。 　これで、いくつかの追加パラメーターの分を midi 化して出力できるように unity を修正したら、いよいよ鍵盤を弾いてるように見せられるかどうか？のテストに入ります。

　現在、右手の小指の動向を調整しています。左手は、ほぼいいかな？ 　ピアノを弾く場合、指は普通より広めにひろがった方が良いので、特に親指は人差し指に対してほぼ９０度の角度で開くようにしてます。 　指の広がり具合とかは、単純に倍率を変えれば広がり具合が変わるってわけじゃないです。パーの状態でちょうどいいようにすると、グーの時にはトンデモナイ状態になっちゃったりするんで、あっちを立てれば、こっちが立たず、みたいな感じで混乱します。 　いくつかの代表的な指の形をテーブルにして、そのテーブルの間を行ったり来たりするのがいいのかもしれないです。 　というわけで、指のテスト動画。せっかくなので、水色で表示される角度の調整曲線とかも表示させて録画してみました。

　フミカの指の認識は LeapMotion で拾って、それを Unity で Vroid の 3D モデルに変換してるわけですけど、これの親指が結構問題。 　小指、薬指、中指、人差指は、指の構造的に結構単純で指の根本は上下左右に動き、その先の関節は上下方向のみに動くんだけど、親指は動きが違うんですよ。 　自分の指を動かして眺めれば分かるんだけど、かなり複雑な動きをします。 　これを LeapMotion で拾うと、LeapMotion 付属の手だと結構うまく動いてるように見えるけど、外の 3D モデルの指に置き換えようとすると突然問題が起こります。 　それっぽい雰囲気だけだと、なんとか誤魔化せるかもしれないけど、細かい動きを再現しようとすると微妙に変！ 　例えば他の指が上下に動いてる時も、親指の座標系は XYZ の３つの軸が微妙に絡み合ってて、一筋縄ではいかない！ 　Vtuber のソフトを見てても、親指がビミョ～なのは結構多いです。色々見た中では 3Tene っていう Vtuber ソフトの親指が一番再現性が高い気がします。 　特に手をグーの状態にした時に、親指の曲げ具合が足りないと、握りこぶしから親指だけが飛び出して、ヒワイな放送禁止形態になっちゃいます。 　これ、なかなか綺麗に行かなかったんだけど、親指のみ IK の設定を２重にして、LeapMotion で拾う座標データも、指先と関節の途中の２つを拾って、IK のターゲットを２つ作るという荒業を使うと上手く行くような気がしてます。 　ただいま、その辺実験中！

　ピアノの鍵盤のコントロールは大体こんなもん？ってとこまでできたので、最終段階の手の動きを調整って思って、色々やってたら、さらに細かく調整に入ってしまい、ドツボ状態になっています。 　現在は指の動きを Leap Motion でトラッキングして、それがリアルに見えるように最適な方法を探しています。 　今年の頭の状態でも、気にせずに行っちゃっても良かったのかもしれないけど、ついついテストしてるうちに深みにハマって… 　基本的な指の形は、クラシックピアノで習うように手のひらで、卵を軽く握るようなフォームで作ってます。 　この手のひらを丸くするってのは、どうも日本のピアノ教育の呪文のような気がしなくもなくて、海外のピアニストを見ると、時々クラシックでも手を平たくして弾いてる人がいるような気がします。 　ポップス系で言うなら、オルガン系から上がって来たキーボードプレイヤーは全般的に手をひらったくして弾いてる気がする… 　たとえばキースエマーソンなんかは、結構指を平たく伸ばし気味にして演奏してると思います。 　どっちが良いか？っていうと、昔だったら卵を軽く握るフォームが圧倒的だったと思うけど、色々ビデオを見たり、演奏を聴いたりしてみると「別にどっちでもいいんでないかい？」って気がします。 　どちらかの方が、音が良いとか、速弾きに向いてるとか、色んな説があるけど、どうもただの都市伝説のような気がしなくもない… 　ただ、ピアノを弾いてる時の見た目としては、卵握りフォームの方が、カッコよく見えるように思います。 　というわけで、今日も指の形が弾いてるように見えるには、どういう unity のプログラムを書けばいいのか？奮闘中です！

　昨日の続きですが、ピアノの鍵盤の動きのシミュレートを考えた場合、鍵盤を押し込んだ時の速度と、もうひとつ、リリースベロシティ（Release Velocity）も考慮する必要があると思います。 　リリースベロシティは、その名の通り鍵盤から手を離す速さなわけですが、この値が小さいほど鍵盤からゆっくりと手を離したって事になるわけです。 　このリリースベロシティはある程度高級な midi キーボードでないと出力されないし、シーケンサー側もデフォルトでは、無視するように設定されてる事があります。 　ギターのサンプリング音源なんかで、高級なやつは、リリースベロシティを見て、カッティングの音の切れる時のノイズの出方とかをコントロールできるやつがあったような気が… 　動作としては昨日書いたベロシティの逆をやれば良いんだけど、これが結構問題発生しました。というのは、鍵盤がリリースベロシティで戻って来てる間に、次の鍵盤を押しちゃったらどうなるんだ？って事なんですよね。 　この辺、midi 2.0 が出てきて、本当に鍵盤の深さの情報を出力できれば、一発で解決できる問題なんだけど、現状では手探りで実験するしかないという… 　私は、鍵盤がゆっくり戻って来てる時に次を弾いちゃったら、リピテーションモードって設定に行くようにしました。 　リピテーションでは、指定した時間内に、指定した回数以上の打鍵があった場合、リリースベロシティを元にした鍵盤の戻りを無視して、打鍵状態に戻るようにしました。 　まあ、実際の演奏でこれが必要なシチュエーションがどこまであるのか、結構疑問だったりするんですけどね。 　具体的にはピアニッシシモで弾いてる時に、同じ音程を突然フォルテッシモで連打する、みたいな演奏状態になるケースで必要になるかと… 　例えば、ラベルの「夜のガスパール」って組曲にある「蛾」だったか「スカルボ」だったかのフレーズで、急激な同音程の連打みたいなシーンですね。 　ま、フミカが夜のガスパールを弾くかどうかは分からんけど（笑）。 　というわけで、昨日のベロシティによる鍵盤の動きを図にしたのが以下です。

　２０２０年１月のテスト動画で、大まか体の動きと指の動きを取る事ができたので、次はピアノの問題。 　恐らく、ほとんどの人が誤解してるのは、Midi データで楽器の演奏モーションを作ろうとした場合、midi データの Note On のデータは音の出るタイミングであって、楽器を弾きだすタイミングじゃないのです。 　例えばピアノで言えば、Note On が来た時、音源は音を鳴らすわけだけど、演奏モーションで Note On が来た時っていうのは、鍵盤が一番下がったタイミングになるわけです。 　つまり、鍵盤が下がり始めるタイミングというのは、Note On が来るよりも前からでないといけないわけ。 　この音が出始める前にピアノの鍵盤が下がり始める動きがないと、ピアノの鍵盤が突然ガクン！と下がったようになってしまいます。 　鍵盤が下がり始めるタイミングは Velocity 値が小さいほど早く、Velocity 値が大きいほど遅くなります。ここが結構こんがらがる所なんだけど、例えば１秒後に音が出るとして、小さい音はすぐに鍵盤が動き出して１秒後に鍵盤が一番下まで降りている必要があり、逆に大きい音は９００ミリ秒くらい待ってから、鍵盤が下がり始め、１００ミリ秒で一番下まで降りる、つまり早いスピードで鍵盤が動いて強く弦を叩いて大きな音がするってわけです。 　現状の midi 1.x では、鍵盤が動き出すタイミングのデータはないので、ベロシティで大まかの鍵盤下降スピードを予測して、鍵盤を動かす必要があります。 　midi 2.0 では、この辺、鍵盤の深さのデータも検出できるらしいので、midi 2.0 が出て来ると、もっと精密なピアノ鍵盤の動きが再現できる可能性があります。 　ただし、midi 2.0 になっても、キーボードのソフトが鍵盤が押される深さのデータを出力するようにプログラムされてなければダメなんですけどね。 　というわけで、ベロシティの強弱によって、鍵盤の下がる速度が変わるようなプログラムを Unity で書いて、動かしてるのが以下の動画です。

　で、昨日演奏してた小象の行進のビデオを元に、プログラマーさんの方で指のマークをプログラムで追跡してマーカーとして書き出しているのが、以下のビデオです。 　結構ちゃんとトラッキングしてて、実際にはこの他に４方向のビデオを撮影してトラッキングしてます。うまく行ったら最終的に８方向から撮影してトラッキング、そのデータを３次元解析して、指先の座標データを割り出そうという作戦でした。 　ま、この１か月後くらいにプログラマーさんは入院して頓挫しちゃったわけですけどね。

　最初の頃、プログラマーさんがまだ入院前、彼は指の動きをデータ化するのに、演奏中の指にマークを貼り、それを複数の方向から撮影して座標を割り出すという作戦を考えてました。 　なので私は各指の先と、手の甲に片手で６か所、両手で１２か所のマークを貼って演奏し、それをとりあえず４台のビデオで撮影して実験しました。 　各マークは認識しやすい色をテストして選び、一つのマークには２色の色の組み合わせを使って撮影してました。 　以下が、小象の行進をテストで演奏してる所です。 　小象の行進を選んだのは、左手が同じパターンを繰り返し、その位置が変わりながら伴奏するようになってたので、１パターン分だけでも認識に成功すれば、あとはデータのコピペでも行けるのでは？と考えたからです。

　で、これが３つ目のテスト動画。 　この子犬のワルツは、以前書いた路上ゲリラライブのデモにも入れた曲。軽いジャズ風で、昔のオイゲンキケロってジャズピアニスト風にしてみました。 　こんな感じの路線の曲アレンジは、結構フミカ的サウンドとしてはありかと思ってます。

　その他のテスト動画で、ポップコーン。

　で、２０２０年の１月に試しに撮ってみたモーションのテスト動画です。 　ここでは、HTC Vive、Vive トラッカー、Leap Motion の組み合わせで、体と指の動きをチェックしてます。 　体の動きと指の動きは、各々別々に Unity から Midi 化して取り込んでて、それを前から言ってるように Midi シーケンサーにデータ化して取り込んでいます。 　まずは、どんな感じになるか見てる状態。デモ曲はナットロッカーです。

　だいたい、昨日までのエントリーであれこれと経緯を書いたわけだけど、ピアノを演奏させる、という単一の動作をいかに綺麗に見せるか？が今回のポイントなんです。 　色々な人がやっているのを見てると、手が鍵盤の上をなんとなく動いてるだけとか、演奏してる内容と指が全然一致してないとか、そんなのばっかりでした。 　最近は AI で学習させた演奏ってのが出てきてるけど、この辺は、自由度がどうなんだろう？って疑問符は付きます。ま、前から書いてるとおり最終的には全部 AI になるんだろうけど、当面はキャプチャー＋プログラムで完成させるしかないかな？と思ってます。 　何人かの人がやってるのは Leap Motion だけでやるバージョンと、Leap Motion に HTC Vive のトラッカーとかを組み合わせやってる方法。この辺は Vtuber の方法の延長ですね。 　だけど、これだけだと、どうしても鍵盤と指の動きが一致しない。フィンガートラッキングはあくまでも指の動きを追ってるだけで、その先が鍵盤に完全にタッチしてるかどうかってのは、また別問題。 　そこで、キャプチャーする時に、一緒に midi の演奏データも取り込んでおいて、そのデータとモーションキャプチャーの動きを合致させる事ができれば、精度の高い演奏モーションを作れるんではないか？と考えてるわけです。 　まあ、口で言うは易しで、実際に実験してみると、まあ、うまくいかねえのなんの！ 　ノロノロとプログラム考えてる間に、全部 AI バージョンに追い抜かれるよ！って感じですが、とにかく始めちゃったので頑張ろうという状況です。

　とにかく、フミカの 3D データはできた！ 　すると問題は、その 3D モデルのフミカに、どうやってピアノを弾かせるか？って事になるわけです。 　その時点で、最初に参加してくれてたプログラマーさんは病院行きになってて、継続して仕事をする事は不可能。予算はない。誰かにボランティアで頼もうにも、どのプログラムを使って、どういう風にデータを作るべきか？の指標がない。 　とまあ、ないない尽くしで、立ち止まってた時に、知り合いに紹介された VR 系で有名な近藤さんっていう人が、midi で mmd モデルを動かすのをやってるのを見せてもらったんですよ。 　近藤さんがやってたのは、unity を使った仕組みだったので、unity でなんとかなるのか？みたいな感じで色々チェックを始めたわけです。 　これが２０１９年の８月。その時点で 3D モデルを midi で動かしたりできる可能性があるのは、unity , Unreal Engine, あと 3D CG ソフトの iClone っていうのが、Python を使ってエクステンションが書けるようになってたので、そのどれかでやるって感じだったんだけど、近藤さんがやった事実があるんで、Unity でやってみる事にしたわけです。 　この時、私は Unity っつ～か、C# の知識はゼロ！で、マニュアル本を２～３冊買って、載ってるゲームのプログラムを作ってみて少しずつ 3D モデルを Unity で動かせるようにしていったわけです。 　以前のビデオと重複しちゃうけど、以下が Unity + Midi + ユニティちゃんで作った Midi コントロール 3D モデルなわけです。 　この頃はまだ Mac + Unity + Midi でやってたんだけど、Mac 用の Unity/Midi エクステンションは、やたら動作が不安定で、クラッシュしまくり状態でした。 　なので、途中から Mac を使うのはあきらめて、開発は Windows でやるようになりました。

　せっかく Vカツでフミカのモデルを作ってみたのに、よ～く規約を見たら、５０００円払ってもデータを使えるのはニコ動のみで、しかもモデルデータとしては書き出せない！ 　というわけで「俺の時間を返せ～！」とか思いつつ、しょうがないので Vカツのデータはあきらめて、Vroid に乗り換え。 　また一週間くらいかけてデータを作ってみました。ただ Vカツの方が雰囲気は良いと思う。Vroid のフミカはな～んかオバサンっぽいんだが（特に髪の毛）、まあ無料だし、自分の能力がないんだししょうがない！ 　とりあえず、自分で使えるモデルデータがあれば、ピアノ演奏プログラムがなんとかなりそうになって来た段階で、同じサイズの本格的なデータを専門家に依頼して作ってもらえばいいや、という事で、とにかくフミカの３Dモデル完成！ 　この段階が去年の８月。 　で、以下が Vroid で作ったフミカ（そこ、笑わんよ～にな！）

　ビューアーを使って色々デモしたけど、反応ないし、ビューアー作ってくれたり、フミカの 3D データを途中まで作ってくれてたプログラマーさんは、ついに入院。完全な手詰まり状態となりました。 　結局全部自分で作って YouTube に載せるなり、音源作るなりしないと何も先に進まんな、という事で、色々考えました。 　最大の問題は２つ。 １：フミカの 3D モデルを仮でもいいから作らないと、テストもできない。 ２：３Dモデルでピアノを弾かすためのモーショントラッキングをなんとかしないと、何もできない。 　とまあ、当たり前っちゃあ当たり前な話。モーショントラッキングは、どうしてもダメなら以前載せた初音ミクのピアノ演奏みたいに、ビデオで本物の演奏を撮影して、それをモーショントレースすれば可能ではある。 　初音ミクで作った、モーショントレースは１分半作るのに３ヵ月くらいかかってるから、手慣れて来たとしても１曲作るのに、やっぱ３ヵ月くらいはかかるでしょう。 　とんでもなく時間がかかるけど、何もやらないよりはマシか？ってな事で、最悪その方法でやるって事にして、まずモデルについて考えました。 　その時点で使える無料ソフトは　Blender か、Vカツか、Vroid の３択。 　プログラマーさんが 3D データ作る時に、その途中経過の Blender データとか見せてもらったけど、こりゃさすがに私には無理！って事で、まず Vカツでフミカを作ってみる事に。 　なんたって 3D キャラなんざ作った事ないわけですから、用語も覚えつつ、それでも１週間くらいで作ったのが以下の動画。

　昨日書いた、路上ゲリラライブの仕組みは、複数のビューアーがオモチャピアノの周りを取り囲むように固定配置されます。 　この場合、ビューアーの位置は固定されてるわけだから、ピアノを演奏してるフミカのカメラ位置も当然固定になります（ビューアーが移動したら、フミカの見える角度もそれに合わせて動かさなきゃいけないけど、そのビューアー移動がないわけですからね）。 　とすると、前もって、ゲリラライブのステージで設置するビューアーと同じ位置関係、例えばゲリラライブのステージのビューアーが５０ｃｍ四方に並んでたとして、その１０倍の倍率＝５ｍ四方の範囲にカメラをビューアーと同じ位置関係で並べ、ブルーバックでギターとかの本物の演奏者に演奏してもらって、撮影し、演奏者の部分だけを抜いた画像を作って、フミカの演奏動画に合成すれば、ゲリラライブのステージ上に見えるバーチャルキャラのフミカと一緒に、本物の演奏者がセッションする、というような風景が作り出せるわけです。 　とまあ、結構面白いはずなんだけど、それが「これは面白いだろう！」と証明するためには自分でそれを作るしかない。 　昔なら知り合いでも手伝ってくれる人がいたけど、今やみんな内向き志向、守りの体制な 人ばっかりで「やるぞ！」って気合いがあるのは私一人という惨状。 　さらに困った事に、Unity で作るとしても、何をするべきか？どういう仕様にするべきかは、作りながら考えるしかないんで、ド～～～ン！とお金をかけてスタッフでも雇えればいいけど、それは無理なんで、ここはひとつ自分でやるしかないと… 　しかも、ピアノ演奏のデータ作成も今や機械学習が…　ってな話でないと関係者は見向きもしない！ 　知り合いがヤマハに話をしたら鼻で笑われたそうです。 　 今に見とれよヤマハ！！！！

　昨日書いたみたいに、ビューアーを手に持ってオモチャのピアノの方を見ながら３０分くらいのライブを見るのは手が痛くなってキビシイし、複数のユーザーがピアノの周りをビューアー片手に見物するのは危険が伴う可能性も高い。 　というわけで、それじゃピアノの周りにビューアーを複数固定して、それを見たらどうだろうか？って案を思いつき、そのデモビデオを作ってみました。 　これが以下のような動画。路上に置かれた机の上のオモチャピアノに向かって、本物の人間が、それを見てるって想定です。

　これまでの動画でアップしたように、最初の考えに、オモチャのピアノをビューアーで見ると、そこにフミカが登場してピアノを弾くって方法にするつもりだったんだけど、やってみると、ビューアーを持って１曲の間中オモチャのピアノを見続けるってのは、手が痛くなる！ 　ましてや３０分くらいのステージでビューアーを持ち続けるってのは無理があるなあと思い始めたわけです。かといって、HTC Vive とか Oculus のようなゴーグルをかけるってのは、あり得ないと思ってました。 　ゴーグルがもっと小さくて機動性が高くなるか、眼鏡に固定するような小型の物になるかしないと、とてもじゃないけどマニアにしかウケないよなあ、と思ったわけです。 　最終的には本物のグランドピアノを裸眼で見ると、空間３次元立体視のキャラがいるってのになると思うんだけど、そこに行きつくまでのプレゼンをどうするか？ってのは頭の痛い所。 　実際、ビューアーを使った 3D ビューは最初は盛り上がったけど、今は下火。そりゃそうですよね。

　フミカの仮 3D データが出来たので、これを初音ミクでやってたビューアーに適用して、フミカ版のビューアーを作ってみました。 　これが２０１９年の１月の状態で、こんな感じでした。

　仮であれ 3D のデータが出来たので、今度は音楽の方がどの程度のペースで作成できるか実験するために PodCast 形式で、おしゃべりと演奏のファイルを作ってみました。 　オープニングとエンディングの固定曲を作り、毎回フミカが曲の解説をしてから演奏ってフォーマットにして、クラシックやポップスのアレンジなんかを公開するのに、どの程度手間がかかるか？ってのの検証です。 　よく YouTube で人気を出すためには毎週アップしろとか、毎日アップしろとか色々と聞きますが、ピアノ曲をアレンジ演奏して動画も編集してってのだと結構大変そう。 　で、実際に作ってみると、早くて１週間、長くて２週間で１曲ペースかな？って感じでした。でも本チャンではこれに動画が入るから、果たしてどのくらいのペースでアップできるのかは謎ですねえ。 　多くの YouTuber のサザッションは「とにかく沢山作って、一つの動画の参照数が少なくても数で稼ぐ。そのうち登録者が増えるのを狙う」ってパターンみたいだけど、それは無理か～？って感じですよね。 　ただ、動画登録者によっては、２～３個しか登録してないのに、１つの動画の参照数が１００万だの２００万だのってのもあるわけで、フミカとしてはそれを狙うしかないか？ 　というわけで、試験的に作ったポッドキャストが以下です。とりあえず７話分作ってみました。 　 フミカのピアノキャストを聞く（YouTube）

　で、ビューアーと平行してプログラマーさんがフミカの３Dデータを作ってくれてました。これが２０１８年の１１月の話。 　 以前のエントリーにある設定資料のやつです。 　この仮３Dデータを元に試しにフミカを動かしてみたのが以下。 　これは iClone のデモ版でやってみたんだけど、iClone は、以前多少使った事があったので、フミカの CG 部分はこれでやってみようかと思って購入。 　その後、フミカの自己紹介をテストで作ってみたのが以下です。