March 2010 Archives

先週からなかなか開発時間がとれないうちに類似のアイディアを実装したアプリも出てきてしまったのだけど、とりあえずjquery-svgを使ってlemurもどきをつくってみようと思っている。プレイヤとは別にGUIデザイナまで作らないといけないことを面倒に感じて、なかなかやる気が出ないのも問題なのだけど。

とりあえず今計画しているのは、JSONに落とし込んだinstrumentを、メインのHTMLから読み込んでWebBrowserで表示するだけのアプリだ。instrumentはGUIデザイナで作成して、JSONとして保存する。メインHTMLでは静的あるいは動的にそのJSONを読み込んで、プレイヤの実装となるJavascriptがそれを処理する。GUIデザイナはブラウザアプリで作ると大変そうなので、とりあえずlemurを眺めながらでっちあげた構造だけをC#で書いてある。まだ何も出来ていないが、役割分担するコード片を作ってみた。まだJSONの楽器定義を読み込むようにもなっていない。

• プレイヤの実装(JS): http://gist.github.com/349034
• メイン画面の例(HTML): http://gist.github.com/349033
• デザイナ用UIコントロール定義(C#): http://gist.github.com/340045

まあ途中であきらめてプラットフォーム別の実装にしてしまうかもしれないが、とりあえず出来る範囲ではこれで進めてみようと思っている。まだjquery-svgどころかjquery...どころかjavascriptをよく分かっていないので、のんびり勉強しながら進めていくことになりそうだ。

androidのパッチは試行錯誤の末投げることができたので、次に気になったwebkitのSVGサポートまわりを眺めてみることにした。androidのwebkitのソースには、webkitの特定のブランチから引っ張ってきたものと、Javascriptエンジンv8の特定のブランチから引っ張ってきたもの、あとこれはどれのことを指しているのか分からないがchromiumの特定のブランチから引っ張ってきたものがあるようだ。ただ、v8が実際に使用されているかどうかは分からない（「ガベージコレクションのアルゴリズムと実装」でのv8に関する記述を見た限りでは、少なくともこの執筆当時にはv8は有効でなかったことが読み取れる）。

webkit自体は前回書いた（修正を加えた）通りskiaを使っていて、androidのwebkitのソースでもsvg関係のツリーは含まれている。ただしAndroid.mkで参照されているソースとしては含まれていない。ツリーをそのまま持ってきて、makeから除外している。そして、Android.jsc.mkなどを眺めてみるに、ENABLE_SVGというビルドのフラグをonにすると、どうやらSVG関係のソースをビルドに含めているように見える。これはどうもbuild/buildspec.mk （これ自体はデフォルト）の中にあるENABLE_SVGをuncommentすると良いように見えるのだけど、とりあえずまだSVGが有効になったwebkitのビルドには成功していない。

この辺はもう少しトライしてみたいところだけど、makeでビルドするとclean buildになって非常に時間がかかってしまうので、もう少し短縮できる方法は無いか探ってみたいところだ。でもwebkitは他のいろんな部分で使われているだろうから、整合性のあるビルドを構築するのは大変かもしれない...

sf2xrniがひと段落ついた、というより公式フォーラムなどに投げてみても全く反応が無くてフィードバックも無いので、これ以上自分でバグ潰しするのは何か打ち込む時にしようと決めて、こっちは放置することにした。

というわけで、次はlemurもどきだ。月初にGUI設計をHTMLベースで記述する可能性について考えたわけだけど、今週は知人とも何となく相談してみたりなどして、これをもう少し具体的に検討してみた。なるべくcocoatouchでもandroidでも動くようなコードの共通化を実現したい。

まずWebページとバックエンドロジック（OSCの送信など）のinteropについて。webviewとGUIフレームワークなんて出来るのか分からんから、とりあえずHTTPサーバをローカルで立てて、ブラウザはそこを叩き、HTTPサーバがバックエンドのロジックを実行するのはアリだろうと考えた。HttpListenerがlocalhost:8080で動いていて、webページはそこをPOST先にする、といった感じだ。動くかもしれないけど、多少回りくどいので重いだろう。

それより、もう少し直接的に、Javascriptとネイティブオブジェクトのinteropが可能なのではないかと思って調べてみた。そうしたら、案の定出てきた。

• CocoaTouchの場合: WebScriptObjectというプロクシを経由することで、Objective-Cの関数を呼び出せるようだ。webViewのwindowScriptObjectに、オブジェクトをプロパティとしてsetすることで、Javascript上でwindowオブジェクトのプロパティとしてアクセスできる。
• Androidの場合: WebViewクラスのaddJavaScriptInterface()を使うことで、Javaオブジェクトを変数にバインドできるようだ。

どちらもそれほど難しいものではなさそうだ。anowaveを作った時に使ったflashとjavascriptのinteropと、仕組みは類似している。SilverlightのRegisterScriptableObject()も同じようなものだと言えるだろう。

追記: SafariのJS proxyの情報は正しくないようだ。というのは、これはあくまでCocoaだけのもので、CocoaTouchでは使えないらしい。これは困った...まあHTTPサーバを裏で立てれば良い問題ではあるけど。

interopが実現出来そうだと分かったので、次はUIをどう記述するかが問題だ。先日はHTML Canvasを使えば良いと思っていたけど、やりたいことを考えれば、むしろSVGを使う方がずっと簡単ではないかと気がついた。

しかしそこで気になったのは、まずSVGツリーでタッチイベントを取得できるのかという問題だ。SVG DOMがHTML DOMとどこまで実装を共有しているかは分からないし、SVG DOMは少なくとも標準仕様としてはtouch UIを前提としていないので、サポートされていない可能性だってある。というわけで、ひとつテストケースを作ってみた。ちなみにtouchイベントの使い方はここで簡単に説明されているが、document.addEventListener("touchstart") などを利用する。iPhoneでアクセスしてみたところ、タッチイベントはSVGツリー上でも無事取得できているようだ。

問題はここからだ。まず、上記テストケースにAndroidのエミュレータ上からアクセスしてみたが、そもそもSVGが表示されない。調べてみると、どうやらAndroid上のWebKitはSVGをサポートしていないようだ。Safari上のWebKitはcairoを使っているが、Androidではgoogleが開発したskiaが使用されている。おそらくその関係で、SVGのサポートまでは手が回っていないのだろう。そもそも、cairoベースのwebkitにおけるSVGの実装自体、昨年あたりにexperimentalとして追加されたもので、SVGのテストを含むACID3を100%通過したのも最近のことのはずだ。この件について見つけられた情報は、半年くらい前にまだちゃんとビルドできないと書かれたものだった。

追記: これは違いそうだ。webkitがcairoを使っているというのは、むしろ一部のプラットフォームやビルドの話のようだ。ソースを見ての判断ではないけど、おそらく基本的にはskiaなのだろう。androidに含まれていない理由は、ビルドできなかったという以上のことは分からない。

次に、タッチイベントが取得できたといっても、今回のプロジェクトで本当に使いたいのは、シングルタッチではなくマルチタッチだ。先に紹介したページでも説明されているけど、iPhoneではマルチタッチのイベントはgesturestartなど別のイベント種別で定義されていて、これらはAndroid上では実装されていない。そもそもtouchstartなどはWebKitのソースに含まれているが、gesturestartなどは含まれていない。マルチタッチのイベント定義については、WebKitはMozillaとも異なるし、おそらくAppleが特許権を行使したりなどしているせいで、混沌としている状態だろう。

ただ、最近になってAndroidではマルチタッチをサポートするようになり（そのためAppleが特許権侵害を主張したりなどして騒ぎになっている）、その関係でWebKitでもマルチタッチがサポートされるようになっている。はずだ。今日詳しい知人から聞いたところでは、APIのレベルでも追加されているはずではないかとのことだった。ただ、androidのソース上では、それに対応するイベントは定義されていないようなので、Googleのeclairの独自ビルドに限定されているのかもしれない。

そもそもマルチタッチのイベントは実機（しかもnexusOneなど2.1対応のもの）が無いと拾えないので、確認のしようもない。そろそろ観念して実機を入手した方が良いかもしれない。

まあ、数ヶ月待てば、この辺りはだいぶ状況が変わりそうな気もするので、基本的にこの方向性で進めてみても良いのかもしれない。

sf2xrniのコードがだいぶ進んで、sf2ファイルを解析している途中でエラー終了したりすることもなくなったので、今後はgithubリポジトリにして進めていくことにした。

とりあえず今日は多くの音色をxrniとしてインポートして聴いて喜ぶことができた。まだSplitMapすらまともに出力していないのだけど、音だけは聴くことが出来る。まだサンプリングによっては短すぎたりすることがあって、何かがおかしいのだけど、原因は分からない。この辺は引き続きデバッグしていこうと思っている。

それなりに安定化・実用化したら、Renoiseの公式フォーラムに投げ込めば、公式サイトでツールとして紹介されるようになるかもしれない。いま2.5が出たばかりなので、出来れば今週中くらいにカタをつけたいところだ。

今月はこのツールを書いたということで、anowave, jmdspに続いて、1月1本ペースのhackはまだ続けられていると言えそうだ。別にそんなに急がなくても良いのだけど。

先日はLemurもどきということでiPadでマルチタッチだけで操作できるコントロールのやつを思いついたわけだけど、アレではやはり三次元の操作感は得られない。それなら、立体的な操作感を全てとは言わないものの、タッチパネル上で何か実在する物体（ツマミとか）を載せたりして、物体の磁気や影の動きなどを磁気センサや光センサで捉えるだけで動作を入力として捉えて、コントロールの代わりにすることはできないかと思った。

そして、よく考えてみたら、それはタッチパネル上でやる必要は全然なくて、そもそも物理的な部品をARのマーカーのように認識できればいいのではないかと思った。今はHIROのマークを認識するのも大変かもしれないけど、画像認識の精度が上がってくれば、たとえばツマミのノッチがどこにあるかを認識して、その角度が変わったらカメラからの映像を通してコールバックイベントを送受信することができたりしないだろうか。そう考えると、今がんばって結線したり電気的特性をどうのこうのと考える作業が、いずれ過去のものとなっていくのではないかと思えてくるのだ（今のC言語の位置付けみたいなもんだ）。物理的に接続しなくても、ソフトウェア処理系がいったん実装されれば、カメラに座標を記憶させるだけで済むようになるのだから。

まあ、三次元映像と人間の動作だけでさまざまな仮想物体を制御できるようになる未来の方が近いのかもしれないけど。仮想的なデバイスを操作するVPL?ベースのプログラミング?が主な作業になるような気がしている。三次元CDを作るソフトでモデリングする作業はもはやプログラミングとは呼ばれていないだろうし、それくらいの位置付けになってもいい気はする。いや無理かな。

renoise 2.5がリリースされた。というわけで早速ダウンロードし、立ち上げて何か作ってみようかなと思ったものの、最初に浮かんできたフレーズの音色がsynth. hitで、presetでもdownloadableでも音色が見つけられず、やはりサウンドフォントを使えるようにしなければダメだという気になった。サウンドフォントを使うだけならVST経由でもいけるし、そもそもmidiチャネルを使えばいいのだけど、xrniとはいじり方が違うようなので、なるべくxrniにしたいと思っている。（この時点でもう最初に浮かんだ音は消え去った）

というわけで、1月にちらっと手を出してみたsf2xrniを進めようとしている。前回書いた通り、サウンドフォントはバンク音色のセットで、ひとつのバンクに相当するxrniとは構造が違う。まずsf2の構造から眺めなおして見た。

以下は半ば落書きのように分かったことをメモしているだけなので、整理されていないと思ってもらいたい。

sf2では、ひとつの音色はPresetという構造になり、フルキーボードに対応する。Presetには複数のPreset Zoneがあり、それぞれのPreset ZoneについてInstrument（楽器）が定義される。そのInstrumentには、サンプリングデータの定義と鍵盤のRangeが含まれている。鍵盤の範囲の他にも、音量やパンポットが、対象サンプリングデータの選択条件になっているようだ。

サンプリングデータは実際には別のバッファに16ビット符号ありのリトルエンディアンでまとめられていて、定義部分ではそのインデックスを指定しているだけだ。（そうでないとデータが読みにくいことだろう。）　サンプリングデータのループについても、仕様書の6.2で規定されている。ちなみにサンプリングデータがファイルに含まれないサウンドフォントというものもあって、それは物理的なROMを前提としている。

renoiseにはそこまで複雑な音色選択の条件は無い。SplitMapと呼ばれる鍵盤のインデックスと、外部音色ファイルを間接指定するSampleの定義しかない（SampleはSplitMapの数だけ定義するのだろう）。

87ページある仕様書を眺めて見たのだけど、今回はファイル構造を追いかけるのが目的になるので、重要なのはsection 7までで、naudioでenum型の値を見れば内容が何となく分かる以上セクション8はあまり関係が無く、演奏実装モデルやROM形式などを説明しているセクション9以降はほぼ無関係そうだ。section 5のINFO-list chunkもメタ情報が中心で、あまり重要な内容は無い。87ページが30ページまで減った。実質的にはhydra形式と呼ばれているsection 7の説明だけ読んでも、あとはnaudioの構造を見るだけでなんとかなりそうだ。

さて、実装はどうすべきか。今あるコードはsf2のSampleHeadersを中心に拾っているが、これは良くなさそうだ。Presetごとに音色xrniファイルを作る方向で実装した方が良いだろう（つまり1つのsf2から複数のxrniが作られることになる）。 サンプリングデータはファイルごとに分割するしかない。おそらくバンクをまたぐサンプリングデータの共有は（理論上はあり得るとしても）実際にはなされていないだろうから、これでリソース消費が増えるということは無いだろう。 Instrumentの定義ごとに、サンプリングを切り出して（これはSampleHeader情報を参照して行う必要がある）、Rangeに対応するかたちでSplitMapを定義する必要がある。音量やパン別に音色定義があるものは、xrniに無い以上あきらめるしかない。

とりあえず、このアプローチでそれなりに上手くいくのではないか。コードを書いてみることにしよう。

昨日ソースを眺め始めたandroid本体だけど、修正すべきコードはlibmediaではなくlibmediaplayerserviceの中ですぐに見つかって、パッチも作ることができた。ただ、困ったことに、ビルドしたandroidを実行できたことが一度もない。そして意外とこれがハマり道になった。というか、未だに解決していない。

まず、makeではどうやらランタイムしかビルドしてもらえないようだ。実機に転送するバイナリイメージを作成するにはそれで十分なのだが、エミュレータをビルドするには、make sdkを別途実行しなければならない。これに気づくまでしばらくかかった。

そしてsdkビルドでは、やはりjava 1.6がどうにも通らない。java 1.5にして、パスを調整して、ようやくmake sdkが最後まで通るようになった（と、こう書いた時点で、もしかして1.6でもPATHさえ設定すれば通ったんじゃないかという気にもなってきたが後の祭りだ）。

ここまでやってもsdkでビルドされるはずのファイルが足りないと言われるので（実際には別のディレクトリに出来上がっているのだけど）、たぶんどこかしら実行の仕方がよろしくないのだろうとは思っているのだが、web上にある情報も1.5や1.6など割と古いものばかりで、いまいち当てはまらないものが多い。もう少し調べないと分からないのだが、そこまでしてパッチを当てたいかというと微妙な内容ではある。

少し他にもやりたいことが出てきたので、頭を切り替えようかとも思っている。実のところ、google I/O 2008のプレゼンテーションのスライドを見て、全体像が何となく見えたので、気分的には「正体不明のandroidなるものへの苦手意識」のようなものはほとんどなくなって、他に行ってもいい気がしてきたのだ。嫌いではないのでまたいじるだろうけど、ハマるものでもないかな、みたいな感じだ。

週末に例のandroidのmidi playerをいじっていて、MediaPlayerはファイルの拡張子が大文字だとメディア種別を認識してくれないという問題に気づいたので（日本ではそれなりに知られている問題のようだ）、問題があるなら本体を修正するのが筋じゃないかと思って、androidのソースを引っ張ってきて見てみることにした。

androidのビルドはLinux or Macでしか行えず、しかもSnow Leopardは未対応だというので、Linuxでしか行えない。Linux環境でも、純正のビルドはSun Java 1.5を要求されたりして（gcjには対応していない）、なんだか面倒だ。試しにopenjdk 1.6しか入っていない環境でビルドしようとしたら、make時にチェックされてエラーになってしまった。

Java 1.6がダメな理由は、どうやらアノテーションの互換性に起因する問題のようなので、アノテーションの互換性って何のことだろうと思って調べてみたら、どうやらJava 1.5よりもJava 1.6の方がある程度柔軟に記述できるような感じだ。完全上位互換というわけではないので正しくはないのだろうが、ビルドはできるだろうということで、一部のmakeファイルをいじったら、ビルドできるようになった。まあ実際に動かしてみてダメだったら諦めてsun-java-jdk-1.5を入れるしかない。

androidのビルドにはwebkitなども含まれているので、それなりに時間がかかるし、先にflexやらgperfやらを入れておかないと、途中でかなしいことになる。ビルドを仕掛けて一晩放置するくらいが良いかもしれない。MediaPlayerのjavaソースをいじるだけなのだから、全体をビルドする必要は無かったのではないか...と思いながら待っていた（実際にはjavaソースだけではすまないのだけど）。

ビルドが完了すると、outディレクトリ以下にいろいろファイルが出来上がるようだが、今回はちゃんと出来ているかどうかにはあまり興味がない。修正しようと思っているMediaPlayerのソースを探すところからだ。しばらくソースツリーをいろいろ探した挙句、MediaPlayer.javaをぐぐればソースツリーの位置がわかるはずと気づいた...ソースはframeworks/base/media以下にあった。

java/android/media/MediaPlayer.javaのsetDataSource()を見てみると、そこには見慣れないnativeという修飾子がある。どうやらこれがJNIと呼ばれるもののようだ。JNIがどうなっているかは知らないが、同じmediaディレクトリ下にあるだろうとをつけたら、libmediaディレクトリにネイティブのC++ソースがあった。

該当するコードは、android_media_MediaPlayer.cpp 中の setDataSource(), getMediaPlayer() → IMediaPlayerService.cpp 中の　BpMediaPlayerService::create() → IMediaPlayer.cpp というところを探しているところで、まだどこを修正すれば良いかは分かっていない。実のところ、javaのソースをちらっと直せば足りるんだろう、くらいにしか思っていなかったので、C++のコードを眺めているのは想定外だ。ということはsdkでなくndkで使っても同じ問題にぶつかるのだろう...

ということで今回はここまで。

さて、3月になったので、具体的にLemurもどきを作ってみようかなという気になってきた。しかし相変わらずLemurの仕組みがどうなっているのかは、さっぱり分かっていない。というわけで、lemurのサイトに行って眺めてみた。

Lemurは、どうやらあの本体上でUIの編集作業を行うわけではなく、UI自体はJazzEditorと呼ばれるGUIデザイナを使って設計するようだ。そしてJazzEditorはフリーダウンロードになっている。さっそくダウンロードして動かしてみた。WYSIWYGスタイルのGUIデザイナになっていて、ポトペタで画面を作ることができる。youtubeで公開されている動画のような画面は、全部ここで設計して作られたものということになりそうだ。

部品の種類はそれほど多くない。約20種類のコンポーネントが用意されているのみだ。カスタムコンポーネントを作成するツールは見当たらなかった（動作環境がLemur本体ということを考えれば、それほど自由がないことも理解できよう）。

部品にはビヘイビアとプロパティを設定することができる。プロパティは大きさ等を規定し、ビヘイビアは出力とは無関係に、コントロール自身のアクションを規定するものとなりそうだ。プロパティにはアクションとして送信されるOSCまたはMIDIのパラメータを指定するような感じだ。

そしてGUIデータはjzmlというXML形式で保存する。このXMLの仕様は、古いものだが公開されている。また、OSCのメッセージ仕様も公開されているようだ。なかなかオープンにできている。

前回構想を書いたアプリケーションの作業は、大半がGUIの作成で終わることになるだろうと思っている。やるべきことは、それぞれのコントロールが、入力を受けて、OSCまたはMIDIでメッセージを送ることだけだ（要求があればPOXや最悪SOAPだって返せるだろう）。本体には何も記録されない（してもいいけど）。

そのGUIだが、何を使って作成するかは、一考に値する。iPadであればCoreGraphics、AndroidであればSurfaceViewを使うだろうし、System.DrawingのようなAPIがあれば、それを使っても良い。と、ここで思い至るのは、そもそもWeb UIとして作成してしまえば良いのではないか、ということだ。すなわちHTML Canvasである。そのうちWebGLも使用可能になるかもしれない。Web UIとブラウザ コントロール コンテナのinteropさえできれば、あとはバックグラウンドでOSCなどを処理するだけだ。幸いsafariでもfirefoxでもマルチタッチAPIは実現している。（まだ標準は無いと思うけど。）

これは、要するにコードの再利用性の問題だ。CoreGraphicsで書いたアプリケーションをAndroid環境で走らせることはできない。HTML Canvasとinterop部分さえあれば、あとはinteropの先だけ差し替えれば良いし、言語によっては差し替えなくてもどうにかなるかもしれない。iPad用にアプリケーションを独自に作成するコストは、もったいない気がしている。

今年・来年は、スマートフォン環境に特化した開発を余儀なくされていたアプリケーションの開発スタイルが、変わってくることになるんじゃないかという気がしている。