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

Mountain LionでのMax SDK

久々にMaxオブジェクトを作ろうとして、Max SDKをダウンロードしたら付属のサンプルすらビルドできない。これはビルド設定の内容が古いからでした。

OS X 10.8 & Xcode 4.5でMaxSDK-6.0.4を利用する場合は、maxmspsdk.xcconfigの33〜34行目を以下のように修正します。これでOK!

SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
MACOSX_DEPLOYMENT_TARGET = 10.8

iOS 3.1.3をサポートする方法

iOS SDKは年々進化を続けているのはイイんだけど、後方互換性は一部犠牲になっている。他のプラットフォームに比べると数倍マシだとは思うけどね。ともあれ、最新OS最新モデルに対応しつつも、以前のOSや機種を切り捨てられない場合も少なくない。しかも初期のSDKで作成したプロジェクトをアップデートし続けるのもスッキリしないので、最新SDKから新しいプロジェクトを作ったりすると、それなりに問題が発生する。

そこでiOS SDK 5.1 (Xcode 4.3.2)で作ったプロジェクトを初代iPhoneの最終OSであるバージョン3.1.3に対応させる方法を書いておくね。ここではテンプレートとしてUtility Applicationを用い、iPhone/iPad両用のユニバーサル・アプリを作ることにします。もちろん、ARCはオフ、Storyboardも使えませんよ。

まず、何はともあれDeploymentを3.1に設定する。

■ プロジェクトのiOS Deployment Targetを 3.1 に設定。

次いで、初代iPhone、iPhone 3G、iPod touch(第1世代と第2世代)のCPUであるarmv6でも動作するように指定する。

■ プロジェクトのBuild SettingsのArchitecturesのArchitecturesに armv6 を追加。

■ プロジェクトのBuild SettingsのArchitecturesのBuild Active Architecture Onlyを NO に設定。

■ ウィンドウの下部にあるValidate Settingsをクリックし、Perform Changesを実行。

■ Info.plistにある Required device capabilities を削除。

Blocksを使う場合には以下の設定も必要。

■ プロジェクトのBuild SettingsのLinkingのOther Linker Flagsに -weak-lSystem を追加。

次に、テンプレートが生成するコードはiOS 3では存在しないクラスやメソッドを使っているので、iOS 3でも動作するように変更する。

まず、テンプレートはiPad用にUIPopoverControllerを使っているので、UIKitのリンクを弱める。

■ ターゲットのBuild PhasesのLink Binary With LibrariesにあるUIKit.frameworkを Optional に設定。

また、デバイスの判断にuserInterfaceIdiomメソッドもiOS 3では使えない。そこで汎用的に利用できるマクロを用意して、ソースコードを書き換える。

■ 〜-Prefix.pchに以下のマクロを定義。

#define UI_USER_INTERFACE_IDIOM() ([[UIDevice currentDevice] respondsToSelector:@selector(userInterfaceIdiom)] ? [[UIDevice currentDevice] userInterfaceIdiom] : UIUserInterfaceIdiomPhone)

■ ソースコードの該当箇所を書き換える。AppDedegateに1ヵ所、MainViewControllerに3ヵ所、FlipsideViewControllerに1ヵ所あるはず。

[[UIDevice currentDevice] userInterfaceIdiom]

UI_USER_INTERFACE_IDIOM()

に置き換える。

また、UIWindowのrootViewControllerプロパティもiOS 3では使えない。

■ AppDedegate の application:didFinishLaunchingWithOptions: の、

self.window.rootViewController = self.mainViewController;

if([self.window respondsToSelector:@selector(rootViewController)])
    self.window.rootViewController = self.mainViewController;
else
    [self.window addSubview:self.mainViewController.view];

に置き換える。

同じく、UIViewControllerのcontentSizeForViewInPopoverプロパティもiOS 3では使えない。

■ FlipsodeViewController.m の initWithNibName:bundle: の、

self.contentSizeForViewInPopover = CGSizeMake(320.0, 480.0);

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
	self.contentSizeForViewInPopover = CGSizeMake(320.0, 480.0);

に置き換える。

以上の作業でiOS 3.1.3からiOS 5.1までのすべてのデバイスで動作するユニバーサル・アプリになったハズ。お疲れさまでした。

このようにして作ったテスト用のプロジェクト一式も入れておきますね。
Download RunOnOS3Test.zip

