Yokemuraの開発ブログ(Yokemura's Development Blog)

とりあえず Logic7 を XCode から立ち上げるのはあきらめました；
AULab と Garageband はちゃんと立ち上がるのを確認できたので、ひとまずデバッグはそれで行って、最終的な確認に Logic を使おう、という感じです。

I gave up fighting the problem in launching Logic7 from XCode...
I've made sure that AULab and Garageband can be launched without problems, so I'm gonna do most of the debug operation with them, and use Logic only for final verification.

今さらながらソースファイル分割の正しい方法について勉強中です・・・。
extern宣言の使い方、関数プロトタイプをヘッダファイルに記述する利点、enum foo{ ... }; は単なる宣言なのか実体が作られるのか・・・etc.

プロジェクトを新しいものに移し替えたらコンパイルは通ったんですが、じゃあチェックしてみようということ XCode上でカスタム実行ファイルを設定して Logic を立ち上げようとしてみると「Logicはステータス45で終了しました」と言うばかりで立ち上がってくれない。
別途手動で Logic を立ち上げてプラグインを挿してみるとちゃんと動くのだが、これではコンソールを使ったデバッグとか一切できない。どうにかならんのか・・・。

I've transplanted my project to the new one and it compiled successfully.
Then I tried to launch Logic7 by setting the custom executable for the project but it fails to launch with error message "Logic exited with status 45".
When launching Logic directly by hand they(Logic and my plugin) work well, but I cannot use debug console etc. with this method.
Are there any good solution...?

これまで Magical8bitPlug の開発を XCode2.x ベースで進めてきたんですが、iPhone アプリ制作に絡んで XCode3.2 へのアップグレードを余儀なくされました。
で、アプリの件が終わって Magical8bitPlug の方に戻って見るとなぜかコンパイルが通らなくなっている。
エラーログを見てみると、AudioUnit 関係のヘッダやら何やらが別の場所に移されている模様。しかも、ディレクトリ構造も少し変わっているっぽい。
最初はなんとか直そうと思っていたのだけど、かなり面倒っぽくなってきたので新しいプロジェクトを起こしてそこにソースをコピーした方がいい気がしてきた・・・。

I was developing my Magical8bitPlug on XCode2.x but
by the requirement in developing iPhone App I was forced to upgrade XCode to ver.3.2.
When I've got my iPhone App things finished and back to my Magical8bitPlug's work again, I noticed that it's never compiled again.
Reading the error log to have found most of the AU-related files are moved to different locations.
Not only they're moved but the directory structure have been changed, too.
I tried to fix it at first, but now I'm feeling it may be better to make a new project and move my source codes into it...

次回起動時にアプリの状態が再現するよう各種変数を保存するための方法としては、アプリ終了時に NSUserDefaults に書き込みを行うのが一番一般的かつ楽な方法でしょう。
iPhoneOS3.x系では、そのNSUserDefaults関係の操作を applicationWillTerminate に記述することで実現できるわけで、実際これで動いておりました。
が、iOS4ではどうやら applicationWillTerminate 自体が呼ばれておらず、かわりに applicationWillResignActive だけが呼ばれている様子。
なので結局、iOS 3&4 両方で状態保存を実現するためには、applicationWillTerminate と applicationWillResignActive の両方に NSUserDefaults 関係のコードを書かないといけない。
なんか腑に落ちないよなぁ・・・。

(10/6追記)
もっと確実にやるためには applicationDidEnterBackground にも同じことを書かないといけないみたいです。

The easiest way to save the application's state so that it can restore them on the next launch is writing NSUserDefaults when the application is terminating.
With iPhoneOS3.x it can be done by writing NSUserDefaults related codes on applicationWillTerminate and everything worked well.
But it seems iOS4 no longer calls applicationWillTerminate but only calls applicationWillResignActive instead.
Consequently, to let your app have the save state function both on iOS 3&4 you have to write NSUserDefaults related codes both in applicationWillTerminate and in applicationWillResignActive.

(Added on 10/6)
You also have to write the same thing in applicationDidEnterBackground to make it perfect.

ObjCOSC で MIDIノートをOSCulatorに送るのは非常に簡単で、iPhone側は
[port sendTo:"/action" types:"f", 1.0f];
みたいに書いて、あとはOSCulatorの方で "/action" に希望のノートナンバーを割り当てればいい。

でも連続してノートを送ろうとすると、/action の値を一旦リセットしないといけないのがちょっと厄介。
というのは、OSCulatorは各アドレス（ここでは /action ですね）について前回送信した値を覚えていて、その値から10%以上変化した値を送らないと無視してしまうのであります。
とりあえずこんな感じで対策しました。
cocos2dベースのコードですが（"schedule:" は CCNodeのセレクタなので）、NSTimerを使えば同じことができると思われます。

// どこかのメソッドの中
[port sendTo:"/action3" types:"f", 1.0f];
[self schedule:@selector(sendNoteOff:) interval:1.0f];
// セレクタをひとつ追加
-(void) sendNoteOff:(ccTime)dt
{
  [self unschedule:@selector(sendNoteOff:)];
  [port sendTo:"/action1" types:"f", 0.0f];
}

Basically it's pretty easy to send MIDI notes to OSCulator by ObjCOSC.
Just write like this on your code,
[port sendTo:"/action" types:"f", 1.0f];
and assign desired note No. to "/action" on OSCulator.

But if you want to repeat this action, you have to reset the value to 0.0f before sending the next one.
This is because OSCulator remembers your last value you have sent to the address (in this example "/action"),and ignores the input message unless the value differs over 10% from the last value.

I did like below to manage this issue.
It's cocos2d-based ("schedule:" is the selector of CCNode) but I believe you can do the same with NSTimer.

// In some method in the class
[port sendTo:"/action3" types:"f", 1.0f];
[self schedule:@selector(sendNoteOff:) interval:1.0f];
// Add this method to the class
-(void) sendNoteOff:(ccTime)dt
{
  [self unschedule:@selector(sendNoteOff:)];
  [port sendTo:"/action1" types:"f", 0.0f];
}

I gave it a go with my iPhone(iPad)-OSC system in my last performance. I was so nervous because I couldn't assure its stability till the performance had finished.
The system is connected by ad-hoc Wi-Fi network with my iBook be the base station. Most of the time it's working well, but from time to time unknown disconnections took place and brought me heart attacks.

Besides the OSC related things, there were some other difficulty with iPhone/iPad themselves.
For example
* I have to be aware of battery remainder because I have to leave them awake all the time so that keep them connected to Wi-Fi (if you let them sleep it takes long time to reconnect!)
* I had to pay lots of attention when pick the device to show it to the audience because just a bit of touch on the screen may cause undesirable action of the App.

On reflection, as it's my first time to work with this system, so it'd be better to have begun with less critical kind of usage. This time it was very critical, that is, if it didn't work the whole performance might have been spoiled.

ライブで実際に iPhone(iPad) - OSC を絡めたシステムを運用してみましたが、まぁヒヤヒヤものもいいところ。
iBook から Wi-Fi ネットワークを立ち上げて接続しまして、基本的には安定して接続できてたんですが、時々急に不安定になったりするので最後まで不安が拭えませんでした。

あと OSC以外のところでは、iPhone/iPadそのものの取り回しがけっこう大変でした。
いちどつながったWi-Fi を切断したくないのでスリープはさせたくないがそうすると電池残量を気にしなきゃいけなかったりとか、オペレーションがタッチセンスのみ、しかもほぼ全面がタッチセンサなのでステージ上での取り回し上すごく気を遣う、とか；

初使用だから、多少の操作ミスもご愛敬になるような場面で使えば良かったのに、いきなりクリティカルなところに使用してしまったのもアレですね；

ライブで使うにあたって、いちいち時間制限を気にしてられないのでライセンスを購入しようと思ったら、最初出来なくてちょっとあせった。Safariが古かったのがいけなかった模様。(Safari 4.0.5)
最新のFireFoxでは問題ありませんでした。

I decided to use OSCulator in my live performances and to buy the license of it, but unable to purchase the license at the first time.
It may be because Safari's version is too old (Safari 4.0.5) .
With the newest FireFox caused no problem.

ObjCOSCは最初の印象ほど難しくはなかったです。
わりと簡単に送信できました。
しかし、今さら気づいたのが、OSCulatorの方が受信しかできないという点。OSCメッセージを受け取ってMIDIに変換することはできるが、逆はできないという。
がっつりインタラクティブなことをやろうとするとこれはけっこうな制約・・・

（9/29追記）誤解してました。できるようです。
http://www.osculator.net/doc/manual:midi_input

I've found ObjCOSC isn't so difficult than my impression at first glance.
But I also found that OSCulator cannot convert MIDI signal to OSC message.
It can only receive OSC message and convert to other signals.
It's a big problem in making full-interactive kind of system...

(added on 9/29) I was misunderstanding. It can.
http://www.osculator.net/doc/manual:midi_input

I'm now trying to build a remote control system with OSC(Open Sound Control).
As I'm planning to use my iPod Touch as the client so I thought using ObjCOSC framework must be convenient, but it seems not to match with my environment very well.
There seem to be other OSC related libraries, so I'll go check them out.

OSC(Open Sound Control)を使って遠隔操作みたいなシステムを組みたいと思ってまして。
クライアントにはiPod Touchを使いたいということで調べたら、ObjCOSCフレームワークがあるらしく、早速使ってみたのだけど、ちょっと相性が合わないっぽくてちょっとうまく動かない感じ。
他にもOSCを扱うライブラリとかあるっぽいのでもうちょっと調べてみよう。