鍵盤付きシーケンサーであり、しかも接続開始時点でMIDIキーボードとしての送信メッセージ(f8)が強制的に発行される仕様であった。VSTi音源の場合はオープン時にMuse自身でWave制御のメモリを確保している。VSTi音源のオープンが完了する前に強制送信メッセージが起こる。MIDIメッセージの処理が実施され、メモリアクセス違反に陥った。ガードフラグを立てておき、初期オープンが完了した時点でフラグをクリアすることにした。従前から備えているものを活用し、フラグ新設による処理構造の複雑化を回避した。Muse起動すると数秒で確実にMuseが落ちました。他の鍵盤ソフト・シーケンスソフトでは問題なくソフト起動・鳴らすことに成功。Museでのみ、上の現象が起きました。Museが落ちることは無くなりました。確認ボタン[はい]/[いいえ]のどちらの押下であっても、繰り返し演奏が継続されるようになっている。[はい]押下によりアクセス不可のデータリンクが除去されれば、それを除いたアルバムから次曲を選択するため、繰り返し演奏は正常に継続する。そのデータを再生しようとして、閉じた確認ダイアログがまた表示されるというデッドロックに陥る。演奏を停止させることによりデッドロックを回避するシーケンスとした。本ダイアログの表示となり[はい]を押下するまでこの状況から脱出できなくなります。正常なインターフェースになっていないと考えられます。対応状況(2021.04.01)†V8.11にて対応済み(原因)データパス識別子「>」の文字検索結果を評価せず、そのまま処理を続行していたため、NULLアドレスに対して演算を行い異常終了となった。(対処)識別子「>」の検索結果を評価し、未検出の場合は当該行をキャンセルするシーケンスとした。Museが起動した瞬間に落ちてしまうようです。5856行目に従うなら、無視されると思うのですが。内部的な処理をした後、Windowsのデフォルト処理を実施せずそこで処理を打ち切るよう改変した。処理を打ち切っても直前の寸法および位置が正当なものであれば問題ないが、muse.ini自体が存在しない完全に初期状態からの起動の際は、ウィンドウ寸法や位置が正しく演算されない。このため、譜面モニタやドキュメント表示は面積ゼロのウィンドウとなってしまった。結果として譜面モニタはあたかも表示されていないかのように振る舞い、ドキュメント表示に至っては使用するフォントサイズがゼロとなり、内部演算でゼロ除算が発生してクラッシュした。この不具合はWin7でもWin10でも同様に発症する。(対処)ウィンドウの寸法および位置の変更イベントにおいて、以前のようにWindowsのデフォルト処理を実施するよう改めた。障害報告(2020.06.06)†muse8.04を先日ダウンロードさせていただきました。museを起動させたところ、以下の状態が見られました。漫画喫茶のpc(win10のように見えましたが未確認)です。museデータの演奏は出来ました。対応状況(2020.03.14)†V8.02にて対応済み(原因)メニュー表示文字列にタブを含めると挙動が不安定になるのは、Win32apiにおける仕様である模様。(対処)登録の際に、タブを半角スペースに変換しておくこととした。履歴リストの表示カラムを節約するため、連続スペースの集約処理も施すこととした。(タブ)と、両側にタブのある文字列をスイープすると、履歴リストに表示されません。対応状況(2020.03.01)†V8.01にて対応済み(原因)指定のエディタを起動するプロセスを発行する際、引数でReadme.txtのパスを与えているが、Museのインストールフォルダのパスに空白が含まれている場合、空白がデリミッタとなり、パスの一部がパラメータ引数と認識されてしまった。メモ帳などパラメータ引数を持たないエディタの場合は問題がないが、そうでない場合はReadme.txtをロードできない。(対処)指定エディタを起動する際、Readme.txtのパス全体をダブルクォートで括って渡すようにした。うまく機能していないようなんです。同じエディタへのパスを書いたのですが、本体の「マニュアル表示」を開くと空白のエディタ画面が立ち上がってしまいます。試しにパスをダブルクォーテーションで括ってもみましたが、こうすると指定エディタは立ち上がらず初期状態(メモ帳での画面)で開きます。対応状況(2019.06.09)†V7.88にて対応済み(原因)V7.10からの潜在バグ。新しい関数を立ち上げたが、その関数内でフィンガー情報に反映する変数へのセットをし忘れていた。(対処)正しくセットするようにした。本障害はダイアログへの表示のみに関わり、演奏には影響しない。(補足)今回のバージョンより、VS2019によるビルドに更新した。対応状況(2018.12.12)†V7.86にて対応済み(原因)V7.63から抱え込んでいた不具合。同様の不具合がV7.03で発見されV7.04で対処したが、V7.63の時点でシークに関する制御に手を加えた際、再び症状が出るようになっていた。強制的に現時刻を最終時刻に律則させる処理を入れていたことが原因である。現時刻がリロード処理で律則されてしまい、その判断が正しく行われなくなっていた。(対処)リロード時に強制的に現時刻を最終時刻に律則させる処理を取り払った。鍵盤を1回クリックしても演奏が始まりません。2回クリックすると曲頭から演奏が始まります。不正なパスであってもそのパスに置換されてしまい、以降そのパスをリロードする状況に陥っていた。(対処)現在のパスを一旦退避しておき、不正なパスを取得した場合はパスを復帰するようにした。本事象と同じことが排他的起動(*x)や、データパスを引数に与えた起動においても行われていたため、その処理も同様の手直しを行った。「ファイルをオープンできません」というダイアログが出て読み込みが無効になります。その際、既にロード済みのMuseデータには変化がなく、演奏もそのままできます。常にドラッグ&ドロップしたファイルに対する「ファイルをオープンできません」が出るようになってしまいます。対応状況(2018.10.08)†V7.84にて対応済み(原因)V7.83にて、ドラムパートのP指定とX指定の順番を守る分岐処理を組み込んだが、ドラムパートであることを判定するための情報は、Zメンバーあるいは*DRUMコマンドから得ていた。障害が発生したデータは、*DATAコマンドによりドラム転向しているため、そのメンバーがドラムであることの判断が付かず、通常処理にてP指定とX指定の順番が変化した状態のままであった。(対処)ノート構造体に送信候補フラグを新設し、加えてシークを2パスで処理することで、ドラムパートか否かによらず、常にコントロールのデータ記述順を守って送信するするよう抜本的改造を行った。XGシステムONを送信した際は、インターバルを長めにとって音源側が処理を確実に行えるようにした。以下のデータで再現します。対応状況(2018.10.02)†V7.83にて対応済み(原因)V7.81にてシーク効率を高めるため、プログラムチェンジ(P指定)に対し、ローテーションバッファ方式を組み込んだ。この方式はP指定の発行を処理の最後で実施するため、NRPN関係のX指定と発行の順番が入れ替わる結果となった。XG音源のドラムに対するNRPNは、プログラムチェンジが発行されるとリセットされるため、データの記述順によっては、シーク時にNRPNが効かなくなるという症状が発現した。(対処)ドラムパートのP指定をローテーションバッファ方式の対象から外し、NRPNとの記述順を変えずに音源に送出するよう改めた。障害報告(2018.10.01)†いつ頃からか、XG曲で途中再生するとドラムが頭から聞いた場合と変わってる気がします。以下のデータで再現します。対応状況(2018.07.07)†V7.78にて対応済み(原因)ビルド環境をVS2008からVS2010にした際、今まで必要だったメインウィンドウのサイズ固定化処理が不要となったため、その処理をV7.77で取り除いた。その処理をトリガにしたイベント発生を足掛かりに、起動引数によるダイアログ群表示処理を行っていたため、それらの処理がうまく動かなくなってしまった。(対処)ダイアログ初期表示のためのシーケンスや、最小化表示起動の制御、各種ウィンドウの初期状態のセットなどを全面的に見直した。挙動でおかしいと思われる点がありましたので連絡いたします。コマンドラインオプションでメンバー情報(*m)、譜面モニタ(*s)を表示させたとき、フォントがおかしいです。消して再表示させると元に戻ります。フィンガー情報(*f)を表示させようとしても、表示されません。ランチャー(CLaunch)で全ウィンドウを表示させて起動するよう設定していたので、おかしいなと思いました。コマンドプロンプトからオプション指定して起動しても同様でした。対応状況(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版以降は開発者様と同じ症状です。プロパティのセキュリティタブで、見えているユーザーすべてにフルコントロール権限を与えましたが、直りませんでした。VAフォルダを作って、コピーしてあります。(報告3)もう少し情報を追加します。・Museの応答なしインスタンスがあると、2つ目のインスタンスは管理者でなくても正常に動作する・muse.exeのプロパティのうち、互換性設定で「管理者としてこのプログラムを実行する」をチェックすると、起動時のUACポップアップは出るが、応答なしになる・iniファイルの#DV指定がない状態で起動すると、音源にSCVAを選ぼうとすると応答なしになる・2つ目のインスタンスはSCVAが選べ、正常まとめると、V7.75以降は、SCVAを音源として指定すると最初のインスタンスは右ボタンメニューから管理者起動をしておかないとNGで、応答なしのインスタンスが居れば、次からは管理者権限がなくても正常動作する、という状態です。※多重起動は、あくまでも挙動確認のためだけです。iniファイルへのアクセスが重なると、ポップアップでエラーが出ます。VAのためC:\VSTPluginsのプロパティを表示し、セキュリティタブで表示される全ユーザーに対してフルコントロールを許可して確認しました。(報告4)以下に試行順序通りに結果を書きますが、奇っ怪です。最終的に7.74org版も異常になってしまいました。muse自体の問題でなく、UAC関連で何かありそうな印象を受けました。ここまでで、レポートします。〇結果(操作順)*a,b,c,d版の順で1回ずつ実行。対応状況(2018.06.07)†V7.77にて対応済み。(原因)DPI比率の考慮がされていなかったため、100%以外のDPI値において、ウィンドウ枠幅のドット数算出に誤差が生じていた。(対処)Muse起動時にDPI比率を取得し、フィッティング寸法を決定する際にそれを利用するよう改めた。障害報告(2018.06.04)†DPI設定で120%や150%の指定を行うと、スクリーン境界でのフィッティングが効かず、スクリーンからはみ出したり、スクリーンの半ばで引っ掛かるなどの症状が起こる。Windows10でもWindows7でも症状を確認した。対応状況(2018.05.11)†V7.75にて対応済み。非表示音源によって歯抜けになった際に、位置づれを起こしていた。選択音源の位置を特定する際、相対位置指定ではなく、識別子指定で行うこととした。(追記)本件とは直接関係が無いがX129の指定名称を変更し、Readme.txtを改訂した。「微細ピッチ」と改名した。←これを選択DDDEEEFFFするとEEEなど別の音源が選択(EEEの音源に●印が付く)されてるようにみえます。内部的にはきちんとCCCが選択されているようでCCCの音源から音が出ます。Museを再起動するときちんとCCCが選択された状態になっております。対応状況(2018.05.11)†V7.75にて対応済み。同位置におけるカーソル移動を発行しているが、その際スケーリングの考慮をしていなかったため予期せぬ位置に飛んでしまう現象が生じていた。譜面モニタ外での同位置移動処理を抑止することとした。論理座標の一意性が失われるため、物理座標で処理を行うよう変更した。物理座標で処理することで正しく機能するよう修正した。OSの設定で150%に拡大(機能の名前はDPIスケーリング?)Museのバージョン:7.74上記の環境でMuseを起動したと同時にマウスカーソルの位置が別の場所に飛んでしまいます。譜面モニタを表示し、かつ自動スクロールをオンにしているとページが切り替わるタイミングでマウスカーソルが飛んでしまいます。この現象はMuseのウィンドウ内だとわずかしか飛びませんがMuseのウィンドウ外だと大きく飛ぶように思います。高DPI設定では〜のチェックを入れてスケーリングを無効にすると発生しません。設定した別PCで再現するか試したところ大きくは飛ばないもののわずかながら動く模様です。高DPIは想定していないでしょうしどちらかといえばOS側のバグ(仕様?)な気もしますが一応ご報告をと思いました次第です。対応状況(2017.11.29)†V7.73にて対応済み。(原因)2度読み処理の際、シーク関数によってユニコードBOMの先頭まで戻り、データ解析で矛盾を生じていた。(対処)シーク関数ではなくファイルポジションの退避と復帰によって対処した。本対処により、UTF-8(BOM付き)、UTF-16(リトルエンディアン)も読み込めるようになった。VSTiのパラメータ記憶ファイルも同じ原因のミスがあったため、併せて対処した。障害報告(2017.11.13)†......何度も何度も失敗繰り返してやっと原因判明。UTF-8ではダメだったのだ。Shift-JISでないと読み込めないのらしい。Shift-JISを基本サポートしておらんため、そんな簡単なコトに気づかなかった。UTF-8で保存してた。対応状況(2017.06.15)†V7.72にて対応済み。(対処)WAVE音源クローズ時のバッファクリア条件を緩和することで抜本的に解決した。副次的に、通常の音源切替性能も向上した。障害報告(2017.05.17)†バグ報告ですが、再現性が定かではないです。正常終了できなかったという報告です。音源を選択解除しようとして右クリックしたところ、応答を停止する現象が発生しました。対応状況(2017.05.09)†V7.71にて対応済み。(原因)この不具合はV7.32以降からの潜在バグである。V7.31からV7.32にアップする際、メンバー情報の表示で演奏をモタレさせないようにするため、その表示もマルチスレッド処理の対象に含めた。その際、表示制御用フラグの簡素化を図ったが、データ切替時の表示更新に対する考慮を欠いていた。(対処)表示制御用のフラグに不定状態の区分を1つ増やした。障害報告(2017.05.07)†まず、以下のデータをロードする。dこの時、メンバー情報ダイアログのAメンバーには、「小鳥」が表示されている。次に以下のようにドラム転向を追加し、リロードする。dここでメンバー情報が「ドラムセット(124)」となるべきところ、更新されず「小鳥」のままである。一度メンバー情報を閉じてから開きなおすと、「ドラムセット(124)」になっている。演奏自体は正常のようだ。対応状況(2016.11.13)†V7.62にて対応済み。(原因)V7.40からV7.50にアップする際、カレントディレクトリの変更処理は不要であると判断し削除した。他のディレクトリからMuseを起動した場合、WAVEコマンドのパスが通らなくなっていた。対話処理の場合のみカレントディレクトリをロードしたMuseデータの所在ディレクトリに変更する処理を加えた。以前は鳴っていたのですが、最近WAVEコマンドの音が鳴らなくなりました。対応状況(2016.11.13)†V7.62にて対応済み。過去バージョンでもタイミングによっては発生し得る。エクスプローラーからのクリックで起動した場合も同様の症状が起こる。共有メモリ領域の矛盾が生じてクラッシュする。(対処)音源起動中やロード中は環境準備中のフラグを立て、そのフラグが立っている間は、ドラッグ&ドロップ、および排他起動をキャンセルする制御とした。起動している間に、エクスプローラーからデータをMuseにドロップすると確実にクラッシュします。対応状況(2016.10.22)†V7.61にて対応済み。(原因)V7.50にて、ウィンドウフィット演算の効率化を試みたが、その際デグレードを起こしていた。(対処)以前の演算シーケンスに戻した。食い込むようになっています。症状の発現は、V7.50からです。対応状況(2016.09.21)†V7.52にて対応済み。(原因)VSTi演奏の際、既定の再生デバイス(WAVE_MAPPER)を指定してウェーブデバイスをオープンしていたが演奏中にコントロールパネルから既定の再生デバイスを変更すると、オープンしたデバイスハンドルと不整合が生じ制御不能となってMuseがハングしていた。演奏停止状態であっても、ウェーブデバイスは稼動し続けているため、演奏の有無に関らずフリーズが起こる。(対処)既定の再生デバイスは、常にデバイスIDがゼロの位置に動的に変化するため、WAVE_MAPPERではなくゼロを指定してウェーブデバイスをオープンするよう改めた。これにより、VSTi音源が選択されている状態でコントロールパネルから既定の再生デバイスを変更してもオープンした時点のデバイスに対して発音を継続する制御となり矛盾は生じなくなった。VSTi操作パネルの[X]ボタンでウェーブデバイスをオープンしなおすため、このボタンにて、既定の再生デバイスの変更を反映できる。音源にVSTiを選択した状態で、Windowsの既定の再生デバイスを切り替えると、Museがフリーズしてしまいます。演奏中かどうかに関わらず、必ず発生します(起動直後でも発生します)。MSGS選択時は問題ありません。演奏中に切り替えると、切り替えた先の再生デバイスで引き続き演奏が鳴ります。VSTi使用時は、デバイスへ直接WAVE出力しているのが関係しているのでしょうか。(x64)になります。対応状況(2016.04.12)†V7.33にて対応済み。(経緯)V7.30におけるデグレード。(厳密に言うと、V7.30以前からの潜在バグ)試聴系ダイアログを利用している最中は演奏は停止させるのが、Museの基本仕様である。V7.30開発時、繰返し演奏の処理中(シークバーを自動で曲頭に戻す処理中)に「楽器の試聴」や「ドラムの試聴」をメニュー選択すると、ダイアログが出ている状態で演奏が再開されてしまうという不具合を発見しそれに対処した。対処方法として、繰返し演奏再開中の試聴起動を確実に検出するためにインターバルを与えることとした。結果として、タイマーコールバックの多重起動の現象を誘発した。演奏を再開するために再びタイマーを起動する。冒頭でのキャンセルができない状態に陥っていた。演奏カウンターがダブルカウントされる。よって、演奏が倍速になってしまった。タイマー停止は1つだけが実施されるため、次に再びタイマーを2つ起動する操作を行うと、タイマーが計3つ起動していることになり、今度はトリプルカウントの状態に陥る。これを繰り返すことで「現象を発生させる毎にどんどん高速になる」という症状を発現していた。論理的にはインターバルが無くとも、タイミングによっては多重起動が起こってしまう。繰返し演奏の巻戻し処理中を表現するフラグを設け、このフラグが立っている間は、タイマー起動や停止、およびMuseデータのロード更新に関わるあらゆる操作を無効とする処理を組込んだ。繰返し演奏モードではない通常演奏において、演奏再開やシーク反応が改善するという副次効果を得た。巻戻し処理の内部インターバルを安全にゼロにできたため、以前XG音源がらみで除去した繰返しモードにおける演奏開始時のインターバルを復活できた。こちらのインターバルでは、すべての割り込み操作が可能である。対応状況(2016.03.02)†V7.31にて対応済み。(原因)V7.30におけるデグレード。MIDI音源オープン/クローズの制御のためのグローバル変数を整理し処理を効率化したが、それに伴う演奏会場ダイアログの送信ボタン[SEND]の不活性化条件を変更し忘れていた。(対処)正しい判定条件に改修した。適当なMuseデータを読込んで演奏させ、途中で再生を止める。この状態(演奏停止状態)で、演奏会場ダイアログを表示させると[SEND]ボタンが活性化してしまっている。過去のバージョンでは、演奏停止では不活性状態で起動し、演奏再開で活性化する動きだった。対応状況(2015.09.24)†V7.06にて対応済み。(原因)繰返し演奏時、曲尾に到達していた際の演奏再開位置の算出処理は、シーク処理のモジュールを利用しているが、そのモジュールはMARKとSTOPの両方を位置算出の対象としているため、最後のMARKに位置決めされてしまう症状となった。(対処)シーク処理モジュールにSTOPのみを位置決め対象とするオプションを設け繰返し演奏の指定がある場合はそのオプションで処理を行うよう改めた。単独の(`)に加え、連続する(``)も1文字のダブルクォート(")になる仕様とする。ダブルクォートにアットマークが続く文字列("@)を表現するためである。鍵盤をクリックすると、曲頭まで巻き戻されず、MARKコマンドからの演奏になってしまう。m1上記例の場合、曲尾からの演奏再開でMARKコマンド部分にシークされミが鳴る。曲尾まで達した後は曲頭に巻き戻されて、ドからの正常な繰返し演奏に移行する。対応状況(2015.08.29)†V7.05にて対応済み。(原因)本件はMuseのバグではなく、Windows10の障害である可能性が高い。初期化ファイル(muse.ini)にて、ファイル系ダイアログのサイズを固定化するスイッチDSZを設けることにした。デフォルトは可変(DSZ=1)であるが、Windows10での利用者は固定(DSZ=0)にすることを推奨する。ファイル系ダイアログの寸法は、OSレベルでレジストリに記憶され、Windows自体を再起動しても以前のサイズを復元する。そのため、不用意にダイログを大きくしてしまうとWindows10環境では元に戻らなくなる。この様な状況に陥っても、DSZスイッチを固定に切替えれば、適度な寸法に戻すことができる。本機構は、マイクロソフトがバグを解消した暁には撤去する予定である。muse(V7.10)にて、DSZスイッチを撤廃する。障害報告(2015.08.22)†Museメニュー「ファイル(F)」→「開く(O)」で出てくるダイアログですが、サイズを大きくすることはできますが、それを小さくすることができません。同様に、「エクスポート」の「MIDIファイル」や「PDFファイル」で出てくる書込み用のダイアログでも同じ現象になります。この現象はWindows10でのみ現れます。対応状況(2015.08.15)†V7.04にて対応済み。(原因)リロード時、新たにロードしたデータが以前のデータよりも演奏時間が短い場合に、演奏時刻を曲尾に律則させる処理を行っている。V7.00で曲尾到達時の内部時刻の定義を変更した際、上記処理における改修が漏れていた。(対処)リロード時も、新しい内部時刻定義に基づいた律則処理に改めた。鍵盤をクリックしても1回のクリックでは演奏が始まりません。2回クリックすると曲頭から演奏が始まります。V6.90では、1回のクリックでも演奏が始まっていました。対応状況(2015.08.01)†V7.03にて対応済み。(原因)V7.00からV7.01にアップする際、プログラム各所のシェープアップを図ったが、その際に作り込んだバグ。V7.01でキーメッセージ関係の処理を整理し、WM_CHARのイベントを一切利用せず、WM_KEYUP/WM_KEYDOWN系統のみに簡素化した。これによりメインのメッセージループでのTranslateMessage?()は不要になると判断し、取り払った。取り払ったために、反応しなくなってしまった。(対処)TranslateMessage?()のコールを復活させた。標準的なWindowsの仕様となっていません。メニューバーのイニシャルにアンダーラインが付いているか否かによらず起こります。Altを押下して一旦キーを上げ、その後F/G/H/Vを押下する場合はメニューが出ます。対応状況(2015.07.21)†V7.02にて対応済み。(原因)V7.01の開発時に、譜面モニタの右クリック連打によりMuseが落ちる症状を見つけた。当時は、クローズ処理でのインターバルを充分に与えることで対処したが、インターバル中にリロードのイベントが大量に発生すると、同様の現象が起こることが判明した。そこで、インターバルを終えたタイミングで、インターバル中に発生した操作イベントをクリアする処理を施した。これにより上記の症状は治まったが、シーク操作時にもイベントクリアが起こることとなり、キーを解放した瞬間の演奏再開が実施されなくなったことが原因である。(対処)演奏中のシークを管理しているフラグを利用し、それが立っている場合はイベントのクリアをしないこととした。「表示」に加え、「演奏」の機能もサポートすることにした。演奏中の状態で押したとき、ジャンプした後演奏が再開しないことがあります。効いて、演奏が再開することもあります。パソコンの起動直後が顕著で、この操作を繰返すと次第に起こらなくなります。スクロールバー両端の三角印のクリックでは起こらないようです。現象を確認しています。対応状況(2015.07.13)†V7.01にて対応済み。(原因)V7.00で途中再生におけるシーク制御に効率改善を実施したが、その際に混入したバグ。波形加工の遅延指定ではメッセージが大量に発生する可能性があるため、バッファリングを行っている。本来、波形加工のLSB/MSBであるNRPNをバッファリングした後、それがXでの指定である場合を考慮し、リアルタイムに音源送出する処理に移行すべきところ、波形加工バッファリング後に処理を打ち切っていた。(対処)NRPN検出後、バッファリングした後も音源送出処理へ移行するよう改修した。メッセージがうまく再現されなくなっています。対応状況(2015.07.13)†V7.01にて対応済み。(原因)V7.00で履歴メニュー制御の大幅な効率改善を実施したが、その際に混入したバグ。履歴メニュー直下の曲項目は、直近で選択されたものが先頭に移動する制御を行っているが、muse.iniで履歴メニュー直下の表示曲をゼロに指定した場合の対処が漏れていた。(対処)履歴メニュー直下の表示曲がゼロの場合は、曲項目の移動処理を行わないように改修した。障害報告(2015.07.12)†V7.00で不具合を発見しましたので報告致します。muse.logの内容が下記の状態で、別の.musファイルからmuseを起動したところ、2つ目のタイトル行が履歴メニューに表示されなくなりました。用(区切り線)ただいま。0に指定しているのですが、開いた.musファイルの履歴が表示されてしまいます。対応状況(2015.04.11)†V6.82にて対応済み。(原因)演奏会場の確認ダイアログをコールした際の、スライダー値範囲の初期化漏れ。そのため、最終スライダーのみ初期化されていなかった。(対処)正しい停止条件に改修した。確認ダイアログの最下段スライダーは、100までしか指定できない。対応状況(2015.03.09)†V6.81にて対応済み。その中の最終メッセージのみを残すようにしている。別途属性表示用のノートを確保しない構造で制御している。変化の激しい遅延指定により、遅延開始の1つ目のノートとその直前のノートが同一時刻になる場合が発生。上記の仕様から直前ノート側が除去されることとなり、それに伴って付帯されている属性表示用の文字情報も解放された。付帯の文字情報を温存する方式とした。従前でも譜面モニタの表示文字用のノートは存在している。MIDIコントロールを伴わないノートとなる。今回の対処は、このノート種別に挿げ替えることで対処したことになる。(補足)本件追跡中に、演奏開始時点のシーク処理を高速化する部分で論理的な不備を発見した。何の属性値もコントロール種別も持たないフルゼロのMIDIメッセージを送出する可能性があった。この不具合による直接的、致命的な症状は出ないと推測されるが、本件の対応に伴い改修しフルゼロメッセージを送出しないよう改めた。