Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (601-620 を表示) / 全ページ数 / [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.8690/Re[10]: ★★★V6.33公開
■投稿者/ ねこしん -(2013/02/11(Mon) 19:45:41)

    >>が、Ctrl+→で飛んだときにメンバー情報のバリエーション番号が消えるのと、メイン画面の時刻表示部分が白抜きになってしまいます。
    > う〜む。またしてもこちらでは再現しませんorz
    > ただこの症状は、多分高い再現性があると思います。
    > 可能なら、メールにてそのデータ送付と再現方法の伝授をしてもらえますか？
    これは、バリエーションを使ってるデータだと全部で起きるっぽいです。
    自分の吹奏楽のデータ（スケルツォと梁塵秘抄がわかりやすいかと）のアルトサックスにバリエーションを使っているので、自分はそれで確認しました。
    再生している、していないにかかわらず起きるんですが…
    音源側には、しっかりとバリエーションも送信されてるようです。


    > 出現するのは、テスト用(museS2.exe)のみですか？
    > また、今回のシーク操作をせず、起動直後で出ますか？
    はい、テスト用（前回のテスト用でもそうだったきが）のみで、起動直後になります。

    追加
    テスト版で、一回落ちました。
    自分の吹奏楽のためのスケルツォで確認しました。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8692/Re[11]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/11(Mon) 20:57:22)

    > ねこしんさん >が、Ctrl+→で飛んだときにメンバー情報のバリエーション番号が消えるのと、メイン画面の時刻表示部分が白抜きになってしまいます。

    > 開発者> う〜む。またしてもこちらでは再現しませんorz
    > 開発者> ただこの症状は、多分高い再現性があると思います。
    > 開発者> 可能なら、メールにてそのデータ送付と再現方法の伝授をしてもらえますか？

    > これは、バリエーションを使ってるデータだと全部で起きるっぽいです。
    > 自分の吹奏楽のデータ（スケルツォと梁塵秘抄がわかりやすいかと）のアルトサックスにバリエーションを使っているので、自分はそれで確認しました。
    > 再生している、していないにかかわらず起きるんですが…
    > 音源側には、しっかりとバリエーションも送信されてるようです。
    ●前者「バリエーション番号が消える」に関しては、梁塵秘抄で確認しました。
    Xコマンドを使っているんですね。
    実はXコマンドを使用すると、各種ダイアログ情報の整合性を保証できないのが今の仕様です。
    Readme.txt(３０５４行目あたり)
    ;　(注)“X”指定の機能は、今までのメンバー属性“PVRQ……”などを完全に包含し
    ;　　　ています。しかし“X”指定での記述は「フィンガー情報」や「メンバー情報」
    ;　　　「譜面モニタ属性表示」などに反映されません。“X”指定は、音源の性能を
    ;　　　より引き出したい方のための一種裏技的な機能であることをご承知おき下さい。
    ;

    しかし、[Ctrl]を併用しないシークならちゃんと反映してますね。
    なんとも、統一感のない動き・・・(苦笑)。
    バグではないのですが、ちょっと対処に挑戦してみます（って、この混乱状態の中で別の改造をして大丈夫だろうか・・・）

    ●後者「メイン画面の時刻表示部分が白抜き」は、やはり再現しませんでした。
    こちらは、もしかしたら今回のシークによって落ちる症状と関係があるかもしれません。


    > > 出現するのは、テスト用(museS2.exe)のみですか？
    > > また、今回のシーク操作をせず、起動直後で出ますか？
    > はい、テスト用（前回のテスト用でもそうだったきが）のみで、起動直後になります。
    ●ディスプレイドライバが落ちる件
    そうですか。
    では、今回のシーク操作とは関係なさそうですね。
    museS1.exe
    museS2.exe
    の両方で起こったとの事ですが、逆にV6.33 やそれ以前のMuseでは起きないのでしょうか？

    > 追加
    > テスト版で、一回落ちました。
    > 自分の吹奏楽のためのスケルツォで確認しました。
    了解しました。
    原因を特定できていないので、もし落ちないとしても治った気がしていませんでした。
    継続調査します。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8691/Re[8]: ★★★V6.33公開
