#一部の方からtumblr経由で内容の不足が指摘されたので、加筆しておく。

Max/MSPは音楽や音響処理に対して最適化されたマルチメディアプログラミング言語である。

コンピュータ音楽やエレクトロ、ノイズなどの先鋭的な音楽の制作や、メディアアート作品の制作などで頻繁に使用されている。

精度保証は無いものの、音楽で利用されるサンプリングレート以下(例えば96kHz程度)であれば、デジタル信号処理的なことをお手軽に実現することにも利用できるので、いろいろと重宝する。

ところが、科学っぽい計測に使用する際に、処理の経過時間を計測する際に、安定して動作をしないという問題があった。

安定して動作をしない原因は、マルチコアCPUとwindowsのtimer関数の問題に近いことのようで、cpuタイマーがどのCPUを見にいっているのかを固定できないということと、信号処理のためのバッファとかクロックとかさまざまな要素が絡みあっているようだ。

そこで、上記のような実装をして解決をすることにした。

ところが、リアルタイム計測に利用しようと思うと、問題が生ずる。

コンピュータによるリアルタイム計測では、通常タイムスタンプ、もしくは、それに代る何かが必要となる。いずれにせよ、時間に関する目盛りが必要となる。一般的なC言語等でのプログラムの場合、専用のAD変換インタフェースボードを使用する場合には、ボード上のカウンタを、カウンタが無い場合にはCPUtimeを検出する、windowsやOpenGLなどに限定されるがパフォーマンスカウンタを利用する、などの方法がある。なお、CPUtimeについては、マルチコア化によって、保証性が下っていることがすでに指摘されている。

Max/MSPにおいても、CPUtimeを利用する方法がある。しかし、この方法は、マルチコア化の影響を受けている可能性があり、少なくとも、僕のテストでは、安定してはいなかった。そこで別の方法を利用する必要がある。

もともと、Max/MSPがMIDIデータ等の情報の時間密度が低いデータをストリーム処理することに特化したMaxのレイヤ(時間精度1msec)と、オーディオデータのサンプリングレートでストリームを処理するMSPのレイヤ(時間精度1sample)の2つの間での通信のタイミングがバッファの書き込みのタイミングなど様々な要素により、一意には定まっていないという問題がある。(なおMaxレイヤからMSPレイヤへのトリガについては、比較的時間遅れが少ないことが経験的に判っている。)

このようなことから、実装では、どちらかのレイヤの中でカウンタを動作させることが、重要な制約要件となる。

どちらのレイヤで実装するかは、求めている時間の精密さによって決定すれば良いだろう。

僕の場合は、sample rateでの時間分解能が必要となったことからMSPでの実装を行なった。

具体的には、サンプリングレートで動作する整数で数え上げを行う関数を実装している。

現状、高負荷な状態でも安定して1sample精度のカウンターは動作している。

ソースはそのうち公開するが、[0, 96000, 1000] -> [line~ ] とかすれば、1秒間正確に96kbpsでカウンターが動作するよ、とだけヒントを書いておく。(そんなに簡単な実装はしてないけど。)