Muse掲示板

使い方 新規投稿 新着記事 ツリー表示 ワード検索 過去ログ 管理モード

過去ログ表示

過去ログ4 を表示

表示ログ 過去ログ1 過去ログ2 過去ログ3 過去ログ4
過去ログ5 過去ログ6

過去ログ検索は 検索 より行えます。
記事数 / 1314件 (1101-1120 を表示) / 全ページ数 / [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65]

No.10309/Re[11]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/26(Sat) 00:05:04)

    > 上のような構成にすれば、本当にサブスレッドの処理が重ければ、効果があるのではないでしょうか?
    > メインから SetEvent した後、メインはすぐに動けるわけですから。
    そうですね。私も作っていて気づきました。
    ただ、現状は劇的な効果が見られないので、文字表示の機能を強化しその処理が重くなる時に、
    合せて実装しようと、現段階では思っています。

    ちなみに、*WAVE の発行は今でも重いので、これに適用すれば効果がはっきりするだろうと思い、
    先ほど実験してみたのですが、残念ながらまったく効果はありませんでしたorz
    初回の音出しでは、メインウィンドウのシークバーが一瞬止まってしまいました。
    その止まっている時間も、従前のシングルスレッドと差を感じられませんでした。
    SetEvent した後、すぐに動けるはずなんだけどなぁ〜。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10312/Re[12]: Muse 新機構の提案……
