前回はUGenを中心としてSuperColliderの世界への探求を試みてみた。今回はその上位構造となるSynthDefを見ていこうと思う。
SuperColliderはクライアントサーバ型アーキテクチャであることは既出のことなのだけど、SynthDef、そしてSynthがこの二つの間にかかった橋だと言えるだろう。UGenは確実に向こう側の世界だ。
お約束だけど、まだSuperColliderへの冒険の道半ばなので、間違っていることが含まれているかもしれないということは注記しておこうと思う。
Multitarget Ping Tool – Pingmania
もうすでにAppStoreにならんでるのだけど、とある方面からのリクエストにより、ほとんどの方にはいまいち使い道がないのではないかと思われるアプリを実装した。どういったツールなのかというと、同時に複数ターゲット（最大１６）に対してPingのステータスをとり続けられるというツールなのだ。
ネットワークの回線を生業とするプロの方々が使うツールらしい。
例えばネットワーク回線が集中するようなイベント会場などでどのルートがどれぐらい負荷がかかってるかなどをチェックして、対策を打つなんて事に使うようだ。
実装はICMPのEchoプロトコルを使って実装している。つまり、普通のPingなんだけど、iPhone OSではネイティブソケットでICMPタイプを作らせてくれないので、そのあたりの実装が一工夫必要だった。しかし、それもなんとか解決できた。
他にも同時にPingを投げるにあたって、構造上別ターゲットのものに影響をうけないように、といったことにはかなり気を配って実装してある。見た目は地味だけどプロの方がつかえるツールとして仕上がってるのではないかと思う。
そして、このエントリのアプリケーションイメージを作るのにiPhone Screentakerというソフトを使用したのだけど、スクリーンショット画面をごらんの通り、iPhoneの画像にはめ込んでくれる。他にも何通りか用意されていて、なかなか良い感じになる。おすすめです。
PingmaniaはRusty-raven社よりAppStoreで発売中です。
How to run OpenMusic on OSX
１２音技法での対位法の扱いを調べている時にWikipediaに載っていた、
現在の代表的な自動作曲ソフトウェアとして、フランス国立音響音楽研究所IRCAMが開発したOpenMusicが挙げられる。このソフトウェアの説明書に付属するチュートリアルの初歩段階に、十二音技法の音列各種を自動生成する練習課題がある。
という記述になんとなく興味を引かれて、OpenMusic
というのがどういったものなのかを見てみようかという気になった。
OpenMusicはMaxやPdなどで有名なIRCAMのプロジェクトで、Max等とは違って、どちらかというとアルゴリズミックコンポジションの方にフォーカスしているようだ。いかにして波形を作るかというより、いかにして音符を作るか。そう言い換えることが出来るだろうか。
音列に対して逆行、反行、反逆行などはもちろん、時間的な変形を行うことが出来るのはもちろん、限定されたランダムネスのなかから音列を作ったり、音列の生成変形に関してその機能は網羅されている。らしい。
らしいというのは、わたし自身がまだ全然機能を試せていないため、何が出来るということを把握していないためだ。
OpenMusicのソースコードはLGPLで公開されているので、誰でも試すことが出来る。出来るのだけど、実はLISPで書かれているので簡単には動かなかった。色々試してみた結果、なんとか動くようになったので、手順を書き留めておこうと思う。
Exploring Into SuperCollider
少々前よりSuperColliderをいじっている。SuperColliderというのは、あえて説明することもないぐらいの有名どころなのだけど、主に音楽・音響記述に長けたプログラミング言語環境だ。音響系といってもDSPなどのストリームプロセスを書くというよりは、むしろ、ノードの接続を記述してシンセサイザーをつくり、それをコントロールするロジックを記述して動かすというのがコアな部分のようだ（もちろんそれ以外が出来ないというわけではない）。
Maxなどともコンセプトでは似ているところもあるのだけど、決定的に違うのはそれがビジュアルプログラムではなくテキストコーディングで行うものという点ではないかと思う。
わたしがSuperColliderに興味を持ったそもそものきっかけは、SC140というTwitterに書けるだけの分量でSuperColliderで音楽を作ろうという試みがあるということを知ったときだった。そのミニマムな魅力にくらくらっときて自分でもやってみたいと思ったのだった。
SuperColliderは少々取っつきにくいところがあるのだけど、コミュニティのパワーが補って余る。わたしもとても助けられている。特に、@umbrellaprocess氏(on twitter)にはわたしの初歩の初歩な質問にもきちんとレスポンスをいただき、大変感謝している。
SuperColliderのTutorialは、公式のIntroductory Tutorialがよくまとまっていると思う。今見返してみると、よく読めばちゃんと書いてあるということも多い・・・。
わたしはSuperColliderを学ぶ上でまずターゲットに決めたのはUGenというクラスだった。その部分がSuperColliderでシンセサイザ（音響処理も含む）を扱うクラスの基底クラスだったというのがその理由だった。
今回、とりあえず今までに分かったことをまとめてみた。しかし、まだSuperColliderへの冒険の道半ばなので、間違っていることが含まれているかもしれないということは注記しておこうと思う。
The Issue About Different Behavior Of UIScrollView Over Device Generations
Irodoriの1.1版は嬉しいことにUSのitunes storeのNew and noteworthyに載せてもらうことができた。1.1版の特徴は、要望が多かった既にPhotoAlbumに保存してある画像からの解析機能なんだけど、これを実装するときに、わたしとしては初めて同じバージョンのiPhone OSのデバイスの機種間での挙動の違いを体験したので、メモとして書いておこうと思う。
iPhone OSは基本的なアーキテクチャは一貫している印象があって、iPhoneかiPod touchか、OpenGLES2対応かそうでないか、ARM6か7ぐらいかの違いしか無くて、しかも後方互換性があるので、一番ベーシックなところで作っておけばどれでも特に対策をする必要もなく問題なく動くというものだと思っていた。
特に一番基本的なApplication FrameworkであるCocoa touchなんかは上位レイヤーにいるのでどのデバイス用でも同じものを使ってると（そうしない理由があまり浮かばないので）思っていたのだ。
もちろんシミュレータは今までにも違う挙動を示すことがあった。しかし、iPhoneで開発をした方なら分かると思うのだけど、まあ、シミュレータだしな、というところはあった。
さて、問題になったのはUIScrollViewだ。このクラスは表示サイズより大きいものや、複数あるビューを選ぶようなとき、スクロールや拡大縮小機能を提供してくれる。UITableViewはUIScrollViewの派生クラスだ。こういう前置きも必要無いぐらい基本的なクラスだと思う。
このクラスには、中においたコンテンツビューの端に余白を空けるように出来る機能がある。それがcontentInsetで、それぞれに指定したピクセル分端に余白が出来る。コーディングとしては同じ事がUIScrollViewを小さく作っておいてclipsToBoundsをNOにしておくことでも実現できる（clipsToBoundsをNOにするとコンテンツビューがそのサイズでクリップされなくなるので）。
contentInsetを使った方が便利な点はスケールした場合も座標の計算を行わなくても良いという点。コンテンツビューのスケールに依らず指定ピクセル分の余白を空けてくれる。もちろん、スケールに合わせてコンテンツビューサイズを変更すれば同じ事は出来る。
Irodoriでは指定された画像から解析用の画像を切り出すという処理の切り出し部分を指定するところにUIScrollViewを使用した。初期値は縦または横の短い方がちょうど切り出す領域の大きさになるように拡大または縮小している。切り出し領域は画面端よりオフセットされた位置にあり、その上下左右をcontentInsetで指定している。
このスケールされた状態で領域と同じ大きさの場合スクロールはされない。contentInsetの分とスケールされた辺の長さを足したものが丁度UIScrollViewの大きさと同じになるためだ。正方形の場合は固定された状態に（初期的に）なる。
これが期待されるべき動作で、仕様通りでもある。さらにいうとiPhone 3Gの3.1.3ではその通りに動作した。しかしシミュレータでは動作が異なっていた。拡大縮小およびスクロールを繰り返した後、または最初から。そのタイミングは決まったものではなく、突然「外れる」のだ。まさしく、外れると表現するのがいちばんその状態にしっくりと来る。
シミュレータだけの問題なら放っておいても問題ないのだけど、iPod touch 1st gen.で試してみたら、なんとシミュレータと同じ挙動になったのだ（つまり、「外れた」）。バージョンも確かめてみたのだけど3.1.3だった。
つまりは同じバージョンのOS間でAPIの挙動が異なったというわけだ。
こういう時はたいてい非正規な初期化など、どこかミスをしてることが多い。しかし、色々と試してみたけれども、片方はちゃんと動作し続け、もう片方は「外れた」ままだった。
そのものずばりな解決方法があるのかもしれないが、わたしはとりあえず次のように対処しておいた。
- UIScorollViewDelegate protocolのscrollViewDidEndDragging:willDecelerate:のdecelerateがNOのとき
- またはscrollViewDidEndDecelerating:が呼ばれたとき
このときにcontentOffsetの値の値が範囲を超えていた場合に範囲内に戻すようにした。contentOffsetプロパティに直接設定しても良いし（setContentOffset:）、setContentOffset:animated:を使用し、戻るところをアニメーションさせることも出来る。アニメーションさせた場合も終了時にDelegateのメソッドscrollViewDidScroll:が呼ばれるので、そこでスクロール中は禁止していた処理を許可状態などにする。
もっともこれが確認できるのは一部の機種に限られるのだけど。
Irodoriの場合、領域切り出し部分なので、仕様通りの動作を期待すると「外れていた」場合、領域外までふくむことになり、最悪の場合BAD_ACCESSで落ちてしまう（そして落ちた）。UIが絡むところはやはりその値がちゃんと想定した範囲内かどうかはチェックした方が良いな、と、再認識したのだった。
Irodori is ready for sale!
申請していたアプリが、今日審査に通ったという通知が届きました。これが前から少し話題に出していたアプリで、カテゴリとしてはカメラアプリになるのだけど、写真を撮る事が目的ではなく、カメラを通してそこにある色をサンプリングしようというのがそのコンセプトです。
アプリケーションの名前は”Irodori”といいます。
使い方は至って簡単で、他のアプリと同じようにツールバー上のカメラアイコンを押すとカメラ画面になります。
ここで撮影をすると、それを解析した特徴色が16色ほどピックアップされるので、その中から気に入った色があればお気に入りマークをつければ、自分のカラーパレットにお気に入りの色が集まっていくという仕組みです。
そうやってピックアップした色見本をメールやtwitpicで家族や友人に見せることも出来ます。
無料のお試し版は出来ることはここまでで、保存できる枚数にも制限があるのですが、アプリ内課金で機能制限解除版を購入していただくと、さらにパレットをAdobe act形式やase形式、PaintShop pal形式でのエクスポートも可能になります。もちろん保存できる枚数の上限も大幅に増えます。
基本機能は無料お試し版で使用可能なので、是非一度お試しください。
Implementing Delayed Loading
再申請したアプリの結果は、今日の時点ではまだ返ってきていない。大体in reviewになってから結果がくるまでに営業日で７日ぐらいかかるようだ。アプリの審査が通ったら、お披露目しようと思うのだけど、また要再提出となると、また一週間ということになって・・・。iPhoneアプリはこのあたりが一番難しいですね。
任天堂やソニーなんかはもっと速いんだけど、審査をする本数も全然違うというのもあるんだろう。そういえば任天堂にはマリオクラブ（いつのまにか会社になっててびっくりした）というのがあり、初めて名前を聞いたときは秘密結社？などと思ったのだけど、ソフトのクォリティコントロールをしているところだ。ここが、ＯＫを出さないとリリースさせてもらえない。ソフトウェア上のバグから、どのロットのハードではちゃんと動かないなどというレポートまで報告してくれる。どのロットのハードでもちゃんと動かないとダメというのが、任天堂は遊べるということには強いこだわりがある会社なんだなという印象をうけた思い出がある。
さて、今回申請したアプリはたくさんの画像を扱うもので、すべてをメモリ上に持っておくことが出来ないので、必要になったらロードしないといけない。とはいえ、いちいち待たされてから、画像の内容を判断するのはもどかしいので、まずは荒くでも見たい。最初に軽いけど荒い画像を表示しておいて、そのうちに隙を見て正式な画像をロードする、つまり遅延読み込み（delayed loading）だ。
Human Interface Guidelines is Worth Reading For Developers
Appleは昔から、アプリケーションの挙動はこの場合はこうするのが良いという「お作法」をHuman Interface Guidelines(HIG)という形でアプリケーションデベロッパに提示している。そのせいもあってか、Macのアプリはこういうものはここにあるとか、こうすればいいということにカンがかなり効きやすくなっている。
それは、iPhone OSでも同じで、iPhone Human Interface Guidelinesという形で示されている。
先日、iPhoneアプリをsubmitしたのだけど、昨日HIGに適合しない部分があるというrejectをいただいてしまった。その結果のメールを受け取ってから、しまったと思ったのだけど、動作がちゃんと行われるというのは事前にチェックしていたのだけど、HIG関連はチェックしていなかった。これからは必ず申請前のチェックに入れようと思う。また、チェックリストも作ろうかなと思っているところだ。
わたしが引っかかったのはHIGでもSystem-Provided Buttons and Iconsという項目。そのなかに”Standard Buttons for Use in Toolbars and Navigation Bars”という項があるのだけど、つまり、システムデフォルトで用意されているアイコンには決まった動作が規定されていて、そのアイコンを使うならその規定に従ってねって事なのだ。
わたしは”Action”というボタンアイコンを押したときに独自ダイアログを出すように実装していた。規定の項目を見ると”Opens an action sheet that allows users to take an application-specific action”とある。アクションシート(UIActionSheet)を開いてその中から動作をユーザに選ばせるというのが規定されている動作だ。その点が違うので修正してねって事だった。
早速アイコンを独自のものに変えて再提出した。事前によく読んでおけば避けられたポカミスってところかな。ついでに表示上の自分のURLのスペルを間違うという恥ずかしいミスを修正できたのでラッキーだったと思ったりもする。
と、いうわけでiPhoneアプリを作るデベロッパーにとっても、HIGに目を通しておくっていうのは重要じゃないかと思うのだ。
Locole!
わたしが音楽を担当させてもらったiPhone用のパズルゲームが本日発売になった。
線路パネルをうまくつないでいって電車をゴールに導くという、ルールはとてもシンプルだ。ただ解く（ゴールに到達する）だけならそんなに難しくはないだろう。ゲームとしてはイージーな部類に入るので、歯ごたえを求める方には物足りなく感じるかもしれない。
しかし、それを上回る魅力がこのゲームにはあると私は感じる。ミニチュア感というのだろうか、箱庭的なそのグラフィックが、まさに見ているだけで楽しいのだ。デバッグしながら本気で遊んでしまったゲームというのはかなり久しぶりな気がする。
フィールドには鉄橋やトンネルもある。そこを通す必要が無くてもなんとなく通したくなる（そしてはまったりもする）。画面上には乗車率ゲージがあるのだけど、それが赤になった状態で電車をあちこちに連れて行くと、なんとなく申し訳ないような気がしてくる。そういうイマジネーションがかき立てられるミニチュア感がそこにあるのだ。
リプレーモードもついていて、時計代わりに出来たりもするのだけど、なぜか思わず見入ってしまう。時間泥棒である。
カタルシスなどとは無縁な、とてものほほんとしたゲームだけど、基本１−３面がお試し無料なので、ぜひプレーしてみてください。私的に超プッシュです。
Music from LocoleもWorksのページに追加しました。よければ聴いてみてください。
Kindle or not
Kindle用の電子書籍を買ってみた。Kindleのハードウェア自体は持っていないのだけど、Mac用のソフトが丁度公開になったのだ（我が家にWindows PCはもはや存在しない・・・）。amazon.comのアカウントはメールアドレスは同じでもco.jpとは別扱いになるとか、そういう小さなクリアしないといけないことはあるけど、どこからソフトをダウンロードすればいいかが分かれば、後はそんなにたいした問題ではない。このiPadがまもなく出ようという時期にKindleか、なんて思わなくもないんだけど、iPadでもKindleアプリが出るようだし。
電子書籍というものを買うのは初めてではなくて、以前にPDFで売っていたものを買ったことがある。とあるパーサジェネレータの解説書だった。今回購入したのもそうだけど、１年や２年すると内容が古くなって使えなくなるような技術書というのは電子書籍と相性が良いような気がする。自動的に内容がアップデートされるとなお良しなんだけど、そこまですると商売にならないか。メーカー公式の開発資料とかサブスクリプション方式の課金なら可能かな。iPhone SDKのドキュメント類もそうなっているし。
Kindle for Macの操作上のちょっとした違和感は、何かを買おうとするとWebブラウザに操作がうつるということ。Kindle for Macはあくまでもビューアであるらしい。Kindle用に用意された本のリストを見ようとすると（Shop in Kindle Storeというボタンがある）Safariに表示されたamazon.comのページに移動させられて、そこで購入したものを登録したどのデバイスに送るかを選んで戻ってきてみるという手順になる。なんだかDropBoxで隣のマシンにファイルを送っているようなもどかしさがある。
Kindleが良いなと思う点はちゃんと内容を見て買うことが出来る点かな。見ることが出来るのはアマゾンでのプレビューと変わらないのだけど、書籍はプレビューが用意されているものとされていないものがあるけど、おそらくKindle版は全部にプレビューが用意されているんじゃないだろうか（違うかもしれない）。
今回Kindle版を買ってみようと思ったのは、主に好奇心なのだけど、iPhone版で同じ書籍のプレビュー版を見たとき、意外と読めるなと思ったのも大きい。おそらくhtml的な何かなのだろうけど、スクリーンサイズに合わせてそれなりによめるものになっている。ところどころ単語間が妙に開いてたりもするんだけど（レイアウトの都合上）、ネイティブの人はこういうところにイラっとなったりはしないのだろうか、なんてふと思ったりもした。
買ってみてあれ？っておもったのは、文書のコピペは出来ないということ（サンプル版はできなくても仕方がないと思っていたのだけど）。コードのサンプルなんかはコピペして手軽に試してみたいところなんだけど、これも書籍ごとに設定が違ったりするのだろうか。隣に表示しているのをみながら横でそれを打つというのはちょっと間が抜けている感じがする。
あとは貸し借りが出来ないというのが意外と不自由だなと思う点。これはKindleに限らないことなんだけど。「この本面白いよ、読んでみな」と家族に勧められないのは、何とかならないのだろうか。それとも何らかの方法があるのだろうか。
冒頭の写真はInside Macintosh。裏の値段は３０ドルちょっとになってたけど、当時日本で９千円ぐらいしたような記憶がある。内容はもう全く役に立たないんだけど、記念に今でも本棚にある。