Mirrorscopeみたいな処理はiOS 4.0以降のAVCaptureナンチャラを使うんだけど、開発中に困惑したのがビデオ入力の画像解像度などを決めるプリセットの挙動。デバイスの差異を吸収するためにプリセットとして抽象化されてると勝手に思ってたら大間違い。なかなか一貫性がないので表にまとめました。初代iPhoneはiOS 4.0が対応していないので省いています。
結論的には、どのデバイスでも同一の解像度が得られるプリセットはないし、解像度の大小関係も一意的に決められませんね。特に3Gが鬼門になっています。Mirrorscopeではがんばって全デバイスに対応してますけど、なんか理不尽な感じが拭えません（笑）。
それに、これまた抽象化の都合のいいところで、次のアップデートでは数値が変わっちゃうかもしれないですね。せめてプリセットに対して解像度を返してくれるメソッドがあるといいんですけどね（ないよね？＞誰となく…）。
11/12から11/14までの3日間に渡って韓国ソウルのIDAS (International Design school for Advanced Studies) でMobilizingのワークショップを行ないます。IDASは初めて訪問しますが、Hongik University（弘益大学校）のメディア・デザイン系大学院で、ソウル郊外にあるそうです。とある人がおっしゃるには雰囲気はIAMASに似てるとか。楽しみです。
先月のVSMM2010でのワークショップやHongik大学でのレクチャーが、いずれも短時間だったものの、とても好評だったので今回の招聘に繋がったようです。このように動きが早いのが彼の国の原動力なんでしょうね。一方で何かとカオスだったりして、それはそれで楽しいのですが、此の国とは違う刺激があります。
久々のファクトリー探訪、今回はiOS 4.1のファクトリー・イメージ。手順はこんな感じ。
結果的には4,979個のpngファイルが得られました。一部の@2xのpngファイルはエンコード方式が変わったのか、デコードに失敗しているみたいです（新しいデコーダってある？）。ともあれ、思いがけない画像があったりして、楽しいですよ。iOSや標準アプリケーションのGUIパーツは研究価値大だし、絵文字なども楽しいですね。
Xcodeではプロジェクトごとのbuildフォルダに作業用の中間ファイルが保存されます。これは2回目以降のビルドを高速化するなどお役立ちファイル群なのですが、自動的に消去されるわけではないので、サンプルコードを試しただけでも残ってしまう。このフォルダはそれなりの容量を占めるので、塵も積もれば山となっちゃいます。
そこで、こんなAutomatorワークフローを作ってみました。すべてのbuildフォルダを探してゴミ箱に入れるというもの。ワークフロー自体は簡単ですけど、実行してみてビックリ。なんと全buildフォルダを集めると1GBを超えていました。馬鹿になりませんね。
当然のことながら、ゴミ箱を空にする前には内容の確認が必要ですよ。たまたまフォルダ名がbuildだった重要なファイルまで消去しちゃわないようにね。ちょっとした小ネタでした。
先日のVSMM2010でMobilizingのワークショップを行なってきました。MobilizingはパリのFdMで開発が始まり、最近はIAMASも協力しているiOS用の新しいプログラミング言語です。僅か2時間半ほどのワークショップだったので、Mobilizingの紹介と体験くらいしかできなかったものの、それでもプログラミングが苦手と言う学生さんも変なアプリを作っていました。
Mobilizingの特徴は、ずばり、ビギナー＆アーティスト向けの超簡単言語ってことですね。どれくらい簡単かと言うとこんな感じ。
// IDの宣言
int ship = 0;// 初期設定
void setup()
{
// 船を作る
ship = triangle(0,0, 30, 100, -30, 100);
}// 処理更新
void update()
{
// 船を動かす
float x = AccX * 10.0 + getPositionX(ship);
float y = -AccY * 10.0 + getPositionY(ship);
setPosition(ship, x, y);// 船の向きを変える
setRotation(ship, AccGravityY);// タッチされるとその位置に船を動かす
if (TouchCount > 0)
setPosition(ship, TouchX1, TouchY1);
}
これだけ（主要コードは8行だけ）で、iPhoneを傾けると船に見立てた三角形がスルスルと動いて行きます。船先はちゃんと進行方向を向くし、画面からはみだした時はタッチで呼び戻せます。Objective-CとCocoa Touchに格闘している人からすれば、有り得ないくらいで、笑うしかないですね。Processingをさらに簡易にしたような感じかな。
MobilizingはC言語風のスクリプトを書いて、パーサ（インタプリタ）込みでビルドしてiOSアプリを作っちゃいます。つまり、通常のXCode＋iOS SDKを使うので、シミュレータでもデバイスでも動作して、App Storeにも出すことができるという優れモノ。ただし、機能は限定されいて、洗練されていない部分もあります。まだベータ版の段階で鋭意改善中ってワケで、いずれオープソースのフリーウェアとしてリリースされる予定です。
今回はヨーロッパ圏外では初のワークショップで、特にアート系の人からは驚嘆かつ大好評をいただきました。より深く行なって欲しいとのオファーもいくつかあって、さっそく来月に3日間のワークショップを開催することに。こちらがビックリするくらい反応が早いですね〜
【追記】いくつかお問い合わせをいただきましたが、現時点では公開時期は決まっておりません。せめて、と言うことで、ワークショップでのスライド（PDF）を公開します。現在実装されている機能の概要（10ページ目）なども載っています。
VGAアダプタなどDockコネクタを使用するアプリケーションを開発する場合は、そのデバッグがとっても面倒です。何故って、XcodeのデバッガはDockコネクタに接続するUSBケーブル経由で情報を遣り取りするから。つまり、Dockコネクタは別のデバイスに使われているので、デバッガが使えなくなるわけです（涙）。
そこで便利なのが、Kensingtonの4-in-1 Car Charger for iPodってアダプタ。本来は自動車のシガーソケットから電源を取るためにUSBケーブルが備わっていると同時に、別のDockデバイスを使うためにメスのDockコネクタが備わっているという逸品。
この手のアダプタは一部手抜きだったりしますが、この製品は全ピン配線されているらしく、VGAアダプタを繋いで外部ディスプレイに映像出力しながら、デバッガを動かすことができました。これでビルド＆実行のたびにケーブルを替えたり、実行中にデバッグ作業ができない苦痛から解放されます。
VGAアダプタ以外にも、Dockアダプタを使用する外部アクセサリー用のアプリケーション開発にも使えるハズね。対応製品としてはiPodやiPod nanoしか記載されていないものの、iPadでもiPhone 4でもバッチリでした。
ただし、これは古い製品らしく、今では入手困難みたい。もしどこかで見つけたら即ゲットですよ。いずれ、Xcodeもワイヤレス・デバッグに対応すると思いますが、それまではこのアダプタが欠かせません。
10/20は韓国ソウルで開催される国際学術会議VSMM2010（Virtual System and Multimedia 2010）でMobilizingによるワークショップを行います。近くにお住まいの方、会議に参加される方は、ぜひ遊びに来てくださいね。
このMobilizingはiOS用の新しいプログラミング言語（？）でアーティスト向きに可能な限り簡単に開発ができることが目指されています。逆に言うと、機能的には絞り込まれていて何でもできるわけではありませんけどね。まだまだ発展途上ですが、近い将来にオープンソース・フリーウェアとして公開が予定されています。
Mobilizing Hands-On Workshop
Date: October 20th, 2010
Time: 9:10 – 12:00
Place: COEX, Seoul, Korea
ちなみに、MobilizingはパリのFdMで開発が始まり、最近では日本からも参加しています。昨年4月に日仏アート・アライアンスを作ろうと話していたのが、こんな形で動き始めている次第です。
また、FdMのボスであるジャン＝ルイ・ボワシエさんの公開講座が10/23にあります。私は渡航中で参加できないのですが、興味のある方は参加されてはどうでしょうか？
ジャン＝ルイ・ボワシエ公開講座「モバイルスクリーン」
日時：2010年10月23日（土）13:10〜
会場：名古屋芸術大学 西キャンパスB棟2F大講義室
【追記】諸事情によりボワシエ氏の来日が中止になり、代わりに同氏の映像資料の上映や研究者による解説が行なわれるそうです。
MIDIが機能的に不十分なのは周知として、かと言って代替えの決め手がないのが昨今の音楽業界のツライところ。有力候補はOSC (Open Sound Control) ですが、これもちょっとパッとしない。でも、まぁMaxもSuperColliderも標準対応なのでOSCを使っちゃうワケですが….
それでiPhoneやiPad用のOSC対応アプリケーションを作る場合には、OSCでの送受信を行なうライブラリ（フレームワーク）を使うのが簡単。OSCライブラリはいくつかあるので、ちょっとまとめてみました。
この表でSuporrted Data Typesの記号の意味はOSCの仕様に従っています。また、Response Time（応答時間）は、MaxからiPhoneにOSCメッセージを送り、それに応じたiPhoneからOSCメッセージが送られてくるまでの時間をミリ秒単位で計測し、0.1秒間隔で1000回行なった結果の平均です。つまり、通信は2回行なわれていて、Maxでの送受信にかかる時間も含まれています。片道なら、この数値の半分ですね。Standard Deviationは1000回分の計測値の標準偏差です。
さて、表にまとめたものの、これでますます悩ましくなりました。以下、簡単にコメントしておきます。
ObjCOSCは実測値は優秀ですが、基盤となっているOSC-Kitが古い時代のものでサポートされないそうなので、将来に渡る使用には不安が残ります。ObjCOSC自体もWEBサイトが消滅しているようです。
VVOSCは機能的には優れているんだけど、処理時間も標準偏差も大きいのがイケてません。他のライブリに比べて4倍くらい時間がかかって、しかもバラつきが大きいので演奏的なリアルタイム性の高い用途には向かないでしょうね。
bboscは処理時間も短く、機能的にもまずまずなのですが、計測中に1〜2秒間無反応になることがありました。私のコーディングがイマイチなのかもしれませんが、WEBサイトにはサンプル等が乏しく、原因は解明できていません。このままじゃちょっと怖くて使えませんね。
libloも処理時間や機能は良好とは言え、こやつはC言語インターフェースなので、Objective-Cと混在させて使うための知識やテクニックが必要になります。プログラミングの知識が少ない初心者は手を出さないほうが無難ですよ（これに限らず、私に質問しないでね〜）。
残るWSOSCはOSCメッセージの処理だけでデータの送受信機能を備えていないので、計測をしていません。OSC-Kitは前述の理由で却下。ofxOsc、oscpack、WOscLibなどのC++ライブラリは個人的にはキライなので、これまた却下。
と言う訳で、決定打を見いだせないままのレポートになっちゃいました（残念）。内容的な間違いや新しい情報があれば、ぜひぜひご連絡下さいね〜。
iPhoneの内蔵カメラの扱いは紆余曲折あって、多くのデベロッパーが苦労（というか快楽？）しています。しかし、先日大きな動きがあったので、これまでの経緯を含めてまとめておこうと思います。
第0章
iPhone OS 2.0からiPhone OS 3.0までの公式SDKでのAPIとしては、ユーザが写真を撮るためのユーザ・インターフェースを表示し、撮影した後の画像を取得できる機能が提供されていました。これらのAPIだけではアプリケーション側からカメラの画像がリアルタイムに取得できず、ライブ・ビューに他の画像などを重ねることもできません。いずれもAR的手法を実現する上で欠かせない機能なんですけどね。
ただし、非公式には存在しているAPIが結構沢山あって、柔軟なObjective-CとCocoa Touchの特性故に、実際に利用することもできます。このようなハック的手法で、公式にはできないようなカメラ・アプリケーションがいくつか発表されていました。例えば、私のDecorReality（リアルタイム・プリクラ風のビューワ）もそうですし、TC50でのセカイカメラが驚きをもって迎えられたのは、そんな理由もありました。
もっとも、非公式APIを利用したアプリケーションはAppleの審査を通らない可能性があります。特にiPhone OS 3.0以降は審査が厳密になったようで、ほとんど許可されなかったみたい。このためにiPhone OS 3.0でのアップデートができなかったカメラ・アプリケーションも少なくありません。2.0時代に公開していたSnappy（動き、音、時間などで自動撮影）もそうでした。
第1章
フツーの写真撮影以外はほとんど何もできない公式APIは、iPhone OS 3.1においてようやく拡張されます。新しく追加されたAPIには以下のような機能がありました。
これらのAPIが登場したおかげで、Snappyを復活させ、セカイカメラも目出度くリリースできました。技術的に可能ということと、App Storeで公開できることとは、全然別のレベルのお話なのですね。そして、TransReality（ライブ・ビューのリズミカルな変形）やAirCamera（撮影をネットワークで制御）のようなアプリケーションも比較的簡単に実現できるようになりました。
しかし、iPhone OS 3.1においても、ライブ・ビューのリアルタイム取得は公開されませんでした。つまり、カメラが今どのような映像を捉えているかが得られないので、ビデオチャットやリアルタイム画像解析などはできないわけです。
第2章
2009年12月になって、唐突にUstream Live Broadcasterなどのライブ映像系のアプリケーションがApp Storeで公開されるようになります。これらは非公式APIであるUIGetScreenImage()（スクリーン全体の画像を取得）を使っていました。このAPIにより、擬似的ではあるものの、ライブ・ビューのリアルタイム取得ができます。さらにデベロッパー・フォーラムではUIGetScreenImage()を使っていいよとのAppleからのメッセージも掲載されちゃいました。
実はこのUIGetScreenImage()は以前から存在が知られていたんですね。私のアプリケーションでもMirrorscope（鏡像などライブ・ビューに特殊な視覚効果を与える）などは、1年以上前にサブミットしていたものの、何度もリジェクトの憂き目に合っています。Appleの転身により最近になってリリースできたとは言え、ちょっと不条理なキブンですね。
ここで不可解であるのは、SDKなりOSなりのバージョン・アップをすることなく、非公式APIの使用を公式に認めた前例があまりないことです。このあたりの事情には裏話もあるようですが….ま、少しずつでも前進している現状を評価することにしましょう。
ともあれ、ライブ・ビューの取得ができるようになったので、ARToolkitやPTAMなどの画像解析系のAR技術は今後すぐにでも一般化していくでしょうね。つまり、iPhoneでのARは新しいステージに突入したことになります。QRコードなどの単なるマーカー認識も、カメラをかざすだけで済むので実用性が高まるのは間違いありません。
最終章？
以上のようにUIGetScreenImage()は、iPhoneのカメラ・アプリケーションの応用範囲を飛躍的に広げます。もっとも、このUIGetScreenImage()は本質的なライブ・ビュー画像の取得ではないので、画像取得のタイミングやオフスクリーンでの画像取得などの問題が残っています。また、現在のAPIではフォーカスや明度などのカメラ機能の調整もできません。
このようなカメラ機能の完全解放を切に望みたいところですが、それがiPhone OS 3.2になるのか、iPhone OS 4.0になるのか、はたまた永遠の夢となるかはJobs神のみぞ知る、ですね。しかし、OSが完全開放されているAndroid勢力が、iPhoneデベロッパーの援護射撃をしてくれるハズです、たぶん。
【追記】iOS 4.0のAV Foundationに含まれる機能によってカメラ機能の完全解放は（ほぼ）達成されました。
先の記事「iTunes Connectの言語問題」の続きで、iTunes Connectのデフォルト言語が日本語である場合は、悲惨な単純反復作業をちょっとでも軽減したいですよね。だって17回も同じことをしなきゃならないから！
そこで以下は、新しいiPhoneアプリケーションをサブミットする場合に、どのように設定項目を入力するかという戦略です（ちょっと大袈裟）。前提としてはデフォルト言語が日本語で英語でのローカライズのみを行う場合ですが、他のローカライズを行う場合も同じ要領です。
Application Name
日本語名があれば、必ず日本語で入力する。
ローカライズ時に言語ごとに変更可能だが、一旦設定すると変更できない（アップデート時には変更可能）。
Application Description
日本語で入力する。
ローカライズ時に言語ごとに入力できる。ローカライズ時には空欄となり、デフォルト言語での説明が自動的にコピーされるわけではない。設定後も変更可能。
Application Keywords
必ず日本語で入力する。
ローカライズ時に言語ごとに変更可能だが、一旦設定すると変更できない（アップデート時には変更可能）。ローカライズ時には空欄となり、デフォルト言語でのキーワードが自動的にコピーされるわけではない。
Application URL
Support URL
Support Email Address
英語でのURLやアドレスを入力する。
ローカライズ時にデフォルト言語での設定が自動的にコピーされるので、再入力しなくて済む。すべてのローカライズが終われば日本語でのURLやアドレスを設定する。設定後も変更可能。
Large 512×512 Icon
日本語でのアイコンがある場合も英語でのアイコンを登録する。
アイコンは共通でローカライズごとに設定できない。設定後は変更可能。
Primary Screenshot
Additional Screenshots
英語でのスクリーンショットを登録する。
ローカライズ時にデフォルト言語でのスクリーンショットが自動的にコピーされるので、再アップロードしなくて済む。すべてのローカライズが終われば日本語でのスクリーンショットを登録する。設定後も変更可能。
以上の手順でどうでしょうか？ 私も時々手順を間違えて苦労を重ねることがあるので、備忘録として書いておきました。もちろん、将来iTune Connectの動作が変更されるかもしれないので、その時は悪しからず。
どなたかテキストや画像のアップローダを作っていただけると嬉しいな〜