iOSデバイスとOSバージョン一覧表

問題:iPhone OS 3.0以降に対応するアプリの動作確認のために必要なiOSデバイスは何台?

先のオプティマイザ問題もあって、iOSデバイスとOSのバージョンを調べてみました。この表での最小OSは、そのデバイスが発売された時点のOSのバージョンで、最大OSはどのバージョンのOSまで対応しているかを示している。(5.0.1)は現在の最新バージョンで、今後も対応するバージョンが上がる可能性があります。

3.xアプリの欄にマル印が付いているのは、OSのバージョン3.xに対応するアプリが動作することを示しており、動作確認をする必要がある。例えば、iPhone 4はOS 4.0以降に対応するので、3.xアプリの欄にはマル印は付いていない。つまり、動作確認をする必要はない(そもそもできない)。そして、iPhone 4はOS 4.xとOS 5.xについてアプリの動作確認をすることになる。

一般にOSのバージョンを下げることはできないので、メジャー・バージョンごとに動作確認用のデバイスを用意する。つまり、iPhone 4ならOS 4.xとOS 5.xの2台が必要になるわけ。厳密にはマイナー・バージョンごとにも動作確認すべきかもしれないが、これは最大のマイナー・バージョンに限って良いはずね(たぶん)。

そこで、この表のマル印を数えれば、今回の問題に対する回答になる。

回答:23台

ただし、iPhone 4 (GSM)とiPhone 4 (CDMA)の違いは僅かで、個別に検証する必要はないかもしれない。この場合は必要台数は21台となる。逆にiPadもiPad 2も、Wi-FiモデルとWi-Fi+3Gモデルがある(iPad 2の3GはさらにGSMとCDMAに分かれる)ので、これらは区別して動作確認するべきかもしれない。このように考え方によっては23台以外の回答も有り得るよ。

ともあれ、動作確認のためには数多くのデバイスが必要だってことが分かるね。OS 4.x対応であれば17台、OS 5.x対応で8台が必要となる。個人や小規模なグループなら、これだけの台数を揃えるのは難しいかもしれない。初代iPhoneのように入手が難しい機種もある。しかし、万全を期するにはこれだけの台数が必要だし、何か問題が発生した場合には手の打ちようがないよね。

え?私?CDMA以外は必要台数全部揃っています(笑)。

【追記】iPhone OSにはバージョン2.xも存在するけど、現在のXcode 4.2では2.x用のアプリを開発するのは困難なので、ここでは省略しています。また、初代iPhoneが登場した時のOSはバージョン1.0で、これはApp Storeに対応していない。

最終確認はReleaseビルドで

先日リリースしたBanner 1.5.2について、iPhone 3Gで三角形みたいに歪んでいる、というメールあり。何それ?と思いながら確認しても、特に異常はなさそう。そもそもサブミット前にiPhone 3Gでもチェックしている…とここまではXcodeでの話。もしや!と思ってiPhone 3GでApp Storeからダウンロードしてインストールして起動すると、しっかり歪んでました。歪むと言うよりグルグル斜めに廻っている感じ。でも、もう一度Xcodeから実行すると正常に表示される。しかも4Sなど他のiPhoneではApp Storeのアプリでも問題がない。謎!

原因はXcodeのオプティマイザでした。オプティマイザは実行速度が速くサイズが小さくなるようにコードを最適化してくれる。ところが、iPhone 3Gに対して(arm6に対して)はオプティマイザがお馬鹿さんらしく、変なコードになる場合があるらしい。そして、開発中に使うDebugビルドはオプティマイザがオフだけど、App Storeへのサブミットに用いるReleaseビルドではオプティマイザがオンになる。つまり、オプティマイザが馬鹿とは言え、Releaseビルドで動作確認をしなかった私が愚か者でした、ってワケ。

ちなみに、DebugビルドかReleaseビルドかは、Schemeポップアップ・メニューから「Edit Scheme…」を選び、Build Configurationで指定する。これをReleaseにしてRunすれば、App Storeからダウンロードするアプリと同じ状態になる(はず)。なので、アプリの最終動作確認はReleaseビルドで行うべし、ですね。ただし、Releaseビルドではデバッグ情報もなくなるので要注意。デバッグが必要であれば、Debugビルドのままターゲットの設定でオプティマイザだけをオンにする。

さて、オプティマイザがiPhone 3G用にどのようなコードを生成しているかまでは分からない(調べるのは大変)。そこで、あれこれソースコードを書き換えて、オプティマイザがオンでも正常動作するよう修正する。半ば手探りだけど、今回は表示なので見当を付けやすい。オプティマイザが間違えようもない(と思われる)馬鹿丁寧な処理にして解決。

と言う訳で、修正版のBannerをサブミットしていますので、iPhone 3Gユーザの方は今しばしお待ちください。ご迷惑をおかけして、申し訳ありませんでした。

【追記】ってことは、AppleはiPhone 3Gで動作確認していない、ってこと?

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

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