Device」カテゴリーアーカイブ

バランスWiiボードは接続のみ

Wiiリモコンと同じく、Wii Fitに同梱されるバランスWiiボードもBluetooth接続ですが、きっとダメだろうと思いつつ試してみたところ、やはりダメでした。

具体的には、Bluetooth接続アシスタントでジョイスティックとして認識され、接続もできますが、そこまでです。Maxのhiオブジェクトのメニューには現れないし、しばらくすると接続が解除されちゃいます。デバイス名は「Nintendo RVL-WBC-01」のようですが、サービス名として「Nintendo RVL-CNT-01」(これはWiiリモコンのこと)と表示されるのも不思議。以上はLeopardの場合で、Tigerでは認識されるものの、接続まではできませんでした。

wii-balanceboard-bt.png

Wii Fit自体まだ日本でしか発売されていないそうで、WiiLi.orgでの解析も始まっていませんね。バランスWiiボードでのアイディアが現時点ではないから、aka.wiiboardに取り組む予定はありません(笑)。でも、136Kgまでの荷重に耐えられるデバイスってのは興味深いです。

MactrackerはMac辞書

Mactrackerは歴代Macintoshの各種情報を集めたグレートなアプリケーションで、この度Version 5にアップデートされました。メモリを増設したいんだけど、モジュール・タイプって何だっけ?とか、あの古いマシンにLeopardをインストールできるかな?って場合に便利です。スペック的な事柄はもちろんのこと、開発時のコード・ネームやら発売時の価格やら、何から何まで網羅しています。

Mac本体だけでなくて、マウスやキーボード、ディスプレイなどの周辺機器や、Mac OSとMac OS Xのシステム・ソフトウェアの情報も網羅しています。さすがにApple I/II/IIIやLisaはないけど、iPhone、iPod、Apple TVはあるし、Newtonもありますね。1983年以前の機種を知りたい場合は、apple-history.comあたりかな。

Macに関しては、機種ごとに起動音(Startup Chime)を聞けるのもウレシイですね。昔のマシンには死亡音(Death Chime)もあります。ご想像のように、パッケージを開けばサウンド・ファイルをゲットできますから、サンプル・ネタにどうぞ。

mactracker.jpg

もうひとつ簡易版ながらWebバージョンもあります。iPhone用のインターフェースになっているけど、普通のWebブラウザでも閲覧できます。ブックマークが吉ね。

RocketFMと古ラジオ

22チャンネル大作戦の実験のために購入したRocketFMは、小粋なデザインで性能も上々です。ドライバをインストールすれば、サウンド環境設定の出力デバイスにRocketFMが現れます。なので、サウンドを出力するアプリケーションなら何でも、FMラジオに音を送り込むことができます。RocketFM環境設定で送信周波数を設定ね。

rocketfm-system-preference.jpg

22チャンネル大作戦での問題点は、RocketFMのソフトウェアがAppleScriptableではない(たぶん)ので、外部制御は困難っぽいこと。でも、aka.mouseあたりを使って疑似マウス操作をすれば大丈夫でしょう(たぶん)。それから、FMラジオって周波数が合っていない時は、ホワイト・ノイズが流れちゃうんですね。信号がない(弱い)時は自動ミュートしてくれるとイイんですが、何台か試した限りでは、そんな機能は付いていませんでした(涙)。22チャンネル大作戦に関しては、これが一番の問題になりそう。

rocketfm-and-old-radio.jpg

ところで、このRocketFMを(文字通りの飛び道具として)明日のライブで使います。当初は普通のラジカセを使うつもりでしたけど、ナント、新ユニットの相方様が古いラジオをオークションで落としてきました。細部にこそ神は宿る、ってことかもしれません(笑)。すぐに狂っちゃうチューニングとか、低域も高域も出なくて歪みがちなスピーカーとか、とってもいい感じです。

クルマにもOS X

Engadgetの記事で知りましたが、VolkswargenとAppleが協業中との噂は、コンセプトカーSpace Up!に搭載されているGUIとして現れて来たようです。正面のダッシュパネルも横のカーナビ系パネルも、OS X風というかLeopard風というかCover Flow風になっています。しかも、Volkswargenは今後このGUIを全車種に導入していくとか

