堕天使の煉獄

今日もニコニコＰＧ。

ＱＴでMIDIシーケンサ作り再開中。
とりあえず以前のＳＭＦファイル読み込み部分のコードがあまりにもウンココードだったのと、読み込みにwinapiのマルチメディア用関数を使用していたので、環境非依存なコードに変更。
最初はｃ++の標準関数つかおうと思ったのだけども、ＱＴのバイナリ読み込みのQDataStreamがバイトのエンディアン指定まで出来る事を知って、こりゃ楽だってことでｗｉｎ依存コードからＱＴ依存コードにｗ

そこで組み替えながら見直してたときに気づいた事。
レコポンで吐いたＳＭＦって、メタイベントのFF 21の出力ポート指定がっつり入ってるのね。ＳＭＦフォーマットの参考サイトでは非標準ってことで、このポート指定イベントは記載すらされてないところが結構あったり。
そもそもこのポート指定って、ほとんどSC88Proとかの32チャンネル対応音源向けに通常は16チャンネルが最大だけど、ポートＡ、Ｂでわけて32チャンネル使えるっていう特殊機能向けのもので、SC88Pro以降ではあんまし使われなくなったので、結局非標準とされた……みたいな経緯のあるものなんだけども。

なにげに最近では状況が変わって来て、最近のMIDI機器はMIDIケーブルじゃなくてUSB接続がスタンダードになって、そこで16チャンネルまでっていう転送量上の制限が関係なくなって。そんで最近では64チャンネルまで使える音源が普通になってきてるそうな。

そこでこのポート指定の部分がまた使われ始めてるらしい。
……残念なことに、どこも同じ使い方してるわけではなく
ttps://sites.google.com/site/yyagisite/material/smfspec

利用法として、現状以下の3パターンが確認されているが、 どのパターンで作成されているかはデータだけでは識別不能。

1.pp=0～3が、それぞれポート1～4に対応している場合
2.pp=0がミュート、1～4がそれぞれポート1～4に対応している場合
3.pp=0がポート1、pp=1がポート2、pp=2がポート1&2両方、 pp=3がミュート

日本国内(のフリーソフトの類)では基本的に 1. のパターンを想定しておけば問題ないと思われる。

と、ばらつきがある感じだとかで。
うーん。めんどくさい。

ＳＭＦフォーマットの2もいろいろとフォーマットが違ったりするんだけど、なにげにチャンネル数が増えた所為か、これもまた使われ始めてるらしい。どの使われ方がスタンダードなのかとかさぱーりですが。
まあフォーマット2は用途が限定されそうなので、無視してもよさげですけど。

んでもＳＭＦフォーマットって、パソ通時代からある様な古いフォーマットなんですよね……。ランニングステータスとか、少しでもファイルの容量を減らす工夫とかあったりして。

今となってはただ読み込むのにちまちまバイト単位で読み込んで、特定のビットを調べて、このビットが立ってたら次のバイトとつながってるデータだとか、バイトの並びを変えたりとか、めんどくさいことこの上ないｗ

んで、ＳＭＦはまあ、わりとフォーマットを説明してるサイトとかぽこぽこ出てくるので苦労はないのだけども。
レコポンユーザーとしてはRCPやG36ファイルにも対応したいところ。

……が、この界隈、現在ほぼ絶滅危惧種指定な感じなんですよね。
この辺のソフトとかドキュメントとか、更新日時をみると2000年代ですらない所も多く、ほとんどが化石化してるぽ。

そんでもって、昔はそれなりにあった気がするんだけど、いま改めて検索してみると全然RCPやG36ファイルのフォーマットの情報とか出てこない……。
コンバータとかのソフトはあるんだけどな（んでもどれも古すぎて、ｗｉｎ７とかｗｉｎ１０とかでもうごくのかね。MS-DOS用のアプリとかまで出てきたけど……ｗ）

ようやく見つかったのがSTedというレコポンのクローン？　のソースコードの中にファイルのフォーマットの情報が載ってたりで。コレならなんとかなりそうぽ。

うーん。
いまだに最新の機器でも使われるMIDIという規格のわりに、その周辺は時がとまってるんだよな。１０年以上前に。

新しいんだか古いんだか……。