Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (381-400 を表示) / 全ページ数 / [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.8427/Re[3]: NO TITLE
■投稿者/ 楠本 -(2012/11/12(Mon) 00:20:05)

    全然関係ないことで申し訳ないですが、
    画像だけを見ると、シークバーの下のテキストエリア部分に、
    三角印のようなものがあるのですが、元々ありましたっけ。
    MARKを使ったことがないもので。
    それに、シークバー内に、点線が見えるのは気のせいですか。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8428/Re[4]: NO TITLE
■投稿者/ taka -(2012/11/12(Mon) 19:26:05)

    シークバー内の点線というか「区切り」というか、私もありました。
    ただ、今起動させてみたら何もありませんでした…。

    何なんでしょ？

    > MARKを使ったことがないもので。

    「使って確認する」というのもひとつの手段ではあると思いますよ。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8430/Re[5]: NO TITLE
■投稿者/ waimi -(2012/11/12(Mon) 20:22:54)

    MARKを使ったデータで、シークバーの下あたりを右クリックすると、
    ▲が出ますよ。

    それと、
    Muse大賞2012のリンクＩＥでは出るのですが、
    Chromeでは表示されませんね。
    どうしてなんでしょ。OSはXPなんですが。

    うわ、２曲もエントリー頂いてどうしましょ。
    とりあえず、祝杯あげます。
    つの手段ではあると思いますよ。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8432/Re[6]: NO TITLE
■投稿者/ Αφροδιτη -(2012/11/12(Mon) 21:59:56)

記事No.8422 のレス / 関連記事表示
削除チェック/

No.8429/Re[4]: NO TITLE
■投稿者/ 開発者 -(2012/11/12(Mon) 20:14:36)

    楠本さん
    > 三角印のようなものがあるのですが、元々ありましたっけ。
    はい。元々あります。(開発後記 2000.5.10 をご覧下さい)

    詳細は、Readme.txtの3644行目あたり、
    ;======================================
    ; ( 3) シークバーの扱い方
    ;======================================
    を参照して下さい。


    楠本さん
    > それに、シークバー内に、点線が見えるのは気のせいですか。

    takaさん
    > シークバー内の点線というか「区切り」というか、私もありました。

    げっ！
    私は出会ったことがありません。
    今度、出現したらぜひスクリーンショットを採っておいてくださいね。
    よろしくお願いしまぁ〜すっ。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8451/Re[1]: NO TITLE
■投稿者/ 開発者 -(2012/11/17(Sat) 14:52:43)

    himajin925さん
    そなさん
    H.N.WPKIDSさん
    木下さん
    Elekenさん

    Museの不具合対応にご協力頂き、本当にありがとうございます。
    とても精緻で的確な情報、優れた洞察による推論など、
    有益なヒントを数多く頂き、心から感謝しております。
    大変厄介な対応作業となっていますが、お陰様で負荷が軽減しています。

    とはいうものの、まだ完全解決には至っておりません。orz
    私が懸念した「(1)Museの根深く基本的なバグ」モードに突入していています(苦笑)。

    というわけで今回は、対応途中の経過報告となります。
    皆さん申し訳ありません。

    ・WinXP環境を準備し、当方でも現象の再現に成功しました。

    ・ビルド環境VC6では再現せず、VS2005でのビルドでのみ出現します。
    　　→よって、皆さんが保有しているMuseでは、V6.20以降でないと発現しません。

    ・過去バージョンをVS2005でビルドし直し、V5.70β版での再現を確認しました。
    　　→ただし、何故か正式版のV5.70では発現しませんでした。
    　　　正式版で再現するのは、V5.81からです。

    ・対処療法ではありますが、症状を抑え込むバージョン(V6.27)はできています。
    　　→ただし、納得できないのでしばらくリリースを控えます。

    以上が現時点の概略です。
    詳細は、MuseWikiにアップしておきました。
    http://musewiki.dip.jp/MuseWiki/index.php?Muse%C9%D4%B6%F1%B9%E7%B0%EC%CD%F7#a6dc89ca

    また何かお気づきの点などありましたら、
    ご報告の程よろしくお願いします。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8452/Re[2]: NO TITLE
■投稿者/ himajin925 -(2012/11/17(Sat) 16:30:40)

    こんにちは

    SetWindowText なら、戻り値はどうでしょう？（ GetLastError は有用な情報は返してくれない？でしょうが）

    ＯＳ依存の現象のようで、大変そうです(^_^;)が、お待ちしてます
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8453/Re[3]: NO TITLE
■投稿者/ 開発者 -(2012/11/17(Sat) 17:55:07)

    himajin925さん

    > SetWindowText なら、戻り値はどうでしょう？
    なるほど！
    苦戦しているので、アドバイスが嬉しいです。

    で、早速試してみたのですが、結果は TRUE でした。orz
    再現性は確保できているので、科学的にアプローチできます。

    今は、履歴データによって現象が出たり出なかったりする件を追っていました。
    これもまた微妙な按配です。
    ほんの少し履歴データを変更すると、途端に現象が出なくなります。
    Museデータを、ちょっち変更すると出なくなるのと同じ印象です。
    まるで、ガラス細工のようです(苦笑)。

    で、再現する状態でプログラムを少しずつ削り取っていって、
    症状が出なくなる瞬間を把握しようと思って作業していたのですが、
    結局、MuseWikiの（対処）の項に記載したのと同じ結果に行き着きました。

    テキストエリアに表示する文字列のメモリ確保を１バイト増やすか、
    履歴データのパス文字列のメモリ確保を１バイト増やすか、
    どちらか一方でも行うと症状は出なくなります。

    アライメントの関係かとも思い、
    コンパイルの最適化オプションを外すなどもしてみたのですが、
    結果は同じでした。

    > ＯＳ依存の現象のようで、大変そうです(^_^;)が、お待ちしてます
    現時点の対処方法(１バイト余分にメモリ確保)は、今一つ釈然としないのですが、
    一応今まで追跡した内容からして、
    限りになく患部に近い所に薬を塗れているのではないか、
    と思い始めてきました。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8454/Re[4]: NO TITLE
■投稿者/ 開発者 -(2012/11/17(Sat) 18:26:51)

    正式バージョンではないのですが、
    対応を試みた V6.26a を以下にアップしました。
    http://www1.c3-net.ne.jp/kato/data/Muse.zip

    時間が許す時に、症状が改善しているかをお試し頂き、
    ご報告頂けると助かります。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8456/Re[4]: NO TITLE
■投稿者/ himajin925 -(2012/11/17(Sat) 23:37:04)

    「テキストエリアに表示する文字列」や「履歴データのパス文字列のメモリ」を使用する前に、NULL以外の使用されない値（MFCでは 0xCD だったか）で埋め尽くすなどしてから使用するとどうなるでしょう？期待される長さだけ転送されるでしょうか？
    コンパイラ、ライブラリのバグだったりして

    ・wsprintfAを使用しているのですね。http://msdn.microsoft.com/es-ar/library/ms647550 には（よく分かりませんが(^_^;)
    DO NOT USE
    と書いてあるような…セキュリティ関連だとは思うのですが
    ・「履歴データ」って何でしょう(^_^;)

    6.26a は、大丈夫のようです(^_^)
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8457/Re[5]: NO TITLE
■投稿者/ 開発者 -(2012/11/17(Sat) 23:59:15)

    > NULL以外の使用されない値（MFCでは 0xCD だったか）で埋め尽くす
    メモリアロケーションで、動的に必要な長さを確保しているため、
    埋めようが無いと思うのですが・・・。^^;

    > 期待される長さだけ転送されるでしょうか？
    デバッグのために仮に実施したのですが、本件の症状が出る状態でも、
    テキストエリアに送信している問題の文字列アドレスそのものを、
    別の手段で別のウィンドウに転送させるとちゃんと表示されるんです。orz

    > コンパイラ、ライブラリのバグだったりして
    あはははっ。それは無いと思います。
    もしそうだったら、とっくの昔に（なんせ2005年のコンパイラですから）、
    全世界にいる私より数段優れたプログラマー達が、炎上していると思います。

    > ・wsprintfAを使用しているのですね。
    確かに使っています。
    ただし、今回問題となる*MARKや*TEXTのパラメータ解析部には使用していません。

    > http://msdn.microsoft.com/es-ar/library/ms647550 には（よく分かりませんが(^_^;)
    確かに、“文字列lpOutはヌル終端であることが保証されていません。”のくだりが気になりますね。

    >・「履歴データ」って何でしょう(^_^;)
    履歴データは、muse.logというファイルです。
    初回のmuse利用後、muse.exeと同じフォルダに作成されます。
    次回のmuse起動の際、［履歴(H)］メニューに表示される内容が格納されています。
    muse.logをテキストエディタで編集すると、
    履歴とは異なり固定的な「お気に入り」のデータを階層的に管理できます。
    詳しくは、Readme.txtの4190行目あたり、
    ; (16) 履歴について
    をご覧下さい。

    > 6.26a は、大丈夫のようです(^_^)
    良かった。
    とりあえず安牌(アンパイ)確保、といった所です。
    もう安目で上がっちゃおうかなぁ〜(笑)。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8459/Re[6]: NO TITLE
■投稿者/ himajin925 -(2012/11/18(Sun) 09:19:43)

    たとえばこういうことを考えました
    char * pBuf = malloc(nLen);//または nLen は仮に大きめに。逆に、大きめだと再現しないかな？
    memset(pBuf, 0xcd, nLen);//デバッカから埋めても良いですが
    //編集、転送した→デバッガで pBuf 以下をダンプ。たとえば、NULLの後ろに何かが送られてるとか（NULLが２つとか）
    //release ビルドなら、簡単な16進ダンプを MessageBox で表示する、など
    可能性は薄くても、後ろの領域まで含めて、変化していないか確認してみたいな、と

    あるいは、まったく別に コンパイルのスレッドと再生・表示のスレッド（こう分かれているのか分かりませんし、どういう組み合わせかも？ですが）の追い越しとか…ちょうど30バイト（+1+1=32バイト）のとき、というのがますます分かりませんが…同期オブジェクトの仕様、挙動がＯＳによって違うなんてこと、ないかな
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8460/Re[7]: NO TITLE
■投稿者/ 開発者 -(2012/11/18(Sun) 10:11:15)

    > char * pBuf = malloc(nLen);//または nLen は仮に大きめに。大きめ、だと逆に再現しないかな？
    はい。大きめだと再現しません。(それが、V6.26a です)
    で、「きっちり」サイズでmallocしたとします。

    > memset(pBuf, 0xcd, nLen);//デバッカから埋めても良いですが
    わかりました。埋めたとします。

    > //編集、
    編集とはつまり、pBufに*MARKの文字列を「きっちり」セットすることですよね？
    ということは、上記の0xcdは上書きされてしまいます。

    > 転送した→デバッガで pBuf 以下をダンプ。たとえば、NULLの後ろに何かが送られてるとか（NULLが２つとか）
    サイズが「きっちり」しているので、終端NULLの後ろは管理外のメモリ空間です。
    Ｃ言語で開発しているので覗く事はできますが、それが如何なる値であっても不正ではないと思います。

    ・・・himajin925さんの実験イメージは、これであっていますか？
    私の理解にどこか誤解があるかもしれません。

    > コンパイルのスレッドと再生・表示のスレッド（こう分かれているのか分かりませんし、どういう組み合わせかも？ですが）の追い越しとか…
    演奏時のモタレを少なくするため、データのロード時点でほとんどの処理を済ませています。
    演奏時は、文字列をテキストエリアに転送しているだけです。

    それにしても、プログラムソースが目の前にない中で、
    これほどのアドバイスができるhimajin925さんの才能は素晴らしいです。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8461/Re[8]: NO TITLE
■投稿者/ himajin925 -(2012/11/18(Sun) 10:53:03)

    はい、そういうことです。
    （自分の失敗を元に）いろいろ想像しているだけです。申し訳ありません

    ライブラリの malloc でアライメント調整または領域長の切り上げが、ちょうど32バイトのときは行われない（想像です）、でも NULL は33バイト目以降に書かれているとか、そもそも書かれていないとか、他の何かも書かれている等を一応心配しておきたい、という感じです。
    なぜ XP だけ、というのはこれでは説明できませんが。
    （SetWindowText の戻り値云々と書いたのは、末尾の NULL がない（上書きされた等）→超長い文字列として設定しようとしたことになった、Set…で失敗、との想像でした）
    （malloc が、ＯＳ のメモリ管理を使用しているのかライブラリ内でヒープ領域から割り当てているのかも、想像ですが、ローカルなヒープ領域の中なら後続の領域も参照できるかもしれないので）
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8462/Re[9]: NO TITLE
■投稿者/ 開発者 -(2012/11/18(Sun) 12:01:33)

    > はい、そういうことです。
    > （自分の失敗を元に）いろいろ想像しているだけです。申し訳ありません
    とんでもありません。
    こちらこそ、いろいろアイディアを出して頂いて恐縮しています。

    一応あらゆる可能性を探るために、大きめに確保して終端NULL以降の値が、
    転送後に変化するかを確認してみました。（これだと症状が出ない状態ではありますが）

    結果は、埋めておいた0xcdに変化はありませんでした。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8463/Re[10]: NO TITLE
■投稿者/ Eleken -(2012/11/18(Sun) 14:59:19)

    個人的にはとても原因が気になります。
    以下は Ver. 6.26 で試した結果です。

    まず、デバッガ(Spy++)でウィンドウメッセージをトレースしたところ、問題が生じるタイミングではそもそも WM_SETTEXT メッセージが発行されていないようです。
    次に、同一タイミングでたくさんの 30 バイトの MARK コマンドを発行するようなデータ
    （ *MARK"MARK 01_______________________" の数字部分を 01 〜 32 まで変える）
    で試したところ、

    ・いくつかの MARK コマンドによる WM_SETTEXT が発行されない
    ・どの MARK コマンドが表示されないかは、リロードされるたび変わる
    ・逆に、リロードしない限りは、先頭から再生を繰り返しても、表示されない MARK コマンドの種類は変わらない

    という結果になりました。
    問題はリロード時に生じているのではないかというのが、私の推測です。

    ＃的外れなことを言っていたらごめんなさい。

    あと、本件とは関係無いのですが、例えば以下のデータで
    #A0| d4r @Y0 mf
    #A1| @Y1 _1
    フィンガー #A0 の Y0 が発行されないのは仕様でしょうか？
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8464/Re[11]: NO TITLE
■投稿者/ 開発者 -(2012/11/18(Sun) 16:41:41)

    Elekenさん

    ご指導、ありがとうございます。

    > 問題が生じるタイミングではそもそも WM_SETTEXT メッセージが発行されていないようです。
    > 問題はリロード時に生じているのではないかというのが、私の推測です。
    これは、かなり核心を突いているかもしれません。
    この仮説に基づいて、再度追跡してみます。

    ちなみに、
    > 以下は Ver. 6.26 で試した結果です。
    ということは、V6.26aでは、やはり症状は抑え込まれているということでしょうか？

    > ・逆に、リロードしない限りは、先頭から再生を繰り返しても、表示されない MARK コマンドの種類は変わらない
    もしかしたら、この状態でMIDIファイルのエクスポートをしたら、
    そのMIDIファイルも、当該のMARK文が欠落した状態かもしれませんね。
    Museは演奏データとMIDIエクスポートデータを一元化しているので、
    MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。

    > あと、本件とは関係無いのですが、例えば以下のデータで
    > #A0| d4r @Y0 mf
    > #A1| @Y1 _1
    > フィンガー #A0 の Y0 が発行されないのは仕様でしょうか？
    こちらは、別件のバグでした。
    こちらでもすぐに再現でき、そしてすぐに対応できました。
    V6.27をリリースする際は対応版をご提供できます。
    30バイトMARK文の件と比べたら、まるで天国でデバッグしているような気分でした(苦笑)。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8470/Re[12]: NO TITLE
■投稿者/ Eleken -(2012/11/18(Sun) 21:56:37)


    >>以下は Ver. 6.26 で試した結果です。
    > ということは、V6.26aでは、やはり症状は抑え込まれているということでしょうか？
    そうです。今のところ、V6.26a では症状は生じていません。
    ちなみに、V6.26 を互換モードで起動した場合では、Windows 2000 以外のモードでは症状は生じません。

    >>・逆に、リロードしない限りは、先頭から再生を繰り返しても、表示されない MARK コマンドの種類は変わらない
    > もしかしたら、この状態でMIDIファイルのエクスポートをしたら、
    > そのMIDIファイルも、当該のMARK文が欠落した状態かもしれませんね。
    > Museは演奏データとMIDIエクスポートデータを一元化しているので、
    > MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。

    なるほど！早速試してみました。
    症状が出た状態で MIDI エクスポートをしても、正常なデータが出力されるのみです。
    ということは、メモリ上のデータは全て正常？？
    OS 依存ということも考えると、私の考えていたより問題の根は深いのでしょうか・・・

    > こちらは、別件のバグでした。
    > V6.27をリリースする際は対応版をご提供できます。
    やはり、そうでしたか。
    早速のご対応ありがとうございます。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8472/Re[13]: NO TITLE
■投稿者/ 開発者 -(2012/11/18(Sun) 22:19:49)

    Elekenさん
    > 症状が出た状態で MIDI エクスポートをしても、正常なデータが出力されるのみです。
    > ということは、メモリ上のデータは全て正常？？
    > OS 依存ということも考えると、私の考えていたより問題の根は深いのでしょうか・・・
    多分、メモリ上のデータは全て正常だと思います。
    しかし、どこかでMuseがデータ以外のメモリを壊していることが考えられます。
    症状はMARK表示の演奏時に出ますが、Elekenさんが推察されているとおり、
    リロード（あるいはロード後の後処理）で既に破壊工作は完了しているのではないかと(苦笑)。

    ちなみに、
    > ではそもそも WM_SETTEXT メッセージが発行されていないようです
    の件を追試してみましたので、ご報告します。
    SetWindowText()をコールしている箇所で、デバッグライトにて
    ・SetWindowText()の戻り値
    ・SetWindowText()で送信している文字列内容
    を確認してみました。
    なんと面妖なことに、Spy++でメッセージが送られていない状況でも、
    ・戻り値は、TRUE
    ・文字列は正常な３０文字
    が確認されました。
    つまりデータは壊れていない、ということを裏付けていると思います。

    Elekenさんのご指摘の通り、演奏時点での症状から追跡するのを止めて、
    データロード時点の不具合を追跡してみようと思います。
    [8450]でElekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。

    *HEAD"This is a dummy." _1
    *MARK"123456789012345678901234567890" _4
    %
    {{#A0 m4r}{#B0 m4r}{#D0 m4r}}
    {{#A0 m4r}{#B0 m4r}{#D0 m4r}}
    {{#A0 m4r}{#B0 m4r}{#D0 m4r}}
    ・
    ・
    ・
    (↓この行を 2000 回繰り返す)

    です。
    結局、属性関係は無くても症状が出ますので、
    譜面モニタの属性表示はシロだったみたいです。
    また、マクロの繰返し数で2000回指定をすると症状が出ません。
    どうも、無名マクロの処理にバグが混入している気がしてきました。
    今度こそ、犯人の潜むアジトを特定できるといいのですが・・・。
記事No.8422 のレス / 関連記事表示
削除チェック/

No.8475/Re[14]: NO TITLE
■投稿者/ 開発者 -(2012/11/18(Sun) 23:33:13)

    経過報告です。
    > [8450]でElekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。
    更に、純度を高めることができました。

    *HEAD"This is a dummy." _1
    *MARK"123456789012345678901234567890" _4
    %
    #A0
    { d }
    { d }
    { d }
    　・
    　・
    　・
    (↑この行が多い程、再現確率が高まる。10,000行あれば楽勝で出現）

    だいぶ敵陣に近づいてきたような気がします。
    ただ、無名マクロの処理はとっても複雑なので、気が重いです。(苦笑)
記事No.8422 のレス / 関連記事表示
削除チェック/

パスワード/

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