Muse不具合一覧     

FrontPage

※最新版のMuseにて、既知の不具合はすべて解消しています。

(V8.32)フィンガー情報の表示文字がウィンドウに納まらない場合がある†

対応状況(2023.11.22)†

V8.33にて対応済み

(原因)
V8.32において、フィンガー情報のフォントをTrue Typeに変更したが、
このフォントは、Windows10以降にのみ標準添付されているため、
Windows7や8では不測のフォントが選ばれることになった。
WindowsOSの代替えフォント機構にて、自動的に固定ピッチが採用されると高を括って、確認を怠った。

(対処)
リソース定義上は、従前どおりMSゴシックを指定しておき、
フォンガー情報起動時に、利用OSの状況に応じて適切なフォントが採用されるよう改めた。
なお、マニュアル表示のフォントに関しては、今回の対応と同様の処理が施されていた。

障害報告(2023.11.19)†

多分、そのフォント。OSに入ってない気がします。
リサイズできないまま見切れてます。

(V8.17)長いフォント名をHEADに指定するとクラッシュする†

対応状況(2022.06.04)†

V8.18にて対応済み

(原因)
Windowsでは、フォント名の文字数は最大３１文字と定められているため、
HEADコマンド用のメモリを、末尾のデリミッタも含め３２文字分固定的に確保していた。
しかしMuse専用制御として、このメモリに１文字分のフォント修飾情報も付与しているため、
３１文字フォント名を格納した場合、１文字分のメモリ不足が生じて領域破壊が起きた。

(対処)
メモリ確保を不足なく行うようメモリ領域を拡大した。

障害報告(2022.06.04)†

以下のMuseデータをロードすると、かなりの頻度で落ちます。

*FONT"Bahnschrift Light SemiCondensed"
*HEAD"ABC"
[dms]1

(V8.11)３連符の楽譜出力を省略記述に差し替える際、装飾音扱いになってしまう†

対応状況(2021.06.05)†

V8.12にて対応済み

(原因)
LILYコマンドの「音符・休符の抑止」*LILY"±x" の処理において、和音と連符の抑止が完全でなかったことが真因。
抑止処理を音符と休符のみに施し、和音や連符の開き括弧および閉じ括弧に対しては施していなかった。
最後のクリーンアップ処理にて、無効なデータを除去しているが、括り括弧が残っていたため、
連符内和音の場合のみ除去が完全に実施されず、微小な空白休符が出現する結果となった。
この微小な空白休符が、続く修飾音の判断処理で拾われ、次音のスルー指定の音符が修飾音として扱われることになった。
なお、和音内連符においても無効なデータ除去は完全ではなく、lyファイルには中身の無い和音構成が無駄に出力される状況であった。
最終的な楽譜には譜刻されないため見た目には問題はないが、データ処理としては不備がある。

(対処)
和音と連符の抑止判断部を見直し、括弧部分も正しく抑止するよう改めた。
また、*LILY"±x"の抑止対象として連結&も加え、完全性を高めた。

障害報告(2021.06.04)†