■投稿者/ himajin925 -(2016/03/26(Sat) 17:41:54)

    >
    > ちなみに、*WAVE の発行は今でも重いので、これに適用すれば効果がはっきりするだろうと思い、
    > 先ほど実験してみたのですが、残念ながらまったく効果はありませんでしたorz
    > 初回の音出しでは、メインウィンドウのシークバーが一瞬止まってしまいました。
    > その止まっている時間も、従前のシングルスレッドと差を感じられませんでした。

    そうですか、なんかちょっと残念 (なぜか僕が残念に思う(^_^.)
    シークバーの停止と言うのは、体感したことがないのですが、wav の再生の遅延は感じることがありますね。

    > SetEvent した後、すぐに動けるはずなんだけどなぁ〜。

    何が起きているのでしょうね?

    wav ファイルの再生は、関数は何を使っているのか分からないのですが、高水準の「ファイル名を与えると再生する」関数であれば、予め読んでおいて、メモリのハンドルで渡す、とかはどうでしょう。(低水準関数を利用している場合でも、先読みは可能でしょうね)(.mus ファイルの2度読みが要りますが)
    ただ、そこまでしたほうが良い、と思っているわけでもないんです。
    単に「何が起きているのでしょう?」と言うところです。

    その再生関数に、何かプロセス全体にかかる制限は?メッセージのディスパッチが一時停止される、とか?

    ↑たぶん無いでしょうか、動きをみると疑いたくなります。ただの想像ですが。
    muse のウィンドをタイトル行で「つまんで」動かしながら *WAVE のところを演奏させてみると、ウィンドの動きがちょっと飛んだりします。シークバーの件と同様なのかな?
    何が起きているのでしょう?
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10310/Re[8]: Muse 新機構の提案……
■投稿者/ るう -(2016/03/26(Sat) 11:42:03)

    あっ、調べてみたらtimeSetEvent()は最初から別スレッドで動作するんですね。
    ですのでわざわざマルチスレッド化なんてしなくても、最初から「別スレッドで演奏」になっていたのかもしれません。
    そりゃ効果ありませんね……。

    なおPostMessage()は「メッセージを投げる(後は対象スレッドの次のメッセージループが勝手に処理してくれる)」ですので、
    SendMessage()の場合(メッセージを投げ、対象スレッドが完了するまで待つ)と比べるとどうしても同期性に劣ります。
    もしかしたら、その辺が関連するのかもしれません。
    (同一スレッドの場合はSend、異なる場合はPosstとして働くSendNotifyMessage()もありますが多分今回は関係ナシ)

    そこで、新しい方法を考えてみました……出てくるスレッド数はなんと「3つ」になります!

    (a) メインスレッド(スレッド優先度:THREAD_PRIORITY_NORMALのはず)
    (b) マルチメディアタイマー(スレッド優先度:THREAD_PRIORITY_TIME_CRITICALのはず)
    (c) 重い処理専用スレッド(スレッド優先度:THREAD_PRIORITY_ABOVE_NORMALかTHREAD_PRIORITY_HIGHEST辺りに設定……普段はWaitForSingleObject()して寝ている)

    ●必要なモノ
    ・(b)と(c)で共用するイベント
    ・(b)と(c)で共用する「重い処理スタック」
    ・(b)でのみ使用する「退避用スタック」
    ・重い処理用クリティカルセクション

    ●手順:
    (a) → 今まで通り
     せいぜい、演奏停止時にクリティカルセクション内で「重い処理スタック」を空にするくらい
    (b) 以下のように変更:
     ・重そうな処理が必要になったら場合or「退避用スタック」にデータがある場合、
      ・TryEnterCriticalSection()
       ・成功時
        ・「退避用スタック」の中身を全て「重い処理スタック」に投入&「退避用スタック」を空に
        ・重そうな処理を「重い処理スタック」に投入
        ・LeaveCriticalSection()
        ・イベント発火して(c)を起こす
       ・失敗時
        ・重そうな処理を「退避用スタック」に投入するだけ
     ・軽い処理は通常通り
    (c) 重い処理をより高い優先度で実行するスレッド
     (c-1) Muse起動直後、イベントをWaitForSingleObject()して寝る
     (c-2) 起きたら、
      ・EnterCriticalSection() ※ここはTryじゃない
      ・「重い処理スタック」を全部処理
      ・LeaveCriticalSection()
     (c-3) (c-1)に戻る

    こんな感じに優先度の高いスレッド(c)を噛ませてやる事で、
    UIスレッドの全体の優先度自体を上げる事なく、同期性を高めたまま重いUI処理を実行できる……と思うのですが、いかがでしょう?
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10311/Re[9]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/26(Sat) 14:37:23)

    > あっ、調べてみたらtimeSetEvent()は最初から別スレッドで動作するんですね。
    > ですのでわざわざマルチスレッド化なんてしなくても、最初から「別スレッドで演奏」になっていたのかもしれません。
    > そりゃ効果ありませんね……。
    あははっ(笑)。
    結局、そういうことなのかもしれませんね。
    でも、今回けーごさんの書き込みに端を発し、
    るうさん、himajin925とやり取りしたマルチスレッドの件は、
    別の意味で絶大なる効果を生み出した可能性があります。(後述します)

    > なおPostMessage()は「メッセージを投げる(後は対象スレッドの次のメッセージループが勝手に処理してくれる)」ですので、
    > SendMessage()の場合(メッセージを投げ、対象スレッドが完了するまで待つ)と比べるとどうしても同期性に劣ります。
    > もしかしたら、その辺が関連するのかもしれません。
    > (同一スレッドの場合はSend、異なる場合はPosstとして働くSendNotifyMessage()もありますが多分今回は関係ナシ)
    おおっ、SendNotifyMessage()なんていうのもあるんですね。
    勉強になります。
    早速試してみたのですが、やはりPostMessage()と同様に同期せず、処理が後回しにされてしまいました。
    (これが同期しないということは、別スレッドであることの証かも)

    > そこで、新しい方法を考えてみました……出てくるスレッド数はなんと「3つ」になります!
    >
    > (a) メインスレッド(スレッド優先度:THREAD_PRIORITY_NORMALのはず)
    > (b) マルチメディアタイマー(スレッド優先度:THREAD_PRIORITY_TIME_CRITICALのはず)
    > (c) 重い処理専用スレッド(スレッド優先度:THREAD_PRIORITY_ABOVE_NORMALかTHREAD_PRIORITY_HIGHEST辺りに設定……普段はWaitForSingleObject()して寝ている)
    (c)が1つなら、計3つですが、
    独立した重い処理(譜面モニタ描画とか、鍵盤表示とか)が、いくつもあったらもっと増えちゃいますね。

    > こんな感じに優先度の高いスレッド(c)を噛ませてやる事で、
    > UIスレッドの全体の優先度自体を上げる事なく、同期性を高めたまま重いUI処理を実行できる……と思うのですが、いかがでしょう?
    考察、ありがとうございました。開発の参考にさせて頂きます。
    ただ今回は、劇的な効果が確認できないため、マルチスレッドの対応は見送ろうと思います。
    肌で感じられる効果がないと、まっとうに開発できるているかどうか確認しながら進められないので、
    開発自体がちょっと辛いんです。

    ・・・ちなみに、先ほど後述すると書いた「絶大なる効果」の件ですが、
    マルチスレッドに対応させたオプションでビルドしたら、
    なっなんと、muse.exeの容量が2/3になったのです。
    しかもソースプログラムに、スレッド関係の記述が一切存在しないのにです!

    人間で言えば、体重60kgの人が一夜にして40kgになったようなものです。
    msvcrt.libは、libcmt.libと比較にならない最適化コンパイルをするのかもしれません。
    Muse側のプログラムは一切変更していないのですが、もしかしたら実行処理性能もアップしたかも。

    サウンドフォント対応、LilyPond対応、ユニコード対応、と強化するたびに
    徐々に実行モジュールが増加(当たり前ですが)してきたのですが、
    一気に、それ以前のサイズに戻ったのです。驚きです。

    そんな訳で、機能的には何も変化は無いのですが、
    しばらく様子を見てから、マイナー扱いでバージョンアップするかもしれません。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10313/Re[10]: Muse 新機構の提案……
