先の記事を書きながら考えたことなんだけど、まずJamoma以外にも、UBC Toolboxとか、

v001とか、同じようなミドルウェアがいくつかあります。

私もIAMASのプロジェクトでDSPBoxってのをハードウェア込みで作ったりしました。

これらはそれぞれ目的が違うので、見かけや使い方が異なります。だけど、出発点となっているのは、毎回同じようなパッチを書くのは面倒なので、汎用的な処理を標準化してライブラリにしましょう、ということね。

例えば、オーディオ・ファイルを再生するのはsfplay~だけど、それ以外にもopenや1や0といったメッセージが必須だし、pause、resume、loopといったメッセージも欲しくなりそう。さらに、再生位置の取得や設定をするには、それなりに込み入った処理を書くことになる。こういったパッチを毎回（曲を書く度に）作るのは苦痛以外の何者でもないよね。

そこで、

• 頻繁に使う処理をモジュール化して、再利用できるようにする。
• GUIを付けて、直感的にマウスなどで操作できるようにする。
• 混乱しないように、複数のモジュールのデザインを統一する。
• 複数のモジュールを組み合わせられるよう、入出力の整合性を取る。

ってな作業をして、ミドルウェアが出来上がっていくことになります。

これで、めでたしめでたし、いろんな処理が簡単にできてウレシイ！ということになるのですが、実際にそれで満足できる範囲は限られています。ミドルウェアが規定した範囲ですね。例えば、

• モジュールのGUIを変更したい。
• モジュールに新しい機能を追加したい。
• 異なるミドルウェアのモジュールを組み合わせて使いたい。

といった欲求が起こった場合に、ミドルウェアの内部に立ち入って改造することになります。これは結構面倒だし、ミドルウェアの内部ってドロドロしている場合が多いから、第三者が容易に手を出せるものではないです。ちょっとイジったけで、全体がおかしくなってしまうかもです。

もちろん、このような事情はMaxも同じで、Maxが規定した範囲でしか処理を作れないのも事実です（同じ論法で、OSが、コンピュータが、CPUが….と素粒子レベルにまでイっちゃいます〜笑）。ただし、Maxはオブジェクトを極力シンプルにしているし、Maxの拡張方法も（ほぼ）きちんと規定しているので、混乱は少ないはずです。

つまり、ミドルウェアが簡易に高機能になればなるほど、ミドルウェアが規定する範囲が狭まり、拡張が難しいことになります。もちろん、万能のミドルウェアなんて有り得ないし、有り得ないからこそ、MaxやらC言語やらがあるわけです。ミドルウェアがアプリケーション化すると、Ableton Liveとかmotion diveとかになってしまい、それじゃ頭悪すぎなのでMaxを使ってるんだよね？　つまり、機能じゃなくって言語だったハズ、です。

もっとも、ここでの論考はミドルウェアを否定したいわけじゃなくって、ミドルウェアの限界を明らかにしつつ、それじゃどうしたらいいの？ってことを考えたいわけです。ミドルウェアが便利に使える範囲なら、どんどんミドルウェアを使えば良いと思いますね。…とタラタラ書いてたら長くなっちゃったので、この続きは、また後日。