大変だアモーレ

たかがリサンプリングと鷹を括っていたけど、
やっぱなかなかのズ脳労働だわ。
今作っているアプリは、信号処理オブジェクトのブロックをいっぱい繋げていく、いわばＭａｘ／ＭＳＰ系の画面無しバージョン（プログラミングインターフェイスのみ）となっています。
で、リサンプリングなわけですから、その信号処理オブジェクトのあるグループのサンプリング周波数が変わるわけですよ。

いっぱい繋げられた信号処理オブジェクトのブロック群は、信号処理用の仮想機械といえますから、ＣＰＵに例えてみるのが良いでしょう。

要するにクロック周波数がいつでも自由に、そして非常に滑らかに変更できるコアと、クロック周波数が一定のコア、それとこれら２つのコアの通信路をソフト的にエミュるような感じでしょうか。

もちろん一般的なＣＰＵと比べて随分シンプルな装置ではあるわけですが、でもやんなきゃならないのは、そういうことなのです。

で、実際の処理の部分は書けたし、データ構造を準備するところも半分書いた。

しかし、残りの半分は、それらを足し合わせたくらいに７面倒くさいのです。

仮想機械用のデータ構造をコンパイルする部分（オブジェクトコンポジション以降なので、意味解析→コード生成だけですが）。これが面倒なのだ。
基本的にはコンパイル用関数を再起呼び出しするつもりだけど、、、
しばらくぶりにメンテナンスするから忘れているというのもあるな

初期化で思う

現在未踏で作成しているアプリはC++でコーディングしている。
CやC++といったメモリ直にアクセスするタイプの言語だと、初期化の際にもメモリレイアウトが意識できてしまうので、意識してしまう。
例えば、３種類のバッファbuf_a,  buf_b,  buf_cがあったとして、それぞれの要素数をSIZE_A、SIZE_B、SIZE_Cとしておこう。
で、メモリアクセスの局所性を考えてこんな初期化をついついやってしまう。

buf_a = new float[SIZE_A + SIZE_B + SIZE_C];
buf_b = &buf_a[SIZE_A];
buf_c = &buf_b[SIZE_B];

要するに１回のnew (システムに対してメモリの確保を依頼する命令）で、複数のバッファの領域を一緒に確保しておいて、それぞれのポインタのアドレスには対応する領域の先頭アドレスを代入するという感じ。

これって確かにメモリアクセスの局所化という点では一理あるかも知れないけど、最適化コンパイラにとっては、かえって足かせになったりするかも？？と思う。
ま、この例だけでなくて、CやC++のポインタは人間にも最適化コンパイラにも優しくない前時代の産物といわれているようですがね、、、

でも、なんとなく上記のような書き方をしてしまうなりよ

函館へ、そして

行ってきました函館へ！

函館名物の魚介類もタンと食べました！

いった理由は、未踏ソフトの中間発表です。
他の未踏採択者の方々の発表を聞いたり、自分が発表したり、発表の後に飲んだり食べたり、写真を撮ったり。しゃべったりしました。

いや、皆々様さすがに作業が進んでいて、まさに脂が乗っている。そんな感じでした。
ガリガリ書いた感じがする人とか、色々な方向転換があった人とか、色々と。
やはり編集ツール系を作っている人は進捗具合がわかりやすかったですね。
「あ、機能が増えてる～」とか思えました。

で、肝心の僕ですが、４月５月あたりに設計＆製造しておりました、進化的計算法を使ったボコーダの解説をしました。発表する内容はこれがメインだったので、ちょっとアルゴリズムにまで踏み込んで発表しました。
ま、実際のところメインルーチンは５００行足らずだし、準備用のコードやクラスのヘッダを併せても１０００行そこそこのコードだったわけですが、試行錯誤もろもろがあって、２ヶ月という時間を要したわけですが、
実装量の話はさておいて、色々と面倒なことをやっていることについて紹介しました。

しかし、出てくる音にピンと来る人は少なかったきも。。。
ちょっと恐れてはいたのですが、
難しそうなことだけやって肝心の音がつまらない、、、
ということになっていたのかも、、、、

なので最終発表会のときにはもう少しわかりやすいというか、ピンとくる音を出力したいと思います。
ぶっちゃけ２台のコンピュータを使って。伴奏に合わせて僕が演奏する。
そんなパフォーマンスをやってみようと思います。

そして、アプリももう少しだけビジュアル面でのテコ入れをしたいかなぁーと