■投稿者/ 諸熊 -(2016/03/26(Sat) 19:39:08)

    > ・・・ちなみに、先ほど後述すると書いた「絶大なる効果」の件ですが、
    > マルチスレッドに対応させたオプションでビルドしたら、
    > なっなんと、muse.exeの容量が2/3になったのです。
    > しかもソースプログラムに、スレッド関係の記述が一切存在しないのにです!
    >
    > 人間で言えば、体重60kgの人が一夜にして40kgになったようなものです。

     Readmeの半分になっちゃうんですか?
    病的に痩せるとかビバウンドするとか、そっちを心配したくなります(笑)。
    プログラムだからそんな人間臭いことはそうそう無いと思いますが…
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10314/Re[11]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/26(Sat) 21:04:21)

    himajin925さん
    > 何が起きているのでしょうね?
    私も興味が尽きないので、空いた時間を見つけては今後も実験しようと思います。

    諸熊さん
    > 病的に痩せるとかビバウンドするとか、そっちを心配したくなります(笑)。
    というわけで、脳筋トレに励みます(笑)。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10316/Re[12]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/27(Sun) 17:55:46)

    喜ばしいお知らせがあります!
    効果を生み出すマルチスレッドのMuseが完成しました。

    前回[10309]で
    「初回の音出しでは、メインウィンドウのシークバーが一瞬止まってしまいました。」と書きましたが、
    これは、シークバーの移動で演奏をモタレさせないよう、
    PostMessageで移動させていたのが原因でした。
    (自分でコーディングしておきながら、忘れてました)汗

    そこで、
    現行バージョンでは、演奏と一緒に*WAVEを鳴らすと演奏がひっかかるデータを作り、
    *WAVEをスレッドポストする新バージョンで実行してみたら、演奏は滑らかに通過しました!
    確実にマルチスレッドの効果が確認できたのです。

    勢い今度は、
    フォントのロード時点で演奏がひっかることがあるテキスト表示に関しても
    マルチスレッド化したところ、その効果も確認できました。
    初期ロード時にステルス描画するという対処療法部分はバッサリ削除した状態でもモタレませんでした。
    (なお、この実験は私の環境では効果を確認しづらかったので
     Αφροδιτηさんにご協力頂きました。ここに、謹んでお礼申し上げます。)

    また、
    るうさんからスレッド優先度のアイディアを頂きましたが、
    それをしなくても十二分に効果を得ましたので、今回は見送りました。m__m

    という訳で今回、皆さんとやり取りしたマルチスレッド関係の話題は、以下の様な成果を得て閉幕です。
     ・文字表示の演奏モタレを抜本的に解決(更にセンタリングなどの今後の重い処理開発も可能に)
     ・WAVEコマンドの演奏モタレを抑止(ただし、WAVE発音自体の初回タイムラグは従前どおりです)
     ・実行モジュールmuse.exeが、2/3に減量(諸熊さんが気付かれたとおり、Readme.txtの半分の容量です)
     ・対処療法である初期ロード時のステルス描画の削除(派生的に色コードをconst化できました)

    思いの外、多くの収穫でした。
    心から感謝致します。

    脳筋トレ、続けてよかった(笑)。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10317/Re[13]: Muse 新機構の提案……
