@otobeya_now: FMP7が古い曲データのバイナリ互換を持っていない辺り、俺はRCの今後に期待している件www
@Judstyle: FMPV4->MML-(手)->FMP7ってこと？ それともF2PCVみたいにFMPV4->FMP7直結？ FMP7の利用許諾んとこにリバースエンジニアリング不可って明記されちゃってるんで直結は難しいかな…何か怒られない方法探ってみるか…
@otobeya_now: そう、一旦ソース（もしくは中間言語？）に戻して、さらに目的のドライバのMML仕様に合わせてテキストで吐き出す形のコンバーターが出来たらすごいよねー。大昔に使ってた「リッチテキストコンバータ」みたいな感じで。
@Judstyle: それはF2PCV.dll->PMDRC.dll->PMDRCC.exeで既に通った道ですな…適当な中間形式を作るのが面倒で、PMD形式を中間形式として使った人でなしですｗ 『MML->中間データ->任意のデータ形式』の逆版なら作る価値ありか。
@otobeya_now: 言語仕様をXMLで記述するようにして、日本のどこかにいる偉い人に丸投げするのも手ｗ
@Judstyle: ちょ、MMLをXMLで書くの？ 一応MMLの仕様は2008年頃に策定済みで実装始めてるんだけどｗ - 駄日記08/10/22,JUDSTYLE.jp - http://blog.judstyle.jp/article/21627688.html
@otobeya_now: いや、単純に各ドライバ<>中間言語のMML変換テーブルを外部に持てば誰でも変換作れるようになるのかな？って話。Spiceとかに互換持たせればMIDIもイケるなｗ
@Judstyle: 理解。ただ中間データ->演奏データはテーブル方式だと処理速度上げるの難しいので、まんまDLLのプラグイン式にしたほうが多分早いんじゃないかと。あと乗ってくる人を見つけるのが大変そう、っていうかいないと思うｗ つまりdo it mayselfってことかなｗ
MMLを高機能化するとどうしても多段変換になってしまうので、どうせ多段化するなら中間データ仕様とそのI/Oをしっかり設計して、MMLと演奏データの自由度を増そうぜ、っていう考えは当然ながら前からあったんだけど、その変換を定義ファイルとして外出しすることは本気で考えたことはなかった。ちょっと探ってみようとは思う。
ところで、会話の中でも出てる通りFMP7はリバースエンジニアリング禁止だし、以前に軽く『正方向の互換コンパイラを作りたい』って投げてみたけどあっさりお断りされてしまったので、FMP7は一旦棚上げして、従来の方針通りMMLパーサを先に仕上げてしまおう、という決心はついた。
そもそも逆コンが綺麗なMMLを吐けない最大にして唯一の理由が『演奏データ生成時に不可逆な圧縮や変換を行う』ということなので、これを犯さない中間データ形式を定めれば問題は自ずと解決に向かうだろうね。まあMMLを不可逆変換しないで演奏データを作ることができれば問題はないんだろうけど、そんなことは無理。
実のところ、不可逆変換を伴わなければ正コンと逆コンでは処理系も大して変わらないし、そのコードを書く手間もそんなに大きくならないから、MMLパーサを作る視点からしたらメリットは大きい。問題は多分中間データから演奏データへのコンバートだけど…
というあたりで中間データの仕様を再考してみよう。MML仕様とMMLパーサは現行のものが流用できるし、MMLパーサを増設するというのは毎回新規で起こすよりは楽なんじゃないかと思う。もっとも、MMLパーサを1バイナリ＋定義ファイルで運用する点についてはもうちょっと考えてみる。厳密にFMPとかPMDのMMLコンパイラを再現するのはどうなんだろうか、という意味で。
