手元にあったMIDIファイルを適当に変換してみてテスト。 「音の長さだけは」正確に取れてる…んだろうけどMIDIによって割り切れない値入ってたりあるからなあ あと、曲名がコメントで入るようにした。 休符どうしよう。

休符の扱いに悩む理由がわからないかなぁ。単純に無音が鳴っているって考えればC4がR4になるだけなんだけど…。C8R8とQ4C4どっちにするかって話？(これは何を綺麗なMMLとするかっていう正解が無い話なので、好きな方で良いと思う。最初はQ8固定で変換したほうが楽) 画面写真からの予想だと、MIDIから変換した割には随分素直に見えるのでSMFの解析時に色々情報削っているのかなと。具体的には次のイベント(or終端)が来るまでを1音としてるような。それだとしたら一回ちゃんとノートの絶対位置とゲートタイムを出してから変換するだけだと思います。ベースタイム変換も絶対位置求めてから変換すれば割り切れないのは問題ないし。

そうですね…ノートイベント単位で音を書き込んでいってるスタイルになってます NextMidiでも絶対値Tickが取れるの分かったので 今日が週末なので帰ったらまた練り直しかけてみます

惜しいところまで変換できるようになった様子。 休符部分が挿入できたがやっぱり余りの計算がよくわからなくなった。 note.Gate % midi_Resolution？ midi_Resolution % note.Gate？

余り？余りを使うことは無いと思うんだけど…。タイムベースの変換は TimeもGateも「プチコンのTPQN/MIDIデータ側のTPQN」倍するだけなので。例えば4分音符でCDEって並んだMIDIデータ(TPQN=480)を元にすると Time Note Gate 0:000 C 480 0:480 D 480 0:960 E 480 が、48/480=1/10倍 されて 0:000 C 48 0:048 D 48 0:096 E 48 ってなるだけなんで。この時割り切れない数値が出る時はあるけど、誤差が問題になるのは蓄積した時だから、Timeが先頭からの時間であればノート毎にしか出ないんで問題ないです。そのまま整数型に突っ込んで平気。

相対/絶対時間を出したのは、SMF(MIDIデータを保存するファイルの形式)がMIDIイベントに前のイベントからの時間(デルタタイム)を足して並べただけ(+α)のファイルだからです。外部ライブラリ使ってるようなのでそのへんはよしなに。 というか前の書き込みでベースタイムとかかいてるけどタイムベースの打ち間違いです、恥ずかしい。

余りってもしかしてMML変換部分のことかなぁ…。 ゲート(tick)からMMLでの音長に変換するのはこんな感じ。所謂コイン問題なのでメモ化してぐるぐると。 ticks=156 を 16&2. って文字列で返すような仕様なんでそのままでは使えませんが。実際はもっと違うデータ構造で数小節分テーブル化しておいて、それ組み合わせて使う形になるんじゃないかなぁ。PCでやるならその場で計算してもメモリ/速度ともに足りそうだけど:)

MMLの音長(Ln)ってn分音符と同じなんだけど、n分音符は(4/4拍子の長さの)1小節をn分割した長さって意味なんで、MMLでの音長に変換するのは「1小節分のTicks/音符のticks」。もちろん割り切れない長さがでてくるので、&なり_なりで繋ぐしかないです。さっきのプログラムは付点も含めて、MMLが最小になるような組み合わせを探すものです。 ちなみにMIDIでのresolutionって1小節じゃなくて4分音符1つ分のticks(TPQN=TicksPerQuaterNote)だったりするので注意が必要です。どういう単位になってるかはライブラリのマニュアルを見てください。多分変換せずにTPQNのままだと思うけど……。

(だめだこんがらがってきた)

(だめだこんがらがってきた)