MIDIのコアエンジンは LongMessageとかMMC/MTC などのニッチ機能を除いてほぼプロトタイプが完成した。
宿敵なるは、VST のSDKだ。

MIDIフィルタ機能

本題に入る前に、まず現状について。
プロトタイピングの目標のひとつに、スクリプトエンジンの検証が項目としてあり、その実現性について少し。

スクリプトの使いどころとしては以下の3パターンを考えている。

1. シーケンサ自体のマクロ(一般的な操作の自動化などに使うもの)
2. フィルタ
3. シーケンスジェネレータ

今回検証した 3. について、以下に実際に動作する Squirrel スクリプトを掲載する。

c <- rand();

function callback(pos, range) 

{

  local length = 60;

  for(local a=pos;a<(pos+range);a++ )

  {

    if (a%length==0)

    {

      AddNote(a, c  %128, 64, length);

    }

  }

}

このスクリプトは、32分音符のノートを連続的に生成する。
midiom2 は以前とは異なり、バッファリング再生を基本としたエンジン設計となっているため、時間軸の未来方向へのデータ生成が可能となっている。
MIDIディレイのようなエフェクトを実現したければ、入力データを受け取るコールバック内で、未来のTick時刻に AddNote を行うだけでよい。
スクリプト内でいちいち入力データをディレイタイム分保持しておく必要がない。（まだ入力コールバックの機構は実装していないが）
CC の使われていないコントローラをVMの内部状態の遷移用のスイッチとして使うことも可能だろう。(アルペジエータのパターン切り替えとか)

MIDIフィルタの開発に仰々しいSDK引っ張ってきて開発するなんて手間とは以後おさらばできることになる。
ただひとつ心配があるとしたら処理速度だろうか。Core2DuoのCPUでは上記のスクリプトを100個くらい同時に動かしたところで1%未満のCPU使用率だったので、VM自体の動作は相当軽いものと期待できそうだ。

フィルタを簡単に作れることにどれだけニーズがあるのか知らないが、自分にとっては音楽の作り方のアプローチを変えるファクターだと思う。
プログラムやっている人に音楽やっている人はかなり多い気がするので自分だけではないと思っているが（僕のまわりだけ？）

完成のころには内部のインスタンスを直接触れるインターフェイスを提供して、便利なジェネレータAPIセットを実装して、複雑なフィルタを構築できるようになっている、はず。

VST host 開発

VSTの開発をする場合、まずSteinberg の開発者ページよりSDKをダウンロードして、サンプルを動かす。
minihost というサンプルプロジェクトがVST のホストアプリケーションのサンプルになっている。
素直なコードで好感を持てた。成功する規格というのはこういう部分が良くできていると思う。

別配布されている ASIO SDK もサンプルをビルド。
サイン波にアンプモジュレーションをかける生成関数を書いてバッファに渡してみるとちゃんと音が鳴る。
ASIOはVSTよりもかなり簡単。内部でスレッドを立てているらしく、コールバック内でアクティブでないバッファにデータを書き込むだけの単純な構成となっている。
DirectXAudioとはだいぶ毛色が異なっている。

ロードしたVSTEffect に ASIOのバッファサイズ分のデータを要求してリングバッファに書き戻してやると、音が鳴った。

難しい印象を持っていたが、特に信号処理の深い知識も必要とせず、肩透かしを食らった気分。

おそらく大変なのはこの先のSDKではサポートしてくれない部分だろう。

リアルタイムとバッファリング

midiom のエンジン部となる、EMIDI(エミディ)というライブラリを先行して開発している。
EMIDIはそれ自身でスレッドを生成し、MIDIシーケンスの再生のスケジューリングや、データの編集、モジュールの結線、ASIO/VSTのホスティング、物理デバイスのモジュール化、シリアライズ機構など、シーケンサに必要な GUI 以外のすべての機能を保有している。(することになる)

この手のシーケンサは時間軸の単位が何種類も共存することが混乱の元となる。
必要な時間表現を考えてみると、
MIDIはTickという拍子や拍などに依存した時間軸で表現し、Tickを制御するためにテンポという時間表現を用い、もちろんms単位の時間軸も必要であり、オーディオを扱いだすとサンプルというこれまた周波数によって可変の時間軸が入ってきて、さらにMTCでは SMPTEで時間をフレームで表現しなければならなくなり、そしてこれらすべてをCPUの周波数やOSのタスクスイッチに乗っかって扱わなければならない。
同期祭り。