wolkswargen-spaceupblue.jpg

これまた、OS X汎神論ですね。クルマの操作系、特にカーナビのGUIは無茶苦茶なものばかりなので、これは待ち遠しいです。ちなみに、ここ数年のマイカーはNew Beetle→New Beetle Cabrioletなんだけど、最近のVWはイマイチなので、さっさとリリースしないとダメでしょう。

ただし、これに限らないけど、GUIは見なければ操作できないのが最大の難点。クルマのUIとして、Appleがどうアレンジするのか、お手並み拝見ですね。近代以降の視覚依存性からの脱却に、未来はかかっています。

GPhoneはアンドロイド

ウワサのGoogleケータイは、Androidなるモバイス・デバイス用のソフトウェア・セットとして発表されましたね。SDKは11/12(来週じゃん)に公開となってます。

android_logo.png

面白いのは、AndroidはGoogleが中心であるものの、通信キャリアやハードウェア・ソフトウェア会社など33社によるOpen Handset Allianceを形成していること。そのメンバーにKDDIとDoCoMoが入っていて、XxxxXxxxは入っていない。ってことは…ってことですか? 他にもいろいろ邪推できますね。個人的にはAdobeが入っていないのがステキだと思います(さようならFlash)。

open-handset-alliance_m.jpg

マルチ・タッチLemurが国内発売

以前から話題になっていたJazzmutantのマルチ・タッチ・スクリーンによるフィジカル・コントローラ「Lemur(レミュー)」と「Dexter(デクスター)」が、いよいよ国内発売されるそうです。発売元はMax/MSP/Jitterも取り扱っているイー・フロンティア(旧カメオ・インタラクティブ)さん。まだ国内向けのWebサイトがなく、国内価格など詳しい情報は分かりませんが、今月末に製品発表会があるそうです。発売予定日は11月26日とか。

lemur.jpg

マルチ・タッチと言えばiPhone/iPod touchもそうですが、ニューヨーク大学のJeff Han氏の研究(よくできたデモ映像は必見)や、それを製品化するPerceptive Pixel社、何でもちょっと遅れてちょっかいを出すMicrosoft社(笑)のSurfaceなど、世間の注目が集まっているホットな分野ですね。精度や耐久性を無視すれば、自分で作っちゃうことも可能です。

ただし、演奏や制作に使えるフェーダやノブを持ったフィジカル・コントローラの発展型として考えると、Jeff Han方式やMicrosoft Surface方式は壁面やテープル・サイズで大き過ぎるし、iPhone/iPod touchは掌サイズで小さ過ぎるかもしれません。となると、実際の選択肢はLemur/Dextuerしかないですね。マルチ・タッチは長年研究されていますが、実用に耐える現実の製品として開発したJazzmutantはエライ!と思いますよ。

私も以前にDSPBoxプロジェクトをやっていたこともあって、マルチ・タッチには興味津々だったのですが、当時の技術ではロクなものがありませんでした(笑)。だから半信半疑だったものの、2年程前にLemur試作機のデモを見せてもらった時は、本当にビックリ。ちゃんとマルチ・タッチができている!反応速度も精度もバッチリ!と驚愕しましたからね。そして、万を期しての国内登場という訳です。ポケット・マネーでちょいっと買える価格ではないと思いますが、少しでも入手し易い価格になることを祈りつつ、正式発表を待つことにしましょう。

生体センサーで行こう!

一昨日のIAMASでは、DSP特論なる授業がありました。安直なネーミング(笑)とは裏腹に、毎回素晴らしい講師をお招きしてのレクチャー&ワークショップ・シリーズで、今回(と次回)は「生理心理学とメディア・アート」と題して、赤松も何かと(アレとかコレとか)お世話になっている照岡正樹さんにご登場いただきました。

何と言っても今回のメイン・ディッシュは、この講義のために新たに設計・制作していただいた生体センサーですね。小さなセンサー・ボード(緑色の基板)はショートピンを切り替えて、EOG(眼球運動)、皮膚電位、心電、脳波、筋電が測定できるようになっています。IAMASだからってことで、Gainer(赤色の基板)との接続のために、ハム・フィルター(極小の緑色の基板)まで用意される完璧ぶり。