3連符の楽譜出力を省略記述に差し替える際、装飾音扱いになってしまいます。
ly ファイルを見ると、 \acciaccatura { s128 というコードが入っています。
事象が発生する条件および回避策を検討しましたが、私の方では発見できませんでした。

; B 〜 M では発生しませんでした。
; N で発生しました。Mとの違いを見ると、MUSEの方のコードが和音か単音かの違い、でしょうか?
; O、P でも同様に発生しています。
; ただ、Q、R、Tでは発生せず、Sでは発生しました。連符かつ和音の場合でしょうか?
; Sの変形として、U 〜 W でも発生しています。
; Xは発生していない例（希望する記譜イメージに近いもの、ただし、Yのように1小節目も和音にしたい）です。
; Yは本来書いていたコードで、事象が発生している例です。

*LILY"_(8)"
"\mark \default"!A! {([>d<d],,)4}4 *LILY"-x" {}"\tuplet 3/2 { <c c'>4.:8 }" *LILY"+x" {}3  "r4"_1

"\mark \default"!B! {d8d}4     *LILY"-x" {}"c'8 c'"                      *LILY"+x"  {}3 _1
"\mark \default"!C! {d8d}4     *LILY"-x" {}"\tuplet 3/2 { c'8 c' c' }"   *LILY"+x"  {}3 _1
"\mark \default"!D! {d8d}4     *LILY"-x" {}"\tuplet 3/2 { <c c'>8 q q }" *LILY"+x"  {}3 _1
"\mark \default"!E! {[d]8,}4   *LILY"-x" {}"\tuplet 3/2 { <c c'>8 q q }" *LILY"+x"  {}3 _1
"\mark \default"!F! {[d]8,}4   *LILY"-x" {}"\tuplet 3/2 { <c c'>4.:8 }"  *LILY"+x"  {}3 _1
"\mark \default"!G! {(ddd)4}4  *LILY"-x" {}"c'8 c'"                      *LILY"+x"  {}3 _1
"\mark \default"!H! {(ddd)4}4  *LILY"-x" {}"<c c'>4"                     *LILY"+x"  {}3 _1
"\mark \default"!J! {(ddd)4}4  *LILY"-x" {}"<c c'>8 q"                   *LILY"+x"  {}3 _1
"\mark \default"!K! {(ddd)4}4  *LILY"-x" {}"\tuplet 3/2 { c'8 c' c' }"   *LILY"+x"  {}3 _1
"\mark \default"!L! {(ddd)4}4  *LILY"-x" {}"\tuplet 3/2 { <c c'>8 q q }" *LILY"+x"  {}3 _1
"\mark \default"!M! {(ddd)4}4  *LILY"-x" {}"\tuplet 3/2 { <c c'>4.:8 }"  *LILY"+x"  {}3 _1

"\mark \default"!N! {([!>d<!d],,)4}4  *LILY"-x" {}"\tuplet 3/2 { <c c'>8 q q }" *LILY"+x"  {}3 "r4"_1
"\mark \default"!O! {([>d<d],,)4}4    *LILY"-x" {}"\tuplet 3/2 { <c c'>8 q q }" *LILY"+x"  {}3 "r4"_1
"\mark \default"!P! {([>d<d],,)4}4    *LILY"-x" {}"\tuplet 3/2 { <c c'>4.:8 }"  *LILY"+x"  {}3 "r4"_1

"\mark \default"!Q! {[d]8,}4     *LILY"-x" {}"c'4" *LILY"+x"  {}3 _1
"\mark \default"!R! {(ddd)4}4    *LILY"-x" {}"c'4" *LILY"+x"  {}3 _1
"\mark \default"!S! {([d],,)4}4  *LILY"-x" {}"c'4" *LILY"+x"  {}3 "r4"_1
"\mark \default"!T! {(dd(d))4}4  *LILY"-x" {}"c'4" *LILY"+x"  {}3 _1

"\mark \default"!U! {([d][d][d])4}4  *LILY"-x" {}"c'4" *LILY"+x"  {}3 "r4"_1
"\mark \default"!V! {([d],d)4}4      *LILY"-x" {}"c'4" *LILY"+x"  {}3 "r4"_1
"\mark \default"!W! {(dd[d])4}4      *LILY"-x" {}"c'4" *LILY"+x"  {}3 "r4"_1

"\mark \default"!X! {(ddd)4}4       *LILY"-x" {{}"\tuplet 3/2 { <c c'>4.:8 }"}4 *LILY"+x"  {([>d<d],,)4}4 _1
"\mark \default"!Y! {([>d<d],,)4}4  *LILY"-x" {{}"\tuplet 3/2 { <c c'>4.:8 }"}4 *LILY"+x"  {([>d<d],,)4}4 _1

報告を受けた上記のデータから、純正培養データを作成したところ、以下のデータで症状を確認した。

*LILY"-x" ([d])4 *LILY"+x" "c4" d4

なお、連符内和音の場合のみ発現し、以下の様な和音内連符、単独の和音、単独の連符では症状が出なかった。

*LILY"-x" [(d)]4 *LILY"+x" "c4" d4
*LILY"-x" [d]4 *LILY"+x" "c4" d4
*LILY"-x" (d)4 *LILY"+x" "c4" d4

また、抑止指定を行わない場合も症状は出なかった。

([d])4 "c4" d4

(V8.10)MIDIインターフェースを介してYAMAHA QY10を接続するとMuseが落ちる†

対応状況(2021.04.21)†

V8.11にて対応済み

(原因)
症状の出る接続音源 YAMAHA QY10 は鍵盤付きシーケンサーであり、しかも接続開始時点でMIDIキーボードとしての送信メッセージ(f8)が強制的に発行される仕様であった。
一方、VSTi音源の場合はオープン時にMuse自身でWave制御のメモリを確保している。
そのため、QY10の電源をONにした状態でMuseを起動すると、 VSTi音源のオープンが完了する前に強制送信メッセージが起こる。
結果として、Wave発音のためのメモリ確保がされていない状態で MIDIメッセージの処理が実施され、メモリアクセス違反に陥った。

(対処)
起動時点の音源初期オープンが完了するまでは、MIDIメッセージの処理を実行しないよう ガードフラグを立てておき、初期オープンが完了した時点でフラグをクリアすることにした。
なお本フラグは、音源切替え処理の期間中にMIDI処理をキャンセルするために、 従前から備えているものを活用し、フラグ新設による処理構造の複雑化を回避した。

障害報告(2021.04.20)†

MIDI鍵盤から Muse経由で音を鳴らしてみようと以下の接続を試みたところ、
Museが「確実に」落ちる現象がありましたので、事後ですが報告させていただきます(；・∀・)

【症状】
　YAMAHA QY10（鍵盤付きシーケンサー）
　　↓
　　↓UX16（MIDIインターフェイス）
　　↓
　Windows10
この接続で Muse起動すると数秒で確実にMuseが落ちました。

【確認】
他の鍵盤ソフト・シーケンスソフトでは問題なくソフト起動・鳴らすことに成功。
Museでのみ、上の現象が起きました。

【解決】
　1. UX16でPCとQY10をつなぐ（QY10電源は入れない）
　2. Muse起動
　3. QY10の電源を入れる
この順番で Museが落ちることは無くなりました。
Museが落ちたのは、QY10の電源を入れたままで Museを起動していたせいだったようです(汗)

(V8.10)アルバム連続再生でリンク除去をキャンセルするとデッドロックが発生する†

対応状況(2021.04.03)†

V8.11にて対応済み

(原因)
繰り返し演奏のシーケンスは、「履歴除去の確認」と独立して組み立てられており、
確認ボタン［OK］／［キャンセル］のどちらの押下であっても、繰り返し演奏が継続されるようになっている。
もし［OK］押下によりアクセス不可のデータリンクが除去されれば、
それを除いたアルバムから次曲を選択するため、繰り返し演奏は正常に継続する。
しかし［キャンセル］が押下された場合は、アクセス不可のデータリンクがアルバムに残ることになり、
再びそのデータを再生しようとして、閉じた確認ダイアログがまた表示されるというデッドロックに陥る。
特にアルバムにリンク切れの曲が１つしかない場合は、完全な無限ループに陥る。

(対処)
繰り返し演奏で確認ダイアログの［キャンセル］が押下された場合、
演奏を停止させることによりデッドロックを回避するシーケンスとした。

障害報告(2021.04.03)†

アルバム系の繰り返し演奏を実施中に、アクセス不可のMuseデータに到達した際、
「履歴除去の確認」ダイアログが表示されますが、ここで［いいえ］を押下すると、
再び本ダイアログの表示となり［はい］を押下するまでこの状況から脱出できなくなります。

Muse自体が落ちるといった症状ではないのですが、 ［いいえ］を押下するとデッドロックに陥るため、
実用上［はい］以外の選択ができないダイアログが出てしまい、 正常なインターフェースになっていないと考えられます。

(V8.10)muse.logに記述ミスがあるとMuseが起動せず異常終了する†

対応状況(2021.04.01)†

V8.11にて対応済み

(原因)
データパス識別子「>」の文字検索結果を評価せず、そのまま処理を続行していたため、
NULLアドレスに対して演算を行い異常終了となった。

(対処)
識別子「>」の検索結果を評価し、未検出の場合は当該行をキャンセルするシーケンスとした。

障害報告(2021.04.01)†

「muse.log」で、曲名の前に付ける識別子「>」を書き忘れると、 Museが起動した瞬間に落ちてしまうようです。
Readme.txt 5856行目に従うなら、無視されると思うのですが。

(V8.04)譜面モニタが開かず、マニュアル表示でクラッシュする†

対応状況(2020.06.06)†

V8.05にて対応済み

(原因)
V8.04にて、ウィンドウ制御の効率を高めるため、ウィンドウの寸法および位置の変更において、
内部的な処理をした後、Windowsのデフォルト処理を実施せずそこで処理を打ち切るよう改変した。
処理を打ち切っても直前の寸法および位置が正当なものであれば問題ないが、
muse.ini自体が存在しない完全に初期状態からの起動の際は、ウィンドウ寸法や位置が正しく演算されない。
このため、譜面モニタやドキュメント表示は面積ゼロのウィンドウとなってしまった。
結果として譜面モニタはあたかも表示されていないかのように振る舞い、ドキュメント表示に至っては
使用するフォントサイズがゼロとなり、内部演算でゼロ除算が発生してクラッシュした。
なお、この不具合はWin7でもWin10でも同様に発症する。

(対処)
ウィンドウの寸法および位置の変更イベントにおいて、以前のようにWindowsのデフォルト処理を実施するよう改めた。

障害報告(2020.06.06)†

muse8.04を先日ダウンロードさせていただきました。
museを起動させたところ、以下の状態が見られました。

●譜面モニタが開かない
●マニュアルを表示させようとすると、muse が落ちる

確認環境:
 - 自宅pc(win7)
 - 漫画喫茶のpc(win10のように見えましたが未確認)

です。
尚、museデータの演奏は出来ました。

(V8.01)ドキュメント表示にて履歴リストに表示されない検索文字列がある†

対応状況(2020.03.14)†

V8.02にて対応済み

(原因)
メニュー表示文字列にタブを含めると挙動が不安定になるのは、
Win32apiにおける仕様である模様。

(対処)
登録の際に、タブを半角スペースに変換しておくこととした。
なお、履歴リストの表示カラムを節約するため、連続スペースの集約処理も施すこととした。

障害報告(2020.03.14)†

（タブ） hoge hoge （タブ）
と、両側にタブのある文字列をスイープすると、履歴リストに表示されません。

(V8.00)初期化ファイル設定#RMでエディタがうまく指定できない†

対応状況(2020.03.01)†

V8.01にて対応済み

(原因)
指定のエディタを起動するプロセスを発行する際、引数でReadme.txtのパスを与えているが、
Museのインストールフォルダのパスに空白が含まれている場合、空白がデリミッタとなり、
パスの一部がパラメータ引数と認識されてしまった。
メモ帳などパラメータ引数を持たないエディタの場合は問題がないが、そうでない場合はReadme.txtをロードできない。

(対処)
指定エディタを起動する際、Readme.txtのパス全体をダブルクォートで括って渡すようにした。

障害報告(2020.03.01)†

muse.ini の #RM がうまく機能していないようなんです。

#ED とまったく同じエディタへのパスを書いたのですが、本体の「マニュアル表示」を開くと空白のエディタ画面が立ち上がってしまいます。
試しにパスをダブルクォーテーションで括ってもみましたが、こうすると指定エディタは立ち上がらず初期状態（メモ帳での画面）で開きます。

(V7.87)フィンガー情報ダイアログにペダル状態が反映されない†

対応状況(2019.06.09)†

V7.88にて対応済み

(原因)
V7.10からの潜在バグ。
ペダルの遅延／先行音長をサポートした際ペダルに関する処理が複雑になったため、 新しい関数を立ち上げたが、
その関数内でフィンガー情報に反映する変数へのセットをし忘れていた。

(対処)
正しくセットするようにした。
なお本障害はダイアログへの表示のみに関わり、演奏には影響しない。

(補足)
今回のバージョンより、VS2019によるビルドに更新した。

障害報告(2019.06.09)†

以下のデータをロードしてフィンガー情報ダイアログを開き、プルダウンで Y ペダルを選んでも、表示が @A Y0 のままです。

#A0 drmf @Y1 drmf

(V7.85)曲尾到達時のリロードで演奏再開にクリックが２回必要となる†

対応状況(2018.12.12)†

V7.86にて対応済み

(原因)
V7.63から抱え込んでいた不具合。
同様の不具合がV7.03で発見されV7.04で対処したが、
V7.63の時点でシークに関する制御に手を加えた際、再び症状が出るようになっていた。
リロードの際にその時点で展開されているデータよりも演奏時間が短い場合に、
強制的に現時刻を最終時刻に律則させる処理を入れていたことが原因である。
曲尾から曲頭に戻る判断部分は最終時刻と現時刻の前後関係で行っているが、
現時刻がリロード処理で律則されてしまい、その判断が正しく行われなくなっていた。

(対処)
リロード時に強制的に現時刻を最終時刻に律則させる処理を取り払った。

障害報告(2018.12.11)†

曲尾まで演奏を聴き、シークバーが右端に到達している状態で、
現在ロードされているデータよりも演奏時間を短くしたMuseデータを「リロード(L)」すると、
鍵盤を１回クリックしても演奏が始まりません。
２回クリックすると曲頭から演奏が始まります。

(V7.85)オープン不可のファイルをドロップするとリロードできなくなってしまう†

対応状況(2018.12.12)†

V7.86にて対応済み

(原因)
ドラッグ＆ドロップのファイルパス取得先をカレントなデータパスを記憶する変数にしていたため、
不正なパスであってもそのパスに置換されてしまい、以降そのパスをリロードする状況に陥っていた。

(対処)
現在のパスを一旦退避しておき、不正なパスを取得した場合はパスを復帰するようにした。
なお、本事象と同じことが排他的起動(*x)や、データパスを引数に与えた起動においても行われていたため、
その処理も同様の手直しを行った。

障害報告(2018.12.10)†

正常なMuseデータを読み込んだ後、 オープンできないファイル（例えばフォルダそのものなど）をMuseにドラッグ＆ドロップすると、
「ファイルをオープンできません」というダイアログが出て読み込みが無効になります。
その際、既にロード済みのMuseデータには変化がなく、演奏もそのままできます。
ここまでは正しい挙動なのですが、一旦この症状を起こすと、 譜面モニタ右クリックによるリロードができなくなってしまい、
常にドラッグ＆ドロップしたファイルに対する「ファイルをオープンできません」が出るようになってしまいます。

(V7.83)XG音源でドラム転向すると途中再生で音質が変わってしまう†

対応状況(2018.10.08)†

V7.84にて対応済み

(原因)
V7.83にて、ドラムパートのP指定とX指定の順番を守る分岐処理を組み込んだが、
ドラムパートであることを判定するための情報は、Zメンバーあるいは*DRUMコマンドから得ていた。
しかし障害が発生したデータは、*DATAコマンドによりドラム転向しているため、
そのメンバーがドラムであることの判断が付かず、通常処理にてP指定とX指定の順番が変化した状態のままであった。

(対処)
ノート構造体に送信候補フラグを新設し、加えてシークを２パスで処理することで、
ドラムパートか否かによらず、常にコントロールのデータ記述順を守って送信するするよう抜本的改造を行った。
また、XGシステムONを送信した際は、インターバルを長めにとって音源側が処理を確実に行えるようにした。

障害報告(2018.10.06)†

以下のデータで再現します。

*DATA""
*DATA"43,10,4C,00,00,7E,00"

@I X0=127 X32=0 P26 X7=127 V127
 X99=24 X98=40 X6=70

#I0 _1 {o2m2_}2 _1`10

(V7.82)XG音源で途中再生するとドラムの音質が変わってしまう†

対応状況(2018.10.02)†

V7.83にて対応済み

(原因)
V7.81にてシーク効率を高めるため、プログラムチェンジ(P指定)に対し、ローテーションバッファ方式を組み込んだ。
しかし、この方式はP指定の発行を処理の最後で実施するため、NRPN関係のX指定と発行の順番が入れ替わる結果となった。
一方、XG音源のドラムに対するNRPNは、プログラムチェンジが発行されるとリセットされるため、
データの記述順によっては、シーク時にNRPNが効かなくなるという症状が発現した。

(対処)
ドラムパートのP指定をローテーションバッファ方式の対象から外し、NRPNとの記述順を変えずに音源に送出するよう改めた。

障害報告(2018.10.01)†

いつ頃からか、XG曲で途中再生するとドラムが頭から聞いた場合と変わってる気がします。
以下のデータで再現します。

*DATA""
@Z P26 X99=24 X98=40 X6=127
#Z1 _1 o2m

(V7.77)起動引数 *msf 指定時の挙動がおかしい†

対応状況(2018.07.07)†

V7.78にて対応済み

(原因)
ビルド環境をVS2008からVS2010にした際、今まで必要だったメインウィンドウのサイズ固定化処理が不要となったため、その処理をV7.77で取り除いた。
しかし、その処理をトリガにしたイベント発生を足掛かりに、起動引数によるダイアログ群表示処理を行っていたため、それらの処理がうまく動かなくなってしまった。

(対処)
ダイアログ初期表示のためのシーケンスや、最小化表示起動の制御、各種ウィンドウの初期状態のセットなどを全面的に見直した。

障害報告(2018.07.07)†

MUSE Ver.7.77 の挙動でおかしいと思われる点がありましたので連絡いたします。

コマンドラインオプションでメンバー情報(*m)、譜面モニタ(*s)を表示させたとき、フォントがおかしいです。
いったん消して再表示させると元に戻ります。
また、フィンガー情報(*f)を表示させようとしても、表示されません。

ランチャー(CLaunch)で全ウィンドウを表示させて起動するよう設定していたので、おかしいなと思いました。
コマンドプロンプトからオプション指定して起動しても同様でした。

実行環境は
Windows 10 Pro 32bit
です。

(V7.76)VSTi音源起動時にパネルを表示した段階でフリーズする†

対応状況(2018.06.10)†

V7.77にて対応済み

(原因)
V7.73にてbluetooth利用時のフリーズを回避するため、事前にWave音源をオープンする処理を施したが、
パネル表示後にその音源をクローズする際のポーリング条件が厳しすぎた。

(対処)
ビルド環境をVC2008からVC2017にしたことで、事前のダミーWave音源をオープンせずとも、フリーズしなくなった。
そのため、事前のオープン／クローズの処理を行わないようにした。
それに伴い、今回の原因であるクローズ内ポーリング処理も発行されることはなくなった。

障害報告(2018.06.04)†

(報告1)
普通にSoundCanvasVAをMuseで読み込ませると、Muse、VSTiパネル共にフリーズしてしまいます。
タスクマネージャーでアクティベーターを落とすと、ようやく操作できるようになります。

(報告2)
うちのWin10機(64bit)でもうまく動作しません。
Muse7.7.4版はOKで、7.7.5版以降は開発者様と同じ症状です。
プロパティのセキュリティタブで、見えているユーザーすべてにフルコントロール権限を与えましたが、直りませんでした。
SCVAは、C:\VSTPluginsの下にSound Canvas VAフォルダを作って、コピーしてあります。

(報告3)
もう少し情報を追加します。
〇V7.74
・管理者として実行をしなくても正常に起動する
・多重起動による複数インスタンスでも問題なし(※)
〇V7.75とV7.76共通
・iniファイルで音源がSCVAに指定された状態で通常に起動すると、応答なしになる
・マウス右ボタンメニューから「管理者として実行する」を実行すると通常に動作する
・既にMuseが動作している状態で、更にインスタンスを作るのは管理者でなくても正常
・Museの応答なしインスタンスがあると、2つ目のインスタンスは管理者でなくても正常に動作する
・muse.exeのプロパティのうち、互換性設定で「管理者としてこのプログラムを実行する」をチェックすると、起動時のUACポップアップは出るが、応答なしになる
・iniファイルの#DV指定がない状態で起動すると、音源にSCVAを選ぼうとすると応答なしになる
・2つ目のインスタンスはSCVAが選べ、正常
まとめると、V7.75以降は、SCVAを音源として指定すると最初のインスタンスは右ボタンメニューから管理者起動をしておかないとNGで、応答なしのインスタンスが居れば、次からは管理者権限がなくても正常動作する、という状態です。
※多重起動は、あくまでも挙動確認のためだけです。iniファイルへのアクセスが重なると、ポップアップでエラーが出ます。
こちらのディレクトリ構成が、C:\VSTPlugins\Sound Canvas VAのためC:\VSTPluginsのプロパティを表示し、セキュリティタブで表示される全ユーザーに対してフルコントロールを許可して確認しました。

(報告4)
以下に試行順序通りに結果を書きますが、奇っ怪です。
最終的に7.74org版も異常になってしまいました。
muse自体の問題でなく、UAC関連で何かありそうな印象を受けました。
一旦ここまでで、レポートします。
〇環境
元の7.74ディレクトリ(C:\App\7.74\MUSE\)にa,b,c,d版を展開
org版は、昨日試行していた版で、無印のmuse.exe
a,b,c,d版はそのままのファイル名で実行
〇結果（操作順）
　*a,b,c,d版の順で1回ずつ実行。全てUACが出て、続行させるとフリーズ
　・ 7.74orgが正常に起動
　・ ２回目のa,b,c,d版繰り返しはa版のみ動作(org版試行せず)
　・ 管理者として実行は、b,c,d版で異常(a版,org版試行せず)
　・ 7.75ディレクトリに移動して7.75org起動が正常(昨日と差異)
　*2回目の7.75orgが異常
　・ 7.74ディレクトリに戻り7.74a異常
　*7.74org異常
　・ 7.74org管理者権限で起動して異常
　・ この状態で他のDAW(Ability)からSCVAは利用可能

(V7.76)DPI設定時に各ウィンドウのスクリーン境界フィッティングがうまくいかなくなる†

対応状況(2018.06.07)†

V7.77にて対応済み。

(原因)
DPI比率の考慮がされていなかったため、100%以外のDPI値において、
ウィンドウ枠幅のドット数算出に誤差が生じていた。

(対処)
Muse起動時にDPI比率を取得し、フィッティング寸法を決定する際にそれを利用するよう改めた。

障害報告(2018.06.04)†

DPI設定で120%や150%の指定を行うと、スクリーン境界でのフィッティングが効かず、
スクリーンからはみ出したり、スクリーンの半ばで引っ掛かるなどの症状が起こる。
Windows10でもWindows7でも症状を確認した。

(V7.74)muse.iniの#DNで音源名を非表示指定した場合に●印が付かなかったり別の音源に付いたりする†

対応状況(2018.05.11)†

V7.75にて対応済み。

(原因)
単純に音源のデバイスIDを足掛かりに選択音源の位置を算出していたため、
非表示音源によって歯抜けになった際に、位置づれを起こしていた。

(対処)
メニュー項目識別子に音源デバイスIDを与えているため、
選択音源の位置を特定する際、相対位置指定ではなく、識別子指定で行うこととした。

(追記)
本件とは直接関係が無いがX129の指定名称を変更し、Readme.txtを改訂した。
従来、この名称は「ピッチベンド」となっていたが、Uコマンドと区別できないため、
「微細ピッチ」と改名した。

障害報告(2018.05.06)†

#DNで不要なデバイスを非表示にしている場合の挙動で
音源メニューから

AAA
BBB
CCC ←これを選択
DDD
EEE
FFF

するとEEEなど別の音源が選択(EEEの音源に●印が付く)されてるようにみえます。
が内部的にはきちんとCCCが選択されているようでCCCの音源から音が出ます。
Museを再起動するときちんとCCCが選択された状態になっております。

(V7.74)DPI設定時マウスカーソルの位置が勝手に移動してしまう場合がある†

対応状況(2018.05.11)†

V7.75にて対応済み。

(原因)
譜面モニタ上の表示が変更された際、それに応じたマウスカーソルに変更するため、
同位置におけるカーソル移動を発行しているが、その際スケーリングの考慮をしていなかったため
予期せぬ位置に飛んでしまう現象が生じていた。

(対処)
譜面モニタ上であればアプリケーション側での考慮が不要なため、
譜面モニタ外での同位置移動処理を抑止することとした。
また、プロパティでアプリケーション毎にDPI抑止をした場合、
論理座標の一意性が失われるため、物理座標で処理を行うよう変更した。
なお、配色マップにおける採色機能においても、同じ原因で問題が生じるため、
物理座標で処理することで正しく機能するよう修正した。

障害報告(2018.05.06)†

OS:Windows7 64ビット
画面の解像度:3840x2160 OSの設定で150%に拡大(機能の名前はDPIスケーリング？)
Museのバージョン:7.74

上記の環境でMuseを起動したと同時にマウスカーソルの位置が別の場所に飛んでしまいます。

譜面モニタを表示し、かつ自動スクロールをオンにしていると
ページが切り替わるタイミングでマウスカーソルが飛んでしまいます。
この現象はMuseのウィンドウ内だとわずかしか飛びませんが
Museのウィンドウ外だと大きく飛ぶように思います。

この現象はmuse.exeのプロパティ 互換性 高DPI設定では〜のチェックを入れて
スケーリングを無効にすると発生しません。

ちなみにWindows10x64 1920x1080 125%拡大 に設定した別PCで再現するか試したところ
大きくは飛ばないもののわずかながら動く模様です。

もともと高DPIは想定していないでしょうし
どちらかといえばOS側のバグ(仕様？)な気もしますが
一応ご報告をと思いました次第です。

(V7.72)UTF-8の楽団編成ファイルが読み込めない†

対応状況(2017.11.29)†

V7.73にて対応済み。

(原因)
２度読み処理の際、シーク関数によってユニコードBOMの先頭まで戻り、データ解析で矛盾を生じていた。

(対処)
シーク関数ではなくファイルポジションの退避と復帰によって対処した。
本対処により、UTF-8(BOM付き)、UTF-16(リトルエンディアン)も読み込めるようになった。

なお、VSTiのパラメータ記憶ファイルも同じ原因のミスがあったため、併せて対処した。

障害報告(2017.11.13)†

……何度も何度も失敗繰り返してやっと原因判明。
MuseLoidを設定する 「sfmファイル」の文字コードが UTF-8ではダメだったのだ。Shift-JISでないと読み込めないのらしい。
自分が使ってるエディタ『Sublime Text』は Shift-JISを基本サポートしておらんため、
そんな簡単なコトに気づかなかった。せっせと UTF-8で保存してた。
ばーかみてぇ……orz

ブログ「MIZの本日も安上がりに素晴らしい一日」より
http://blog.livedoor.jp/miz_mus/archives/2066715.html

(V7.71)VSTi音源切り替え時に応答を停止する†

対応状況(2017.06.15)†

V7.72にて対応済み。

(対処)
WAVE音源クローズ時のバッファクリア条件を緩和することで抜本的に解決した。
副次的に、通常の音源切替性能も向上した。

障害報告(2017.05.17)†

バグ報告ですが、再現性が定かではないです。
環境｜OS:Win 10, CPU:Celeron Dual Core 2.16GHz, 4GB RAM, バージョンは7.71zip版
正常終了できなかったという報告です。
音源を選択解除しようとして右クリックしたところ、応答を停止する現象が発生しました。

(V7.70)データの再ロードでメンバー情報の表示内容が更新されない場合がある†

対応状況(2017.05.09)†

V7.71にて対応済み。

(原因)
この不具合はV7.32以降からの潜在バグである。
V7.31からV7.32にアップする際、メンバー情報の表示で演奏をモタレさせないようにするため、その表示もマルチスレッド処理の対象に含めた。
その際、表示制御用フラグの簡素化を図ったが、データ切替時の表示更新に対する考慮を欠いていた。

(対処)
表示制御用のフラグに不定状態の区分を１つ増やした。

障害報告(2017.05.07)†

まず、以下のデータをロードする。

#A0 P124 d

この時、メンバー情報ダイアログのＡメンバーには、「小鳥」が表示されている。

次に以下のようにドラム転向を追加し、リロードする。

*DRUM"A"
#A0 P124 d

ここでメンバー情報が「ドラムセット(124)」となるべきところ、更新されず「小鳥」のままである。
一度メンバー情報を閉じてから開きなおすと、「ドラムセット(124)」になっている。
演奏自体は正常のようだ。

(V7.61)WAVEコマンドが効かない場合がある†

対応状況(2016.11.13)†

V7.62にて対応済み。

(原因)
V7.40からV7.50にアップする際、カレントディレクトリの変更処理は不要であると判断し削除した。
しかし、WAVEコマンドの相対パス基点は、ロードしたMuseデータの所在ディレクトリであるため、
他のディレクトリからMuseを起動した場合、WAVEコマンドのパスが通らなくなっていた。

(対処)
バッチコマンドの場合は、エクスポートするファイルをカレントディレクトリにする仕様のため、
対話処理の場合のみカレントディレクトリをロードしたMuseデータの所在ディレクトリに変更する処理を加えた。

障害報告(2016.11.13)†

以前は鳴っていたのですが、最近WAVEコマンドの音が鳴らなくなりました。

(V7.61)音源起動中にmusファイルをドラッグ＆ドロップするとクラッシュする†

対応状況(2016.11.13)†

V7.62にて対応済み。

(状況)
従来、巨大なサウンドフォントや重いVSTiなどの音源を扱う機会が少なかったため 発現頻度が低かっただけであり、
従前からの潜在バグであって、 過去バージョンでもタイミングによっては発生し得る。
ドラッグ＆ドロップだけでなく、排他制御オプション(*x)を用いて エクスプローラーからのクリックで起動した場合も同様の症状が起こる。

(原因)
音源起動中に、ドラッグ＆ドロップなどで新しいデータのロード処理がスタックされると、
ロード済みデータの演奏終了処理と新しくロードするデータとの並列処理が実施され、 共有メモリ領域の矛盾が生じてクラッシュする。

(対処)
音源起動中やロード中は環境準備中のフラグを立て、そのフラグが立っている間は、
ドラッグ＆ドロップ、および排他起動をキャンセルする制御とした。

障害報告(2016.11.12)†

Roland SoundCanvas? VA の起動は、初回で20秒、２回目以降で10秒程度掛かりますが、
起動している間に、エクスプローラーからデータをMuseにドロップすると確実にクラッシュします。

(V7.60)スクリーン四隅でのウィンドウフィットが微妙にずれる†

対応状況(2016.10.22)†

V7.61にて対応済み。

(原因)
V7.50にて、ウィンドウフィット演算の効率化を試みたが、その際デグレードを起こしていた。

(対処)
以前の演算シーケンスに戻した。

障害報告(2016.10.21)†

表示位置を画面外周にくっ付けると自動的に境界で止まってくれてたのが、 少し食い込むようになっています。

環境はWindows７ 64bitです。
症状の発現は、V7.50からです。

(V7.51)VSTi使用時に既定の再生デバイスを切り替えるとフリーズする†

対応状況(2016.09.21)†

V7.52にて対応済み。

(原因)
VSTi演奏の際、既定の再生デバイス(WAVE_MAPPER)を指定してウェーブデバイスをオープンしていたが
演奏中にコントロールパネルから既定の再生デバイスを変更すると、オープンしたデバイスハンドルと不整合が生じ
制御不能となってMuseがハングしていた。
なお、演奏停止状態であっても、ウェーブデバイスは稼動し続けているため、演奏の有無に関らずフリーズが起こる。

(対処)
既定の再生デバイスは、常にデバイスIDがゼロの位置に動的に変化するため、
WAVE_MAPPERではなくゼロを指定してウェーブデバイスをオープンするよう改めた。
これにより、VSTi音源が選択されている状態でコントロールパネルから既定の再生デバイスを変更しても
オープンした時点のデバイスに対して発音を継続する制御となり矛盾は生じなくなった。

なお、VSTi操作パネルの[X]ボタンでウェーブデバイスをオープンしなおすため、
このボタンにて、既定の再生デバイスの変更を反映できる。

障害報告(2016.09.21)†

音源にVSTiを選択した状態で、Windowsの既定の再生デバイスを切り替えると、Museがフリーズしてしまいます。
演奏中かどうかに関わらず、必ず発生します（起動直後でも発生します）。
なお、MSGS選択時は問題ありません。演奏中に切り替えると、切り替えた先の再生デバイスで引き続き演奏が鳴ります。

VSTi使用時は、デバイスへ直接WAVE出力しているのが関係しているのでしょうか。

環境はMuse V7.51、Windows 10 Pro (x64)になります。

(V7.32)繰返し演奏で演奏テンポが異常になる場合がある†

対応状況(2016.04.12)†

V7.33にて対応済み。

(経緯)
V7.30におけるデグレード。（厳密に言うと、V7.30以前からの潜在バグ）

試聴系ダイアログを利用している最中は演奏は停止させるのが、Museの基本仕様である。
V7.30開発時、繰返し演奏の処理中（シークバーを自動で曲頭に戻す処理中）に
「楽器の試聴」や「ドラムの試聴」をメニュー選択すると、
ダイアログが出ている状態で演奏が再開されてしまうという不具合を発見しそれに対処した。

対処方法として、繰返し演奏再開中の試聴起動を確実に検出するためにインターバルを与えることとした。
ところが、このインターバル中にマウスのクリックイベントが発生する可能性が高まり、
結果として、タイマーコールバックの多重起動の現象を誘発した。

(原因)
繰返し演奏のシーケンスは、まずタイマーを一旦止めて、自動巻き戻し処理を施した後、
演奏を再開するために再びタイマーを起動する。
タイマー起動の冒頭で、２度呼びをキャンセルする様にしているが、
その判断をするためのフラグを立てる前（巻き戻している間）に、
再度タイマー起動のトリガ（今回はクリック操作によるタイマー起動）が掛かり、
冒頭でのキャンセルができない状態に陥っていた。

後続のタイマー起動をキャンセルできないと、タイマーが２つ起動することになり、
演奏カウンターがダブルカウントされる。よって、演奏が倍速になってしまった。
更にタイマー停止は１つだけが実施されるため、次に再びタイマーを２つ起動する操作を行うと、
タイマーが計３つ起動していることになり、今度はトリプルカウントの状態に陥る。
これを繰り返すことで「現象を発生させる毎にどんどん高速になる」という症状を発現していた。

(対処)
V7.30にてインターバルを与えたことで、
タイマーコールバック多重起動の現象が起こりやすくなったことは事実だが、
論理的にはインターバルが無くとも、タイミングによっては多重起動が起こってしまう。

インターバルゼロでも起こりうる多重起動を抑止するために、
繰返し演奏の巻戻し処理中を表現するフラグを設け、このフラグが立っている間は、
タイマー起動や停止、およびMuseデータのロード更新に関わるあらゆる操作を無効とする処理を組込んだ。

これにより、本障害発見のきっかけとなった試聴ダイアログ起動を検出するためのインターバルも不要となり、
繰返し演奏モードではない通常演奏において、演奏再開やシーク反応が改善するという副次効果を得た。
また、巻戻し処理の内部インターバルを安全にゼロにできたため、以前ＸＧ音源がらみで除去した
繰返しモードにおける演奏開始時のインターバルを復活できた。
こちらのインターバルでは、すべての割り込み操作が可能である。

障害報告(2016.04.10)†

[現象]
繰返し演奏にてシークバーが先頭に戻った時点でクリックすると高速再生される
・一度停止させても再生速度は元に戻らない → 再起動するしかない？
・現象を発生させる毎にどんどん高速になる

[使用音源]
存在する以下の全ての音源で現象を確認
・Microsoft GS Wavetable Synth
・CoolSoft? VirtualMIDISynth
・Timidity++ Driver

[確認バージョン]
以下のバージョンで現象を確認（それ以前は試していない）
・7.32
・7.31

[使用OS]
Windows Vista

(V7.30)演奏会場ダイアログのSENDボタンが送信不可状態でも活性化してしまう†

対応状況(2016.03.02)†

V7.31にて対応済み。

(原因)
V7.30におけるデグレード。
MIDI音源オープン／クローズの制御のためのグローバル変数を整理し処理を効率化したが、
それに伴う演奏会場ダイアログの送信ボタン[SEND]の不活性化条件を変更し忘れていた。

(対処)
正しい判定条件に改修した。

障害報告(2016.03.01)†

適当なMuseデータを読込んで演奏させ、途中で再生を止める。
この状態(演奏停止状態)で、演奏会場ダイアログを表示させると[SEND]ボタンが活性化してしまっている。
過去のバージョンでは、演奏停止では不活性状態で起動し、演奏再開で活性化する動きだった。

(V7.05)MARKのあるデータで曲尾から繰返し演奏を行うと曲頭に戻らない†

対応状況(2015.09.24)†

V7.06にて対応済み。

(原因)
繰返し演奏時、曲尾に到達していた際の演奏再開位置の算出処理は、
シーク処理のモジュールを利用しているが、そのモジュールはMARKとSTOPの両方を
位置算出の対象としているため、最後のMARKに位置決めされてしまう症状となった。

(対処)
シーク処理モジュールにSTOPのみを位置決め対象とするオプションを設け
繰返し演奏の指定がある場合はそのオプションで処理を行うよう改めた。

(補足)
本件とは関係が無いが、V7.06よりダブルクォート内の特殊文字として、
単独の(`)に加え、連続する(``)も１文字のダブルクォート(")になる仕様とする。
ダブルクォートにアットマークが続く文字列("@)を表現するためである。

障害報告(2015.09.24)†

以下の様なデータを最後まで演奏させた状態で、メニューから「繰返し演奏」を指定し、
鍵盤をクリックすると、曲頭まで巻き戻されず、MARKコマンドからの演奏になってしまう。

d1 *MARK"A" m1

上記例の場合、曲尾からの演奏再開でMARKコマンド部分にシークされミが鳴る。
そして、曲尾まで達した後は曲頭に巻き戻されて、ドからの正常な繰返し演奏に移行する。

(V7.04)読込ダイアログのサイズが小さくならない†

対応状況(2015.08.29)†

V7.05にて対応済み。

(原因)
本件はMuseのバグではなく、Windows10の障害である可能性が高い。
http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2015/08/25/windows-10-mfc-cfiledialog.aspx

(対処)
マイクロソフトの対応がいつになるか定かではないため、
初期化ファイル(muse.ini)にて、ファイル系ダイアログのサイズを固定化するスイッチDSZを設けることにした。
デフォルトは可変(DSZ=1)であるが、Windows10での利用者は固定(DSZ=0)にすることを推奨する。

あいにくファイル系ダイアログの寸法は、OSレベルでレジストリに記憶され、Windows自体を再起動しても以前のサイズを復元する。
そのため、不用意にダイログを大きくしてしまうとWindows10環境では元に戻らなくなる。
この様な状況に陥っても、DSZスイッチを固定に切替えれば、適度な寸法に戻すことができる。

なお本機構は、マイクロソフトがバグを解消した暁には撤去する予定である。

(追記)2015.12
2015.11のWindows10 Update にて、本障害が対処された。
muse(V7.10)にて、DSZスイッチを撤廃する。

障害報告(2015.08.22)†

Museメニュー「ファイル(F)」→「開く(O)」で出てくるダイアログですが、
サイズを大きくすることはできますが、それを小さくすることができません。
同様に、「エクスポート」の「MIDIファイル」や「PDFファイル」で出てくる
書込み用のダイアログでも同じ現象になります。

なお、この現象はWindows10でのみ現れます。

(V7.03)リロード後すぐに演奏を開始しない場合がある†

対応状況(2015.08.15)†

V7.04にて対応済み。

(原因)
リロード時、新たにロードしたデータが以前のデータよりも演奏時間が短い場合に、演奏時刻を曲尾に律則させる処理を行っている。
V7.00で曲尾到達時の内部時刻の定義を変更した際、上記処理における改修が漏れていた。

(対処)
リロード時も、新しい内部時刻定義に基づいた律則処理に改めた。

障害報告(2015.08.15)†

曲尾まで演奏を聴き、シークバーが右端に到達している状態で、メニューから「リロード(L)」を実施した後、
鍵盤をクリックしても１回のクリックでは演奏が始まりません。２回クリックすると曲頭から演奏が始まります。
V6.90では、１回のクリックでも演奏が始まっていました。

(V7.02)ALTキー併用のメニュー選択ができない†

対応状況(2015.08.01)†

V7.03にて対応済み。

(原因)
V7.00からV7.01にアップする際、プログラム各所のシェープアップを図ったが、その際に作り込んだバグ。
V7.01でキーメッセージ関係の処理を整理し、WM_CHARのイベントを一切利用せず、WM_KEYUP／WM_KEYDOWN系統のみに簡素化した。
これによりメインのメッセージループでのTranslateMessage?()は不要になると判断し、取り払った。
しかし、このWindowsが提供しているこのキーコード変換モジュールは、メニューのALTキー処理に必要不可欠な模様で、
取り払ったために、反応しなくなってしまった。

(対処)
TranslateMessage?()のコールを復活させた。

障害報告(2015.08.01)†

メイン画面フォーカス時の Alt 系ホットキーの挙動が 標準的なWindowsの仕様となっていません。
Alt+F/G/H/V の押下の際、V7.00 ではメニューが開きますが、V7.01 以降では開きません。
メニューバーのイニシャルにアンダーラインが付いているか否かによらず起こります。
ただし、Altを押下して一旦キーを上げ、その後F/G/H/Vを押下する場合はメニューが出ます。

(V7.01)コントロールキーによるシーク操作で演奏が再開しない場合がある†

対応状況(2015.07.21)†

V7.02にて対応済み。

(原因)
V7.01の開発時に、譜面モニタの右クリック連打によりMuseが落ちる症状を見つけた。
V6.33での障害「シークを素早く断続的に繰り返すと落ちる場合がある 」とほぼ同等の症状。
当時は、クローズ処理でのインターバルを充分に与えることで対処したが、
インターバル中にリロードのイベントが大量に発生すると、同様の現象が起こることが判明した。
そこで、インターバルを終えたタイミングで、インターバル中に発生した操作イベントをクリアする処理を施した。
これにより上記の症状は治まったが、シーク操作時にもイベントクリアが起こることとなり、
キーを解放した瞬間の演奏再開が実施されなくなったことが原因である。

(対処)
演奏中のシークを管理しているフラグを利用し、それが立っている場合はイベントのクリアをしないこととした。

(補足)
本件とは関係が無いが、V7.02より「マニュアル表示」メニューを階層化し、
「表示」に加え、「演奏」の機能もサポートすることにした。

障害報告(2015.07.21)†

メインウィンドウをフォーカスしているときの Ctrl+←/→ を、演奏中の状態で押したとき、
ジャンプした後演奏が再開しないことがあります。

このとき、いくつかの操作が受け付けられなくなりますが、
Ctrl+←/→ は効いて、演奏が再開することもあります。
パソコンの起動直後が顕著で、この操作を繰返すと次第に起こらなくなります。

スクロールバー両端の三角印のクリックでは起こらないようです。
また、7.00 では起こらないようです。

MIDI デバイスは VirtualMIDISynth と Timidity++ で、OS は 7 と 8.1 で現象を確認しています。

(V7.00)X指定でのNRPNが途中再生で再現されない†

対応状況(2015.07.13)†

V7.01にて対応済み。

(原因)
V7.00で途中再生におけるシーク制御に効率改善を実施したが、その際に混入したバグ。
波形加工の遅延指定ではメッセージが大量に発生する可能性があるため、バッファリングを行っている。
本来、波形加工のLSB/MSBであるNRPNをバッファリングした後、それがXでの指定である場合を考慮し、
リアルタイムに音源送出する処理に移行すべきところ、波形加工バッファリング後に処理を打ち切っていた。

(対処)
NRPN検出後、バッファリングした後も音源送出処理へ移行するよう改修した。

障害報告(2015.07.13)†

途中再生で NRPN メッセージがうまく再現されなくなっています。

（例）X99=1 X98=32 X6=10 X98=48 X6=120 _1 d1

(V7.00)履歴メニューがmuse.logどおりに表示されない†

対応状況(2015.07.13)†

V7.01にて対応済み。

(原因)
V7.00で履歴メニュー制御の大幅な効率改善を実施したが、その際に混入したバグ。
履歴メニュー直下の曲項目は、直近で選択されたものが先頭に移動する制御を行っているが、
muse.iniで履歴メニュー直下の表示曲をゼロに指定した場合の対処が漏れていた。

(対処)
履歴メニュー直下の表示曲がゼロの場合は、曲項目の移動処理を行わないように改修した。

障害報告(2015.07.12)†

V7.00で不具合を発見しましたので報告致します。
muse.logの内容が下記の状態で、別の.musファイルからmuseを起動したところ、
２つ目のタイトル行が履歴メニューに表示されなくなりました。

[muse.log]※パスは省略
---------------------------------------------------------------------------
*Microsoft GS Wavetable Synth 用
2013/03/10(13:32:14) 16> Muse\CHA-LA HEAD-CHA-LA.mus
2014/02/11(19:06:33) 39> Muse\Inscrutable Battle.mus
2014/09/20(17:34:22) 10> Muse\OCEAN.mus
2015/05/06(18:12:38) 6> Muse\コネクト.mus
2015/05/06(18:23:52) 23> Muse\ロビンソン.mus
2014/02/11(19:14:40) 12> Muse\空も飛べるはず.mus
2014/02/11(19:13:33) 8> Muse\残酷な天使のテーゼ.mus
2014/10/13(22:40:50) 12> Muse\世界の車窓から.mus
2015/05/06(18:07:51) 50> Muse\冒険でしょでしょ？.mus
2015/06/06(17:39:48) 4> Muse\恋せよ女の子.mus
*Timidity++ Driver 用
2015/05/06(17:45:32) 3> Muse\Sparkling Daydream.mus
2014/09/20(17:40:05) 13> Muse\TAKE ON ME.mus
2013/03/05(00:54:45) 8> Muse\TSUNAMI.mus
2015/06/05(23:24:04) 86> Muse\そのままの僕で.mus
2014/08/20(23:13:42) 32> Muse\ハナミズキ.mus
2015/05/06(18:04:23) 37> Muse\マイ　フレンド.mus
2014/09/20(17:49:10) 10> Muse\半妖.mus
2014/09/20(17:29:41) 27> Muse\夢をあきらめないで.mus
2014/09/20(17:24:54) 40> Muse\涙の海で抱かれたい〜SEA OF LOVE〜.mus
---------------------------------------------------------------------------

[履歴メニュー]
---------------------------------------------------------------------------
Microsoft GS Wavetable Synth 用
(区切り線)
ただいま。
---------------------------------------------------------------------------

また、muse.iniでは、履歴メニューにおける表示曲数を
LGM = 0
に指定しているのですが、開いた.musファイルの履歴が表示されてしまいます。

(V6.81)演奏会場の確認ダイアログ最下段スライダーの最大値が不正である†

対応状況(2015.04.11)†

V6.82にて対応済み。

(原因)
演奏会場の確認ダイアログをコールした際の、スライダー値範囲の初期化漏れ。
for文にて値をセットしているが、停止側条件を <= とすべきところ、< としていた。
そのため、最終スライダーのみ初期化されていなかった。

(対処)
正しい停止条件に改修した。

障害報告(2015.04.10)†

演奏会場において、コーラス設定のSend-Rの最大値は本来127であるが、
確認ダイアログの最下段スライダーは、100までしか指定できない。

(V6.80)変化の激しい遅延指定があると直前の指定値が譜面モニタ属性で表示されなくなる†

対応状況(2015.03.09)†

V6.81にて対応済み。

(原因)
Museは音源の負荷を低減するため、コンパイルの最終段階で、同一時刻に発行されている同一種のコントロールメッセージを圧縮し、 その中の最終メッセージのみを残すようにしている。
一方、演奏データのメモリ効率を高めるため、各発音ノートに譜面モニタの属性表示用の文字情報を付与できる場合は、 別途属性表示用のノートを確保しない構造で制御している。
変化の激しい遅延指定により、遅延開始の１つ目のノートとその直前のノートが同一時刻になる場合が発生。 上記の仕様から直前ノート側が除去されることとなり、それに伴って付帯されている属性表示用の文字情報も解放された。

(対処)
除去すべき側ノートに付帯の文字情報があり、かつ残存すべき側のノートに付帯の文字情報が無い場合は、 除去すべき側のノートを完全に解放せず、コントロール用のノートから譜面モニタの表示文字用のノートに変化させることで、 付帯の文字情報を温存する方式とした。
なお、従前でも譜面モニタの表示文字用のノートは存在している。例えば、休符に挟まれた音量V指定が存在する場合は、 MIDIコントロールを伴わないノートとなる。今回の対処は、このノート種別に挿げ替えることで対処したことになる。

(補足)
本件追跡中に、演奏開始時点のシーク処理を高速化する部分で論理的な不備を発見した。
何の属性値もコントロール種別も持たないフルゼロのMIDIメッセージを送出する可能性があった。
この不具合による直接的、致命的な症状は出ないと推測されるが、本件の対応に伴い改修しフルゼロメッセージを送出しないよう改めた。

障害報告(2015.03.08)†

以下の様なMuseデータを譜面モニタの属性表示で確認すると、V100 の部分が表示されない。

%126 V100V40:8 d1

なお、上記からごく僅かに遅延変化を緩和させた場合は、V100 が表示される。

%125 V100V40:8 d1　　;テンポをほんの少し遅くする
%126 V100V50:8 d1　　;変化量をほんの少し小さくする

(V6.74)和音内の音符に付与されたアクセントwが譜面モニタの属性表示でずれる†

対応状況(2014.07.01)†

V6.75にて対応済み。

(原因)
フィンガー属性を検出した時点で、和音の冒頭に巻き戻すことなく属性表示用のアクセントノードを生成していた。

(対処)
アクセントが和音内に存在している場合、生成する表示用ノードの位置を和音冒頭に位置決めするよう改めた。

(補足)
本件は w だけでなく、他のフィンガー属性(v p q)に関しても同様の不具合が認められたため、それらにも対応した。

障害報告(2014.06.29)†

以下の様なMuseデータを譜面モニタの属性表示で確認すると、アクセントの表示位置がおかしい。

c2 [ d w+20 m s ]4 f4

w+20のアクセントは、実際の演奏では和音内のミの音に掛かっているが、
譜面モニタの属性表示では、和音外のファの位置に表示されてしまう。

(V6.71)楽譜出力において必要以上にスラッシュセパレータが譜刻される†

対応状況(2014.04.24)†

V6.72にて対応済み。

(原因)
V6.71にて施した楽譜出力機構の内部的改善における、スラッシュセパレータ挿入判断のための五線カウントロジック部分のデグレード。
具体的には、単独五線あるいはグループ数をカウントする際、メンバー情報やフィンガーフォーカスでオミットしたフィンガーをマスクする処理を、
LILYコマンドのグループ化ノード ( [ { においてもコールしてしまっていたため、負値の配列アクセスが起こり不定値によるカウント処理が発生していた。
概ねほとんどのグループでカウントされず、ネスト量の制御値がゼロのままになったため、単独五線の判断が起こらなくなった。

(対処)
フィンガーのマスク処理は、グループ化ノードの処理判定の後に実施するよう改めた。
また、グループ内に譜刻対象の五線が存在しない場合に備え、グループ内の五線数を別変数でカウントし、
グループが完了する時点で従前の五線数をインクリメントする方式とした。

(補足)
V6.71にて小節休符をサポートしたことで、複数のフィンガーが集約された五線上での休符譜刻が従前以上に発生するようになった。
今回、初出フィンガーのみに小節休符を生成するという制御を組み込み、パート譜での小節休符譜刻を維持したまま複数フィンガーの休符衝突を削減させた。

障害報告(2014.04.24)†

V6.70までは、単独フィンガーや１つのグループ五線の場合にはスラッシュセパレータの譜刻が抑止されていたが、
V6.71では、ほとんどの場合で譜刻されてしまう模様。

(V6.70)楽譜出力において強弱指定(v)に対する自動記譜抑止が働かない場合がある†

対応状況(2014.03.23)†

V6.71にて対応済み。

(原因)
一括指定コマンド(*FING)の強弱(v)指定の処理において、その抑止判断をするフラグ参照先に誤りがあった。
フィンガーの処理ループにおいて、本来巡回先フィンガーのフラグを参照すべきところ、*FINGが記述されているフィンガーのフラグを参照していた。

(対処)
巡回先フィンガーのフラグを参照するように改修した。
また自動記譜抑止において、他の属性処理にも同様のケアレスミスがないかチェックしたところ、
タイミング合わせ(%)にも同じミスを発見したため、これも改修した。

障害報告(2014.03.23)†

楽譜出力関連ですが、以下の記述で楽譜を出力すると強弱記号(この例では fff)が表示されます。

#A0 *LILY "-v"
#A1
*FING "A(v127)"
#A0 d

これは私の期待と違うのですが、こういう仕様なのでしょうか?

#A1 を削除すると表示されません。
コマンド*FING が #A1 に記述されているからでしょうか。

(V6.70)０番フィンガーの存在しないデータでPDFに出力した楽譜が乱れる†

対応状況(2014.03.20)†

V6.71にて対応済み。

(原因)
V6.40にて楽譜構成定義 *LILY"0 ..." の五線集約指定の符幹方向制御を可能にした。
その制御用に従前の接続記号"+"に加えて"*"の接続詞を新設した。
しかし未使用フィンガーの離脱処理モジュールにて、追加された"*"の考慮が欠落していた。
そのため、０番フィンガーが存在しない場合にすべてのフィンガーが１つの五線に集約してしまうという症状に陥っていた。

(対処)
未使用フィンガーの離脱処理にて、接続記号"*"も正しく処理するよう改修した。
なお、"+"指定と"*"指定とを正しく区別しきれていない箇所も存在したため、合わせて改修した。

(補足)
LilyPondが(2.16.x)から(2.18.x)にアップした際、文法が非互換となった。
具体的には、スタッカーティッシモの指定記号が変更された。(\\| → \\!)
そこで本バージョンMuse(V6.71)より、LilyPond(2.18.x)の新しい指定記号を前提とした解釈に改めた。

よって
Muse(V6.70)を含む以前のバージョンの場合は、LilyPond(2.16.x)を、
Muse(V6.71)を含む以降のバージョンの場合は、LilyPond(2.18.x)を導入されたし。

障害報告(2014.03.19)†

「シシリアーノ」の楽譜出力がV6.40以降のバージョンで正しく印刷されません。

*LILY "0 
	[
	<Violin1 / Vn.1> @C 
	<Violin2 / Vn.2> @D 
	<Viola / Vl.> @F 
	<Cello / Ce.> @H+@I 
	<Basso / CB.> @J+@K 
	/
"

Windows８のせいではないと思うのですが、如何でしょうか。
LilyPondのバージョンは2.16.2です。
フィンガー指定に変更しましたが，出力は同じでした。

(V6.65)不正記述のあるマクロで文法エラーを検出しない場合がある†

対応状況(2014.02.23)†

V6.70にて対応済み。

(原因)
名前付きマクロにおいて、不正文字検出ロジックが漏れていた。

(対処)
無名マクロで実施している不正文字チェックと同等のロジックを組み込んだ。

障害報告(2014.02.23)†

d{4}

だと文法エラーですが、

d$a{4}

だと文法エラーになりません。

(追記) $a{}の中の数字は1でも2でも再現は4分音符になります。

(V6.65)連続して参照させる再現表記で落ちる†

対応状況(2014.02.20)†

V6.70にて対応済み。

(原因)
和音の閉じ括弧を検出した段階で、それと対になっている和音の開き括弧を、それ以降の再現表記(,)で再現すべき和音として記憶している。
この記憶する和音は閉括弧を検出するたびに更新されるため、今回のように再現先の和音内に再現記述がある場合、
自己参照ループに陥り、再帰呼出し処理でスタックオーバーフローが生じていた。
なお本障害は和音の再現表記のみならず、同様の理由で連符の再現表記でも起こった。

(d) (()) ()

(対処)
一度再現処理を施した再現先を記憶しておき、二度目以降の再現処理において自己参照を引き起こす状態か否かをチェックし、
もし自己参照が起こる場合は、記憶しておいた再現先を再利用して再現を実施するという一連の処理を組み込んだ。
またこの処理が駆動する場合は、閉括弧検出時に更新する再現先ポイントも再利用位置にシフトさせ、
多段階、多階層の再現処理でも自己参照回避が正しく実施されるよう工夫した。
自己参照チェックはマクロ展開も含んだ再帰処理であるためMuseコンパイルの性能を劣化させるが、
和音や連符の括弧外にある再現表記は自己参照が起こらないことは自明であるため、その場合はこの処理を駆動させない工夫をした。
よって、連符内連符など多階層の再現表記を利用しない従前データでは性能劣化はほとんど生じない。
また再利用のための再現先記憶域は、従前から存在する括弧対の管理変数を使い回すことでメモリ効率の劣化も回避した。

障害報告(2014.02.18)†

Muse を墜とす 7 文字

[d][,],

d はなくても墜ちます。

[][,],

(V6.65)途中再生時、Ｘコマンドの遅延が効かなくなる†

対応状況(2014.02.03)†

V6.70にて対応済み。

(原因)
V6.41→V6.50の時点でシーク処理の効率化を施した際に埋め込んだ障害。
波形加工によるNRPN音源負荷を低減するため、最終値のみ送信を行っているが、XコマンドによるRPNは即時送信している。
そのため、波形加工とXコマンドのMuseデータ記述順によっては、
シーク時にその順序が逆転し、演奏時に本来あるべきMSB,LSBの指定状態になっていなかった。

(対処)
MIDI規格によりデータエントリがNRPNとRPNで共用されているため、
１つのデータエントリで同時にNRPN、RPNの指定を実施することはあり得ないということを前提に、シーク処理を全面的に見直した。
従来、データエントリ検出時点で即時送信すべきか否かを判定していたが、
その時点では波形加工判断とバッファリングに留め、NRPNあるいはRPNを検出した時点で、
既存のバッファ内容を音源に送信すると共に、検出したNRPNあるいはRPNを新たにバッファリングする方針とした。
これにより、従来諦めていたXコマンド遅延指定時の最終値のみ送信の処理も実装可能となった。
バグを改修しただけでなく、性能も向上したはずである。

障害報告(2014.02.02)†

＜報告１＞
再生させてみたのは

*DATA""
*DATA "43,10,4C,00,00,7E,00"
@A P31/0 R80 R=65.64.60 W=64.67.64 T-12 S-24 X7=127
#A0 @ X101=0 X100=2 X6=64 X6=76:1 o4 x1 c4 c c c
*STOP""

です。
２つ目以降の音に右クリックで飛び込むと、以降 c 音になって、上がっていきません。
ただ、音がビヨ〜ンと揺れているようです。
ビブラート関連の NRPN かほかの RPN が効いてる？のかちょっとわかりませんが

いろいろやってみると、うまく上がっていくケースもあるようです。
どうも、R= と W= を両方削除すると、途中飛び込みでも正常に上がっていくようです。
※GS リセット下（１行目２行目削除）でも、同様のようです

R= と W= が、NRPN を使用しているのかわかりませんが、
X101 X100 X99 X98 のバッファリング・即時送信、あたり（？）
１）途中に飛び込む
２）溜め込んでいた R= W= を NRPN で送信（同じく溜め込んでいた X100、X101 の送信順番は？）
３）遅延指定の X6 が送信⇒２）で送られたメッセージのデータエントリとして評価される
とこんな想像です


＜報告２＞

#A0 @ R=64.64.64
X101=0 X100=2 X6=64 X6=100:1 d4 d d d

このデータで、X101, X100 でのRPN 指定と R= での NRPN 指定が干渉しているのが原因のはずです。
V6.55 での NRPN の干渉問題と同様だと思います

(V6.64)ドラム試聴でドラムセットを切替えるとボタンフェースが●のみになる†

対応状況(2014.01.07)†

V6.65にて対応済み。

(原因)
V6.60からの潜在バグ。
ドラムセットにおけるボタン表示文字列の制御で、ユニコード対応に漏れがあった。

(対処)
UTF-16による文字列演算に改修した。

(補足)
本バージョンより、ドラム試聴のClassicセットにおいて、ティンパニのボタン名称を明示するよう変更した。

障害報告(2014.01.06)†

ドラムセット画面で音色が●だけになります。

(V6.63)曲尾到達時に巻き戻しシークを行うと、その後の再生で無音演奏となる†

対応状況(2013.12.18)†

V6.64にて対応済み。

(原因)
演奏が曲尾到達した際に、以下の処理を実施している。
?音源のクローズ処理を行う
?演奏開始ノートをNULLにクリアする
一方、巻き戻しシークのイベントが起こった場合は、シーク位置の演奏開始ノートが新たにセットされる。
今回の事象は、?の処理中に巻き戻しシークのイベントが発生するもので、そこで演算された演奏開始ノートが、その後に続く?の処理でクリアされるために発生した。
演奏開始ノートがNULLの場合、MIDI音源に発音メッセージを送信しない。
しかるに演奏開始時刻はシークポイントを堅持しているため、無音演奏という事態に陥った。

本件は、V6.33→V6.34で行った「タイマー停止時に適度なインターバルを与え、その後にMIDI音源のクローズを実施する」という対処により、
?に積極的な処理時間を与えることとなり、その結果発現しやすくなった。
しかし、あくまでも発現確率が高まっただけであり、V6.34で与えたインターバルが真因ではない。

(対処)
演奏が曲尾に到達した時点で、即座に演奏開始ノートをNULLにクリアし、その後でインターバルを含む音源クローズを行うことにした。
これにより、シーク操作が音源クローズ中に起こっても、その演算結果である演奏開始ノートがクリアされることはなくなった。

(補足)
本対処とは直接の関係は無いが、V6.64よりビルド環境をVS2005からVS2010に変更した。
これにより、以降の対応OSは、XP/7/8/8.1となる。
V6.60でのユニコード対応により、98/Me/2000のサポートが難しくなったことがきっかけである。

障害報告(2013.12.18)†

V6.41〜V6.63で発生を確認しましたが、V6.26では発生しないようです。

【現象】
コマンド*MARK""のある曲の再生中、最後に到達した瞬間にシークバーの[<]をクリックすると、
次に鍵盤をクリックして再生した際に無音となる。タイミングはかなりシビア。
音が消えても、一度停止して再開すると再び音が出る。

【再現コード】

dddd *MARK"" dddd

【追記】
本件の不具合を発現させるためには*MARK""は必ずしも必要でなく、
以下の様な再現コードにおいても、曲尾到達タイミングで[BS]キーを押下して曲頭に巻き戻すと、
続く再生で同様に無音演奏となる。

dddd

(V6.62)版数表示部分に♪マークが表示されていない状態で演奏する場合がある†

対応状況(2013.12.02)†

V6.63にて対応済み。

(原因)
演奏停止時点でのメインウィドウのシークバーによる位置決めは単純であるが、演奏中のシーク操作ではシーク後に演奏を再開する仕様である。
演奏中のシークであっても、内部処理としてはシーク開始時点で一旦MIDI音源をクローズし、シーク先が決定した時点で再度オープンし演奏を再開する。
一方、版権表示部分の♪マークは、基本的にはMIDI音源がオープンされ演奏している状態を表現しているが、演奏中のシークにおいては
内部的にMIDI音源がクローズされていても♪マークを表示したままにしておき、停止状態でのシークか演奏中のシークかを識別し易くする仕様である。
そして、どちらのシークであるかを内部フラグに記憶しておき、無駄な描画をしない様、演奏中シークの場合は♪マークを再描画しないようにしてあった。

しかし、本件の状況のように演奏開始とシークが間髪入れず実施されると、内部フラグと♪マーク表示との整合タイミングにずれが生じ、
♪マークが表示されていない状況で無駄な描画を行わないシーケンスに入ってしまい、結果として♪マークが非表示状態で演奏している状態に陥った。

なお、V6.51からV6.52にマイナーアップした際、確実なメッセージ処理をするために、MIDIオープンと演奏開始との間に0.1秒ほどのインターバルを与えた。
このインターバルが、より「演奏開始とシークが間髪入れず実施される」状況を発生させ易くしていた。
このインターバルが存在しなければ確率は低くなるが、所詮原理的に本症状は発生する。

(対処)
♪マークの描画に関しては、シーク区分の内部フラグ状態によらず、MIDI音源オープン時に常に表示させるよう改めた。

障害報告(2013.12.01)†

末尾に空でない文字列をもつ *STOP があり、それより前に *MARK があるMuse データで確認した挙動です。

*MARK を通過した後に Ctrl+→ を押して、*STOP の位置で停止している状態で、スペースキーを押すと♪が表示されます。
その一瞬後に Ctrl+← を押す(タイミングがちょっと微妙)と、♪が消えて、直前の *MARK に戻って再生が始まります。
しかし、このとき♪が消えたままで再生している状態になります。

更に単純な状況で再現しました。
MARKは不要でした。

_1
*STOP"xxx"

(1)スペース押下で冒頭から演奏開始（上記データでは音は出ないけど）
(2)演奏している間に[CTRL]キーを押下（以降、[CTRL]は押しっぱなしです）
(3)STOPで停止したら、スペース押下の直後に、間髪入れず[←]押下（[CTRL]は押したまま）
(4)シークバーが曲頭に戻って演奏開始（この時点で♪が表示されていない）

(V6.61)マクロ繰返し数の記述エラーを検出しない†

対応状況(2013.11.29)†

V6.62にて対応済み。

(原因)
Museは、 *STOP"" による完全停止以降の記述に関して、実際に利用されるマクロ以外の文法チェックは実施しない仕様である。
また、その繰返し数は利用時に決定されるため、それもエラーチェックしない仕様である。
この仕様を実装した際、 *STOP"" による完全停止以前の記述に関しても同様の処理を施していた。

(対処)
コマンド *STOP"" の前後に拠らず不正な繰返し数を検出した段階で繰返し数に負値を与えておき、
実際の演奏シーケンスで内容を展開する際、繰返し数をチェックする方法に改修した。

(補足)
本件の対応により、繰返し数ゼロのマクロ(有名／無名を問わず)においても、 *STOP"" による完全停止以降の記述と同様の扱いが可能となった。
すなわち、実際に利用されるマクロ内の範囲のみ文法エラーを検出する。 よって、繰返し数に関しても不問となる。
ただし、利用されるマクロ内に記述された階層的なマクロに関しての繰返し数はエラー検出される。

障害報告(2013.11.29)†

以下の様な記述は文法エラーであるが、エラーダイアログが出ず、繰返し数１として処理されてしまう。

#A0 $macro{ drm } M

名前の無いマクロでも同様。

#A0 { drm } M

(V6.61)Muse起動直後に鍵盤を右クリックすると落ちる†

対応状況(2013.11.28)†

V6.62にて対応済み。

(原因)
症状は１年前(2013.01.27)のV6.31のバグと同じであるが、別の原因による障害。

V6.60での文法エラーダイアログ後のリロードでダウンする障害の対処をした際、
フォント名称の切替え制御を変更したが、起動直後のシークキャンセルの考慮が欠落していた。
起動直後のＢＳキーはシーク防止の対処を施していたが、マウス右ボタンでは防止の対処を怠っていた。

(対処)
起動直後のマウス右ボタン時もシークキャンセルの判断を追加した。

(補足)
本件の対応に伴い、V6.50時点から内包し続けていた以下の障害も解消した。
「起動直後の右ボタン押下でメンバー情報の楽器がすべてグランドピアノになる」

障害報告(2013.11.29)†

データを何も読み込まない状態で鍵盤を右クリックすると、落ちますね……。
こちらでは 100%の確率です(・д・ )

(V6.60)ROOMコマンドの内容が反映しない場合がある†

対応状況(2013.11.20)†

V6.61にて対応済み。

(原因)
ROOMコマンドの文脈解釈における考慮不足。
具体的には、開き括弧および文字列終端検出でデリミッタ処理を実施していたが、Q(あるいはR)の検出ではそれを怠っていた。
なお本件は、V4.40にてROOMコマンドをサポートした時点からの潜在バグであった。

(対処)
正しく文脈を解釈するよう改修した。

障害報告(2013.11.19)†

MU2000 を使用していて気づいたのですが、どうもROOMコマンドが利いていないようなのです。

*ROOM " R3 Q2 "	;利かない

としても、MU2000 は「HALL 2」と報告してきます。
機能→演奏会場の確認で小ホールを「SEND」すると切り替わります。
とまた、音源依存の話かなとも思いましたが、他の方のデータをいろいろ調べているうちに以下のことも分かりました。
以下のコマンドは利くんです。

*ROOM " R3( ) Q2 "	;( ) 内は省略しても、利く
*ROOM " R3 "		;Q がないと、利く

不具合一覧の「(V5.36)ハード音源(MU90B)にて、演奏会場の設定があると再生ができない」のあたりにも関係しているのかとも思われますが、
上記３つでコマンドの送り方が違う、などあるのかな？

以下は、MuseのMIDIエクスポートの結果
＜*ROOM "R3 Q2" の場合＞

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

＜*ROOM "R3() Q2" の場合＞

f0h 41h 10h 42h 12h 40h 01h 30h 03h 03h 04h 40h 48h 00h 7dh f7h
f0h 41h 10h 42h 12h 40h 01h 37h 00h 08h f7h
f0h 41h 10h 42h 12h 40h 01h 38h 02h 00h 40h 08h 50h 03h 13h 00h 57h f7h

＜*ROOM "R3" の場合＞

f0h 41h 10h 42h 12h 40h 01h 30h 03h 03h 04h 40h 48h 00h 7dh f7h
f0h 41h 10h 42h 12h 40h 01h 37h 00h 08h f7h

★以上の３種類のMIDIで、１つ目のエクスクルーシブの内容が“R3 Q2”だけ異なる

f0h 41h 10h 42h 12h 40h 01h 30h 04h 04h 00h 40h 40h 00h 07h f7h	;R3 Q2
f0h 41h 10h 42h 12h 40h 01h 30h 03h 03h 04h 40h 48h 00h 7dh f7h	;R3() Q2
f0h 41h 10h 42h 12h 40h 01h 30h 03h 03h 04h 40h 48h 00h 7dh f7h	;R3

(V6.60)文法エラーのダイアログを閉じた瞬間にリロードをすると落ちることがある†

対応状況(2013.11.19)†

V6.61にて対応済み。

(原因)
文法エラーが起きた際、途中まで読込んだMuseデータはすべてメモリ上からクリアする。
一方、テキストエリアに描画するためのフォント名称は、MuseデータのFONTコマンド文字列へのポインタとして記憶している。
文法エラーが起きた直後、本来必要の無いテキストエリアの描画を行っており、
その際、既にメモリ解放されたエリアのフォント名称を参照していた。

(対処)
Museデータをクリアした場合は、フォント名称へのポインタをスタティック上のデフォルトフォント名称に切替える様改めた。
また、本来必要の無い文法エラー直後のテキストエリア描画を実施しない様に改めた。

障害報告(2013.11.16)†

記述エラーのダイアログを閉じた瞬間にリロードをすると落ちることがあるようです。
記述ミスを含む大きめのデータが起きやすいと思います。
タイミングはダイアログが消える瞬間ぐらいです。

また、記述ミスが1300行代にあるデータでしか今のところ起きません。
2000行代に記述ミスを作っても落ちないし、1600行代でも落ちないんですが、
同じデータで1300行代あるいは1400行代に記述ミスを作ると落ちます。

症状を起こすための操作手順

?データの1388行目に何かしらの記述ミスを入れる
?読み込む
?ctrlを押しながらダイアログの[OK]を押す。
?あるタイミングでLを押してリロードする

こんな感じで落ちるのを確認しています

(V6.60)繰返し演奏にてシークバーが先頭に戻った時点でクリックするとエラーになる†

対応状況(2013.11.13)†

V6.61にて対応済み。

(原因)
演奏が曲尾に到達した時点で、一旦MIDIデバイスをクローズし、曲頭に戻してから再オープンを実施しているが、
そのクローズからオープンまでの間に、鍵盤のクリックが起こると手動での演奏開始(つまり再オープン)が発行される。
MIDIデバイスがオープン済みであるか否かのフラグで、二重オープンの際に２度目をスキップするシーケンスを組んでいたが、
MIDIデバイスオープンに時間が掛かる(サウンドフォントなど)の場合、２度目のオープンが発行された時点で、
未だフラグがセットされていないという事態に陥り、結果として二重オープンを実施することになっていた。
二重オープンを強制的に実施することで「MIDIデバイスをオープンできません」のエラーが出現した。

(対処)
オープン処理をクリティカルセッション制御とし、二重オープン時に２度目が確実にスキップするよう改善した。
なお、クローズ処理も含めてフラグ整合を取るべきと判断し、今回のクリティカルセッションと共通のオブジェクトでクローズ処理もくくることにした。

障害報告(2013.11.13)†

繰返し演奏のモードにして、シークバーが先頭に戻ったタイミングで停止させるとエラーが表示されました。

エラーメッセージ
タイトル：(Muse)システム状況
内 容：MIDIデバイスをオープンできません

サウンドフォントを使用した場合に、発生するようです。
『Microsoft GS Wavetable Synth』では、発生しませんでした。
Vre 6.60 で確認しましたが、Ver 6.56 でも発生していました。

(V6.55)X指定で記述したNRPNがシーク時に反映されない場合がある†

対応状況(2013.10.21)†

V6.56にて対応済み。

(原因)
X指定のNRPN,RPNは波形加工以外も多様に存在するので、バッファ量が膨大になるため都度即座に送信している。
一方、波形加工は特に遅延指定の負荷が高いため、バッファリングによる最終値送信としている。
また波形加工のＭＳＢは共通なため、ランニングステータスを活用している。
その際、波形加工を検出した時点でランニングステータスを前提にしてＭＳＢのバッファをクリアしてしまい、
その後、即時出力のNRPNが検出された場合、ＭＳＢの送信されない事態に陥っていた。

(対処)
ＭＳＢのクリアは即時出力時側で実施するように改めた。

障害報告(2013.10.20)†

最近のバージョンの Muse においてシーク時に送信されないNRPNがあるようです。
例えば以下のようなデータです。

#B0|@ P023 Q=104.84 
X99=01 X98=53 X6=38 ;EQ Treble Freq
X99=01 X98=49 X6=114 ;EQ Treble Gain
_1% d4rmfs

このように、前に Q= や W= などが存在する場合、これらの NPRN メッセージがシーク時に正常に送信されていないようです。
古いバージョンでテストしたところ、V6.41 では正常で、V6.50 から異常が発生するようです。

(V6.54)文法エラー情報をクリップボードに出力する際の改行コードが不正である†

対応状況(2013.09.07)†

V6.55にて対応済み。

(原因)
クリップボードにおいては、CR(0x0d)-CF(0x0a)の２コードを必要とするが、CFの出力処理を失念していた。
本障害は初版の時点から内包されていた。

(対処)
２コード出力するよう改めた。

障害報告(2013.09.07)†

キーボードの上下キーでリロードを行った際、文法エラーがあるとその内容がクリップボードに出力されるが、
テキストエディタに貼り付けると部分的に文字化けしたり、本来２行の内容なのに改行をしなかったりする。

(V6.53)途中再生時に波形加工が正常に反映されない場合がある†

対応状況(2013.07.22)†

V6.54にて対応済み。

(原因)
Museは極力無駄なコントロールメッセージを音源に送出しないようにして音源負荷を低下させる工夫を施している。
その一環として、同一のMSBやLSBが続く場合は送出の省略を実施している。
このため、単独のデータエントリーでコントロール値を変更する場合が存在する。
一方途中再生時において、シークを効率的に実施するため、波形加工のメッセージはその最終値のみを一括送出するようにしている。
曲頭から再生した場合は矛盾は起きないが、途中再生時の場合に単独のデータエントリーに対して省略されているLSBの種別が食い違う可能性があった。
V6.41までは、この食い違いを発生させないように最終的に発行したMSBとLSBをシーク処理の最後に再発行していたが、
V6.50でシーク処理全体を組み直した際、この再発行処理を取り除いてしまっていた。

(対処)
最終のLSB再発行処理を復活させた。
なおMSBの方は、波形加工の一括送出処理の特性上、種別の食い違いが発生しないため、再発行しないままとしている。

(再現性)
VSCでは本症状は再現しなかったが、これはVSCの特殊な音源仕様が理由である可能性が高い。
VSCの波形加工(周波数)は、Q=?,?における?と?が独立ではなく、どちらを指定しても同じ１つの効果だけをサポートしている模様。
すなわち、?を指定しても、?を指定しても、最後に指定した値でもう片方を律則してしまう。
(波形加工の確認ダイアログで実験したところ、かなりの確度で本推論が正しいと思われる)
もしこの推測が正しいとすると、LSBの種別が食い違うというバグがあっても、VSCは不具合が起きていないかのように振舞うことになる。

障害報告(2013.07.21)†

以下のデータは最初から再生した際には問題はありませんが、途中から再生すると「Q=64.64」が反映されないようです。

Q=1.0 Q=0.:2
d1
%*MARK "途中再生"
Q=64.64
d1

冒頭の「Q=1.0」や、「Q=0.:2」を外した場合や、「Q=64.64」の部分を「Q=64.64:i1」のようにするのはOKです。
バージョンは、V6.50以降から発生しているようで、V6.41では未発生でした。
現象を確認した音源は、
? Roland SC-8850(UM-1G経由)
? CoolSoft? VirtualMIDISynth
? Timidity
です。
SoundFont?によってはQ=の効きが違うので、効果がわかりにくいこともありますが、GeneralUser? GS等30MBレベルのSFなら再現できると思います。
VSCでは、演奏終了時のメモリ解放を有効にするか否かで挙動が変わる場合があったかと思います。

(V6.52)音源メニューにサウンドフォントが表示されない†

対応状況(2013.07.13)†

V6.53にて対応済み。

(原因)
V6.50にて音源メニューの構築処理を効率化した際、コンフィグファイルが存在しない場合に、構築ループを脱出してしまうという不具合を埋め込んでしまった。
具体的には、continueとすべきところをbreakとしてしまった極めて初歩的なミス。

(対処)
コンフィグファイルの有無に拠らず処理を継続する様に改めた。

障害報告(2013.07.11)†

音源メニューに、「VirtualMIDISynth」は表示されますが、 サブメニューでサウンドフォントが、表示されなくなりましたので、 報告させていただきます。
v6.50辺りからのようです。

確認バージョン
v6.36　：○
v6.37　：○
v6.40　：○
v6.41　：○
v6.50　：×
v6.51　：×
v6.52　：×

OS：Windows 7 Pro 32bit
VirtualMIDISynth：v1.8.1

(V6.51)「繰返し演奏」で何度か演奏させているとエクスクルーシブが効かなくなる場合がある†

対応状況(2013.07.03)†

V6.52にて対応済み。

(原因)
演奏を停止／再生させたり、シークさせたり、繰返し演奏させたりした場合、
以下の様な演奏停止から演奏再開までの処理がほぼ共通して実行される。

?演奏の停止
?音源のクローズ
?音源のオープン
?初期コマンドおよびシーク位置までのコマンドを音源へ送信
?演奏の再開

上記一連のシーケンスで、繰返し演奏が他の操作と異なる点は?と?の間のインターバルにある。

繰返し演奏では、曲が終了してから曲の演奏を再開するまで一瞬で移行すると、プレーヤーとして落ち着きの無いリピート演奏になるため、
?と?の間にあえて２秒程度のインターバルを与えていた。
このインターバルは待ち時間の間でもキーやマウスの入力を受け付けるよう、Sleep()処理ではなくタイマイベントを使ったカウンタ方式を使っていた。

この方式のインターバルを取り払うと症状が改善したため、本インターバル処理に問題があると推測される。
※問題の箇所は絞られたが、真因として合理的説明が付かないため、本件に関しては断続的に追跡を試みる。
＜追記＞Elekenさんの分析により、真因が明確となった(下記、掲示板からの転載を参照のこと)

(対処)
リピート処理において、?と?の間のインターバルを除去した。
なお、タイマイベントを使ったカウンタ方式は、マークコマンド刻みに位置決めする逆方向のシーク操作でも利用しているが、
こちらに関しては現時点で支障が生じていないため、現状維持とした。

プレーヤーとしては即応型の繰返し演奏となり少々バタツキ感があるが、Museデータの曲頭、曲尾に休符を配しているデータも多くそちらに委ねる事とした。
また、エンドレスタイプの演奏に関しては逆に有利に働くと判断している。

＜真因分析＞

[9051]　Re[11]: 「繰り返し演奏」機能にて…  
投稿者：Eleken 投稿日：2013/07/03(Wed) 21:11:58

私も同じ音源を使っています。
MuseWiki にて
> 本件に関しては断続的に追跡を試みる。
となっているので、おせっかいかもしれませんが、少し問題解決のヒントを書いてみます。

結論から言うと、この問題は本質的には「繰り返し演奏」に固有の問題ではなく、
「GS リセット下で XG Sys. Ex の付加されたデータ」という、GS 準拠でも XG 準拠でもない、
いわば想定外の MIDI 信号を受信したときの音源の挙動に関わる、音源固有の問題です。

「繰り返し演奏」固有の問題でないことは、以下のデータを最初から再生したときと
途中から再生したときの挙動の違いから明らかです。
（本問題はソフトウェア音源では生じません）
*ROOM"Q2(,,,,,,) " ; Set Chorus (GS) [*1]
_1%
*POOL"43,10,4C,02,01" ; Set Variation (XG) [*2]
*DATA"5B,09" ;Variation PART: #Z
*DATA"40,41,00" ;Variation TYPE: CHORUS 1
*DATA"4E,00,34" ;PARAM. 7W: EQ Low Gain (-12dB)
#Z1 o2 {|d4/r dr|}4 _1
#Z2 o2[f+]0 |<d+4/>{,8/}6| {|{,8/}8|}3 _1

具体的に言うと、[*1] と [*2] の受信するタイミングに関わっているようです。
[*1] を [*2] より前に受信したとき、音源 (MU1000) は 以降の XG バリエーションエフェクトのコーラス
[*2] を無効化するようです。
逆に [*2] が [*1] と同時かより以前に受信されると、[*2] は有効化されるようです。
おそらく、GS 音源をエミュレートする際の XG 音源の仕様だと思われます。

[9052]　Re[12]: 「繰り返し演奏」機能にて…  
投稿者：開発者 投稿日：2013/07/03(Wed) 22:12:55　 [ 返信 ]  

Elekenさん
>「繰り返し演奏」固有の問題でないことは、以下のデータを最初から再生したときと
> 途中から再生したときの挙動の違いから明らかです。
> ・・・
> 具体的に言うと、[*1] と [*2] の受信するタイミングに関わっているようです。
> [*1] を [*2] より前に受信したとき、音源 (MU1000) は 以降の XG バリエーションエフェクトのコーラス
> [*2] を無効化するようです。
> 逆に [*2] が [*1] と同時かより以前に受信されると、[*2] は有効化されるようです。
> おそらく、GS 音源をエミュレートする際の XG 音源の仕様だと思われます。
素晴らしい解析力！！

現在のMuseの「繰返し演奏」は、
初期化関係のエクスクルーシブ（この場合はROOM[*1]が含まれます）を送信した後、
人工的に２秒ほどのインターバル挿入して、そこから徐に演奏を開始していました（以降の[*2]の発行となります）。
つまりElekenさんが例示してくれたデータの _1% が必ず存在するといった状況ですね。

・・・実は、昨晩から今に至るまで、MIZさんにトライアル版を何度も送りつけては状況を確認してもらっていました。
MIZさんとの実験の結果、このインターバルを取り払うと症状が改善する事実がわかりました。
よくある音源の問題として、インターバルの無いメッセージで欠落が起きるというのがあるため、
インターバルが無い方が症状が改善するという事態に、私もMIZさんも戸惑っていたのです。
まったく合理的説明を付けられずにいました。

Elekenさんの今回の見解で、一気に霧が晴れた気分です。
本当にありがとうございます！
> おせっかいかもしれませんが、
全然おせっかいじゃありません！救世主です！！

つまり、こういうことだったんですね。
--------------------------------------------------
?従前の繰返し演奏モードでは、[*1] → インターバル → [*2] としている。
?そのインターバルを取り払うことで、[*1]と[*2]がほぼ同時に発行されるようになった。
この?と?では、音源側のメッセージの扱いが異なる。
現在のMuseは、繰返し演奏は?となり、それ以外の停止／再生では?となる。
したがって、現象は繰返し演奏でのみ出現した。
--------------------------------------------------

そう言えば追跡の最中、MIZさんが「ROOMコマンドの有無で症状が変化するのが気になる」と言ってました。
MIZさん、良い勘してますっ！

そして、どうもこの「ほぼ同時」という部分がかなり微妙みたいですね。
実はMIZさんの実験によると、インターバルが挿入されているMuse(V6.51)にて、
１回目の演奏：データ部のエックスクルーシブが効いている。
２回目の演奏：データ部のエックスクルーシブが効いていない。
３回目の演奏：データ部のエックスクルーシブが効いていない。
４回目の演奏：データ部のエックスクルーシブが効いている。
・
・
・
といった感じで、なんと４回目に効いている状態に戻っていました(苦笑)。

なんにしても、音源仕様ということで納得です。
なお、Elekenさんのご記帳を、そのままMuseWikiに掲載させて頂きました。
だって、感動しちゃったんだもん(笑)。お許し下さい。

障害報告(2013.07.01)†

以下のデータを「繰返し演奏」させると、１回目と２回目で音色が変化してしまう。

*ROOM" R2(,1,115,30,,40) Q2(,,,,,,) " ;1(UM-3G(1))
*DATA"43,10,4C, 02,01,5B,09";メンバーZ
*DATA"43,10,4C, 02,01,40,41,00";CHORUS 1
*DATA"43,10,4C, 02,01,52,00,34";EQ High Gain 
#Z1 o2 {|d4r dr|}4

・繰返し演奏ではなく、通常の停止／再生操作では再現しない
・ROOMコマンドを取り去るなど、これ以上簡素化すると再現しない
・muse.iniのVGSフラグは１(すなわち、停止時にGS音源初期化を発行している)
・使用している音源は YAMAHA MU1000

(V6.40)初期化パラメータVGSをゼロにするとXG音源で音が鳴り止まない場合がある†

対応状況(2013.05.11)†

V6.41にて対応済み。

(原因)
V6.34において、MIDI音源クローズ時点でGSリセットを送信するように改修した際、
それまで演奏停止時点で確実な発音停止を図るために送信していた オールサウンドオフとコントローラリセットが不要となることに気づき撤廃。

V6.35において、クローズ時点のGSリセット送信は他のソフトと組み合わせて使用する際に不便であるとの進言に基づき、
初期化ファイルにて送信の有無を切り替えられるように改良。

この時点で、GSリセットを送信しない設定をした場合、
GSリセットの送信をせず、オールサウンドオフとコントローラリセットも送信しない
という状況となり、確実な発音停止ができない症状に陥った。

(対処)
GSリセット送信をしない設定の場合は、オールサウンドオフとコントローラリセットを送信するように改修した。

障害報告(2013.05.11)†

XG 音源の MU1000 を USB 接続で使用するとき、muse.ini で VGS=0 として使用すると、
最近の Muse では一時停止の際にノートオフが送信されません。
音が鳴りっぱなしになってしまいます。

手持ちの他の音源では、ハードウェア音源も含め、症状は発生しません。
過去の Muse でも試しましたが、V6.30 では症状は発生しませんでしたが、
V6.37 ではすでに症状は発生しました。
OS は 32bit版の Windows XP です。

(V6.40)譜面モニタ音部領域のテンポ属性表示で％記号が２つ表示される場合がある†

対応状況(2013.05.11)†

V6.41にて対応済み。

(原因)
V6.40の開発において、譜面モニタの属性表示のための構築処理を一部見直したが、その際に％記号が１つのみであることを前提に処理を組んでしまった。

(対処)
最後の％記号を検出し、それのみを採用するよう改修した。

(補足)
本障害対応とは別件であるが、起動パラメータに *q を指定した場合、*STOPコマンドで一時停止せず通過する仕様に変更した。
これにより、バッチ処理で複数のMuseデータの連続演奏が可能となった。

障害報告(2013.05.10)†

例えば、以下のようなデータで４小節目までスクロールさせると、音部エリアの表示が < %90%6 > といった不正な表示になる。

_1 _1 _1 %90%60:2 _1`10

(V6.36)ドラム試聴においてタブで遷移できないボタンがある†

対応状況(2013.03.08)†

V6.37にて対応済み。

(原因)
V6.31において、ドラムのボタンリソースを効率化し、テキストリソースによる随時書き直しに改めた際に、
ドラムセットの変更においてもボタンリソースを変更させないことによる影響の考慮不足で埋め込んでしまったバグ。
EthnicとAsiaでアサインされないo1dが無効化された際、タブストップ可能なボタンが存在しない状況に陥っていた。

(対処)
EthnicとAsiaが選択された際o1d+のボタンにタブストップ属性を割り付け、他の選択が起こった時にそれを解除するという処理を追加した。

障害報告(2013.03.08)†

ドラムの試聴でEthnicあるいはAsiaを選択し、タブでの移動を行う際、o1列にフォーカスが移動しない。

(V6.35)メンバー情報で矢印キーを押下するとスクリーンリーダーが読み上げてしまう†

対応状況(2013.02.24)†

V6.36にて対応済み。

(原因)
V6.35における、メンバー情報の警告音抑止の対処で、ダミーのエディットコントロールを配置したが、それが矢印キーの読み上げを誘発した。

(対処)
ダミーのコントロール配置を取り止め、ディスパッチループ内でメンバー情報のみ従来の判断処理を行うように改修した。

(補足)
今回の障害対応とは関係が無いが、V6.36にて以下の機能強化も実施した。
・ドラム試聴にドラムセット「ASIA」を追加した
・フィンガー情報および譜面モニタの表示属性切替を該当キー押下で可能とした

障害報告(2013.02.23)†

メンバー情報ダイアログでキー押下時に警告音は鳴らなくなったのですが、
スクリーンリーダーが、現在のフォーカス位置をReadOnly?のエディット領域として認識しているようで…
キーを押すと、そういうことを毎回読み上げられてしまいます。

(V6.34)メンバー情報でキー押下すると警告音が鳴る†

対応状況(2013.02.21)†

V6.35にて対応済み。

(原因)
V6.28で、メイン関数のディスパッチ処理をMicrosoftが提唱する効率的な方式に変更したが、その影響で音が出るようになった。
ダイアログ上に文字入力を受け付けるコントロールが存在しないために、問合せ関数、IsDialogMessage?()の中で発音している模様。
なお本症状は、Win7では発現しない。
(対処)
メンバー情報ダイアログに、読取り専用、かつ大きさゼロのエディットコントロールを、ダミーで配置することで問題を回避した。

障害報告(2013.02.21)†

メンバー情報ダイアログを出した状態で英数字系のキーを押下すると、Windowsの一般の警告音が鳴るのは私だけでしょうか？
@Windows XP
V6.29の頃から出るようにはなっていました。V6.27では鳴りません。

(V6.33)シークを素早く断続的に繰り返すと落ちる場合がある†

対応状況(2013.02.16)†

V6.34にて対応済み。

(原因)
Museが演奏時に駆動するタイマーコールバックと、そのタイマーの停止は別のスレッドでの実行である。
よってコールバックが実施されている最中にタイマー停止が起こる可能性があるが、その対処を行っていなかった。
タイマー停止直後に音源のクローズを実施しており、結果としてクローズ処理と発音処理が競合してハングしたと思われる。

(再現性)
タイマー停止から音源クローズまでの間に、最後のコールバックによる演奏処理が完了しきれない場合に限り発現するため、
再現性は極めて低く、再現させるためには以下のような状況が必要であった。
・演奏開始と停止が短周期かつ高頻度に繰り返される(左右カーソルキーの高速な押下／開放による断続的シーク操作など)
・演奏処理が充分に重い(多量のデータ、譜面モニタ、サウンドフォントなどの高負荷状態)
・タイマー停止から音源クローズまでが速やかに処理される(性能の良いＰＣ。Win7搭載のＰＣは往々にしてパフォーマンスが良い)

(経緯)
V6.27からV6.28にバージョンアップする際、高速化のために演奏停止の処理に手を加えた。
従来、音源のクローズ命令を確実に実施するために適度なインターバルを与えていたが、
それが無くとも安定して音源処理が完了することを確認したため、V6.28でそのインターバルを取り払った。
しかしこのインターバルは、本件で発現したタイプの不具合を抑止するという別の意味も偶然持ち合わせていた。
(当時は、抑止を意図してインターバルを与えた訳ではなかった)
このインターバルは、タイマーを停止してから音源をクローズするまでに、適度な時間間隔を与える事になり、
結果として、タイマー停止後に残存するタイマーコールバック内の演奏処理をすべて完了させる余裕を生み出していた。
V6.28でその余裕時間を取り払ったため、今回の症状が発生する事となった。

(検証)
追跡中、midiOutShortMsg?()に、クローズ後の音源ハンドルを渡していることが原因であると分析したこともあったが、
強制的にそのような状況を作り上げた実験では、midiOutShortMsg?()は、
MMSYSERR_INVALHANDLE(指定されたデバイスハンドルが無効)を返却するのみで、ハングすることは無かった。
この挙動は、音源ハンドルをNULLにしても、またランダムで意味のないハンドル値を指定しても同様であった。
このことから、音源ハンドル値の不正がハングの引き金になっているわけではなく、
音源管理モジュールの深部においてクローズ処理と発音処理の競合が起きた際にハングすると推測している。
よって、この競合状態を回避することが、本質的な解決につながると結論した。

(対処)
タイマー停止時に適度なインターバルを与え、その後にMIDI音源のクローズを実施する事とした。
またタイマーコールバック(演奏処理)でのMIDI音源へのデータ送信直前にタイマー状況をチェックし
もし停止していたら送信しないようガードを掛けた。

障害報告(2013.02.09)†

●報告１
メインの画面で、再生しながらCtrl+→,←でマーク間を行ったり来たりすると、落ちることがあるようです。
いっぱい動かすとなります。1、2回じゃ発生しません。最低で4回、最高で30回ぐらいでした。
譜面モニタを表示した時にだけ起きるようです。
だから音源と言うよりは描写系の何かだと思います。
あと、データによっても起きるか起きないかが変わります。
小さめのデータは起きないようで（起きるのかもしれませんが30回ぐらいでは起きませんでした）
大きめのデータ（というより16メンバーをフルに使っていると起きやすい）だと起きます。
ちなみにMARK文のあるデータです。

●報告２
譜面モニタを表示しなくても、メインの画面で再生しながら
Ctrl+→を数回押すと落ちたり落なかったりします。
因みに落ちた時の画像です。↓

●報告３
音源の話があったので色々試してみると、
MSGSやサウンドフォントなどの、ソフト音源系（音源のオープンに時間がかかる系）が出やすいようです。
現行バージョンだとサウンドフォントなら譜面モニタなしですぐに落ちます。
テスト版だと、譜面モニタなしだと今のところ落ちてないです。

●報告４
[→]だけでも落ちますね。[→]を押した時に落ちるようです。
1秒に２、３回程度の押し方で、半分位で落ちました。

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

●報告６
V6.27では落ちない模様です。V6.28では落ちます。

●報告７
逆アセンブルして解析すると、どうやら、次のような呼び出しが発生した後、コケているようでした。
midiOutShortMsg?(hmo, 0x003c4d9d);

第二引数は何の変哲もないノートオンですので問題なしとして、
hmoの値が古い値をとっていたり、どこかで値が破壊されていたり、
などという可能性はないでしょうか？

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

(1) midiOutOpen?()が完了する前に演奏を開始してしまうケースがある
(2) hmoが、バッファオーバーフロー等の影響で破壊される
の2つに絞られたことになると思います。

●報告９
「クローズ後、hmoにNULLが設定される前に演奏処理を行っている」ではないかと考えます。

＜状況の整理＞

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

＜症状を確認した環境＞

[ＯＳ]
Win7(Home)
Win7(Pro32)

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

(V6.32)テキストエリアの文字列に指定したフォントを反映しない場合がある†

対応状況(2013.02.06)†

V6.33にて対応済み。

(原因)
V6.30の開発の際、演奏時の文字列表示シーケンスを効率化し、ＣＰＵの低負荷化を図ったが、
その際に考慮不足で混入したバグ。
演奏時、同時刻内の表示テキスト文字列はその最後の文字列のみを表示するシーケンスに組み直したが、
同時刻内において、該当する表示文字列よりも後にフォント指定があった場合、
そのフォントを採用して文字列を表示する状況に陥っていた。

(対処)
表示文字列が採用すべきフォントを都度記憶しておき、そのフォントで文字列表示を終えた後に、
その時刻内で検出した最終フォントを、カレントなフォントとして採用するよう改めた。

障害報告(2013.02.06)†

例えば、以下のような記述の場合

*MARK"AAA"
*FONT" Shonar Bangla ,2 "
*TEXT"BBB"
*FONT"ＭＳ ゴシック,0"

上記の*TEXT"BBB"部分にその直前の*FONT" Shonar Bangla ,2 "が反映されずMSゴシックで表示されます。
メイン画面のスライダを少し進めた位置でリロードすると反映されますが、実行状態のまま次の楽章に入るとMSゴシックに戻ってしまいます。

(V6.32)メンバー情報に*COLRコマンド指定色が反映しない場合がある†

対応状況(2013.02.03)†

V6.33にて対応済み。

(原因)
V6.32の開発の際、極力軽快に動作するようソースプログラム上で無駄な処理を洗い出し、それらの除去を試みた。
その際、必要なウィンドウ描画の更新リージョンも削除してしまった。

(対処)
再度、以前のソースプログラムと比較しながら入念に必要十分な更新リージョンを確認し、コーディングをし直した。

障害報告(2013.02.03)†

(報告1)
V6.32でデータを読み込んで、*COLR""でメンバー色を変え、リロードした際に、
譜面モニターと本体のメンバー色は変わりますが、メンバー情報の色が変わらないようです。

また、他のデータを読み込んだときにメンバー色に反映される時もありますが
データを変えても色が変わらないこともあります。
ちょっと挙動がよくわかりません。。。

(報告2)
メンバー情報画面の各パートの色が更新されません。
Ver6.31までは正常で、Ver6.32で起こる現象の様に思います。
ちなみに、ＯＳはＸＰ2002 SP3です。

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

(V6.31)Muse起動直後に鍵盤を右クリックすると落ちる†

対応状況(2013.01.27)†

V6.32にて対応済み。

(原因)
右クリックやＢＳキーにより曲頭への巻き戻しのシーク処理に入る。
シーク処理の中では、カレントなフォントデータの参照およびフォントセットを行っているが、
カレントなフォントデータの起動時における初期化忘れにより、不定値のアドレス参照が発生していた。

(対処)
適切な初期化を施した。

障害報告(2013.01.27)†

Museを起動し、データを読込んでいない状態で鍵盤を右クリックすると確実に落ちる。

(V6.30)MARK間に休符しか存在しない場合にシークの位置決めがうまく働かない†

対応状況(2013.01.27)†

V6.31にて対応済み。

(原因)
データのリスト構造を頼りにシーク位置決め判断を実施しているため、AAAとBBBの間にまったくデータが存在しない場合、
AAAに位置決めされた状態と、AAAとBBBの間に位置決めされた状態を、シーク処理モジュールからは全く同一に見えてしまっていた。
そのため、後者であっても前者と同様の演算結果となっていた。
本件は、MARK文初期提供時点からの潜在バグ。

(対処)
時刻情報で制御することも考えたが、MARKが同一時刻に存在する場合に処理が複雑になるため
MARK文の間にデータが一切存在しない状況においては、データロード時点で位置決め用のダミーデータを挿入することとした。

障害報告(2013.01.26)†

以下の様なデータにおいて、シークつまみをAAAとBBBの間に位置決めした状態でシークバーの左黒三角ボタンを押下すると
本来、AAAの位置にシークすべきところが、曲頭までシークしてしまう。

_1
*MARK"AAA"
_1
*MARK"BBB"
_1

(V6.30)リロード時に譜面モニタの水平スクロールバーのつまみが全体に広がる†

対応状況(2013.01.27)†

V6.31にて対応済み。

(原因)
スクロールバーのレンジセットと使用可否指定の処理順序ミス。
本件は、譜面モニタ初期提供時期からの潜在バグ。

(対処)
レンジセットの後に使用可否指定を実施するように改めた。
なお、エラーが発生したデータをロードした際、譜面モニタのストレッチで、
保持しておくべきエラー以前の表示位置を書き換えてしまう障害にも対処した。

障害報告(2013.01.26)†

データをロードする前に、譜面モニタをあらかじめ表示しておき、
スクロールしなくても終止符がウィンドウ内に表示される程度に短い演奏時間のMuseデータをロードすると
本来、水平スクロールバーがグレーアウトすべきところを、横いっぱいに広がったつまみが表示される。

(V6.30)リロードを繰り返すとMuseが落ちる場合がある†

対応状況(2013.01.27)†

V6.31にて対応済み。

(原因)
メモリ解放実施済みの文字列アドレスへの参照を行っていた。
具体的には、フォント名の文字列を指し示すアドレス変数の処理部分。
以下の２点において、上記の症状に陥っていた。
＜その１＞
Museデータロード時、同時刻に存在する同名のフォント指定(*FONT)をカットするデータコンパクト化の後処理を行っているが、
そのカットするフォントがヘッダー(*HEAD)に反映させるフォントの場合、ヘッダー文字列描画で不定参照となった。
＜その２＞
フォントファイルのロード負荷を低減するため、テキストエリアに一旦セットしたフォント名を記憶しておき、
続けて同一フォント名のセットが必要になった際にそれを実施しない処理を施しているが、
データをロードし直した際に一旦セットしたフォント名実体の記憶アドレスが変更されるため、
その後のシーク処理やテキスト表示における同一フォント名の比較処理の際に、不定参照となった。

(対処)
＜その１＞に関しては、残存させる側の同一フォントのアドレスに挿げ替える処理を追加した。
＜その２＞に関しては、データロードの際にセット済みアドレス記憶をNULL化し、NULLの場合は比較処理を行わない処理を追加した。

障害報告(2013.01.25)†

以下の操作を繰り返すと、高頻度でMuseが落ちる。
「文法エラーの起こるデータをロードし、その文法エラーを訂正して再度ロードを行い、直ぐにシークを実施する。」

(V6.30)波形加工ダイアログの強弱スライダーを動かすと２度発音が起こる†

対応状況(2013.01.11)†

V6.31にて対応済み。

(原因)
スライダーを操作すると様々なタイプのイベントが発生するが
その仕分け処理にミスがあった。

(対処)
スライド位置が確定した際に発生するイベントのみ発音させるように改修した。
なお今回の改修に伴い、残響、揺らぎ、コーラスのスライダー、および
波形加工の垂直スクロールバーの全てのコントロールの操作で発音するように仕様を変更した。
加えて、波形グラフのエリアをクリックすることで発音する機構は廃止した。
また発音の機会が増加したため、発音を積極的に停止させたい場合があることを想定し、
[COPY]ボタンを[STOP & COPY]とし、本ボタンの押下で発音停止を可能とした。

障害報告(2013.01.11)†

ドラム波形の強弱でキーで動かすと２回鳴ります。

マウスでクリックすると、
クリック→鳴る
そこから放す→ピッチが高くなって鳴る
ようです。

(V6.30)楽器の試聴ダイアログのタブ遷移に異常がある†

対応状況(2013.01.11)†

V6.31にて対応済み。

(原因)
V6.30において、ダイアログのレイアウトおよび構成を見直した際、
変更に対応したリソースの WS_GROUP および WS_TABSTOP の設定を失念した。

(対処)
リソース属性の設定を精査し、正しく指定し直した。

障害報告(2013.01.11)†

楽器の試聴ダイアログにて、「121：Fret ノイズ」ボタンを選択した状態で上矢印キーを押すと、
フォーカスが「128：銃声」ではなく、「■ 音止」に移動してしまう。
また「128：銃声」を選択した状態で下矢印キーを押しても、フォーカスが移動しない。

前バージョンのV6.29では、
「121：Fret ノイズ」ボタンから上矢印キーで「128：銃声」へ、
「128：銃声」から下矢印キーで「121：Fret ノイズ」へトグル移動できていた。

なおドラムの試聴の方は正常動作している模様。

(V6.28)譜面モニタで属性表示を行うと落ちる場合がある†

対応状況(2012.12.18)†

V6.29にて対応済み。

(原因)
本機構の初期実装時点から内在していたバグ。

音部記号の上部に表示する属性値<xxx>の値を算出するタイミングは、五線音符が再描画される時点を採用していた。
そしてその算出値を「値」として記憶し、再描画メッセージを発行していた。
かたや再描画モジュールは、イベントを受けた段階でその算出値から属性値<xxx>の「表示文字列」へ変換整形しそれを描画する。
しかしこのシーケンスでは、「値」から「表示文字列」に整形する段階で譜面モニタの状況が変化していた場合には、
以前の状況のデータと最新状況のデータを混在利用して変換処理を実施することになり矛盾が生じてしまう。
この変換処理は、 「グルーブ(p,q)」「ピッチ(U)」「ペダル(Y)」の場合に実施するため、症状を再現させる概要報告とも一致している。

一方、属性選択ポップアップメニューにて任意の属性を選んだ時点で、そのポップアップメニューが消えるため
その下部に位置する音部記号エリアや五線音符エリアの再描画が必要になる。
もし、五線音符エリアの再描画メッセージが音部エリアの再描画メッセージよりも先に発行された場合は
属性値の算出後に属性値<xxx>の表示が実施されるため矛盾は無いが、
これらのメッセージ順番が逆になった場合、矛盾が生じる可能性がある。
特に、自動譜めくりによって属性値<xxx>を変更すべき状態となっている場合で、
かつ現在表示されている属性とは異なる属性に切替えた場合には、
この矛盾によりNULL参照という事態に陥る可能性が高まる。

音部記号エリアと五線音符エリアの再描画メッセージの発行順序は、その時点のＯＳ処理の状況によるため、
その順序がどうであれ、アプリケーションは正しく動くように設計すべきであるにもかかわらず、
特定の順序を前提とする実装となっていた。

(対処)
属性値<xxx>の値を算出したタイミングで、変換整形を完結させ表示文字列としてそれを記憶しておき、
どのようなタイミングで再描画メッセージが起こっても、その表示文字列で描画するよう改めた。

障害報告(2012.12.16)†

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

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

(V6.27)MARK位置決め後の再生時、テキストが指定外の修飾で描画される場合がある†

対応状況(2012.12.06)†

V6.28にて対応済み。

(原因)
V6.27でシーク処理の性能改善を図ったが、その際のデグレード。

V6.26以前は、シークポイント(MARK)の文字列描画を実施した後、
次に出現する文字列に備えて、事前にフォントの更新を行っておくアルゴリズムであったが、
V6.27の改善で、文字描画が必要になった時点でフォント更新を実施するアルゴリズムに変更した。
にもかかわらず、事前フォント更新の処理を廃棄し忘れていたため、
タイミング上、フォントを変更していない文字にまでフォント更新が起こってしまった。

(対処)
不要な事前フォント更新の処理を削除した。

(備考)
なお本件の対処中、以下の２つの不具合も検出したため並行対処した。
(1)シーク時、ちらつき防止用の不要文字描画の抑止機構が効いていなかった。
　　→比較文字列の冒頭１バイトを片側だけ取り除いていた。
(2)マーク文字列に、ヘッダー文字列のフォントが不正に採用される場合があった。
　　→シーク処理の初期値にデフォルトではなくヘッダーのフォントを採用していた。

障害報告(2012.12.05)†

*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)フォーカス機構にて当該フィンガーの音が出ない場合がある†

対応状況(2012.11.23)†

V6.27にて対応済み。

(原因)
現在のMuseは、メンバー情報やフォーカス機構において、
ミュート指定したメンバーやフィンガーであってもノートＯＦＦの命令はすべて音源に送っている。
その理由は、もしノートＯＮの直後（まだノートＯＦＦが送信されていない状態）で、
そのメンバーやフィンガーにミュートを掛けると、音が鳴り続けてしまうという事態を抑止するためである。

＞ なぜ一つ目が消えないのかは謎ですが…
まず、#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は同時刻のノートＯＮとノートＯＦＦがあった場合、先に全ての音止を送信してから、
間髪入れずノートＯＮを送るように工夫している。
よって、pコマンドを使わないと、OFF(1)→OFF(3)→ON(2)という順番で音源に送信され、
OFF(3)は止めるべき相手がいないため、症状が出ない。

(対処)
連結＆処理用にセットした音符対を表現するOFFからONへのポインタが残存しているため、それを活用して対応を行った。
各音符に新たなフラグ（音源へのノートＯＮ送信済みフラグ）を設け、ミュート対象のノートＯＦＦを検出した際、
先のポインタで対となるノートＯＮをたぐり、そのフラグが既に立っていたら音源に送信し、立っていなければ送信しない
という制御を組み込んだ。

障害報告(2012.11.22)†

*FING"x1 "
@A P72 
#A1 p^i10cc
#A2 cc

この状態で、フォーカス機能を使って#A1だけ再生すると二つ目のcが消えます。
どうやらpコマンドを使って、同じメンバーで同じ音を同じタイミングで出すと消えるようです。
なぜ一つ目が消えないのかは謎ですが…

(V6.26)曲頭付近のペダルオフ(Y0)が出力されない場合がある†

対応状況(2012.11.18)†

V6.27にて対応済み。

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

(対処)
１パス目の読込みではY0カットせず、後処理で実施している“連続する同値のコントロール(それはYに限らず)のカット処理(後送をカット)”
に縮退効果を委ねることにした。ただしこの対応では、演奏冒頭のY0指定をカットせず、すべからく音源に送信してしまう。
１パス目で先読みの処理を行えば理想的対応は可能だが、処理速度の低下を招く恐れがあるため
冒頭のY0カットは行わないことを制約として本対処を採用する。

改めて考察してみると
他のコントロールコードも音源の初期値が明確でないことから、
初回のコマンドはカットしないようにしているため、
今回の仕様で、より全体の整合が図られたとも言える。

障害報告(2012.11.18)†

例えば以下のデータで

#A0| d4r @Y0 mf
#A1| @Y1 _1

フィンガー #A0 の Y0 が発行されないのは仕様でしょうか？

(V6.26)MARK文字列がテキストエリアに表示されない場合がある†

対応状況(2012.11.24)†

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

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

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

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

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

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

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

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

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

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

過去のバージョンをVS2005でビルドし直し、WinXPで再現テストを実施した。
V5.70のバージョン以前は、テキスト文字列の記憶域を１バイト多く取り、
それを文字列区分(TEXT/MARK/STOP)のフラグとして利用していたため、
再現データのパラメータの方を１文字減らしてみた。 これにより、同様の症状が出ることを確認した。

こうしてバージョンを遡っていくと、
結果としてソースコードが現存しているV3.1においても症状が出ることが確認できた。
更に、プログラムからあらゆるダイアログ、発音機構などを除去した状態でも再現する。
このことから、極めて基本的な部分に真因があることが予想される。

障害報告(2012.11.11)†

●(2012/11/11) 21:33　＜himajin925さん＞

Ver6.26 にアップしました。
いろいろやってみたんですが、
（１）譜面モニタをメインウィンドと同じ幅、４／４表示にして、
（２）小節線１１０〜１１３がモニタの左端に来るようにして
（３）小節線の左で右クリック
→２．戦いの…が鍵盤上部に表示されない
ようです。
画像を上げておきました。

画像を見てもらえたようですので、この現象がおきることがある、
のは分かっていただいたと思います（指揮棒カーソルは２．を過ぎているが、鍵盤の上は１．のまま）
私のところでも、同じ条件で毎回起きるわけでもないようで、？？です。
ただ、画像の場所で右クリック、２．戦いの…が表示されたら、また右クリック、
と数回やっていると高い確率で発生するようになる、らしいのですが、
初回でも起きる場合があるし、何回も起きない場合があるし、ってまったく？？です。
まったく困ってはいないのですが(^.^)

もっと前から（先頭からも？）演奏した場合も同様の場合があるようですが、
再現しない場合もあって、やはりよく分かりません。
（２）の場所が条件なのかもまったく？です（たぶん条件ではないのでしょう）

●(2012/11/11) 22:55　＜開発者＞

再現のためのレシピを忠実に何度も試したのですが、やはり私の環境では再現しませんでした。
少々厄介なことになってしまいました(苦笑)。

こういった場合考えられるのは、
　　(1)Museの根深く基本的なバグ
　　(2)メモリやリソースなどの環境の問題
のどちらかだと思いますが、
私の経験では９０％は(1)の方です。orz

ただ、再現しないことには障害追跡ができません。
本当は、こういった時こそ「純正培養データ」が欲しいのですが、

●(2012/11/12) 23:18　＜himajin925さん＞

やはり再現しませんか？
もうちょっと単純に（4/4表示で）小節線116のちょっと左で右クリックすると、
正常では、一瞬「１．ソロモンの…」が表示され、「２．戦いの…」が上書きされ、
第２曲が開始、となりますが、何回か続けてみると
（多分３回目）、「１．ソロモンの…」の表示のまま演奏が始まる、
って言う現象が、やはりおきます。

私の環境のせい？

抽出データでの再現はうまくいってません。
マクロ、第１曲の最後、第２曲〜という mus ファイルを作って Museを再起動し、
演奏してみると、正常に、「２．戦いの…」が表示されます。（何度右クリックしても）
ただし、一旦元データで「１.ソロモンの…」のまま演奏される現象が発生したあと、
Museを再起動せずにこの抽出データを再生してみると………やはり「１.ソロモンの…」のまま演奏が始まったりします。

●(2012/11/12) 23:55　＜開発者＞

問題の「２．戦いの…」のMARKを、TEXTおよびSTOPに書き換えて、
それでも症状が出るかを試してもらえますか？

●(2012/11/13) 00:05　＜himajin925さん＞

TEXT → 同様です（いや、正常ケースがなくなるかな。
116の右で右クリックすると 赤字で「２．戦いの…」が確かに表示されるけど、
左で右クリックでは、いつも「１．…」のまま？）
STOP → 演奏を再開すると、「１．ソロモン…」のまま、で同様です
いずれもマクロ $1{ の中を書き換えました

●(2012/11/13) 00:34　＜開発者＞

もう一つ、実験してもらうことを思いついたので、試してもらえますか？
本来「２．戦いの…」が表示されなければならないのに「１．…」のままになっている状態で、
Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
これでも「１．…」のままになっているか否かを試してみてください。

●(2012/11/13) 17:39　＜そなさん＞

XP SP3なので試してみました。
再現できましたorz

●(2012/11/13) 21:05　＜開発者＞

ご報告、ありがとうございます。
Museのバグである公算が高まってきたのは残念ですが、
再現する試験者が増えたのは心強い限りです。
お手数ですが、お手すきの時に以下の実験をして結果を教えてもらえますか？
＝＝＝＝＝
本来「２．戦いの…」が表示されなければならないのに「１．…」のままになっている状態で、
Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
これでも「１．…」のままになっているか否かを試してみてください。

●(2012/11/13) 21:18　＜himajin925さん＞

（１）「最小化→元に戻す」または「他のウィンドで隠す」いずれも、
　　　「演奏中」「演奏停止」どっちでも、「１．ソロモンの…」のままです。
（２）次いで、文字列そのものを疑っていろいろやってみました。
文字列の中身をまず疑ったのですが（全角スペース＋D など）どうも違うようで（４．饗宴の踊り…では発生しない）
そのスペースを半角に置き換えたりしてみているうちに、どうも「３０バイトの文字列が指定された場合に発生する
のではないか」という推測に達しました。

*MARK"１２３４５６７８９10百千万億兆"
*MARK"012345678901234567890123456789"
*MARK" 2.戦いの踊り　Danza guerresca"

↑全角・半角の違いが分かりにくいですが…いずれも３０バイトのはずです
この３ついずれでも発生します。また「４．饗宴の踊り…」でも半角文字を１つ削除すると、
やはり発生します（３０バイトになります）。
３０バイト以下と超える場合で処理が分かれる、など何かありますか？

●(2012/11/14) 09:08　＜そなさん＞

> 本来「２．戦いの…」が表示されなければならないのに「１．…」のままになっている状態で、
> Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
> 次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
> これでも「１．…」のままになっているか否かを試してみてください。

やってみました。
再生中 停止中 ともに「１．…」のままでした。
起動直後の演奏では正常に切り替わることが多い気がします。

ついでに 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に書き換えて 
> 本来「２．戦いの…」が表示されなければならないのに「１．…」のままになっている状態で、
> Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
> 次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。

すると 色のみ赤に変化

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

●(2012/11/14) 12:54　＜木下さん＞
  
再現性は１００％ではないですが，症状が出ていますので報告します。

ＯＳ：Windows2000 SP4

マークの文字列が更新されない条件
・「シバの女王ベルキス」MARK"2. "とMARK"4. "
・譜面モニタでマークの前の位置でリロードする
・マークの文字列は丁度３０文字（全角文字は２と数える）

状況
・１度更新されないと，その後の更新されない確立がかなり上昇する
・シーク開始位置で確立が変化する
・譜面モニタ１１４の２拍目の確立が高い
・確立が１００％や０％の場所は無い
・↑でのリロード＆演奏でも再現

関係が不明
・文法エラー表示

自分のデータで上記の条件で再現しないか調査中ですが未だに再現していません。
いま少し調べてみます。

> 本来「２．戦いの…」が表示されなければならないのに「１．…」のままになっている状態で、
> Museのメインウィンドウの右上にあるウィンドウの最小化ボタンを押下する。
> 次に、タスクバーのMuseをクリックして再びMuseウィンドウを表示させる。
 
表示は更新されないままでした。 

●(2012/11/14) 15:46　＜Elekenさん＞

少し気になったので、私の環境 (Windows XP SP3) でも調べてみました。
気付いた点は以下の３点です。

(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の（対処）の項に記載したのと同じ結果に行き着きました。

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

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

＞ ＯＳ依存の現象のようで、大変そうです(^_^;)が、お待ちしてます
現時点の対処方法(１バイト余分にメモリ確保)は、今一つ釈然としないのですが、
一応今まで追跡した内容からして、
限りになく患部に近い所に薬を塗れているのではないか、
と思い始めてきました。

●(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
・文字列は正常な３０文字
が確認されました。
つまりデータは壊れていない、ということを裏付けていると思います。

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 にバグはなかった！」で良いでしょうね。よかったよかった
 
（１）純粋培養 Muse の様子を見ていて、症状の起きない 95-Me の互換モードでは、XP でのメモリ管理と違う
　　　（ヘッダを見ると、95-Me はバイト単位での割り付けかと想像される→別の API で割り付けてる？）ので問題がおきない？
（２）XP 以降では 8バイト単位の割り付けになるが、開放されたブロックの再利用の仕方
　　　（同じ大きさの開放領域があればそれを使うが、その探し方）が　Vista 以降で変更になったそうで、
　　　そのせいで XP でだけ発生するのでしょうか。ただ、そうだとすると同様の条件になるケースはありそうだと感じます。
　　　XP で顕在化しただけで、Win7 でも…いや何らかの修正がされているのかな？
（３）ちょうど 40 バイト空いていた場合だけではなくて、
　　　ちょうど 16バイト空きで 8バイトの文字列…
　　　ちょうど 24バイト空きで 16バイトの文字列…
　　　…
なんていうことが、データによってはありそうですが…そのうち見つかる可能性もあるのかな
 
で、やはり +1 とするのですか？

●(2012/11/25) 11:09　＜開発者＞

＊Elekenさん
＞ なぜ「32」byte かは、もし仮にマクロ展開時に作る構造体が 25-32 byte なら
＞ 説明がつきそうですが・・・。
Elekenさんって、まるでシャーロックホームズみたいですね！

私が掲示板(2012/11/24) 11:09 で書き込んだ、
＞ また、機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。
を具体的にお示しします。何か考察のヒントになるかもしれません。

既に純正培養Museでは３つの構造体しか使用しておらず、
利用しないメンバーもどんどん剥ぎ取っていますので、
以下の様な簡素な内容になっています。

// ノート構造体 --------------------------------
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では使用していません。
そこでこれらの★付きメンバーも剥ぎ取ろうとしたのですが、１つでも取り払うと症状が出なくなってしまいました。

＊himajin925さん
＞ しつこいなぁと思われたでしょうが(^_^;)
いえいえ、むしろ“真実を追究する”真摯な姿に感動さえしています。
少々大袈裟かもしれませんが、
この姿勢は、科学者や検事や医師などの職業を問わず、
人のあらゆる活動で尊重されるべきものだと思います。

＞ で、やはり +1 とするのですか？
はい。可変長文字列のmalloc()だけ１バイト余分に確保するようにしようと思います。
ほとんどは、コンパイル時の一時的な確保ですから、永続的にメモリ効率を落とす訳ではないし、
演奏時にも確保し続けるのは、テキストの表示文字列と譜面モニタの属性表示文字列、
履歴データのパス、楽譜出力用のタイトル群とスルーコマンド位です。
そもそもたった１バイトですので、大勢に影響は無いでしょう。

※その対応箇所のコメント文には、今回の趣旨が分かるように書いておこうと思います。
　さもないと１０年後の自分が見直した時、無駄なメモリを確保している！
　と、戻してしまいそうです(笑)。

＞ これで、「Muse にバグはなかった！」で良いでしょうね。よかったよかった
とても安堵しています。＼(^o^)／
でもこの“戦いの踊り”が終わり、お二人とエキサイティングなやりとりもできなくなると思うと、
ちょっち淋しい感じもしたりして(苦笑)。

記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。

●(2012/11/25) 02:23　＜Elekenさん＞
  
> 機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。
 
メモリをみたところ、「末尾 40 byte 領域」を持つヒープ断片は
<24 バイト, <16 バイト, <8 バイトのデータが規則正しく埋まっているようです。
ご提示頂いた構造体と照らし合わせると、前２者は t_macr, t_work であるようです。
（ malloc ではサイズが 8 バイト単位に切り上げられます）
このへんの絶妙なバランスが、「末尾 40 byte 領域」を導いていたと推測しています。
 
しかし、すみません、折角ご提示頂いたのですが、これ以上の探求は
ライブラリの malloc, free の解析を伴うので難しいです。
これでゲームクリアとさせていただきます（笑）。
 
himajin925 さんの仰るような未確認バグデータに対応する意味も含めて、
+1 バイト余計に確保することはスマートな解決策だと思います。
malloc １回で 8〜15 バイトの無駄ですから、1 バイトのオーバヘッドは誤差のようなものだと思います。
 
> 記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。
このソフトウェアが "muse.exe" を名乗っているのを見ると、Muse のアイデンティティってなんだろうと暫し考えてしまいます。
テキスト領域と鍵盤ひとつあれば Muse なのかな？
 
ともあれ、Muse は思っていた以上によく考えられて設計されているのだと、
ただただ感服するばかりです。
今回は難しいパズルを見つけた気がして、少し書き込みすぎてしまいました。
一番楽しんでいたのは私だったかも知れません。

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

対応状況(2012.10.25)†

V6.26にて対応済み。

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

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

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

障害報告(2012.10.24)†

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

(V6.24)楽譜スルーを指定するとセミコロンのコメントで文法エラーになる場合がある†

対応状況(2012.09.23)†

V6.25にて対応済み。

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

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

障害報告(2012.09.23)†

Muse V6.24 において、

${macro} "r4" d4 ;
$macro{}

が、「d4; が記述ミス」というエラーを発生させます。 ちなみに、行末のセミコロンを削除した

${macro} "r4" d4 
$macro{}

は正常に動作します。

(V6.23)移調楽器yでパラメータ省略すると、PDF出力楽譜の音程が狂う†

対応状況(2012.09.13)†

V6.24にて対応済み。

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

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

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

障害報告(2012.09.13)†

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

(V6.22)同時刻内のＯＮ／ＯＦＦノート整列処理がうまく効かない場合がある†

対応状況(2012.09.02)†

V6.23にて対応済み。

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

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

障害報告(2012.08.31)†

V5.5より同時刻内のＯＦＦノートを前方に、ＯＮノートを後方に整列させる処理を組み込んでいるが、
その処理が(非常にレアケースではあるが)、機能しない場合があった。

(V6.21)Windowsの古いOS(Win95/98/Me)で起動しない†

対応状況(2012.09.01)†

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の導入を促す警告ダイアログが出現し、起動はできなかった。
そこで、１世代古いビルド環境であるVS2005を採用することにした。
Win95は対応できないが、Win98以降のOSであれば起動可能となった。

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

障害報告(2012.08.21)†

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

(V6.20)未定義の起動パラメータ文字を指定するとシステムエラーのダイアログが出現する†

対応状況(2012.08.19)†

V6.21にて対処済み。

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

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

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

障害報告(2012.08.19)†

(その１)

従来のショートカットのままMuseを起動したところ、エラーが出るようになりました。
v6.1までは発生しないエラーです。
---------------------------
〈Muse〉システム状況
---------------------------
ファイルがオープンできません
\\hoge\muse\-$
---------------------------

(その２)

不正なコマンドライン文字列を与えると、長時間ハングした後にエラーを返す。
数十秒ハングした後、意味不明なエラーを返すので、是非改善すべきかと思います。

(V6.20)初期化ファイル(muse.ini)に指定したテキスト背景色が正しく反映しない†

対応状況(2012.08.19)†

V6.21にて対処済み。

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

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

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

障害報告(2012.08.19)†

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

(V6.02)途中再生で演奏を開始すると各種コントロール指定が無効になってしまう†

対応状況(2011.11.26)†

V6.03にて対処済み。

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

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

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

障害報告(2011.11.18)†

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

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

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

対応状況(2011.10.17)†

V6.02にて対処済み。

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

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

障害報告(2011.10.08)†

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

動画を撮りました。

(V6.00)マクロでＸ遅延を利用すると２回目以降の再現で遅延が効かない†

対応状況(2011.07.10)†

V6.01にて対処済み。

(原因)
Museコンパイルモジュールにて、遅延のコロンを一時的にNULLに置き換えて文法解析しているが、
その復帰をエラー時のみに実施していたため、正常系でコロンがNULLのままになっていた。
マクロを使用しない場合は支障は実用上の無いが、マクロ利用の場合はその文字列空間を再利用しているため、
２回目以降はコロンが無くなったままになり、遅延指定が成されていないという解釈ミスが生じた。

(対処)
必要な解析が完了した時点で、文法エラー検出以前に直ぐにコロンを復帰するよう改修した。

障害報告(2011.07.10)†

以下のデータでおかしな演奏になります。

#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)ドラムメンバーに移調楽器コマンドを指定するとエラーとなってしまう†

対応状況(2011.07.05)†

V6.00にて対処済み。

(原因)
移調楽器コマンド'y'は、それがドラムメンバーに指定された場合、
「エラーとはならないが、その指定は無視される」という仕様であるにもかかわらず
エラー判定を実施していた。

(対処)
エラー判定を外した。

障害報告(2011.07.02)†

転調を頻繁に行うデータを作っているのですが、困ったことが…
ドラムにまで判定を出してしまっているようです。

#Z0@ P17
*FING "y"
#Z1 o2rrrr

でエラーになります。ちなみに、

@Z P17
*FING "y"
#Z1 o2rrrr

では、Zフィンガーがまだ登場していないのでエラーになりませんが、

@Z P17
#Z1 o2rrrr
*FING "y"

はダメでした。

(V5.92)演奏状態でシークした際、曲が残っているのに演奏を停止してしまう場合がある†

対応状況(2011.07.05)†

V6.00にて対処済み。

(原因)
左右矢印キーやシークボタンなどでスライドバーを移動させた際、
つまみがシークバーの右端座標に達したかどうかを曲尾到達の判定に利用していた。
そのため、MARK文前半に対して後半の演奏時間が極端に短い場合、
後半の演奏が残されているにもかかわらず曲尾に到達したと判断された。
これは、MARK文前後の演奏時間の差があまりに大きいため、
後半のシークバーのドット数幅が１以下（実質ゼロ）になってしまうためである。

(対処)
曲尾到達の判定にシークバーの位置を利用することを止め、
内部的に処理している演奏時間を参考に判断することにした。

障害報告(2011.06.26)†

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(ポルタメント)指定が反映されない†

対応状況(2011.05.12)†

V5.92にて対処済み。

(原因)
V5.34からV5.35へのマイナーバージョンアップにてシーク高速化処理を施した。
その一環としてシーク時に出力しても意味のないコントロールを音源に送信しない処理を組み込んだが、
その対象にポルタメントおよびポルタメントコントローラを挙げてしまった。

(対処)
シークの際に必要最低限のポルタメント関係のコントロールを送信するよう変更した。

障害報告(2011.05.09)†

X65（ポルタメント）についてです。 ポルタメントは、"X65=127" のように指定しますが、他のX指定と異なり、
この指定は途中再生に上手く対応していないように思います。
演奏中に"X65=127" の位置を通るとポルタメント状態になりますが、
その位置より後から途中再生すると、ポルタメント指定が行われていないかのような 状態で演奏されてしまいます。
これについて、S-YXG50 と MU1000 の音源で確認しましたが、
VSCのような他の音源で同じ現象が再現されるかどうかは確認していません。
（ポルタメントは音源によって扱いが異なる場合があるようです）
Windows XP 上で確認しました。

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

対応状況(2011.05.12)†

V5.92にて対処済み。

(原因)
V5.23からV5.24へのマイナーバージョンアップにてシーク高速化処理を施した。
その開発途上でシークポイントまでテキスト表示が存在しない場合に
フォント切り替えを実施する処理を組み込んだが、結果的にそれが不要になるシーケンスに落ち着いた。
しかるに、開発途上でのフォント切り替え処置の削除をし忘れていた。

(対処)
フォント切り替え処置の削除を行った。

障害報告(2011.05.09)†

HEADタグのフォントの件です。
通常HEADタグは、それ以前に書かれたFONTタグで指定されたフォントで描画されると思います。
ところが、HEADタグの後にFONTタグがある場合、再生位置がそのFONTタグの位置の後にある状態で
Muse のウィンドウを他のウィンドウで隠し、再び Muse のウィンドウを表示させると、
HEADタグより後で指定したフォントで再描画されてしまいます。
Windows XP 上で確認しました。

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

対応状況(2011.05.06)†

V5.91にて対処済み。

(原因)
V5.90にて、文字列描画による演奏のモタレを軽減するため、
同時刻内のノートONの後にテキスト表示イベントを移動する処理を施したが、
テキスト表示イベントの一種であるMARKコマンドの場合、
ノートONが発行された後にその位置で停止する状況に陥り、
MARKから演奏を開始すると出だしの音が発音されたくなった。

(対処)
MARKコマンドは並べ替えの処理を行わず、
モタレ軽減の処理は、TEXTコマンドのみを対象とする様、修正した。
STOPコマンドに関してはV5.90においても本考慮が成されていたため、
MARKもSTOPと同等の処理とした。 具体的には、MARKやSTOPを検出した際は、
同時刻であっても異時刻に変化した場合と同じ扱いとした。

障害報告(2011.04.29)†

早々で申し訳ありませんがマーキング(*MARK)にジャンプさせたときに
MARK直後の発音が飛ばされるようなのですが...。
分かりやすいのは、開発者様の「交響曲第７番（ベートーベン）」を読込んで
第２楽章にスライダーを右にジャンプさせると第２楽章最初の和音がとんでしまいます。

(V5.90)メニュー「データ編集」が正しく機能しない†

対応状況(2011.05.06)†

V5.91にて対処済み。

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

(対処)
正しい手順に修正した。

障害報告(2011.04.27)†

museのver5.9ダウンロードさせていたたぎました
しかし、データ編集を押すとテキストドキュメント(メモ帳)ではなく、
それが入ってるフォルダ(?)が出てきます
前まではちゃんとメモ帳だったと思うのですが、、、

(V5.87)ＰＣ起動初回で演奏のモタレが生じる場合がある†

対応状況(2011.03.05)†

V5.88にて対処済み。

(原因)
バックグランドで処理が走っている場合などの環境下でMuseが初出現のフォントをロードする際
その処理に時間が掛かるため、演奏がモタレてしまう場合がある。

(対処)
Museデータのロード直後に、そのデータに使用されているフォント使って１回ダミー描画し、
演奏開始時点で初回のフォント読込みを終えている状態とした。

障害報告(2010.11.02)†

私が Musing したデータを Muse で再生すると、曲頭の数音が時間的に詰まって鳴る場合があります。
パソコン起動後初回に起動した Muse で初回再生の場合には必ずそうなります。

実行環境として、

・rsync
・cp （cygwin のコピーコマンド）
・Windows のバックアップコマンド

にて、以下のデータを演奏させると、

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

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

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

対応状況(2011.02.04)†

V5.87にて対処済み。

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

(対処)
エクスクルーシブ・メッセージを音源に送信した後、 バッファのデータヘッダー要素である状態フラグの監視ループに入り、 その値が完了になった時点でループを抜け出すというシーケンスに改めた。 一種のポーリングではあるが、この方式はコールバックに依存しないため 確実なバッファの解除が実施できると判断した。 また、MIDI音源オープン時にコールバックの定義をする必要が無くなり、 イベントに関する処理負荷も低減させることができたと推測している。

※なお、本件とは直接関わりは無いが、V5.87のバージョンアップにおいて、 Readme.txtの改訂も実施した。 具体的には、利用頻度の高いものを極力早めに解説するという方針の基に “第２章　Ｍｕｓｅコーディングの手引き”における節立てを組み直した。

障害報告(2011.02.01)†

(1)Timidity++をインストールし、Museのメニューの「音源(V)」に Timidity++ Driverが追加された状態にしておく。

(2)Museで“Timidity++ Driver”を音源として選択し、任意データを数秒演奏させる。

(3)音源メニューから“Microsoft MIDIマッパー”に切り替える。

(4)この状態で再び演奏を開始しようとすると、Museがフリーズ状態になった後、 しばらくして落ちる。

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

対応状況(2011.01.26)†

V5.86にて対処済み。

(原因)
前回の不具合対応時に、マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施したが、
その際、マクロ再帰処理に入る前のエラー制御変数の初期化が漏れていた。
そのため、一番初めに検出したマクロ（エラーがあろうと無かろうと）をエラーの候補として扱ってしまい
実際にどこか別の場所にエラーがある際に、そこもエラー表示してしまうという不具合を起こしていた。

(対処)
エラー制御変数の初期化を確実に実施するよう改善した。

障害報告(2011.01.21)†

定義マクロ、$Syn2_0{・・・}を記述せず、Ｘ行目にその展開マクロ${Syn2_0}を記述すると、
Museはマクロが未定義であるという文法エラーを検出するはずです。
しかし、このエラーとは直接関係のない以下のエラー表示が出現してしまいます。

(MUSE)文法エラー
　　対応する定義マクロがありません。
　　Ｙ行目 → $MC-G1_01

この際、Ｙ行目に関わるマクロには文法的なエラーは存在しません。
そして［ＯＫ］を押下して上記のエラー表示を閉じると、この段階ではじめて以下の正当なエラー表示が出ます。

(MUSE)文法エラー
　　対応する定義マクロがありません。
　　Ｘ行目 → ${Syn2_0}

つまり、Ｘ行目にエラーがあると何故かＹ行目がエラーとして検出されてしまいます。
Ｘ行目のエラーを解決すると、Ｙ行目のエラー表示も出なくなります。

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

対応状況(2011.01.19)†

V5.85にて対処済み。

(原因)
従前の処理シーケンスは、データに一度だけ記述するタイプのコマンド重複チェックを、
マクロ展開処理よりも前に実施しており、しかも無名マクロの展開部ではそのコマンドの
展開を実施していなかった。しかし当初の仕様では、マクロの繰返し数にゼロ指定が
出来無かったため、定義部は必ず実行されるという前提を置くことができるため
演奏データとしては矛盾無く翻訳できた。
更にこの仕様で無名マクロを利用した場合、重複チェックに掛からない状況であったが、
定義部と展開部が必ず同一の指定となるため、２つの指定が競合することはなく、
事実上の問題は無いと判断していた。

しかるにゼロ指定を可能としたV5.3以降、定義部でも展開部でもコマンド認識をしない状況が生じ、
今回の症状が出現するに至った。

(対処)
マクロ展開を処理しながらコマンド重複チェックも並行するシーケンスに変更する事で、
マクロ内に記述されたコマンドを正しく展開解析し、重複チェックも厳密に行うようにした。
なおドラムに関しては、移調(T)および音部記号(?)を無効化する仕様を実現するため、
マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施した。

障害報告(2011.01.02)†

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)譜面モニタの右クリック・リロードで、指揮棒カーソルが２つ出現してしまう場合がある†

対応状況(2010.12.23)†

V5.84にて対処済み。

(原因)
譜面モニタがアクティブ状態で右クリックする場合と、非アクティブの状態で右クリックする場合とで
リライトのイベントと演奏開始イベントの順序が異なり、後者を先に受信した場合に
排他的論理和で描画している指揮棒カーソルの表示が乱れていた。

(対処)
右クリック・リロードの際、演奏開始直前で強制的に最描画のアップデートコマンドを送信することで、
イベントの順序関係を調整し、表示が乱れないように対処した。

障害報告(2010.12.20)†

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

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

対応状況(2010.11.8)†

V5.83にて対処済み。

(原因)
未使用メンバーの制御コードをクリアする際、属性値の文字列を解放していなかったため、クリアルーチンの条件から漏れて、そのままデータが残っていた。 MIDIコードの内容としてはゼロであったためＡメンバーのＩＤと一致し、Ａメンバーの属性と解釈されて譜面モニタ上に表示してしまった。

(対処)
未使用メンバーを検出した際、属性値の文字列も解放するように修正した。

障害報告(2010.11.6)†

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

@B V60
#A0 d r m

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

対応状況(2010.5.29)†

V5.82にて対処済み。

(原因)
新たにデータをロードする際、HEADコマンドの文字列内容を記憶した領域の１文字目をNULL化することでクリアしているが、
MIDIエクスポートにおいては、その２文字目から有意な文字として活用しているためクリアされたことが認識できていなかった。

(対処)
MIDIエクスポートの際、１文字目でHEADコマンドの有無を検出するよう改修した。
また従来のバージョンでは、HEADコマンドが存在していなくても、シーケンス・トラック・ネームを出力していたが
今回の改修に伴い、HEADコマンドが無い場合は、そのレコードの出力そのものを行わないように改善した。

障害報告(2010.5.29)†

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

(V5.70)ショートカットでメニュー選択するとメンバーがＯＦＦになってしまう場合がある†

対応状況(2010.4.13)†

V5.71にて対処済み。

(原因)
メンバー情報ウィンドウにて、コントロールを併用したショートカットキーでモーダル系ウィンドウを使用するメニューを選択した場合、
そのウィンドウを閉じた時点で、メンバー情報ウィンドウにショートカットキーのアルファベット文字が送信されてしまう。
しかも、その時点の送信メッセージではコントロールキーの併用を検出する事ができないため、
Museアプリケーションは、メンバー情報ウィンドウ自体のキーボードによるメンバーＯＮ／ＯＦＦとして反応してしまっていた。
なおこの障害は、メンバー情報からのメニューショートカット選択をサポートしたV5.30より存在し続けていた。

(対処)
メンバー情報がキーボードからの文字列を受けた際、その時点のアクティブなウィンドウを検知し、
それがメンバー情報ウィンドウ自身で無い場合は、メンバーＯＮ／ＯＦＦ機構を発動しないようにした。

※なお、V5.70において、スペースバーやバックスペースなどのキーボード操作における障害も見つかっており、
V5.71によってそれらにも対処した。

障害報告(2010.4.13)†

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

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

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

対応状況(2010.3.11)†

V5.62にて対処済み。

(原因)
微分音長で指定した音長がテンポの関係と相まって極度に短くなり、
MIDIのティック値が内部処理上ゼロとなると、出音と止音が同時刻に出力されてしまう。
この状況下において、V5.50で施した同時刻内でのノートオフとノートオンの
順序入れ替え処理により、出音と止音の順序が反転してしまうため。

(対処)
１つの音符により発生した出音と止音が同時刻に存在していた場合、
その状況下で生成されたノートオンとノートオフは、
論理的には異なる時刻に存在すると解釈することで、
順序入れ替えの処理を行わなず、次の処理ステップに移行するように修正。

障害報告(2010.3.9)†

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

*STOP"１−Ａ（テンポ：120）" %
#A1 _1 di7 _1 ri6 _1 mi5 _1 fi4 _1 si3 _1 li2 _1 ci1 _1~i28

*STOP"１−Ｂ（テンポ：120）" %
#A1 _1 di7 _1~i7 ri6 _1~i6 mi5 _1~i5 fi4 _1~i4 si3 _1~i3 li2 _1~i2 ci1 _1~i1

!ｉの長さに関連性を見つけられませんでしたので、端数的な影響を疑ったのがＢですが、
　そうすると出現パターンが変わります。
　また、テンポが変わると不都合の出現パターンも変わります。（２−Ａ、Ｂ）!

*STOP"２−Ａ（テンポ：133）"  %%133
#A1 _1 di7 _1 ri6 _1 mi5 _1 fi4 _1 si3 _1 li2 _1 ci1 _1~i28

*STOP"２−Ｂ（テンポ：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)楽器の指定が反映されない場合がある†

対応状況(2010.2.9)†

V5.52により対応済み

(原因)
V5.50で施した同時刻内でのノートオフおよびノートオンの順序入れ替え処理において、 曲頭での特殊処理にミスがあったため、冒頭部分のコントロールが演奏リストから 離脱されたままになっていた。
(対処)
曲頭部分の処理を正常化した。

障害報告(2010.2.8)†

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

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

(V5.50)途中から再生(シーク)させると正しく演奏されない場合がある†

対応状況(2010.2.7)†

V5.51により対応済み

(原因)
シークの高速化(演奏開始までの待ち時間短縮)のために、最終的に無効となるコントロールコードを音源に送出しない処理を施しているが、コントロール間で順序関係のあるものに関しては本処理に掛けない様にしている。モノオンとポリオンはそのコントロールに該当するが、プログラム上、高速化処理に該当するコントロールとして扱っていた。
(対処)
モノオンとポリオンに関しても高速化処理から外す様、プログラムの修正を行った。

障害報告(2010.2.7)†

打ち込みをやっていたところ、奇妙な現象に遭遇しました。
X126(モノ オン)で同時発音数を1にしていたのをX127(ポリ オン)で戻した時です。
普通に鳴らすと普通に鳴るのですが、途中から鳴らすと…
VSCとTimidityで発生、MSGSではドラムでなく普通の楽器でダンパー付ければ発生。
Wingroove、S-YXG50、SC-8850はそもそもポリ オンにならなかったので発生も何もなし。

#Z0@ X126=127_4%
#Z1 {o3 d+4o2r}4
%*MARK "その１"

#Z0@ X127=1_4%
#Z1 {o3 d+4o2r}4
%*MARK "その２"

#Z0@ _4%
#Z1 {o3 d+4o2r}4
%

その2から演奏させると、ポリ オンが効かず、シンバルが切れます。
ただし普通に鳴らすと問題なく演奏しています。

途中からの演奏で情報を切り詰める際、最後から見ているような感じですね。
コントロール番号が違うから、別物として見ているような…

(V5.47)中身の無いマクロを記述するとハングする場合がある†

対応状況(2010.1.9)†

V5.50により対応済み

(原因)マクロの解析処理において、展開作業終了後作業用メモリの解放を行っているが、中身の無いマクロに関してメモリ開始アドレスと終了アドレスの位置関係が逆転しており、解放時に管理外のメモリにアクセスする状態になっていた。
ハング症状が出たり出なかったりする事象は、管理外のメモリ内容がＰＣの使用環境により偶然NULLであったり有意であったりすることで起こったものと推測される。

(対処)マクロの開始終了アドレスをセットする処理部分で中身の無いマクロ状態を認識し、適切な判断材料を記憶する事で上記事態を回避する制御に改めた。

障害報告(2010.1.4)†

以下の様な記述をするとMuseがハングする

${macro2}

$macro2{ _d }0
$macro1{ }0

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

(V5.46)演奏会場の設定における残響設定Delayの値が、Muse再起動でクリアされる†

対応状況(2009.8.14)†

V5.47として対処版をリリース

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

障害報告(2009.8.14)†

少し前から気になっていたコトをひとつ……。
演奏会場の設定画面についてなのですが。

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

(V5.45)和音内連符において連符以降の音にアルペジオ指定が効かない†

対応状況(2009.8.10)†

V5.46として対処版をリリース

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

障害報告(2009.8.10)†

和音内に連符を記述した場合、連符以降の音にアルペジオ指定が効かない。

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

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

(V5.44)ドラムセットの持ち替えが効かない場合がある†

対応状況(2009.02.15)†

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)†

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

(第二報告) ドラムセット（17）だけでなく（25）も持ち替え出来ない症状が出ました。 私の場合、回避策としては例えば（17）から（2）に持ち替える時に 一度＠Ｐ1を挿入することでリセットされ（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


;メンバＯの表示＠Ｐ2→Ｐ17→Ｐ2 →Ｐ25→Ｐ17
;　　　　　演奏　Ｐ2→Ｐ17→Ｐ17→Ｐ25→Ｐ17と聞こえます
;メンバＺの表示＠Ｐ2→Ｐ17→Ｐ2 →Ｐ25→Ｐ2
;　　　　　演奏　Ｐ2→Ｐ17→Ｐ17→Ｐ25→Ｐ25と聞こえます

(V5.43)アルバムに１曲も存在しないのにセパレータが表示される場合がある†

対応状況(2008.10.28)†

V5.44としてリリース

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

障害報告(2008.10.28)†

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

(V5.42)大量の音符が重なった部分で行番号検索を実施すると落ちる†

対応状況(2008.07.28)†

V5.43としてリリース

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

障害報告(2008.07.19)†

添付ファイルのデータで今回の目玉機能の音符クリックを行うと （自宅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)楽器の試聴における方向キーの動作不正†

対応状況(2008.07.17)†

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

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

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

障害報告(2008.07.17)†

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

(V5.40)極端に長い演奏を記述すると動作が不正となる†

対応状況(2008.07.17)†

V5.41にてリリース済み。

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

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

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

障害報告(2008.07.13)†

{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と音部記号？を組み合わせると調性が狂う場合がある†

対応状況(2008.07.11)†

V5.40にてリリース済み。

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

(対処)以下の処理仕様に改修した。

ドイツ音名の場合、音名“b”は調性を無視する。
また、音名“h”はフラット系の調性を無視する。

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

障害報告(2008.06.27)†

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

いま入力に挑戦中の曲に♭６つの調が出てきて、ビオラのパートの音が変で、分からなくなってしまいました
以下の例を演奏してみてください

\------;変ト長調の場合
 
;ト音記号
#A0 x2 ?0 o3 g4 a b < c d e f g _2 ;b でＯＫ
 
;ヘ音記号
#A0 x2 ?6 o5 e4 f g a b < c d e _2 ;b でＯＫ

;アルト記号
#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 ;ＯＫ→h- と記述しなければならない？

;テノール記号
#A0 ?4 x2 o4 a4 b < c d e f g a _2 ;これは ｂ でＯＫ

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

(V5.36)ハード音源(MU90B)にて、演奏会場の設定があると再生ができない†

対応状況(2008.06.14)†

V5.37にて対応済み。

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

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

MuseのROOMコマンドは、Reverb Send Level To Chorus(36h) を対象としていないが、
上述の１つのエクスクルーシブ送信を実現するために、(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)†

＜第一報告＞
このたび「 YAMAHA MU90B 」を購入しまして、自作の Muse データを演奏させてみたのですが、 曲によって演奏されるものとされないものとがありました(汗)
自分なりに調べたところ、「ある時期」を境に古いデータはちゃんと演奏され新しいものは演奏されないことに気づきました。 データ作成の日付と Muse Wiki にあった Muse の更新履歴を照らし合わせてみたら、 どうも「ROOM コマンド出現以降の Muse データ」が MU90B で演奏されないようなのです。
ただし、 過去データで XG リセットを入れた２曲だけは、演奏できることにも気づきました。
そこで、試しに 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　;コーラス

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

(V5.35)途中再生の際、波形加工が正しく反映されない†

対応状況(2008.05.18)†

V5.36で対処済み。

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

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

障害報告(2008.05.17)†

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

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

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

(V5.34)波形加工遅延の記述があるとシーク(途中再生)の開始が極度に遅くなる†

対応状況(2008.04.25)†

V5.35で対処済み。

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

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

障害報告(2008.04.09)†

{#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が記述エラーとなる†

対応状況(2008.03.07)†

V5.34で対処済み。

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

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

障害報告(2008.03.07)†

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

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

(V5.32)音量Vのマイナス方向への相対指定で最終値が負値になる†

対応状況(2008.02.23)†

V5.33で対処済み。

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

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

障害報告(2008.02.23)†

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

(V5.32)繰返し数ゼロの展開マクロ以降のデータがコンパイルされない†

対応状況(2008.02.21)†

V5.33で対処済み。

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

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

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

障害報告(2008.02.21)†

繰返し数ゼロの展開マクロを記述すると、それ以降に記述したデータがまったく演奏されない。

(V5.31)メンバー情報ダイアログの「M」の文字が欠けてしまう†

対応状況(2008.02.11)†

V5.32で対処済み。

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

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

障害報告(2008.02.11)†

ところでメンバー情報を開くと、メンバーＭの字で左側の縦棒が欠けて表示されますが、私だけでしょうか？

(V5.30)メンバー情報ダイアログをクローズし再び開くと楽器名が表示されない†

対応状況(2008.02.09)†

V5.31で対処済み。

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

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

障害報告(2008.02.09)†

演奏途中にメンバー情報ウィンドウを閉じて、再度開いたときに
メンバーの名前が消えてしまいます。

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

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

(V5.26)譜面モニタ末尾の右クリックでメンバ色一覧の楽器名が消える†

対応状況(2008.01.12)†

V5.27で対処済み。

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

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

障害報告(2008.01.08)†

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

(V5.25)履歴メニューの除去操作で追加されてしまう場合がある†

対応状況(2008.01.02)†

V5.26で対処済み。

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

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

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

障害報告(2007.12.28)†

【報告その１】
階層のある履歴について最下層の曲を右クリックで削除使用とすると、 その上の階層に現在開かれている曲を登録してしまう。 ３階層と４階層で確認しましたが同様でした。

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が折り返し表示されると思います。 このファイルが削除できません。

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

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

*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)音域限界の音程にて譜面モニタの表示が乱れる†

対応状況(2007.12.09)†

V5.25で対処済み。

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

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

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

障害報告(2007.12.09)†

「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)曲中からの再生時に指定したフォントが効かない場合がある†

対応状況(2007.11.25)†

V5.24で対処済み。

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

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

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

障害報告(2007.11.23)†

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

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

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

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

(V5.22)p指定で後音を前音より先に発音させると連結＆の結果が異常となる†

対応状況(2007.10.18)†

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

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

障害報告(2007.10.16)†

以下のデータを実施した際、異常な解析結果となる。

x2_2
[ceg]4p^2q~2&[ceg]8_

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

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

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

(V5.21)連結＆が他のフィンガーのｐｑに影響を受ける†

対応状況(2007.10.14)†

明かな再現性を確認。
V5.22で対処済み。

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

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

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

障害報告(2007.10.13)†

連結コマンド"&"の仕様が， 次のようなコードではうまく機能しません．

*FING"x1 q~64"
#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)リロード時のフォント変更反映不備†

対応状況(2007.10.12)†

明かな再現性を確認。 原因は、シーク時のちらつきを防止するために文字列内容の変更が無い場合に無駄な描画を抑止する処理に置いて、フォントが変更されていた場合は抑止しない考慮が欠落していたため。 V5.21にて修正済み。

障害報告(2007.10.12)†

FONTコマンドで別のフォントに変更したデータをリロードした際、リロード直後にそのフォントに反映されず、元のフォント状態を維持してしまう場合がある。

(V5.15)ステレオ指定のエラー検出の不具合†

対応状況(2007.09.19)†

本件に関して、バグであることを確認。
原因は、ステレオのプラス側の処理で条件分岐の不手際。
修正完了。

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

なお、現バージョン(V5.15)において、エクスポートもMuse演奏も
MIDIの数値制約内に強制的に納めており、演奏障害などは起きない。
文法エラー通知のみの不具合である。

障害報告(2007.09.19)†

#B1@ _2 S+664 [fl-]1
数値は99999999までいけました。それ以上は文法エラーになります。
なお、「-」の方は64以下で本来のエラー検出になります。

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

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

(V5.14)演奏終了時に異常終了†

対応状況(2007.08.04)†

Ver.5.15にて修正済み。

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

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

障害報告(2007.07.16)†

時間を置いて、異なる２名が不具合報告を開発者へ送付。 症状としては「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)履歴曲追加・除去時の不具合†

