2012年11月11日

Peter Deutsch さんあたりが,「MusicXML without "backup"」を re-define してくれないかなぁ.そしたら私は乗る.実装も手伝うし,日本語ドキュメンテーションも手伝うし,自分でも何か作ると思う.

Web拍手:


Peter Deutsch さんあたりが,「MusicXML without "backup"」を re-define してくれないかなぁ.
そしたら私は乗る.実装も手伝うし,日本語ドキュメンテーションも手伝うし,自分でも何か作ると思う.
別に「対抗馬」になる必要はなくて,「別の観点でのエンコーディング」として存在すればよく,「オリジナルの MusicXML」と「MusicXML without "backup"」との 双方向コンバータがあればいい.

「MusicXML without "backup"」でなく,「MusicXML for Performance Description」でもいいかも.
そしたら,必然的に backup がなくなる.
演奏情報は,時系列を逆行しようがない.
対抗馬にもならず,別の観点でのエンコーディングであることも明確.


Michael は,backup 要素の必要性をたびたび主張しているけれど,はっきりいって必須の情報ではない.
いろいろと情報を出してくるけれど,本音は,もう後戻りができないからでしょ,はっきりいって.
Michael 自身も,本当のところは,backup が必要ない,むしろじゃまだ,ということはわかっているはず.
MuseData の思想そのままに backup を採用してしまって,失敗したなぁと思っているはず.
(もしいまだにそう思っていないのだとしたら,救いようのない設計センスの悪さ.)

いまから後戻りするのはめんどくさいものなー,Dolet for Finale は作り直しになるだろうし,そもそも作り直せないでしょ,Finale のデータ構造からして.
MuseData(Finale のデータ構造)由来なのは,他者からしてみたら,はっきりいってどうでもいい.
一般的な音楽情報処理プログラマからしてみたら,MuseData のデータ構造は非常にセンス悪いわけです,楽譜情報データとしても,演奏情報データとしても.
MusicXML が「interchange format」を標榜しているのであれば,なおさら MuseDate の思想は捨てたほうがいい.

現状の MusicXML でなぜ backup なんていう時系列を逆行する情報が必要になってくるかというと,voice 要素が必須の要素になっていないから.
どうして voice 要素が必須の要素でないかというと,楽譜情報を MusicXML にエンコードするときに,それぞれの情報がどこに属する情報であるかという判断をしなくて済むようにしているから.
要は「曖昧である」という情報をエンコードしてあるわけです.
楽譜の記法上の曖昧性を残したまま記述できるところが,MusicXML の長所であり,短所でもある.

で,結局のところこの特徴は,複数のプログラムや研究プロジェクト間での「interchange format」としては長所になるところ場面がほとんどなく,短所であることのほうが圧倒的に多い.
短所どころか,"障壁" でさえある.
長所になる場面って,せいぜい,OMR(光学楽譜認識)結果を表現するときくらいじゃないかなぁ?
「どこに所属しているかわからないけれど,とにもかくにも抽出できたオブジェクト」を表現するときくらい.
そういう場面でも voice を必須にしてもいいと思う.それで backup がなくなるのだから,メリットのほうが大きい.

Finale で読み書きするときに問題にならない "だけ" の話であって,よそに出したり,よそからもらってくるときに,「これ,どーすんよの?」とあっという間に "障壁" になる.
もっというと,Finale 内でさえ問題になるときがあったよねぇ,自分で Export した MusicXML を自分で Import できなかったり同一結果にならなかったり.
Finale 内でさえ,backup が必須の場面というのはほとんどないわけだし,もう強情張るのはやめたほうがいいんじゃないかなぁ.

「backup は要らない(じゃま)」とか,「voice というのはなんなのか,主旨を明らかにしてくれ」という質問や苦情が何度も何度も Michael に寄せられる.
だって,メリットないんだもの.じゃまだし,わかりづらいし,めんどくさいだけで.
むしろ,プログラマにとってはデメリット多すぎ.


Michael も(MakeMusic も)殿様商売ができるほどには状況はよくないのだから,どこかで妥協しないとね.
Finale も,もうろくに売れてないでしょ?

ML でも,Michael のやり方は卑怯だと言われるようになったし.
強硬な態度をとっていてもいいことないんじゃないかなぁ.
少なくとも,自分の意にそぐわない提案や意見を,大した反証なく打ち切るのはナシだ.

デファクト・スタンダードなのではなくて,妥協してサブセットを使っているだけ.
「みんな問題なく使えている」のではなくて,「みんな我慢して使ってあげている」だけ.




【憂さバケツの最新記事】
posted by NOIKE at 17:03 | 東京 ☁ | Comment(0) | TrackBack(2) | 憂さバケツ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック

「Welcome to MusicXML 3.0」 MusicXML の仕様について書かれている新しいサイト(ドキュメント).
Excerpt: 「Welcome to MusicXML 3.0」 http://www.finalemusic.com/UserManuals/MusicXML/MusicXML.htm MusicXML の仕..
Weblog: とりコー
Tracked: 2012-12-17 21:55

MakeMusic のサイトが一新された.それにしたがって,MusicXML のサイトや Finale のサイトも一新されている.
Excerpt: 「MakeMusic - Software to compose, practice, teach, and perform music.」 http://www.makemusic.com/ M..
Weblog: とりコー
Tracked: 2013-02-28 15:40
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。