Hatena::Groupbms

BMS関連ツール開発日記 by TEM

2018-12-16

[]記録 23:22 記録 - BMS関連ツール開発日記 by TEM を含むブックマーク はてなブックマーク - 記録 - BMS関連ツール開発日記 by TEM

  • 今日はforkした方で新データ形式対応を実装
    • 完成して普通のBMSなら普通に変換出来ることを確認
    • “【Freak《Show】Down》”を変換してみるとエラーに
    • 調べてみると、どうやら分解能が8垓ぐらい必要みたい(ちなみに符号無し64bitの最大値は1844京ぐらい)
    • 流石に64bit範囲を超えると無理っす。と今日一日だいぶ無駄になった感じ。まあ無駄じゃないけど
    • 掛け算で簡単に範囲を大きくできるんでやはり近似する方が無難だなあ
  • と言うことで、とりあえずそのソースは保存しておいて、通常データ形式で開発は続行
  • とりあえず Squirrel スクリプト関連のガワは作ったので後はガシガシ設計実装していく感じで

2018-12-15

[]記録 02:06 記録 - BMS関連ツール開発日記 by TEM を含むブックマーク はてなブックマーク - 記録 - BMS関連ツール開発日記 by TEM

  • 寒い寒いでPCの前で縮こまって、だらだらなにもしなかった。
  • とりあえず新データ形式の為にforkをしてやってみることにした。

https://hitkey.nekokan.dyndns.info/diary1812.php#D181214

https://hitkey.nekokan.dyndns.info/diary1812.php#D181215

お返事

  • 同じタイミングに同じWAVが存在する場合は1つしか鳴らさない設定の話
    • 正確には「同じWAVが鳴った場合前のWAVを消す」の設定がfalseの場合のみの話でした
    • その設定で同じWAVが同じタイミングで鳴ると2倍の音量の音が鳴ってしまう
      • どうもBMS制作時のミスでそういうBMSが時々あるみたい
    • v1ではデフォルトでは「消さない」設定だったのでこれが結構起きてたみたい
    • twitter で検索したらこれの問題にあった人が居たので
  • ちなみにv1の「同じWAVが鳴った場合前のWAVを消す」の設定の話
    • v1デフォルトでは「消さない」設定だったのは当時複数のBMSを変換するとプチプチ鳴ってた事があったため
    • 意識的に利用してない限り、「消さない」設定はあまり問題にならない
    • BMSの仕様の「消す」設定を利用してるBMSより、プチプチ鳴るBMSの方が多い判断してデフォルトを「消さない」にした
  • エラー時等の行番号表示等の話はパーサ制作時から意識してるので、エラー処理時に便利なようににできるかと
  • 今はFLACなんて物もあるのかー
  • 数BPM
    • あまり考慮してなかったのでresounding絡みの処理あたりで不整合が生じてるんかな
    • 数BPMに関してはv1とも違う解釈でそのうちちゃんと実装してみるかな
    • 数BPMなんて普通ならエラーだけど面白いから趣味範囲の話って事で
  • 負数STOPは意識してやったので現状でもちゃんと意図通り動く筈

2018-12-13

[]記録 00:25 記録 - BMS関連ツール開発日記 by TEM を含むブックマーク はてなブックマーク - 記録 - BMS関連ツール開発日記 by TEM

  • 同じタイミングに同じWAVが存在する場合は1つしか鳴らさない設定とかあれば良さそう
  • if に来た時に行数表示してこのif成立させる?見たいに聞くのはアリか。

https://hitkey.nekokan.dyndns.info/diary1812.php#D181213

お返事

  • 現在は同じ小節の全ての各チャンネルの分解能は一緒になるように合わせるようになっている
  • 実はチャンネル毎に別の分解能を持たせる事も考えたが
    • BMSの仕様であるWAVを鳴らしてから同じWAVが鳴った場合に前のを消すを再現が超難しい
    • それが無ければ可能ではあるが、1小節でチャンネル数と同じ回数ループする
      • 同じ箇所のBPM変更やらSTOPシーケンスの計算を何度もやることになる
    • 可能ではあるが、大半のBMSの処理時間を増やしてまでやる理由は薄いなと
  • あと、超絶分解能だったとしてもBMX2WAVはアプリの目的上、1秒間に44100の分解能になるのでそれ以上の分解能を持っても意味は無い
  • ついでに、あまりに大きすぎる分解能を持つと現実的な時間内に処理が終わらない事にもなる
  • なので現実的な解としては以下かなと
    • BMX2WAVの分解能の限界を決めて
    • 超絶分解能が来た場合は分解能を限界近くまで上げてから
    • その分解能に近似させる
    • 近似した場合で、結果オブジェクトが重なる場合があるのでその対処は必要か
  • 色々考えてみたら、BMSのデータ構造を大幅に変更すれば行けるかな?
    • 現在は分解能分の配列を作りそこにオブジェクトを入れていく感じ
    • しかし、BMSONみたくオブジェクトに位置情報を与える形にすれば行けるかも?
    • けどそれをやるとパーサとか変換部とか大分大変なことになる。うーん
    • やるにしても正式版を公開してからforkしてやってみる感じ?
    • あー、なんかその新データ形式の方が良いんじゃないかって気分になってきたゾ
  • 特殊なWAVは流石にサポート外かなー。
  • 特殊なWAVのサポートするならメジャーな順からが妥当なんだけど
    • そもそもどの特殊WAVがメジャーなのかもよくわからんし
  • レア事象の割にはこっちの苦労が大きいしユーザ側で対処も出来るしねえ