■投稿者/ 楠本 -(2013/02/11(Mon) 20:42:00)

    仕事から帰ってきたのですが、開発者様の方で再現できて良かったです。
    > 一応、しばらく動かしてみましたが、今のところこちらでは落ちていません。
    > 再現頻度が低いため、これで完治したことを確約できないのですが・・・。
    >
    > で、以下にアップしましたので、もしお時間のある時に試してもらえますか？
    早速試してみました。
    が、結果は残念なことに、すぐに落ちてしまいました。
    一応、画像を載せておきます。
    http://sinfonia.6.ql.bz/test/test3.png
    それと、[8685]の、
    >３番目は実施していません。
    >もしそのような動きをしたとしたら、これはまた別の障害である可能性があります
    は、再現できましたでしょうか。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8693/Re[9]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/11(Mon) 22:47:00)

    ねこしんさん
    楠本さん

    ●ねこしんさんも、楠本さんも、museS2.exeで落ちてしまったこと、了解です。
    その後、もしかしたら核心部分かもしれない所に気づきました。
    そこに手を入れたバージョンを作ってみました。(museS3.exe)
    （今一自信はないのですが・・・）

    お手数ですが、もう一度試してもらえますか？
    http://www1.c3-net.ne.jp/kato/data/smuse.zip

    ●「バリエーション番号が消える」件にも対応しています。
    Xコマンドの[Cntl]シークでも、メンバー情報に反映すると思います。
    ・・・今回のバグ追跡に比べると、なんとも楽しい作業でした(苦笑)。

    ●小刻みな［→］入力で曲尾まで達した際、曲頭に巻き戻す件。
    > それと、[8685]の、
    > >３番目は実施していません。
    > >もしそのような動きをしたとしたら、これはまた別の障害である可能性があります
    > は、再現できましたでしょうか。
    再現できました。
    ご報告ありがとうございました！
    なかなか気づきにくい部分なので、本当に助かりました。
    museS3.exeで、これも対処済みです。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8694/Re[10]: ★★★V6.33公開
■投稿者/ 楠本 -(2013/02/11(Mon) 23:37:36)

    開発者様、ごめんなさい。報告が間違っていました。
    以前、V6.29は落ないと報告しましたが、
    今回のテスト版を試すと落ちにくい感じはしましたが、結果的には落ち、
    以前試したV6.29と似ている感じがしたので、もしや、V6.29でも・・・と思い、再度試してみたところ、
    V6.29でも落ちにくいが、結果的には落ちました。画像を載せておきます。
    http://sinfonia.6.ql.bz/test/test5.png
    ＰＣのせいなのか、なんなのか、分からなくなりました。
    混乱させて済みません。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8695/Re[11]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/11(Mon) 23:52:36)

    楠本さん
    > 以前、V6.29は落ないと報告しましたが、
    > 今回のテスト版を試すと落ちにくい感じはしましたが、結果的には落ち、
    了解いたしました。
    むしろ、今回(V6.3x)の大量の改訂のどこかにデグレードがあったわけではなく、
    実は、初版の頃から生き長らえていたバグなのかもしれませんね。
    演奏させたままでのキーボードシークは普段あまり使いませんので
    発生の機会が無かっただけの様な気もします。

    私としては、過去からの潜在バグであった方が気が楽です。
    過去に遡るほど、プログラムが単純な部分ですので。
    こうなると、どこまで遡れば症状が出なくなるのかを知りたくなります。

    > ＰＣのせいなのか、なんなのか、分からなくなりました。
    いいえ、ＰＣのせいではありません。Museのバグのせいです。

    > 混乱させて済みません。
    困窮していますが(苦笑)、混乱はしていませんのでご安心下さい。
    今後とも、何かお気づきのことがあれば、ドシドシお寄せ下さい。
    間違えや勘違いは、すぐに訂正していただければ結構です。
    これからも、よろしくお願いします。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8696/Re[10]: ★★★V6.33公開