■投稿者/ Kobarim -(2016/03/27(Sun) 20:39:16)

    > なっなんと、muse.exeの容量が2/3になったのです。
    > しかもソースプログラムに、スレッド関係の記述が一切存在しないのにです!

    開発環境は VS2010 よりも古いのでしょうか。
    C ランタイムをマルチスレッド版にして、ダイナミックにリンクしているだけだったり
    しませんか?MSVCXXX.DLL がないと動かないとか。
    今までは C ランタイムをスタティックにリンクしていたとか。

    まあ、VC++6.0 だったらそれでも全く困らないと思いますけど。

    > Muse側のプログラムは一切変更していないのですが、もしかしたら実行処理性能もアップしたかも。

    コンパイラオプションでシングルスレッド版をマルチスレッド版に変えただけなら、
    C ランタイムが複数のスレッドから同時に呼ばれても大丈夫なように排他制御をする
    ようになるので、その分だけ実行速度が低下(体感できるほどは変わらないと思います)、
    実行ファイルサイズもむしろ大きくなってもおかしくない筈ですが…。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10318/Re[14]: Muse 新機構の提案……
■投稿者/ Kobarim -(2016/03/27(Sun) 20:51:08)

    > msvcrt.libは、libcmt.libと比較にならない最適化コンパイルをするのかもしれません。

    見落としていました。
    やっぱりスタティックにリンクしていたのを MSVCRXX.DLL 依存になるようにしただけのような…。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10319/Re[15]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/27(Sun) 21:31:17)

    > やっぱりスタティックにリンクしていたのを MSVCRXX.DLL 依存になるようにしただけのような…。
    げっ、そういうことだったのかorz

    Kobarinさん、ご指摘ありがとうございました。
    あやうく、DLL依存のモジュールをリリースするところでした(汗)。

    ビルドオプション見直して、正しくリバウンドできました(苦笑)。
    今回の対応で、むしろ 2kg 太って、じゃなかった 2KB 増えてます。
    まあ、それでも巷のソフトに比べるとスリムですよね。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10320/Re[16]: Muse 新機構の提案……
■投稿者/ Kobarim -(2016/03/27(Sun) 21:46:16)

    VC++6.0 でビルドしたものだと MSVCRT.DLL が必要となりますが、Muse が動作する
    Windows2000 以降なら最初からインストールされている筈なので問題にはなりません。

    VC7 以降だと OS によっては必要なランタイムが最初からはインストールされていない
    かもしれません。ちょっと分かりません。

    VS2015 だと Winwdows10 でも(少なくとも2015年10月頃は)必要なランタイムが
    最初からは入っていませんでした。現在はどうだか分かりません。もしかしたら
    Windows Update か何かで勝手に入るのかもしれません。

    マルチメディアタイマーだと、コールバック関数内で使える API が限られています。

    https://msdn.microsoft.com/ja-jp/library/windows/desktop/dd757631(v=vs.85).aspx

    の Remarks の部分です。

    MSDN で調べるとこの記述がないところもあるので、最近の OS では大丈夫なのかもしれません。

    もし Remarks の通りなら、コールバック関数内で malloc/new を呼ぶことさえも危険という
    ことになります。(C ランタイムライブラリが内部で HeapAlloc なり VirtualAlloc を呼ぶ
    でしょうから)

    なので、可能なら MIDI 演奏ルーチンもスレッド化した方が出来ることの制約が少なくなる
    ので望ましい気がします。その場合のスレッド優先度は TimeCritical にしておかないと
    ちょっとしたことで「モタリ」が発生するのでご注意下さい。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10321/Re[17]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/27(Sun) 22:31:24)

    Kobarinさん
    再び、ご丁寧なご教示、ありがとうございます!
    心より感謝します。とっても勉強になります。

    > VC++6.0 でビルドしたものだと MSVCRT.DLL が必要となりますが、Muse が動作する
    > Windows2000 以降なら最初からインストールされている筈なので問題にはなりません。
    なるほど。
    現在のMuseは、VS2010 Expressです。

    > VC7 以降だと OS によっては必要なランタイムが最初からはインストールされていない
    > かもしれません。ちょっと分かりません。
    了解しました。
    この辺のトラブルが生じると利用者の手を煩わせるので、
    念のためかもしれませんが、やはり静的リンクでビルドしておこうと思います。
    それでも、高々336KBしかないソフトなので気が楽です。

    > マルチメディアタイマーだと、コールバック関数内で使える API が限られています。
    おお、恐ろしや(苦笑)。
    ちょっと確認してみます。

    > MSDN で調べるとこの記述がないところもあるので、最近の OS では大丈夫なのかもしれません。
    Museは初版(1999年)から、そ知らぬ顔してピアノ鍵盤の表示してますねぇ〜(冷汗)。
    流石に、malloc/newなんてしてませんが・・・。

    > なので、可能なら MIDI 演奏ルーチンもスレッド化した方が出来ることの制約が少なくなる
    > ので望ましい気がします。その場合のスレッド優先度は TimeCritical にしておかないと
    > ちょっとしたことで「モタリ」が発生するのでご注意下さい。
    なるほど。
    本格的なプレーヤーソフトは、そのように組んでるんですね。
    だから、あんなにいろいろな動きが可能なのか・・・。
    勉強になります。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10322/Re[18]: Muse 新機構の提案……