2018-12-11

[]テスト版2 00:42 テスト版2 - BMS関連ツール開発日記 by TEM を含むブックマーク はてなブックマーク - テスト版2 - BMS関連ツール開発日記 by TEM

http://childs.squares.net/program/temp/bmx2wav_new_core_test1812120017.zip

  • データの重ね合わせの件は失念していなかった。
    • 旧バージョンは上書きしてたけどv2では検出しようとしてロジックを少し変えていた
    • それにバグがあったので修正した
  • ifのネストをするしないを設定できるように
    • 今まではネストするようにしてた
    • not nest if をチェックするとIFの後にENDIFが無くてIFが来た場合直前にENDIFがあると解釈する
  • ENDRANDOMに対応
    • RANDOM、SETRANDOMを実行するとスタックにその値をpushする
    • IFで分岐するかしないかはスタックのトップの値を参照する
    • ENDRANDOMを実行するとスタックから値をpopする。
    • RANDOMの無いENDRANDOMはエラーにするよ
  • not nest if をチェックして“【Freak《Show】Down》”を変換しようしたが分解能が144453120必要とかになった
    • ファイル上5945行目あたり#032小節目の時点で
    • どういう意図なんだ…
    • 上限外して試してみたがマシンのメモリ32GBが枯渇した
    • これ変換出来るようにする必要あるぅ?
    • 分解能を超えた場合少ない分解能に近似させる変換するとか?
    • 流石に結構苦労する割に意味が乏しい気がするので、あらかた終わった後かなー
  • とりあえず分解能限界を65536にした

あっ、やべ分解能限界を外したままアップしちゃった。めんどいからこのままで。

2018-12-10

[]記録 00:25 記録 - BMS関連ツール開発日記 by TEM を含むブックマーク はてなブックマーク - 記録 - BMS関連ツール開発日記 by TEM

  • Core(変換部をこう呼んでいます)はだいたい出来たので次ぎの部分へ
  • スクリプトSquirrel の基礎となるクラス群のバインディング作業がまずあるかな
  • アプリでのスクリプト利用によるあーたらこーたらは色々考えてまとめている最中
  • GUI のデザイン等も同時に考えている。
  • コンピュータ上のすべてのフォルダをツリービューで表示するにはどうするか要調査

https://hitkey.nekokan.dyndns.info/diary1812.php#D181210

お返事

  • e.g.1 は普通に失念していました。
    • 旧バージョンではどうしてるのか、新バージョンだとどうなるか調べないと
    • たしか普通に合成して意図通りの動作にするのが正しい筈
  • 「#ENDIFを持たない#IF」 は#IFの後、#ENDIFが無くて#IFがある場合をどう解釈するかがポイント
    • 旧バージョンもv2もネストする(入れ子)と解釈してる。
    • なのでこのままだと“【Freak《Show】Down》”を「作者の意図通り」に解釈するのは不可能
    • 現実的には設定でネストするしないを選択してパースするってのが可能ではあるが
    • #ENDIF が無いままEOFに行ったら今度は最初からパースをネストしない方式でやり直して行くって設定かな
  • #ENDRANDOM 関連はおそらくnanashigrooveの作者は#RANDOMで乱数発生させた時にスタックLIFO)で保存してるっぽいのか
    • 旧バージョンやv2は言うならグローバル変数乱数値を入れてそれをifで分岐してる
    • まあ確かにネストifを考えると#ENDRANDOMが無いとネストifの意味が無いわな
    • #ENDRANDOM に対応しても #ENDRANDOM を使わないBMSの解釈が変わる訳では無いので #ENDRANDOM を正式対応するか