対応状況(2007.07.04)†

Ver.5.12にて修正済み

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

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

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

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

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

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

障害報告(2007.07.02)†

ver.5.11でも履歴曲、削除の時の右ボタンが効かない感じがします。
（階層は１階層のみ）(Me)
ちなみに右ボタンでの曲登録は出来るみたいですが...？
(USBマウスを使用しています)

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

(V5.10)履歴機能の不具合†

対応状況(2007.07.01)†

Ver.5.11にて修正済み

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

障害報告(2007.07.01)†

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

(V5.02)アルバムからの選択における履歴更新制御の不具合†

対応状況(2007.05.31)†

Ver.5.03にて修正済み

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

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

障害報告(2007.05.29)†

ただ気のせいだったらすいませんが、Muse.iniに追加されたLGS = 1 なんですが、説明通りの動作をしていないようなのが気になります。

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

期待する動作
０：「アルバムからの選択」で演奏した曲は履歴に記録されなくて、開くやＤ＆Ｄで演奏した曲は記録されます。
１：「アルバムからの選択」か否かに関わらず，演奏した曲は全て履歴に記録されます。

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

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

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

対応状況(2007.05.28)†

Ver.5.02にて修正済み

障害報告(2007.05.27)†

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

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

対応状況(2007.05.27)†

Ver.5.01にて修正済み

障害報告(2007.05.26)†

↑くさば環境(Windows2000)

↑浅川環境(Windows Me)

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

(V5.00)フィンガー拍数のプルダウンメニューから「V：音量」が消える†

対応状況(2007.05.27)†

Ver.5.01にて修正済み

障害報告(2007.05.26)†

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

(V5.00)Muse演奏終了時に音源がリセットされる†

対応状況(2007.05.27)†

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)†

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

(V5.00)S-YXG50を使用時にMuseが落ちることがある†

対応状況(2007.05.27)†

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

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

障害報告(2007.05.26)†

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

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

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

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