マルチアウトのVSTi

画面のようにまともに動くようになった。
描画周りは最適化の余地がだいぶ残っている。

異種ピン間のコピー

MONO->STEREO
STEREO->MONO
のような異種の信号のコピー処理の枠組みを作成。
今後、Pan の演算処理をここで行う。
当面は実装しても -3db 固定で。

アイコン/デザイン調整

アイコンとかデザインとかゆっくり考え中。
ちょっとだけ見た目が変わった。
プラグインリストはアイコンを見ただけで、VSTi なのか VSTEffect なのか区別つくようにした。

本が来た　コンピュータ音楽

す、すばらしすぎる。
なんでもっと早く買ってなかったんだと後悔。

(14:30)

デシベル計算

デシベル計算をまじめにやってボリュームメータが動くように。
フェーダーマウスでつまんで動くように。

(8:44)

フェーダー

使いやすいフェーダーって微妙にクセをつける必要があるのだということがわかった。
うまいパラメータをあわせることでCubaseっぽい感じにした。

(10:57)

amazonコネェ

もう少ししたら出かけなきゃいけないんだけど
本が届かない。

インサートエフェクトセクションのエディタ開くボタンが機能するようになった。

(12:50)

モックレイアウト

ようやっと、レイアウトのモックアップ作成。パーツ切り取ったり座標数えたり、内部用 GUI ウィンドウシステムの描画部分作ったりで、時間かかった。

ごちゃごちゃしているけど、信号の流れがわかりやすいような感じにした。ちょーかわいい。

プリフェーダー・ポストフェーダーのインサートは自由に位置を変更できるようになったら便利だとおもったので、モジュールシステムらしく、このGUIの枠組みの中でできるだけ自由な結線の変更に対応しようと思う。

(4:06 昼夜逆転)

アニメーション

ステレオメータが出力に連動して動くようになった。
ボリュームフェーダも動かすことはできるけど、ボリューム、ゲインの実装にまだ手をつけていないのでまだ連動せず。

(10:15)

ゲインコントロールロジック実装/マルチアウト

ロジックは入ったが、マウスイベントを抽象化していないので、まだつまみをマウスで動かすことはできない。
複数の出力を持つVSTiの場合チャネルUIが複数表示されるようになった。
パンどうしようかな。
サラウンドはかなり手間がかかるため、とりあえず最初はステレオのみで公開までこじつけたいな。

(12:18)

コンピュータ音楽—歴史・テクノロジー・アート

勢いあまって、昔から欲しかったけど(高くて)手を出せなかった本ポチった。
明日届く。
この辺の分野でバイブルといわれる本。大学いるときに図書館で良く読んだ記憶があるけど、やっと活かせそうな気がする。

MIDIバイブルといい、音楽関係の技術書はバイブルが多いな。

(12:28)

タブインターフェイス

VSTi につきタブをひとつ展開するようになった。
左のツリービューから VSTi をクライアント領域にドラッグすることで、新規タブとともにVSTi がロードされる。

花粉

今日は外に出てないのにくしゃみがやばい。
来週病院行って薬もらってこよう。

(22:45)

ポートの選択

画面は、MIDI入力ポートを選択しているところ。
VSTi のスタック部のUIはまだかなりいい加減だけど、動作的には安定してきた。

左のプラグインリストから、ドラッグアンドドロップでプラグインを読み込むことができるようになっている。

昼寝

迂闊にも昼間寝てしまった。
疲れたまってるのか、休日の気の緩みか。

動作的にはとりあえず使うことはできる感じになってきた。
アルファ版に向けて最低動作のための作業順序を調整していこうと思う。

まだ先は長い！
(3:21)

設計思想

内部的にはフルモジュールシステムとして組みあがっているのだけども、モジュールシステムって結線とか面倒だしどうしてもエンジニア寄りで使いにくい部分もあるので、UIはスタック式を選択。

ハードシンセのように使うために、MIDI入力ポートとチャネルの選択が画面遷移なしでできること。簡潔なUI。

VSTプラグインの一覧性が良いこと。

立ち上がりが軽いこと。
これを実現するために、プラグインのデータベースを初回起動時に作成する。(もちろんリビルドも可能に) Waves の起動は異様に重たくて、Cubaseとかでも、起動に最低１〜２分はかかるという重たさなので(なんかCPUディテクションして最適化されたコードを動的に展開している気がする)初回にデータベース化して、次回起動時は一瞬で起動するように。
っていうか、あんな値段しておいてこの起動時の配慮の無さはないわ。
シーケンサ、オートメーションという重たい要素が無いので、動作も最小負荷となる。

シーゲート

不具合を公式に認めたとかニュースがあったが、うちのHDDがビンゴ。
ファームのアップデートめんどうだなぁ。

(3:40)

チャネルデザインプリプロ

今週は連休。
アイデアとコンセプト出し。
モダンでカラフルを目指す。

