設計と実装と実現

Peter Deutsch さんが,ひさしぶりにまともなことを言っている.
(この人,DTD を読めば想像がつくことを質問するときがあるので,私はあんまり好きじゃない)

「Finale を利用する」というのは,おっしゃるとおりで「a certain way」だ.
Finale を採用したことによって成功もしたけれど,失敗もしているような気がする.

すでにある実装から仕様をつめていくと,ある時期にかなりの手戻りを食らってしまう.
設計から実装に進んだときと違って,そのときの手戻りはたいてい莫大な作業量になる.
さらに,手戻りすべき時期に手戻りしないでごまかして進み続けると,本人も周辺も疲弊していってしまって,さらには人が離れていく.
とはいえ,その手戻りを食らう頃に,その仕様や実装がすでに古いものになるようなときは,実装から仕様をつめるというのは,実用面で手っ取り早いこともある.
MusicXML は,最初はそのつもりでいたのかもしれない.

でも,いまになっても MusicXML のデータ構造やこまごました設計を Finale にべったり依存して決めるのは,そろそろデメリットのほうが大きくなっているんじゃないかなぁ.
たとえば, という概念が必要になるのは,Finale がレイヤーという概念を採用してしまっているからに他ならない.
なんて,作曲しながら楽譜を書くのにいらないよねぇ.
そうとういい加減な思考で作曲をしないかぎり.
が MusicXML という楽譜データ形式に存在したほうがよい点って,ひょっとしてあるのかなぁ?

せっかく「仕様のメジャー・バージョンアップをしましょう」,となったのだから,ごっそり直しちゃったほうがいいと思う.
いままでの実装やツールを捨てたほうが,簡単でしょう.
もはや大きな手戻りもないだろうから,気が楽だし.

おそらく,Michael さんは,こきたない のはいった MusicXML を処理するプログラムを書いたことがないのではないかと思う.
以外にも「えぇー?」という仕様がいまでも残っているけれども,まぁ,いいやー.

この記事へのコメント

2007年04月27日 18:43

The core issue, though, is that music notation itself is loosely
structured.


うっひゃー.そんな答えが返ってくるとは.
なんだか,よくわかってしまったよ(^^;).