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

MoMuでオーディオ処理

iOSでのオーディオ処理を担うCore Audioは準OS Xクラスの充実ぶりで優秀なんだけど、それなりに面倒な設定が沢山ある。そこでちょっとは楽ができそうなのがMoMu: A Mobile Music Toolkit。これはスタンフォード大学のCCRMAがSmuleの協力を得て開発し、公開しているモバイル・デバイス向けのライブラリ。

CCRMAは長年コンピュータ音楽の一翼を担ってきた研究所だし、SmuleはOcarinaなどのiOSアプリで有名な、資金調達もガンガンやってるアクティブなベンチャー企業。この2つがタグを組んだライブラリだから期待が高まる。ちなみに、CCRMAの有名な音響合成ライブラリSTK (Synthesize Toolkit) もMoMuから利用できる(とは言え…)。

さて、MoMuはオーディオ処理だけでなく、図のようにグラフィックス、マルチ・タッチ、加速度センサー、位置情報、コンパスなどの機能も提供している。これで結構なことができそうと思う人はいいんだけど、MoMuはC++インターフェースなのが個人的には難あり。そこで、MoMuのオーディオ処理だけを活用させていただくObjective-C++で参ります。以下、手順。

(1) プロジェクトにMoMuから以下のファイルを追加。
   mo_audio.h
   mo_audio.mm
   mo_def.h

(2) ターゲットに以下のフレームワークを追加。
   AudioToolbox.framework

(3) MoMuを利用するクラス(例えば〜ViewController)のソース・ファイルの拡張子を .m から .mm に変更。

(4) ソースコード(例えば〜ViewController.mm)で、ヘッダをインポートして定数を定義。

#import "mo_audio.h"

#define SRATE         44100
#define FRAMESIZE     128
#define NUMCHANNELS   2

(5) 適切なメソッド(例えばviewDidLoad)でオーディオ処理を初期化し、処理の開始を記述。

MoAudio::init(SRATE, FRAMESIZE, NUMCHANNELS );
MoAudio::start(audioCallback, nil);

(6) オーディオ処理のコールバック関数を記述。これはC言語関数なので@implementationより前(または@endより後)に記述すること。

void audioCallback(Float32 *buffer, UInt32 framesize, void *userData)
{
}

以上でMoMuが利用できる。シミュレータでも実機でも動作するので、プロジェクトを実行して、グワ〜〜ンとかビィイイ〜とか爆音が響き渡れば成功。そうならない場合は、スピーカーのボリュームが下がっているか、マイクが無効になっているか、処理の記述が間違っているか、のどれかだろうね。

爆音大会になる理由は、MoMuはマイク入力をコールバック関数のbufferに渡し、コールバック関数が終わった時点のbufferをスピーカーから出力するから。つまり、コールバック関数に何も記述しないと、マイク入力がそのままスピーカー出力され、フィードバックが起こってハウリングするというワケ。

ハウリングしないように無音にするには、bufferの内容をすべて0にすれば良い。サイレンス音響合成ってのも、なんだかトキめく(?)が、コールバック関数の中身を次のように記述する。

Float32 *data = buffer;
for (int i=0; i<framesize; i++)
{
	*data++ = 0.0;	// 左チャンネル
	*data++ = 0.0;	// 右チャンネル
}

bufferはFloat32型の配列で、その要素数はframesizeで与えられるが、実際にはチャンネル数だけインターリーブしている。例えば、2チャンネル(ステレオ)なら、最初の要素が左チャンネルの1番目のデータ、次の要素は右チャンネルの1番目のデータ、その次の要素は左チャンネルの2番目のデータ…といった具合。データの値の範囲は-1.0から1.0まで。さらに、startの2番目のパラメータがコールバック関数のuserDataに渡される(ここではnilで何も渡していない)。

ここまで理解できれば、後は勝手にイヂることができるね。ナンチャッテ音響処理をいくつか書いてみよう。繰り返します、ナンチャッテ、です。