4時間くらいやってこれ。
デザインは頭なやませるひとつ。
グラフィカルのものって、後戻りはコスト高くなるので、ある程度完成系を考えながら進めないといけない。プログラム側からの制御も考えつつなので。

(14:45)

ドラクエ延期

延期先が、僕の誕生日なので許す！

(21:10)

設定ダイアログの作成

設定ダイアログを作る。

HTML ダイアログ(CDHtmlDialog)

前から気になってはいたけど、使ったことがなかった MFC の HTMLダイアログ。
使ってみるとこれがまた便利。
UIのレイアウトは結構頭を悩ませる要因だが、HTMLでかけると width=100% とかできるので、レイアウトの負荷が軽減される。
また、使い慣れたHTMLエディタを使ってデザインすることができるので、アプリケーションの不毛な割りに生産性の低いダイアログボックスのUIレイアウトを、無縁のデザイナさんとかでも行うことができそう。

もちろん javascript もフルで動くので、HTMLのレイヤでデータを構築するアプリケーションを構築して、アプリケーション側からは、生成された適当な DIVのテキストをパースしてウマウマなんてことも可能だ。 この発想だと、ダイアログUIの分業がかなりきれいに行えることになる。

あらかじめ最小の入出力を決めておいて、DreamWeaver なり、ExpressionWebなりで動的なWEBページを自由に作ることができるのだから。

C++からのDOM操作は、まあアレなんだけど、それでも innerHTMLとかでゴリゴリ書き換えるという発想は今までのC++の流儀ではなかったなあと感心した。　いまさらだが。。。

(13:05)

休日

インサートエフェクト

チャンネルモデルを追加して
Instrument -> Channel -> InsertEffect x8 -> Output
のような結線でエフェクトのチェインを組めるようになった。
VST2.4 は 32bit浮動処理ができるのだけど、プラグイン側で対応しているものはほとんどないという。
midiomHostでは、内部の信号演算は全て32bit浮動少数で行うので、音が混ざったときの音質は良くなるはず。

動的なレイテンシの変更

動的なレイテンシ変更に対応。
リセット処理も、危険がいっぱい。
音楽ソフトって、通信プログラミングと変わらない難しさがある。
ただし、FireFace800でしか確認できないので、ASIOドライバのクセによっては、正しくレイテンシの変更に追従できないかも。
そのうち、ASIO4ALLで試してみる。

ASIO出力マッピング

(18:00)
ASIO出力が複数ある場合のマッピングを記述。
サウンドデバイスの抽象化。ASIO以外当面対応する気はないのだけど。
チャンネルにインサートエフェクト積んで、MIDIキーボードで軽々演奏できるようになって、いよいよ楽しくなってきた。
初期設定用UI作成をちょっとずつ進める。テストが楽になるので。

依存を切る方向でリファクタリングしていけばしていくほど、リファクタリングがすんなり運ぶ。今日は結構進んだ。

オーディオに手を出してしまうと、最小なんてものはどこ吹く風。

フェーダー、ミキサー、インサートエフェクト、パンコントロール(サラウンド)、書き出し、レイテンシ補正、プリフェーダ、センドエフェクト。これだけは最低でも搭載しないと使いやすいとはいえない。

VST2.4じゃ、floatとdoubleが混在してて、バッファの処理も書き分けが必要。

「使いやすい」の部分には初心者でも最初から遊べるという方向付けが良いんじゃないのかと思う。

鍵盤でシンセが会話
こういう系統の面白いシンセをバンドルできればいいなーと思って、同僚にVST SDKを布教しつつ信号処理系の知識を深めていこうとおもう。

今日思いついたこととしては、インサートエフェクトで、MONO->Stereo 見たいな接続でも、うまく処理できるような仕組みにしようと思った。また、サラウンドにも対応しようと思っているので、いよいよサラウンド再生環境がほしくなってきた。 X-Yパンでモノトラックをぐりぐり動かしてみたい。

midiomHost

midiom2 への最初の布石として、
midiomHost というASIO+VSTホストアプリケーションなぞ作っている。

VSTiのホスティング用ソフトという位置づけで、あまっているPCをハードシンセにしてしまいましょうというコンセプト。
最小構成で、使い勝手のよいホストアプリケーション。

少しずつ開発を続けてきてようやっと、midi 周りのモジュール化が完了した感じで、今現在はオーディオの実装を仕様満たすまで突っ走る感じ。画像は、VS2008のリボンなんかが使えるテンプレートアプリケーションにエンジンを積んでテストプログラムを作っているところ。VS2008超すごい。

Waves, AutoTune,UAD, NIのVSTi など、手元の有名どころのVSTは全て起動できる状態になったので、プラグインのローダー部分は信頼できる品質になったとおもう。Waves は立ち上がるまでが Fuckin 大変だった。

