12/18の日曜日に、妻の主催する「子どもの音楽会」でKinectを使ったインタラクティブな音楽作品の発表を行いました。
手を叩くと音が鳴るように、空間に触れると音が鳴る、挙動が音になる。そういった、触覚ではなく、音によるフィードバックによる空間と身体のインタラクションだ。それは、空間を楽器にしてしまおうという試みでもある。
マルチタッチサーフェスを仮想的に空間に用意し、触れたり、かき回す（お風呂に腕を突っ込んだり、かき混ぜたりするイメージがわかりやすいかもしれない）ことにより音を奏でる機能を実装してみた。
今回、Kinectを使い、その上でアプリケーションを構築してみるという、わたしにとっては最初の挑戦であり、いくつか入力方法を用意してみて、試していく過程で、わかりやすさ、確実性という点から絞っていった。そこには、「子どもの音楽会」と冠されるように、メインの対象は子どもで、見ただけで、まねしてみただけで出来る事が必要という理由もあった。
前回までにClock(TempoClock)によってトリガーを発生させ、そのタイミングでコマンドをシンセサイザノードに送信することによって演奏を行うことが可能だと言うことを見てきた。
ただ、その操作はローレベル過ぎて、確かに可能なのだけど、毎回このような基礎の部分から行わないといけないとなると面倒だ。おそらく、プログラムをかける人なら必ずなんらかの手間の簡略化（クラス化なり）を行うだろう。そしてSuperColliderにもそういった上位のラッパークラスが用意されていて、演奏をさせたいのに、それまでのことに煩わせらるといったことがないようになっている。
今回見ていくのはPatternクラスだ。Patternクラスは豊富な派生クラスが存在していて、名前が示すとおりパターンとして登録しておけばそれを演奏してくれるというものだ。必ずしも最初に決められたものだけではなく、ジェネレーティブなものもある、そしてそれらを複雑に組み合わせることも出来る。
パターンクラスを使うと、例えばこんなコードで演奏をさせることが出来る。
Pbind(\degree, Pseq(#[0,1,2],2)).play
さて、これを見ていると、ふと疑問がわいてくる。魔法というものが存在しないように、前々回見たような処理を誰かが行ってくれているわけだ。それは誰がどのようにして行っているのだろうか。どうやってコマンドは手元からシンセサイザノードに届くのだろうか。
その点に注目してPatternクラスを見ていこう。
前回は実際にサウンドの生成を行っているサーバscsynthを離れて、クライアントであるsclang側でのシンセサイザコントロールのさわりの部分を見てみた。
SuperColliderにはClockというクラスがあり、その機能はトリガーをかけて欲しい時間を登録しておき、トリガーのタイミングで行いたい処理を実行すれば良いという仕組みになっていた。トリガーは一度かかると解除されるので、繰り返し行いたい場合は処理の終了時に再度トリガーを登録しておく必要がある。
そのClockクラスの主要な派生クラスの一つがTempoClockであり、名前の通りテンポによる時間管理を行うクラスになっている。主要というのは、このクラスにはdefaultというクラス変数があり、クラスがロードされたときに暗黙にそこにインスタンスが生成される。そして、いろんな演奏に関するクラスがClockに関するパラメータのデフォルト引数（引数が明示的に指定された無かった場合も）としてTempoClock.defaultを使用しているからだ。
TempoClockにはプロパティtempoがあるのだけど、ではこのtempoのパラメータの単位はなんだろうか。メトロノームと同じくBPMでいいのか、はたまた違うのか。初期的に設定されているテンポはどれぐらいの速さなのだろうか。
今回はTempoClockに注目してみようと思う。
前回までのところで、シンセサイザを作り(SynthDef、Synth)、そのラッパクラス(Synth)を使いクライアント(sclang)からサーバ(scsynth)を操作できるというところまでたどり着いた。
SynthDefのコンストラクタの２つめの引数ugenGraphFuncで渡される関数オブジェクトの引数が、すなわちそのシンセサイザのコントローラとなり、Synthクラスのsetメソッドを使って値をセットすることが出来る。
とりあえず演奏すべきシンセサイザを作るところまでは来たので、次はそれを演奏させたい。手動で値をセットするのも良いのだけど、ある程度は自動演奏させたい。
SuperColliderには演奏させるための仕組みが色々と用意されている。今回ピックアップしたのはRoutineクラスだ。流れ的には、必要なコントロールパラメータを設定し、必要なだけスリープする（次のタイミングを待つ）、その繰り返しが単純明快なので、サーバ側でのUGenの時のようにクライアント側のSuperCollider探求のとっかかりとして最適なのではないかと思ったのだ。
話の舞台はサーバからクライアントに移る。
前回、前々回でUGenという出口から始まり、ようやくクライアント側からサーバ側への橋がみつかった。いままでの道のりを図示すると左図のようになるだろうか。
今回見ていくのはもう一つの橋、Synthクラスだ。
前回はUGenを中心としてSuperColliderの世界への探求を試みてみた。今回はその上位構造となるSynthDefを見ていこうと思う。
SuperColliderはクライアントサーバ型アーキテクチャであることは既出のことなのだけど、SynthDef、そしてSynthがこの二つの間にかかった橋だと言えるだろう。UGenは確実に向こう側の世界だ。
お約束だけど、まだSuperColliderへの冒険の道半ばなので、間違っていることが含まれているかもしれないということは注記しておこうと思う。
１２音技法での対位法の扱いを調べている時にWikipediaに載っていた、
現在の代表的な自動作曲ソフトウェアとして、フランス国立音響音楽研究所IRCAMが開発したOpenMusicが挙げられる。このソフトウェアの説明書に付属するチュートリアルの初歩段階に、十二音技法の音列各種を自動生成する練習課題がある。
自動作曲 十二音技法(Wikipedia)
という記述になんとなく興味を引かれて、OpenMusic
というのがどういったものなのかを見てみようかという気になった。
OpenMusicはMaxやPdなどで有名なIRCAMのプロジェクトで、Max等とは違って、どちらかというとアルゴリズミックコンポジションの方にフォーカスしているようだ。いかにして波形を作るかというより、いかにして音符を作るか。そう言い換えることが出来るだろうか。
音列に対して逆行、反行、反逆行などはもちろん、時間的な変形を行うことが出来るのはもちろん、限定されたランダムネスのなかから音列を作ったり、音列の生成変形に関してその機能は網羅されている。らしい。
らしいというのは、わたし自身がまだ全然機能を試せていないため、何が出来るということを把握していないためだ。
OpenMusicのソースコードはLGPLで公開されているので、誰でも試すことが出来る。出来るのだけど、実はLISPで書かれているので簡単には動かなかった。色々試してみた結果、なんとか動くようになったので、手順を書き留めておこうと思う。
少々前よりSuperColliderをいじっている。SuperColliderというのは、あえて説明することもないぐらいの有名どころなのだけど、主に音楽・音響記述に長けたプログラミング言語環境だ。音響系といってもDSPなどのストリームプロセスを書くというよりは、むしろ、ノードの接続を記述してシンセサイザーをつくり、それをコントロールするロジックを記述して動かすというのがコアな部分のようだ（もちろんそれ以外が出来ないというわけではない）。
Maxなどともコンセプトでは似ているところもあるのだけど、決定的に違うのはそれがビジュアルプログラムではなくテキストコーディングで行うものという点ではないかと思う。
わたしがSuperColliderに興味を持ったそもそものきっかけは、SC140というTwitterに書けるだけの分量でSuperColliderで音楽を作ろうという試みがあるということを知ったときだった。そのミニマムな魅力にくらくらっときて自分でもやってみたいと思ったのだった。
SuperColliderは少々取っつきにくいところがあるのだけど、コミュニティのパワーが補って余る。わたしもとても助けられている。特に、@umbrellaprocess氏(on twitter)にはわたしの初歩の初歩な質問にもきちんとレスポンスをいただき、大変感謝している。
SuperColliderのTutorialは、公式のIntroductory Tutorialがよくまとまっていると思う。今見返してみると、よく読めばちゃんと書いてあるということも多い・・・。
わたしはSuperColliderを学ぶ上でまずターゲットに決めたのはUGenというクラスだった。その部分がSuperColliderでシンセサイザ（音響処理も含む）を扱うクラスの基底クラスだったというのがその理由だった。
今回、とりあえず今までに分かったことをまとめてみた。しかし、まだSuperColliderへの冒険の道半ばなので、間違っていることが含まれているかもしれないということは注記しておこうと思う。
またしても、五線紙の話題だ。
持ち運びするポケットノートとしてはMoleskineが大きさ的にも丈夫さ的にも良い感じと思っている。丈夫といっても、あまり開いたり閉じたりを繰り返しすぎると背表紙が割れてくるのだけど。Moleskineは五線紙のバージョンも出していて、前にも書いたと思うのだけど、9x14センチのノートだと縦ではなく、横で五線紙だったら完璧だったのにと、そこだけが残念だった。Moleskineではそういう横タイプのものも出ているので、なおさらだ。
Moleskineにはポケットサイズだけではなく、ラージサイズという一回り大きいものも用意されてるのだけど、横罫と方眼と無地しか無かったのだった。ラージサイズで五線が出ればかなり良いんじゃないかと思ってたのだけど、無いものは仕方がない。
ずっとそう思ってたのだけど、今でも日本のサイトではそうなってるのだけど、実は去年の年末に本国イタリアではラージサイズの五線が出ていたのだ。たまたま、お膝元ではもっと種類多いんじゃないかと思って覗いてみたらどんぴしゃだったのだ。
さて、あると分かったのは良いのだけど、どこで手に入れようかということなのだけど、Amazonで"Moleskine"で検索しても出てこなかった。Googleで検索したとき、最初に出てきたのはジュンク堂だったのだけど、洋書扱いでちょっと値段が高かった。どうしようかなと思ってしばし放置して、そういえばと思ってAmazonで"Music Notebook - Large"と、ずばり検索してみたら、あれ？あるじゃない。Amazonはなんかそういうの多い気がする。ちなみにやっぱりMoleskineでは出てこないのだった。
Amazonは洋書扱いでも値引きがあるので早速注文してみた。
さて、手元に届いてみての印象はというと、まずびっくりしたのは両面ではなかったということ。たしかにノートのアイコンでは片一方にしか五線書いてなかったので、その通りなんだけど。開いて右側が五線になっていてその裏は白紙になっている。
次にびっくりしたのは段数が奇数だったこと。11段でした。今までに奇数段数の五線紙は無かった気がするんだけど。
これぐらいの大きさなら縦型でも五線の横幅はそうそう狭いという感じはしない。丈夫そうなのもMoleskineのウリなんだけど、良い感じ。値段はちょっと高いかなと思わなくはないが、五線紙はどれもそんなには安くないので、まあこんなものかもという感じでしょうか。
ともあれ、五線紙の選択肢が増えたのは嬉しい。
この週末に簡単なPianoアプリをiPhone用に作っていた。売り出すためというのではなく、最近移動が多く移動に時間を多く費やしている妻のニーズに応えようと思ったのだ。
もちろん、多くの有料・フリーを問わずそういったアプリがすでに数多くAppStoreに登録されているのは知っていたのだが、作ってみたくなったというのと、一度作って仕組みを持っておくと他の遊びにも使えそうという思惑もあった。
さて、わざわざ作るのだから、たとえば全部の鍵盤の音を減衰しきるまで録音しておいて、スイッチでそれを再生するだけというのは、確かにゴールには近道かもしれないけども、面白くない。やはり、Wave Tableを扱うオシレータをもったシンセサイザ、つまり簡単なサンプラーぐらいにはしたい。
iPhoneで音を扱うためのAPIは大きく分けてOpenALかAudio Unitになる。他にも簡単に扱えるようなものもあるのだけど、今回はローレベルで扱いたかったので除外した。
OpenALは以前テストしてみたことがあったのだけど、今ひとつiPhone上ではよくなかった。バッファアンダフローが頻繁に発生した。Call stackみてもAudio Unitにラッパーをしているみたいだし、オーバーヘッドを考えたらAudio Unitを扱うのが良さそうと言うところまでは分かっていたのだけど、iPhoneでAudio Unitっていうのも負荷的な問題は大丈夫なのかなといった疑問も少しあったのだ。
結論から言ってしまうと、Audio Unitの部分は意外とすんなりといってしまった。Undocumentedな部分で？？？となることが少なくなかったが、書かないといけないコードは拍子抜けするぐらいシンプルだった。AUGraphを作ってその中にアウトプットを追加し、ミキサーを追加し、ルーティングしてやるだけ。
もっとも、Appleのドキュメントでの手順ではどこからとも無くアウトプットがやってきていたので、アウトプットはデフォルトで何かしらあるのかと思ったら無いというような、少々はまった箇所はいくつかあったけれども。音を出すソフトのデバッグは音が出るまでが大変だ。
OpenALのテストの時の印象からするとAudio Unitはずいぶんと良い。５音ポリ（iPhoneのマルチタッチは最大５ポイントなのだ）ぐらいだとアンダーフローは発生していない。そのかわりUI側のタスクが若干引っ張られてるような感じを受けることがあるけど、音途切れが発生するよりは良い。
出力までの経路が完成したなら、あとはオシレータだ。当初は軽さだけを追求して、WaveTableからの読み出しもスキップのみしかさせていなかった。未だに乗除算は避けられるものなら避けたいと思ってしまう。浮動小数点も同様に。
オシレータだけだと寂しいので、ADSR付のエンベロープジェネレータも実装する。そもそもエンベロープジェネレータないとキーのオンオフどうするんだという話でもある。
すべてを実装して、試しに鳴らしてみる。なんだか、処理落ちもなく普通に音が出ている。もちろん、個々のオシレータなどは注意深く軽く実装したのだけど、所詮まだＣレベル、実用にはまだまだ最適化が必要だと思ってただけに、またしても拍子抜け。
iPhoneのスピーカから出てくる音はおもちゃのキーボードのピアノの音みたいで、これはこれでかわいくて良いなと思ったのだけど、簡単なオーバーサンプリングをオシレータに追加してみると、やはり手を入れた分ぐらいは音がよくなる。それでもまだ処理落ちする気配がない。
こうなってくると欲が出始めて、つぎはローパスフィルタが欲しいとか思ってしまうのだった。