これら時間にかかわるすべての処理はリアルタイムでなければならないのだが、もうひとつ即応性というものが要求される。
バッファリングは、ストリーム安定化の手段として用いられる。
「どうせ遅れがあるんなら一番遅いやつに合わせてみんなで手をつないでいこうぜ」
このことでリアルタイムな再生環境が作られるのだが、あくまでもこれは再生だけである。

録音をするときは、これらバッファリングされた(つまりは遅延して再生している)演奏にあわせて録音するわけで、快適な録音機能を実装するためには、バッファリング再生しつつ、入力されたデータは即座に処理しなければならない。MIDIのフィルタをひとつ考えても、バッファリング再生のために先読みしたデータにフィルタをかけることができる、かつ、入力されたデータは即座に処理しなければならない
ASIOのレイヤーでは必ず一定値の遅延があるため、VSTiを演奏する場合は低レイテンシーのオーディオデバイスが必要となる。
EMIDI側でこの遅延にあわせて補正をかけるかどうかは選択できるようにするのが良いと考えている。

EMIDIの再生エンジンの演奏で VSTi が ASIO経由で鳴った

スレッドが三つも回っているため、なかなか動いてくれなかったが。同期コードをはさみ何とか手元にあるいくつかのVSTiで演奏ができた。
再生した音楽データは、上記の squirrel スクリプト。
複数VSTiの起動も成功した。

VSTi / ASIO は面倒な実装がまだまだ残っていそうなのだが、とりあえずここでいったん終了。
なんかごちゃごちゃあるオペレーションとかは根気が必要そうだ。

VST SDK に付属ののサンプルは必要十分だけども、アプリケーションのレベルに持っていくにはやることが相当あるという結論。
低レイテンシのオーディオアプリとか仮想音源とかが使えるようになるという点に対しては十分価値があると思う。

次は入力部。

KAOSSILATOR や TENORI-ON などのデジタル技術による新世代の楽器が注目されている

複雑性と直感性を共存させたこれらの楽器は、デジタル楽器の楽しさを再認識させてくれるだろう。
世界中のほとんどデジタル楽器を制御できるMIDIは、こういった新しい楽器の中にも十数年間ほとんど形を変えず、いまだに動脈として機能している。
MIDIに関しては今も昔もなにも変わっていないが、コンセプトやアイデアが良いとこんな製品がでてくるものだと感動した。

そこで、最近こっそり開発を進めている midiom2について初露出したいとおもう。

midiom2 でやりたいこと

midiom の次バージョンの構想が固まりつつある。
そのコンセプト概要を以下書き連ねていこうと思う。

数値入力シーケンサであること

これはmidiomのコンセプトであり、意味するものはデータリストの編集のみで楽曲を構築するポテンシャルを持つことである。

プログラマブルシーケンサであること

midiom version1 では設計上の限界に直面したため、プログラマブルな側面は中途半端なものとなってしまった。
時系列のMIDIデータとC言語などのような手続き処理系の言語の多くの共通点から、データリスト上にロジックを閉じ込めることができるのではないかと考えたのが事の発端であったが、そもそもその前提が間違っていたように今となっては思う。
一番大きな間違いは、MIDIの時系列のデータの連続性と、手続き処理の連続性を混同していたことだ。
N88BASICの時代からDATA文があるように、データ構造とアルゴリズムは分離されるべきである（このあたりの解決策に関してはFlashの実装が参考になる）。データ中にロジックを記述するというのは、N88BASICのDATA文中にマシン語を記述するようなもので、書きやすいはずがない。しかも、midiomは単純な命令しか提供できなかったので、機能はあるが、利用価値がないという状態に陥ってしまった。
そこで、次世代のmidiomでは、データとロジックを完全に分離する。多くのアプリケーションがマクロ機能などでロジックを分離し、データに対してロジックを適用するというアプローチをとっているように、バーチャルマシンをシーケンサの要所に取り込む。
VMには、実行速度の面と組み込みの容易さから squirrel を候補としている。もちろんRubyなどの贅沢なスクリプトを組み込むポテンシャルも持ち合わせる。
（MMLに関してはこれ自体処理系ではなくてデータであるため、違うアプローチが必要であるため、採用するかどうかは未定である。）

モジュールの概念を取り入れること

モジュールとして振舞うオブジェクトは、データの入力と出力をサポートし、シーケンサ内でほかのモジュールと結合する。外部とのデータのやりとりはMIDIポートをモジュール化したオブジェクトを利用することとなる。適度に抽象化されたMIDIデータはシーケンサ内を縦横無尽に飛び回り、生成され、加工され、フィルタリングされポートに届けられる。このことによって、アルペジエータやスライサーなどといったMIDIエフェクトが実現可能となる。アルペジエータやスライサーの実体は、スクリプトの VM モジュール、つまり、スクリプトで記述されたフィルタプログラムである。

