MIDIライブラリについては、とりあえずMIDIプレイヤーを作るための下地部分としては概ね書き終えたので、次はUIについて書くことにする。
MoonlightでMLDSPを作成し始めた当時、MLDSPはそもそも完成したMIDIプレイヤーとして作成する意図は無かった(!)。もともとは同時期に作っていたprocessing (proce55ing) の.NET版実装のグラフィックス描画スクリプトのサンプルとして作成していたものだった。実際に作り上げられたアプリケーションも、同processingエンジンに依存していた部分があって、必ずしも（いや、全くもって）Silverlightらしいアプリケーション設計にはなっていなかった（もっとも、GUIアプリケーション フレームワークがこのMIDIプレイヤーに適合する部分は多くない）。当時はSilverlight 2.0の時代で、WriteableBitmapも存在しなかったため、全てのオブジェクトはSystem.Windows.Shapesのクラスなどを使用していた(!)ため、大変重いものだった。
今回、改めてXMDSPとしてデスクトップ版を実装するにあたっては、特にC#/.NETに限定しなくても良いと考えた（ただしC#の既存ライブラリを使い回したかったので、C#で無理そうな場合のみ他をあたるつもりだった）。ほしいのは基本的な2Dグラフィックス描画の能力で、OpenGL/OpenTKのようなナマの3Dは（よく分からないので）避けたかった。そしてクロスプラットフォーム（実際にはLinux/WindowsあとついでにMac）で動くことを要件とした。さらに開発環境がLinuxにも対応していることが必要だった。Unityは無償版があるものの開発環境がLinuxデスクトップで動作しないのでNG、Cocos2D/XNAやMonoGameもMonoDevelopテンプレートがLinux上で（おそらく）意図通りに動作しなかったのでNG…と、かなり厳しい線引きになった。
以上を通過したものとして、Agg#は割と好印象だったのだけど、基盤がどうしてもWindows.Formsになってしまうのと、ファイルダイアログすら独自に実装させられているのを見て、これは厳しい選択であるように思われた（実際にはWindows.Formsに載っているのだから、Windows.Formsのダイアログを使えば機能するのだけど、それが良いかどうかは疑問だ）。Gtk#のgdk/cairoも選択肢として考え出したところで、Xwtが使えるのではないかと考えた。Gtk#はAPIがあまりC#erには直感的ではないので（gtk#はプラットフォームネイティブのAPIだし基本的に自動生成する以上は仕方がない）、Xwtで実現可能ならXwtにする、というのは合理的な判断だったと思う。
Xwtについて、少し書いておくと、これは各プラットフォームにおける、ネイティブのUIフレームワークを直接使用する、最大公約数アプローチのクロスプラットフォームGUIフレームワークだ。WxWidgetなどが設計思想としては近いだろうか。WindowsならWPF、OSXならMonoMac、LinuxならGtk#を使用している。基本的には、ウィジェットのAPIを共通化しているが、グラフィックスまわりも共通のAPIが利用できる（これは多少ネイティブから離れたAPI構成になってはいると思うが、使いやすくはある）。Gtk#ではCairoをグラフィックスのContextとして使用している。
Xwtのコードに含まれているサンプルで、Xwt.DrawingというAPIで、2Dグラフィックスの基本機能があることは確認できたので（筆者はLinux上のGtkで確認した）、まずはキーオン・キーオフを表示する16段キーボードから実装することにした。それぞれのチャネルについて、キーボードに対応するCanvasを作成して、OnDraw()というメソッドの中で、渡されたグラフィックスのContextオブジェクト（XwtのGtk実装）に定義されたSetColor()やらLineTo()やらStroke()やらといったメソッドを呼び出して2Dグラフィックスを描画するだけだ。
さて、実際にそのやり方でキーボードを描画して動かしてみたものの、非常に重くて実用に耐えなかった。この続きは明日。