まず、ホワイトノイズ。

Float32 *data = buffer;
for (int i=0; i<framesize; i++)
{
	Float32 noise = (Float32)rand() / (Float32)RAND_MAX;
	*data++ = noise;	// 左チャンネル
	*data++ = noise;	// 右チャンネル
}

次で、サイン波。

Float32 *data = buffer;
Float32 frequency = 440.0;
Float32 phaseDelta = 2.0 * M_PI * frequency / SRATE;
static Float32 phase;
for (int i=0; i<framesize; i++)
{
	phase = phase + phaseDelta;
	Float32 value = sin(phase);
	*data++ = value;	// 左チャンネル
	*data++ = value;	// 右チャンネル
}

発展させて、マイク入力にトレモロ。

Float32 *data = buffer;
Float32 frequency = 8.0;
Float32 phaseDelta = 2.0 * M_PI * frequency / SRATE;
static Float32 phase;
for (int i=0; i<framesize; i++)
{
	phase = phase + phaseDelta;
	Float32 value = sin(phase) * 0.5 + 0.5;
	*data++ = *data * value;	// 左チャンネル
	*data++ = *data * value;	// 右チャンネル
}

最後に、サンプリング(1秒録音1秒再生の繰り返し)。

Float32 *data = buffer;
static Float32	samples[SRATE];
static long index = 0;
static bool isSampling = YES;
for (int i=0; i<framesize; i++)
{
	if (isSampling)
	{
		samples[index] = *data;
		*data++ = 0.0;	// 左チャンネル
		*data++ = 0.0;	// 右チャンネル
	}
	else
	{
		*data++ = samples[index];	// 左チャンネル
		*data++ = samples[index];	// 右チャンネル
	}
	
	if (++index >= SRATE)
	{
		index = 0;
		isSampling = !isSampling;
	}
}

さらにイロイロしたい人はMusic DSP Code Archiveあたりを参考に。

はい、おしまい。

【追記】諸般の事情(笑)により、サイン波とトレモロのコードを変更しました。また、演算精度に少々問題がある箇所があります。意図的、または、ナンチャッテです。

iOSでVVOSC

OSC (Open Sound Control) は伝統的(笑)にOSC-Kitを使ってたけど、これは本家でも古いと言われるコードなので、最近はVVOSCを使うことが多い。このVVOSCは、vvopensourceなるオープン・ソース・フレームワークの一部で、Objective-Cインターフェースでキレイにデザインされてて、機能も申し分ない。サンプルとして提供されているOSCTestAppを見れば、何をサポートしているか一目瞭然。デベロッパでなくてもOSCの送受信チェックに便利だから、Downloadsからビルド済みのアプリをダウンロードね。

ただし、VVOSCはOS Xがメイン・ターゲットらしく、サポートされているとは言え、iOSではイマイチ。これまで何とか修正していたけど、iOS 5 & Xcode 4.2になって再びビルドが通らない。そこで、本来推奨されているスタティック・ライブラリではなく、ソースをプロジェクトに取り込んだのが以下の手順。

(1) ターミナルを開き、ソースをsvnで入手。Xcodeのレポジトリに登録してチェックアウトしてもOK。

(2) ソースからVVOSCとVVBasicのフォルダをプロジェクトのフォルダにコピー
 
(以下、コピーしたフォルダでの作業で、OS X関連などのファイルを削除する)

(3) VVOSCフォルダからAppSrcとDoxyfileを削除

(4) VVBasicsフォルダからDoxyfileとInfo.plistを削除

(5) VVBasicsフォルダのsrcフォルダから VVCrashReporter〜.〜 VVCURLDL.〜 VVSprite〜.〜 を削除

(ここからはXcodeでの作業)

(6) VVOSCフォルダとVVBasicフォルダをプロジェクトに追加

