個人的に気になっているのは、今 otoco でやろうとしている、楽譜情報と演奏情報 (シーケンス情報) を融合するデータ表現に関する研究が、MML なりそれ以外なりのアプローチで行われているのか、ということです。別に、既に行われているなら otoco を作るのはやめようとかそういう話ではないのですが、先行研究があれば参考にはさせて頂きたいな、とは思うわけです。

今のところそれらしい研究成果はまだ見つけられていないのですが、music macro language で検索してみたところ、面白いものを見つけました。かなり画期的な概念に基づく MML、その名も「PMML」です。

何より面白いのがスレッドという概念です。音楽においては、通常「パート」と表現される概念ですが、PMML では並列される演奏は並列される処理として表現するわけです。

例えば「名前付きスレッド」はまさにパートを表現するもので、スレッド名を定義し、そのスレッド名ごとに処理ならぬ演奏内容を分けて記述します。以下のように:

// ちなみに曲は、昔おいらが作った "Happy Mouse" でやんす
defthread(melody, string, bass)

melody {
    o=5 s frfa^crar b-rargrfr ercrdrer frar i. f s r   // フラットって "-" でいいのかしら?
}
string {
    o=4 h a b- q ^cb- h a
}
bass {
    o=3 q ff b-b- ^cc ff
}

そして名前をつけずに単にブレース { ～ } で括るとそれは無名スレッドになるのですが、無名スレッドはスコープとして利用できます。例えば上記の例で、メロディーパートは最後の音だけちょっと長い音を使っていますが、そのために音符の長さ指定が行ったり来たりしてますよね。

    // i. で付点 8分音符に変更、そして最後の休符は sで 16分音符に戻している
    o=5 s frfa^crar b-rargrfr ercrdrer frar i. f s r

ここの部分で無名スレッドによるスコープを用いると、以下のように書けるわけです。

    // 最後の音だけを付点 8分音符にする
    o=5 s frfa^crar b-rargrfr ercrdrer frar { i. f } r

スコープは、和音を表現するブラケット [ ～ ] の中で用いると、長い音と短い動く音が混じった和音を表現することも可能です。

// 動物の謝肉祭より「像」の最後の部分
defthread(tuba, p_right, p_left)

tuba {
    o=3 s { i _b- } d-rd-r { i d- } e-d-cd- cr_a-_b-cd e-fga-b-^c
    { q ^d i ^e- q _b- i c } fefrb-r e-r { q r }
}

p_right {
    o=4 s { i _b- } d-rd-r { i [ gb-^e- ] } [ b-^e-^g ] r [ b-^e-^g ] r
    [ a-^e-^a- ] r { i rr q. r }
    o=5 i r { q [ _b- { i fe- } { i a-g } ] } r [ dfa-^d ] [ e-g^e- ]
    s [ a-^c^a- ][ g^c^g ][ a-^c^a- ] r [ dfa-^d ] r [ e-g^e- ] r i rr
}

p_left {
    o=3 s { o=2 i [ _b-b- ] } [ _d-d- ] r [ _d-d- ] r { i [ gb-^e- ] } [ b-^e-g ] r [ b-^e-g ] r
    [ a-^e- ] r { i rr q. r }
    o=4 i r { q [ _b- { i fe- } { i a-g } ] } r [ dfa- ] [ e-g ]
    s [ _a-ca- ][ _gcg ][ _a-ca- ] r o=3 [ _b-b- ] r [ _e-e- ] r i rr
}

ちなみに otoco ではどう書くのかって? それは、あの、今後の宿題とさせてください (^_^;A 。

他にも、スプライン曲線的なコントロール値の変化を実現するコマンドがあったり、C言語ライクな演算子が使えたり、マクロの引数として渡す値の配列を定義できたりと、非常にプログラマブルな仕様になっています。

こういう仕様の MML はおいらもある程度は夢想したりもしたのですが、ただプログラマーにとって理想的な言語世界というのが、果たして一般的な DTM ユーザーにとっても理想的なものとなりうるのか、という点において足踏みせざるを得ません。「可読性」という言葉一つをとっても、プログラマーにとってのそれ (処理内容の理解) と、DTM ユーザーにとってのそれ (楽譜としての理解) とでは、全く意味合いが違ってくる可能性があるからです。

ただ、音楽制作に対する新たなアプローチを提供するアイデアとしては、非常に興味深いものがありますし、機能の一つ一つは非常に参考になるものがあります。いくつかのアイデアは otoco においても拝借させて頂くことがあるかも知れません。

しかし 1997年時点でこんなものが存在していたとは…。