teruoka-sensor.jpg

センサー・ボード自体は増幅器と考えて良いそうですけど、全体としては単純な電気装置ではなくって、照岡さんの長年のノウハウが随所に詰め込まれた「作品」ですね。医療用の最高級品からチョイスされた導電ゲル付き銀・塩化銀電極(Electrode 1025)、安っぽい紙で巻かれている電極〜ボード接続部、単三乾電池を6本も使用している電源部などなど、一見不可解だったりしますが、実は深い深いワケがあるとのこと。

もうひとつの重要なノウハウは「生体情報は音で聴け!」だそうです。生体情報の測定は常にノイズとの戦いで、結果的にノイズを分析しているだけの学術研究も見受けられるとか。波形やスペクトルを見るだけでは判断できないことが、音として聴けば一目(一聴)瞭然なので、必ず耳で聞く習慣を付けて欲しいとのことです。

今回のボードからはライン・レベルの信号が出力されているので、そのままアンプとスピーカーを繋ぐだけです。電極を腕に付けて手を動かすと、ゴゴゴゴッって感じの音が聞こえます。ホワイトノイズ的な雑音に混じってるんだけど、人間の耳と脳は優秀ですからね。レベルの低い脳波でも、聞き分け方を教えてもらったので、なんとか判別することができます。

音となると、MSPの登場ですね。コンピュータのオーディオ入力に繋いで、adc~をオン。
  信号来てますか?  → meter~
  波形はどんな感じ? → scope~
  大きく表示したい  → *~(あるいはscope~の設定)
  高域はカットしたい → biquad~(あるいはlores~など)
  周波数分布はどう? → spectroscope~
てな感じで、サクサクと処理が進みます。ライン入力を汎用のA/Dコンバータとして使っているわけですが、生体情報をオーディオ処理するのは、なかなか新鮮な体験です。もちろん、Max処理もJitter処理もOKだし、Gainerならマルチ・チャンネル処理も簡単。

といった感じで、敷居が高いと感じる生体センサーが一気に身近になるワークショップでした(これをどう発展させるかが次回への学生課題)。照岡さんの優しい語り口とは裏腹に、講義は刺激的な情報満載でクラクラするくらい。配布されたレジュメだけでも数ページに渡って説明&図版がビッシリ。その夜のちゃんこ鍋を囲んでの裏講義でも、示唆に富んだ話題の応酬で、お腹いっぱい、ごちそうさま、でした。

RocketFMで疑似マルチ・オーディオ

今回の知人クエストは22チャンネル・オーディオ出力の安価な実現方法でした。でも、真の意味でのマルチ・チャンネルではなくって、条件は以下の通りです。

・小ギャラリーで屋内展示する。
・22ヵ所から個別に音を出す。
・同時には1ヵ所から音が出れば良い。
・標準的な音質で小音量の音で良い。
・事前に録音した音を時系列に沿って再生する。
・経費はできるだけ安くしたい。

ちなみに、音の空間的な定位が重要だそうで、鑑賞者の位置は特定できないので、数個のスピーカーによるサラウンドはバツです。また、インタラクティブ処理ではないので、コンピュータは使っても使わなくても良く、必要であればコンピュータやソフトウェアは用意できるそうです。

さてさて、これをフツーに考えると、22チャンネルのアナログ出力を持つオーディオ機器(オーディオ・インターフェース、マルチトラック・プレーヤ、オーディオ・スイチャなど)を使うことになるかと思います。でも、これだけのチャンネル数になると業務用のゴツイものばかりで、なかなか安価な機材はありません。

この路線で、一番安いと思われる機材構成は、4系統のadat出力を持つM-AudioのProFire Lightbridgeを1台と、adat入力を8チャンネルのアナログ・オーディオ出力に変換するALESISのAI-3を3台との組み合わせでした。国内の実勢価格で合計18万円くらいです。安物のアンプ内蔵スピーカーを1台1,000円とすれば、総合計20万円ほどになります。もっと安い機材や、異なる仕組みでも安価な手法があれば、ぜひ教えてください。

で、ここからが本題なのです。「同時には1ヵ所から音が出れば良い」んだから、発想を変えて、周波数コントロールができるラジオ送信機が1台とラジオ受信機が22台あれば、一挙解決じゃん、と思ったわけです。すでに同様の実践例がありそうだけど、なかなかコロンブス卵的でしょ? ケーブル配線も不要になるしね。

実際の製品を調べてみると、Griffin TechnologyのRocketFMというUSB接続のFMトランスミッターがピッタリ。国内でも5,000円以下で購入できるようです。スピーカー付きFMラジオも安物なら1,000円前後でしょうから、全部で3万円以内に収まりそうです。正統派マルチ・オーディオ路線に比べると、かなり安くなりました(拍手!)。

rocketfm.jpg

問題になりそうなのは、RocketFMの送信周波数をどのようにコントロールするか?ですね。メーカーのWebサイトでは、AppleScript対応とかSDK提供といった記述はなかったので、明確には判断できないでいます(問い合わせ中)。

でも、周波数の設定はシステム環境設定で行なうとなっているので、きっとなんとかなります。Maxでもaka.mouseaka.keyboardを使えば、できそうでしょ? 理屈と実際が異なるのは、この世の常ですが(笑)。

【追記】初出時に「PocketFM」と表記していました。単なる勘違いでしたが、正しくは「RocketFM」です。ポケットに入るような小さなFMトランスミッターで、ロケットのような形をしていて、シャレてますね〜と思ってたんですよ(苦笑)。

FlashとWiiリモコン

今回の学生クエストは久々のWiiネタで、WiiリモコンをFlashで使いたい、というものでした。Flashはヤメとけば?と即答はしたものの、それじゃあんまりなので(笑〜AIR+Flexという建設的な意見もあり)、以下いくつかの方法を挙げておきます。いずれも単なる知識で、きちんと実証してません。何故ってFlashは持ってないからね(ウソ)。

まず、手前ミソなあたりから、aka.wiiremoteを使うとして、MaxとFlashとの通信を考えれば、次の2つの方法があります。

方法1:jit.qt.movieでswfファイルを読み込んで再生。flash_varメッセージやgetflash_varメッセージを使って、flashの変数を読み書きする。Jitter Tutorialの44番「Flash Interactivity」あたりを参照ね。書き出すFlashのバージョンやQuickTimeの設定に要注意

方法2flosc (Flash OpenSound Control) を介在させて、OSCをプロトコルとしてMaxとFlashを通信させる。Maxではudpsendやudpreceiveを使い、FlashではXMLSocketを使います。floscに付属するサンプルを見れば、なんとかなるでしょう。

Wiiリモコンのデータ・ハンドリングだけなら、専用アプリを使うのが簡単。

方法3OSCulatorからOSCメッセージを送り、floscを経由してFlashで受け取る。方法2のMaxをOSCulatorに置き換えたものね。OSCulatorは次のMIDI送信も可能。

方法4WiiToMidiThe Wiinstrumentを使い、MIDIメッセージをFlashに送る。Flashは標準でMIDIを受け取れる(よね?)。

FlashムービーをWebブラウザで再生するなら、ブラウザ限定プラグインあり。

方法5:Firefoxの拡張プラグインWiiRemoComを用い、JavaScriptでWiiリモコンの状態を取得し、JavaScriptからSetVariable()関数でFlashへデータを送り込む(のかな?)。

どうせなら、Wii本体のインターネット・チャンネルでやれば?ってことも考えられます。

方法6:WiiのWebブラウザ(Opera)は、標準でWiiリモコンの状態をJavaScriptで取得可能。それがwindow.opera.wiiremoteオブジェクトで、このページの後半に情報が載っています。細かなデータは取れないけど、解釈されたデータは使い易くなっています。

他にもありそうですが、面倒なのでこの辺で切り上げます。こんなにイロイロあるのは決定的な解決方法が無いからで、やっぱり馬鹿なんです。いや、手足をもがれた可哀想な立場と言うべきかな。セキュリティ命ですから(笑)。