フレームの概念を取り入れること

フレームは DAW で実現されているようなトラック上に配置されるデータの塊である。
midiom version1 では、すべてのトラックは 0 Tick から開始するため、データのシフトをする場合、余分な余白データをデータの先頭に挟まなければならなかった。また、シーケンスは分離不可能であったため、データ途中のある区間のみをシフトしようとする場合の操作は煩雑であった。
フレームは、モジュールと同様に多様性を許容するので、トラックに配置できるフレームは何もMIDIシーケンスに限らない。この部分はmidiom2のキモとなる。このアイデアによって自動作曲なんかが簡単に行えるようになるかもしれない。

ループシーケンサであること

ACIDのようなデータ操作ができるようにすること
また、Kaossilatorのようなリアルタイムループレコーディングができるようにすること

VSTi への対応

まだ何も手をつけていないに等しいので、確定はできないが、VSTiをホスティングして動かすことは検証段階で確認済み。ただし、隙のない実装ができるかについては、コストとの相談となる。
VSTi対応がなくても、MIDI Yokeなどの内部結線で、フリーのホストアプリケーションと組み合わせてるだけでよいのだが、同じフレームワーク内で利用できることが、モチベーションに影響すると考えている。
スクラッチを起こすのに使用するアプリケーションはひとつで済ませたい。セーブデータもひとつでよいので簡単に復帰できるわけだし利便性は高い。

グラフィカルであること、美しいこと

数値入力シーケンサという意味では必要ではないが、ライブでDJが開いているPCの中で動いていても様になるレベルを目指す。見た目も、ライブでの実用性も。
GUIは思い付きではなくてデザイン作業からちゃんとやろうと思っている。

かっちょいいこと

かっちょよくないツールなんて使いたくない。
ただし、かっこよくなくてもいい。

高速であること

フルスクラッチで書き起こしているエンジン部は現段階で version1 の何百倍ものパフォーマンスを発揮している(当社比)。データがどれだけ大きくても(たとえば100万ステップのシーケンス)エンジンは耐えてくれる。あくまでもエンジンの話ではあるが。
スクリプトの実行環境を提供する上で重要なのは軽いことである。重いスクリプトを実行する場合、CPU資源をフィルタ処理に集中させることができる。
また再生時の遅延についても解決策を用意している。スクリプトの実行に1msのレイテンシが存在していても、データの生成速度がその処理速度を追いこさない限り、その環境でベストなタイミングで(といっても1msがMIDIの限界だが…)演奏をしてくれる。モジュールやスクリプトの遅延に引きずられることはない仕様となっている。

キー入力ですべての機能にアクセス可能

これも midiom のコンセプトである。
どこまで貫けるかは一考しなければならない。
ユーザーインターフェイスは確実に以前より複雑になるので、考えたら吐きそう。
GUIプログラミング(デザイン・設計以外の実装)はスポーツである。要求されるスキルは根性が主である。

使いやすいことというのは、楽器の形態、シーケンサの形態が多様であるゆえ、コンセプトにはしない。
提案型でいきたい。

とりあえず、骨はコレくらいだろうか。

これらのコンセプトに乗っかるアイデアは膨らんでいるが、またの機会に。

music key Cm(ハ短調)
のように、調を決めるデータを入力できるようになった。
今後の布石として。

*

アップデートはもうしばらく未定です。

●トラックビュー Alt+Enter でトラックプロパティの表示
●数値入力エディタ Ghost表示がoffの状態でコピーを行うと不正なデータがコピーされるバグの修正
●ヘルプ トピックの文字化けの修正(追加内容はありません、古い情報のままです：対応をしなければ)

数値入力エディタの致命的バグ（というかバグを出してしまった。。。）の修正が入っています。


バグのご報告ありがとうございました。

midiom version 1.32 release
●メタデータ入力(Ctrl+\)メタデータエディタ(TAB)SMFメタデータ読み込み、SMFメタデータ出力
●immediate loop 機能

●ステータスバーちらつき軽減
●デュアルコントロールレーン上でマウス位置の情報が正確にステータスバーに表示されていなかった
●コントロールレーン上でコンプレス操作がきかなかった
●コントロールレーン選択状態で X T C などのデータ編集ショートカットが機能していなかった
●数値エディタ上でのコピーの不具合修正
●グリッドエディタ W キーでレイヤー切り替えを行ったときに数値エディタが追従しなかった不具合の修正
●統合エディタのサイズ変更に関するバグの修正

*

※上書きインストールでキー定義情報がすでに保存されている場合、メタデータを入力するショートカットキーは設定されていない状態となります。設定->数値入力エディタのキーカスタマイズより、設定してください。