■投稿者/ けーご -(2016/03/27(Sun) 22:51:42)

    言い出しておきながら何も分からないですね。。
    再配布を全部コピってるうちとしては、SP2セットアップ直後のxpにはD3DX24dllすら無いですね。
    VCPPも2005〜2015全部後で追加しました
    フレームも4.0が重くて消しちゃいました。
    (VisualBasicじゃないなら3.5も使ってない、ですよね

    vistaや10にはガジェットとかで辛うじて2005,2008が入ってるかって感じですかね
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10323/Re[18]: Muse 新機構の提案……
■投稿者/ Kobarim -(2016/03/27(Sun) 23:47:34)

    Windows9x だと MIDI の再生は 16bit DLL 内でマルチメディア
    タイマーを使用して演奏ルーチンを実装しないと、ウィンドウを
    最大化・最小化するだけで演奏が「もたり」ました。(Win98 は
    割と平気でしたが Win95 は結構酷かった)

    32bit アプリケーションから 16bit DLL を使うのはかなり特殊な
    手法が必要で、当時の私では実力不足で対応出来ませんでした。

    NT カーネルなら普通に 32bit マルチメディアタイマー(またはマルチ
    スレッド)で大丈夫だったのですが、NT では 32bit アプリケーション
    から 16bit DLL を使うことは出来ないので、本当にきちんとした MIDI
    プレイヤーソフト(TMIDI Player 等)は Win95/NT で演奏ルーチンを分け
    ていました。

    とまあ、昔話はこのくらいにして、スレッド生成時(CreateThread/_beginthreadex)
    の ThreadProc を

    DWORD ThreadProc(LPVOID pParam)
    {
    while(!終了フラグ){
    TimerProc();
    Sleep(N);//N はタイマーの周期(ms)
    }
    }

    のように実装すると、マルチメディアタイマーと大体同じ動作になり、
    TimerProc() 内で使える API の制約がなくなります。

    マルチスレッドアプリケーションの開発はとても難しいと私は思います。
    デバッグ版では大丈夫でもリリースビルドだとダメになったり、PC に負荷
    がかかっているときだけ発生したり、再現性のないバグに悩まされます。

    MSDN の記述を信じるなら、描画をマルチメディアタイマーで行うのは
    おそらく危険だとは思うのですが、今までに特に安定性に関わる不具合報告が
    ないなら現在の OS では大丈夫なのかもしれません。

    PostMessage なり PostThreadMessage(これも使っちゃいけないっぽいですが)
    でメッセージを受け取ったスレッド内で描画するなら問題ないと思います。

    負荷がかかったときの「演奏のもたり」はタイマーの周期を 4ms から 1ms
    に変更するだけで結構改善されると思います。

    1ms に変えても、コールバック関数自体が「毎回重い処理をするのでない」
    なら負荷は気にしなくて良いと思いますが、心配なら周期を設定出来るよう
    にするのも1つの手かと思います。

    あと、どうも Muse は timeGetTime を使ってないっぽいので、演奏時間の
    計測をどうやってるのかが気になります。もし GetTickCount を使用して
    いるなら精度がかなり悪いので timeGetTime に置き換えた方が良いです。

    QueryPerformanceCounter は呼び出しているようなので、そちらを使って
    演奏時間を計測しているならそれはそれで良いと思います。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10324/Re[19]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/28(Mon) 00:35:22)

    > とまあ、昔話はこのくらいにして、スレッド生成時(CreateThread/_beginthreadex)
    > の ThreadProc を
    >
    > DWORD ThreadProc(LPVOID pParam)
    > {
    > while(!終了フラグ){
    > TimerProc();
    > Sleep(N);//N はタイマーの周期(ms)
    > }
    > }
    >
    > のように実装すると、マルチメディアタイマーと大体同じ動作になり、
    > TimerProc() 内で使える API の制約がなくなります。
    素晴らしい情報のご提供、ありがとうございます!
    今後の開発の参考にさせてもらいます。

    > マルチスレッドアプリケーションの開発はとても難しいと私は思います。
    > デバッグ版では大丈夫でもリリースビルドだとダメになったり、PC に負荷
    > がかかっているときだけ発生したり、再現性のないバグに悩まされます。
    そうですね。
    私も今まで腰が引けていたのですが、今回は踏み込んで良かったと思います。
    自身の技術力も高まった気がします。
    今後、得体の知れないバグが出てくるかもしれないけど(苦笑)。

    > MSDN の記述を信じるなら、描画をマルチメディアタイマーで行うのは
    > おそらく危険だとは思うのですが、今までに特に安定性に関わる不具合報告が
    > ないなら現在の OS では大丈夫なのかもしれません。
    そうですね。
    今までの障害報告からすると、本件周りの不具合はないような気がします。
    http://musewiki.dip.jp/MuseWiki/index.php?Muse%C9%D4%B6%F1%B9%E7%B0%EC%CD%F7

    > PostMessage なり PostThreadMessage(これも使っちゃいけないっぽいですが)
    > でメッセージを受け取ったスレッド内で描画するなら問題ないと思います。
    そうなんだ。ならば大丈夫なのかも。

    > 負荷がかかったときの「演奏のもたり」はタイマーの周期を 4ms から 1ms
    > に変更するだけで結構改善されると思います。
    これも有効な情報です!
    必要な時が来たら、試してみようと思います。
    ちなみに、WindowsのMediaPlayerは4msのようだ、
    と書かれているサイトを最近見たことがあります。

    > あと、どうも Muse は timeGetTime を使ってないっぽいので、演奏時間の
    > 計測をどうやってるのかが気になります。もし GetTickCount を使用して
    > いるなら精度がかなり悪いので timeGetTime に置き換えた方が良いです。
    > QueryPerformanceCounter は呼び出しているようなので、そちらを使って
    > 演奏時間を計測しているならそれはそれで良いと思います。
    Museの演奏時間は、マルチメディアタイマーのロスを含んだ実際の演奏時間よりも、
    Museコーディングによる論理的、理想的な時間の方が有益であると考え、
    コーディングされたデータから数値計算で求めています。
    よって、timeGetTime, GetTickCount はもちろんのこと、
    QueryPerformanceCounter も使っていません。

    逆に、どうやってQueryPerformanceCounter を使っていると予測したのでしょうか?
    何かmuse.exeを分析するとわかるのかな・・・。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10325/Re[20]: Muse 新機構の提案……
