小さくても安心

ASIOというオーディオインターフェイスのAPI規格は、レイテンシが少ないというメリットがあるため、音楽用のソフトや、オーディオカードは軒並み対応しています。
で、レイテンシが少ないのは明らかにメリットなので、多少扱いが面倒でもASIOは使ったほうがいいわけです。

で、僕のアプリもASIOに対応しました。ASIOは規格に曖昧な部分が多くて、色々とトラブルがあるらしいのですが、少なくとも自分のオーディオインターフェイスでは動きます。

で、これはとりあえず解決したとしましょう。

で、もっと本質的な問題として、レイテンシが小さいことが挙げられます。
そもそもの目的としていた性質が問題となるのです。
なぜ問題なのかというと、レイテンシが小さいということは、言い換えると時間的なバッファが少ない。
１０００サンプルに１回、重い重い処理をするというようなことをしていたとして、仮にバッファサイズが３００サンプルの場合、重い重い処理でも１０００サンプルに１回なら中和できるだろうという目論みは外れて、３００サンプルで中和しないと、そのバッファの処理で音切れが発生してしまうわけです。
なので、思い思い処理を大きな時間粒度でドカンとやるわけにはいかず、もっと細かいタイミングで、五月雨式に実行してやる必要があります。

で、メモリの消費量を増やして、ダブルバッファリングというのをやるのがベターかと思いました。
「聴かせない」メモリ上で、必要なデータが揃っている処理ブロックについては、五月雨式なタイミングで実行して、全てのデータが揃った時点で、「聴かせる」メモリと、「聴かせない」メモリへのポインタをスワップします。

そんな感じでConvolverの実装を作り変えて見たいと思います。

ありゃ。。

きづいたら１ヶ月近く更新してない。。
mixiで駄文ばかりかいているせいで、この有様だ。。

６末で前の現場をオサラバして、今は家でゴロゴロしつつ未踏の作業なんかもやっている。そんな感じだ。
ＡＳＩＯへの対応が一応終わって、今はプリセット機能のコーディング。
プリセットはＤＬＬにしてプラグインのように追加できるようにする。これも今週中にはできるだろう。
残るはプリセットそのものを充実させること
少し余裕も出てきそうな感じがするので、８月の最終発表にむけて曲らしきものも作ってみるつもりだ。

大変だアモーレ

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

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

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

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

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

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

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

初期化で思う

現在未踏で作成しているアプリは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++のポインタは人間にも最適化コンパイラにも優しくない前時代の産物といわれているようですがね、、、

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

函館へ、そして

行ってきました函館へ！

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

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

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

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

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

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

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

新機能だよ

特許も出したしちょっと自慢してみたいと思います。
基本的にはボコーダっていう機能を出発点にしているのですが、あえて回り道をして面白い音を作るみたいな感じですね。
ボコーダ（音楽用途のボコーダに限定しましょう）は、２つの入力ソースを持っていて片方のスペクトルアナライーザーの形を元に、もう１つの波形のグライコをリアルタイムでコントロールするみたいな機能です。
大昔からあるエフェクトで、実はそんなに負荷もないし、簡単に作れるのですが、
ちょっと、回り道して進化的計算法というのを使ってみました。
えーと、これ以上はばらしてしまうと面白くないので、6/3の発表をお楽しみにまっていてくださいな！

で、作ってみた音がこれ。。
あえてフィードバックをかけていますが、かけなくても別の質感のエフェクトとして機能します。

http://hanac200x.cocolog-nifty.com/ok13.mp3

デノーマル恐るべし

多分デノーマル値の問題で遅くなっているだろうなぁ～
と思っていたのですが、やはりそうでしたorz

ただ、デノーマルが発生しているだろうと思っていた箇所とは別の箇所で発生していたため、発見が遅れてしまった。
いままでせいせい５０個くらいの粒子しか動かせなかったところが１２０までＯＫになった

ふぅー、ようやく胸の使えがとれた気分だ＾▽＾

これだけの数ならば２手に分けて色々と試せるね。

一番の重しが取れたので、細々とした修正で、あと１０個くらいは増やしたいものだ

特許かきかき

いやぁ、日本語ってム図解しい。短いプログラムでも、それが何をやっているのかを詳細に書こうとすると、かえってソースコードよりも長くなります。
特許の場合は考えられうる設定なんかも事細かに書いて、類似特許の出現を抑えたりだとか。そういうことも考えなければならないので。。。

でもなんとか水曜日くらいにはできあがりそうかな？
はやく書き上げてソフトの開発にもどらなければ！！

デバックと再検討三昧

やっと序の口を突破か？

てゆーか、直したい本丸の部分ではなくて、その下請けルーチンの改修に手間取っていた。

すんごくたちの悪い問題。
sqrt()
って関数は平方根を求める関数なんだけど、
最適化ビルドの場合、引数にマイナスの値を指定すると、無限ループになっていた。
で、まさか個々が原因だとは思わなかったので、究明するために四苦八苦・・・・
しかも、本来はマイナスの値は出てこないはずのだけれど、計算精度の問題で、ごく稀にマイナスの値が発生すると、、、
ここも中々気づくのに時間がかかり申した。。。

ただ、運がよかったのは、改修によって発生した問題というのは分かっていたので、直したところを１つ１つコメントアウトしたり、はずしたりして、1個1個潰していった。
でも、まさかここが？ってとこだったので、気づくの遅れたよ。。。

さ、これからようやく、本来直したかったところの修正だ！

難航

今日は１７くらいまでＰＣの前にかじりついていて、気晴らしにアキバへ出かけた。
途中で雨がパラパラしてきて焦ったＹＯ．．
とくにアキバ的なものは買わなかった。
基本的にふらふらすることが目的だったので、
徒歩→三田線（西巣鴨→水道橋）→丸の内線（後楽園→御茶ノ水）→徒歩
とわけの分からんコースでアキバに移動。

うーん、ちょっと詰まってます。
当初考えていた枠組みは、あまり威力を発揮しなさそうなので、微妙な軌道修正がいるかも。
なので、今は検証と対策案を練っているところ。
必要な機能自体は出揃っているので、あとはその組み合わせ方を調整していくことになるとは思う。
うーん、やっぱゴールデンウィークはこいつ１つにかかりっきりになりそうやね。