大分予想通りに

ただいまドライバプログラムを書いて、動作検証を行っている。
大分予想通りに動くようになってきた。
あとはテル民と結合して、遊びながら（笑）結合テスト

ようやく面白くなってきたかな。がむばるべし！

トリガー検出

トリガー検出。
つまりあれです。
UIのスレッドと信号処理のスレッドが動いていて、ＵＩのスレッドでマウスをクリックなんかした時に、「押したよ～～」と伝えるフラグですね。
あれを実装しました。（あいかわらずいまだにテストしてませんが、）

で、これだけのためにシグナルなりミューテックスを使って、スレッドを止めてしまうのもなんとも忍び難いわけで、そういうのを使わずになんとかならないかな～と思って書いてみました。
実はダメなのかもしれないけど、、、
^=　　（XORで代入）がアトミックな操作であれば大丈夫なんだけどね。。

そーっとそーと

STLのlistを使ってクラスのポインタを格納しているんだけど、これをソートしたいと思いました。
しかし、クラスそのものではなくてポインタなので、どうやってソートするんだろうと、しばし悩んだ。。。
そして、listに登録しておきたいクラスのポインタを、メンバに持つクラスを書いてやって、そいつの"<"演算子をオーバーロードしてやればよかったことに気づく・・

こんな感じだね
class i_have_foo {
   foo* p_foo;
   bool operator < ( const i_have_foo& l, const i_have_foo& rh) {
      return l.p_foo->id < r.p_foo->id;
   }
}
こんな感じのクラスを定義しておけばよいはず
試してみるか

プチ悩みどころ

UIの操作情報を信号処理に流すときなんだけど、
たとえばマウスのON／OFFなんかをそのまま変数に入れて信号処理のループで参照したりすると、ま、トランジェントなわけですから、ブチっていうパルス状のスペクトラムとなってしまうわけです。
なので、基本的には、UIから流れ込む情報は、ローパスフィルタをかけるのが定説なわけです。
そのローパスフィルタのフィルタ係数によって操作した時の音の質感って微妙に変化するわけ。
なので、これを計算オブジェクトの属性（その他の値の範囲とかいろいろな情報とセットになってます）として持つのか、システム全体のプロパティとして持つのか、ちょっと悩みどころ。
前者は、同じパラメータ共有になってしまう。後者は計算量がほんの少しだけ増える。

うーん、ま後者で、問題ないのかな～

abstract particle synthesisか・・

curtis roadsの”microsound”を買ってみた。

僕が今未踏ソフトで開発しているアプリは、granular synthesisに分類されるものだ。
で、この方式について一冊の本でまとまった知識を仕入れたことがなかったなぁ、と思った矢先、たまたまサンレコでRoadsさんがgranularの本を出していることを知ったので、早速アマゾンで注文してみたわけです。

で、４章の粒子合成色々ってところを読んでみたけど、やはり自分が考えているものに近いというか、かなりかぶりそうな予感のものが挙げられていた。
なかでも”abstract particle synthesis”ちゅーのは、今作ろうとしているアプリのアイデアに一番近いというか、かぶっている（汗）

Sturmは物理法則に従って動く粒子のモデルを実装した。粒子がその環境下において相互作用を及ぼしあえば、それらはずっと進化し続けるようなユニークな解を作り出す。

理論上はどのような信号でも固有の初期状態と時変のポテンシャルを有するユニークな粒子の集合によって代表できる。

Sturmは細粒音（訳者注：ブツブツな音）はその内部にサウンドサンプルが並べられた箱の中の粒子の運動によってモデル化できると仮定した。

と、、、他にもメタリックボールっていうのもあって、これも僕がやろうとしていることとかぶるなぁ～と、わっはっは