■投稿者/ ねこしん -(2013/02/12(Tue) 17:16:47)

    > お手数ですが、もう一度試してもらえますか？
    > http://www1.c3-net.ne.jp/kato/data/smuse.zip
    うーん…まだ落ちてしまいますねえ。

    そもそもこれWin7でしか起きないとかないですかね？
    楠本さんもWin7ユーザーのようですし。

    > ●「バリエーション番号が消える」件にも対応しています。
    > Xコマンドの[Cntl]シークでも、メンバー情報に反映すると思います。
    > ・・・今回のバグ追跡に比べると、なんとも楽しい作業でした(苦笑)。
    こっちは大丈夫でした。

    あと、ディスプレイドライバが落ちる件ですが、同じ状況にしたら、V6.33でも落ちました。
    これはなんか自分の環境だけな気がします。
    たぶん、"ダウンロード"フォルダから自分のアカウントのフォルダにうつるときに、何かしらの表示関係の不具合が起きるっぽいです。
    システムのデザインとかいじると出ないので、対応できそうです。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8697/Re[11]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/12(Tue) 20:16:54)

    >>お手数ですが、もう一度試してもらえますか？
    >>http://www1.c3-net.ne.jp/kato/data/smuse.zip
    > うーん…まだ落ちてしまいますねえ。
    了解です。
    粘り強く、発想が枯渇するまでがんばってみようと思います。
    また、いくつか手を入れてみました。
    http://www1.c3-net.ne.jp/kato/data/smuse4.zip

    私の環境ではだんだん落ちなくなってきました。
    というか、前回の版(museS3.exe)も、今回の版(museS4.exe)も落ちていません。orz
    ますます、改善しにくくなってます(苦笑)。

    再現性が低いと、
    一回でも症状が出れば治っていない事を証明できますが、
    症状が出ないからと言って完治したことを立証できない、
    というなんとも勝ち目のない戦いをしている様で辛いですね。

    > そもそもこれWin7でしか起きないとかないですかね？
    > 楠本さんもWin7ユーザーのようですし。
    そうかもしれませんね。
    ただ、ＯＳ差を疑うのは最後の最後にしたいです。

    >>●「バリエーション番号が消える」件にも対応しています。
    >>Xコマンドの[Cntl]シークでも、メンバー情報に反映すると思います。
    >>・・・今回のバグ追跡に比べると、なんとも楽しい作業でした(苦笑)。
    > こっちは大丈夫でした。
    良かったです。
    派生的に機能強化しちゃいましたね(笑)。

    > あと、ディスプレイドライバが落ちる件ですが、同じ状況にしたら、V6.33でも落ちました。
    > これはなんか自分の環境だけな気がします。
    > たぶん、"ダウンロード"フォルダから自分のアカウントのフォルダにうつるときに、何かしらの表示関係の不具合が起きるっぽいです。
    > システムのデザインとかいじると出ないので、対応できそうです。
    こちらも了解です。
    ドライバを破壊するような高度なハッカー技術を、私は
    持ち合わせていませんので、多分Museとは関係がないかもしれませんね。

    では、museS4.exe の結果、お待ちしております。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8698/Re[12]: ★★★V6.33公開
