[[FrontPage]]
#contents



*(V6.33)シークを素早く断続的に繰り返すと落ちる場合がある [#ace02fc1]
**状況(2013.02.11) [#d059e589]
追跡中

**概要(2013.02.09) [#e1c87310]

●報告1~
メインの画面で、再生しながらCtrl+→,←でマーク間を行ったり来たりすると、落ちることがあるようです。~
いっぱい動かすとなります。1、2回じゃ発生しません。最低で4回、最高で30回ぐらいでした。~
譜面モニタを表示した時にだけ起きるようです。~
だから音源と言うよりは描写系の何かだと思います。~
あと、データによっても起きるか起きないかが変わります。~
小さめのデータは起きないようで(起きるのかもしれませんが30回ぐらいでは起きませんでした)~
大きめのデータ(というより16メンバーをフルに使っていると起きやすい)だと起きます。~
ちなみにMARK文のあるデータです。 ~
~
●報告2~
譜面モニタを表示しなくても、メインの画面で再生しながら~
Ctrl+→を数回押すと落ちたり落なかったりします。~
因みに落ちた時の画像です。↓~
#ref(SeekDown.png)
~
●報告3~
音源の話があったので色々試してみると、~
MSGSやサウンドフォントなどの、ソフト音源系(音源のオープンに時間がかかる系)が出やすいようです。~
現行バージョンだとサウンドフォントなら譜面モニタなしですぐに落ちます。~
テスト版だと、譜面モニタなしだと今のところ落ちてないです。~
~
●報告4~
[→]だけでも落ちますね。[→]を押した時に落ちるようです。~
1秒に2、3回程度の押し方で、半分位で落ちました。~

●報告5~
V6.29でも落ちます。~

 <状況の整理>
 
 ・押下キーは[→]のみで落ちる([CTRL]や[SHFIT]の併用不要)
 ・マウスグリップによるシークでも落ちる
 ・何度かシークを素早く断続的に実施していると、いつか[→]を押下した瞬間に落ちるようである
 ・譜面モニタを表示したり、音源をサウンドフォントにしたり負荷を高めると落ちやすい
 ・MARK文が無くても落ちる

 <症状を確認した環境>
 
 [OS]
 Win7(Home)
 Win7(Pro32)

 [Muse]
 V6.33
 V6.29
  
 [音源]
 SC-88Pro
 Microsoft GS Wavetable Synth



*(V6.32)テキストエリアの文字列に指定したフォントを反映しない場合がある [#v0067f6c]
**状況(2013.02.06) [#y3093704]

V6.33にて対応済み。~
~
(原因)~
V6.30の開発の際、演奏時の文字列表示シーケンスを効率化し、CPUの低負荷化を図ったが、~
その際に考慮不足で混入したバグ。~
演奏時、同時刻内の表示テキスト文字列はその最後の文字列のみを表示するシーケンスに組み直したが、~
同時刻内において、該当する表示文字列よりも後にフォント指定があった場合、~
そのフォントを採用して文字列を表示する状況に陥っていた。~
~
(対処)~
表示文字列が採用すべきフォントを都度記憶しておき、そのフォントで文字列表示を終えた後に、~
その時刻内で検出した最終フォントを、カレントなフォントとして採用するよう改めた。
~
**概要(2013.02.06) [#t85e228b]
例えば、以下のような記述の場合~
 *MARK"AAA"
 *FONT"Signet Roundhand,2"
 *TEXT"BBB"
 *FONT"MS ゴシック,0"
上記の*TEXT"CCC"部分にその直前の*FONT" Signet Roundhand ,2 "が反映されずMSゴシックで表示されます。~
メイン画面のスライダを少し進めた位置でリロードすると反映されますが、実行状態のまま次の楽章に入るとMSゴシックに戻ってしまいます。~


*(V6.32)メンバー情報に*COLRコマンド指定色が反映しない場合がある [#m7ccb6a3]
**状況(2013.02.03) [#naf09f3a]

V6.33にて対応済み。~
~
(原因)~
V6.32の開発の際、極力軽快に動作するようソースプログラム上で無駄な処理を洗い出し、それらの除去を試みた。~
その際、必要なウィンドウ描画の更新リージョンも削除してしまった。~
~
(対処)~
再度、以前のソースプログラムと比較しながら入念に必要十分な更新リージョンを確認し、コーディングをし直した。~
~
**概要(2013.02.03) [#l3ccdffd]
(報告1)~
V6.32でデータを読み込んで、*COLR""でメンバー色を変え、リロードした際に、~
譜面モニターと本体のメンバー色は変わりますが、メンバー情報の色が変わらないようです。~
~
また、他のデータを読み込んだときにメンバー色に反映される時もありますが~
データを変えても色が変わらないこともあります。~
ちょっと挙動がよくわかりません。。。~

(報告2)~
メンバー情報画面の各パートの色が更新されません。~
Ver6.31までは正常で、Ver6.32で起こる現象の様に思います。~
ちなみに、OSはXP2002 SP3です。~
~
この現象が起きる手順は、~
1. muse.exeを起動(MUSデータを開かない状態)~
2. メンバー情報を表示(デフォルトの色が表示される)~
3. 色を変更してあるMUSデータを開く。この時、色表示が更新されない~
4. 更に色を変更してあるMUSデータを開く。この時も色表示が更新されない~
5. 別のプログラムを開く等して別の画面を表示する~
6. 再びmuse.exeを表示する。ここではメンバー情報の色は更新されています。~


*(V6.31)Muse起動直後に鍵盤を右クリックすると落ちる [#c14f47f5]
**状況(2013.01.27) [#g85919f3]

V6.32にて対応済み。~
~
(原因)~
右クリックやBSキーにより曲頭への巻き戻しのシーク処理に入る。~
シーク処理の中では、カレントなフォントデータの参照およびフォントセットを行っているが、~
カレントなフォントデータの起動時における初期化忘れにより、不定値のアドレス参照が発生していた。~
~
(対処)~
適切な初期化を施した。~
~
**概要(2013.01.27) [#j35112c0]
Museを起動し、データを読込んでいない状態で鍵盤を右クリックすると確実に落ちる。~
~



*(V6.30)MARK間に休符しか存在しない場合にシークの位置決めがうまく働かない [#x0e18e80]
**状況(2013.01.27) [#m78b1287]

V6.31にて対応済み。~
~
(原因)~
データのリスト構造を頼りにシーク位置決め判断を実施しているため、AAAとBBBの間にまったくデータが存在しない場合、~
AAAに位置決めされた状態と、AAAとBBBの間に位置決めされた状態を、シーク処理モジュールからは全く同一に見えてしまっていた。~
そのため、後者であっても前者と同様の演算結果となっていた。~
本件は、MARK文初期提供時点からの潜在バグ。~
~
(対処)~
時刻情報で制御することも考えたが、MARKが同一時刻に存在する場合に処理が複雑になるため~
MARK文の間にデータが一切存在しない状況においては、データロード時点で位置決め用のダミーデータを挿入することとした。~
~
**概要(2013.01.26) [#j35112c0]
以下の様なデータにおいて、シークつまみをAAAとBBBの間に位置決めした状態でシークバーの左黒三角ボタンを押下すると~
本来、AAAの位置にシークすべきところが、曲頭までシークしてしまう。~
 _1
 *MARK"AAA"
 _1
 *MARK"BBB"
 _1


*(V6.30)リロード時に譜面モニタの水平スクロールバーのつまみが全体に広がる [#rc82bd5f]
**状況(2013.01.27) [#v243038c]

V6.31にて対応済み。~
~
(原因)~
スクロールバーのレンジセットと使用可否指定の処理順序ミス。~
本件は、譜面モニタ初期提供時期からの潜在バグ。~
~
(対処)~
レンジセットの後に使用可否指定を実施するように改めた。~
なお、エラーが発生したデータをロードした際、譜面モニタのストレッチで、~
保持しておくべきエラー以前の表示位置を書き換えてしまう障害にも対処した。~
~
**概要(2013.01.26) [#ldf701c3]
データをロードする前に、譜面モニタをあらかじめ表示しておき、~
スクロールしなくても終止符がウィンドウ内に表示される程度に短い演奏時間のMuseデータをロードすると~
本来、水平スクロールバーがグレーアウトすべきところを、横いっぱいに広がったつまみが表示される。~



*(V6.30)リロードを繰り返すとMuseが落ちる場合がある [#u7622b37]
**状況(2013.01.27) [#qbd8205f]

V6.31にて対応済み。~
~
(原因)~
メモリ解放実施済みの文字列アドレスへの参照を行っていた。~
具体的には、フォント名の文字列を指し示すアドレス変数の処理部分。~
以下の2点において、上記の症状に陥っていた。~
<その1>~
Museデータロード時、同時刻に存在する同名のフォント指定(*FONT)をカットするデータコンパクト化の後処理を行っているが、~
そのカットするフォントがヘッダー(*HEAD)に反映させるフォントの場合、ヘッダー文字列描画で不定参照となった。~
<その2>~
フォントファイルのロード負荷を低減するため、テキストエリアに一旦セットしたフォント名を記憶しておき、~
続けて同一フォント名のセットが必要になった際にそれを実施しない処理を施しているが、~
データをロードし直した際に一旦セットしたフォント名実体の記憶アドレスが変更されるため、~
その後のシーク処理やテキスト表示における同一フォント名の比較処理の際に、不定参照となった。~
~
(対処)~
<その1>に関しては、残存させる側の同一フォントのアドレスに挿げ替える処理を追加した。~
<その2>に関しては、データロードの際にセット済みアドレス記憶をNULL化し、NULLの場合は比較処理を行わない処理を追加した。~
~
**概要(2013.01.25) [#k1956ec0]
以下の操作を繰り返すと、高頻度でMuseが落ちる。~
「文法エラーの起こるデータをロードし、その文法エラーを訂正して再度ロードを行い、直ぐにシークを実施する。」~




*(V6.30)波形加工ダイアログの強弱スライダーを動かすと2度発音が起こる [#q15a37f0]
**状況(2013.01.11) [#i50f47af]

V6.31にて対応済み。~

(原因)~
スライダーを操作すると様々なタイプのイベントが発生するが~
その仕分け処理にミスがあった。~
~
(対処)~
スライド位置が確定した際に発生するイベントのみ発音させるように改修した。~
なお今回の改修に伴い、残響、揺らぎ、コーラスのスライダー、および~
波形加工の垂直スクロールバーの全てのコントロールの操作で発音するように仕様を変更した。~
加えて、波形グラフのエリアをクリックすることで発音する機構は廃止した。~
また発音の機会が増加したため、発音を積極的に停止させたい場合があることを想定し、~
[COPY]ボタンを[STOP & COPY]とし、本ボタンの押下で発音停止を可能とした。~
~
**概要(2013.01.11) [#e1c53010]
ドラム波形の強弱でキーで動かすと2回鳴ります。~
~
マウスでクリックすると、~
クリック→鳴る~
そこから放す→ピッチが高くなって鳴る~
ようです。~


*(V6.30)楽器の試聴ダイアログのタブ遷移に異常がある [#l5a6e721]
**状況(2013.01.11) [#j05e0a5c]

V6.31にて対応済み。~

(原因)~
V6.30において、ダイアログのレイアウトおよび構成を見直した際、~
変更に対応したリソースの WS_GROUP および WS_TABSTOP の設定を失念した。~
~
(対処)~
リソース属性の設定を精査し、正しく指定し直した。~
~
**概要(2013.01.11) [#s08c98d6]

楽器の試聴ダイアログにて、「121:Fret ノイズ」ボタンを選択した状態で上矢印キーを押すと、~
フォーカスが「128:銃声」ではなく、「■ 音止」に移動してしまう。~
また「128:銃声」を選択した状態で下矢印キーを押しても、フォーカスが移動しない。~
~
前バージョンのV6.29では、~
「121:Fret ノイズ」ボタンから上矢印キーで「128:銃声」へ、~
「128:銃声」から下矢印キーで「121:Fret ノイズ」へトグル移動できていた。~
~
なおドラムの試聴の方は正常動作している模様。~
~


*(V6.28)譜面モニタで属性表示を行うと落ちる場合がある [#x299ee10]
**状況(2012.12.18) [#if3cb965]

V6.29にて対応済み。~

(原因)~
本機構の初期実装時点から内在していたバグ。~
~
音部記号の上部に表示する属性値<xxx>の値を算出するタイミングは、五線音符が再描画される時点を採用していた。~
そしてその算出値を「値」として記憶し、再描画メッセージを発行していた。~
かたや再描画モジュールは、イベントを受けた段階でその算出値から属性値<xxx>の「表示文字列」へ変換整形しそれを描画する。~
しかしこのシーケンスでは、「値」から「表示文字列」に整形する段階で譜面モニタの状況が変化していた場合には、~
以前の状況のデータと最新状況のデータを混在利用して変換処理を実施することになり矛盾が生じてしまう。~
この変換処理は、 「グルーブ(p,q)」「ピッチ(U)」「ペダル(Y)」の場合に実施するため、症状を再現させる概要報告とも一致している。~
~
一方、属性選択ポップアップメニューにて任意の属性を選んだ時点で、そのポップアップメニューが消えるため~
その下部に位置する音部記号エリアや五線音符エリアの再描画が必要になる。~
もし、五線音符エリアの再描画メッセージが音部エリアの再描画メッセージよりも先に発行された場合は~
属性値の算出後に属性値<xxx>の表示が実施されるため矛盾は無いが、~
これらのメッセージ順番が逆になった場合、矛盾が生じる可能性がある。~
特に、自動譜めくりによって属性値<xxx>を変更すべき状態となっている場合で、~
かつ現在表示されている属性とは異なる属性に切替えた場合には、~
この矛盾によりNULL参照という事態に陥る可能性が高まる。~
~
音部記号エリアと五線音符エリアの再描画メッセージの発行順序は、その時点のOS処理の状況によるため、~
その順序がどうであれ、アプリケーションは正しく動くように設計すべきであるにもかかわらず、~
特定の順序を前提とする実装となっていた。~
~
(対処)~
属性値<xxx>の値を算出したタイミングで、変換整形を完結させ表示文字列としてそれを記憶しておき、~
どのようなタイミングで再描画メッセージが起こっても、その表示文字列で描画するよう改めた。~
~
**概要(2012.12.16) [#z1488234]

 himajin925さん
 投稿日:2012/12/16(Sun) 22:11:57
  
 譜面モニタの左上 <>で右クリック、各種設定値を表示しようとする場合
 テンポ<->ボリューム<->ピッチ …などと何回《も》繰り返して選びなおしていると、
 「問題が発生したため、MUSE.EXE を終了します。…」のダイアログが出で、異常終了します。
 今回も発生条件がよく分かりません。
 Ver6.27 です。WinXP SP3
 落ちたアドレスは Offset:0002650c または 000265e4
 以前のバージョンでも発生していたかも知れません(落ちた覚えがあります)。
 またアドレスは2つだけ書きましたが、直前に右クリックのメニューから選んだ表示項目によって違っているのか、
 他のアドレスで落ちることもあるのかもしれません。
 ※今のところ「大地の歌」でしか発生していません←他の曲でも出ました


 Elekenさん
 投稿日:2012/12/17(Mon) 21:52:07
  
 私も、前からたまに落ちる現象があったので、極力譜面モニタ属性は触らないようにしていました。
 こちらの環境の問題かと思っていたのですが、他の方の環境でも再現する現象ということで、少しびっくりです。
 こちらで少し調べたところ、以下の順番の操作で 100% 再現します。
 (1) 譜面モニタを開き、自動譜めくりをオンにして、適当な譜面モニタ属性を表示する
 (2) 再生中に、<> 部分を右クリックして、メニューを表示する
 (3) 自動譜めくりが行われる
 (4) 「グルーブ(p,q)」「ピッチ(U)」「ペダル(Y)」のいずれかをクリックする


*(V6.27)MARK位置決め後の再生時、テキストが指定外の修飾で描画される場合がある [#l3c5a3d2]
**状況(2012.12.06) [#i0408f10]

V6.28にて対応済み。~

(原因)~
V6.27でシーク処理の性能改善を図ったが、その際のデグレード。~
~
V6.26以前は、シークポイント(MARK)の文字列描画を実施した後、~
次に出現する文字列に備えて、事前にフォントの更新を行っておくアルゴリズムであったが、~
V6.27の改善で、文字描画が必要になった時点でフォント更新を実施するアルゴリズムに変更した。~
にもかかわらず、事前フォント更新の処理を廃棄し忘れていたため、~
タイミング上、フォントを変更していない文字にまでフォント更新が起こってしまった。~
~
(対処)~
不要な事前フォント更新の処理を削除した。~
~
(備考)~
なお本件の対処中、以下の2つの不具合も検出したため並行対処した。~
(1)シーク時、ちらつき防止用の不要文字描画の抑止機構が効いていなかった。~
  →比較文字列の冒頭1バイトを片側だけ取り除いていた。~
(2)マーク文字列に、ヘッダー文字列のフォントが不正に採用される場合があった。~
  →シーク処理の初期値にデフォルトではなくヘッダーのフォントを採用していた。~
~
**概要(2012.12.05) [#v700a75f]

 *MARK"A"
 *TEXT"B"
 _
 *FONT",2"
 *MARK"C"

ファイル読込み直後は 2 行目が表示する "B" はデフォルトの書体で表示されるのですが、~
一度 5 行目を通過した後で左三角やシークバーで 1 行目のマークに戻り、~
再び再生すると 2 行目の "B" がイタリック体で表示されました。~
~
1 行目か 5 行目のどちらかの *MARK でも削ると "B" がイタリック体になる現象は起きませんでした。~
1 行目を *TEXT にした場合も起きませんでしたが、~
1 行目は *MARK のままで 5 行目を *TEXT にした場合は起きました。~
また、V6.26 では起きませんでした。~




*(V6.26)フォーカス機構にて当該フィンガーの音が出ない場合がある [#bcdf616f]
**状況(2012.11.23) [#ea21165c]

V6.27にて対応済み。~

(原因)~
現在のMuseは、メンバー情報やフォーカス機構において、~
ミュート指定したメンバーやフィンガーであってもノートOFFの命令はすべて音源に送っている。~
その理由は、もしノートONの直後(まだノートOFFが送信されていない状態)で、~
そのメンバーやフィンガーにミュートを掛けると、音が鳴り続けてしまうという事態を抑止するためである。~
~
> なぜ一つ目が消えないのかは謎ですが…~
まず、#A0 #A1 の両フィンガーとも通常に演奏させた場合を図解すると以下の様になる。~
 #A0   ON(1)------------OFF(1)
                 ON(2)--------------OFF(2)
  
 #A1   ON(3)------------OFF(3)
                        ON(4)-------OFF(4)
  
 ここで、#A0だけフォーカスし 現行Museの仕様で#A1をミュートすると、
  
 #A0   ON(1)------------OFF(1)
                 ON(2)--------------OFF(2)
  
 #A1                    OFF(3)
                                    OFF(4)
 
 となり、この時、OFF(3)が、ON(2)の音を止めてしまう。
なお、Museは同時刻のノートONとノートOFFがあった場合、先に全ての音止を送信してから、~
間髪入れずノートONを送るように工夫している。~
よって、pコマンドを使わないと、OFF(1)→OFF(3)→ON(2)という順番で音源に送信され、~
OFF(3)は止めるべき相手がいないため、症状が出ない。~

(対処)~
連結&処理用にセットした音符対を表現するOFFからONへのポインタが残存しているため、それを活用して対応を行った。~
各音符に新たなフラグ(音源へのノートON送信済みフラグ)を設け、ミュート対象のノートOFFを検出した際、~
先のポインタで対となるノートONをたぐり、そのフラグが既に立っていたら音源に送信し、立っていなければ送信しない~
という制御を組み込んだ。~
~
**概要(2012.11.22) [#ibea74f4]
 *FING"x1 "
 @A P72 
 #A1 p^i10cc
 #A2 cc
この状態で、フォーカス機能を使って#A1だけ再生すると二つ目のcが消えます。~
どうやらpコマンドを使って、同じメンバーで同じ音を同じタイミングで出すと消えるようです。~
なぜ一つ目が消えないのかは謎ですが…~

*(V6.26)曲頭付近のペダルオフ(Y0)が出力されない場合がある [#d2902aac]
**状況(2012.11.18) [#ea21165c]

V6.27にて対応済み。~

(原因)~
Museは演奏時のモタレを抑止するため、極力無駄なMIDIコマンドを音源に送信しないようにしている。~
例えばペダルに関しては、直前にY0が指定されていた場合、続いてY0を指定してもカットされる。~
ペダルの初期値はY0であるため、初めに検出したY0はカットされるというシーケンスになっていた。~
しかし本件の様な記述の場合、実際の演奏時には先にY1が発行されるため、Y0をカットしてはいけない。~

(対処)~
1パス目の読込みではY0カットせず、後処理で実施している“連続する同値のコントロール(それはYに限らず)のカット処理(後送をカット)”~
に縮退効果を委ねることにした。ただしこの対応では、演奏冒頭のY0指定をカットせず、すべからく音源に送信してしまう。~
1パス目で先読みの処理を行えば理想的対応は可能だが、処理速度の低下を招く恐れがあるため~
冒頭のY0カットは行わないことを制約として本対処を採用する。~
~
改めて考察してみると~
他のコントロールコードも音源の初期値が明確でないことから、~
初回のコマンドはカットしないようにしているため、~
今回の仕様で、より全体の整合が図られたとも言える。~

**概要(2012.11.18) [#ndd3bd78]
例えば以下のデータで
 #A0| d4r @Y0 mf
 #A1| @Y1 _1
フィンガー #A0 の Y0 が発行されないのは仕様でしょうか?



*(V6.26)MARK文字列がテキストエリアに表示されない場合がある [#a6dc89ca]
**状況(2012.11.24) [#l4a87ce0]

V6.27にて対応済み。~
ただし、真因が確実に特定できたとは言えない状況ではあるが、~
状況証拠に基づいた対処を行い、リリースを実施する。

(原因)~
現在の所、直接の原因は不明。~
間接原因としては、ビルド環境をVC6からVS2005に変更した事に因るが、~
真因は別の所にあり、ビルド環境の変更が単にそれを顕在化させただけかもしれない。(2012.11.17現在)~

ヒープ断片化の状態で、末尾に丁度 32 バイト分の空きがあるヒープ断片が存在していた場合、~
新たなメモリ確保を行うと、VS2005 の malloc がそこを優先的に割り当ててしまう。~
というのが、現時点での最有力な真因候補となっている。(2012.11.24現在)~

(対処)~
文字列記憶域を確保する際、デリミッタ(\0)用に1バイト追加指定していたが、これを2バイトに変更した。~
プログラム構造としてはこの追加バイトは不要ではあるが、本件はカーネル障害と想定し、~
NULL 終端 の次のバイトがヒープの外にならないようにするための対処として実施した。~

(分析)~
現象はWinXPのみに起こり、Win7では起こらない。~

また、文字列が30文字である場合に限る(30より大きくても小さくても出現しない)が、~
Museはテキストエリアへの表示の見栄えを考慮し、~
左マージン用に、内部で先頭に半角1文字の空白を添えている。~
さらに、文字列の終端にデリミッタ(\0)の1文字が加算されるため、~
実質上は、32バイトの文字列の場合に現象が起こることになる。~

・32バイトというキリの良いサイズでのみ出現~
・WinXPのみでの出現~
・VS2005でのビルドのみで出現~
という限られた条件下での不具合となる。~

再現性は高くなく、演奏でMARK文を通過する状況を何度か繰り返すと発生する。~
平均的には、3〜10回に1回程度出現するが、極めて不安定である。~
また、再現するデータも比較的複雑な(あるいはリロードに時間が掛かる)演奏に限られる模様。~

本現象は、MARK文だけでなく、TEXT文やSTOP文でも出現する。~
また表示されていない状態で、ウィンドウの最小化と最大化を行うなど~
表示のリライトを実施しても再描画されないことから~
ウィンドウへの描画メッセージのタイミング問題ではない。~

また、問題の文字列(MARK文の内容)を、別の手段(デバッグライトなど)で表示させた場合、~
現象が起こっている際にも正しく表示されることから~
NULL終端の欠落や単純なメモリ破壊などの問題ではない。~

過去のバージョンをVS2005でビルドし直し、WinXPで再現テストを実施した。~
V5.70のバージョン以前は、テキスト文字列の記憶域を1バイト多く取り、~
それを文字列区分(TEXT/MARK/STOP)のフラグとして利用していたため、~
再現データのパラメータの方を1文字減らしてみた。
これにより、同様の症状が出ることを確認した。~
~
こうしてバージョンを遡っていくと、~
結果としてソースコードが現存しているV3.1においても症状が出ることが確認できた。~
更に、プログラムからあらゆるダイアログ、発音機構などを除去した状態でも再現する。~
このことから、極めて基本的な部分に真因があることが予想される。~


**概要(2012.11.11) [#y7556a79]

 ●(2012/11/11) 21:33 <himajin925さん>
 
 Ver6.26 にアップしました。
 いろいろやってみたんですが、
 (1)譜面モニタをメインウィンドと同じ幅、4/4表示にして、
 (2)小節線110〜113がモニタの左端に来るようにして
 (3)小節線の左で右クリック
 →2.戦いの…が鍵盤上部に表示されない
 ようです。
 画像を上げておきました。
 
#ref(MARK1.jpg)
 
 画像を見てもらえたようですので、この現象がおきることがある、
 のは分かっていただいたと思います(指揮棒カーソルは2.を過ぎているが、鍵盤の上は1.のまま)
 私のところでも、同じ条件で毎回起きるわけでもないようで、??です。
 ただ、画像の場所で右クリック、2.戦いの…が表示されたら、また右クリック、
 と数回やっていると高い確率で発生するようになる、らしいのですが、
 初回でも起きる場合があるし、何回も起きない場合があるし、ってまったく??です。
 まったく困ってはいないのですが(^.^)
 
 もっと前から(先頭からも?)演奏した場合も同様の場合があるようですが、
 再現しない場合もあって、やはりよく分かりません。
 (2)の場所が条件なのかもまったく?です(たぶん条件ではないのでしょう)
●(2012/11/11) 22:55 <開発者>~
~
再現のためのレシピを忠実に何度も試したのですが、やはり私の環境では再現しませんでした。~
少々厄介なことになってしまいました(苦笑)。~
~
こういった場合考えられるのは、~
  (1)Museの根深く基本的なバグ~
  (2)メモリやリソースなどの環境の問題~
のどちらかだと思いますが、~
私の経験では90%は(1)の方です。orz~
~
ただ、再現しないことには障害追跡ができません。~
本当は、こういった時こそ「純正培養データ」が欲しいのですが、~
~
 ●(2012/11/12) 23:18 <himajin925さん>
 
 やはり再現しませんか?
 もうちょっと単純に(4/4表示で)小節線116のちょっと左で右クリックすると、
 正常では、一瞬「1.ソロモンの…」が表示され、「2.戦いの…」が上書きされ、
 第2曲が開始、となりますが、何回か続けてみると
 (多分3回目)、「1.ソロモンの…」の表示のまま演奏が始まる、
 って言う現象が、やはりおきます。
 
 私の環境のせい?
 
 抽出データでの再現はうまくいってません。
 マクロ、第1曲の最後、第2曲〜という mus ファイルを作って Museを再起動し、
 演奏してみると、正常に、「2.戦いの…」が表示されます。(何度右クリックしても)
 ただし、一旦元データで「1.ソロモンの…」のまま演奏される現象が発生したあと、
 Museを再起動せずにこの抽出データを再生してみると………やはり「1.ソロモンの…」のまま演奏が始まったりします。
●(2012/11/12) 23:55 <開発者>~
~
問題の「2.戦いの…」のMARKを、TEXTおよびSTOPに書き換えて、~
それでも症状が出るかを試してもらえますか?~
~
 ●(2012/11/13) 00:05 <himajin925さん>
 
 TEXT → 同様です(いや、正常ケースがなくなるかな。
 116の右で右クリックすると 赤字で「2.戦いの…」が確かに表示されるけど、
 左で右クリックでは、いつも「1.…」のまま?)
 STOP → 演奏を再開すると、「1.ソロモン…」のまま、で同様です
 いずれもマクロ $1{ の中を書き換えました
●(2012/11/13) 00:34 <開発者>~
~
もう一つ、実験してもらうことを思いついたので、試してもらえますか?~
本来「2.戦いの…」が表示されなければならないのに「1.…」のままになっている状態で、~
Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。~
次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。~
これでも「1.…」のままになっているか否かを試してみてください。~
~
 ●(2012/11/13) 17:39 <そなさん>
 
 XP SP3なので試してみました。
 再現できましたorz
●(2012/11/13) 21:05 <開発者>~
~
ご報告、ありがとうございます。~
Museのバグである公算が高まってきたのは残念ですが、~
再現する試験者が増えたのは心強い限りです。~
お手数ですが、お手すきの時に以下の実験をして結果を教えてもらえますか?~
=====~
本来「2.戦いの…」が表示されなければならないのに「1.…」のままになっている状態で、~
Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。~
次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。~
これでも「1.…」のままになっているか否かを試してみてください。~
~
 ●(2012/11/13) 21:18 <himajin925さん>
 
 (1)「最小化→元に戻す」または「他のウィンドで隠す」いずれも、
    「演奏中」「演奏停止」どっちでも、「1.ソロモンの…」のままです。
 (2)次いで、文字列そのものを疑っていろいろやってみました。
 文字列の中身をまず疑ったのですが(全角スペース+D など)どうも違うようで(4.饗宴の踊り…では発生しない)
 そのスペースを半角に置き換えたりしてみているうちに、どうも「30バイトの文字列が指定された場合に発生する
 のではないか」という推測に達しました。
 
 *MARK"12345678910百千万億兆"
 *MARK"012345678901234567890123456789"
 *MARK" 2.戦いの踊り Danza guerresca"
 
 ↑全角・半角の違いが分かりにくいですが…いずれも30バイトのはずです
 この3ついずれでも発生します。また「4.饗宴の踊り…」でも半角文字を1つ削除すると、
 やはり発生します(30バイトになります)。
 30バイト以下と超える場合で処理が分かれる、など何かありますか?

 ●(2012/11/14) 09:08 <そなさん>
 
 > 本来「2.戦いの…」が表示されなければならないのに「1.…」のままになっている状態で、
 > Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
 > 次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
 > これでも「1.…」のままになっているか否かを試してみてください。
 
 やってみました。
 再生中 停止中 ともに「1.…」のままでした。
 起動直後の演奏では正常に切り替わることが多い気がします。
 
 ついでに 30バイト説も実験
 $2{*MARK" 2.戦いの踊り Danza guerresca"}→元のまま→発生
 $2{*MARK" 2.戦いの踊りDanza guerresca"}→スペースを削除→正常に表示
 $2{*MARK" 2.戦いの踊り Danza guerresca+"}→最後に+を追加→正常に表示
 $2{*MARK"012345678901234567890123456789"}→発生
 $2{*MARK"012345678901234567890123456789+"}→正常
 $2{*MARK"01234567890123456789012345678"}→正常
 
 書く位置を変えてみる
 ${2}を 1小節前に書く→発生
 ${2}を8分音符分後ろに書く→正常
 
 こんな感じでしたが お役に立つでしょうか〜?
 
 追記
 
 ver 
 5.82 発生せず
 5.92 ↓
 6.01 ↓
 6.03 発生せず
 6.21 発生
 
 109小節目の頭から再生すると発生率高め?
 クラのロングトーンがあるから?
  
 MARKをSTOPに書き換えて 
 > 本来「2.戦いの…」が表示されなければならないのに「1.…」のままになっている状態で、
 > Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
 > 次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
 
 すると 色のみ赤に変化

 ●(2012/11/14) 10:56 <H.N.WPKIDSさん>
  
 Windows 7 上で動くWindows XP Mode で症状を確認しましたのでご連絡します。
 当該症状のにつきまして、同様の結果が出ました。
 こちらは再現率が高い *MARK を *STOP に変えた時のスクリーンショットとシステムのプロパティ画面です。
 なお、互換モードでXP SP3を動かした時では発生しませんでした。  
#ref(MARK2.png)

 ●(2012/11/14) 12:54 <木下さん>
   
 再現性は100%ではないですが,症状が出ていますので報告します。
 
 OS:Windows2000 SP4
 
 マークの文字列が更新されない条件
 ・「シバの女王ベルキス」MARK"2. "とMARK"4. "
 ・譜面モニタでマークの前の位置でリロードする
 ・マークの文字列は丁度30文字(全角文字は2と数える)
 
 状況
 ・1度更新されないと,その後の更新されない確立がかなり上昇する
 ・シーク開始位置で確立が変化する
 ・譜面モニタ114の2拍目の確立が高い
 ・確立が100%や0%の場所は無い
 ・↑でのリロード&演奏でも再現
 
 関係が不明
 ・文法エラー表示
 
 自分のデータで上記の条件で再現しないか調査中ですが未だに再現していません。
 いま少し調べてみます。
 
 > 本来「2.戦いの…」が表示されなければならないのに「1.…」のままになっている状態で、
 > Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
 > 次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
  
 表示は更新されないままでした。 

 ●(2012/11/14) 15:46 <Elekenさん>
 
 少し気になったので、私の環境 (Windows XP SP3) でも調べてみました。
 気付いた点は以下の3点です。
 
 (1) 発生条件について
 (a) データのロード(おそらく構文解析かテンポ処理)に時間がかかる場合
 (b) *MARK や *TEXT 構文などで、テキスト内容が丁度 30 バイトの場合
 (a) かつ (b) の条件のとき、構文の直前からリロード再生を行うと発生するようです。
  たとえば、以下のデータで、譜面モニタ上の最初の小節で何度か右クリックすると再現します。
 
 *HEAD"This is a dummy." _1
 *MARK"123456789012345678901234567890" _4
 {%{#A0 v10%80:16@V-20m4%90V+20r}{#B0 v10@V-20m4V+20r}{#D0 v10@V-20m4V+20r}} (←この行を 2000 回繰り返す)
  
 また、単にファイルサイズが大きいだけではだめで、構文がある程度複雑でないと再現しないようです。
 
 (2) 発生条件を一度満たした後の Muse の挙動について
 一度この現象が発生した Muse で、現象が再現しないはずの他のデータを読み込んだ場合でも、
 (b) の条件を満たしただけで同じ現象が発生します。
 このことから、この現象は Muse の内部状態を変化させていることが示唆されます。
 
 (3) 現象が発生する Muse のバージョンについて
 最近の古いバージョンは持っていないのですが、Ver. 2010 では発生せず、 
 Ver. 2012 では既に発生することを確かめました。
 よって、この間の更新が現象の一因になっていることが示唆されます。

 ●(2012/11/17) 16:30 <himajin925さん>  
 
 SetWindowText なら、戻り値はどうでしょう?( GetLastError は有用な情報は返してくれない?でしょうが) 
●(2012/11/17) 17:55 <開発者> ~
~
早速試してみたのですが、結果は TRUE でした。orz~
再現性は確保できているので、科学的にアプローチできます。~
~
今は、履歴データによって現象が出たり出なかったりする件を追っていました。~
これもまた微妙な按配です。~
ほんの少し履歴データを変更すると、途端に現象が出なくなります。~
Museデータを、ちょっち変更すると出なくなるのと同じ印象です。~
まるで、ガラス細工のようです(苦笑)。~
~
で、再現する状態でプログラムを少しずつ削り取っていって、~
症状が出なくなる瞬間を把握しようと思って作業していたのですが、~
結局、MuseWikiの(対処)の項に記載したのと同じ結果に行き着きました。~
~
テキストエリアに表示する文字列のメモリ確保を1バイト増やすか、~
履歴データのパス文字列のメモリ確保を1バイト増やすか、~
どちらか一方でも行うと症状は出なくなります。~
~
アライメントの関係かとも思い、~
コンパイルの最適化オプションを外すなどもしてみたのですが、~
結果は同じでした。~

> OS依存の現象のようで、大変そうです(^_^;)が、お待ちしてます~
現時点の対処方法(1バイト余分にメモリ確保)は、今一つ釈然としないのですが、~
一応今まで追跡した内容からして、~
限りになく患部に近い所に薬を塗れているのではないか、~
と思い始めてきました。~
~
 ●(2012/11/18) 14:59 <Elekenさん>  
 
 個人的にはとても原因が気になります。
 以下は Ver. 6.26 で試した結果です。
 
 まず、デバッガ(Spy++)でウィンドウメッセージをトレースしたところ、問題が生じるタイミングでは
 そもそも WM_SETTEXT メッセージが発行されていないようです。
 次に、同一タイミングでたくさんの 30 バイトの MARK コマンドを発行するようなデータ
 ( *MARK"MARK 01_______________________" の数字部分を 01 〜 32 まで変える)
 で試したところ、
 
 ・いくつかの MARK コマンドによる WM_SETTEXT が発行されない
 ・どの MARK コマンドが表示されないかは、リロードされるたび変わる
 ・逆に、リロードしない限りは、先頭から再生を繰り返しても、表示されない MARK コマンドの種類は変わらない
 
 という結果になりました。
 問題はリロード時に生じているのではないかというのが、私の推測です。
●(2012/11/18) 16:41 <開発者> ~
~
> 問題が生じるタイミングではそもそも WM_SETTEXT メッセージが発行されていないようです。~
> 問題はリロード時に生じているのではないかというのが、私の推測です。~
これは、かなり核心を突いているかもしれません。~
この仮説に基づいて、再度追跡してみます。~
~
ちなみに、~
> 以下は Ver. 6.26 で試した結果です。~
ということは、V6.26aでは、やはり症状は抑え込まれているということでしょうか?~
~
> ・逆に、リロードしない限りは、先頭から再生を繰り返しても、表示されない MARK コマンドの種類は変わらない~
もしかしたら、この状態でMIDIファイルのエクスポートをしたら、~
そのMIDIファイルも、当該のMARK文が欠落した状態かもしれませんね。~
Museは演奏データとMIDIエクスポートデータを一元化しているので、~
MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。~
~
 ●(2012/11/18) 21:56 <Elekenさん>  
 
 > ということは、V6.26aでは、やはり症状は抑え込まれているということでしょうか?
 そうです。今のところ、V6.26a では症状は生じていません。
 ちなみに、V6.26 を互換モードで起動した場合では、Windows 2000 以外のモードでは症状は生じません。
 
 > MIDIエクスポートデータは、そのまま演奏データのダンプデータとして活用できます。
 なるほど!早速試してみました。
 症状が出た状態で MIDI エクスポートをしても、正常なデータが出力されるのみです。
 ということは、メモリ上のデータは全て正常??
 OS 依存ということも考えると、私の考えていたより問題の根は深いのでしょうか・・・
●(2012/11/18) 16:41 <開発者> ~
~
> OS 依存ということも考えると、私の考えていたより問題の根は深いのでしょうか・・・~
多分、メモリ上のデータは全て正常だと思います。~
しかし、どこかでMuseがデータ以外のメモリを壊していることが考えられます。~
症状はMARK表示の演奏時に出ますが、Elekenさんが推察されているとおり、~
リロード(あるいはロード後の後処理)で既に破壊工作は完了しているのではないかと(苦笑)。~
~
ちなみに、~
> ではそもそも WM_SETTEXT メッセージが発行されていないようです~
の件を追試してみましたので、ご報告します。~
SetWindowText()をコールしている箇所で、デバッグライトにて~
・SetWindowText()の戻り値~
・SetWindowText()で送信している文字列内容~
を確認してみました。~
~
なんと面妖なことに、Spy++でメッセージが送られていない状況でも、~
・戻り値は、TRUE~
・文字列は正常な30文字~
が確認されました。~
つまりデータは壊れていない、ということを裏付けていると思います。~
~
Elekenさんのご指摘の通り、演奏時点での症状から追跡するのを止めて、~
データロード時点の不具合を追跡してみようと思います。~
(2012/11/14) 15:46 で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回指定をすると症状が出ません。~
どうも、無名マクロの処理にバグが混入している気がしてきました。~
今度こそ、犯人の潜むアジトを特定できるといいのですが・・・。~
~
●(2012/11/18) 16:41 <開発者> ~
~
経過報告です。~
> (2012/11/14) 15:46 でElekenさんが作ってくれた「純正培養データ」の純度を更に高めることができました。~
更に、純度を高めることができました。~
 *HEAD"This is a dummy." _1
 *MARK"123456789012345678901234567890" _4
 %
 #A0
 { d }
 { d }
 { d }
  ・
  ・
  ・
 (↑この行が多い程、再現確率が高まる。10,000行あれば楽勝で出現)
だいぶ敵陣に近づいてきたような気がします。~
ただ、無名マクロの処理はとっても複雑なので、気が重いです。(苦笑)~
~
 ●(2012/11/23) 03:26 <Elekenさん>  
 
 失礼ながら実行時の Muse(ver.6.26) をメモリダンプして解析したところ、次のことが分かりました。
  *メモリ上に確保された MARK 文のテキストの最初の文字 (半角スペース) から見て、オフセット -3 バイト目のメモリが、
   ・正常に表示されるテキスト -> 0x01
   ・表示されないテキスト -> 0x11
  になっている
 このアドレスのメモリが何を表すのか分かりませんし、他の環境でどうなるかもわかりませんが、この共通点は少し怪しそうです。

 ●(2012/11/24) 00:16 <himajin925さん>
 
 SendMessage (SETTEXT) で送るメッセージが HEAP の末尾に来た場合、メッセージが飛んでいないようです。
 なぜそうなるのでしょう?
 Win95、98、Me ではおきず、XP 2000 でおきるというと、SendMessage の変換 (UNICODE 関連)のあたりの
 仕様の違いに関連ありそうとは思いましたが、これはという情報はまだ見つかってません。
 
 症状が一定しないのは、きっと単なるリロードでは HeapCreate しなおしていない?のではないか、と思いました。
 前のコンパイルの HeapAlloc したメモリが残っている、などないでしょうか?
 
 32バイトちょうどだとなぜ末尾に来るのか?
 (もしかすると、このメッセージの分を HeapAlloc する際、拡張が起きているのかな?)
 なぜ末尾ではいけないのか?←これが問題ですね。まだまだ分かりません。
 
 ただ、どうも「アプリのバグ」という感じではない、と思います
 
 多分 私の環境でも、release ビルドだったら、HeapAlloc したときの保護バイトが付かないだろうから(?)、
 Heap の最後に確保されるように工夫して、SendMessage してみようと思います。

 ●(2012/11/24) 02:20 <Elekenさん>  
  
 > SendMessage (SETTEXT) で送るメッセージが HEAP の末尾に来た場合、メッセージが飛んでいないようです。
 なるほど!
 謎(の一部)が解けました。
 つまり、昨日の投稿でのオフセット -3 バイト位置は、HeapAlloc でできたメモリ管理用構造体で、
 0x01 は空きあり、0x11 はヒープ末尾を表すフラグだったわけです。
 
 この NULL 終端がヒープ末尾に来る文字列の問題は、以下の簡単なプログラムで確認できます。
 
  HANDLE hHeap = HeapCreate(0, 16384, 16384);
  int i, ret, cnt = 0, alloc_bytes = 32;
  char* p_last, * p_first, *p;
 
  p = p_first = (char*)HeapAlloc(hHeap, 0, alloc_bytes);
 
  while(1){
  	p_last = p;
  	sprintf(p, "Allocation #%04d.______________", cnt++); // 終端込みで 32 バイト
  	if((p = (char*)HeapAlloc(hHeap, 0, alloc_bytes)) == NULL) break;
  }
  
  HWND hWnd = (HWND)0x001F0A78; // 適当なウィンドウ
 
  for(i=0; i<10; i++){
  	_sleep(1000);
  	ret = SendMessage(hWnd, WM_SETTEXT, 0x00, (LPARAM)p_first); // 表示される
  	printf("text= %s, ret = %d\n", p_first, ret);
  	_sleep(1000);
  	ret = SendMessage(hWnd, WM_SETTEXT, 0x00, (LPARAM)p_last); // 表示されない
  	printf("text= %s, ret = %d\n", p_last, ret);
  }
  HeapDestroy(hHeap);
 
 必ずしも 32 バイトの HeapAlloc が問題なわけではなく、HeapAlloc を呼び出した時点の残り割り当て可能領域に依存します。
 例えば上記プログラムなら、こちらの環境 (WinXP, コンパイラ VC++6.0) では、少なくとも
 (ヒープ領域サイズ, 割り当てサイズ) = (16384, 32), (16384, 24), (8192, 24), (8192, 16) のときに発生します。
 
 スレッドをまたいで WM_SETTEXT を送信するので、カーネルがテキストをコピーする必要があり、
 そのときにカーネルのバグで、NULL 終端を越えて走査しようとしてしまう・・・というストーリーでしょうか?
●(2012/11/24) 11:09 <開発者>~
~
> HeapAlloc を呼び出した時点の残り割り当て可能領域に依存します。~
思い当たる節があります。~
純正培養Museを作る過程で、本来必要なFree()部分をコメントアウトしたら、症状が出なくなりました。~
また、機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。~
~
 ●(2012/11/24) 17:36 <Elekenさん>  
 
 あまり自信はないですが、
 複雑なデータをロードした後の状態が、ヒープの断片化を起こしていて、
 リロードした後、テキスト構文のメモリ確保の段階で
 末尾に丁度 32 バイト分の空きがあるヒープ断片が存在して、
 VS2005 の malloc がそこを優先的に割り当ててしまうということなのでしょうか。
 
 もしカーネルのバグだとすると、それ以外のライブラリは全て仕様内の動作をしているので、解決策は
 ・SendMessage で送信する文字列の NULL 終端 の次のバイトがヒープの外にならないようにする
 という一点で、そのためには、
 (1) 文字列領域は 1 バイト多く確保する
 (2) 別に用意したヒープ末尾でないバッファに文字列を一旦コピーして、それを SendMessage する
 (3) ヒープ断片化が起こらないように、ヒープは自分で管理する。リロードの度に HeapDestroy -> HeapCreate
 
 …のどれかをとればいいように思います。
●(2012/11/24) 20:01 <開発者>  ~
~
解決策のご提示、ありがとうございます!~
~
> (1) 文字列領域は 1 バイト多く確保する~
これは、まさにV6.26aの対応そのものですね。~
~
> (2) 別に用意したヒープ末尾でないバッファに文字列を一旦コピーして、それを SendMessage する~
今回の格闘の最中、実はこれを実施した記憶があります。~
SendMessage()する前に、別途確保した文字列変数に問題の文字列内容をコピーし、~
それをSendMessage()に送ってみました。すると、症状は出ませんでした。~
ただ、演奏時点の処理負荷が増えるので、対応策としては却下していました。~
~
場当たり的に試行した私の実験と、論理的に導いたElekenさんの対応策の結果が見事に一致していますので、~
Elekenさんの今回の真因推理はかなりの確度で正しいと思えます。~
~
> (3) ヒープ断片化が起こらないように、ヒープは自分で管理する。リロードの度に HeapDestroy -> HeapCreate~
私の技術力からして、この対応は継続的にメンテナンスしていく地震がありません。~
じゃなかった、自信がありせん。そういえば先程、横浜で比較的大きな自身がありました。~
じゃなかった、地震がありました。~
~
> …のどれかをとればいいように思います。~
という訳で、「(1) 文字列領域は 1 バイト多く確保する」を正式な対応とすることが、~
現時点では濃厚です。~
~
 ●(2012/11/24) 21:53 <himajin925さん>  
  
 32Byte で発生するなら、なぜ他の 8 の倍数バイトで発生しないのかも謎です。
 それとも、mus ファイルの内容によっては、(見つけていないだけで)発生する場合があるのかな?

 ●(2012/11/25) 02:23 <Elekenさん>  
  
 > 32Byte で発生するなら、なぜ他の 8 の倍数バイトで発生しないのかも謎です。
 > それとも、mus ファイルの内容によっては、(見つけていないだけで)発生する場合があるのかな?
  
 それが一番の謎です。
  
 ヒープ領域固定の場合、32 byte の malloc がヒープ終端に来るケースは、
 malloc(HeapAlloc) のオーバーヘッドが 8 byte なので、ヒープ残量 40 byte のときです。
 この状態で、30 byte *TEXT の代わりになるような、*TEXT 文の組み合わせも存在しそうに思います。
  
 このときに連続して malloc すると問題になるパターンは、
 (32 byte), (1-8 byte -> 16byte), (13-16byte -> 8 byte) の 3 パターンです。
 しかしながら、30byte *TEXT の代わりに (6byte *TEXT -> 14byte *TEXT) などとしても、問題は起こりません。
  
 Muse でのケースは、ヒープ断片化を起こしていると考えられるので、より複雑です。
 つまり、malloc 関数には「末尾 40 byte 領域」をアロケートする他に、別の領域を使う選択肢があるからです。
 (他に、ヒープを広げるという選択肢も!)
 malloc 関数は 前述の状態において、24 byte よりも小さい領域が指定されたとき後者を選択し、
 25-32 byte が指定されたときのみ、前者を選択するのではないでしょうか。(メモリ効率上、賢い戦略だと思います)
  
 このあたりは、malloc のソースコードを見ないとわからないので、全く確証が持てません。
   
 なぜ「32」byte かは、もし仮にマクロ展開時に作る構造体が 25-32 byte なら
 説明がつきそうですが・・・。

 ●(2012/11/25) 09:37 <himajin925さん>  
  
 しつこいなぁと思われたでしょうが(^_^;)
 これで、「Muse にバグはなかった!」で良いでしょうね。よかったよかった
  
 (1)純粋培養 Muse の様子を見ていて、症状の起きない 95-Me の互換モードでは、XP でのメモリ管理と違う
    (ヘッダを見ると、95-Me はバイト単位での割り付けかと想像される→別の API で割り付けてる?)ので問題がおきない?
 (2)XP 以降では 8バイト単位の割り付けになるが、開放されたブロックの再利用の仕方
    (同じ大きさの開放領域があればそれを使うが、その探し方)が Vista 以降で変更になったそうで、
    そのせいで XP でだけ発生するのでしょうか。ただ、そうだとすると同様の条件になるケースはありそうだと感じます。
    XP で顕在化しただけで、Win7 でも…いや何らかの修正がされているのかな?
 (3)ちょうど 40 バイト空いていた場合だけではなくて、
    ちょうど 16バイト空きで 8バイトの文字列…
    ちょうど 24バイト空きで 16バイトの文字列…
    …
 なんていうことが、データによってはありそうですが…そのうち見つかる可能性もあるのかな
  
 で、やはり +1 とするのですか?
●(2012/11/25) 11:09 <開発者>  ~
~
*Elekenさん~
> なぜ「32」byte かは、もし仮にマクロ展開時に作る構造体が 25-32 byte なら~
> 説明がつきそうですが・・・。~
Elekenさんって、まるでシャーロックホームズみたいですね!~
~
私が掲示板(2012/11/24) 11:09 で書き込んだ、~
> また、機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。~
を具体的にお示しします。何か考察のヒントになるかもしれません。~
~
既に純正培養Museでは3つの構造体しか使用しておらず、~
利用しないメンバーもどんどん剥ぎ取っていますので、~
以下の様な簡素な内容になっています。~
 // ノート構造体 --------------------------------
 typedef struct t_note {
 	struct t_note* mpz_next;	/* 次ポインタ */
 	char* mpc_txt;			/* コマンド文字列 */
 	DWORD mh_tim;			/* イベント時刻(ミリ秒) */
 	char mc_mid;			/* MIDIデータ */
 } T_note;
  
 // データ展開ワーク ----------------------------
 typedef struct t_work {
 	struct t_work* mpz_next;	/* 次ポインタ */
 	char* mpc_data;			/* データ文字列 */
 	int mi_num;			/* ★行番号 */
 } T_work;
  
 // 定義マクロリスト ----------------------------
 typedef struct t_macr {
 	struct t_macr* mpz_next;	/* 次ポインタ */
 	char* mpc_name;			/* マクロ名(無名マクロの場合はNULL) */
 	T_work* mpz_p0;			/* ★開始アドレス( { の次) */
 	T_work* mpz_p1;			/* ★終了アドレス( } の前) */
 	char mc_ext;			/* ★展開中フラグ */
 } T_macr;
この中の★印の付いたメンバーは、現時点の純正培養Museでは使用していません。~
そこでこれらの★付きメンバーも剥ぎ取ろうとしたのですが、1つでも取り払うと症状が出なくなってしまいました。~
~
*himajin925さん~
> しつこいなぁと思われたでしょうが(^_^;)~
いえいえ、むしろ“真実を追究する”真摯な姿に感動さえしています。~
少々大袈裟かもしれませんが、~
この姿勢は、科学者や検事や医師などの職業を問わず、~
人のあらゆる活動で尊重されるべきものだと思います。~
~
> で、やはり +1 とするのですか?~
はい。可変長文字列のmalloc()だけ1バイト余分に確保するようにしようと思います。~
ほとんどは、コンパイル時の一時的な確保ですから、永続的にメモリ効率を落とす訳ではないし、~
演奏時にも確保し続けるのは、テキストの表示文字列と譜面モニタの属性表示文字列、~
履歴データのパス、楽譜出力用のタイトル群とスルーコマンド位です。~
そもそもたった1バイトですので、大勢に影響は無いでしょう。~
~
※その対応箇所のコメント文には、今回の趣旨が分かるように書いておこうと思います。~
 さもないと10年後の自分が見直した時、無駄なメモリを確保している!~
 と、戻してしまいそうです(笑)。~
~
> これで、「Muse にバグはなかった!」で良いでしょうね。よかったよかった~
とても安堵しています。\(^o^)/~
でもこの“戦いの踊り”が終わり、お二人とエキサイティングなやりとりもできなくなると思うと、~
ちょっち淋しい感じもしたりして(苦笑)。~
~
記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。~
~
 ●(2012/11/25) 02:23 <Elekenさん>
   
 > 機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。
  
 メモリをみたところ、「末尾 40 byte 領域」を持つヒープ断片は
 <24 バイト, <16 バイト, <8 バイトのデータが規則正しく埋まっているようです。
 ご提示頂いた構造体と照らし合わせると、前2者は t_macr, t_work であるようです。
 ( malloc ではサイズが 8 バイト単位に切り上げられます)
 このへんの絶妙なバランスが、「末尾 40 byte 領域」を導いていたと推測しています。
  
 しかし、すみません、折角ご提示頂いたのですが、これ以上の探求は
 ライブラリの malloc, free の解析を伴うので難しいです。
 これでゲームクリアとさせていただきます(笑)。
  
 himajin925 さんの仰るような未確認バグデータに対応する意味も含めて、
 +1 バイト余計に確保することはスマートな解決策だと思います。
 malloc 1回で 8〜15 バイトの無駄ですから、1 バイトのオーバヘッドは誤差のようなものだと思います。
  
 > 記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。
 このソフトウェアが "muse.exe" を名乗っているのを見ると、Muse のアイデンティティってなんだろうと暫し考えてしまいます。
 テキスト領域と鍵盤ひとつあれば Muse なのかな?
  
 ともあれ、Muse は思っていた以上によく考えられて設計されているのだと、
 ただただ感服するばかりです。
 今回は難しいパズルを見つけた気がして、少し書き込みすぎてしまいました。
 一番楽しんでいたのは私だったかも知れません。




*(V6.25)演奏会場の設定で[COPY]押下するとクリップボード末尾に不正文字が付く場合がある [#w42c4af9]
**状況(2012.10.25) [#s67717d5]

V6.26にて対応済み。~

(原因)~
V6.10より音源メニューにおける各音源のバージョン表示を撤廃したが、~
その際、演奏会場の設定ダイアログからの変数削除が完全でなかったため、~
初期化されていない文字列を添加して、クリップボードに出力していた。~

(対処)~
バージョン表示に関する不要な変数を完全に削除し、クリップボード出力の際に、~
それを添加しないようにした。~

(補足)~
本障害対応とは別件であるが、利用OSによって切り分ける処理を施し、~
テキスト表示エリアの背景色は、極力メニューバーの配色と等しいデフォルト色を~
採用するよう工夫した。~

**概要(2012.10.24) [#n38ad6b3]
演奏会場の設定ダイアログにて[COPY]ボタンを押下すると、現在選択されている~
演奏会場設定のMuse文法記述がクリップボードに出力される仕様であるが、~
その際、出力された文字列の末尾にゴミが付いてしまう。


*(V6.24)楽譜スルーを指定するとセミコロンのコメントで文法エラーになる場合がある [#o37cc339]
**状況(2012.09.23) [#ff4350aa]

V6.25にて対応済み。~

(原因)~
LilyPondに対応する前は、マクロ記述直後にダブルコーテーションを記述すると~
文法エラーとなるため、何の考慮もせずに次の文字処理に移行させていた。~
V6.2より、楽譜スルー指定の新設によりダブルコーテーションもコマンドの先頭を~
識別するデリミッタ文字となったが、上記の処理シーケンスに手を加えることを~
失念していた。そのため、ダブルコーテーションの内外判定で不整合を生じた。~

(対処)~
マクロ終了時に、デリミッタとしてダブルコーテーションを検出した際~
フリップフロップのフラグを立てて処理を継続するように改修した。~

**概要(2012.09.23) [#w7444ded]
Muse V6.24 において、
 ${macro} "r4" d4 ;
 $macro{}
が、「d4; が記述ミス」というエラーを発生させます。
ちなみに、行末のセミコロンを削除した
 ${macro} "r4" d4 
 $macro{}
は正常に動作します。

*(V6.23)移調楽器yでパラメータ省略すると、PDF出力楽譜の音程が狂う [#oac0b972]
**状況(2012.09.13) [#o37bb18f]

V6.24にて対応済み。~

(原因)~
移調楽器コマンドでパラメータが省略された際に、メンバー属性値を採用する処理が欠落していた。~

(対処)~
省略時にメンバー属性値を採用する処理を追加した。~

(補足)~
V6.24より、muse.exeのプロパティに版権やバージョンをセットすることとした。~

**概要(2012.09.13) [#ibb780d2]
例えば、y+++ や y/+5 といった形式で、移調楽器のパラメータ(調性や移調)を省略すると、~
PDFに出力した楽譜の音符が、極度の低音側に記譜されるなど乱れた状態になる。~
ただし、演奏は正しく行われている。~

*(V6.22)同時刻内のON/OFFノート整列処理がうまく効かない場合がある [#m39237d7]
**状況(2012.09.02) [#ce9752e2]

V6.23にて対応済み。~

(原因)~
タイ(&)による音符の統合処理の際、OFFからONへのポインタを更新していないにもかかわらず、~
同時刻内の整列処理において、そのポインタを参照して条件判定を実施していた。~
そのため、統合処理で除去されシステム上不定状態となったノートの値を参照することとなり、~
レアケースでの不具合が生じることとなった。~

(対処)~
OFFとONのノート間を双方向ポインタに強化すると共に、統合処理の際にリアルタイムに更新し、~
整列処理に影響を与えないようにした。~
また整列処理の条件も見直し、強弱ゼロ(v0)の音符に対してより効果的な順序変更を施すようにした。~

**概要(2012.08.31) [#bd2f3bdc]
V5.5より同時刻内のOFFノートを前方に、ONノートを後方に整列させる処理を組み込んでいるが、~
その処理が(非常にレアケースではあるが)、機能しない場合があった。~


*(V6.21)Windowsの古いOS(Win95/98/Me)で起動しない [#d7d4055c]
**状況(2012.09.01) [#y2f72db7]

V6.23にて対応済み。(但し、Win95は除く)~

(原因)~
Muse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更したため。~
Micorosoftのポリシーもあり、VS2008の通常ビルドではWindows2000以上のOSを要求するようになった。~

(対処)~
ビルド時にWindowsVersionのマクロを強制的に古いID番号にセットすることで問題を回避を試みた。~
通常古いID番号をセットすると、新しいAPIを活用できなくなるが、~
Museは古いAPIだけで組み立てられているので、ビルド時の問題は皆無であった。~
が、しかし、結果としてWindows Me で起動すると、新しいWindows OSの導入を促す警告ダイアログが出現し、起動はできなかった。~
そこで、1世代古いビルド環境であるVS2005を採用することにした。~
Win95は対応できないが、Win98以降のOSであれば起動可能となった。~

(補足)~
本対処の模索中に、V6.22がリリースされた。
V6.22では、演奏会場の設定のタイプ選択をラジオボタン形状に変更すると共に、~
演奏会場およびフィンガー情報のダイアログにて、タブストップによるフォーカス移動を可能とした。~

**概要(2012.08.21) [#dff9bf90]
V6.20からWindowsの旧バージョン(いまだにWindows Meですが...)対応されなくなったんですね。~
起動時に「...新しいバージョンのWindowsが必要です...」~
のメッセージが表示され起動できませんでした。~


*(V6.20)未定義の起動パラメータ文字を指定するとシステムエラーのダイアログが出現する [#tbbdaf45]
**状況(2012.08.19) [#tc87074b]

V6.21にて対処済み。~
~
(原因)~
従来から内包していた潜在バグ。~
オプション文字の解析をする際、未定義文字を検出した場合の脱出条件にミスがあった。~
具体的には、文字のデリミッタ到達で判定するところを、文字アドレスがNULLであるかの判定をしていた。~
なおMuse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更した。~
従来不運にも症状が出なかったのは、コンパイル結果の実行モジュールにおけるメモリ管理方式の差異と考えられる。~

(対処)~
正しい脱出をするように改修した。~

(補足)~
今回の改修に伴い、オプションの列挙記述も可能とした。~

**概要(2012.08.19) [#p52afc5b]
(その1)~
 従来のショートカットのままMuseを起動したところ、エラーが出るようになりました。
 v6.1までは発生しないエラーです。
 ---------------------------
 〈Muse〉システム状況
 ---------------------------
 ファイルがオープンできません
 \\hoge\muse\-$
 ---------------------------
(その2)~
 不正なコマンドライン文字列を与えると、長時間ハングした後にエラーを返す。
 数十秒ハングした後、意味不明なエラーを返すので、是非改善すべきかと思います。

*(V6.20)初期化ファイル(muse.ini)に指定したテキスト背景色が正しく反映しない [#t6750463]
**状況(2012.08.19) [#r967a343]

V6.21にて対処済み。~
~
(原因)~
Muse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更した。~
そのコンパイル処理の差でsscanf()関数の書式指定の処理仕様に変更が生じた模様。~
16進文字を数値に変換する際に正しい結果が得られなくなった。~

(対処)~
sscanf()ではなく、strtol()を利用することで回避した。~

(補足)~
今回の改修を機に、ソース内のすべてのsscanf()をstrtol()に変更した。~
これにより、muse.exeのサイズが(極僅かではあるが)コンパクト化するという副次効果を得た。~

**概要(2012.08.19) [#v35c7f3b]
テキストエリア背景色の設定が反映されない。~
muse.ini に TCL パラメータを指定したとき、赤成分が無視され、常に 0 と見做されるように見えます。~


*(V6.02)途中再生で演奏を開始すると各種コントロール指定が無効になってしまう [#oe14d2e4]
**状況(2011.11.26) [#oe285c35]

V6.03にて対処済み。~
~
(原因)~
途中再生からの演奏開始指定において、そこまでのコントロール属性をそれ以降の演奏に反映させるため~
時系列に内容をバッファリングし、最終的なコントロール属性のみを音源に送信する機構を組み込んでいる。~
それらの送信は演奏開始の冒頭で、短時間に一気に実施される訳であるが、~
特にプログラムチェンジ(楽器指定)コマンドは、音源側での処理に時間がかかるため、~
高い密度でコマンドを送信すると処理渋滞が発生し、その後に続くコマンドの処理に欠落が生じてしまう。~

(対処)~
プログラムチェンジの送信に関しては、一定のインターバルを与えて送信するように改修した。~

(補足)~
なお本件とは直接関係は無いが、今回のマナーアップにて、Windows7向けのUI改善も施した。~
・ウィンドウ移動におけるディスプレイの四隅フィッティングの調整~
・デフォルトのMuseカーソルの形状変更~
・デフォルトのテキストエリア背景色の変更~
・メインウィンドウのシークバー上下マージンの調整~
・ドラムの試聴におけるドラムセット選択ボタンを標準化~

**概要(2011.11.18) [#x44d092c]
・メンバー属性の一部(特にV指定)が無視されている。(恐らく初期設定のV127になっている)~
・V指定について遅延命令が有効にならず、階段状に音量が変化する。~
・特定メンバーのS指定が無効になって0になっている。~
・特定メンバーのバンクセレクト(/8)が無効になっている。~
・途中再生で症状が発生し、最初から演奏すると正常な動作を見せる。~
・正常に演奏する場合もある。~
・音源としてSC-88proを使った場合のみに再現される。(MSGS、Timidity+では再現されず)~

なお、W=、R=、Q=の頻用が原因と思われたため、それらを制御していたフィンガーを~
全てコメントアウトすることで症状が抑制するも、やはり時々同じ症状が出た。~
そこで該当フィンガーに絞らず、データ内すべてのW=、R=、Q=指定をコメントアウトしたところ、症状は大幅に抑制された。~


*(V6.01)メニューのプルダウンを出した状態で譜面モニタをクリックすると小節線の表示が切り替わってしまう [#k2415381]
**状況(2011.10.17) [#jdd3305e]

V6.02にて対処済み。~
~
(原因)~
譜面モニタ上のマウスカーソルの位置はリアルタイムに検出し、そのエリアに応じてカーソル形状を変更している。~
その処理に伴って、検出したエリアIDを記憶しておき、マウスクリックが起こった際にエリアIDを参考に処理分類を行っている。~
しかし、マウスが譜面モニタのクライアント領域から外れた際、そのエリアIDをクリアしていなかったため~
メニュープルダウンでのフック状態から復帰した際に、直前のエリアIDに呼応する処理が発動されてしまった。~

(対処)~
マウスが譜面モニタから外れた際、エリアIDをクリアする処理を追加した。~

**概要(2011.10.08) [#ycec2281]
Museの不具合(?)だと思うのですが、~
譜面モニタを開いた状態で、一度「ファイル(F)」などがあるところを開き、~
「開く(O)」などを選択したり、閉じたりせずに譜面モニタをクリックすると、~
勝手に小節などの縦の線が消えてしまいます。~
同様のことを繰り返すと、また出てくるので、モニタの下の部分をクリックしたようになるのです。~

動画を撮りました。
#ref(claw.mpg)



*(V6.00)マクロでX遅延を利用すると2回目以降の再現で遅延が効かない [#c5447938]
**状況(2011.07.10) [#p0775c41]

V6.01にて対処済み。~
~
(原因)~
Museコンパイルモジュールにて、遅延のコロンを一時的にNULLに置き換えて文法解析しているが、~
その復帰をエラー時のみに実施していたため、正常系でコロンがNULLのままになっていた。~
マクロを使用しない場合は支障は実用上の無いが、マクロ利用の場合はその文字列空間を再利用しているため、~
2回目以降はコロンが無くなったままになり、遅延指定が成されていないという解釈ミスが生じた。~
~
(対処)~
必要な解析が完了した時点で、文法エラー検出以前に直ぐにコロンを復帰するよう改修した。~
~
**概要(2011.07.10) [#ycec2281]
以下のデータでおかしな演奏になります。~
 #Z0@ P1 X71=127 X74=8
 #Z0@ {X74=72:1`2 _1`2 X74=8:1`2 _}4
 #Z1 o2 {d4r}32
音がこもっている状態から強めていって、またこもらせる、みたいなプレイをマクロで繰り返しているのですが、なぜか最初の1回しか遅延が働いてくれません。~
SD-50、S-YXG50両方で確認しています。VSCだと出ません。~
*(V5.92)ドラムメンバーに移調楽器コマンドを指定するとエラーとなってしまう [#h9ae071a]
**状況(2011.07.05) [#ydb0deb1]

V6.00にて対処済み。~
~
(原因)~
移調楽器コマンド'y'は、それがドラムメンバーに指定された場合、~
「エラーとはならないが、その指定は無視される」という仕様であるにもかかわらず~
エラー判定を実施していた。~
~
(対処)~
エラー判定を外した。~
~
**概要(2011.07.02) [#zaf041f8]

転調を頻繁に行うデータを作っているのですが、困ったことが…~
ドラムにまで判定を出してしまっているようです。~
 #Z0@ P17
 *FING "y"
 #Z1 o2rrrr
でエラーになります。ちなみに、~
 @Z P17
 *FING "y"
 #Z1 o2rrrr
では、Zフィンガーがまだ登場していないのでエラーになりませんが、~
 @Z P17
 #Z1 o2rrrr
 *FING "y"
はダメでした。~
~

*(V5.92)演奏状態でシークした際、曲が残っているのに演奏を停止してしまう場合がある [#x323c16c]
**状況(2011.07.05) [#vee1994d]

V6.00にて対処済み。~
~
(原因)~
左右矢印キーやシークボタンなどでスライドバーを移動させた際、~
つまみがシークバーの右端座標に達したかどうかを曲尾到達の判定に利用していた。~
そのため、MARK文前半に対して後半の演奏時間が極端に短い場合、~
後半の演奏が残されているにもかかわらず曲尾に到達したと判断された。~
これは、MARK文前後の演奏時間の差があまりに大きいため、~
後半のシークバーのドット数幅が1以下(実質ゼロ)になってしまうためである。~
~
(対処)~
曲尾到達の判定にシークバーの位置を利用することを止め、~
内部的に処理している演奏時間を参考に判断することにした。~
~
**概要(2011.06.26) [#aefdb7de]

Ver. 5.92 で気になる挙動に遭遇しました。~
マクロの繰返し後に *MARK を置いたデータを再生中にその *MARK へジャンプすると再生が停止する。~

 {mr}733 *MARK"M" d

を再生し、途中で左右三角ボタンや Ctrl+→・← を押すと *MARK"M" の表示が行われて再生が停止する~
( d が発音されず、再生を再開すると発音される)。~
~
{mr} を $a{mr} や $a{mr}0 ${a} としたり、音符を休符にして同じ操作をしても同様の現象が生じる。~
~
上の例では繰返し回数が 732 以下であれば現象は生じませんが、~
その限界値はマクロ定義内と *MARK 以後の音符/休符の個数に依存し、~
マクロ定義内は多い方が、*MARK 以後は少ないほうが限界値が小さくなるようです。~


*(V5.91)途中再生の際、X65(ポルタメント)指定が反映されない [#v950530c]

**状況(2011.05.12) [#xff86bc6]

V5.92にて対処済み。~
~
(原因)~
V5.34からV5.35へのマイナーバージョンアップにてシーク高速化処理を施した。~
その一環としてシーク時に出力しても意味のないコントロールを音源に送信しない処理を組み込んだが、~
その対象にポルタメントおよびポルタメントコントローラを挙げてしまった。~
~
(対処)~
シークの際に必要最低限のポルタメント関係のコントロールを送信するよう変更した。~
~
**概要(2011.05.09) [#tc06ae6e]
X65(ポルタメント)についてです。
ポルタメントは、"X65=127" のように指定しますが、他のX指定と異なり、~
この指定は途中再生に上手く対応していないように思います。~
演奏中に"X65=127" の位置を通るとポルタメント状態になりますが、~
その位置より後から途中再生すると、ポルタメント指定が行われていないかのような
状態で演奏されてしまいます。~
これについて、S-YXG50 と MU1000 の音源で確認しましたが、~
VSCのような他の音源で同じ現象が再現されるかどうかは確認していません。~
(ポルタメントは音源によって扱いが異なる場合があるようです)~
Windows XP 上で確認しました。~
~

*(V5.91)HEAD文字列に指定したフォントが反映されない場合がある [#pa1d7c85]

**状況(2011.05.12) [#sfc5dd59]

V5.92にて対処済み。~
~
(原因)~
V5.23からV5.24へのマイナーバージョンアップにてシーク高速化処理を施した。~
その開発途上でシークポイントまでテキスト表示が存在しない場合に~
フォント切り替えを実施する処理を組み込んだが、結果的にそれが不要になるシーケンスに落ち着いた。~
しかるに、開発途上でのフォント切り替え処置の削除をし忘れていた。~
~
(対処)~
フォント切り替え処置の削除を行った。~
~
**概要(2011.05.09) [#y211b962]
HEADタグのフォントの件です。~
通常HEADタグは、それ以前に書かれたFONTタグで指定されたフォントで描画されると思います。~
ところが、HEADタグの後にFONTタグがある場合、再生位置がそのFONTタグの位置の後にある状態で~
Muse のウィンドウを他のウィンドウで隠し、再び Muse のウィンドウを表示させると、~
HEADタグより後で指定したフォントで再描画されてしまいます。~
Windows XP 上で確認しました。~
~

*(V5.90)MARKに位置決めして演奏を開始すると、出だしの音が発音されない [#fb52c104]

**状況(2011.05.06) [#z8d2d40c]

V5.91にて対処済み。~
~
(原因)~
V5.90にて、文字列描画による演奏のモタレを軽減するため、~
同時刻内のノートONの後にテキスト表示イベントを移動する処理を施したが、~
テキスト表示イベントの一種であるMARKコマンドの場合、~
ノートONが発行された後にその位置で停止する状況に陥り、~
MARKから演奏を開始すると出だしの音が発音されたくなった。~
~
(対処)~
MARKコマンドは並べ替えの処理を行わず、~
モタレ軽減の処理は、TEXTコマンドのみを対象とする様、修正した。~
STOPコマンドに関してはV5.90においても本考慮が成されていたため、~
MARKもSTOPと同等の処理とした。
具体的には、MARKやSTOPを検出した際は、~
同時刻であっても異時刻に変化した場合と同じ扱いとした。~
~
**概要(2011.04.29) [#m9f3dad8]
早々で申し訳ありませんがマーキング(*MARK)にジャンプさせたときに~
MARK直後の発音が飛ばされるようなのですが...。~
分かりやすいのは、開発者様の「交響曲第7番(ベートーベン)」を読込んで~
第2楽章にスライダーを右にジャンプさせると第2楽章最初の和音がとんでしまいます。~

*(V5.90)メニュー「データ編集」が正しく機能しない[#r12e3721]

**状況(2011.05.06) [#b3abaf2c]

V5.91にて対処済み。~
~
(原因)~
V5.90にて、バッチ処理モードの際の高速化のために処理の入れ替えを行った際、~
データ編集のためのエディタパスを管理する変数の初期化手順が狂ってしまった。~
~
(対処)~
正しい手順に修正した。~

**概要(2011.04.27) [#j8ed6ec8]
museのver5.9ダウンロードさせていたたぎました~
しかし、データ編集を押すとテキストドキュメント(メモ帳)ではなく、~
それが入ってるフォルダ(?)が出てきます~
前まではちゃんとメモ帳だったと思うのですが、、、~
~
*(V5.87)PC起動初回で演奏のモタレが生じる場合がある [#pba52f97]

**状況(2011.03.05) [#n4308b61]
V5.88にて対処済み。~
~
(原因)~
バックグランドで処理が走っている場合などの環境下でMuseが初出現のフォントをロードする際~
その処理に時間が掛かるため、演奏がモタレてしまう場合がある。~

(対処)~
Museデータのロード直後に、そのデータに使用されているフォント使って1回ダミー描画し、~
演奏開始時点で初回のフォント読込みを終えている状態とした。~
~
**概要(2010.11.02) [#e6d71198]
私が Musing したデータを Muse で再生すると、曲頭の数音が時間的に詰まって鳴る場合があります。~
パソコン起動後初回に起動した Muse で初回再生の場合には必ずそうなります。~
~
実行環境として、~
 ・rsync
 ・cp (cygwin のコピーコマンド)
 ・Windows のバックアップコマンド
にて、以下のデータを演奏させると、~

 *FONT "Times New Roman"
 _1d2d *TEXT "" dd

前半2つのドの音と後半2つのドの音との間でモタレが起こります。~
すなわち、TEXTコマンドの位置で遅延が生じます。


*(V5.86)Timidity++で演奏させた後、MIDIマッパーに切り替えて演奏させると落ちる [#jff27456]

**状況(2011.02.04) [#yc449f17]
V5.87にて対処済み。~
~
(原因)~
エクスクルーシブ・メッセージを送信した後、MIDI音源がその処理を完了したタイミングで、
アプリケーション側が用意したバッファを解除する必要があるが、
従来のMuseはその解除タイミングを得るために音源側から発信されるコールバックを活用していた。
Timidity++以外のドライバは、音源処理完了時点でこのコールバックを
アプリケーション側に投げてくれたため、正常な解除処理が行われていた。
しかし、Timidity++ドライバでは何故かそのメッセージを投げてくれないため、
前回のバッファが解除されていない状況で、
次に続くエクスクルーシブ・メッセージを処理する状況となり、
システム上の不整合が生じてハングアップに至る。~

(対処)~
エクスクルーシブ・メッセージを音源に送信した後、
バッファのデータヘッダー要素である状態フラグの監視ループに入り、
その値が完了になった時点でループを抜け出すというシーケンスに改めた。
一種のポーリングではあるが、この方式はコールバックに依存しないため
確実なバッファの解除が実施できると判断した。
また、MIDI音源オープン時にコールバックの定義をする必要が無くなり、
イベントに関する処理負荷も低減させることができたと推測している。~
~
※なお、本件とは直接関わりは無いが、V5.87のバージョンアップにおいて、
Readme.txtの改訂も実施した。
具体的には、利用頻度の高いものを極力早めに解説するという方針の基に
“第2章 Museコーディングの手引き”における節立てを組み直した。~
~

**概要(2011.02.01) [#r15c1c31]

(1)Timidity++をインストールし、Museのメニューの「音源(V)」に
Timidity++ Driverが追加された状態にしておく。~
~
(2)Museで“Timidity++ Driver”を音源として選択し、任意データを数秒演奏させる。~
~
(3)音源メニューから“Microsoft MIDIマッパー”に切り替える。~
~
(4)この状態で再び演奏を開始しようとすると、Museがフリーズ状態になった後、
しばらくして落ちる。~




*(V5.85)マクロに関するエラー表示が必要以上に出現する [#wea4fa54]

**状況(2011.01.26) [#g2c02a01]
V5.86にて対処済み。~
~
(原因)~
前回の不具合対応時に、マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施したが、~
その際、マクロ再帰処理に入る前のエラー制御変数の初期化が漏れていた。~
そのため、一番初めに検出したマクロ(エラーがあろうと無かろうと)をエラーの候補として扱ってしまい~
実際にどこか別の場所にエラーがある際に、そこもエラー表示してしまうという不具合を起こしていた。~
~
(対処)~
エラー制御変数の初期化を確実に実施するよう改善した。~
~
**概要(2011.01.21) [#w1b9ddc3]

定義マクロ、$Syn2_0{・・・}を記述せず、X行目にその展開マクロ${Syn2_0}を記述すると、~
Museはマクロが未定義であるという文法エラーを検出するはずです。~
しかし、このエラーとは直接関係のない以下のエラー表示が出現してしまいます。~
~
 (MUSE)文法エラー
   対応する定義マクロがありません。
   Y行目 → $MC-G1_01
この際、Y行目に関わるマクロには文法的なエラーは存在しません。~
そして[OK]を押下して上記のエラー表示を閉じると、この段階ではじめて以下の正当なエラー表示が出ます。~
~
 (MUSE)文法エラー
   対応する定義マクロがありません。
   X行目 → ${Syn2_0}
~
つまり、X行目にエラーがあると何故かY行目がエラーとして検出されてしまいます。~
X行目のエラーを解決すると、Y行目のエラー表示も出なくなります。~

*(V5.84)マクロ記述されたコマンドが実行されない場合がある [#nde459ba]

**状況(2011.01.19) [#p0c9cbcb]
V5.85にて対処済み。~
~
(原因)~
従前の処理シーケンスは、データに一度だけ記述するタイプのコマンド重複チェックを、~
マクロ展開処理よりも前に実施しており、しかも無名マクロの展開部ではそのコマンドの~
展開を実施していなかった。しかし当初の仕様では、マクロの繰返し数にゼロ指定が~
出来無かったため、定義部は必ず実行されるという前提を置くことができるため~
演奏データとしては矛盾無く翻訳できた。~
更にこの仕様で無名マクロを利用した場合、重複チェックに掛からない状況であったが、~
定義部と展開部が必ず同一の指定となるため、2つの指定が競合することはなく、~
事実上の問題は無いと判断していた。~
~
しかるにゼロ指定を可能としたV5.3以降、定義部でも展開部でもコマンド認識をしない状況が生じ、~
今回の症状が出現するに至った。~
~
(対処)~
マクロ展開を処理しながらコマンド重複チェックも並行するシーケンスに変更する事で、~
マクロ内に記述されたコマンドを正しく展開解析し、重複チェックも厳密に行うようにした。~
なおドラムに関しては、移調(T)および音部記号(?)を無効化する仕様を実現するため、~
マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施した。~
~
**概要(2011.01.02) [#hda326a8]

MUSEのコマンド?についてなのですが、~
音符ですと、~
  {d4}0
  {}
と書きますと、ドの音が4分音符で一回鳴ります。~
ですが、~
  {*DRUM"O1"}0
  {}
と書きますと、Oのメンバーはドラムに転向しませんでした。~
いろいろ試してみましたが、~
  {*DRUM"O1"}0
は、転向せず、~
  {*DRUM"O1"}{} もしくは、*DRUM"O1" *DRUM"O1"
は転向します。~
~
ヘッド*HEAD"moji"
についても同じでした。~
~
ひとつのMUSEデータ内で、音源別に2種類の設定を記述しようとして、発見しました。~
これは、*DRUM""や*HEAD""が、音符とは違い、MUSEデータ内のどの位置に書いても有効な事と、関係がありますでしょうか?


*(V5.83)譜面モニタの右クリック・リロードで、指揮棒カーソルが2つ出現してしまう場合がある [#n1f590c3]

**状況(2010.12.23) [#bc2c986c]
V5.84にて対処済み。~
~
(原因)~
譜面モニタがアクティブ状態で右クリックする場合と、非アクティブの状態で右クリックする場合とで~
リライトのイベントと演奏開始イベントの順序が異なり、後者を先に受信した場合に~
排他的論理和で描画している指揮棒カーソルの表示が乱れていた。~
~
(対処)~
右クリック・リロードの際、演奏開始直前で強制的に最描画のアップデートコマンドを送信することで、~
イベントの順序関係を調整し、表示が乱れないように対処した。~
~
**概要(2010.12.20) [#xb73973c]

譜面モニタが非アクティブなウィンドウ状態にある際、右クリックでリロードしようとすると~
そのクリック位置で指揮棒カーソルが2度描画され、クリック位置に指揮棒カーソルの残像が出現する。~
演奏および指揮棒カーソルの動作は正常であり、リライトすると残像も消える。~


*(V5.82)譜面モニタ属性表示にて、未使用メンバの属性が誤って表示される場合がある [#ra6c2606]

**状況(2010.11.8) [#bc2c986c]
V5.83にて対処済み。~
~
(原因)~
未使用メンバーの制御コードをクリアする際、属性値の文字列を解放していなかったため、クリアルーチンの条件から漏れて、そのままデータが残っていた。
MIDIコードの内容としてはゼロであったためAメンバーのIDと一致し、Aメンバーの属性と解釈されて譜面モニタ上に表示してしまった。~
~
(対処)~
未使用メンバーを検出した際、属性値の文字列も解放するように修正した。~
~
**概要(2010.11.6) [#xb73973c]

以下の様なコーディングをした場合に、譜面モニタでAメンバーの音量属性(V)を表示させると、~
本来Bメンバーの属性値である音量(V60)がAメンバーの音量として表示されてしまう。
 @B V60
 #A0 d r m


*(V5.81)MIDIエクスポートにて直前にロードしたHEAD内容が出力されてしまう場合がある [#y22b76ad]

**状況(2010.5.29) [#y3b940bf]
V5.82にて対処済み。~
~
(原因)~
新たにデータをロードする際、HEADコマンドの文字列内容を記憶した領域の1文字目をNULL化することでクリアしているが、~
MIDIエクスポートにおいては、その2文字目から有意な文字として活用しているためクリアされたことが認識できていなかった。~
~
(対処)~
MIDIエクスポートの際、1文字目でHEADコマンドの有無を検出するよう改修した。~
また従来のバージョンでは、HEADコマンドが存在していなくても、シーケンス・トラック・ネームを出力していたが~
今回の改修に伴い、HEADコマンドが無い場合は、そのレコードの出力そのものを行わないように改善した。~
~
**概要(2010.5.29) [#fc92833c]

HEADコマンドが存在するデータを一度ロードし、その直後に今度はHEADコマンドの無いデータをロードする。~
その状態でエクスポートコマンドでMIDIファイルを出力すると、そのMIDIファイルに一回目にロードした~
データのHEADコマンドの内容(文字列)が出力されてしまう。


*(V5.70)ショートカットでメニュー選択するとメンバーがOFFになってしまう場合がある [#zeeea9b6]

**状況(2010.4.13) [#y3b940bf]
V5.71にて対処済み。~
~
(原因)~
メンバー情報ウィンドウにて、コントロールを併用したショートカットキーでモーダル系ウィンドウを使用するメニューを選択した場合、~
そのウィンドウを閉じた時点で、メンバー情報ウィンドウにショートカットキーのアルファベット文字が送信されてしまう。~
しかも、その時点の送信メッセージではコントロールキーの併用を検出する事ができないため、~
Museアプリケーションは、メンバー情報ウィンドウ自体のキーボードによるメンバーON/OFFとして反応してしまっていた。~
なおこの障害は、メンバー情報からのメニューショートカット選択をサポートしたV5.30より存在し続けていた。~
~
(対処)~
メンバー情報がキーボードからの文字列を受けた際、その時点のアクティブなウィンドウを検知し、~
それがメンバー情報ウィンドウ自身で無い場合は、メンバーON/OFF機構を発動しないようにした。~
~
※なお、V5.70において、スペースバーやバックスペースなどのキーボード操作における障害も見つかっており、~
V5.71によってそれらにも対処した。
~
**概要(2010.4.13) [#fc92833c]

「メンバ情報」がカレントウィンドである状況下で[Ctrl]+oを押下すると、メインウィンド・メニューの[開く]のダイアログが表示される。~
次に、[ESC]キーにより、[開く]のダイアログを閉じると、O(オー)メンバーの◆が◇(disable)となる。~

本件は、[エクスポート]や[ドラムの試聴]においても、それぞれEメンバー、Zメンバーで同様の症状が発生する。~

*(V5.61)微分音長を使うと鍵盤の色が残ったまま音が鳴りっ放しになる場合がある [#ybfa7781]

**状況(2010.3.11) [#c6e1f997]
V5.62にて対処済み。~
~
(原因)~
微分音長で指定した音長がテンポの関係と相まって極度に短くなり、~
MIDIのティック値が内部処理上ゼロとなると、出音と止音が同時刻に出力されてしまう。~
この状況下において、V5.50で施した同時刻内でのノートオフとノートオンの~
順序入れ替え処理により、出音と止音の順序が反転してしまうため。~
~
(対処)~
1つの音符により発生した出音と止音が同時刻に存在していた場合、~
その状況下で生成されたノートオンとノートオフは、~
論理的には異なる時刻に存在すると解釈することで、~
順序入れ替えの処理を行わなず、次の処理ステップに移行するように修正。~
~
**概要(2010.3.9) [#ad2d54d6]

発見したのは最新版Muse(V5.61)でしたが、どうやら今年(2010年)に入ってバージョンアッ
プした5.50版から現象が発生しているようです。~

 *STOP"1−A(テンポ:120)" %
 #A1 _1 di7 _1 ri6 _1 mi5 _1 fi4 _1 si3 _1 li2 _1 ci1 _1~i28
 
 *STOP"1−B(テンポ:120)" %
 #A1 _1 di7 _1~i7 ri6 _1~i6 mi5 _1~i5 fi4 _1~i4 si3 _1~i3 li2 _1~i2 ci1 _1~i1
 
 !iの長さに関連性を見つけられませんでしたので、端数的な影響を疑ったのがBですが、
  そうすると出現パターンが変わります。
  また、テンポが変わると不都合の出現パターンも変わります。(2−A、B)!
 
 *STOP"2−A(テンポ:133)"  %%133
 #A1 _1 di7 _1 ri6 _1 mi5 _1 fi4 _1 si3 _1 li2 _1 ci1 _1~i28
 
 *STOP"2−B(テンポ:133)"  %%133
 #A1 _1 di7 _1~i7 ri6 _1~i6 mi5 _1~i5 fi4 _1~i4 si3 _1~i3 li2 _1~i2 ci1 _1~i1
 
極限までシンプルな再現データは以下の通り

 %999 di16 _1 *STOP"a"


*(V5.51)楽器の指定が反映されない場合がある [#x5201abf]
**状況(2010.2.9) [#c6e1f997]
V5.52により対応済み~
~
(原因)~
V5.50で施した同時刻内でのノートオフおよびノートオンの順序入れ替え処理において、
曲頭での特殊処理にミスがあったため、冒頭部分のコントロールが演奏リストから
離脱されたままになっていた。
~
(対処)~
曲頭部分の処理を正常化した。

**概要(2010.2.8) [#ad2d54d6]

バグらしき?ものの報告:添付したファイルStorymus.txtをmuse5.50や5.51で演奏しよ
うとするとメンバーごとに楽器指定をしてあるにもかかわらず、全てのメンバーがピア
ノの音色で鳴ってしまうと言う症状です。5.47では大丈夫でした。私の使用環境はXPホ
ームエディションです。学校のXPプロフェッショナルでも同じ症状が出ました。

 #A0 dms
 #B0 @P49 msc
 #C0 @P57 <msc>
 #D0 @P26 <<msc>>




*(V5.50)途中から再生(シーク)させると正しく演奏されない場合がある [#p47df2a0]
**状況(2010.2.7) [#sc3a94ae]
V5.51により対応済み~
~
(原因)~
シークの高速化(演奏開始までの待ち時間短縮)のために、最終的に無効となるコントロールコードを音源に送出しない処理を施しているが、コントロール間で順序関係のあるものに関しては本処理に掛けない様にしている。モノオンとポリオンはそのコントロールに該当するが、プログラム上、高速化処理に該当するコントロールとして扱っていた。
~
(対処)~
モノオンとポリオンに関しても高速化処理から外す様、プログラムの修正を行った。

**概要(2010.2.7) [#hc7ba3f6]

 打ち込みをやっていたところ、奇妙な現象に遭遇しました。
 X126(モノ オン)で同時発音数を1にしていたのをX127(ポリ オン)で戻した時です。
 普通に鳴らすと普通に鳴るのですが、途中から鳴らすと…
 VSCとTimidityで発生、MSGSではドラムでなく普通の楽器でダンパー付ければ発生。
 Wingroove、S-YXG50、SC-8850はそもそもポリ オンにならなかったので発生も何もなし。
 
 #Z0@ X126=127_4%
 #Z1 {o3 d+4o2r}4
 %*MARK "その1"
 
 #Z0@ X127=1_4%
 #Z1 {o3 d+4o2r}4
 %*MARK "その2"
 
 #Z0@ _4%
 #Z1 {o3 d+4o2r}4
 %
 
 その2から演奏させると、ポリ オンが効かず、シンバルが切れます。
 ただし普通に鳴らすと問題なく演奏しています。
 
 途中からの演奏で情報を切り詰める際、最後から見ているような感じですね。
 コントロール番号が違うから、別物として見ているような…


*(V5.47)中身の無いマクロを記述するとハングする場合がある [#v23f76b6]
**状況(2010.1.9) [#nc920eec]
V5.50により対応済み~
~
(原因)マクロの解析処理において、展開作業終了後作業用メモリの解放を行っているが、中身の無いマクロに関してメモリ開始アドレスと終了アドレスの位置関係が逆転しており、解放時に管理外のメモリにアクセスする状態になっていた。~
ハング症状が出たり出なかったりする事象は、管理外のメモリ内容がPCの使用環境により偶然NULLであったり有意であったりすることで起こったものと推測される。~
~
(対処)マクロの開始終了アドレスをセットする処理部分で中身の無いマクロ状態を認識し、適切な判断材料を記憶する事で上記事態を回避する制御に改めた。~


**概要(2010.1.4) [#z3a66748]
以下の様な記述をするとMuseがハングする

 ${macro2}
 
 $macro2{ _d }0
 $macro1{ }0

症状を起こす条件として以下の2つの条件が成り立つ場合~
・最後に中身の無いマクロが繰り返しゼロで指定されている(macro1)~
・休符から始まる有意なマクロが上記と別に存在する(macro2)~

*(V5.46)演奏会場の設定における残響設定Delayの値が、Muse再起動でクリアされる [#bb297e5c]
**状況(2009.8.14) [#nc920eec]
V5.47として対処版をリリース~

(原因)V5.36で検出されたハード音源(MU90B)への不具合をV5.37で対処した際、大幅な変数配列構造の見直しを図ったが、そこでmuse.iniにおける値範囲の整合チェック部分
の修正に漏れがあった。muse.iniに127以上の値が書かれていた場合にゼロにすべきところが、7以上の値でゼロにしてしまっていた。~
(対処)変数と値範囲の関係を、適切な判定文に修正した。

**概要(2009.8.14) [#z3a66748]
少し前から気になっていたコトをひとつ……。~
演奏会場の設定画面についてなのですが。~

各パラメータをいじったあとで Muse を再起動すると、~
リバーブのパラメータ「Delay」の値だけが 0 に戻るのは~
何か理由があるのでしょうか?^^;~


*(V5.45)和音内連符において連符以降の音にアルペジオ指定が効かない [#rf2e7cea]
**状況(2009.8.10) [#r52e380c]
V5.46として対処版をリリース~

(原因)連符自体にはアルペジオは効かない仕様のため、連符を検出した際アルペジオ指定を無効化していたが、そのため和音内の連符の場合に連符以降の音も無効化されてしまった。~
(対処)連符検出時のアルペジオ無効化時点でアルペジオ情報を退避させ、和音が完結した時点でそれらの情報を復帰する処理を施した。

**概要(2009.8.10) [#of807d03]
和音内に連符を記述した場合、連符以降の音にアルペジオ指定が効かない。~

 [dms(<<mfmf>>)<dms>]1:8

上記の例では、始めのdmsにはアルペジオが効いているが、連符後の<dms>には効かない。

*(V5.44)ドラムセットの持ち替えが効かない場合がある [#ud1513a5]
**状況(2009.02.15) [#fc5bdc1a]
V5.45としてリリース~

(原因)~
以下の様にスタンダード・ドラム以外からドラムセットを持ち替えようとすると
うまく持ち替えられない。
ただし、本症状が出るのは、YAMAHA XG ソフト音源の場合であり、
Roland VSC などでは症状が出なかった。
したがって、本件は音源固有の問題と考えられるが、
ミューザーのコーディング効率向上やMusingにおける不要な戸惑いを無くすため
Museの不具合として扱い、バージョンアップすることとした。~

 #Z0 o2 @
 
    *TEXT"うまく鳴る"
    P17 r4 P1 P2 r
 
 *TEXT"" _1
 
    *TEXT"持ち替えない!"
    P17 r4 P2 r

(対処)~
スタンダード・ドラム以外の指定状態から、ドラムの持ち替えが行われるとき、
Muse側で強制的にスタンダード・ドラムを一旦出力してから、
所望のドラムに持ち替える様に、コンパイル・エンジンを書き換えた。
ドラムの試聴においても同様の対処を施した。~

**概要(2009.02.04) [#x7c8d316]

(第一報告)
例えばメンバーOをドラムに転向させてドラムセット(2)にします。
次にドラムセット(17)に持ち替え(?)更に(2)に戻します。
その時、メンバー情報はドラムセット(2)になっているのですが、
ドラムセットの音は(17)のままなのです。
ドラムセット(1)にすればドラムセット(1)の音が発音されているようなのですが・・・。
ドラムセット内の持ち替えは1回まででしょうか?
ちなみに音はo2のr(スネア)だけしか確認していませんが。
ついでにドラムの視聴でもドラムセット(17)のスネアを聴いて
(2)を聞くと(17)のスネアの音が残っているようです。
(1)を聞くとリセットされるみたいです。(2009.02.04)~
~

(第二報告)
ドラムセット(17)だけでなく(25)も持ち替え出来ない症状が出ました。
私の場合、回避策としては例えば(17)から(2)に持ち替える時に
一度@P1を挿入することでリセットされ(2)に持ち替えることができます。(2009.02.08)

 ;----------------------------------------------------------------------------------------
 ;*Musedby      "hiro"
 ;*MuseVersion  "5.44"
 ;*DataVersion  "1.0"
 ;*MidiDevice   "YAMAHA XG SoftSynthesizer"
 ;----------------------------------------------------------------------------------------
 
  *HEAD"         Muse ドラムセット   by : hiro"
 
 #O0  @ P2     X7=105 V100 o2 v100 *DRUM"O" U+20
 #Z0  @ P1     X7=100 V90  o2 X99=24 X98=36 X6=68
 %118
 
 #O0  _1 | _2. v110r16// v95r v110l v100l
 
      $OI2{$OI'{$Orset1{$O6{_4 v110r8// _4. v100r8// _} | $O7{_4 v110r8// _4. v95r8// _}}
      ${O6} | $O9{_4 v110r8// _4. r8// v95r16// v100r}} | ${Orset1} | ${O6}
      _4 v110r8// v100c _16 v110c32/ v95c v110c16// v95c v110c v95l v100s8//}
 
      $OE{@P17 @V-10${Orset1}3 | ${O6} | _2 v110[rc]8// v95,16// v100, v110, v95l v100s8// }@V+10
 
      $OI2-2{@P2${OI'} | ${Orset1}
      _4 v110r8// v95r16// v100r _ v110c v95c v100l  v110c v95l v110s v100f
      @V-15 @P25 v110[sr]8// v95,16// v100,{v110 , v95, v110, v100,}3 @V+15 @P2}
 
      ${Orset1}3
 
 #Z0  _1`2
 
      $ZdI{$Zd6{v110d4// _8 v95d8// _16 v110d16// v100d8// _4}7 | $Zd13{v110d4// _2.}}
 
      $ZdE{@P25 $Zd74{v110d4// v95d v110d v100d}7
      v110d4// v95d8.// v100d16// v110d4// v100d }
 
      @P1 ${Zd6}7

(第三報告)
ドラムセットデータV2を送付いたします。
こんな感じにしてみましたが、如何でしょうか?(2009.02.09)

 ;----------------------------------------------------------------
 ;*Musedby      "hiro"
 ;*MuseVersion  "5.44"
 ;*DataVersion  "2.0"
 ;*MidiDevice   "YAMAHA XG SoftSynthesizer"
 ;----------------------------------------------------------------
 
  *HEAD"         Muse ドラムセット   by : hiro"
 
 #O0  @ P2     X7=100 V100 o2 v100 *DRUM"O"
 #Z0  @ P2     X7=100 V100 o2 v100 
 
 #O0  _1 | @P2 r4/ @P17 r  @P2 r @P25r | @P17 r
 
 #Z0  _1 | @P2 d4/ @P17 d  @P2 d @P25d | @P2 d
 
 
 ;メンバOの表示@P2→P17→P2 →P25→P17
 ;     演奏 P2→P17→P17→P25→P17と聞こえます
 ;メンバZの表示@P2→P17→P2 →P25→P2
 ;     演奏 P2→P17→P17→P25→P25と聞こえます
 


*(V5.43)アルバムに1曲も存在しないのにセパレータが表示される場合がある [#t3b73af5]
**状況(2008.10.28) [#afb5288f]
V5.44としてリリース~

(原因)履歴機構において初期化忘れの変数があった。~
(対処)正しく初期化した。~

**概要(2008.10.28) [#of807d03]
履歴メニューの階層下に更に階層がある状態で、
その直下にマウスで複数の曲を登録していくとセパレータが現れる。~
その状態で先程登録した階層直下の曲を次々に削除していくと、
最後の1つを消した段階で本来セパレータも消えるはずのところ、
それが残ってしまう。


*(V5.42)大量の音符が重なった部分で行番号検索を実施すると落ちる [#t3b73af5]
**状況(2008.07.28) [#afb5288f]
V5.43としてリリース~

(原因)表示用文字列配列のガード部分に不完全な判定があった。~
(対処)ガードの不備を改訂した。~

**概要(2008.07.19) [#of807d03]
添付ファイルのデータで今回の目玉機能の音符クリックを行うと
(自宅PCでは)十中八九落ちてしまいます。
 *FING"x2"
 %
 #A0 {${A}} #A1 {} #A2 {} #A3 {} #A4 {} #A5 {} #A6 {} #A7 {} #A8 {} #A9 {}
 #B0 {} #B1 {} #B2 {} #B3 {} #B4 {} #B5 {} #B6 {} #B7 {} #B8 {} #B9 {}
 #C0 {} #C1 {} #C2 {} #C3 {} #C4 {} #C5 {} #C6 {} #C7 {} #C8 {} #C9 {}
 #D0 {} #D1 {} #D2 {} #D3 {} #D4 {} #D5 {} #D6 {} #D7 {} #D8 {} #D9 {}
 #E0 {} #E1 {} #E2 {} #E3 {} #E4 {} #E5 {} #E6 {} #E7 {} #E8 {} #E9 {}
 #F0 {} #F1 {} #F2 {} #F3 {} #F4 {} #F5 {} #F6 {} #F7 {} #F8 {} #F9 {}
 %
 *STOP""
 *STOP""
 $A{o4c1^1}
無論ここまでの使い方をする人はいないと思いますが。
ハードなデーターでどこまで行くか想像できないので
ストッパーをかけた方がいいのかな・・・と思います。


*(V5.41)楽器の試聴における方向キーの動作不正 [#w9b187b9]
**状況(2008.07.17) [#ib67e1c1]

V5.42としてリリース済み。~

(原因)ダイアログにおけるコントロール属性のタブグループの設定ミス。~
(対処)タブグループ属性を正しくセットし直した。~

(追記)本対応に便乗し、以下の改良を実施した。~
譜面モニタ行番号検索において、マクロ記述対象の場合、~
その表示行番号を「展開側」と「定義側」の両方とする。

**概要(2008.07.17) [#of807d03]
楽器視聴のウィンドウでP121〜P128列にタブで移動し、上下を押していくと…~
P121で上を押すとおかしな動きをし、~
P128で下を押しても反応ありませんでした。~
他の部分と比べると、一貫性に欠けているような気がします。


*(V5.40)極端に長い演奏を記述すると動作が不正となる [#p6a5cb68]
**状況(2008.07.17) [#y2f79d7e]
V5.41にてリリース済み。~

(原因)Double Word で処理してる演奏カウントが、
オーバーフローする時点でエラー処理を施していなかった。

(対処)エラー処理を追加した。

(追記)本件の対応に伴い、譜面モニタ行番号検索機能の強化も実施する予定。~
・マクロや再現表記の行番号対象を、定義部から展開部へ変更~
・複数の音符矩形が重なっている場合は列挙表示~
・異なるファイル名がロードされた際、行番号表示をクリア~


**概要(2008.07.13) [#y55ed3fc]
 {d1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`9629}999
を中盤あたりから再生すると音長がおかしくなる。~
ちなみに、~
 {d1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`9629}4
までは正しく表示される。

 {d1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`29999^1`9629}5
これは異常となる。マクロが4の時より演奏が短くなる。


*(V5.37)独音名表記x2と音部記号?を組み合わせると調性が狂う場合がある [#u7bdac75]
**状況(2008.07.11) [#y2f79d7e]
V5.40にてリリース済み。~

(原因)今までのプログラムは、調性無視を明に処理しているのは“h”のみであった。
何故なら“b”の方は初めから半音階の音価であるため、
調性記号で指定されるシャープやフラットが掛からない(対象になるはずがない)と
判断したためである。
ところが、音部記号?を使用した場合は、たとえ“b”であっても、
全音部分にシフトする場合がある。
したがって、“b”も調性を無視する処理を加える必要がある。

(対処)以下の処理仕様に改修した。
 ドイツ音名の場合、音名“b”は調性を無視する。
 また、音名“h”はフラット系の調性を無視する。

(追記)厳密に言うと本件の対処で上位互換が崩れるが、
音部記号と独音名を併用するデータは
極めて少ないと想定され、現実的には問題がないと判断している。
また、本件はあくまでもバグの対処であるため、積極的に互換性を崩す仕様変更ではない。~

**概要(2008.06.27) [#b074da86]

アルト記号の場合のドイツ式表記の場合の h b の扱いに関しての質問です。~
音部記号に関わらず、第3線に音符がある場合、調性(又は臨時)記号で~
フラットが付いている場合 b~
フラットがない場合 h~
と記述する、と思ってきましたが、その理解であっているでしょうか?~

いま入力に挑戦中の曲に♭6つの調が出てきて、ビオラのパートの音が変で、分からなくなってしまいました~
以下の例を演奏してみてください
 \------;変ト長調の場合
  
 ;ト音記号
 #A0 x2 ?0 o3 g4 a b < c d e f g _2 ;b でOK
  
 ;ヘ音記号
 #A0 x2 ?6 o5 e4 f g a b < c d e _2 ;b でOK
 
 ;アルト記号
 #A0 x2 ?3 o4 f4 g a b < c d e f _2 ;b ではおかしい
 #A0 x2 ?3 o4 f4 g a h- < c d e f _2 ;OK→h- と記述しなければならない?
 
 ;テノール記号
 #A0 ?4 x2 o4 a4 b < c d e f g a _2 ;これは b でOK

アルト記号だけ扱いが違うのか、勘違いかな?



*(V5.36)ハード音源(MU90B)にて、演奏会場の設定があると再生ができない [#n19a67fe]
**状況(2008.06.14) [#l132cce1]
V5.37にて対応済み。~

(原因)演奏会場の設定のためのエクスクルーシブは、連続したデータアドレスを持つため、~
送信効率を高める様にリバーブ・コーラスを1つのエクスクルーシブにまとめていた。~
この送信方法は他の音源ではうまく機能していたが、MU90Bにおいては動作しないことが判明した。~
具体的には、以下の条件でMU90B側が動作不良(ハング)となる模様。~

 Reverb Send Level To Chorus(36h) を受信した後、
 連続して Reverb Predelay Time(37h) を受信するとハングする

MuseのROOMコマンドは、Reverb Send Level To Chorus(36h) を対象としていないが、~
上述の1つのエクスクルーシブ送信を実現するために、(36h)にもダミーで常にゼロをセットし送信していた。~
結果として、上記の動作不良条件を満たすことになった。


(対処)リバーブとコーラスの指定を分離し、更にリバーブに関しては(35h)までのデータと(37h)データを別々に送信するよう改訂。~
ただし、コーラス内の一連のデータは従来通りまとめて送信させた。~
今回の改訂内容を、*DATAコマンドで表現すると以下のようになる。

 <従来>
 *DATA"41,10,42,12,(40,01,30,r1,r2,r3,r4,r5,r6,00,r8,q1,q2,q3,q4,q5,q6,q7,q8)"

 <今回>
 *DATA"41,10,42,12,(40,01,30,r1,r2,r3,r4,r5,r6)"
 *DATA"41,10,42,12,(40,01,37,r8)"
 *DATA"41,10,42,12,(40,01,38,q1,q2,q3,q4,q5,q6,q7,q8)"

MU90Bにおいても、今回の方式で正常動作することを確認済み。~


(追記)本件の対処の際、以下の仕様が機能しないという潜在バグを発見したため改修した。~
「Muse演奏の最中に[COPY]ボタンを押すと、その時点の演奏会場ダイアログの指定がその場で演奏に反映される」~

**概要(2008.06.03) [#ldc75676]
<第一報告>~
このたび「 YAMAHA MU90B 」を購入しまして、自作の Muse データを演奏させてみたのですが、
曲によって演奏されるものとされないものとがありました(汗)~
自分なりに調べたところ、「ある時期」を境に古いデータはちゃんと演奏され新しいものは演奏されないことに気づきました。
データ作成の日付と Muse Wiki にあった Muse の更新履歴を照らし合わせてみたら、
どうも「ROOM コマンド出現以降の Muse データ」が MU90B で演奏されないようなのです。~
ただし、
過去データで XG リセットを入れた2曲だけは、演奏できることにも気づきました。~
そこで、試しに ROOM コマンドが入ってるデータに XG リセットを入れてみたところ、
それまで演奏できなかったデータがちゃんと演奏されました。
また、ROOM コマンド記述の行をコメントアウトするとやはり演奏できます。~
MU90B でリバーブ&コーラスのシステムエフェクトを使うには、
自力で XG リセット&エクスクルーシブを入れるしか解決策が無いのでしょうかね?^^;~
MU90B は TG300B モードにも対応してるハズなんですケド……(???)~

<第二報告>~
「Domino」にて、Muse からエクスポートした MIDI ファイルを調べてみましたら、~
GSリセットのあとに~

 f0h 41h 10h 42h 12h 40h 01h 30h 04h 04h 00h 40h 40h 00h 00h 00h 02h 00h 40h 08h 50h 03h 13h 00h 57h f7h

というエクスクルーシブがはき出されていました。~
これは、リバーブ&コーラス設定を一気に書いてあるものなのでしょうか?~
この MIDI ファイルを「Domino」で再生しても、MU90B では演奏できません。~

そこで、~
 f0h 41h 10h 42h 12h 40h 01h 30h 00h 0fh f7h ;リバーブ
 f0h 41h 10h 42h 12h 40h 01h 38h 00h 07h f7h ;コーラス

のように、リバーブとコーラス設定を2つに分けてエクスクルーシブを書き直したところ、~
同じファイルが MU90B で再生できました。~
このあたり解決につながるかもと思い報告でした。~


*(V5.35)途中再生の際、波形加工が正しく反映されない [#a12ada3b]
**状況(2008.05.18) [#r983634a]
V5.36で対処済み。~

(原因)V5.35でシーク処理を全面的に改良したが、その際NRPN/RPNの波形加工値制御において、~
全メンバーを1つのフラグで管理していたため、複数のメンバーが絡むと最適化による不要メッセージの~
送出抑止が過度に働き、必要なメッセージも止められていた。

(対処)波形加工値制御のフラグを16メンバー独立で設け、適切な抑止処理となるよう修正。~
また今回の対処に伴い、ハード音源にも許容できる範囲でシークのインターバルを低減させ、~
より高速にシークできるよう改善した。

**概要(2008.05.17) [#e662b0a6]

Museのver.5.31では問題ないが、
ver.5.35で以下の記述を途中再生すると
メンバーAが正しく再生されない。
 #A0 @Q=64._8@Q=10.
 #A1 _d
 #B0 @Q=.64
 #B1 s

更に、コンパクトにすると以下でも再現する。
 #A0 @Q=64. _8 @Q=10. _8 d4
 #B0 @Q=.64 s4

ただし、Bメンバーを休符にすると再現しなくなる。~
また、Aメンバーで冒頭の@Q=64.を指定しないと再現しなくなる。~
更に、Aメンバー行とBメンバー行の記述順を入れ替えても再現しなくなる。~

なお、Roland系では上記の不正を聞き取りにくく、YAMAHA系では聞き取りやすい。~
<確認しやすい音源>~
・YAMAHA AC-XG WMD XG Symth~
・YAMAHA SXG~
<確認しにくい音源>~
・Microsoft GS Wavetable SW Symth~
・Roland VSC~
・WinGroove~

*(V5.34)波形加工遅延の記述があるとシーク(途中再生)の開始が極度に遅くなる [#wab00be5]
**状況(2008.04.25) [#p40e509c]
V5.35で対処済み。~

(原因)Muse内部でのMIDIメッセージ構築の際、重複する無駄なコマンドを除去しているが~
波形加工の遅延による時間軸方向へのデータエントリー展開状況を考慮していなかった。~
そのため、シーク時の高速化処理(最終値を決定しそのメッセージのみ送信)にて、~
波形加工とは異なるRPNコマンドに対して、波形加工遅延で発生した大量の~
データエントリーを音源に垂れ流してしまう状況に陥っていた。~
この様な状況下で演奏が開始されると、メッセージ渋滞が起こり、~
演奏再開時に音源側で、メッセージを高速に処理する現象が出現した。

(対処)無駄なコマンド除去の不具合を修正。~
今回の対応に伴い、波形加工遅延も最終値のみの送信とし、
更に、他のメッセージに関してもシーク最適化を強化した。

**概要(2008.04.09) [#e662b0a6]
 {#A0  |@Q=0.127:8_8Q=127.0:8_8Q=0.127:8_8Q=127.0:8_8
        Q=0.127:8_8Q=127.0:8_8Q=0.127:8_8Q=127.0:8_8|
  #A1  |o4x1c4ccc|}12

のようなデータを書いた場合の途中再生について後ろの方から途中再生しようとすると~
演奏開始までに数秒かかり、演奏が始まった直後は非常に高速な再生になります。~

ただ、ソフト音源では再現しないことからMIDIケーブルの転送速度の問題かなと思います。~

バグではないと思いますが、譜面モニターで右クリックし途中再生しようとすると~
聞きたいところがうまく聞けないために作業効率が低下します。~




*(V5.33)FINGコマンドでアクセントwが記述エラーとなる[#lc780847]
**状況(2008.03.07) [#s30ffec1]
V5.34で対処済み。~

(原因)単純な実装漏れ。~
アクセントコマンドをサポーとした V5.1から内在していた不具合となる。

(対処)実装した。~
Readme.txtへの記載も漏れていたため対処。

**概要(2008.03.07) [#ge41d985]
FINGコマンドにアクセントwを記述すると、文法エラーが発生しはじかれる。~
FINGパラメータの一番はじめにwを記載したときは正常動作するが、~
二番目以降に列挙した場合はエラーとなる。~

○ *FING"w+10"~
○ *FING"w+10 q-20"~
× *FING"q-20 w+10"~



*(V5.32)音量Vのマイナス方向への相対指定で最終値が負値になる [#lc780847]
**状況(2008.02.23) [#s30ffec1]
V5.33で対処済み。~

(原因)V5.20リリース時点で、ソースプログラムの整理を図ったが、その際に混入したデグレード。~
数値の大小比較における仮変数へのセット手順にミスがあった。

(対処)正しい手続きに改訂した。

**概要(2008.02.23) [#ge41d985]
例えば、@V50 d V-80 m と記述した場合、ミの音が負値(-30)になり、~
そのままMIDI音源に送られるため、逆に大きな音として演奏されてしまう。


*(V5.32)繰返し数ゼロの展開マクロ以降のデータがコンパイルされない [#n6490b5f]
**状況(2008.02.21) [#s30ffec1]
V5.33で対処済み。~

(原因)展開マクロの再帰呼び出し処理において、繰返し数がゼロの際のリターン値が不正であり、~
データ解析処理の終了処理に移行してしまっていた。

(対処)展開マクロの繰返し数がゼロの場合、そもそも解析処理の対象から外すシーケンスに変更した。~

(補足)今回のマイナーアップ(V5.32→V5.33)に伴い、譜面モニタのグリップスクロール操作の改善もついでに行った。~
「譜面モニタの小節線移動(アウフタクト)の反応を、小節番号付近のみとした」~
これにより、ほとんどの小節線上でもグリップスクロール可能となり、~
頻度の高いグリップスクロールの操作性が向上する。

**概要(2008.02.21) [#ge41d985]
繰返し数ゼロの展開マクロを記述すると、それ以降に記述したデータがまったく演奏されない。


*(V5.31)メンバー情報ダイアログの「M」の文字が欠けてしまう [#fd087033]
**状況(2008.02.11) [#s30ffec1]
V5.32で対処済み。~

(原因)★☆記号とメンバー記号(A〜Z)のスタティック部品が微妙に重なっていたため。~
今回のメンバー情報ダイアログのフォントサイズを変更したことで症状が表出した。~

(対処)部品間にマージンを入れて、どの様なフォントであっても重ならないようにした。~

**概要(2008.02.11) [#ge41d985]
ところでメンバー情報を開くと、メンバーMの字で左側の縦棒が欠けて表示されますが、私だけでしょうか?

http://musewiki.dip.jp/pho/member.jpg

*(V5.30)メンバー情報ダイアログをクローズし再び開くと楽器名が表示されない [#qfa7c8f9]
**状況(2008.02.09) [#qc53163f]
V5.31で対処済み。

(原因)無駄な再描画を極力抑止するための機構に不具合があった。~
現在、表示されている楽器名およびバリエーション番号の記憶域を~
ダイアログクローズの際にクリアし忘れており~
再度オープンした時にまで再描画抑止機構が働いていた。~

(対処)クローズ時に、変数クリアを実施。


**概要(2008.02.09) [#qa8684f6]
演奏途中にメンバー情報ウィンドウを閉じて、再度開いたときに~
メンバーの名前が消えてしまいます。~

楽器の持ち替えが発生したタイミングでメンバーの名前が復活するようです。~

XPクラシックスタイルですが、同様の症状が再現しています。~


*(V5.26)譜面モニタ末尾の右クリックでメンバ色一覧の楽器名が消える [#y1c50e9d]
**状況(2008.01.12) [#sd966c6d]
V5.27で対処済み。

(原因)V5.23の障害を対応した際、譜面モニタ曲尾クリック時に曲頭から演奏を
開始してしまう症状を副次的に発見し、演奏せぬように対応したが、
その対処方法が中途半端であったため。~
V5.25での対処は、右クリックのリロード後、
演奏停止ポイントを曲尾にシフトしておらず、
加えて新たにロードしたデータでのシーク処理も施していなかった。~
そのため、演奏開始ポイントにおける楽器名がクリアされた状態のままとなった。
しかも演奏停止ポイントが未処理だったため、再度演奏を開始させた際、
不安定な状況に陥った。

(対処)譜面モニタ曲尾クリックの際、演奏停止ポイントおよびシーク処理を
完結させ、Museの内部制御状況の矛盾を取り払った。


**概要(2008.01.08) [#pe62a8f1]
譜面モニタ上で、曲の最後の部分(もう演奏される音がない部分)を右クリックすると、
メンバ色一覧の楽器名が表示されなくなります。
また、その状態で鍵盤を左クリックしても音が鳴りません。
さらに、しばらく再生したままにするとエラーが発生し、強制終了されました。
それを何度か繰り返したところ、MUSE自体が正常に作動しなくなりました;;
(曲を再生しようとするとMUSEがフリーズします…)

*(V5.25)履歴メニューの除去操作で追加されてしまう場合がある [#a6d84c31]
**状況(2008.01.02) [#zad4fefd]
V5.26で対処済み。

(原因)プルダウンメニューの階層が深くなり、通常右側に現れるメニューが左側に
折り返す状況になった際、既に存在している裏側のメニューアイテムが
マウスクリックされたと誤解釈することに起因する。

(対処)アイテム検出ロジックにおいて、検出時点で再帰呼び出し処理を打ちきらず、
その時点では検出アイテムを一時退避しておき、全メニューを一通り検索した後、
最後のクリックアイテムを採用することで、階層の深いアイテムを優先させる処理とした。

(追記)本件の障害とは無関係であるが、本対応バージョンにおいて以下の微修正も施した。~
・フィンガー拍数および楽器/ドラムの試聴のウィンドウ色を(Vistaに合わせ)淡い色に変更~
・iniファイル制御における“VRS:演奏停止時に音源リセット送出”のデフォルト値を
 “0:しない”とした。
(“1:する”を選ぶと、演奏停止時の負荷でMIDI音源によってはストールする
場合があるため)



**概要(2007.12.28) [#k9a83307]
【報告その1】~
階層のある履歴について最下層の曲を右クリックで削除使用とすると、
その上の階層に現在開かれている曲を登録してしまう。
3階層と4階層で確認しましたが同様でした。
#ref(history_err.png)
MUSE.log
ファイルを例えば
 *aaa
 **aaa111
 ***aaa111bbb
 ****aaa111bbb222
 *****aaa111bbb222ccc
 ******aaa111bbb222ccc333
 2007/12/29(15:26:14) 1> D:\Tools\Down_Load\muse525\SAMPLE0.MUS
 ******
 2007/12/29(15:26:14) 1> D:\Tools\Down_Load\muse525\SAMPLE0.MUS
 ***
 **
 *
 2007/12/29(15:26:14) 1> D:\Tools\Down_Load\muse525\SAMPLE0.MUS
のように書き換えます。
SAMPLE0.MUSの場所は存在する場所を指定します。(上記は仮称位置)
でMuse本体を画面ぎりぎり右側に寄せて
履歴の階層を追っていくと
上記の
 ******aaa111bbb222ccc333
の下の階層に登録されているSAMPLE0.MUSが折り返し表示されると思います。
このファイルが削除できません。

もしこのデータでテストする場合は、
書き換える前の状態のデータをバックアップしてから行ってください。

【報告その2】~
確実な再現性がとれないのですが、 自分なりに精一杯検証してみました。ちなみに、
プログラミングの知識はゼロなので、そのへんは許して下さい。

 *a
 **b
 ***c
 ****d
 ***
 **
 *
これは、大丈夫。クリックで登録も削除もできます。

 *Billy Joel
 **Bruce Springsteen
 ***Kyousuke Himuro
 ****Tomoyasu Hotei
 ***
 **
 *
これも、大丈夫。

 *Billy Joel Best Selection
 **Bruce Springsteen Best Selection
 ***Kyousuke Himuro
 ****Tomoyasu Hotei
 ***
 **
 *

これで、布袋さんのところに曲登録すると、
トラブルが発生します。登録はできますが
曲削除の右クリックを受け付けません。~
さらに、登録された後のlogは

 *Billy Joel Best Selection
 **Bruce Springsteen Best Selection
 ***Kyousuke Himuro
 ****Tomoyasu Hotei
 2008/01/01(02:39:52)       1> C:\WINDOWS\筑集眺餅\Muse\Sample1.mus
 ***
 ** 
このように、文字化けしています。筑集眺餅は
デスクトップになるはずです。まあ、餅を眺める
なんて正月らしくていいですが(笑)~
で、この状態で、この布袋さんのところの
Sample1.musを、右クリックで削除しようとすると
削除されずに(削除しますか?という確認の
窓が出ない)、ひとつ上の氷室さんのところに
新たにSample1.musが登録されてしまっています。~
この氷室さんのところに登録されてしまう
ケースは、生じるときと生じないときがあります。



*(V5.24)音域限界の音程にて譜面モニタの表示が乱れる [#oce4d484]
**状況(2007.12.09) [#s20de566]
V5.25で対処済み。~

(原因)譜面モニタの音符位置情報を符合付き1バイト変数にて処理していたため、127を越える演算部分でオーバーフローを起こしていた。

(対処)メモリ節約のため記憶する変数型は従来通りとしたが、描画位置の計算時に一時的に通常の整数にて演算を実施することで、描画を正常になるよう改修した。

(追記)障害追跡の際、譜面モニタのスクロール時に起こる別の障害も自己発見したためV5.25にて対処した。~
譜面モニタのウィンドウ右端に達しない短いデータをスクロールさせようとすると、譜面全体が一気に右端に寄ってしまい、左側に空白が生じる症状。~
スクロール処理の際、そもそもスクロール不可能な状態を検出し、ガードを掛けた。

**概要(2007.12.09) [#y947a84e]
「o9l--」と記述すると、MUSEで開くときエラーは発生しませんでしたが、譜面モニタに異常な数の下線がつき、音はなりましたが譜面モニタには音は表示されませんでした。また、「o->c+」と記述した場合は正常に表示されました。~

 #A0o9 |{l--4}4{l--8}2{l--16}4{(l--l--l--)8}4l--1
 #A0o->|{c+4}4{c+8}2{c+16}4{(c+c+c+)8}4c+1


(追記)実は o->c+ の場合も音符の位置が不正であった。


*(V5.23)曲中からの再生時に指定したフォントが効かない場合がある [#oce4d484]
**状況(2007.11.25) [#s20de566]
V5.24で対処済み。~

(原因)途中再生を実施する場合、そこまでの各種属性を高速にシークしているが、HEADを除く一回目のテキスト系表記が行われる前にフォント指定がなされている場合、そのフォントをテキストエリアに反映する処置が欠落しており、デフォルトのフォントが採用されていた。

(対処)上記の状況下において、指定されたフォントをテキストエリアにセットする処理をV5.24に施した。

(追記)障害追跡の際、以下の2項目に関する不具合も自己発見したためV5.24にて対処した。~
・途中再生の処理において、同様のシーク処理を2回繰り返していた。~
 →シーク処理を最小限に抑え、処理速度の向上を図った。~
・譜面モニタでのマウス右クリックによるリロード時、指定箇所が曲尾の場合、先頭からの再生を実施してしまう。~
 →曲尾クリックの場合は再生しないよう修正~

**概要(2007.11.23) [#y947a84e]
(不具合報告その1)~
Museのテキストですが今回指定したフォントがうまく読み込めない時があるみたいでたまにデフォルトで表示されます。その時は途中から演奏しなおせば表示されます。[JPN]のフォントでないものだからでしょうか?~

(不具合報告その2)~
フォントの指定がうまくいかないことがありましたのでお知らせいたします。まず下記のようなソースファイルを用意します。~

 *FONT"Times New Roman"
 drmf
 *TEXT"ABC"
 slc<d

譜面モニタで最初の4つの音符の間を右クリックするとフォントがTimes New RomanにならずにWindowsのシステムフォントが使われているようです。テキストが指定されている5つ目以降の音符または曲の先頭より左側を右クリックしたときは正常にTimes New Romanになります。いずれにしろ~
・Museのメインウィンドウを左クリックしたときは問題ない~
・曲の先頭で*TEXT""を指定すれば問題は起きない~
なので実害はないのですが、せっかく気づいたのでご報告いたします。~


*(V5.22)p指定で後音を前音より先に発音させると連結&の結果が異常となる [#r2bf2784]
**状況(2007.10.18) [#hded8699]
(原因)pqおよびスタッカートに依存しない連結&の処理の考慮不足。接続すべきノートOFFとノートONを除去した結果、連結後の残されたノートONとOFFの時間的な順番が逆になってしまい。音が鳴り続ける。しかも、譜面モニタの座標が別のアルゴリズムで処理されていたため表示が発音と食い違ってしまう現象も起きていた。

(対処)接続すべき2音のノートONの後先関係を調べ、上記に該当する状態の場合は連結処理を実施しないように改めた。V5.23で対応済み。

**概要(2007.10.16) [#nb6e8551]
以下のデータを実施した際、異常な解析結果となる。
 x2_2
 [ceg]4p^2q~2&[ceg]8_

今回の実装では&△箸いΦ述を,琉銘屬妊ン、△琉銘屬妊フ、
と言う風に内部処理されていらっしゃると、2つめのデータの
モニタ画像で確信しましたが(これもV5.21とは似ても似つかない出力です)、
とするならば、この最後のデータはオフ→オンの順の処理がなされ、
同じ音をもう一度鳴らせてさらにオン→オフの命令を出さない限り
ひたすら鳴りっぱなしになるのではと思っていました。実際
そうなっているようです。譜面モニタではオフとオンが逆になって
音長が表示されていますが実際にCの和音が鳴り始めるのは
モニタのオフの(ように見える)位置でそれから鳴りっぱなしに
なっているようです。

ある意味忠実なコンパイルとも言えますから、これでよいような気も
しますが(そもそもこんな記述は実際は誰もしませんし)、
譜面モニタの表示がずれるのは少々気分が悪いですね…

エクスクルーシブなどを使わずに、妙な現象を引き起こせるので
面白いと言えば面白いですが、このようにコンパイルしてしまって
良いのか、難しいところですね。オンとオフがひっくり返れば
なかなか粋な仕様とも思いますが、さらに&が続いた場合に
収拾がつかないような気もします(苦笑)。難しいところですね。


*(V5.21)連結&が他のフィンガーのpqに影響を受ける [#i9a541c7]
**状況(2007.10.14) [#q00e37c9]
明かな再現性を確認。~
V5.22で対処済み。

(原因)連結処理のアルゴリズムは同時刻のノートOFFとノートONを検出することで行っているが、その検出を高速化するため、ある条件に達した場合に検出作業を打ちきっていた。今回、pqやスタッカートに影響されない仕様に変更したことで、その打ち切り条件を以前よりも広くとらなければならないにもかかわらず、以前のまま実施していた。

(対処)ロード時に、フィンガー毎の時刻キーによるソーティングリストを作成し、それを元に打ちきり条件を決めるように改修した。これにより、今までのコンパイル速度をほぼ維持しつつ、pqやスタッカートに影響を受けない連結を実現した。

(追記)今回の障害対応に伴い、連結&はフィンガー内でのみ実施するように改めた。従来は、メンバー内のフィンガーをまたいで効果していた。

**概要(2007.10.13) [#nb6e8551]
連結コマンド"&"の仕様が,
次のようなコードではうまく機能しません.

 *FING"x1 q~64" [#pb6f27ea]
 #A0o5 [dg]4&[db][ea]&[e<c>] | [eb]&[ea][dg]&, | _
 #A1p~16q^32.o3 ({ba<c>b<dc>ag}2)1 | () | 

どうやら,他のフィンガーのp,q指定の影響も受けてしまっているようです.~
余りよく調べていませんが,

・#A1 を #B0 など別のメンバーに変えても音は途切れたまま.~
・#A1 をコメントアウトすると,ちゃんと音がつながる.~
・#A1 の q 指定を q^16 とすると,ちゃんと音がつながる.~
・#A1 の p,q 指定を p~4q^4~64 とすると,#A0 の最初のレの音だけがちゃんとつながる.~
・#A1 の音符部分を (ba<c>b<dc>ag)1 | () | とする~
(つまり,16分音符刻みから8分音符刻みにする)とちゃんと音がつながる.

などが判っています.


*(V5.20)リロード時のフォント変更反映不備 [#i9a541c7]
**状況(2007.10.12) [#q00e37c9]
明かな再現性を確認。
原因は、シーク時のちらつきを防止するために文字列内容の変更が無い場合に無駄な描画を抑止する処理に置いて、フォントが変更されていた場合は抑止しない考慮が欠落していたため。
V5.21にて修正済み。
**概要(2007.10.12) [#nb6e8551]
FONTコマンドで別のフォントに変更したデータをリロードした際、リロード直後にそのフォントに反映されず、元のフォント状態を維持してしまう場合がある。


*(V5.15)ステレオ指定のエラー検出の不具合 [#i9a541c7]
**状況(2007.09.19) [#q00e37c9]
本件に関して、バグであることを確認。~
原因は、ステレオのプラス側の処理で条件分岐の不手際。~
修正完了。

ただし、近々次期バージョン(V5.20)のリリース予定のため、~
修正版は、次期バージョンに併せて提供する。

なお、現バージョン(V5.15)において、エクスポートもMuse演奏も~
MIDIの数値制約内に強制的に納めており、演奏障害などは起きない。~
文法エラー通知のみの不具合である。
**概要(2007.09.19) [#nb6e8551]
#B1@ _2 S+664 [fl-]1~
数値は99999999までいけました。それ以上は文法エラーになります。~
なお、「-」の方は64以下で本来のエラー検出になります。~

SC-8850の全面ディスプレイでS+100,S+1000などと指定して確かめてみたところR63となっておりS+64相当であることが確認できる。

MIDIにエクスポートしてみたところ同じようにR63であった。


*(V5.14)演奏終了時に異常終了 [#dcaf6c0f]
**状況(2007.08.04) [#d7a311e7]
Ver.5.15にて修正済み。

(原因)
Muse演奏終了時に、諸々のコントロールを一気にクリアし、次の演奏曲を乱さないためにエクスクルーシブ命令を送っているが、その送信にタイムラグを入れていなかったため、音源側が処理しきれずに異常終了となった。
PCの環境やマシン性能により出現しない場合があるが、出現環境では再現性が極めて高い不具合であった。

(対処)
エクスクルーシブ処理に適切なウエイトを挿入することで対応。

**概要(2007.07.16) [#a9527d90]

時間を置いて、異なる2名が不具合報告を開発者へ送付。
症状としては「Museにて演奏終了時、あるいは演奏停止時に落ちる」というもの。

(2007.7.16)
現在最新バージョンのMUSE ver5.13を使っていますがときどきMUSEが強制終了してしまいます。
ある時はMIDIを聴こうと他のソフト(YAMAHA MidRadioPlayer)を立ち上げた時、
またある時はMUSEで曲を再生しながらIEでmixiをじっと読んでいた最中
(ページを新たに読み込んだ時ではなく表示されたページを静かに読んでいた時。曲は再生途中)
に急に起こりました。
MUSEが原因ではなく、こちらのPCが原因かもしれませんが、旧バージョンのMUSEでは
強制終了したことは無かったので一応ご報告させていただきます。

(2007.7.30)
このところMuseの異常終了が頻発しています。
先日お送りした外套のワルツを演奏終了後に落ちてしまったときのスクリーンショットを
添付します。私の環境は以下のとおりです。
Windows XP Home
Dell Inspiron 1501
CPU AMD Turion 64X2


*(V5.11)履歴曲追加・除去時の不具合 [#dcaf6c0f]
**状況(2007.07.04) [#d7a311e7]
Ver.5.12にて修正済み

2つの原因が複合した不具合であった。

(その1) プルダウンするメニューエリア以外でのクリックへの対応が漏れており、
制御アドレス外のメニュー項目を削除するという処理が動いていた。
完全なMuseプログラムのミス。

  <対処>エリア外クリックへのガードを施した。


(その2) WindowsというOSの互換性問題。具体的に言うと、
メニュー上の右クリック時、
XPにおいてはボタンアップのイベントのみが通知されるのに対し、
Meにおいてはボタンダウンのイベントのみが通知される。
V5.11では、アップイベントでのみ処理を実行していたため、Meでは動作しなかった。

  <対処>ボタンアップに加えボタンダウンでも反応するように改修した。


※アップとダウンの両方のイベントが通知されるようなOSバージョンが存在すると、
処理を二重に実行してしまうため懸念は残るが、その時は別途対処する予定。

**概要(2007.07.02) [#a9527d90]
ver.5.11でも履歴曲、削除の時の右ボタンが効かない感じがします。~
(階層は1階層のみ)(Me)~
ちなみに右ボタンでの曲登録は出来るみたいですが...?~
(USBマウスを使用しています)~

そのあとメニユー(履歴の)項目上などで右クリック
削除確認メッセージが出ると同時(時には表示されないまま)に
システムからの障害メッセージで

http://musewiki.dip.jp/pho/muse_err.png

*(V5.10)履歴機能の不具合 [#y84d189d]
**状況(2007.07.01) [#gdc2d50a]
Ver.5.11にて修正済み

アルバム機構を設定していない場合の履歴管理に不具合がありました。
ある条件文のtrue/falseを逆にしていたため、論理矛盾を起こしていました。
1文字の追加にて修正完了しました。

**概要(2007.07.01) [#ae7c1078]
ところで履歴機能ですが、ファイルをリロードする度に履歴の欄に(なし)という表示が増えていくようです。
右クリックで削除しようとしてもできません。(他の曲を除去していいか聞かれます。)
そして時々Museが強制終了してしまうことがあります。


*(V5.02)アルバムからの選択における履歴更新制御の不具合 [#ge7aa382]
**状況(2007.05.31) [#ye3d938a]
Ver.5.03にて修正済み

確実に再現するバグです。仕様では下記概要の「期待する動作」をイメージして開発しましたが、論理設計のミスで現状動作のようになってしまいました。数行の修正で治りました。

ちなみに次期バージョン(V5.10)ではある理由からこのパラメータを撤廃します。

**概要(2007.05.29) [#bdcc9b8f]
ただ気のせいだったらすいませんが、Muse.iniに追加されたLGS = 1 なんですが、説明通りの動作をしていないようなのが気になります。

説明 ←アルバムからの選択時に履歴を更新 (0:しない/1:する)

期待する動作~
0:「アルバムからの選択」で演奏した曲は履歴に記録されなくて、開くやD&Dで演奏した曲は記録されます。~
1:「アルバムからの選択」か否かに関わらず,演奏した曲は全て履歴に記録されます。

現状はこのスイッチは単に履歴機能の有無として動作しているように思えます。

0:履歴が全く更新されません。~
1:「アルバムからの選択」か否かに関わらず,演奏した曲は全て履歴に記録され
ます。


*(V5.01)テキスト系非出力のエクスポートで不正MIDIファイル [#i323ac54]

**状況(2007.05.28) [#j4387201]
Ver.5.02にて修正済み

**概要(2007.05.27) [#aa6992ae]

「MIDIファイル容量を抑えるため、テキスト系コマンドのデータを出力しない」のチェックボックスを選びエクスポートすると、指定もしていないのに所々でスィング演奏する滑稽なMIDIファイルが出力される。


*(V5.00)フィンガー拍数のプルダウンメニューが文字化けする [#i323ac54]

**状況(2007.05.27) [#j4387201]
Ver.5.01にて修正済み

http://musewiki.dip.jp/pho/WS00000022.JPG

**概要(2007.05.26) [#aa6992ae]

http://musewiki.dip.jp/pho/WS00000021.JPG

↑くさば環境(Windows2000)

http://musewiki.dip.jp/pho/mojibake.gif

↑浅川環境(Windows Me)


http://musewiki.dip.jp/pho/WS00000038.JPG

↑くさば環境(Windows Vista)正常例


*(V5.00)フィンガー拍数のプルダウンメニューから「V:音量」が消える [#g8835282]

**状況(2007.05.27) [#wfebf10d]
Ver.5.01にて修正済み

**概要(2007.05.26) [#eb94afed]
Muse起動時にはフィンガー拍数ウィンドウには「V:音量」が設定されていますが、ほかの設定に変えた場合、プルダウンメニューから「V:音量」が消えてしまう。


*(V5.00)Muse演奏終了時に音源がリセットされる [#t0fa07c1]
**状況(2007.05.27) [#x2e4e4ef]
Ver.5.01にて対応済み

(不具合というか、新仕様なんですが・・・)

muse.iniにVRSという項目を追加。以下マニュアルより引用

 ; ---------------------------------- ♪
 ;  (17)初期化ファイルでのユーザ指定
 ; ----------------------------------
 ;  ■初期化ファイル(muse.ini)は、実行ファイル(muse.exe)と同一フォルダに自動
 ;   生成されるテキストファイルであり通常はユーザが編集する必要はありません。
 ;   しかし、以下の定義行([USR]ブロック)に関しては、積極的にユーザが指定する
 ;   事が可能であり、Museの動作を制御することができます。
 ;
 ;	--------[USR]
 ;	#ED = C:\Program Files\notepad.exe  ←データ編集で使用するエディタ
 ;	#EP = /a /t /m           ←エディタの起動パラメータ
 ;	LGM =   32    ←履歴メニューにおける表示曲数
 ;	LGP =    1    ←履歴曲選択時に演奏開始      (0:しない/1:する)
 ;	LGS =    1    ←アルバムからの選択時に履歴を更新 (0:しない/1:する)
 ;	VRS =    1    ←演奏停止時に音源リセット送出   (0:しない/1:する)
 ;
 ;   (注)初期化ファイルは、Museを終了させるタイミングで出力されます。Museを
 ;     起動しながら初期化ファイルを編集する際、Museを終了してから最終的な
 ;     結果をセーブしないと、折角の編集作業が不意になってしまうため注意し
 ;     て下さい。なお、初期化ファイルの反映にはMuseの再起動が必要です。



**概要(2007.05.26) [#pbe879d6]

これについてはVer.5.0からの仕様変更ですが、ハード音源を使ってパネルで音をいじりたい場合不都合であるのでINIファイルによって制御可能にする予定。


*(V5.00)S-YXG50を使用時にMuseが落ちることがある [#t6cb015c]
**状況(2007.05.27) [#jbe3bb6c]

V5.01でサポートされたmuse.iniのVRSをオフ(0)にすることで現象を抑えられる。

S-YXG50 を「Microsoft MIDI マッパー」でアクセスするという組み合わせの場合、
VRS=0としておく回避策により解決とみなす。

**概要(2007.05.26) [#t3743dc5]
落ちるタイミングは、ファイル読み込み時、あるいは演奏終了時です。「演奏終了時」がポイントではないかと思います。
ファイル読み込み時は、現在は README.TXT のみ確認しました。
ちなみに、Roland VSC を使ってみると落ちません。
演奏に成功します。README.TXT でも全く落ちません。
ですから、おそらくその「残響制御」が原因なのではないかと思います。
過去のバージョンではそういった事は起こりにくかったです。

実際は「Microsoft MIDI マッパー」にて高確率発生する模様です。

VRS=1の時は発生しました。

VRS=0の時は発生しませんでした。

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS