詳しくは書けない例の件で、恐る恐るaka.objectsを試してみたところ、すべてバッチリ動作しました。徹底的に調べた訳じゃないものの、ヘルプ・パッチの範囲では問題ない感じ。lcdが少々バグってるらしく、表示がおかしな箇所があったけど、それはそのうちフィックスされるでしょう。
詳しくは載せられないので、この画像を作成したパッチはこちら。
と言う訳で、後方互換性（上位互換性）は、なかなかのもののようです。エクスターナル・オブジェトを制作している人は、ひと安心ね（これまた、保証できないけどね）。aka.iphone.appsは結構手直しが必要だったり、サポートされていない機能があったりして、ちょっとブルーだったのですが、こちらは大船に乗ったキブンです。
【追記】でも、UI系のオブジェクトは問題が生じる場合があるみたいです。
詳しくは書けない例の件で、Unicodeサポートはほぼ問題がないレベルになりそうです。今のところ表には出せないステイタス・レポートを、孤独に書きまくっています（笑）。まぁ、日本語サポートしてよと長年言い続けた手前、ボランティアとしてがんばっている次第。
それで、Unicodeと言えば普通は（私だけ？）UTF-16を連想するんだけど、少なくとも最初のリリースではUTF-8のみになりそうです。「赤」なら0x8D64じゃなくって、0xE8 0xB5 0xA4ってことね。
もっとも、テキスト入力とかコピペとかなら、文字コードを意識する必要はありません。サクっと入ります。しかし、バイナリー入出力とかWeb系の用途なら、文字コード（エンコーディング）が重要なので、事前情報としてチョコっと入れておきます（でも、保証は何もありませんよ〜）。日本語（インターナショナル？）アプリを作ってる人は、ご留意あそばせ。
あと、プレーンな文字ハンドリングらしく、「get愛」みたいなメッセージも何気なく動きます。ちょっと感動。
さすがにMake:らしく、その手（どの手？）の人は皆チェックしているようで、昨日は世界各地から読んだよ〜メールが舞い込んでいました。いろんなブログ等でも紹介されているみたいですが、その中からCreate Digital Musicの「aka.objects Maker and Breadboard Bandmaster Interviewed」を逆紹介。
この記事はインタビューの紹介だけでなく、テクノロジーのダーク・サイドや言語の問題にも言及していて、そうなんだよね〜と意を強くしちゃいます。Maxに対してPdの優位性もあると、しっかり反論している点も素晴らしい（でも、何を使うかは本人の勝手、とも補足されている）。ただ、赤松はThe Breadboard Bandのバンマスじゃないですし、ライブ半田リングじゃなくって、ライブ・ワイヤリングですからね〜と日本語で書いても伝わらない（＝言語の問題）。
写真＋ちょいとコメントだけみたいな記事が多いことは、昨日のポストでも書きましたが、このサイト（＆姉妹サイトのCreate Digital Motion）は、読み応えのある記事が多いのでお気に入りのひとつです。
それで思い出したのは、ここ何年か、イージーな紹介サイトや、いわゆる「まとめ」サイト、WEBベースのRSSリーダーなどが増えていて、WEB検索しても同じような情報ばかりが出てくること。それらは何らかの観点に基づいて「まとめ」てあるので、サイトとしては意味があるんだけど、単語ベースのWEB検索からすれば、意味のある情報に辿り着くのを困難にしている。WEB検索エンジンの能力不足とも言えるし、セマンティックWEBはまだまだ遠いね〜とも言えますね。
Make:にインタビュー記事「“Made in Japan” Interview: Masayuki Akamatsu」が掲載されました。The Breadboard Bandのこと、Wiiリモコンのこと、iPhoneのこと（コンピュータ終焉論を含む）、Max/MSPのこと（Max 5を含む）、日本のテクノロジー事情などなど、いろいろ喋ってます。
写真orムービーにちょっと解説orコメントを加えたイージーな記事が多い中（Make:はマシなほうだよね）、ポートレイト写真が添えられているだけで、ひたすらテキストが続く硬派な記事だから、読み応えタップリ（なハズ）。全編英語なのが涙ですが、がんばって読んでみてください。
インタビューアは、週イチで日本のテクノロジー・カルチャーを紹介している「Made in Japan」のコラムニスト、Mike Dixonさん。この方は音楽家でもあって、aka.wiiremoteを通じて赤松に興味を持っていただいたみたいです。多謝多謝！
懐古趣味またはジジイ趣味ながら、昔々「コードリソース」という本を書きました。その中で、AfterDark（スクリンー・セーバ）のモジュールのプログラミング方法を解説していて、その題材がオーディオ入力の音量をピクセル化でした。昨日公開したavTracks.appと基本アイディアは同じ、と言うか、これを思い出しながら作ってたワケね。
同じネタの使い回し、進歩ナシという気もしますが（笑）、新しい皮袋に古い酒を入れる（あるいは、古い皮袋に新しい酒を入れる）とどうなるかは、とっても興味があることです。aka.iphone.appsで試していることの半分はソレですね。ただし、もともとのマタイ伝（たぶん）では、新しい酒は新しい皮袋でなくっちゃね〜ってことらしいです。
最近お気に入りのMacBook Airも素晴らしいけど、iPhoneに比べれば古い皮袋っぽく思えてしまう。これは、ポケットに入らないことキーボードがあることが大きいんじゃないかな。特に、キーボードが諸悪の根源のような気がする。だから、悪評が明らかに予想されながらも、Blackberryのような物理的キーボードを排したiPhoneはエライ。そして、次のApple製品はキーボード・レスだと勝手に予想中。
ここにこそ未来への意思があると思うよ。オリジナルMacintosh（あるいはLisa、Alto）のマウスによって、操作のためのキーボード（テキスト）を排したように、次の段階として、メッセージのためのキーボード（テキスト）を排したのがiPhoneだと思うワケね。次なるものが、単純にオーディオ・ビジュアルなのかどうかは、まだ分からないけどね（それが分かれば苦労はしない〜笑）。これはコンピュータ終焉論の観点のひとつだと思う。
と、話がソレまくっていますが、この本ではリブチンスキー効果のPremiereプラグインとか、スクリーン上のピクセル値を読み取るMaxオブジェクトなども作っています。先日、世界で初めてMaxで画像解析をしたのはオマエだ〜とRichard Dudas氏に言われて、ハテ何のことかと思いきや、このオブジェクトのことでした（はーと）。
なお、この本は1994年という大昔の出版なので、今や実用性はゼロに近いものの、メディア考古学的な価値はあるかもね。図書館でチェキット！
Maxではサクサクとプログラムを作って行けるのが素晴らしいのですが、そのうちにパッチが肥大化・複雑化して音が途切れたり、フレーム・レイトが落ちたりってことが多々ありますよね。他のプログラミング言語でも同じようなことが起こりますが、Maxの場合は簡単にプログラミングできるが故に、下手なプログラムを作ってしまいがちですね。しかも、パッチ・コードがスパゲッティ状態で、どこをどう直せば良いか分からない。下手な鉄砲も数撃ちゃ当たる、とは限らないですから。
このような場合の対処法は、すっきりしたパッチに作り直すことがキホン（美しいパッチは美しく動作する！）ですが、もうひとつ役立つ（かもしれない）ことは、パッチの実行状態を分析することです。ただし、現在のMaxは分析機能をほとんど備えていないので、他のツールを使うことになります。
まず、手軽に試せるツールは、アクティビティモニタです。アクティビティモニタを起動して、MaxMSPを選んで表示メニューの「プロセスをサンプル収集」を選びます。これで、MaxMSPが実行しているプロセスを分析した結果が表示されます。この表示は階層化されているものの、スレッドの山盛り状態なので、これを読み解くのは結構大変です。
もう少し賢い（いや、とっても賢い）ツールがDeveloper Toolsに用意されていて、それは/Developer/Applications/Performance ToolsにあるShark（サメ！）です。Sharkを起動したら、Time ProfileのProcessとしてMaxMSPを選んでStartボタンをクリック。しばらくすると分析結果が表示されます。以下の例では、jit.argb2uyvyとjit.slideの実行時間が長いので、このあたりを改善すればパフォーマンスが向上するかも？といったことが分かります。
SharkはMac OS Xの至宝のひとつで、それだけに高機能・多機能なSharkを使いこなすのは大変です。ただ、ヘナチョコ開発者の私でも適当にいじっているうちにヒントが見つかることが多いので、トライする価値はあります。Sharkの他にもDeveloper Toolsには、メモリ関係やOpenGL関係などの分析ツールが揃っていますから、イロイロと試してみると良いと思います。下手な鉄砲も道具を揃えれば当たる（かもしれない）ってことです。
ともあれ、Max5にもパフォーマンス分析ツールが備わって欲しいですよね。強く強く希望（って日本語で書いても届かない〜笑）。
MaxMSP-MLのトッピックなんだけど、ネットワーク経由でスリープしているMacを起こすにはどうするの？って話が出ていました。スリープさせるのはaka.powerとudpsend/udpreceiveあたりを使えばバッチリなのですが、寝た子を起こすのはaka.powerでもできない。MaxもMacも動いていない訳ですからね。
ところが、Wake-On-LANという技術があって、特殊なパケットを送り込めばMacがスリープから目覚めるそうです。そんなこと知らなかったのでビックリしつつ、Wake550というユーティリティを使ってみたら、ちゃんとMacBookが目覚めるので、またビックリ。
そこで、Wake550が使っているPerlスクリプトを読み解いて、aka.datagramとudpsendを使って実験してみると、これまたお目覚めしてくれるので、3度目のビックリでした。Perlは使ったことがないので、間違っているかもしれないけど、取り敢えず動いています（笑）。素晴らしい〜！
テスト・パッチはコレね。もちろん、MACアドレスやブロードキャスト・アドレスは、使用する機材やネットワーク環境に合わせて設定してください。Wi-Fiはダメみたいですよ。iPhoneもダメでした。
wakeonlan-testpat.zip
久々の学生クエストで、Maxで利用できる物理シミューレション（特に力学シミュレーション）用のMaxオブジェクトを調べてみました。と言っても、Web検索しただけですけどね。
物理シミューレションって何？って人は、下記のMathieu Chamagne氏が公開しているデモ・ムービーを見れば、その動作の概要が分かります（これだけじゃないけど）。ここにはLemurを使ったムービーもありますね。Lemur自体も力学シミュレーションを内包しているので、Lemurでボヨンボヨンした情報を使う豪快な手法も考えられます（笑）。
PMPD Cyrille Henry氏が開発した物理シミュレーション・ライブラリ（Pd用）
PMPD for Max Ali Momeni氏によるMPDのMaxへの移植（Max 4.5用）
PMPD library Mathieu Chamagne氏によるPMPDのMaxへの移植（Max 4.6用）
mc.pmpd Mathieu Chamagne氏が作成したPMPDのアブストラクション（簡易利用パッチ）
MSD Nicolas Montgermont氏が開発した物理シミュレーション・ライブラリ（Pd/Max用）
jit.gl.lua + luaODE 以前に紹介したWesley Smith氏が作成したLua言語およびODE（力学エンジン）のMaxへの移植
他にもあれば教えてください。
ちなみに、質問をした学生クンはmotionExpress（IAMASの古堅真彦氏開発）の力学エンジン部分をMaxに移植するそうなので、こちらも楽しみに待ちましょう。
最近はMax関係の記事が少なくって、iPhoneばかりとお嘆きかもしれませんが、当分この傾向は続くかも。もっとも、このサイトは個人サイトじゃないので、他の人も面白い話題があればお願いしますね（趣旨＆景観に配慮して、公序良俗に反しない、ってことで）。
ただ、iPhoneを持っていないから関係ないって思うのは早計ね。あと何年もしないうちに、誰もがiPhone（あるいは同種のデバイス）用の作品を作ってますから。それは、数年前に多くの人がMax（あるいはプログラミング言語で）で音楽や映像を作るとは思っていなかったことと同じ。
Maxに関しては、キブンはMax 5待ちで、特に基本環境的なことは今やる気になれません～。それに、少なくともランタイムがiPhoneに載らない限り、プロトタイピング以外にはMaxはiPhoneに縁がないです。もちろん、これまでもMaxは極めて優秀なプロトタイピング・ツールだったので、それはそれで正解ですけどね。私もMaxでアルゴリズムを作ってから、iPhoneのコードを書いてます。
それで、MaxのオブジェクトをC/C++で書いていた時も感じていたんだけど、テキスト記述型言語でプログラミングしている時は、頭が非常に活性化してハイな状態になる。それに対して、Maxでプログラミングをしている時は、頭は落ち着いていてロー（と言うかクワイエット）な状態になる。
これって、右脳／左脳、芸術野／計算野、鳥瞰的／虫瞰的って話なんだろうけど、なかなか面白いですね。Maxがアーティストに人気があるのは、メディア機能が強力なだけでなくって、そんなところに理由があるような気がするな。だから、ProcessingとかFlash（ActionScript）ってダメなんじゃない？
もっとも、右脳（芸術野）だけではアルゴリズムは作れない。これがアーティスト志望の人がプログラミングから脱落する最大の原因だと思う。なので、一般教養科目がほとんどないIAMASでも、数学（＋英語）だけはあるし、DSPコースのワークショップでも半分はテキスト記述型言語（今年度はProcessingとPython）を使っている訳です。
誤解のないよう補足しておくと、左脳（計算野）だけでもアルゴリズムは作れませんよ。右脳と左脳の両方が必要です。そこで、Maxは両脳を明確に刺激するようになっていて、バランスが取れた状態（やや右脳寄り？）で物事を進める仕組みになっているような気がするな。それは後付けの見方かもしれないけど、Maxという存在自体がそのようになっているんだと思う。
ちなみに、iPhone（と言うかOS X/Cocoa）の開発言語であるObjective-Cは、雰囲気的にMaxに近いです。Objective-CはCのスーパーセットなので、そんなことは本来ナイのですが、実際にプログラミングをしている時の頭の働きはMaxっぽい印象が強いですね。どちらもオブジェクト指向だからってこともあるし、いい加減にコードを書いても、それなりに動いてしまうところも似ています。
だから、次世代MaxはCocoaベースになって、Objective-Cでガンガンとオブジェクトを書けるようになって欲しいな。iPhoneでのランタイムあるいはフルセットも、Cocoaベースなら簡単に移植できるだろうしね。これ、強く希望！（と日本語で書いても、C74には伝わらない〜笑）。
で、タイトルの問いかけに戻って、Maxはプログラミング言語か？に対する答えは、Maxはプログラミング言語である！なのです。それも、芸術と計算が混じり合う極めて希有な存在（だから両方が必要）ですね。この特異性と有用性は、他の言語を使ってみると、よく分かります。そして、Objective-Cはこれに近くって、iPhone（と言うかOS X）という未来があるのだから、そろそろObjective-Cを始めてもいいんじゃない？という提案でもある訳です（やっぱり、ソコかぁ？と言われそうですが〜笑）。
時々同じような質問が来るので書いておきますね。aka.wiiremoteのバージョン1.0B7からextraoutputメッセージが追加されていて、これをオンにする（extraoutput 1を送る）ことで、加速度センサーのキャリブレーション情報やIRセンサーの生データが得られるようになっています。ヘルプ・パッチの右側下寄りにあるothersサブ・パッチを開くと、これらの数値が確認できます。
Wiiリモコンの先端に埋め込まれているIRセンサーは、実際には赤外線カメラで、センサー・バーには両端に赤外線LED（赤外線投光器）が仕組まれています。しかも、このIRセンサーが優秀で、赤外線カメラは1027×768ピクセルの解像度を持っていて、4点までの赤外線光源の位置を100Hzの周期（0.01秒の時間間隔）で割り出してくれます。IRセンサーが画像解析してくれるので、コンピュータではCPU負荷がほとんどなく（Bluetooth通信だけで）、4点もの位置検出ができる訳です。
一般的な用途では、センサー・バーを固定しておいて、Wiiリモコンを手に持って動かしますが、この逆もできます。つまり、Wiiリモコンを固定しておいて、センサー・バー（あるいはロウソクなど何らかの赤外線光源）を動かすことになります。これで何ができるのかという実例は、Johnny Chung Lee氏のWiiプロジェクトが有名ですね。マイノリティ・レポートばりに空中で指を動かして映像を操ったり、机に投影した映像にペンで絵を描いたりしています。ヘッド・トラッキングしたVR映像も奥行き感タップリで楽しめます。
Lee氏はC#用のライブラリを使っているそうですけど、aka.wiiremoteでも情報取得までは実装しています（それ以上はオブジェクトの仕事ではないからね）。前回の告知ではサラっとしか書かなかったので、気が付いていない人が多いみたい（笑）。
ともあれ、赤外線光源を使うなら、これでいろいろと応用できそうでしょ？ 天井にWiiリモコンを取り付けて、赤外線LEDを付けた人の位置を検出するなんて朝飯前。物体（人体）上に複数の赤外線光源（あるいは反射材）を取り付ければ、回転やら距離の検出もできるし、複数のWiiリモコンを使ってもいいしね。