(7) プロジェクトのBuild SettingsのApple LLVM compiler 3.0 – LanguageのOther C Flagsに -DIPHONE を追加

(8) ビルドしてエラーの出る箇所を修正
 #import <VVBasics/〜.h> を #import “〜.h” に修正
 OSCStringAdditions.h に #import “MutLockDict.h” を追加

ビルドが通れば、VVOSCを利用してOSC通信を行うのは簡単。

まずはヘッダをインポート。

#import "VVOSC.h"

そしてOSCマネージャを作って、デリゲートを指定。

OSCManager *manager = [[OSCManager alloc] init];
manager.delegate = self;

出力ポートを作って送信。

OSCOutPort *outPort = [manager createNewOutputToAddress:@"127.0.0.1" atPort:1234];
	
OSCMessage *message = [OSCMessage createWithAddress:@"/test"];
[message addInt:100];
[outPort sendThisPacket:[OSCPacket createWithContent:message]];

入力ポートは作るだけ。

OSCInPort *inPort = [manager createNewInputForPort:1234];

実際に受信するとデリゲートが呼ばれる。

- (void) receivedOSCMessage:(OSCMessage *)m
{	
    NSString *address = m.address;
    OSCValue *value = m.value;
	
    if ([address isEqualToString:@"/test"])
        NSLog(@"%d", value.intValue);
}

はい、おしまい。

【追記】以前に比較したように、VVOSCは処理速度がやや劣っている。これは現在のバージョンでは改善された様子だけど、タイミングがシビアな用途には向かない場合があるかも。

11/11より京都で展示

11/11より京都芸術センターで開催される「ルネサンス—京都・映像・メディアアート」展に「Okeanos Buoys」を出品します。Okeanos Buoysは昨年制作したiPhone数十台(前回は40台+α)によるインタラクティブ・インスタレーションで、日本では初めての展示です。

展覧会にお越しの際は、iOSアプリ「Okeanos」をインストールしたiPhoneをお持ちいただければ幸いです。もちろん、iPadやiPod touchでも構いません。アプリ・サイズが20MBを超えており、Wi-Fiでなければダウンロードできないのでご注意を!

フライヤーPDF (3.5MB)

展覧会「ルネサンス—京都・映像・メディアアート」
会期:2011年11月11日(金)〜11月23日(水) 10:00〜20:00
会場:京都芸術センター/むろまちアートコート
出展作家:アンドレアス・クレシグ、赤松正行、井浦崇+大島幸代、國政展子、合田健二+寺山直哉、来田猛、酒井章憲、捧公志朗、清水久美、高橋三紀子、玉木雄介、中井恒夫、二瓶晃、長谷川潔、人長果月、牧奈歩美、水野勝規、宮崎詞美、宮 永亮、迎山和司、米正万也
(会期中無休、入場無料)

iPhoneで3GとWi-Fiの同時通信

iPhoneで、あるいはiPadを使っていて、3GとWi-Fiを同時に、でも個別にデータ通信したい場合があります。例えば、iPhoneとMacとをWi-FiのOSCでコントロールしながら、同時に3Gでメール・チェックをしたい、みたいな感じ(無理矢理な設定ですが笑)。

通常はiPhoneをWi-Fiルータに繋ぐとWi-Fiが優先されて、3Gはインターネット接続には用いられない、と思っちゃいますよね。となると、en0が…Socketが…って面倒な話になりそう。ところがなんと、Wi-Fi設定でルータのアドレスを指定しなければ、3Gでインターネット接続しちゃうみたいです。

iphone-ad-hoc-connection

そりゃそうだと言うか、なんてスマートと言うか、常識って怖いねと言うか、ともあれ特別なことは不要でした。実際の場面としてはMacBookなどとAd Hoc接続する場合ですね。先に例として挙げたOSC通信とWebサーフィンとかもバッチリでした。RemokonならUsing a Built-in AirPortの設定そのままです。逆にそんなの常識だよと言われそうですが、備忘録として記事にしておきますね。