■投稿者/ Kobarim -(2016/03/28(Mon) 03:34:54)

    元々の提案の趣旨から大分離れて来ている気がしますが…。(汗;

    > Museコーディングによる論理的、理想的な時間の方が有益であると考え、
    > コーディングされたデータから数値計算で求めています。

    論理的な時間は MIDI データ(Muse の場合は MUS データですね)から演算で求める
    のはもちろんと思いますが、実際の時刻が分からないと midiOut系 API をどの
    タイミングで送信すれば良いか分からないような…。

    マルチメディアタイマーの周期が 4ms だとして、

    最初の timeSetEvent 呼び出し時の時刻を 0 とし、その後のコールバック関数の
    呼び出し回数 x 4(ms) が現在時刻

    としているのかな。

    最初の timeSetEvent 呼び出し時の のGetTickCount の戻り値と、コールバック関数
    が呼ばれたときの GetTickCount の戻り値との差から現在時刻を計測しているのかと
    思っていました。もし GetTickCount を使っているなら timeGetTime に置き換えた
    方が良いというつもりで書きました。演奏や表示の「もたり」の原因にもなり得ますので。

    > 逆に、どうやってQueryPerformanceCounter を使っていると予測したのでしょうか?

    Dependency Walker というソフトを使うと、EXE や DLL が依存する DLL と、
    その DLL 内のどの関数をインポートしているかを見ることが出来ます。

    http://www.dependencywalker.com/

    Muse.exe は winmm.dll の timeGetTime をインポートしていませんが、
    kernerl32.dll の GetTickCount と QueryPerformanceCounter をインポートしています。

    QueryPerformanceCounter を Muse で明示的に使った覚えがないなら、
    C ランタイムライブラリが使ってるのでしょうね。

    > 可能なら MIDI 演奏ルーチンもスレッド化した方が出来ることの制約が
    > 少なくなるので望ましい気がします。

    これはもしかしたら余計な事を書いてしまったかもです。

    コールバック関数内で呼び出し可能な API を見る限り、マルチメディアタイマは
    MIDI 再生のためにあるようなものでしょうから、描画と WAVE 再生が別スレッド
    になったのであれば、演奏ルーチンは無理してスレッド化しなくても良いかもです。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10326/Re[21]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/28(Mon) 19:51:53)

    > 元々の提案の趣旨から大分離れて来ている気がしますが…。(汗;
    あはははっ(汗)
    でも、Kobarin(m?)さんとのやり取りはとても楽しいし、刺激的で勉強になります。

    > 最初の timeSetEvent 呼び出し時の のGetTickCount の戻り値と、コールバック関数
    > が呼ばれたときの GetTickCount の戻り値との差から現在時刻を計測しているのかと
    > 思っていました。もし GetTickCount を使っているなら timeGetTime に置き換えた
    > 方が良いというつもりで書きました。演奏や表示の「もたり」の原因にもなり得ますので。
    おお、そういう意図のご指摘だったんですか。
    親身のご指導、痛み入ります。
    Kobarinさんの、心根の優しさが伝わってきました。

    > Dependency Walker というソフトを使うと、EXE や DLL が依存する DLL と、
    > その DLL 内のどの関数をインポートしているかを見ることが出来ます。
    Dependencyは、せいぜいDLLまでかと思っていたのですが、
    確かに右上のフレームに関数も列挙されてますね。気づきませんでした。
    URLもありがとうございました。

    > QueryPerformanceCounter を Muse で明示的に使った覚えがないなら、
    > C ランタイムライブラリが使ってるのでしょうね。
    多分、そういうことだと思います。
    明示的に使っているか、間接的にコールされているかまでは、
    流石にDependencyでもわからないんですね。

    > > 可能なら MIDI 演奏ルーチンもスレッド化した方が出来ることの制約が
    > > 少なくなるので望ましい気がします。
    >
    > これはもしかしたら余計な事を書いてしまったかもです。
    了解いたしました。
    現在、極めてシンプルで見通しの良い作りになっているので、
    しばらくこのままで様子を見たいと思います。

    ちなみに、今回のマルチスレッドへの対応をきっかけに、
    部分的にデータ構造を見直したら、1KB減量しました。
    結局、マルチスレッド化で前バージョンから増えた容量は、1KBだけで済みそうです。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10327/Re[22]: Muse 新機構の提案……
■投稿者/ 開発者 -(2016/03/30(Wed) 22:36:21)

    > 結局、マルチスレッド化で前バージョンから増えた容量は、1KBだけで済みそうです。
    更なるダイエットに成功!
    マルチスレッド化しつつ、元の体型(334KB)に戻りました。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10301/Re[2]: Muse 新機構の提案……
■投稿者/ Αφροδιτη -(2016/03/22(Tue) 23:53:00)

    > 文法が少々複雑になるのが気になりますが、前向きに検討致します。

    力強いお言葉ありがとうございます。

    文法には特にこだわっているわけではありませんので、
    より良いとお思いの文法がありましたらそれで構いません。

    ...でも、現行のマクロを示す {} を継承するとすると、
    区別のために 1 文字は必要と思われるので、私が思いつくのは
    これ(最低 3 文字)が限界です。

    > 一番の問題は、実装です・・・。
    > 多分、両者共に現行のコンパイルシーケンスとデータ構造を
    > 大幅に手直しする必要がありそうです。

    すみません。
    要するに引数付マクロなので、きっと大変だろうと思います。
記事No.10296 のレス / 関連記事表示
削除チェック/

No.10542/Re[1]: Muse 新機構の提案……
■投稿者/ けーご -(2016/09/24(Sat) 20:57:47)

    {X74=+2 _16}10
    そっかこれエラーでしたっけ。。
記事No.10296 のレス / 関連記事表示
削除チェック/


パスワード/

(ダウンロード後、拡張子を .htm or .html にしてください)
[前の20件] [次の20件]

全ページ数 / [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65]

使い方 新規投稿 新着記事 ツリー表示 ワード検索 過去ログ 管理モード

- Child Tree -

Muse