ともあれ、一番手っ取り早いのは、方法4やOSCulator(下図)あたりでのMIDI送信のような気がします。ただし、MIDIのコントロール・チェンジの場合は、一般に7ビットなので、精度が要求されない用途向きね。

osculator.png

GPS-CS1KのログをMaxで解析

今日の学校クエストは、GPS-CS1KのログをMaxで解析したい、ってことでした。GPS-CS1KはSONY製の小型で安価なGPSレシーバで、これを持って歩き回って(あるいは自転車や自動車で走り回って)、後でその行動を何らかのアート表現に結びつけるってことらしいです。

gps-cs1k.jpg

それで、なんか面倒っぽいなっと思ってたら、実際には意外と簡単でした。まず、GPS-CS1Kを持って適当に歩き回った後、GPS-CS1KをMacにUSBケーブルで繋ぎます。これでデスクトップにディスクとしてマウントされるので、そのディスクの中からログ・ファイル(GPSフォルダにある.logファイル)をMacのハード・ディスクにコピーします。このログ・ファイルは単純なテキスト・ファイルなので、適当なテキスト・エディタで開くことができますね。内容の一部はこんな感じ。

$GPGGA,081906,3523.1434,N,13637.3032,E,1,04,07.2,00079.7,M,035.0,M,,*4D
$GPGSA,A,3,11,16,25,27,,,,,,,,,14.0,07.2,12.0*04
$GPGSV,2,1,05,25,44,245,51,27,42,276,50,16,13,123,47,32,,,43*4A
$GPGSV,2,2,05,11,50,219,52,,,,,,,,,,,,*44
$GPRMC,081906,A,3523.1434,N,13637.3032,E,000.0,000.0,210907,,,A*7C
$GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D

このデータはNMEA-0183っていうフォーマットだそうです。本家はココらしいですが、他所様の英語解説日本語解説を拾い読み。ちゃんと仕様を読んでいないので間違ってるかもだけど、GPS-CS1Kのデータは、若干逸脱しているような気もします。

次に、Maxでログ・ファイルを読み込みますが、その前にログ・ファイルの拡張子を.txtに変えておきます。これは、MaxのTextオブジェクトが、明らかにテキストであるファイルしか開いてくれないからです。これはちょっと融通が利かない感じで、イマイチですね。

Textオブジェクトに読み込んだログは、lineメッセージで1行ずつ出力して解析します。ただし、各行はカンマ区切りなので、tosymbolとfromsymbolというオマジナイをかけてリストに変換します。なぜそうなるのか?と聞かれても、よく分からないんですが(笑)、知っている人教えてください。

後は、NMEA-0183フォーマットに従って、routeでデータを種類ごとに振り分けて、unpackで要素ごとに取り出すだけです。ここから先は目的次第ですね。元データがテキスト(ASCII表現)だから、数値処理する場合は、時刻とか単位の取り扱いに少々工夫が必要ね。基本パッチはコレです。

gps-01-logpat.gif

GPS-CS1Kは記録オンリーで、リアルタイム情報を外部に送れない(よね?)ので、私的にはナンジャラホイです。しかも、測位は15秒間隔で精度も10メートル程度らしいので、かなり大まかな情報しか得られません。ま、旅のお供にデジカメと一緒に使ってね的な位置付けの製品なので、文句を言う筋合いじゃないですけどね。

では、何でこんなことやってるかと言うと、もうすぐIAMASではモチーフ・ワークという1年生全員が参加する1週間のワークショップがあって、今回はGPSがモチーフだから、なんですね。全員と言っても50人しかいないんですが、普段はそんな大人数を相手にしないから、準備が結構大変(軟弱)。ただ、久々にMaxネタができたのでウレシイ(笑)。

本当は、のA-GPS付き3G iPhoneが登場して欲しいところですね。そうそう、iPhone勝手アプリも登場したNavizonってのもあるので、必ずしも人工衛星に頼らなくていいかもですね。と、まぁ、何にしてもiPhoneに流れちゃうのは、ビョーキっぽいな〜。