クラウドの再定義

誰でも苦手分野があるけど、Appleの場合はネットワーク・サービスだろうね。この10年間だけでもiToolsに始まり、.MacからMobileMeへと変遷するものの、MacやiPhoneのようなレベルにはほど遠かった。

これはデバイスでのユーザ体験とネットワークでのユーザ体験とは違う、ってことなんだろうね。なぜって、MobileMeほどGUI的に(外見的に)洗練されたネットワーク・サービスはないと思うけど、でも使いにくいよね。むしろ、ネットワークに素敵なGUIをくっつければ使い易くなると思ったのがMobileMeだったんじゃない? 見当違いも甚だしい。

そんなAppleが起死回生とばかりに巨大データセンター込みで仕掛けるのがiCloud。お得意のアイなんとかってネーミングに腐食気味だけど、これがコケたらヤバいってくらい力が入ってる。WWDC2011のキーノートでも明らかなように、iCloudはiOSデバイスの母艦たるMac/PCを不要にしてしまう。もうコンピュータは要らない、ってこと。この転身は遅過ぎたくらいね。Androidはとっくにそうだったんだから。

icloud-logo

それではiCloudって何?って言われても、これだぁ!って目に見える実体がない。MobileMeやGoogleなどの一連のサービスがWEBサイトを示せば雰囲気が伝わるのとは大違い。クラウドって様々な定義があるけど、なんとなくSaaS(Software as a Service)っぽいものを連想してしまうのが悪いクセ(私も)。

iCloudはSaaSじゃなくってPaaS(Platform as a Service)だね。あるいはIaaS(Infrastructure as a Service)。そしてユーザが接するのはWEBアプリではなくネイティブ・アプリ。すでに425,000個もあるアプリを利用しない手はない。Appleは明確に唱っている、「iCloudはあなたの様々なアプリケーションとシームレスに統合」と。

まとめると、こーゆーこと。

  • コンピュータはオシマイ→モバイルで行くぜ!
  • WEBはダメ→アプリで行くぜ!

つまり、これまで以上にアプリ開発者が活躍の場が広がると思う。Mac中心主義だったデジタル・ハブ構想を捨て、iOS/OS X中心主義のクラウド構想に移行するターニング・ポイントがWWDC0211ってことになる。それを支えるのがiCloud。

もちろん、Macは制作ツールとして存続するけど、一般ユーザが使うものではなくなる。WEBも簡易な情報提示の場として有効だけど、高度かつ体験性の高い処理はアプリが担う。はてさてAppleの目論み通りにコトが進むかどうか、お手並み拝見と参りましょう。

【追記】iCloudはiOSデバイスだけでなくMacでもWinでもOK。たぶんAndroidなど他のOSでもOKな気がする。そんなワケでクロス・プラットフォーム展開には支障がないハズね。

4/12から大垣でギークラボ

先週の裏モバイルカフェでのミーティングを経て、いよいよ今週からギークラボ(geeklab.jp)を開設することになりました。前回を第0回として本日4/12は第1回のミーティング。とは言え、当面は広報的なことはいたしませんし、ギークラボが何かも曖昧模糊なままになります。ご興味のある方は、ぜひ辿り着いて入り込んでくださいませ〜って感じ。

geekcafejp

不親切かもしれませんが、理由のひとつには、明確なポリシーを決めずに自然発生的に柔軟に運営したいってことがあります。ただ、以前のモバイルカフェが広く浅くオープンでフリーだったのに対して、ギークラボは狭く深くクローズドでペイドになりそうです。言わば秘密結社(笑)やギルド(笑)なので、一般には情報もあまり流れないじゃないかな。

明文化せずに運営するってことは「契約」ではなく「信頼」に基づくってことで、これはかえって大変。でも、「規模」や「位置」ではなく「密度」や「速度」を求めるなら、必然的に不文律の活動になるのかも。そんなこんなでユルユルとがんばりますよ〜乞うご期待!