■投稿者/ るう -(2013/02/12(Tue) 21:45:45)

    明日朝早くから出張なので、試しに手元のV6.30を落としてみました。
    新幹線乗ってる間の暇潰しに逆アセンブルとかしながら遊んでみます。

    ntdll.dll 7712224D inc dword ptr [eax+14h] ; ここでeax==0
    ntdll.dll 7712215c()
    winmm.dll 72b6e6d4()
    winmm.dll 72b6f172()
    muse.exe 0041605c()
    winmm.dll 72b53af0()
    winmm.dll 72b5a535()
    winmm.dll 72b5a434()
    kernel32.dll 7566ed6c()
    ntdll.dll 7715377b()
    ntdll.dll 7715374e()
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8699/Re[13]: ★★★V6.33公開
■投稿者/ るう -(2013/02/12(Tue) 22:49:26)

    ……winmm.dllからのコールバック関数内のmidiOutShortMsg()？
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8701/Re[14]: ★★★V6.33公開
■投稿者/ るう -(2013/02/12(Tue) 23:46:24)

    何度もすみません；；

    > ……winmm.dllからのコールバック関数内のmidiOutShortMsg()？
    どうやら、次のような呼び出しが発生した後、内部のCriticalSectionでコケているようでした。
    midiOutShortMsg(hmo, 0x003c4d9d);

    第二引数は何の変哲もないノートオンですので問題なしとして、
    hmoの値が古い値をとっていたり、どこかで値が破壊されていたり、
    などという可能性はないでしょうか？
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8702/Re[15]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/13(Wed) 01:34:11)

    るうさん、お久しぶりです。
    この追跡劇に、るうさんが参画して頂けるなんて心強いです。

    > hmoの値が古い値をとっていたり、どこかで値が破壊されていたり、
    > などという可能性はないでしょうか？
    ご存知だとは思いますが、第一引数のhmoは、MIDI音源をオープンした時のハンドルです。
    オープン関数の戻り値で受けた後、プログラム上では一切いじっていません。

    今回の局面で発行されるmidiOutShortMsg()は、２つのフェーズがあります。
    ひとつは、演奏を開始する前にシーク結果としてその時点までの様々なコントロールを吐き出す部分。
    いまひとつは、演奏を開始して刻々とデータを吐き出す部分です。

    るうさんが解析してくれた結果を見ると、
    第二引数がノートオンであるということから、後者の処理であると推論できます。
    何故なら、前者のシーク結果の吐き出し処理では、音を一切出さないからです。

    > どうやら、次のような呼び出しが発生した後、内部のCriticalSectionでコケているようでした。
    > midiOutShortMsg(hmo, 0x003c4d9d);
    “内部のCriticalSectionでコケている”ということは、
    midiOutShortMsg()の中でコケているということですか？
    もしかしたら、midiOutShortMsg()の次で落ちているということは考えられませんか？

    今までのコケた操作を振り返ると［→］を押下したとたんに落ちたような記憶があります。
    ［→］を離すと演奏を開始し、［→］を押下すると演奏を停止してシークを始めます。
    上記のノートオンは、演奏停止直前の最後のノートオンだった、
    という推理は成り立つでしょうか？
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8703/Re[16]: ★★★V6.33公開
■投稿者/ るう -(2013/02/13(Wed) 07:18:26)

    すみません、クリティカルセクション云々というのは間違いだったようです。
    （スタックを一行遡っていた際、どうもスタックポインタの位置がずれて変なところに飛んだようでした）

    VSに関数名表示オプションがあることが判明したので使ってみたところ、以下のようになっています。
    落ちにくくなったはずのMuseS4でも、依然それまでとまったく同じ状態で発生していることがわかるかと思います。
    http://www1.axfc.net/uploader/so/2791522.png (Muse630)
    http://www1.axfc.net/uploader/so/2791525.png (MuseS4)

    やはり、midiOutShortMsg()の中でコケています……しかもメインスレッドとは別のスレッドで。
    もし、
    > オープン関数の戻り値で受けた後、プログラム上では一切いじっていません。
    ということであれば、もしかすると最適化の影響で、メインスレッド上でのhmoの変更がレジスターにキャッシュされたままで反映されて残っている、ということはあるかもしれません。
    （本当にそれだけが原因の場合、hmoの変数宣言にvolatileキーワードをくっつけてみるだけで治るはずです）

    とにかく、デバイスオープンのタイミングとmidiOutShortMsg()のタイミングを順に書き出してみないことには、それだけが真因かどうかは定かではありませんが……。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8704/Re[17]: ★★★V6.33公開
■投稿者/ るう -(2013/02/13(Wed) 07:22:58)

    > レジスターにキャッシュされたままで反映されて残っている
    メモリーに反映されずに、の間違いですね……。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8705/Re[17]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/13(Wed) 20:47:40)

    > やはり、midiOutShortMsg()の中でコケています。……しかもメインスレッドとは別のスレッドで。
    なるほど。
    流石るうさんですね。
    症状が発生するポイントが明確になりました。
    また、常に発生する箇所が一致していること、
    引き金を引くのは、MIDI音源のハンドルであることもわかりました。
    ありがとうございました。

    ただ、
    midiOutShortMsg()から先は、Museから見ると音源の世界なので、
    症状の発生ポイントから問題解決の糸口を探すのは難しそうです。
    どこで、MIDI音源のハンドルが不正な状態になっているかの究明が、
    これからの課題ですね。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8706/Re[18]: ★★★V6.33公開
