rev938で追加。
今後レイアウトも変わりそうなので、それを見越してデザイン性は考えてません。
実装に伴いノードリスト登録時のCDTXのヘッダのみ読み込みが不可能になりましたので、
従来よりsongs.db登録が遅くなると思います。
改善案等あればよろしくお願いします。
(レーンごとのチップ数とかも取得できるようになったのは強みかもしれませんが)
従来よりsongs.db登録が遅くなると思います。
これ、めちゃくちゃ痛いです・・・。うちのデバッグ環境(Win8.1 x64 / Haswell i7-4770T (2.5GHz 4core HTあり) / 16GBメモリ / 3TB WD Green (5400rpm) だと、613曲/1731スコアで、ざっと1分半かかりました。(なお2回目以降だと、HDDキャッシュ効きまくりで、数秒もかからずに終了。)
この間、更新のない曲は問題なくプレイできますが、追加した曲は見えないままです。
実は似たような議論を以前したことがあります。(#28198 曲の長さを曲選択時にわかるようにする)
そちらでは、EnumeratingSongsを二段階に分けて、
1) まず、ヘッダ相当の情報を抽出する
2) 次に、バックグラウンドで粛々と追加情報を追加する
なんてことを話していました。そしてその件はそのまま放置状態になってしまっていたのですが・・・レーン数判定とセットでやってみるとよいかも。
(注: 2)の方は、基本的に1つのDTXファイルあたりの処理が遅くなるので、例えば100個くらいずつで一旦flushするなどの工夫をしないと、「ちょっと本体を起動して、ちょっとプレイして、すぐ終了する」ような場合にはまりそうです)
または、フォルダの更新日を使うとか。現在はDTXファイルの更新日情報だけを使っていて、set.defやフォルダの更新日情報を使っていません。これをうまく使えれば、個々のDTXファイルへのアクセスが大幅に減って、songs.dbの更新の遅さが気にならなくなるかもしれません。
最初の1回目の起動で時間がかかるのは、まあ、仕方ないですね・・・。
あと、個人的には
コメントありがとうございます！
やはり厳しいですか…そちらのチケットも確認致しました。
EnumeratingSongsの機能から見直すというか、その辺りから色々考えてみたいと思います。
レーン数種類
ご指摘ありがとうございます。次コミット時に修正します。
ギターのレーン数
使わないから…と思ったのですが、いざ内部で使う時に0しか拾ってこない！じゃよろしくないですね…
OPEN有無はないよりかはあった方がよさそうですね。新しいレーン数画像を作る方向で検討します。
LPとLBDの区別
こちらも合わせて進めます(すでに着手して頂いてるのでもう間に合わなそう)
いえいえ、私は何も着手してませんので、どうぞどうぞ。
rev.1008でConfigにDTXをヘッダ以外も取得するLoadDTXDetailを追加。
・Reload Songs等曲データを取得する際に、曲データのヘッダ以外も取得
これにより、使用レーン数等、曲データの詳細な取得が可能になりました。
(非常に暫定措置で申し訳ありませんが)
これなんですが、個人的には以下の課題があると思っています。
それぞれ、こんな風に解決できませんか。
色々対策を考えて頂きましたが、個人的にはenumsongsをどうにかできれば一番いいなあとは思ってます。
やっぱり遅延ロードは欲しい…
ikanickさんがお持ちの改善イメージを、具体的に教えていただけますか。
現在の、レーン数取得ロジックがない場合の動作は、だいたい以下のような流れだったと思います。
これを、レーン数取得ロジックを加えたときに、どのように変えようとお考えでしょうか？
(遅延ロードがほしいとのことですが既に上記3で遅延ロードしているので、ちょっとわからなくなってます・・・。さらに5とか6とかの遅延ロジックを入れたいということでしょうかね)
やぎ。さんに書いていただいた
EnumeratingSongsを二段階に分けて、 1) まず、ヘッダ相当の情報を抽出する 2) 次に、バックグラウンドで粛々と追加情報を追加する
こいつが実装できれば一番いいな～と思った…思ってるだけです…
なので上記1～4でいえば5に相当するのかな？
Fork
選曲画面上に、ドラム譜面の使用レーン数を6,10,12レーンに種類分けして表示して欲しい。
・6レーン：HH SD BD HT LT RC
・10レーン：LC HO HH SD BD HT LT FT RC RD
・12レーン：LC HO HH LP LBD SD BD HT LT FT RC RD