小さな作曲家の物語

開発秘話ってほどでもないんですけど(笑)カール・バルトス氏とジャン=マルク・レダーマン氏との共作「MINI-COMPOSER」の制作過程で印象に残ったことをメモ程度に….

まず、私は受託開発の経験が少ない。それがヤなわけじゃないけど、自分のことだけでテンテコマイってのが実情。数少ない例外はiPhone黎明期のクウジットさんの「ロケーション・アンプ for 山手線」と頓智ドットの「セカイカメラ」(初期バーション)くらいかな。いずれも大きなお題はありつつも、具体的には自由にアイディアを投入させていただいた。もちろん、相手は日本人だから日本語でディープな議論も遺憾なくできる。

これに対してMINI-COMPOSERでは、当初から50-50の対等の関係で制作することが前提。だからカールのアイディアも私のアイディアも同じように尊重され、折り合いをつける必要がある。何をどのように作るかという根底部分での合意形成が重要なワケ。でも、お互いに相手の趣味趣向まで理解しているわけじゃないから、これが大変。

しかも、直接会って話し合うことも難しいし、英語でのメールの遣り取りも頓珍漢気味(彼らも英語ネイティブではないはず)。Skypeも悪くないけど、じっくり考えるには適さない。テクノポップ界の大御所に対する配慮&遠慮も一応ある(笑)。ex-KWとダイアトニック・スケールとは何ぞやと応酬するは大変だよ。A#とB♭の違いとかね。

さて、スタート地点は「シンプルなステップ・シーケンサでドラムとサイン波だけ」というもの。それは簡単、アっと言う間にできるよね。でも、それだとカールらしさがどこに発揮されるのかが分からない。それにシーケンサと言われると音楽制作ツールとの印象が強くて、あれも必要、これも必要と思ってしまう。初期の設定画面はこんな感じで、もっと壮絶なバージョンもありました。

mini-composer-proto

このようなプロトタイプが叩き台になるんだけど、UIのスケッチや操作のフローを描いてくれと頼んでも、短い文章が返ってくるだけ。これは勝手な想像だけど、彼らは音楽脳なのでUIや操作を図式化したり、言語化するのは苦手かもしれないね。フツーの請負プログラマなら途方に暮れちゃいそう。

ともあれカールが一貫して主張していたのは、とにかくシンプルにしたい、ってこと。だから、テンポ設定は要らない、ボリューム設定も不要、波形設定もナシ、ピッチ設定も面倒…という具合で、とうとう設定画面自体が消滅。なんだかドイツ人にワビ・サビを教えられている気分(笑)。

かくしてベースもなければ調性も固定のシーケンサになった次第。だけど、サウンドの作り込みは猛烈ダッシュ状態。結構いいんじゃない?と思っていても、気に入らないので全部入れ替えるから待ってろ!みたいな調子。さすがボクはオンガッカです。絶妙のキャラクター付けで、設定が皆無でも(むしろ、それゆえに)最高に楽しめますね。ツールと作品のちょうど中間地帯にうまく降り立ったんじゃないかな。

一方で私の役目と言えばアプリ制作そのものなんだけど、プロトタイプを提示してUIをまとめながら、オーディオ・エンジンの調整に力を入れてました。最初はシーケンスをperformSelectorやCALayerなどでお茶を濁していたものの、サウンドがカッコ良くなるにつれてツラくなり、最終的にはCoreAudioのオーディオ・レイトでビシバシ駆動。これでアニメーションなどもベクター・サイズ(+α)での誤差になり、かなりタイトになったと思うな。