■投稿者/ るう -(2013/02/13(Wed) 23:40:58)

    その後の調査の結果、「hmoがレジスター上からメモリー上にコピーされていない」ということはありえない、ということは判明しました。
    ですので可能性としては、

    (1) midiOutOpen()が完了する前に演奏を開始してしまうケースがある
    (2) hmoが、バッファオーバーフロー等の影響で破壊される

    の2つに絞られたことになると思います。

    このうち(2)が原因かどうかは、デバッガでhmoの変更を監視することで確認できるはずなのですが、ここで1つ問題があります。
    というのも、正常系でもmidiOutOpen()がガンガン呼ばれまくるので、その度にブレークしていたらキリがない（笑）

    そこで試しに、midiOutOpen()の呼び出し回数を減らしたバージョンを用意していただきたいのですが、可能でしょうか？
    大きめの変更にはなりますが、具体的には次のようになります：

    前）
    ・midiOutOpen() … 毎演奏開始時
    ・midiOutClose() … 毎演奏終了時

    後）
    ・midiOutOpen() … 起動後＆MIDIデバイス変更後の初回の演奏開始時
    ・midiOutClose() … MIDIデバイス変更時＆アプリケーション終了時

    ※ 実は、このような提案をする理由は上記のような理由だけではなく、別の理由もあります。
    というのも、VirtualMIDISynthで重たいサウンドフォントを使おうとすると、ちょっと停止してから再開するだけで毎回数秒待たされる、という事がありまして、かなーり嫌気が差しているのです……。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8707/Re[19]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/14(Thu) 00:16:51)

    るうさんの“天才”に触れた気がしています。
    実は、昨日から今に至るまで、楠本さんとある戦略に基づく原因特定に臨んでいました。

    V6.27までは症状が出ないが、V6.28から症状が出るという事実を、
    楠本さんが発見してくれたので、それを足掛かりに、
    V6.28を少しずつV6.27に巻き戻しコーディングし、
    症状が出なくなる瞬間を捉えようと考えたのです。

    そしてたった今、原因が特定されました。
    まさに、
    > (1) midiOutOpen()が完了する前に演奏を開始してしまうケースがある
    でした。
    演奏開始の処理に入り、シークのための前準備にもたついているうちに、
    次の演奏停止命令が入ってしまい、そこでhmoがNULLになってしまうのです。

    原因が特定できたので、これからどの様な対処をするか検討に入ります。
    少々厄介かもしれませんが、真因がつかめなかった今までに比べると
    まるで極楽気分です＼(^o^)／

    > そこで試しに、midiOutOpen()の呼び出し回数を減らしたバージョンを用意していただきたいのですが、可能でしょうか？
    >大きめの変更にはなりますが、具体的には次のようになります：
    > ・midiOutOpen() … 起動後＆MIDIデバイス変更後の初回の演奏開始時
    > ・midiOutClose() … MIDIデバイス変更時＆アプリケーション終了時
    これは、まさに今回の症状を完全に封じ込める抜本的な対処だと思います。

    ただ「演奏を停止したらMIDI音源もクローズする」
    というのは、Muse初版の頃からの私の“こだわり”なんです。
    もう少し踏ん張らせて下さい(笑)。
    もちろん、るうさんの主張は“オープンしっぱなし”と“都度クローズ”の２つを用意して欲しいという
    要求であることは承知しています。やるならmuse.iniでしょうね。

    > 重たいサウンドフォントを使おうとすると、ちょっと停止してから再開するだけで毎回数秒待たされる
    確かに・・・(苦笑)。
    この件もあるので、“オープンしっぱなしモード”というるうさんの要求は、検討リストに入れておきますね。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8708/Re[20]: ★★★V6.33公開
■投稿者/ るう -(2013/02/14(Thu) 01:21:36)

    お力になれたかどうかはわかりませんが、ひとまず、原因究明おめでとうございます。
    といっても、重要なのはここからになりますね。

    > 演奏開始の処理に入り、シークのための前準備にもたついているうちに、
    > 次の演奏停止命令が入ってしまい、そこでhmoがNULLになってしまうのです。
    これでは、hmoに何らかの値が入っている、とする調査結果と矛盾します。
    細かいところですが、正確には「クローズ後、hmoにNULLが設定される前に演奏処理を行っている」ではないかと考えます。
    だとすれば、この現象は本質的にはシークとは関係なく、演奏完了以外の全ての演奏中断処理で発生する危険性があると思うのですが、いかがでしょうか？
    (単に、レアケースなので演奏完了が大量に連続するシーク時にしか発見されなかった、というだけで)

    > “オープンしっぱなし”と“都度クローズ”の２つを用意して欲しいという
    > 要求であることは承知しています。やるならmuse.iniでしょうね。
    「オープンしっぱなし」でなければならないケースがあることは申し上げた通りですが、
    では、「都度クローズ」でなければならないケースというのは、どのような時なのでしょうか？
    もし、同時に複数のハンドルからアクセスすることを許さないデバイスを想定しているのであれば、
    muse.iniで一括指定するのではなく、デバイス単位で選択ができねばならないように思えます。

    少々邪道ですが、演奏中止後すぐに再開するような操作である場合に限り、クローズと再オープンを省略する、みたいなのもアリではないかな、と。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8709/Re[21]: ★★★V6.33公開