うーん、単純にピンポンゲームだけじゃなくて、もっと色々とゲームのアルゴリズムを借用していかないと、差別化は難しいかも。。。ゲーセンでも言って勉強してくるか(笑）

あといくつ初期化すれば？

初期化すべきパラメータがたんとあります。
今のプログラムの枠組みは、API経由で構造化した計算オブジェクトから、コンパイルにも似た処理を経て信号処理用のデータ構造へ変換するという処理をやってます。
なので、その変換過程というか、信号処理用のデータ構造の初期化関数は大変面倒なことに。。
ちなみにコンストラクタは使わないです。最大で３つの関数で初期化します。
要するに入出力用のデータ構造が計算オブジェクトの外側にあるわけで、そいつをNEWする順番のからみとかあって、１ステップじゃ都合が悪いと、こういうわけです。（ま、無理栗１つの関数でできなくもないでしょうが、かえって書きづらいでしょうし、、）

で、初期化すべき変数はたんとあります。
いったいあと幾つ初期化すればよいのでしょう。。
A４の紙にペラッっとまとめて今は、その半分以上は行っているはずですが、、、
それとて、あくまで初期化が複雑な複合的なデータ構造をもつ構造体のうちの１つにすぎません。
ま、今、対象としているのは一番複雑なものではあるのですが、、、似たようなものがもう１つあるし、、これとは違うパターンのもあったりと、、、ま、これを終らせても初期化処理全体の実装ボリュームからするとまだまだ３０％程度といったところでしょうか。。

データも色々なところに持っている。共通バッファみたいなものとか、各構造体が見ているものとか、、、
本当は間接参照をもっと減らしたいのですが、動的にメモリを確保している以上は自ずと限界がありますよね。。。

あとは１サンプル毎に実行する処理も、あればもっと疎らなタイミングで実行する処理もあると、、で、それぞれが入力バッファをフェッチする（値を取得した後にポインタをインクリメントする）わけですが、当然疎らなやつは、いつもフェッチしてくれるわけではないので、、その辺も考えてデータを用意してやらにゃならんし。。

いったいこれを正月中に終らせようとしていたのは誰か？！
そんなやつがいたら絞殺してやりますよ！

大型正月連休終盤

mixiばかりにかいていてもあれなので、こちらにも転記と追記を、、

ようやく一区切りついた感じ
一番簡単な計算オブジェクトではあるけど、、ＡＰＩ呼び出しから諸々変換して、信号処理エンジン用のデータ構造へ変換する部分のコーディングが終った。

あとは、階層化されている計算オブジェクトの変換フローを書いて、
次に信号処理エンジンそのものを書いて（ま、これはシンプルなループ処理だけどね、、）、
で、ＤＬＬとしてコンパイルして（今でもコンパイル自体は構文チェック用にやってますが、、）
ドライバ書いて簡単なデバッグをやって。

で、「テル民」と結合する。

本当はここまでを月曜日までにやりたかったけど、、、、
まーー無理なので（笑）
２／２にデモできるといいなぁ。。

頭の中では、今取り組んでいるモデルを使った色々なアイデアがある。
早くそれらを実際に動かしてみたい！
ファイトだファイアwithファイア！

あ、ちがった

そういう問題じゃなかった。
実行状態にあたる情報は、できればスタック領域に持っておきたい。
その方が、キャッシュが有効に働く可能性が高いしね。
それとは対称的にデータ領域（グローバル変数）やヒープ領域（Ｎｅｗしたやつら）に実行状態をおいておくと何となく遅そうだ。

しかし、実行状態に該当するデータをスタックに保持しようとすると、１つの関数の中で、初期化と信号処理の両方をやんないといけない。
信号処理のループでは、オーディオＩＯや、あるいはディスクＩＯのスレッドと同期したり市内といけないわけだ。
これを１つの関数でやるにはなんとなく無理がありそう。
関数分けたほうが良い気がする。
でも、ヒープとかデータ領域は遅そうと。。。。

どうしたものか、それが問題だ

どっちが速いのだろうか

あるデータ構造に高速にアクセスしたいという希望があったとしましょう。
データ構造であるわけですから、それは基本的には構造体となります。構造体と鳴らなかったとしても、何らかのデータ構造の組み合わせをどっかに管理しておく必要があります。
で、そのあるデータ構造にアクセスする関数をDoＩｔ()としましょう。

グローバルスコープに、
Hoge hoge[100];
Hoga hoga[20];
Hogi  hogi[40];

見たいに入れ物を作ってしまって。
ＤｏＩｔ（）{
    hoge[xx] = ほにゃらら;
    hoga[yy] = ほにょほほ;
　　hogi[zz] = うひょ;
}

ってやるのが速いのか。。

struct ALL {
   Hoge hoge[100];
   Hoga hoga[20];
   Hogi  hogi[40];
};

って定義しておいて、
同じくグローバルで、
ＡＬＬ  all;
ってやる。

で、
ＤｏＩｔ（）{
    all.hoge[xx] = ほにゃらら;
    all.hoga[yy] = ほにょほほ;
　　all.hogi[zz] = うひょ;
}
とやる。

どっちもどっちなんかなぁ・・