※immediate loop 機能は、トランスポートバーのループボタンを押すか、ループモード切替メニュー、キーショートカット（ctrl+l）で切り替えます。
非ループ->今までのループ->immediateループ->非ループ...
と3状態を切り替えることができます。

※メタデータをSMFに書き込み、読み込みする場合は、今までどおり、書き込み、読み込みを行うことで自動的に処理されます。

ちゃんとした機能追加するのに、
時間はかなり経ってしまいました。

申し訳ないです。

ちゃんとメインのツールとして利用していただいている方がいることはありがたいです。

数値入力万歳

*

修正予定リスト

- デュアルコントロールレーン上でマウス位置の情報が正確にステータスバーに表示されていなかった
- ステータスバーちらつき
- コントロールレーン上でコンプレス操作がきかなかった
- コントロールレーン選択状態で X T C などのデータ編集ショートカットが機能していなかった
- メタデータ入力(Shift+\)、メタデータエディタ(TAB)、SMFメタデータ読み込み、SMFメタデータ出力
- immediate loop 機能
- 数値エディタ上でのコピーの不具合修正
-グリッドエディタ W キーでレイヤー切り替えを行ったときに数値エディタが追従しなかった不具合の修正

-数値エディタ上ghost状態でコピーするとおかしなデータがコピーされるバグの修正
-メタデータへの対応
-immediate loop 機能
-> ループ時にループ開始点でのコントロールデータの初期化を行わないループモード
音色やコントロールデータは不正になる可能性があるが、ループ時につっかえるような間がなくなる
アイデア出しの時なんかに使えます

メタデータはとりあえず、サイズのバリデーションなどは行わずに手で入力する形になります

=(追記)======================
と思いつつ仕様書見てると、
メタデータの長さは可変長のデータだった。
ので、エディット時にはデータ部の長さは意識せずに編集できるようにエディタを作成する予定です。
=========================

今週末にでも。

バグフィックス & 開発環境移行版です。

*

- データ操作にまつわるバグが修正されています
再現性の低いバグによって落ちる症状が改善されています
- 今回のバージョンより、Visual Studio 2005 でのビルドを行っています

*

STLの操作の大間違いがあったことがVS2005 に移して判明。
C++の標準に関しては、いまだバージョンアップ毎に挙動が変更というか、コンパイラ開発側の認識が安定してきているというかんじなのでしょうか。

より厳しくなってエラーはいてくれることに関してはありがたいです。

酒がうまいことは何より。
料理がうまければそれ幸い。
知らない人との出会い
呑ミュニケーション。

*

新しい経験だった。

*

miidomをとりあえずここ何ヶ月かかけて
VisualStudio2005でビルドを試みていた。

strict なコンパイラの判断のおかげで排除できた不確実なバグが多数。

とりあえず、その段階のを公開します。

その後　メタイベント & 調性 を実装しようと思います。

また、呑みすぎた。

Lightweight MusicCreation

*

音楽を作る敷居はそれ相応のソフトウェアをそろえれば下がっている。ガレージバンドとかお手軽である。

だけど、出来合いの素材を組み合わせることで楽しいのは本当に初歩のうちであって、それ以上のことにチャレンジしようとすると何らかの敷居の高い作業が必要となる。

*

プログラムで言えば、数値入力がアセンブラだとしたら、ピアノロールによる打ち込みはC言語で、ループシーケンサなんかはLightweight といえる。

*

道具が簡単、必要なモジュールやデータが揃った常態で初めてLightweightとなるのであって、ツールが簡単というだけでは、それらの素材を自分で作らなければならないので、敷居が高いままである。

*

良いツールの条件は、簡単であり、かつ、再利用可能な素材が有志によって提供され続けることじゃないだろうか。

*

なんか、次のヒントが見えてきた気がする。

*

何故midiomで自動作曲ができなかったのか。
最初は許容できるシステムを提案するはずだったのだけど、今のシステムに組み込むのは容易ではない。

*

ここでプログラムとMIDIシーケンサが結びつく。
自動生成に必要なのはMIDIに特化したプログラムの実行環境であって、現状のmidiomにはそのスクリプトのエントリポイントを見つけるのが難しい。

*

重たいプログラムはこの類のソフトには絶対に許されないから、設計の段階で処理速度を意識した物となってしまうのだけど、そのせいでスケールしにくいプログラムとなってしまう恐れがある。

MIDIシーケンサ、数値入力という前提で作ると、それしかできないが、違った視点から──たとえば、ユーザー体験─などから考えれば、新しい発想が出てくる。

なんかアイデア生まれそう。