みるくCocoa

今年の４月から開発を開始したMIDIWindシーケンサの今の状況はこんな感じです。

まだまだ未完成ですが、それっぽい形が出来上がってきたところです。
MIDIファイルの中身が表示されて、再生もできますが、編集機能はまだありません。

MIDIWind2.1.1をリリースしました。
単純にMacOSX10.7に対応させただけで、特に追加機能はありません。また、このバージョンから動作環境が10.6以降となりました。

10.7で動作上問題となったのが内蔵のソフトシンセで、Deprecatedな古いAPIを使用するとアプリごとクラッシュしてしまいます。また、なぜかコントロールチェンジ#93（コーラスエフェクト）を送るとフリーズします。

今回のアップグレードで、Deprecatedな古いAPIを10.6の新しいAPIに書き替え、余計なコントロールチェンジを送信しないようにフィルターを施しています。

OSをMacOSX10.7(Lion)にアップグレードしました。
そして、またしてもMIDIWind2.1の一部の機能が動かなくなりました。

ソフトシンセで再生しようとすると、アプリケーションが予期せず落ちてしまいます。
幸い外部音源の再生は問題なくできるようです。

MIDIWind2.1はMacOSX10.4がターゲットで、ソフトシンセ周りでDeprecatedなAPIを使っていて、このAPIがLionで使用不能にならないことを祈っていたのですが、残念ながらその祈りはAppleには届かなかったようです。
これから、10.7対応に修正する予定です。

MacOSX10.7でも新しいAPIがいろいろ追加されていますが、ジェスチャー・フルスクリーン・自動保存＆バージョンなんかが大きなところかな。まだ詳しく見ていないが、自動保存に伴う「非同期保存」の実装が少し気になるところだ。保存中にデータを書き換えたらどうなるんだろうか？　あと、CoreDataの自動保存ってどうなるんだろ？　自動保存関連の機能追加が無いように見える。
その他にも、TableViewでCellの代わりにViewが使えるようになった。今まではMatrixを使った実装だったので同じcellを並べることしかできませんでしたが、Viewだと行ごとに違うものを使ったりとか出来るっぽい。単純にデータをリスト表示するのとは違うものが作れそうだ。
それから、新しいViewのレイアウト機能が追加された。でも、Xcodeが対応していないっぽく、コードを書いてレイアウトしなきゃならないっぽい。なんか不便だ。

予定どおり現在MIDIWindシーケンサを開発中です。MIDIWindシーケンサは、ようするにSMFファイルの編集ソフトです。ピアノロールやイベントリスト、リアルタイム入力なんかを予定。

Xcode4になってUnitTestが使いやすくなったので、今回の開発ではテストファーストを実践しています。テストファーストとは、先にテストコードを書いてから、そのテストに合格するように本体コードを書く開発スタイルのことです。今のところ、少々ぎこちないながらもなんとか形になっている状況です。噂どおり、テストを全てクリアするのを見るのは、なんだか楽しいですね。

それから、プロジェクトの管理にRedmineを使い始めました。RedmineはRubyで作られたWebアプリケーションで、うちではApache2 + mod_passenger + MySQL5の組み合わせで運用しています。Redmineでは「チケット」を使ってプロジェクトを管理します。リポジトリのリビジョンをチケットに関連付けることもできます。
そして、このMIDIWindのプロジェクトは公開することにしました。リポジトリも公開するので、コミットしたソースコードをリアルタイムに見る事ができます。

MIDIWindプレイヤーの方は、MacAppStoreに出して見ました。無料なので、開発者側に金銭的なメリットは無いですが、ユーザー側にAppStoreのソフトが充実することへのニーズがあるなら、それに答えてもいいかなと思いました。それに、AppStoreに並ぶソフトが有料ソフトばかりというのも、ちょっと寂しいですしね。

MIDIWind Player Edition v2.1をリリースしました。

今回のバージョンでMacOSX10.6に対応するようになり、これでJavaのコードが全て削除されました。また、ユーザーインターフェースも大幅に修正しました。

MIDIWindを作るのは、これで3回目です。バージョン1.0のリリースが2004年なので、7年も開発を続けたことになります。こんなに何度も作る予定ではなかったのですけどね。
思えば、Cocoa-Javaを使ったのがそもそもの始まりでした。当初、JavaはMaxOSXのコアなコンポーネントと位置づけられていたので、まさかOSから削除されるとは思ってもいませんでした。

以前にも書いたことがあると思いますが、MIDIWindはもともとMIDIプレイヤではなく、MIDIシーケンサを作るためのプロジェクトです。MIDIプレイヤは、MIDIデバイスへのアクセスをテストするために、シーケンサに先行して作成したに過ぎません。
そういう訳で、今度こそMIDIWind Player Editionの開発は、バグが出ないかぎり終了にする予定です。4月ぐらいから、シーケンサとしてのMIDIWindの開発が始まるはずです。

まったりと開発を進めていたMIDIWind2.1がある程度形になってきたので、ベータ版として公開することにしました。

