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