8月1日より各務原市で「ドローンが拓く未来」なる空宙博企画展が開催されます。この展覧会では、現実感芸術（プロジェクト）で制作した作品「養老天命反転AR」で使用したドローンの手法を紹介しています。他にも多くのドローンや利用方法が紹介されていますので、お出かけいただければ幸いです。
2020空宙博企画展「ドローンが拓く未来」
会場：岐阜かかみがはら航空宇宙博物館、1階航空エリアA3ゾーン
会期：2020年8月1日〜9月27日
養老天命反転ARでは、ドローンを飛ばして数百枚の写真を撮影し、フォトグラメトリよって養老天命反転地の3Dモデルを作成、これをARとして仮想物体を表示する際の隠面消去として用いています。養老天命反転地は豊かな植生によって形状が季節とともに変化し、長い年月のうちに建造当時とは異なる様相になっています。そこで作品を体験する時点での地形や植生などの形状を把握するためにドローンを使用しています。
ウェアラブルやIoTの斜め上を行きたい雰囲気メガネが初めての開発者向けミーティングを行います。雰囲気メガネは当初からSDKやMDKを公開し、誰もが各自のニーズに応じたアプリやアタッチメントを制作できるようになっています。そこで今回のミーティングでは、赤松が雰囲気メガネの背景やコンセプトをお話し、国内きってのBLEウィザードである上原昭宏が開発環境の説明とハンズオンを行います。さらに開発者支援や今後のロードマップについては、雰囲気メガネのカナメたる白鳥啓が説明します。いわゆるハッカソンやアイディアソンではないので、気軽にミーティングにご参加いただければと思います。よろしくお願いします！
雰囲気メガネ・デベロッパーズ・ミーティング
日時：2016年7月23日（土）13:00〜18:00
12:30〜受付開始、終了後に懇親会を予定しています
場所：清泉女子大学 本館2階 大会議室
東京都品川区東五反田3-16-21
五反田駅 東口より徒歩約10〜15分
主催：特定非営利活動法人MOSA
協力：株式会社 なまえめがね
講師：赤松正行(情報科学芸術大学院大学 [IAMAS])、上原昭宏（合同会社わふう）
定員：30名（MOSA会員枠あり）
参加費：MOSA会員3,000円、学生会員2,000円、非会員4,000円（懇親会費用込み）
注意： 当日アプリ開発に必要な実機を各人分ご用意させていただきます。
昨年来「窓辺のカフカちゃんズ」など自律分散協調型の作品をMonacaで開発しています。ただし、WEB系テクノロジーがイマイチ得意じゃないので、ProcessingのJavaScript版であるp5.jsを使ってお気楽コーディングでお茶を濁す魂胆だったりします。
ところが、p5.js自体は問題なく動作するものの、そのサウンド拡張ライブラリであるp5.sound.jsが不安定で、しばしば悩まされます。以前はソースコードに手を入れて無理やり動かしたこともあったほど。そして、最近のトラブルは、index.htmlでコンポーネントを指定すれば正常動作するのに対して、Monacaのコンポーネント管理を使うとp5自体が動作しないという謎現象でした。
このコンポーネント管理では、利用したいコンポーネントを検索して選択すると、現在のプロジェクトにインストールされるので、下図のようなローダーで利用したいjsファイルにチェックを入れます。この時、表示されている順番（パスのアルファベット順）にファイルが読み込まれるそうです。この場合は最初にp5.sound.jsが読み込まれ、次にp5.jsが読み込まれます。
ところが、p5ではp5.jsが大元と言うか親クラスなので、p5.sound.jsよりも先にp5.jsが読み込まれる必要があります。つまり、Monacaのローダーでは逆の順番で読み込まれるので、p5が正しく動作しなかったわけです。ロード順を指定できると良いのですが、現在のMonacaにはそのような機能がありません。
そこで、この問題を解決するには、Monacaのコンポーネント管理でインストールしたファイルの読み込みは、ローダーで指定せずに（ローダーではチェックを入れずに）index.htmlのscriptタグで指定します。はい、これでOK！
上記の解決策は試行錯誤して見つけていたのですが、釈然としないためにMonacaの開発元に問い合わせたところ、丁寧にローダの仕組みを解説していただいて理解に至りました。このためにサポート・チケットを1枚消費したのは良い勉強ですね（笑）。
アンビエントな情報デバイスである雰囲気メガネは、昨年夏のクラウド・ファンディングでは目標額の200%以上の支援をいただいてファンディングが成立、幾多の困難を乗り越えて本年1月に実際の製品として支援者の皆さまにお届けすることができました。その後は、SDK（ソフトウェア開発キット）の公開とともにサード・パーティのアプリがリリースされ、日常生活はもちろんのことイベントなどでの活用も見かけるようになってきましたね。
一方、雰囲気メガネ・チームは北米およびヨーロッパでの無線機器の認証を取得し、海外展開への準備を進めてきました。そして前回と同じくMakuakeにてクラウド・ファンディング第2弾を開始、多くの方からの支援を募集しています。英語サイトでは海外からの支援を申し込めますので、欧米にお住いの知人にもお知らせいただけると有難いです。もちろん、国内からも支援していただけますし、今後予定されている一般販売価格より安価に入手できるチャンスですね。是非よろしくお願いします。
スマートに情報を伝えるメガネ型端末「雰囲気メガネ」海外展開記念プロジェクト 【英語サイト】
募集期間：2015年9月7日11:00〜2015年10月6日18:00
目標金額：3,330,000円
支援内容：24,000円（雰囲気メガネ1本）
48,000円（雰囲気メガネ2本）
96,000円（雰囲気メガネ4本）
192,000円（雰囲気メガネ8本）
384,000円（雰囲気メガネ16本）
先のエントリーで記したように、Appleが買収したモバイルAR（拡張現実）関連会社Metaioは、すでに既存のユーザのサポートのみに移行していて、その製品やサービスを伺い知ることは難しい。ただし、iOSアプリはまだダウンロード可能なので、ARブラウザであるJunaioや、物体認識ツールであるMetaio Toolboxを試すことができる。また、今年の初めにMetaio関連のワークショップを行ったので、その際のレジュメも公開しておくね。この資料やiOSアプリには、Appleが目指すARの一端が含まれているかもしれない（含まれていないかもしれない）からね。
ダウンロード：「なんちゃってAR制作ワークショップ」レジュメ
さて、このワークショップでは、Metaio Creatorなる簡易AR制作ツールを利用した。以下の図のようなオーサリング環境で、認識するターゲットと対応するリソースを指定するだけでOK、プログラム・コードを書く必要はない。これはMacの内蔵カメラで即座にプレビューすることができ、アップロードすればJunaioアプリによってiPhoneで動作する。あっけないほど簡単であり、アイディア次第で多種多様なARを素早く実現できるようになっている。
Metaio Creatorが備えるターゲットのトラッキング（認識）方法は、図のように6種類もある。これだけの認識方法をひとつのエンジンで統合しているのは立派。やや水増し感もあるけどね（笑）。
このうち、3次元物体を認識するObject Trackingや建造物を認識するEnvironment Trackingでは、そのデータをiOSアプリのMetaio Toolboxを使って制作する。iPhoneをかざして物体や建物の周囲を回ってスキャニングすれば、3次元位置として特徴点が蓄積されていくことになる。
ターゲットが認識された時にトリガーされるリソースも15種類と豊富。静止画や動画、3Dモデルなどを表示したり、WEBサイトの閲覧やツイートの投稿、カレンダーの作成などもできる。必要であればタイムラインによるアニメーションや、簡単なスクリプトの実行も可能。こちらも水増し感がちらほら（苦笑）。
このように見ていくと、Metaio CreatorはARのFlashを目指していたように思える。しかし、Flashがそうであったように、誰でも簡単に作れるものの、最大公約数的な大雑把なコンテンツしか作れないという危惧も強かった。実際にも作例のモナリザは、ARARATのほうが遥かに認識の精度と安定感が良く、イメージの表示もARARTのほうが自然で違和感がなかった。自画自賛のようだけど、これはワークショップの参加者も同意していたよ。
ただし、MetaioにはMetaio SDKなど高度な開発環境も提供されていたので、コード・レベルでチューニングすれば効果的な結果が得られるかもしれない。MetaioはIKEAやAudiなど大手企業のアプリに採用された実績を持つので、それは単なる営業努力だけではないよね。ISMARなど学術会議でのコンテストも勝ち得ている。だから、技術的な基盤は堅牢で性能は高いハズ。AppleがMetaioの何に魅力を見出し、モバイルARをどのように活用するのか、それこそが重要だよね。
ところで、MetaioとはメタI/Oのこと？
「アンドロイドは〜」のほうが収まりは良いけど、ここはアップルです、Apple Inc.です。と言うのも、AppleがAR（拡張現実）界のリーディング・カンパニーのひとつMetaioを買収したから。すでにMetaio社のWEBサイトでは製品の販売や関連する情報は取り下げられている。これまでARには正面切って取り組んでいなかったAppleが、Metaioを得て何をするのか、興味津々です。
ここ数ヶ月を振り返ってみると、Googleは謎に包まれたARスタートアップMagic Leap社に巨額出資を行い、Microsoftは自社開発のARゴーグルHoloLensを発表したよね。Facebookに買収されたHMDの革新者Oculus社も、さらにSurreal Vision社を買収してARに接近中。といったようにIT界の主要プレーヤがARを重要視していることが分かる。そこへAppleも参入するというわけ。
未知数のMagic Leapはさて置くとしても、HoloLensもOculusも頭部に装着するディスプレイが主役。対するMetaioはあくまでもスマートフォンで動作するソフトウェアでしかない。順当に考えれば、Appleが取り込もうとしているのは、その延長線上にあり、いわゆるモバイルAR、つまりセカイカメラやARARTがOSレベルでサポートされることになる。数年間の苦節（笑）を経て、モバイルARが桧舞台に躍り出るや否や、これは楽しみですね。
Appleはもっとも革新的なITカンパニーと評されるほど未来志向だけど、その未来は安っぽいSF映画に描かれるようなキラキラのハイテクじゃない。それは日常生活に違和感なく溶け込み、歴史や文化に支えられ、ある意味で古典的（Classic）ですらあるような未来だと思う。それを端的に表すのがCMフィルムで、来年あたりには何気ない日常生活の場面場面でiPhoneをかざす様子が描かれているかもしれない。あるはメガネかもしれない。それはモバイルARの最後の1マイルね。
WEB系の表現にウトいこともあって気づいていなかったけど、アシアル株式会社のMonacaという開発環境が素晴らしい機能を持っていた。このMonacaはHTML5（とCSS3とJavaScript）で記述して、iOSやAndroidなど複数のプラットフォーム向けのネイティブ・アプリを出力できる。つまり、大昔ならFlashアプリがそうであったように、各プラットフォームの特性を無視した大味なアプリがワン・ソースで作れるわけ。また、クラウド型IDEによってWEBブラウザ（とインターネット）だけで開発ができる。自分のマシンであろうが他人様のマシンであろが、いつでもどこでもログインさえすればセットアップ要らずでWEBベースの緩慢かつ低機能なエディタで作業が続けられる。このあたりがMonacaの大きなメリット（とデメリット）みたい。
もっとも、そのようなメリットは個人的には響かない。XcodeでiOS SDKを駆使したSwiftコードを書くほうが遥かに快感だし、マルチ・プラットフォーム対応は砂糖をまぶした悪夢だからね。ところが、Monacaは現在のXcodeでは絶対にできない領域に君臨している。それは開発中のアプリを複数のiPhoneで同時に動作させること。もちろんXcodeでもiPhoneのアプリを動作させられるけど、それは1台に限られるよね。それがMonacaでは何台でも同時に動くわけ（驚愕）。
実際の動作状況は以下のムービーでどうぞ。これはSnowflakesの基本処理をHTML5化してMonacaで動作させている。MacBookではSafariでMonaca IDEを開き、iPhoneではMonacaデバッガーなるアプリを開く。いずれも自分のアカウントでMonacaにログインしておけば、すべてのiPhoneでHTML5で記述したアプリが起動する。途中でコードを修正して保存すれば、それだけで修正したファイルが再同期されてアプリが再起動する。ムービーでは途中で背景色を変えている。ね、恐ろしく簡単で快適でしょ？
このデモでは、Monacaとして動作するアプリをProcessingのJavaScript版であるp5.jsで書いている。JavaScriptは簡単だけど、p5.jsはもっと簡単で、しかもJavaScriptとの親和性も高い。サーバはMacBookで動いていて、これはnode.jsとsocket.ioで記述。クライアント（iPhone）での通信もsocket.ioを利用している。このようなJavaScript（およびCSS）のライブラリはMonaca IDEで管理できるし、手動で追加・変更しても構わない。
さて、一般には同時に何台も動いても嬉しくないけど、それはデンタクのようなアプリだからだよね。Snowflakesと同様にincubatorやOkeanos Buoyなど、複数のデバイスが相互に関連しながら総体としての表象表現を目指している者には、これは喉から手が出るほど欲しい機能に他ならない。これまでも独自の動作環境を作っていたけど、それはパラメータ調整程度に留まっていた。それがMonacaでは言語レベルで構築できるから、感涙なわけです。作業効率は当社比100倍ね。後はこれで作品作れって話だけど、もちろんそれが一番難しい（笑）。
間もなく（おそらく）出荷される雰囲気メガネでは、独自のアプリケーション開発のためにSDKが提供されます。これはObjective-CまたはSwiftというプログラミング言語を用いる本格的なものなので、もう少しお手軽な方法としてMIDIとOSCを用意しています。OSC（OpenSound Control）はMaxなどで簡単に扱えますし、MIDIなら鍵盤を弾いたり、ツマミをグリグリするだけです。
MIDIやOSCをサポートしているウェアラブル・デバイスやモノのインターネットと呼ばれる製品は珍しいと思いますが、これこそが雰囲気メガネの特徴のひとつですね。そこで、ここでは一足早く雰囲気メガネのMIDIとOSCのプロトコル【暫定版】を説明します。正式なドキュメントは開発者向けサイトで公開されるはずです。
MIDIもOSCも雰囲気メガネのiOSアプリに対してデータを送り、アプリは雰囲気メガネとリンクされている必要があります。つまり、雰囲気メガネ・アプリがMIDIやOSCと雰囲気メガネとの中継役になるわけです。雰囲気メガネ・アプリでは設定ボタンからMIDI/OSC画面を開いて設定を行い、この画面でのみMIDIやOSCを受け取るようになっています。
MIDIに関しては、MIDI/OSC画面でMIDIスイッチをオンにするだけで、それ以外の設定はありません。MIDIのすべての経路を受け入れて、すべてのMIDIチャンネルを受け付けます。CoreMIDIに対応していればネットワークMIDIでもバーチャルMIDIでも構わないし、物理的なMIDIインターフェースでも構いません。最近登場したMIDI Over Bluetooth LEも制約があるようですが一応動作しました。何らかのMIDIメッセージを受け取ると、MIDIスイッチの左横にある小さな丸が点滅します。
MIDIメッセージでは、まず、もっともポピュラーなノート・オンおよびノート・オフ・メッセージに対応しています。MIDI鍵盤を弾けば雰囲気メガネがピカピカと色とりどりに光るわけです。雰囲気メガネの紹介ビデオでもグランド・ピアノを弾いているシーンがありましたね（気分はディスクラビア）。この場合は、ノート・ナンバーを色相として扱い、どのオクターブでもド（C）が赤色で12半音で色環を一周する割当になります。ベロシティは明度の指定で、最大値である127なら最も明るく光り、数値が小さいと弱い光りとなり、0なら光りが消えます。強く（速く）鍵盤を叩くほど明るく光り、鍵盤から指を離せば光りが消えるわけですね。ノート・オフ・メッセージはどのような値でも光りが消えます。
MIDIノート・オン・メッセージ
ノート・ナンバー：色相（図参照）
ベロシティ：明度（0：消灯〜127：最も明るい）
MIDIノート・オフ・メッセージ
消灯
ノート・オンとノート・オフでは色相と明度しか指定できないので、彩度はコントロール・チェンジの1番で指定します。これはモジュレーションなので、多くのMIDIキーボードでは鍵盤の左横にあるホイールやレバーを動かせば彩度が変わります。ただし、コントロール値がゼロの時に彩度が最大で色がはっきりし、値が大きくなるにつれて彩度が下がって白っぽくなります。モジュレーションを上げて「白熱」した演奏になるわけです。
MIDIコントロール・チェンジ
コントロール・ナンバー1（モジュレーション）：彩度（0：彩度最大〜127：彩度最小）
指定した色に変化する遷移時間はコントロール・チェンジの5番と56番で設定できます。コントロール・チェンジの5番はポルタメント・タイム、同じく65番はポルタメント・スイッチですから、それっぽいですよね。コントロール・チェンジ5番の値が0であれば遷移時間は0秒、127であれば4秒とリニアに変化します。コントロール・チェンジ65番の値が0から63までなら遷移は無効、64から127までなら遷移が有効になります。
MIDIコントロール・チェンジ
コントロール・ナンバー5（ポルタメント・タイム）：遷移時間（0：0.0秒〜127：4.0秒）
コントロール・ナンバー65（ポルタメント・スイッチ）：遷移設定（0〜63：有効、64〜127：無効）
さらに、コントロール・チェンジの16番、17番、18番を使ってHSB形式で光りを設定することもできます。これらは汎用操作子の1番から3番で、汎用だから何でも良いでしょうってことです。
MIDIコントロール・チェンジ
コントロール・ナンバー16（汎用操作子1）：色相（0：最小〜127：最大）
コントロール・ナンバー17（汎用操作子2）：彩度（0：最小〜127：最大）
コントロール・ナンバー18（汎用操作子3）：明度（0：最小〜127：最大）
遷移時間の設定以外は、どのMIDIメッセージを受け取っても、ただちに雰囲気メガネの色が変わります。これは、できるだけ簡単に、まさに演奏するように雰囲気メガネをコントロールしたいとの意図です。しかし、逆に言えば効率的ではありませんし、MIDIでは左右個別に色を設定することはできません。より柔軟なコントロールにはOSCをお勧めします。
OSCを利用する場合は、送信するMacやiPhoneと雰囲気メガネ・アプリが動作しているiPhoneとを同じWi-Fiネットワークに繋ぎます。OSCの受信ポート番号はデフォルトで2061で、どこかで聞いたような数値ですが、任意のポート番号に変更しても構いません。雰囲気メガネ・アプリが動作しているiPhoneのIPアドレスが表示されているので、送信元からはこのIPアドレスに対して設定したポート番号でOSCパケットを送ります。OSCのスイッチをオンし、何らかのOSCパケットを受信すれば、スイッチの左横の小さな丸が点滅するはずです。
OSCパケットのフォーマットは以下の通りで、/fun-iki/performというアドレスに続けて7つの数値を与えます。最初の3つの数値は左側レンズの色をHSB形式で指定し、いずれも0.0から1.0までの範囲の実数です。続く3つの数値は右側レンズの色です。最後の数値は指定した色に変化する遷移時間を秒数で指定します。遷移時間として指定できる有効な数値の範囲は0.0秒から655.34秒で、分解能は0.01秒です。
/fun-iki/perform <左色相> <左彩度> <左明度> <右色相> <右彩度> <右明度> <遷移時間>
例えば、次のパケットを送ると、左側は明るい赤色に、右側は暗めの青色にすぐに変わります。
/fun-iki/perform 0.0 1.0 1.0 0.666 1.0 0.5 0.0
そして、次のパケットと送ると、両側のレンズの光りが2秒かけてゆっくり消えます。
/fun-iki/perform 0.0 0.0 0.0 0.0 0.0 0.0 2.0
ちなみに、OSCでは実数を使って細かく制御できるように思えますが、しかし、高い精度は期待しないでください。iPhoneなどのディスプレイに比べると、雰囲気メガネのカラーLEDの色域や精度は広くないですからね。また、データを送ってから色の変化が始るまでの時間的な遅れや、単位時間あたりに送れるデータ量の制限もあります。演奏するように雰囲気メガネをコントロールしたいものの、大量のデータを送ればパケ詰まりになります。このような制限はMIDIでも同じで、実際にデータを送って光り方を確かめながら制作していただけると良いかと思います。
雰囲気メガネはMIDIやOSCによって光り方をコントロールできるようになっています。そこで製品より一足先にMaxで作成した雰囲気メガネ《非公式》シミュレータを公開します。これで雰囲気メガネへどのようにMIDIメッセージやOSCパケットを送れば良いかが分ると思います。
雰囲気メガネ《非公式》シミュレータ（Maxパッチ）をダウンロード
ダウンロードしたアーカイブには3つのファイルが含まれていて、そのうちSimFun’ikiがシミュレータ本体で、MIDI-Fun’ikiはMIDIメッセージ送信のサンプル、OSC-Fun’ikiはOSCパケット送信のサンプルとなっています。Maxでプログラミングされる方はMIDI-Fun’ikiやOSC-Fun’ikiを改造すれば良いですね。Maxを使わない場合も同等のMIDIメッセージやOSCパケットをSimFun’iki（を開いているMaxアプリケーション）に送ればOKです。SimFun’ikiは雰囲気メガネのように光る（色が変わる）はずです。実際に雰囲気メガネを使う場合は、ペアリングしたiOSデバイスに対してMIDIメッセージやOSCパケットを送信するだけです。
もっとも、シミュレータは雰囲気メガネの挙動を忠実に表しているわけではありません。雰囲気メガネはディスプレイのように色域が広いわけでも、応答が速いわけでもないからです。応答速度などは出荷直前まで調整が続けられますので、現時点では具体的な数値を挙げられません。ただ、高速に光が点滅するようなコントロールは無理だと考えたほうが良いですね。そのような制限もありますが、ご自身のアイディアで雰囲気メガネを制御する楽しさと可能性にご期待いただければ嬉しいです。よろしくお願いします〜！
Leap Motion社の3次元センサーThe Leap Motion controllerのDeveloper unitが届いたので、Maxオブジェクトaka.leapmotionを作成して公開しています。Leap Motionはまだ製品版は発売されておらず、受け取ったデバイスも外装なしの基盤剥き出し状態でしたが、動作自体は安定しています。
aka.leapmotionはLeap Motionから得られるデータを忠実に出力しており、ヘルプ・パッチから分かるようにかなりの量のデータが得られます。基本的には人の手や指の認識に特化しており、手に持ったペンやお箸なども（指ではないものとして）認識できます。認識範囲はそれほど広くないものの、テルミン的な範囲はOKかと思います。
ちなみにLeap Motionのデバイスは二つのカメラの画像をUSBでMacに送り、Macで動作するLeapアプリケーションが画像解析をしているようです（想像）。このため、MacBook Pro (Mid 2012, 2.7GHz)でのLeapアプリケーションのCPU使用率は、何もない状態で30%、片手を認識すると40%、両手なら50%といった具合です。Maxオブジェクトではデータを受け取るだけなのでCPU使用率は少なくて済みます。なお、このマシンは4コア・8スレッドなのでフル稼働なら800%となり、単純にはLeap Motionは全体の数パーセントを使っていることになります。
ともあれ、現状のLeap Motionは具体的に何かができるわけではなく、デベロッパーによるアプリケーションの充実を目指している状況のようです。マルチタッチ・トラックパッドのエミュレーションなども期待したいところですね。