■投稿者/ 開発者 -(2013/02/14(Thu) 18:51:14)

    るうさんとの知的な会話が楽しいです。
    > お力になれたかどうかはわかりませんが、ひとまず、原因究明おめでとうございます。
    今回の症状は出現頻度の低さと再現性の不安定さから、真因特定の決め手が難しかったのですが、
    るうさんの解析結果と楠本さんとの実験結果を照らし合わせる事で、
    それが確度の高い結論であると裏付ける事ができました。
    心から感謝しています。

    > といっても、重要なのはここからになりますね。
    そうですね。
    どのような対処が最もエレガントでシンプルで、そして信頼性が高いのか、
    というのが評価基準になると思います。

    > > 演奏開始の処理に入り、シークのための前準備にもたついているうちに、
    > > 次の演奏停止命令が入ってしまい、そこでhmoがNULLになってしまうのです。
    > これでは、hmoに何らかの値が入っている、とする調査結果と矛盾します。
    その通りでした。前回の分析記述は間違えていました。
    正確に言うと、
    > (1) midiOutOpen()が完了する前に演奏を開始してしまうケースがある
    > (2) hmoが、バッファオーバーフロー等の影響で破壊される
    > の2つに絞られたことになると思います。
    のどちらでもありませんでした。

    > だとすれば、この現象は本質的にはシークとは関係なく、演奏完了以外の全ての演奏中断処理で発生する危険性があると思うのですが、いかがでしょうか？
    これもその通りだと思います。

    > 「オープンしっぱなし」でなければならないケースがあることは申し上げた通りですが、
    > では、「都度クローズ」でなければならないケースというのは、どのような時なのでしょうか？
    一言で言うと主観というか、美観というか、単に私の好みと言うだけなんですが・・・(苦笑)。

    今のＯＳやWindowマルチメディア環境はもっと柔軟になっているようですが、
    初版Museを開発していた当時の環境では、１つのアプリケーションがMIDI音源をオープンすると
    それを完全に占有してしまい、他のアプリケーションは同一音源をオープンできない状況でした。
    にもかかわらずほとんどのMIDI関係のソフトは「起動時にオープンし、終了するまでオープンしっぱなし」
    という方式を採用していました。よって、MIDI関係のいろいろなソフトを同時に起動できなかったのです。
    「美しくない」と私は思いました。そして自分の作るソフトはそうありたくない、と思いました。

    その想いが今でも続いています。
    しかし先程も触れましたが、今では音源占有の心配はぜんぜん無いみたいですね。
    （ハード音源でも大丈夫かどうかはわかりませんが）
    というわけで、私のこだわりは既に時代錯誤に陥っているのかもしれません。

    あとは、以下の様にして遊ぶ時、多少有利かな、と。
    http://www1.c3-net.ne.jp/kato/data/muses.png

    > 少々邪道ですが、演奏中止後すぐに再開するような操作である場合に限り、クローズと再オープンを省略する、
    > みたいなのもアリではないかな、と。
    今回の不具合に対処するには「オープン」と「クローズ」に加えて、
    「タイマー起動」と「タイマー停止」という事象も絡めて考察する必要があるんです。

    そういう意味でも「オープンしっぱなし」方式なら、事は単純なんですが。
    いや、待てよ。
    結局、演奏している最中に音源(V)の切替をした場合、全く同じ対処が必要なのか・・・。
記事No.8665 のレス / 関連記事表示
削除チェック/

No.8700/Re[12]: ★★★V6.33公開
■投稿者/ 楠本 -(2013/02/12(Tue) 23:44:47)

    経過報告です。確定ではありません。参考になるかどうか分かりませんが、
    幾つかの過去のバージョンを試していて、無いバージョンは開発者様より取り寄せて試してみた結果、あくまでも抜粋ですが、
    現段階では、V6.27までは落ちず、V6.28以降より落ちる結果となっています。
    今は、V6.27が本当に落ないか、集中的に試しています。
    一応、開発者様には報告しました。
記事No.8665 のレス / 関連記事表示
削除チェック/

パスワード/

(ダウンロード後、拡張子を .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