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の動作が変更されるかもしれないので、その時は悪しからず。
どなたかテキストや画像のアップローダを作っていただけると嬉しいな〜
App Storeで配布や販売するiPhoneアプリケーションは、iTunes Connectというサイトで各種情報を登録します。実はこのiTunes Connectが曲者で、デフォルト言語を日本語にしている場合、悲惨な目にあうんですよ。涙ナミダの物語の始まりハジマリ。
まず、現時点でのiTunes Connectが対応するのは18言語なので、デフォルト言語に対して17種類の言語でのローカライズになります。でも、そんなに沢山の言語に翻訳するのは大変なので、ありがちなパターンとして日本語と英語だけ用意するとしますね。この場合はデフォルト言語である日本語での説明文などを入力した後、英語（English）でのローカライズを行います。
ところが、これで作業を終えると大変マズイです。英語圏ではないApp Store、例えばドイツやフランスのApp Storeではデフォルト言語である日本語で表示されちゃいます。デフォルトってそーゆーことだよと言えば、その通りなんですが….結局のことろ、残る16言語についても、英語での内容でローカライズをしなければなりません。つまり、同じローカライズを17回行うわけです。
もうひとつの問題は、対応言語が今後増える可能性があること。最近でもSwedenやKoreaなどが追加されましたが、それに気がつかずにいれば、これらの国のApp Storeでは日本語で表示されちゃいます。日本語以外の国で日本語が通じるわけがないので、これまた悲惨な目にあいます。
一番良い解決方法は、デフォルト言語を英語にすること。この場合はデフォルト言語である英語で入力した後、日本語でのローカライズを行えば、日本では日本語、それ以外ではすべて英語で表示されるのでバッチリです。しかし、一度デフォルト言語を設定してしまうと、もはや他の言語には設定できない仕組みになっています。デフォルト言語の変更は何度かAppleにお願いしたものの、対応していないの一点張り。つい最近も問い合わせたところが、こんな返事。
Once the default language for your account has been set in iTunes Connect, it cannot be changed.
デフォルト言語を英語にすることは、拙著「iPhone SDKの教科書」でも言及していますし、講演などでも注意事項として度々お話しています。でも気がつかずに日本語に設定しちゃう人が結構多いみたいです。結果的に涙の単純反復作業をせざるを得ない人が沢山いらっしゃるんじゃないかな？ ちなみに私の場合は、App Storeオープン前後に、デフォルト言語は日本語にしてください、と説明を受けたんですよ（とほほ）。
鉄則：iTunes Connectでのデフォルト言語は英語にする。
（この記事続く）
新作AirCameraがリリースされました。LAN内のiPhoneのシャッターを同時に切る超絶？アプリです。何台ものiPhoneで同時撮影すればギガピクセル写真とかパノラマ写真とかオブジェクト写真が簡単にできちゃいます。高価な特殊撮影装置が必要だったけど、これからはiPhoneを集めるだけ。一人で何台も持ってる人は少ないでしょうけど、皆で集まってAirCamera撮影大会しましょう！ギネスにも挑戦できる？
AirCameraはOSCプロトコルなのでコンピュータから制御できます。サンプル・アプリケーションはサポート・サイトにあります。例えば、AirCameraControlのSequential Snapボタンがマシンガン撮影です（複数台のiPhoneが必要）。
OSCを扱えるプログラミング言語はたくさん。Maxな方、Processingな方、SuperColliderな方、QuartzComposerな方、Flashな方、Pythonな方、Rubyな方、Javaな方、Cな方、その他いろいろな方、対応アプリ書いてください。さらにネットワークやセンサーと絡めることもできますね。Tweetで撮影するとかドアが開くと撮影するとか。
もちろん、AirCameraはコンピュータなしでも大丈夫。ツールバー中央の撮影ボタンを押せば、その瞬間に全台がシャッターを切ります。その他すべての操作が連動します（写真アルバムの操作は除く）。また、すべてのAirCameraは設定が連動します。これで1台ずつ設定する手間が省けてシアワセ。コンピュータから設定を変えてもいいですよ。
何台ものiPhoneで撮影はできても、その後に写真を吸出すのが大変。なのでFlickrへの自動投稿機能を備えています。タイトル、説明文、タグが設定できて、iPhoneの名称とIPアドレスが自動付加されます。なので、AirCameraで撮影した素材写真群をギガピクセル写真やパノラマ写真に自動的に繋げるFlickr対応アプリも欲しいところ。Photoshopなどで根性で繋いでいただいても良いわけですが。
そんなこんなで、AirCameraを使って面白い写真を撮影された方や対応アプリケーションを作成された方は、是非お知らせください。サポート・サイトで紹介させていただきます。もっとも、伝統的な撮影方法にしか興味がない人にはAirCameraは無用の長物です。ビットの無駄使いとお呼びください。
【AirCameraで（簡単にor がんばれば）できること】
(from Wikipedia)
【AirCameraのよくある質問の答え】
ところで、写真系や美術系の学校でAirCameraワークショップしましょうよ。ン十台持ち込むからね。参加者は撮影方法を考えて実践してポストプロセスまでやる。一眼レフばかりがカメラじゃない。手も足も動かすし、右脳も左脳も動かすことになるよね。
なお、AirCameraはセカイカメラともエアタグとも関係ありません。開発コードネームはAirCamで、ナントカCameraって山ほどあるから避けたい。でも、ここはやっぱエアカメラしかないと勇気を振り絞りました。ただ、頓智・から類似商標で訴えられないか心配で夜も眠れない（嘘）。
【補記】この記事はTwitterでのポストを編集しました。
昨日のモバイル・カフェでGameKit（の一部）を説明したので、その資料とサンプルコードを公開しておきますね。横着するためにErica Sadun女史の書籍「iPhone Developer’s Cookbook, 3.0 Edition」のサンプルコードからGameKitHelperを利用しています。
簡単GameKit-P2P (PDF)
サンプルコードSmash-X
このサンプルは「iPhone SDKの教科書」に掲載したSmashを拡張して、2台のiPhoneのスクリーンを横断するようにUFOが飛び回るというものです。オリジナル版と同じく、指でタップしてUFOを叩き潰すこと（Smash）もできます。通信以外のキモはboundsプロパティの使い方かな。
Ustreamでは1時間13分あたりから。この時はBluetooth接続に手間取ったのですが、すぐに接続できる時もありますね。ちょっと不可解。ちなみに、この日は冒頭で室内をヘリコプターが飛んています。