さらにはバカでかいアニメーションを入れたり、ランダマイズ機能やスクラッチ機能を入れたり。このあたりはプチ・アルゴリズミック・コンポジションなワケで、MaxやSuperColliderで散々やってきた秘伝の味(笑)。でも今回は軽くフレイバーをまぶした程度ね。ちなみに、この手のアイディアは事前に説明せずに、実際に動かして、どう?と尋ねるのがイイみたい。

未だにスッキリしないのはグラフィック・デザイン。何しろセンス・ゼロの私がやっているから、情けないことこの上ない。知人のデザイナに手伝ってもらおうか?と持ちかけたものの、そのあたりは不満がない様子。考えてみれば、どこか間抜けなダサカッコイイ感じが持ち味だよな〜と思い、強制的に納得しています。

mini-composer-proto-red

他にも小さなエピソードや公表が憚られる話もありますが、全体としては楽しい作業で、見知らぬ他人とのコラボレーションとしては大成功だと思うな。もともとは私のSnowflakesOkeanos Buoysのビデオを見て興味を持ったそうで、求める感性に近いんでしょうね。

それから、当初はモタつき気味だった制作テンポが中盤以降どんどん加速するあたりは圧巻でした。特に震災支援を考えると、モタモタしていては意味が薄れるので、一日でも早く完成させる原動力になりました。音楽もアプリも下手をすれば延々とイジリ続けちゃうから、お尻に火をつけることはイイことです。Light My Fire !

日本へのシーケンス

元クラフトワークのカール・バルトス氏とともに制作した新しいiPhone用のアプリケーション「MINI-COMPOSER」をリリースしました。これはシンプルな16ステップ・シーケンサであると同時に、東北関東大震災への支援を呼びかけています。無償でダウンロードすることができ、iPhone、iPod touch、iPadのどのモデルでも動作します。

mini-composer-1

カールやジャン=マルク(プロデューサ)とは少し前から親交がありましたが、地震や津波による悲惨な状況を受けて、このアプリによって震災支援の呼びかけることにしました。彼らは地震発生時に安否確認と見舞いのメールを送ってくれたし、震災支援を提案するとすぐさま大文字太字で OF COURSE ! との返事をもらっています。その心意気たるや感涙ものです。

震災支援としては救援物資や義援金、作業ボランティアや支援チャリティなどいろんな方法があります。また、災害や復興に役立つアプリの無償提供やアプリの収益金の寄付なども既に行なわれています。一方で私たちはアーティストなので、アーティストとしての支援を考えました。もっとも得意なことで貢献する方策があると思うからです。

つまり、このアプリは一義的には、ただただ私たちの音楽であり、インタラクティブな要素を持たせたエンターテイメントです。被災者の方々はもちろん、そうでない人も、この音楽アプリにちょっとした愉しみを見い出していただければ嬉しい。シンプルなシーケンスの連続に、心が和らいだり気持ちが晴れやかになったりするなら、さらに嬉しい。

そしてインフォメーションを開くと、そこには震災支援を呼びかける短い文章と米国赤十字社の寄付サイトへのリンク・ボタンがあります。このアプリを音楽として楽しむとともに、被災地の状況に思いやる人が少なからずいらっしゃると期待するわけです。ちなみに、米国赤十字社へのリンクは、App Storeのアカウントで手軽に寄付が行なえるので、iPhoneアプリとして最適と考えました。

mini-composer-2

カールと私は多くの人にこのアプリを知っていただき、震災支援をされる方が増えることを願っています。ですから、このアプリを一人でも多くの友人や知人に紹介していただけると、とても有り難いです。そのためにもアプリは有償ではなく無償であり、当然のことながらカールも私も金銭的な利益を得ることはありません。どうか、ご協力くださいますようお願い申し上げます。

ピュアなデータをiOSで

Maxの実父と言うか異母兄弟と言うか良く分からないですが(笑)、Pd (Pure Data) はMaxに似たビジュアル・プログラミング環境。MaxとPdは同じとも言えるし、全然違うとも言える、なかなか奇怪な関係にあります。詳しくは面倒なので省略。パッチと呼ばれるグラフィカルなプログラムはこんな感じ。

