夢のFM音源

さて、ついに筆者が作りたいFM音源の話をする時が来た。前回の記事で私はこう述べた。

ある括りを外すことによって、FM音源はそのポテンシャルを真に発揮しつつ、かつてないほどのユーザビリティを獲得できるのだ。

それが何なのか、身もふたもなく説明してしまおう。オペレータの個数だ。最初から6である必要はないし、より増えてもいいはずだ。

つまり、オペレータが2つあるとき（初期化時はFM音源としての最低限の機能として、キャリア―モジュレータのペアとする）は低CPU消費の代償としてシンプルなサウンドとなる。ユーザがオペレータを足すことで音色は賑やかなものとなっていく。ただしCPUの負荷はどんどん増えていく。

ただ、なんでもできるとシンセを作るデベロッパーも音色を作るユーザーもプログラミングが追い付かなくなる。そこで「一つのオペレータは、キャリアか他のオペレータの1つのモジュレータにしかなれない」という制約を付ける。つまり出力を1つに絞る。ただし、一つのオペレータは複数のモジュレータを持つことができる。これにより、モジュレータ共有の問題は発生しなくなる。仮にモジュレータ共有のサウンドが欲しいと思ったときはモジュレータの設定をコピーしてそれぞれキャリアにあてがえばいい。完全に同じとは言えないが、より自由かつ問題点の無い音作りが可能になる。

この条件下では、FM音源の1キャリアは木が生えたような形になる。1キャリアとモジュレータの集合を「ツリー」と呼ぶことにする。音色はツリーごとにセーブできるし、もちろん全体をセーブすることも可能だ（その場合は「フォレスト」と呼ぶことにしよう）。フォレスト内にはツリープリセットをCPUが許す限りロードすることが可能だ（フォレストをフォレストにロードしてしまうと一瞬でCPUが干上がるのでやめる）。そこでこの（空想上の）システムの名前を「Baobab」としよう。アフリカの幹の太いバオバブの樹だ。

オペレータをドラッグすることで、その上に生えているモジュレータの幹も一緒に移動する。キャリアをモジュレータにすることも造作も無い。リファクタリングが簡単にできるようになる。このときオペレータは今までになかったモジュラー性を獲得する。

フィードバックは自分および、自分の上にあるモジュレータにかけるものとする。キャリア間の移動などで関係性が壊れる場合はフィードバックを除去する。

…どうだろうか。今までのFM音源になかった発想だが、直感的で分かりやすいと思う。そしてソフトウェアならではの運用法だ。こんなシンセを作りたいという熱意は伝わっただろうか。以前述べたとおり、これは誰かにアイディアを盗んでもらいたい。しかし、自分の設計したシンセを世に送り出すという野望は捨てきれない。うずうずして仕方無い。