COM, MFC, ATL ...

Window Media Player用のDSPプラグインをチョコチョコいじっています。なかなか先に進めずにいましたが、だいぶ分かってきました。
以前はCOMアーキテクチャのご利益がいまいち分からずにいましたが、IDLを使ってインターフェースを決め、一意のIDをつける利点がおぼろげながら分かってきました。DLLを作ったときに、自分が持つインターフェースのIDをシステムに登録しておくと、システムの別のところにあるプログラムがそのインターフェースを持つプラグインを探す役に立ちます。インターフェースがタグの役割を果たすわけです。こうして集められたプラグインDLLはすべて同じインターフェースを持つサーバーであり、クライアントであるプログラムは好きなプラグインを実体化して利用することができます。
WMPDSPプラグインはIMediaObjectインターフェースを持つ、DirectX Media Object(DMO)です。このインターフェースはWMPとは独立して規定されており、MSDNの資料を調べることで動作を知ることができました。
DMOは、リアルタイム性の無いMS Windows上でリアルタイム処理をするため、以下のような性質を持っています。

  • 入力バッファの長さは、メソッドが呼ばれるたびに変わる
  • 出力バッファの長さも、メソッドが呼ばれるたびに変わる
  • 入力バッファのすべてのデータを一気に処理することが薦められるが、必ずしもしなくてもいい
  • 出力バッファをすべて埋め尽くすことが薦められるが、必ずしもしなくてもいい

こういった要求を満たすために、プラグインは相当面倒なバッファ管理を強いられます。また、入出力フォーマットのネゴシエーションやフラッシュ、不連続処理などもあります。
曲がりなりにも信号処理関連の仕事はしていましたので、これらは原理さえ分かればクリアするのは単なる作業でした。が、頭を抱えているのはユーザーインターフェースです。Google頼りで調査を薦めていましたが、一向に理解が進みません。今日になってようやくEdit Controlとの値のやり取りができるようになりました。しかし、Sliderを使うべくMFCのマニュアル通りにしてもコンパイルできません。なぜだろうと頭をひねること一時間。
MFCではなくATLが使われていたのでした。MFCもATLも知らないよ。

/* -----codeの行番号----- */