【追記】最後のcontentSizeForViewInPopoverプロパティの説明を追加しました。併せてテスト用プロジェクトも更新しました。

iSuperColliderのビルド方法

先日のワークショップでiOS用のSuperColliderを紹介したことで、その入手方法の問い合わせが何度かあったので、ビルド方法のメモを書いておきます。ただし、これは2012年3月7日時点のレポジトリでの作業方法です。その後にソースコードが変更されることもあるでしょうから、同じように作業してもビルドできるとは限らないです。従って、質問されてもお答えできないってことでご了承願います。

How to build SuperCollider for iOS (March 7th, 2012)

Don’t ask me any questions 😉

Getting source codes

(1) Open Terminal

git clone git://supercollider.git.sourceforge.net/gitroot/supercollider/supercollider isc
cd isc
git checkout 3.5
git submodule init && git submodule update

Building SuperCollider.app (Language)

(1) Open isc/platform/iphone/iPhone_Language.xcodeproj

(2) Set Scheme to ‘SuperCollider > iOS Device’

(3) Set Build Configuration to ‘Release’

(4) Click iPhone_Language in the navigator area
Click SuperCollider in TARGETS
Click Build Settings
Scroll down to Search Paths and open Header Search Paths
Change ../../external_libraries/yaml-cpp-0.2.6/include to ../../external_libraries/yaml-cpp-0.3.0/include

(5) Open externals/yaml group of iPhone_Language in the navigator area
Remove src group
Add isc/external_libraries/yaml-cpp-0.3.0/src into externals/yaml group

(6) Click iPhone_Language in the navigator area
Click SuperCollider in TARGETS
Click Build Phases
Remove libsndfile_iphone.a from Link Binary With Libraries
Add isc/platform/iphone/lib/ libsndfile_iphone.a to Link Binary With Libraries

(7) Connect your iOS device and run

Building iscsynth.app (Synth)

(1) Open isc/platform/iphone/iPhone_Language.xcodeproj

(2) Set Scheme to ‘iscsynth > iOS Device’

(3) Set Build Configuration to ‘Release’

(4) Open Resources group in iPhone_Synth.xcodeproj in the navigator area
Click iscsynth_MainWindow.xib
Remove Dir Browser View Controller from Tab Bar Controller in Objects

(5) Click iPhone_Language in the navigator area
Click iscsynth in TARGETS
Click Build Phases
Remove scUBlibsndfile.a from Link Binary With Libraries
Add isc/platform/iphone/lib/ libsndfile_iphone.a to Link Binary With Libraries

(6) Connect your iOS device and run


以上です。

なお、このビルド作業ではFredrik Olofsson氏にヘルプしていただきました。感謝!(でも彼にも迷惑をかけないようにお願いしますね〜)

また、ワークショップで使用したiSuperColliderは、スリープを自動禁止にしたり、スピーカー選択のコードを修正したり、といった変更を少々加えています。

【追記】本記事初出時には2012年1月末時点のレポジトリでのビルド方法を記載しましたが、2012年3月7日に再度手順を検証して記事を書き換えました。

Dashcodeでアプリ・アイコン効果

iOSが自動的に付加するアプリ・アイコンの角丸グロッシー効果、もちろん画像編集ソフトでできるんだろうけど、ここでは以前にTwitterで教えていただいたDashcodeでの手法をご紹介。DashcodeはXcodeの一部として提供されているAppleの無料ツールね。

(1) Dashcodeで新規プロジェクトを作成。
一番シンプルなSafariのカスタムのテンプレートが最適。

(2) ライブラリから四角形をキャンバスにドラッグ&ドロップ。

(3) インスペクタでサイズを設定。
使用するアイコン画像のサイズに一致させる。ここでは512×512ピクセルとする。

(4) インスペクタで塗りつぶしをイメージに設定し、画像ファイルを選択。

(5) インスペクタで角の丸さを設定。
アイコン画像が512×512ピクセルの場合は100ピクセルくらいになる。

(6) エフェクトのガラスを有効にし、パラメータを設定。
  シャイン:50%
   トーン:80%
    水平:50%
    湾曲:-20%

iOSでの効果とは微妙に違う気がしないでもないけど、まぁ、そこそこ雰囲気は出てるんじゃないでしょうか。

MoMu-STKでシンセシス処理