pd

それで、このPdをiOSで動かそうというプロジェクトがPd for iOS。以前はRjDjがPdベースってことで少々話題になりましたが、その一般化が進んでいるようです。ただし、現時点ではアルファ版なので、いろいろバギーだったりします。

Xcode 4でPd for iOSを試すには、次のような手順になります。

  • Xcodeを起動し、Organizerを開き、Repositoriesを選ぶ。
  • 左下の+ボタンをクリックし、Add Repository…を選ぶ。
  • Nameは Pd for iOS、Locationは git://gitorious.org/pdlib/pd-for-ios.git と入力し、Addボタンをクリック。
  • 左側のリストの Pd for iOS を選択し、Cloneボタンをクリックして、クローンを作る。

これでpd-for-iosというフォルダが作られますが、もう少し作業をする必要があります。これはREADME.txtに説明されている通りです。

  • ターミナルを起動する。
  • cdコマンドでpd-for-iosフォルダに移動する。
  • 次の4つのコマンドを実行する。
    • git submodule init
    • git submodule update
    • git pull
    • git submodule update

これでPd for iOSのインストールは完了。後はPdTest01やPdTest02などのサンプルを試してみてください。まぁ音が鳴ったり、鳴らなかったりしても文句を言う筋合いじゃないですね。Pdはオープンソースのフリーウェアであり、伝統的に自己責任&自己解決が原則ですから。

個人的にこの手の試みで興味があるのはGUIの扱いなのですが、Pd for iOSはInterface Builderを使ってGUIアイテムを貼付ける正攻法。そして、アクションやアウトレットを定義して、専用のメソッドでPdのrecieveオブジェクトに送り込みます。なんだか豪快な感じもしますね。

pd-for-ios

アイの文化的遺伝子

iPad 2を手にして、そして数日使って思うのは、これはiPadだということ。先週まで使っていたiPad 1と何も変わらない。もちろん、並べてみればビックリするほど薄いし、ちょっとだけ軽い。処理は格段に速いし、手に馴染む感じも向上している。画質はトホホでもカメラは可能性を拡げていて、スマート・カバーの工芸的繊細さにウットリする。だけど元々こうだったんじゃないかと思ってしまう連続性と納得感があるんだよね。

ipad2-and-smartcover

これはiPhoneでもiPodでも、さらにはMacでも同じように感じること。言わば、リチャード・ドーキンスが言う文化的遺伝子(ミーム)が各製品を通じて脈々と受け継がれているってことじゃないかな。つまり、デバイスは、あるいはOSは、その時々の最上の表現形ではあっても、常に最終形は存在しないし、常に進化し洗練されていくハズね。

だから、ドラスティックな外観や機能の変化に目を奪われる必要はない。欲しい時が買い時と鷹揚に構えていてもいいし、同時に、真っ先に最新モデルを購入し続けるのもまた正しい。新しいiPad 2は確実に大きな満足を与えてくれるし、これまでのiPad 1も同じように活躍し続けるだろうからね。

iPad 1とiPad 2との違いは、iPhone 3GSとiPhone 4の違いを思い起こせばいい。旧モデルが安価になって併売されるのも、文化的遺伝子が同じだからだろうね。逆に廉価であっても文化的遺伝子が損なわれるようなモデルは登場しないと思う。ただし、例外は最近のiPodで、Classic、Nano、Shuffleは末期的症状を示している気がするな。

同じように考えると、Androidに欠けているのは文化的遺伝子に他ならないと思うよ。そもそもが形態として頭脳と身体が分離している上に、伝えるべき遺伝子が存在しないように見えるな。情熱を持って取り組んでいる人は沢山いるから、心まで欠けているとは思わない。だけど、アンドロイドだから遺伝子は要らないってことじゃないよね。がんばれ、緑ロボット!