portmidi-sharpのサンプルとして、WCF経由でportmidiを叩くものを追加してみた。本当はRESTful APIを使いたいのだけど、まだしばらく不安定になりそうなのと、Silverlight環境で使えないということがあるので、今回はまだBasicHttpBindingだ。
サーバ,
クライアント
これが実におそろしいもので、mono環境ではまだきちんと動作しない可能性が高い。mono on Windowsのコンソール上では、一応.NETクライアント/サーバとmonoクライアント/サーバの任意の組み合わせで実行できるはずだけど、同じものをMac環境にもっていくとなぜか途中で止まったりする。たぶんネットワークまわりの実装が異なるためだろう。非同期メッセージングはそもそも最初からきちんと動作しないので、この辺も解決していく必要がある。
で、何がおそろしいかというと、今回の実装はMIDIメッセージをそのまま送信する仕様になっているので、無駄に演奏のハードルが高いのである（WCFのdogfoodingのためにあえてそうしている）。MIDIプレイヤで送られるMIDIメッセージの数量はとてつもなく多いし、処理速度もかなり要求される、という点だ。monoのWCFのコードは全くと言っていいほど最適化されていないので、これから最適化していく必要があるだろう。まあ、こんなにヘビーな使い方は想定していないのだけど。ただ、.NET環境ではそれなりに再生できているので、多少なりとも張り合えるところまではもっていきたい。
実用上は、SMFの生データと演奏制御命令（play/stop/pause)を送受信すれば全て解決だ。これはmldsp上で実際に必要になる（実装する）予定なので、それは別のものと考える。
さて、このweb playerの目的はSMFを演奏することではない（それはそれであるけど）。自宅で接続するのが面倒くさいYAMAHAのラック音源を別のネットワークマシンに接続して、そのマシンでserviceを起動しておいて、ローカルのclientがそれを叩く、ということを主な用途として想定している。
もちろん、serviceはローカルマシン上で動作させておいて、mldspのようなsilverlightアプリから演奏命令を送信するということもできる。これはFlashでgainerをコントロールするgspと同じやり方だ。
ただ、mldspに関しては、ただでさえCLRのHttpWebRequestを経由するWCFで重いところを、ブラウザへのXPCOM呼び出し経由でHttpWebRequestを介して通信するのが現実的であるとは考えにくい。やはりSMFと制御命令を送受信するのが現実的だ。そもそも本当に利用したくなったらWCFなんて使わない。
今この方法で設計しようと思っているのがMIDI音色エディタ（のようなもの）だ。MIDI制御命令を全てこのWebプレイヤ経由で処理するようにすれば、ブラウザのみで利用できるようにすることもできる。GUI部分に何を使って設計するのが一番良いか、いろいろ考えたのだけど、とりあえずmoonlightを使ったやり方はアリだと思っている。コレとは別に、OpenTKを使う方法も検討している。ただ、テキスト入力をどうするか別途検討する必要もありそうだ（WinFormsを使えば実現できるが、iPhoneなどでは使えなくなる）。
