from ネタ。
Windows Search ならぬ DTX Search サービスを常駐させて、定期的に songs.db を更新させる！
起動高速化、是非欲しいですね ｼﾞｭﾙﾘ
曲が３０００曲を超えたので（いらないのを別フォルダに移動とかさせればいいのでしょうが）、起動にかなり時間がかかります。
songs.db(?)を作成する処理を独立させてはどうでしょうか
songs.dbは次の場合に作成(修正)する
・songs.dbが存在しない
・手動（曲リスト更新(Music-list update ?)のような項目をメニューに追加する）
→曲を追加した、削除したという事実が分かっている場合にユーザーが自分で行う
・エラー時（例えばsongs.dbを参照して曲を実行しようとしたが、削除されていた等、実データが一致しない場合）
・configの設定に項目追加して、毎回起動時に自動でチェックするかどうかを選択できるようにする
→自動で「チェック有効」だと今までと同じ、「チェック無効」だと手動かエラー時にのみに曲データを(再)検索する
これを実装するとなると、曲演奏毎にsongs.dbを更新する必要が出てくるんでしょうかね...スコアデータがらみとかで.
詳しい人、お願いしますm()m
結局、songs.dbには曲リストの構造(どれとどれがset.defでグループ化されているとか・・・)などの情報が保持されていないため、現行のsongs.dbの構成では私が期待していたような高速化には使えないことが分かりました。
仕方がないので、仮に全く別のsongs2.dbをでっちあげました。Songs管理クラスのインスタンスをまんまシリアライズしただけ(笑)
前置きが長くなりましたが、まずは取り急ぎ、DTXManiaの起動時にCapsLockがONならば、dtxファイルの検索は実行せず、代わりにsongs2.dbから情報取得するようなモジュールを作ってみました。このチケットに添付してますので、092のexeと入れ替えてみて下さい。結構起動が速くなりますね。
songs2.dbが無かったり、CapsLock=OFFのときは、従来通りです。
面白いですね(｀・ω・) OSのキャッシュが働くので連続してテストすると違いがわかりにくいですが、いい感じです
songs2.dbが無い状態の時にCapsLock ONの状態で起動するとsongs2.dbが作成されないような気がしますが、テストだからでしょうか （CapsLock OFFで起動しなおせば作成されます）
というわけでテストしてみました。あくまで簡易計測です。
◎テスト環境 WindowsXP HomeEdition Version 2002 SP3 Core2 Quad Q6600 @2.40Ghz(4GB RAM) HDD(Hitachi製) 500GB (SATA Storage) DTX files : 約2,000Scores(1,100songs) 起動ドライブと同ストレージ 方法：各テストパターン毎にPCを再起動して１分ぐらい安定させてからクイックランチャーでDTXを起動と同時に時間計測開始→オープニング画面になるまで ◎テストパターン（左 １分後にスタート１回目の時間 / 右 一度終了させてすぐにDTXを起動） １：songs2.db無し + CapsLock=OFF → （約３２秒 / 約３秒） ２：songs2.db無し + CpasLock=ON → （約３２秒 / 約３秒） ３：songs2.db有り + CapsLock=OFF → （約３２秒 / 約３秒） ４：songs2.db有り + CapsLock=ON → （約１１秒 / 約１秒）期待する４のパターンでは、私の環境では３倍近い結果が出ています。 これはいい仕事かも！
動作のご確認並びに起動時間計測ありがとうございました。
以下、私の環境での参考情報です。
◎テスト環境 Windows7 Professional (SP1) AMD Athlon II X4 605e 2.3GHz (4GB RAM) HDD(WD製) 2TB (SATA/5400rpm) DTX files : 2,904Scores(1,532songs) 起動ドライブ(SSD)とは別HDD 方法：各テストパターン毎にPCを再起動して１～２分ぐらい安定させ、HDDアクセス/CPU負荷共に収まってからexplorerでDTXを起動と同時に時間計測開始→オープニング画面になるまで ◎テストパターン（左 １分後にスタート１回目の時間 / 右 一度終了させてすぐにDTXを起動） ３：songs2.db有り + CapsLock=OFF → （約２０秒 / 約３秒） ４：songs2.db有り + CapsLock=ON → （約５秒 / 約３秒）
from お疲れ様ー。
うちではこんな感じです。
■環境
OS: WindowXP Pro SP3
CPU: AMD Athlon64 X2 4200+ 2.20GHz
RAM: 2GB
Storage: Crucial Real SSD C300 64GB (SATA3.0 (6Gbps) …… を、SATA2.0 (3Gbps) に接続)
DTX: 5850 scores (2879 songs)
■結果
| songs2.db | CapsLock | 初回起動時間 | 再起動時間 |
| 有り | OFF | 10 | 7 |
| 有り | ON | 6 | 6 |
おー。効果出てますねー。
SSDでも起動に6秒掛かるのですか。deserialize()に時間が掛かっているのですね。
個人的には1,2秒くらいで起動して欲しいところですが、これ以上の高速化はさくっとはできないですねぇ。 (deserialize()相当の処理を自分で組むか、Songs管理クラスのプロパティを見直すか。どちらも面倒すぎる・・・)
・・・っとそれはともかく、そろそろbranchを作っておきます。
from SSDでも起動に6秒掛かるのですか。deserialize()に時間が掛かっているのですね。
いやまあ、そのうち4秒が初期化なんですけどね。
起動ステージに入る（＝画面が映る）までの。
もちろん、CapsON/OFF問わず同じだけ時間食います。
なので、初回起動時の songs2.db の処理部分は、実質6秒→2秒に高速化してますよ。
CapsLock=ONで起動するとランダムセレクトの項目が２つになるのですが、ナゼでしょうか？私の端末だけ？OFFだと出ません。
jpeg画像→https://jp-net.sakura.ne.jp/free/index.php?act=download&id1=2
ＦＲＯＭさん：了解です。XPで起動が遅いところはngen.exeである程度高速化できますよ。(ngenのGUIラッパが先に挙げた.NET R-Tuneです)
ランダムセレクトが二重になる件：こちらでも確認できました。すみません。直したものを添付しましたのでよろしくです。
from XPで起動が遅いところはngen.exeである程度高速化できますよ。(ngenのGUIラッパが先に挙げた.NET R-Tuneです)
ご助言ありがとうございます。
ドラム用PC（XP）にはネイティブイメージサービス（.NET Framework Optimization Service）が常駐してますので、 既に NGEN されてると思います。たぶん。きっと。
お疲れさまです
先ほどご紹介いただいた.NET R-Tuneを使ったところ１回目起動で６秒になりました･･･ここまで変わるんですね（驚 感謝です
で、あれこれいらないテストをしていてたまたま発見したのですが、音楽ファイルをルート上のディレクトリに配置すると遅くなりませんか？
普通は適当な名前のフォルダを作ってその下に・実行ファイル・System関連・音楽データというふうに、音楽データはサブフォルダ上に設定にすると思うのですが、
例えば、Cドライブルート上にdtx_mdataというフォルダを作成し、Config.iniのパスを「DTXPath=C:\dtx_mdata\」に設定して
CapsLock:ONで起動しても「LOADING SCORE PROPERTIES FROM FILES」の処理でもたついてしまいます。
試しにルートにTEXTフォルダを作成し、dtx_mdataをそのままフォルダごとコピーし、iniのパスを「DTXPath=C:\TEXTdtx_mdata\」にすれば上記もたつきは発生せず超高速です。
dtx本体のあるフォルダのサブフォルダに音楽データがある場合も当然ちゃんと高速です。
ルートのみが変なのでしょうか？私のＰＣが変なのでしょうか？恋は欲しい。
↑書き込んでおいてごめんなさい、勘違いっぽいのでなかったことに(´д｀)腹筋１００回逝ってきます
(ちょっと不用意に書き込んでしまいました、以後気をつけます)
流れをぶった切ってしまった感があってすごく恐縮です...↑のはパス変更についてのみです
songs.dbを削除しちゃうと？
fastboot2と3のタイムスタンプが一緒かも？
すみません、正しいファイルをzip・添付し直しました。songs.db云々もこれで問題ないはずです。
修正ありがとうございます！
で・・・早速で申し訳ないのですが、fastboot4ではCpasLockがOn/Offともにsongs2.dbを作成しないようです(´д｀)
以前のバージョンでsongs2.dbを作成しfastboot4で起動した場合、高速起動します
その上でテストパターンをいくつか
今は意図的に考慮されていないのかなとも思いましたが、あえて実験しておきました。
表記 注）songs.db → 1 / songs2.db → 2 / CapsLock → CL ◎テストフェーズ１(従来どおりのテスト) 1無+2無+CL:OFF → 1新規作成 → 起動＋動作 1無+2無+CL:ON → 1新規作成 → 起動＋動作 1無+2有+CL:OFF → 1新規作成 → 起動＋動作 1無+2有+CL:ON → ●1作成されず → 高速起動＋動作(以前のバージョンでは1作成されます) 1有+2無+CL:OFF → 起動＋動作(●fastboot4ではsongs2.db作成されず) 1有+2有+CL:ON → 高速起動+動作 ◎テストフェーズ２ → 音楽データの保存先を変更(Config.iniも変更) (ユーザーがデータベースをそのままに音楽データ保存先を変更したと想定) フェーズ１で作成されたsongs.db/songs2.dbをオリジナルとして保存 各パターン毎にオリジナルを使用 1無+2無+CL:OFF → 1再構築 → 起動＋動作 1無+2無+CL:ON → 1再構築 → 起動＋動作 1無+2有+CL:OFF → 1再構築 → 起動＋動作 1無+2有+CL:ON → ●1作成されず → 高速起動＋動作NG(参照エラー？でクライアント終了) 1有+2無+CL:OFF → 1再構築 → 起動＋動作 1有+2無+CL:ON → 1再構築 → 起動＋動作 1有+2有+CL:OFF → 1再構築 →起動＋動作 1有+2有+CL:ON → ●1再構築されず？ → 高速起動＋動作NG(参照エラー？でクライアント終了)間違っていたらごめんなさい(滝
遅くなってすみません。いただいた問題は、ちょっと先走って詰め込んだ機能のなれの果てでした。(結局全部消しましたが・・)
CapsLockのチェックを無くし、songlist.db(旧songs2.db)の情報でまずは起動した後に、曲リストをバックグラウンドで検索するよう、対応を進めました。
バックグラウンド検索の最中は、仮ですが画面左上に"Enumerating Songs.."などと表示します。
曲演奏に入るとバックグラウンド検索を中断し、演奏が終わると再開します。(ここで少し古いAPIを使ってしまっています。後日作り直します)
まだ、バックグラウンドで検索した情報を、アプリ内の曲リストにその場で反映することができていません。 バックグラウンド検索が完了すると、songlist.dbが自動で書き出されますので、当面はそっとアプリを閉じて起動し直して下さい。
更新お疲れ様です
もう高速起動無しでは生きていけない身体になってしまっていたのに更新がないので、どうやって責任を取ってもらおうかと考えておりました。
･･･すいません、半分冗談です。でもこの機能のおかげで普段オンにしないCapsLock君が大活躍という貴重な体験できました。
早速高速起動で楽しませていただいております(｀・ω・´)ありがとう、ありがとう
一応勝手に補足：
初めて使う方は１発目の起動では「song not found」になる場合があります。
その場合はリスト更新が終わるまでそのまま待機して、左上のEnumerating Songs..が消えてから再起動しましょう。
（消える前に終了させるとやり直しです...orz）
少し対応を進めました。バックグラウンドの曲検索が完了した後で選曲画面に入り直せば、曲検索内容が曲リストの反映されるよう対応しています。ただし、その際に、選曲位置は初期状態に戻ってしまいます。初期状態になってしまうのは何とかしたいところですが、はてさてどうしたものか。
なお、Enumerating Songs中に終了させると次回やり直しになるのは、仕様だと思っています。もしもこれを対策するなら「終了しても裏でenumerateを続ける」か「途中までのsonglist.dbを記録してしまう」の2択ですが、どちらもイマイチかと。前者は多分早く終了して欲しくて終了操作をしたのでしょうし、後者は中途半端なsonglist.dbができるのは通常運用している人にとっても色々かったるくなりそうなので。
お疲れ様ですm()m
fastboot7が添付されているのでテストさせていただきました。気づいた点をいくつか失礼します。
・Enumerating Songs...が終了した時点でクライアントが落ちます。
その際、songlist.db/songs.dbがなかった場合は作成されています。
・Enumerating中に曲を選択してもロード画面が終わると同時にクライアントが落ちます。
・「GAME START」選択後、エスケープなどでタイトルに戻るとEnumerating Songs...が消えます。
→そのまま「GAME START」を選ぶとクライアントが落ちます。
個人的にEnumerating Songs...のカラーが好みです。どうやって私の好みを見破ったのかが謎です（違
すみません。ご指摘の内容を修正して、fastboot8としました。(最後にnullにすべき値を間違えていました9
なお、Enumerating Songsのカラーは、選曲画面の上段パネルの色使いに合わせただけですｗ
先ほど、fastboot11を登録しました。
選曲画面を出しているタイミングで曲検索が終わった場合でも、検索結果をそのまま選曲画面に反映するようにしました。 その際、今現在選曲している場所(というかフォーカスしている曲の位置)は維持されます。
同じMUSIC BOX内の曲に増減があった場合は、そのまま放置しても反映されず、別の画面に移るか、適当なMUSIC BOXに出入りするかで更新されます。
これで大体私のやりたいことは一通り実現できました。動作をご確認いただけますでしょうか。 これで問題ないようでしたら、trunkにmergeしたいと思っています。
# 大丈夫だとは思いますが、一応、古いsonglist.dbは消してからお試し下さい
更新お疲れ様です！
さっそくテストさせていただきました。
・ケース１
1)songlist.db / songs.dbを削除してスタート
2)GAME STARTを選択
3)「曲データを検索しています。しばらくお待ち下さい。」の画面で待機
4)Enumerating Songs...が必死に活動中
5)●検索終了後に表示されるリストが空欄になっている
http://jp-net.sakura.ne.jp/free/uf/20120229062600.jpg
→カーソルで上下に移動すれば新しく表示される場所から正しいデータで表示されます。
・ケース２
1)songlist.db / songs.dbがある状態でスタート(fastboot11で作成されたデータを使用しています)
2)GAME STARTを選択
3)適当なBOXに入る
4)そのまま待機
5)Enumerating Songs...が終了する
6)●今現在選んでいるBOXの位置が破棄され、トップリストに戻されます。
また画面上の表示は、選んでいたBOXとミックス表示されています。（表示は今まで選んでいたBOXで、実際の動作はリストトップの動作）
下の画像の場所は本来BOX「09」であり、選ぶとBOX「09」が展開表示されます。
→カーソルで上下に移動すれば新しく表示される場所から正しいデータで表示されます。
http://jp-net.sakura.ne.jp/free/uf/20120229062914.jpg
すみません。修正して fastboot12 としました。
お疲れ様です。
今のところ問題なく動作しています。仕事の都合で比較的触れてないのでもうしばらくいろいろ試させていただきますね。
曲列挙中にプリムービーがある項目を選ぶと重くなりますが、これはしょうがないかな。
しかし、私が考えていた高速化よりはるか上をいく対応…やはりプロの仕事は違いますね(´д｀)
せっかくですので、#PREMOVIE再生中は曲探索を中断するようにしてみました。(fastboot13)
個人的には逆のが嬉しかったりしますが・・・他の方はどうでしょうか？
'検索中は#PREMOVIEを再生せず、検索を優先→終了して反映後は通常動作
いつも意見を拾っていただき感謝です。取り急ぎ報告。
1)起動
2)「GAME START」
3) Ctrl+F1 でコンフィグを開く→待機
4) ●検索が終わるとクライアントが落ちます
'タイトルから入ったコンフィグ画面では落ちません。
↑Shift+F1の間違いです(´д｀)
動作確認いただきありがとうございます。fastboot14にて、以下、修正しました。
早速の対処ありがとうございます。
修正いただいた箇所はすべて問題なく動作していると思います。
やぎ。様にはどんどん開発・改造していただく必要があるかと思います（何,ので、この件の私のデバッグは以上で。
また問題を発見してしまったら報告させていただきます。更新お疲れ様でした＆ありがとうございます！
'デバックスキルもままならないので嫌味になってないか心配です（恐
ご確認いただきありがとうございました。
それでは1週間ほど様子を見ていただいて、問題ないようでしたらこの高速起動処理はリリース093向けに正式に取り込むようにいたします。
ちょっと高速起動対応を始める前にやっていたこと(DTXCヘルプ英訳など)が宙ぶらりん状態になっているので、私は今週はそれを進めようと思っています。
rev324で、branch(亜流)からtrunk(本編)に正式に高速起動対応を取り込みました。
次のバージョンに搭載されます。
Fork
現在のDTXManiaはdtxファイルの追加削除更新有無を確認してから起動するので、特にファイルキャッシュがヒットしない状態での起動は非常に時間が掛かる。
例えば起動時はまずsongs.dbの情報だけで曲一覧を取得して即起動するようにし、その後裏でdtxファイルの追加削除更新チェックを行うようにするなどして、起動を高速化できないか。
もちろん、削除したdtxファイルの演奏を開始できてしまうなどの問題には対処する必要があるが、そもそも dtxファイルの追加削除更新は稀かつ局所的に発生するはずなので、実際にユーザーがこういう「残念な動作」に遭遇することは稀なはずであり、 デメリットよりメリットの方が大きいと考える。