先に紹介したMoMuでのオーディオ処理は、基本的な入出力を肩代わりしてくれるものの、それ以上のことは自前でやらなくてはいけない。実際にもMoMuオーディオは内部的にRemoteIOを呼び出しているだけ。自前でデジタル信号処理を書くのは、お勉強にはイイけど、面倒で難解であることも確か。

一方、MoMuを使うメリットは、同時に用意されたThe Synthesizer Toolkit (STK)を簡単に利用できること。STKはCCARMAを中心に開発されている音響合成ライブラリで、そのクラス・リストを見れば分かるように、基本的なオシレータやフィルタ、エフェクタはもちろんのこと、フィジカル・モデリング系の音源が充実している。Maxな人にはPeRColateという移植ライブラリで有名かもね。

と言う訳で例によってナンチャッテ路線で、MoMu-STKを使ってみよう。まずは「MoMuでオーディオ処理」に示した手順で爆音が出るようにしておく。そして、The Synthesis Toolkit (STK): MoMu ReleaseのサイトからMoMu-STKをダウンロード。その上での手順は以下の通り。ここではTubeBellクラスを用いて、鐘(チューブラー・ベル)を鳴らす。

(1) プロジェクトにMoMu-STK-1.0.0フォルダを追加。

(2) ソースコード(例えば〜ViewController.mm)で、ヘッダをインポートし、定数と鐘のオブジェクトを定義。

#import "mo_audio.h"
#import "TubeBell.h"

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

stk::TubeBell	*myBell;

(3) 適切なメソッド(例えばviewDidLoad)でMoMuのオーディオ処理の初期化と開始の後、鐘のインスタンスを生成し、鳴らす。

MoAudio::init(SRATE, FRAMESIZE, NUMCHANNELS );
MoAudio::start(audioCallback, nil);
	
myBell = new stk::TubeBell();
myBell->keyOn();

(4) コールバック関数では、tick()メソッドによって返される値でバッファを満たす。

Float32 *data = buffer;
for (int i=0; i<framesize; i++)
{
	Float32 value = 0;
	if (myBell != nil)
		value = myBell->tick();
		
	*data++ = value;
	*data++ = value;
}

このようにしてアプリを起動すると鐘が鳴り響くハズ。シミュレータでも実機でもOK。はい、おしまい。

というのも味気ないので、もう少しシンセシスらしいことをしておこう。

まずボタンを作り、Touch DownでplayBell:メソッドを呼び出すようにアクションを定義する。

- (IBAction)playBell:(UIButton *)sender
{
	myBell->keyOn();
}

同じくスライダーを作り、Value ChangedでmodulationChanged:メソッドを呼び出すようにアクションを定義する。

- (IBAction)modulationChanged:(UISlider *)sender
{
	myBell->controlChange(2, sender.value * 127.0);
}

これで、ボタンをタップすると鐘が鳴り、スライダーを動かすと鐘の音色が変わる。シンプルながら、これだけでもサンプリング音の再生では難しい音響合成ですね。他にもパラメータは沢山あるので、いろいろとイヂってみてください。

はい、おしまい。

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は処理速度がやや劣っている。これは現在のバージョンでは改善された様子だけど、タイミングがシビアな用途には向かない場合があるかも。

電子書籍「iOSの教科書」リリース

7/20に電子書籍「iOSの教科書」をwookよりリリースしました。期待の新鋭、神谷典孝さんとの共著で、前著「iPhone SDKの教科書」の精神を最新鋭の環境に蘇らせた!って感じかな。しかも、今回は電子書籍なので、可能な限り軽やかに多方面に展開したいと思っています。

そんなワケで、この電子書籍はiPhone、iPod touch、iPad、Android、Mac、PCのいずれでも閲覧可能です。また、書籍の内容の一部は試し読み可能で、基礎編での操作手順はチュートリアル・ビデオまであります。これらを含めて書籍サポート・サイトiosbook.netには、サンプル・コードやサンプル素材のダウンロードや各種情報が満載。冗談みたいですが、オーディオ・ブックもちょこっとだけ試してみました。

Lionでバリバリとアプリ開発されている方には本書は不要ですが、これからiPhoneやiPadのアプリを開発しようという方や、LionやXocde 4.1にはまだ馴染めないとい方にはバッチリだと思います。試し読みの上、ご購入いただければ幸いです。

iosbook-flyer