対応状況(2013.05.11)†V6.41にて対応済み。(原因)V6.40の開発において、譜面モニタの属性表示のための構築処理を一部見直したが、その際に%記号が1つのみであることを前提に処理を組んでしまった。(対処)最後の%記号を検出し、それのみを採用するよう改修した。指定した場合、*STOPコマンドで一時停止せず通過する仕様に変更した。これにより、バッチ処理で複数のMuseデータの連続演奏が可能となった。いった不正な表示になる。対応状況(2013.03.08)†V6.37にて対応済み。(原因)V6.31において、ドラムのボタンリソースを効率化し、テキストリソースによる随時書き直しに改めた際に、ドラムセットの変更においてもボタンリソースを変更させないことによる影響の考慮不足で埋め込んでしまったバグ。EthnicとAsiaでアサインされないo1dが無効化された際、タブストップ可能なボタンが存在しない状況に陥っていた。(対処)EthnicとAsiaが選択された際o1d+のボタンにタブストップ属性を割り付け、他の選択が起こった時にそれを解除するという処理を追加した。障害報告(2013.03.08)†ドラムの試聴でEthnicあるいはAsiaを選択し、タブでの移動を行う際、o1列にフォーカスが移動しない。対応状況(2013.02.24)†V6.36にて対応済み。(原因)V6.35における、メンバー情報の警告音抑止の対処で、ダミーのエディットコントロールを配置したが、それが矢印キーの読み上げを誘発した。(対処)ダミーのコントロール配置を取り止め、ディスパッチループ内でメンバー情報のみ従来の判断処理を行うように改修した。(補足)今回の障害対応とは関係が無いが、V6.36にて以下の機能強化も実施した。障害報告(2013.02.23)†メンバー情報ダイアログでキー押下時に警告音は鳴らなくなったのですが、スクリーンリーダーが、現在のフォーカス位置をReadOnly?のエディット領域として認識しているようで...キーを押すと、そういうことを毎回読み上げられてしまいます。対応状況(2013.02.21)†V6.35にて対応済み。(原因)V6.28で、メイン関数のディスパッチ処理をMicrosoftが提唱する効率的な方式に変更したが、その影響で音が出るようになった。ダイアログ上に文字入力を受け付けるコントロールが存在しないために、問合せ関数、IsDialogMessage?()の中で発音している模様。本症状は、Win7では発現しない。(対処)メンバー情報ダイアログに、読取り専用、かつ大きさゼロのエディットコントロールを、ダミーで配置することで問題を回避した。XPV6.29の頃から出るようにはなっていました。V6.27では鳴りません。対応状況(2013.02.16)†V6.34にて対応済み。(原因)Museが演奏時に駆動するタイマーコールバックと、そのタイマーの停止は別のスレッドでの実行である。よってコールバックが実施されている最中にタイマー停止が起こる可能性があるが、その対処を行っていなかった。タイマー停止直後に音源のクローズを実施しており、結果としてクローズ処理と発音処理が競合してハングしたと思われる。再現性は極めて低く、再現させるためには以下のような状況が必要であった。・演奏開始と停止が短周期かつ高頻度に繰り返される(左右カーソルキーの高速な押下/開放による断続的シーク操作など)・演奏処理が充分に重い(多量のデータ、譜面モニタ、サウンドフォントなどの高負荷状態)・タイマー停止から音源クローズまでが速やかに処理される(性能の良いPC。Win7搭載のPCは往々にしてパフォーマンスが良い)(経緯)V6.27からV6.28にバージョンアップする際、高速化のために演奏停止の処理に手を加えた。従来、音源のクローズ命令を確実に実施するために適度なインターバルを与えていたが、それが無くとも安定して音源処理が完了することを確認したため、V6.28でそのインターバルを取り払った。このインターバルは、本件で発現したタイプの不具合を抑止するという別の意味も偶然持ち合わせていた。結果として、タイマー停止後に残存するタイマーコールバック内の演奏処理をすべて完了させる余裕を生み出していた。V6.28でその余裕時間を取り払ったため、今回の症状が発生する事となった。強制的にそのような状況を作り上げた実験では、midiOutShortMsg?()は、MMSYSERR_INVALHANDLE(指定されたデバイスハンドルが無効)を返却するのみで、ハングすることは無かった。この挙動は、音源ハンドルをNULLにしても、またランダムで意味のないハンドル値を指定しても同様であった。音源管理モジュールの深部においてクローズ処理と発音処理の競合が起きた際にハングすると推測している。よって、この競合状態を回避することが、本質的な解決につながると結論した。(対処)タイマー停止時に適度なインターバルを与え、その後にMIDI音源のクローズを実施する事とした。タイマーコールバック(演奏処理)でのMIDI音源へのデータ送信直前にタイマー状況をチェックしもし停止していたら送信しないようガードを掛けた。●報告1メインの画面で、再生しながらCtrl+→,←でマーク間を行ったり来たりすると、落ちることがあるようです。1、2回じゃ発生しません。最低で4回、最高で30回ぐらいでした。譜面モニタを表示した時にだけ起きるようです。音源と言うよりは描写系の何かだと思います。あと、データによっても起きるか起きないかが変わります。小さめのデータは起きないようで(起きるのかもしれませんが30回ぐらいでは起きませんでした)大きめのデータ(というより16メンバーをフルに使っていると起きやすい)だと起きます。ちなみにMARK文のあるデータです。●報告2譜面モニタを表示しなくても、メインの画面で再生しながらCtrl+→を数回押すと落ちたり落なかったりします。因みに落ちた時の画像です。●報告3音源の話があったので色々試してみると、MSGSやサウンドフォントなどの、ソフト音源系(音源のオープンに時間がかかる系)が出やすいようです。現行バージョンだとサウンドフォントなら譜面モニタなしですぐに落ちます。テスト版だと、譜面モニタなしだと今のところ落ちてないです。●報告4[→]だけでも落ちますね。[→]を押した時に落ちるようです。1秒に2、3回程度の押し方で、半分位で落ちました。●報告5V6.29でも落ちます。●報告6V6.27では落ちない模様です。V6.28では落ちます。●報告7逆アセンブルして解析すると、どうやら、次のような呼び出しが発生した後、コケているようでした。0x003c4d9d);第二引数は何の変哲もないノートオンですので問題なしとして、hmoの値が古い値をとっていたり、どこかで値が破壊されていたり、などという可能性はないでしょうか?●報告8その後の調査の結果、「hmoがレジスター上からメモリー上にコピーされていない」ということはありえない、ということは判明しました。hmoが、バッファオーバーフロー等の影響で破壊されるの2つに絞られたことになると思います。●報告9「クローズ後、hmoにNULLが設定される前に演奏処理を行っている」ではないかと考えます。対応状況(2013.02.06)†V6.33にて対応済み。同時刻内において、該当する表示文字列よりも後にフォント指定があった場合、そのフォントを採用して文字列を表示する状況に陥っていた。(対処)表示文字列が採用すべきフォントを都度記憶しておき、そのフォントで文字列表示を終えた後に、その時刻内で検出した最終フォントを、カレントなフォントとして採用するよう改めた。"が反映されずMSゴシックで表示されます。メイン画面のスライダを少し進めた位置でリロードすると反映されますが、実行状態のまま次の楽章に入るとMSゴシックに戻ってしまいます。対応状況(2013.02.03)†V6.33にて対応済み。(原因)V6.32の開発の際、極力軽快に動作するようソースプログラム上で無駄な処理を洗い出し、それらの除去を試みた。その際、必要なウィンドウ描画の更新リージョンも削除してしまった。(対処)再度、以前のソースプログラムと比較しながら入念に必要十分な更新リージョンを確認し、コーディングをし直した。譜面モニターと本体のメンバー色は変わりますが、メンバー情報の色が変わらないようです。他のデータを読み込んだときにメンバー色に反映される時もありますがデータを変えても色が変わらないこともあります。挙動がよくわかりません。(報告2)メンバー情報画面の各パートの色が更新されません。Ver6.31までは正常で、Ver6.32で起こる現象の様に思います。色を変更してあるMUSデータを開く。色を変更してあるMUSデータを開く。muse.exeを表示する。ここではメンバー情報の色は更新されています。対応状況(2013.01.27)†V6.32にて対応済み。(原因)右クリックやBSキーにより曲頭への巻き戻しのシーク処理に入る。シーク処理の中では、カレントなフォントデータの参照およびフォントセットを行っているが、カレントなフォントデータの起動時における初期化忘れにより、不定値のアドレス参照が発生していた。(対処)適切な初期化を施した。障害報告(2013.01.27)†Museを起動し、データを読込んでいない状態で鍵盤を右クリックすると確実に落ちる。対応状況(2013.01.27)†V6.31にて対応済み。(原因)データのリスト構造を頼りにシーク位置決め判断を実施しているため、AAAとBBBの間にまったくデータが存在しない場合、AAAに位置決めされた状態と、AAAとBBBの間に位置決めされた状態を、シーク処理モジュールからは全く同一に見えてしまっていた。そのため、後者であっても前者と同様の演算結果となっていた。本件は、MARK文初期提供時点からの潜在バグ。(対処)時刻情報で制御することも考えたが、MARKが同一時刻に存在する場合に処理が複雑になるためMARK文の間にデータが一切存在しない状況においては、データロード時点で位置決め用のダミーデータを挿入することとした。以下の様なデータにおいて、シークつまみをAAAとBBBの間に位置決めした状態でシークバーの左黒三角ボタンを押下すると本来、AAAの位置にシークすべきところが、曲頭までシークしてしまう。対応状況(2013.01.27)†V6.31にて対応済み。(原因)スクロールバーのレンジセットと使用可否指定の処理順序ミス。本件は、譜面モニタ初期提供時期からの潜在バグ。(対処)レンジセットの後に使用可否指定を実施するように改めた。保持しておくべきエラー以前の表示位置を書き換えてしまう障害にも対処した。障害報告(2013.01.26)†データをロードする前に、譜面モニタをあらかじめ表示しておき、スクロールしなくても終止符がウィンドウ内に表示される程度に短い演奏時間のMuseデータをロードすると本来、水平スクロールバーがグレーアウトすべきところを、横いっぱいに広がったつまみが表示される。対応状況(2013.01.27)†V6.31にて対応済み。(原因)メモリ解放実施済みの文字列アドレスへの参照を行っていた。具体的には、フォント名の文字列を指し示すアドレス変数の処理部分。以下の2点において、上記の症状に陥っていた。<その1>Museデータロード時、同時刻に存在する同名のフォント指定(*FONT)をカットするデータコンパクト化の後処理を行っているが、そのカットするフォントがヘッダー(*HEAD)に反映させるフォントの場合、ヘッダー文字列描画で不定参照となった。続けて同一フォント名のセットが必要になった際にそれを実施しない処理を施しているが、データをロードし直した際に一旦セットしたフォント名実体の記憶アドレスが変更されるため、その後のシーク処理やテキスト表示における同一フォント名の比較処理の際に、不定参照となった。(対処)<その1>に関しては、残存させる側の同一フォントのアドレスに挿げ替える処理を追加した。<その2>に関しては、データロードの際にセット済みアドレス記憶をNULL化し、NULLの場合は比較処理を行わない処理を追加した。以下の操作を繰り返すと、高頻度でMuseが落ちる。「文法エラーの起こるデータをロードし、その文法エラーを訂正して再度ロードを行い、直ぐにシークを実施する。対応状況(2013.01.11)†V6.31にて対応済み。(原因)スライダーを操作すると様々なタイプのイベントが発生するがその仕分け処理にミスがあった。(対処)スライド位置が確定した際に発生するイベントのみ発音させるように改修した。今回の改修に伴い、残響、揺らぎ、コーラスのスライダー、および波形加工の垂直スクロールバーの全てのコントロールの操作で発音するように仕様を変更した。加えて、波形グラフのエリアをクリックすることで発音する機構は廃止した。COPY]とし、本ボタンの押下で発音停止を可能とした。障害報告(2013.01.11)†ドラム波形の強弱でキーで動かすと2回鳴ります。マウスでクリックすると、クリック→鳴るそこから放す→ピッチが高くなって鳴るようです。対応状況(2013.01.11)†V6.31にて対応済み。(対処)リソース属性の設定を精査し、正しく指定し直した。音止」に移動してしまう。「128:銃声」を選択した状態で下矢印キーを押しても、フォーカスが移動しない。ノイズ」へトグル移動できていた。ドラムの試聴の方は正常動作している模様。対応状況(2012.12.18)†V6.29にて対応済み。(原因)本機構の初期実装時点から内在していたバグ。音部記号の上部に表示する属性値<xxx>の値を算出するタイミングは、五線音符が再描画される時点を採用していた。その算出値を「値」として記憶し、再描画メッセージを発行していた。かたや再描画モジュールは、イベントを受けた段階でその算出値から属性値<xxx>の「表示文字列」へ変換整形しそれを描画する。以前の状況のデータと最新状況のデータを混在利用して変換処理を実施することになり矛盾が生じてしまう。「グルーブ(p,q)」「ピッチ(U)」「ペダル(Y)」の場合に実施するため、症状を再現させる概要報告とも一致している。属性選択ポップアップメニューにて任意の属性を選んだ時点で、そのポップアップメニューが消えるためその下部に位置する音部記号エリアや五線音符エリアの再描画が必要になる。五線音符エリアの再描画メッセージが音部エリアの再描画メッセージよりも先に発行された場合は属性値の算出後に属性値<xxx>の表示が実施されるため矛盾は無いが、これらのメッセージ順番が逆になった場合、矛盾が生じる可能性がある。自動譜めくりによって属性値<xxx>を変更すべき状態となっている場合で、かつ現在表示されている属性とは異なる属性に切替えた場合には、この矛盾によりNULL参照という事態に陥る可能性が高まる。特定の順序を前提とする実装となっていた。(対処)属性値<xxx>の値を算出したタイミングで、変換整形を完結させ表示文字列としてそれを記憶しておき、どのようなタイミングで再描画メッセージが起こっても、その表示文字列で描画するよう改めた。...」のダイアログが出で、異常終了します。今回も発生条件がよく分かりません。000265e4以前のバージョンでも発生していたかも知れません(落ちた覚えがあります)。他のアドレスで落ちることもあるのかもしれません。私も、前からたまに落ちる現象があったので、極力譜面モニタ属性は触らないようにしていました。こちらの環境の問題かと思っていたのですが、他の方の環境でも再現する現象ということで、少しびっくりです。対応状況(2012.12.06)†V6.28にて対応済み。(原因)V6.27でシーク処理の性能改善を図ったが、その際のデグレード。次に出現する文字列に備えて、事前にフォントの更新を行っておくアルゴリズムであったが、V6.27の改善で、文字描画が必要になった時点でフォント更新を実施するアルゴリズムに変更した。かかわらず、事前フォント更新の処理を廃棄し忘れていたため、タイミング上、フォントを変更していない文字にまでフォント更新が起こってしまった。(対処)不要な事前フォント更新の処理を削除した。(備考)なお本件の対処中、以下の2つの不具合も検出したため並行対処した。(1)シーク時、ちらつき防止用の不要文字描画の抑止機構が効いていなかった。→比較文字列の冒頭1バイトを片側だけ取り除いていた。(2)マーク文字列に、ヘッダー文字列のフォントが不正に採用される場合があった。→シーク処理の初期値にデフォルトではなくヘッダーのフォントを採用していた。イタリック体で表示されました。イタリック体になる現象は起きませんでした。した場合は起きました。対応状況(2012.11.23)†V6.27にて対応済み。(原因)現在のMuseは、メンバー情報やフォーカス機構において、ミュート指定したメンバーやフィンガーであってもノートOFFの命令はすべて音源に送っている。その理由は、もしノートONの直後(まだノートOFFが送信されていない状態)で、そのメンバーやフィンガーにミュートを掛けると、音が鳴り続けてしまうという事態を抑止するためである。両フィンガーとも通常に演奏させた場合を図解すると以下の様になる。OFF(4)となり、この時、OFF(3)が、ON(2)の音を止めてしまう。間髪入れずノートONを送るように工夫している。よって、pコマンドを使わないと、OFF(1)→OFF(3)→ON(2)という順番で音源に送信され、OFF(3)は止めるべき相手がいないため、症状が出ない。(対処)連結&処理用にセットした音符対を表現するOFFからONへのポインタが残存しているため、それを活用して対応を行った。先のポインタで対となるノートONをたぐり、そのフラグが既に立っていたら音源に送信し、立っていなければ送信しないという制御を組み込んだ。ccこの状態で、フォーカス機能を使って#A1だけ再生すると二つ目のcが消えます。pコマンドを使って、同じメンバーで同じ音を同じタイミングで出すと消えるようです。対応状況(2012.11.18)†V6.27にて対応済み。(原因)Museは演奏時のモタレを抑止するため、極力無駄なMIDIコマンドを音源に送信しないようにしている。ペダルに関しては、直前にY0が指定されていた場合、続いてY0を指定してもカットされる。ペダルの初期値はY0であるため、初めに検出したY0はカットされるというシーケンスになっていた。本件の様な記述の場合、実際の演奏時には先にY1が発行されるため、Y0をカットしてはいけない。(対処)1パス目の読込みではY0カットせず、後処理で実施している“連続する同値のコントロール(それはYに限らず)のカット処理(後送をカット)”に縮退効果を委ねることにした。この対応では、演奏冒頭のY0指定をカットせず、すべからく音源に送信してしまう。1パス目で先読みの処理を行えば理想的対応は可能だが、処理速度の低下を招く恐れがあるため冒頭のY0カットは行わないことを制約として本対処を採用する。今回の仕様で、より全体の整合が図られたとも言える。対応状況(2012.11.24)†V6.27にて対応済み。状況証拠に基づいた対処を行い、リリースを実施する。(原因)現在の所、直接の原因は不明。真因は別の所にあり、ビルド環境の変更が単にそれを顕在化させただけかもしれない。そこを優先的に割り当ててしまう。いうのが、現時点での最有力な真因候補となっている。(2012.11.24現在)(対処)文字列記憶域を確保する際、デリミッタ(\0)用に1バイト追加指定していたが、これを2バイトに変更した。次のバイトがヒープの外にならないようにするための対処として実施した。(分析)現象はWinXPのみに起こり、Win7では起こらない。左マージン用に、内部で先頭に半角1文字の空白を添えている。実質上は、32バイトの文字列の場合に現象が起こることになる。・VS2005でのビルドのみで出現という限られた条件下での不具合となる。再現性は高くなく、演奏でMARK文を通過する状況を何度か繰り返すと発生する。平均的には、3〜10回に1回程度出現するが、極めて不安定である。再現するデータも比較的複雑な(あるいはリロードに時間が掛かる)演奏に限られる模様。本現象は、MARK文だけでなく、TEXT文やSTOP文でも出現する。表示されていない状態で、ウィンドウの最小化と最大化を行うなど表示のリライトを実施しても再描画されないことからウィンドウへの描画メッセージのタイミング問題ではない。現象が起こっている際にも正しく表示されることからNULL終端の欠落や単純なメモリ破壊などの問題ではない。過去のバージョンをVS2005でビルドし直し、WinXPで再現テストを実施した。再現データのパラメータの方を1文字減らしてみた。これにより、同様の症状が出ることを確認した。結果としてソースコードが現存しているV3.1においても症状が出ることが確認できた。プログラムからあらゆるダイアログ、発音機構などを除去した状態でも再現する。このことから、極めて基本的な部分に真因があることが予想される。やってみたんですが、(1)譜面モニタをメインウィンドと同じ幅、4/4表示にして、(2)小節線110〜113がモニタの左端に来るようにして(3)小節線の左で右クリック→2.戦いの...が鍵盤上部に表示されないようです。画像を上げておきました。画像を見てもらえたようですので、この現象がおきることがある、のは分かっていただいたと思います(指揮棒カーソルは2.を過ぎているが、鍵盤の上は1.のまま)私のところでも、同じ条件で毎回起きるわけでもないようで、??です。初回でも起きる場合があるし、何回も起きない場合があるし、ってまったく??です。再現しない場合もあって、やはりよく分かりません。<開発者>再現のためのレシピを忠実に何度も試したのですが、やはり私の環境では再現しませんでした。少々厄介なことになってしまいました(苦笑)。私の経験では90%は(1)の方です。orzただ、再現しないことには障害追跡ができません。第2曲が開始、となりますが、何回か続けてみると(多分3回目)、「1.ソロモンの...」の表示のまま演奏が始まる、って言う現象が、やはりおきます。私の環境のせい?抽出データでの再現はうまくいってません。演奏してみると、正常に、「2.戦いの...」が表示されます。(何度右クリックしても)ただし、一旦元データで「1.ソロモンの...」のまま演奏される現象が発生したあと、Museを再起動せずにこの抽出データを再生してみると.........やはり「1.ソロモンの...」のまま演奏が始まったりします。同様です(いや、正常ケースがなくなるかな。<開発者>もう一つ、実験してもらうことを思いついたので、試してもらえますか?本来「2.戦いの...」が表示されなければならないのに「1....」のままになっている状態で、Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。これでも「1....」のままになっているか否かを試してみてください。SP3なので試してみました。<開発者>ご報告、ありがとうございます。再現する試験者が増えたのは心強い限りです。お手数ですが、お手すきの時に以下の実験をして結果を教えてもらえますか?=====本来「2.戦いの...」が表示されなければならないのに「1....」のままになっている状態で、Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。これでも「1....」のままになっているか否かを試してみてください。どっちでも、「1.ソロモンの...」のままです。(2)次いで、文字列そのものを疑っていろいろやってみました。)どうも違うようで(4.饗宴の踊り...では発生しない)そのスペースを半角に置き換えたりしてみているうちに、どうも「30バイトの文字列が指定された場合に発生するのではないか」という推測に達しました。guerresca"↑全角・半角の違いが分かりにくいですが...いずれも30バイトのはずですこの3ついずれでも発生します。「4.饗宴の踊り...」でも半角文字を1つ削除すると、やはり発生します(30バイトになります)。Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。これでも「1....」のままになっているか否かを試してみてください。ともに「1....」のままでした。起動直後の演奏では正常に切り替わることが多い気がします。Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。症状を確認しましたのでご連絡します。当該症状のにつきまして、同様の結果が出ました。変えた時のスクリーンショットとシステムのプロパティ画面です。SP3を動かした時では発生しませんでした。再現性は100%ではないですが,症状が出ていますので報告します。自分のデータで上記の条件で再現しないか調査中ですが未だに再現していません。いま少し調べてみます。Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。表示は更新されないままでした。気付いた点は以下の3点です。条件のとき、構文の直前からリロード再生を行うと発生するようです。以下のデータで、譜面モニタ上の最初の小節で何度か右クリックすると再現します。ファイルサイズが大きいだけではだめで、構文がある程度複雑でないと再現しないようです。条件を満たしただけで同じ現象が発生します。内部状態を変化させていることが示唆されます。発生することを確かめました。よって、この間の更新が現象の一因になっていることが示唆されます。orz再現性は確保できているので、科学的にアプローチできます。今は、履歴データによって現象が出たり出なかったりする件を追っていました。これもまた微妙な按配です。ほんの少し履歴データを変更すると、途端に現象が出なくなります。Museデータを、ちょっち変更すると出なくなるのと同じ印象です。ガラス細工のようです(苦笑)。結局、MuseWikiの(対処)の項に記載したのと同じ結果に行き着きました。履歴データのパス文字列のメモリ確保を1バイト増やすか、どちらか一方でも行うと症状は出なくなります。限りになく患部に近い所に薬を塗れているのではないか、と思い始めてきました。個人的にはとても原因が気になります。メッセージが発行されていないようです。コマンドの種類は変わらないという結果になりました。問題はリロード時に生じているのではないかというのが、私の推測です。メッセージが発行されていないようです。問題はリロード時に生じているのではないかというのが、私の推測です。これは、かなり核心を突いているかもしれません。この仮説に基づいて、再度追跡してみます。コマンドの種類は変わらないもしかしたら、この状態でMIDIファイルのエクスポートをしたら、そのMIDIファイルも、当該のMARK文が欠落した状態かもしれませんね。Museは演奏データとMIDIエクスポートデータを一元化しているので、MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。いうことは、V6.26aでは、やはり症状は抑え込まれているということでしょうか?そうです。症状は生じていません。以外のモードでは症状は生じません。MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。!早速試してみました。エクスポートをしても、正常なデータが出力されるのみです。メモリ上のデータは全て正常だと思います。どこかでMuseがデータ以外のメモリを壊していることが考えられます。症状はMARK表示の演奏時に出ますが、Elekenさんが推察されているとおり、リロード(あるいはロード後の後処理)で既に破壊工作は完了しているのではないかと(苦笑)。メッセージが発行されていないようですの件を追試してみましたので、ご報告します。・SetWindowText?()で送信している文字列内容を確認してみました。・戻り値は、TRUE・文字列は正常な30文字が確認されました。データは壊れていない、ということを裏付けていると思います。Elekenさんのご指摘の通り、演奏時点での症状から追跡するのを止めて、データロード時点の不具合を追跡してみようと思います。Elekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。結局、属性関係は無くても症状が出ますので、譜面モニタの属性表示はシロだったみたいです。マクロの繰返し数で2000回指定をすると症状が出ません。無名マクロの処理にバグが混入している気がしてきました。今度こそ、犯人の潜むアジトを特定できるといいのですが・・・。<開発者>経過報告です。Elekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。・(↑この行が多い程、再現確率が高まる。10,000行あれば楽勝で出現)だいぶ敵陣に近づいてきたような気がします。無名マクロの処理はとっても複雑なので、気が重いです。メモリダンプして解析したところ、次のことが分かりました。なっているこのアドレスのメモリが何を表すのか分かりませんし、他の環境でどうなるかもわかりませんが、この共通点は少し怪しそうです。末尾に来た場合、メッセージが飛んでいないようです。関連)のあたりの仕様の違いに関連ありそうとは思いましたが、これはという情報はまだ見つかってません。しなおしていない?のではないか、と思いました。する際、拡張が起きているのかな?)なぜ末尾ではいけないのか?←これが問題ですね。してみようと思います。末尾に来た場合、メッセージが飛んでいないようです。!謎(の一部)が解けました。ヒープ末尾を表すフラグだったわけです。終端がヒープ末尾に来る文字列の問題は、以下の簡単なプログラムで確認できます。呼び出した時点の残り割り当て可能領域に依存します。呼び出した時点の残り割り当て可能領域に依存します。思い当たる節があります。純正培養Museを作る過程で、本来必要なFree()部分をコメントアウトしたら、症状が出なくなりました。機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。そこを優先的に割り当ててしまうということなのでしょうか。ヒープ断片化が起こらないように、ヒープは自分で管理する。HeapCreate...のどれかをとればいいように思います。バイト多く確保するこれは、まさにV6.26aの対応そのものですね。する今回の格闘の最中、実はこれを実施した記憶があります。SendMessage?()する前に、別途確保した文字列変数に問題の文字列内容をコピーし、それをSendMessage?()に送ってみました。すると、症状は出ませんでした。演奏時点の処理負荷が増えるので、対応策としては却下していました。場当たり的に試行した私の実験と、論理的に導いたElekenさんの対応策の結果が見事に一致していますので、Elekenさんの今回の真因推理はかなりの確度で正しいと思えます。ヒープ断片化が起こらないように、ヒープは自分で管理する。HeapCreate?私の技術力からして、この対応は継続的にメンテナンスしていく地震がありません。なかった、自信がありせん。いえば先程、横浜で比較的大きな自身がありました。なかった、地震がありました。...のどれかをとればいいように思います。倍数バイトで発生しないのかも謎です。倍数バイトで発生しないのかも謎です。