今回のバージョンでMacOSX10.6に対応するようになり、これでJavaのコードが全て削除されました。また、ユーザーインターフェースも大幅に修正しました。
ただ、見ての通りまだまだ未実装な部分が多いので、完成までにはもう少しかかりそうです。

MacOSX10.6でCocoa-Javaな環境が綺麗さっぱり消滅した影響で、MIDIWindが動かなくなりました。
で、どうしようか迷っていたのですが、MacOSX10.6対応版を作ることにしました。いちおうターゲットはこれまでと同じ10.4です。そのため一部10.6でDeprecatedとなったAPIを使うことになりますが、これはこのAPIが10.7で消滅しないことを祈るしかありません。

ちなみに、現在の開発状況はこんな感じです。

見ての通りターミナルの画面ですが、別にMIDIWindがコンソールアプリになる訳ではありません。
MIDIWindは、MVCパターンに沿った設計をしています。そしてMVCパターンでは、
・Viewは、ModelとControllerに依存する。
・Controllerは、ModelとViewに依存する。
・Modelは、どれにも依存しない。
となっているので、理論上Modelを先に作る方が、開発効率がいいはずなのです。それで今回は、Modelを先に作って、それをテストするために、GUIの代わりにCUIを作って見ました。見た目はコンソールアプリですが、GUIなものと同等の機能を持っています。

Modelの方はだいたい出来上がったので、これからViewとControllerを作ります。

DIコンテナであるCocoaDIをバージョンアップしました。
今回の目玉は、プールオブジェクトです。
これは、同じオブジェクトを何度も再利用したり、複数の箇所で共有したりする場合に使います。

プールオブジェクトを使えば、必要なときにobjectForName:でコンテナからオブジェクトを取り出し、不要になったらreturnObject:でコンテナにオブジェクトを返すことで、同じオブジェクトを何度も再利用することができます。オブジェクトを新規に生成するか、プールしてあるオブジェクトを使うかは、objectForName:が判断します。

プールオブジェクトのもう一つの活用法は、オブジェクトの共有です。
生成されるプールオブジェクトには、数量を制限することができ、たとえば５つのオブジェクトを１０個のスレッド間で使い回すようなことができます。オブジェクトの取得にlimitPoolObjectForName:を使えば、上限に達してオブジェクトが取得できないスレッドをロックし、他のスレッドがreturnObject:したときにロックが解除されます。

その他の新機能として、これまで未実装だったlong long、double、NSInteger、Class、SEL、NSData、NSDateの各パラメタータイプが実装されました。
ただし、SEL型については、プロパティーインジェクションに使えません。Key Value CodingがSEL型をサポートしていないためです。以前は、Class型もサポートされていなかったのですが、MacOSX10.5からサポートされました。

その他の変更点として、GCのサポートを必須から有効に変更しました。当初は「これからは、Objective-CもGCが標準の時代だぜー」とか思ってたのですが、やっぱりもとの参照カウント方式に戻して、GCを使うかどうかは、CocoaDIを使う人の自由にすることにしました。

以前、「フレームワークのテストとデバッグ」ということで、SenTestingKitフレームワークを使ったテキスト版TestRunnerについて紹介した訳だが、これがMacOSX10.5から使えなくなっていることが分かった。
調べて見ると、SenTestingKitフレームワークが/System/Library/Frameworksから無くなって、/Developer/Library/Frameworksに移動している。
フレームワークが消滅した訳ではないが、/Developer/Library/Frameworksは、実行時のライブラリ検索パスに入ってないらしく、ビルドはできても実行できない。
そして、XCodeのテスト機能は、依然としてビルド時に実行されてしまうため、そこからデバックに繋げることができない。

そういう訳で、テキスト版TestRunnerを自前で作って見ました。
特別なフレームワークは使っていませんが、作ってみると以外と簡単でした。
CocoaのNSAssertを拡張する形で作っており、Objective-Cのruntime APIを使って、テストケースを自動的に検索するため、テストは[TestRunner run];の１文で実行できます。
また、Objective-C++の関数オーバーロードを利用しているため、assertEquals()一つで、id, int, floatなど複数の型に対応し、テストが書きやすくなっています。

それと、テスト時間の計測に最初は、mach_time APIを利用していたのだけど、これが PowerPC Macでは使えるのに、Intel Macだと何故か使えないんですよね。同じバージョンのOSなのに、困ったものです。
しかたがないので、CoreServicesのAbsoluteTime APIに変更しました。ADCのドキュメントの方でも、mach_time APIよりもAbsoluteTime APIの方を優先して使うような感じのことが書かれていました。
でも、AbsoluteTime APIは、64bitをサポートしてない感じで、微妙に使いづらい。

CocoaDI ver1.2をリリースしました。

CocoaDIを使って、MIDIWind3を作っていると、バインドがうまく行かないなど、もろもろの不具合が発覚。
それらを修正したバージョンを作りました。

それから、MacOSX10.4とMacOSX10.5の２つのソースコードをメンテナンスするのが面倒になったので、今回のバージョンからMacOSX10.4版を削除しました。
MacOSX10.4ユーザーのみなさん、ごめんなさい。まあ、これからはMacOSX10.5の時代ということで。