記録

• 同じタイミングに同じ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がメジャーなのかもよくわからんし
• レア事象の割にはこっちの苦労が大きいしユーザ側で対処も出来るしねえ