今は、オーディオ信号のスケジューリングと結線処理をゆっくり書いている。
現状で、マルチコア、マルチスレッド対応、VST2.4対応、MIDI入出力といった基本エンジンが完成に近づいている。
なんていうか、時間がかかる。

スレッディング前提なので、石橋をたたいて渡る状態。
GUIとCUIのテストプログラムを何か書き換えるたびに走らせて、エンジンの動作を確認。

ここを抜けてしまえば、開発速度は急加速していくと思うんだけど、焦らず続けている感じです。

え？ 何か新しいところ？
うーん。
画面を見てもらうとわかるように、カレンダーがついていて超便──

midiomHost は特に新しいことしようとは考えていません。
特に、こういう規格ものは、忠実にしないと死ぬ目にあうので、その先はmidiom2 で考えています。


Cubase5 申し込まないとなぁ、、、

二徹明けの清々しい休日、久しぶりにプログラムを再開。

VST Host

VSTi のロードと再生までは６月くらいに作ったものをリファクタリング。
ちまちまテストコードの上でライブラリを走らせながら、依存をきれいに切って、midiとVST&ASIOのオブジェクトモデルを整理した。
内部同期の処理がかなり洗練された。


オーディオ部のインサートエフェクトなども実際必須だろうということで、VSTi以外のエフェクト系プラグインを読み込む。ホスト側から見れば、VSTiもVSTEffectも実体は同じもので、MIDIイベントを受け付けるか否かの違いくらいしかないのですんなり行くかとおもいきや。
WavesのShellプラグインで読み込み失敗。
Wavesのプラグインは、単一のDLLで複数のプラグインを格納している形式であるため、(wavesの以外見たことないが)普通にロードするだけではだめみたい。

SDKに実装方法が書いてあったので、そのとおりにやってみるか。


インサートエフェクトを数段かませて、マスターにエフェクトかけられれば、midiomの仕様としてはOKと思う。CubaseなどのDAWとの連携がややこしいことになりそうなのが困りどころ。

ここにきて、Rewireという選択肢が出てくるのだが、
だれか、Rewireに詳しい人いないかなぁ。
正直使ったことないので仕様すらよくわかっていないし、SDKの取得方法がわからんかった。
組み込みも自由な感じなのでぜひSDKを見てみたいのだが。

テストコード

テストコード維持していかないと後半かなりキツくなりそう。
テストコードをメンテナンスする必要性について考察。

- 開発の終盤ではコンパイルに数十分かかったりするので、低いレイヤーでバグが出た場合に、修正→確認のイテレーションが馬鹿にならなくなる。やる気なくなる。
これを回避するために、最小のテストコードで問題を再現させることができるように、テストコードが動き続ける状態にしておくべき。
テストコードもメンテナンスしていかないと、気づいたらその場しのぎの実装によって、動かなくなっていて、テストコード作成時の仕様と噛み合なくなってメンテナンス不可能になったりする。
テストファーストにしておけば、要求がはっきりするので、仕様書書くつもりで取り組むと良い結果につながる。後で過去の忘却したコード読むときの助けになるし。

ASIOとの同期

BufferSize = 64 Samples
ともなると、バッファの書き出しに許される時間は 44100Hz で 1.45 (ms) しかない。

ずっと 1024 samples のような大きなバッファ状態のASIOでコーディングしていたため、このシビアさに気づかなかった。

Sleep(1)

Effectの処理をスレッド化して昨今のCPU事情に合わせようとしたのだが、処理待ちのために

While(Done())

{

  Sleep(1);

}

見たいなことをしてしまうと、
処理が戻ってくるまでに数ミリ秒要することがほとんどで、ASIOの低レイテンシー処理に追いつくことができない。
そこで、ワーカースレッドをスレッドプール化し、イベントで処理の完了を待つという実装に切り替えた。
（VSTEffectの処理にOpenMPのparaｌｌel記法を使ってみたのだが、ブロック単位のマルチスレッド化では、スレッド生成のコストが思いのほか高く、低レイテンシーでは処理が追いつかず。）

タスクマネージャで確認すると、適度に処理が分散されている。
実行コストが低いスレッドプールは強力だ。

マルチスレッド対応の際のDLLの扱い

これまた詰まった部分。
VSTプラグインの実体はDLLであるため、同じプラグインを二重化しても、プロセス内に実体はひとつだけしかマッピングされない。
そのため、プラグインごとに同時実行されないように注意しなければすぐにアクセス違反で落ちる。

VSTSDKでマルチスレッド保護をしてくれれば良いと思うのだが。
そもそもDLL内でグローバル変数を使用していなければこの問題は起こらないはずなので、完全に実装依存。

結局、マッピングされたメモリごとにデータを保護することに。
同じプラグインを複数立ち上げてもマルチコアの恩恵は得られないことになる。
Cubaseとかでもきっとそうだろう。

VST3 SDK では改善されているのだろうか。(今回は2.4SDK)


スレッドとの戦いがしばらく続きそう。