対応状況(2014.07.01)†V6.75にて対応済み。(原因)フィンガー属性を検出した時点で、和音の冒頭に巻き戻すことなく属性表示用のアクセントノードを生成していた。(対処)アクセントが和音内に存在している場合、生成する表示用ノードの位置を和音冒頭に位置決めするよう改めた。q)に関しても同様の不具合が認められたため、それらにも対応した。以下の様なMuseデータを譜面モニタの属性表示で確認すると、アクセントの表示位置がおかしい。譜面モニタの属性表示では、和音外のファの位置に表示されてしまう。対応状況(2014.04.24)†V6.72にて対応済み。(原因)V6.71にて施した楽譜出力機構の内部的改善における、スラッシュセパレータ挿入判断のための五線カウントロジック部分のデグレード。おいてもコールしてしまっていたため、負値の配列アクセスが起こり不定値によるカウント処理が発生していた。概ねほとんどのグループでカウントされず、ネスト量の制御値がゼロのままになったため、単独五線の判断が起こらなくなった。(対処)フィンガーのマスク処理は、グループ化ノードの処理判定の後に実施するよう改めた。グループ内に譜刻対象の五線が存在しない場合に備え、グループ内の五線数を別変数でカウントし、グループが完了する時点で従前の五線数をインクリメントする方式とした。(補足)V6.71にて小節休符をサポートしたことで、複数のフィンガーが集約された五線上での休符譜刻が従前以上に発生するようになった。今回、初出フィンガーのみに小節休符を生成するという制御を組み込み、パート譜での小節休符譜刻を維持したまま複数フィンガーの休符衝突を削減させた。障害報告(2014.04.24)†V6.70までは、単独フィンガーや1つのグループ五線の場合にはスラッシュセパレータの譜刻が抑止されていたが、V6.71では、ほとんどの場合で譜刻されてしまう模様。対応状況(2014.03.23)†V6.71にて対応済み。(原因)一括指定コマンド(*FING)の強弱(v)指定の処理において、その抑止判断をするフラグ参照先に誤りがあった。フィンガーの処理ループにおいて、本来巡回先フィンガーのフラグを参照すべきところ、*FINGが記述されているフィンガーのフラグを参照していた。(対処)巡回先フィンガーのフラグを参照するように改修した。自動記譜抑止において、他の属性処理にも同様のケアレスミスがないかチェックしたところ、タイミング合わせ(%)にも同じミスを発見したため、これも改修した。fff)が表示されます。削除すると表示されません。記述されているからでしょうか。対応状況(2014.03.20)†V6.71にて対応済み。五線集約指定の符幹方向制御を可能にした。その制御用に従前の接続記号"+"に加えて"*"の接続詞を新設した。未使用フィンガーの離脱処理モジュールにて、追加された"*"の考慮が欠落していた。そのため、0番フィンガーが存在しない場合にすべてのフィンガーが1つの五線に集約してしまうという症状に陥っていた。(対処)未使用フィンガーの離脱処理にて、接続記号"*"も正しく処理するよう改修した。"+"指定と"*"指定とを正しく区別しきれていない箇所も存在したため、合わせて改修した。(補足)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)を導入されたし。「シシリアーノ」の楽譜出力がV6.40以降のバージョンで正しく印刷されません。/"Windows8のせいではないと思うのですが、如何でしょうか。LilyPond?のバージョンは2.16.2です。フィンガー指定に変更しましたが,出力は同じでした。対応状況(2014.02.23)†V6.70にて対応済み。(原因)名前付きマクロにおいて、不正文字検出ロジックが漏れていた。(対処)無名マクロで実施している不正文字チェックと同等のロジックを組み込んだ。障害報告(2014.02.23)†d{4}だと文法エラーですが、d$a{4}だと文法エラーになりません。$a{}の中の数字は1でも2でも再現は4分音符になります。対応状況(2014.02.20)†V6.70にて対応済み。(原因)和音の閉じ括弧を検出した段階で、それと対になっている和音の開き括弧を、それ以降の再現表記(,)で再現すべき和音として記憶している。自己参照ループに陥り、再帰呼出し処理でスタックオーバーフローが生じていた。本障害は和音の再現表記のみならず、同様の理由で連符の再現表記でも起こった。()(対処)一度再現処理を施した再現先を記憶しておき、二度目以降の再現処理において自己参照を引き起こす状態か否かをチェックし、もし自己参照が起こる場合は、記憶しておいた再現先を再利用して再現を実施するという一連の処理を組み込んだ。多段階、多階層の再現処理でも自己参照回避が正しく実施されるよう工夫した。和音や連符の括弧外にある再現表記は自己参照が起こらないことは自明であるため、その場合はこの処理を駆動させない工夫をした。よって、連符内連符など多階層の再現表記を利用しない従前データでは性能劣化はほとんど生じない。再利用のための再現先記憶域は、従前から存在する括弧対の管理変数を使い回すことでメモリ効率の劣化も回避した。対応状況(2014.02.03)†V6.70にて対応済み。(原因)V6.41→V6.50の時点でシーク処理の効率化を施した際に埋め込んだ障害。波形加工によるNRPN音源負荷を低減するため、最終値のみ送信を行っているが、XコマンドによるRPNは即時送信している。そのため、波形加工とXコマンドのMuseデータ記述順によっては、シーク時にその順序が逆転し、演奏時に本来あるべきMSB,LSBの指定状態になっていなかった。(対処)MIDI規格によりデータエントリがNRPNとRPNで共用されているため、1つのデータエントリで同時にNRPN、RPNの指定を実施することはあり得ないということを前提に、シーク処理を全面的に見直した。既存のバッファ内容を音源に送信すると共に、検出したNRPNあるいはRPNを新たにバッファリングする方針とした。これにより、従来諦めていたXコマンド遅延指定時の最終値のみ送信の処理も実装可能となった。バグを改修しただけでなく、性能も向上したはずである。c*STOP""です。音になって、上がっていきません。音がビヨ〜ンと揺れているようです。効いてる?のかちょっとわかりませんがいろいろやってみると、うまく上がっていくケースもあるようです。両方削除すると、途中飛び込みでも正常に上がっていくようです。指定が干渉しているのが原因のはずです。対応状況(2014.01.07)†V6.65にて対応済み。(原因)V6.60からの潜在バグ。ドラムセットにおけるボタン表示文字列の制御で、ユニコード対応に漏れがあった。(対処)UTF-16による文字列演算に改修した。(補足)本バージョンより、ドラム試聴のClassicセットにおいて、ティンパニのボタン名称を明示するよう変更した。障害報告(2014.01.06)†ドラムセット画面で音色が●だけになります。対応状況(2013.12.18)†V6.64にて対応済み。(原因)演奏が曲尾到達した際に、以下の処理を実施している。�音源のクローズ処理を行う�演奏開始ノートをNULLにクリアする一方、巻き戻しシークのイベントが起こった場合は、シーク位置の演奏開始ノートが新たにセットされる。今回の事象は、�の処理中に巻き戻しシークのイベントが発生するもので、そこで演算された演奏開始ノートが、その後に続く�の処理でクリアされるために発生した。演奏開始ノートがNULLの場合、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では発生しないようです。次に鍵盤をクリックして再生した際に無音となる。タイミングはかなりシビア。音が消えても、一度停止して再開すると再び音が出る。続く再生で同様に無音演奏となる。対応状況(2013.12.02)†V6.63にて対応済み。(原因)演奏停止時点でのメインウィドウのシークバーによる位置決めは単純であるが、演奏中のシーク操作ではシーク後に演奏を再開する仕様である。♪マークは、基本的にはMIDI音源がオープンされ演奏している状態を表現しているが、演奏中のシークにおいては内部的にMIDI音源がクローズされていても♪マークを表示したままにしておき、停止状態でのシークか演奏中のシークかを識別し易くする仕様である。どちらのシークであるかを内部フラグに記憶しておき、無駄な描画をしない様、演奏中シークの場合は♪マークを再描画しないようにしてあった。♪マークが表示されていない状況で無駄な描画を行わないシーケンスに入ってしまい、結果として♪マークが非表示状態で演奏している状態に陥った。V6.51からV6.52にマイナーアップした際、確実なメッセージ処理をするために、MIDIオープンと演奏開始との間に0.1秒ほどのインターバルを与えた。このインターバルが、より「演奏開始とシークが間髪入れず実施される」状況を発生させ易くしていた。このインターバルが存在しなければ確率は低くなるが、所詮原理的に本症状は発生する。(対処)♪マークの描画に関しては、シーク区分の内部フラグ状態によらず、MIDI音源オープン時に常に表示させるよう改めた。データで確認した挙動です。位置で停止している状態で、スペースキーを押すと♪が表示されます。戻って再生が始まります。このとき♪が消えたままで再生している状態になります。単純な状況で再現しました。MARKは不要でした。対応状況(2013.11.29)†V6.62にて対応済み。よる完全停止以降の記述に関して、実際に利用されるマクロ以外の文法チェックは実施しない仕様である。その繰返し数は利用時に決定されるため、それもエラーチェックしない仕様である。よる完全停止以前の記述に関しても同様の処理を施していた。実際の演奏シーケンスで内容を展開する際、繰返し数をチェックする方法に改修した。よる完全停止以降の記述と同様の扱いが可能となった。実際に利用されるマクロ内の範囲のみ文法エラーを検出する。よって、繰返し数に関しても不問となる。利用されるマクロ内に記述された階層的なマクロに関しての繰返し数はエラー検出される。以下の様な記述は文法エラーであるが、エラーダイアログが出ず、繰返し数1として処理されてしまう。M名前の無いマクロでも同様。対応状況(2013.11.28)†V6.62にて対応済み。(原因)症状は1年前(2013.01.27)のV6.31のバグと同じであるが、別の原因による障害。V6.60での文法エラーダイアログ後のリロードでダウンする障害の対処をした際、フォント名称の切替え制御を変更したが、起動直後のシークキャンセルの考慮が欠落していた。起動直後のBSキーはシーク防止の対処を施していたが、マウス右ボタンでは防止の対処を怠っていた。(対処)起動直後のマウス右ボタン時もシークキャンセルの判断を追加した。(補足)本件の対応に伴い、V6.50時点から内包し続けていた以下の障害も解消した。障害報告(2013.11.29)†データを何も読み込まない状態で鍵盤を右クリックすると、落ちますね......。対応状況(2013.11.20)†V6.61にて対応済み。(原因)ROOMコマンドの文脈解釈における考慮不足。具体的には、開き括弧および文字列終端検出でデリミッタ処理を実施していたが、Q(あるいはR)の検出ではそれを怠っていた。本件は、V4.40にてROOMコマンドをサポートした時点からの潜在バグであった。(対処)正しく文脈を解釈するよう改修した。使用していて気づいたのですが、どうもROOMコマンドが利いていないようなのです。2」と報告してきます。機能→演奏会場の確認で小ホールを「SEND」すると切り替わります。とまた、音源依存の話かなとも思いましたが、他の方のデータをいろいろ調べているうちに以下のことも分かりました。以下のコマンドは利くんです。対応状況(2013.11.19)†V6.61にて対応済み。(原因)文法エラーが起きた際、途中まで読込んだMuseデータはすべてメモリ上からクリアする。テキストエリアに描画するためのフォント名称は、MuseデータのFONTコマンド文字列へのポインタとして記憶している。文法エラーが起きた直後、本来必要の無いテキストエリアの描画を行っており、その際、既にメモリ解放されたエリアのフォント名称を参照していた。(対処)Museデータをクリアした場合は、フォント名称へのポインタをスタティック上のデフォルトフォント名称に切替える様改めた。本来必要の無い文法エラー直後のテキストエリア描画を実施しない様に改めた。記述エラーのダイアログを閉じた瞬間にリロードをすると落ちることがあるようです。記述ミスを含む大きめのデータが起きやすいと思います。タイミングはダイアログが消える瞬間ぐらいです。記述ミスが1300行代にあるデータでしか今のところ起きません。同じデータで1300行代あるいは1400行代に記述ミスを作ると落ちます。�データの1388行目に何かしらの記述ミスを入れる�読み込む�ctrlを押しながらダイアログの[OK]を押す。対応状況(2013.11.13)†V6.61にて対応済み。(原因)演奏が曲尾に到達した時点で、一旦MIDIデバイスをクローズし、曲頭に戻してから再オープンを実施しているが、そのクローズからオープンまでの間に、鍵盤のクリックが起こると手動での演奏開始(つまり再オープン)が発行される。フラグがセットされていないという事態に陥り、結果として二重オープンを実施することになっていた。二重オープンを強制的に実施することで「MIDIデバイスをオープンできません」のエラーが出現した。(対処)オープン処理をクリティカルセッション制御とし、二重オープン時に2度目が確実にスキップするよう改善した。クローズ処理も含めてフラグ整合を取るべきと判断し、今回のクリティカルセッションと共通のオブジェクトでクローズ処理もくくることにした。繰返し演奏のモードにして、シークバーが先頭に戻ったタイミングで停止させるとエラーが表示されました。容:MIDIデバイスをオープンできませんサウンドフォントを使用した場合に、発生するようです。Synth』では、発生しませんでした。対応状況(2013.10.21)†V6.56にて対応済み。(原因)X指定のNRPN,RPNは波形加工以外も多様に存在するので、バッファ量が膨大になるため都度即座に送信している。波形加工は特に遅延指定の負荷が高いため、バッファリングによる最終値送信としている。波形加工のMSBは共通なため、ランニングステータスを活用している。その際、波形加工を検出した時点でランニングステータスを前提にしてMSBのバッファをクリアしてしまい、その後、即時出力のNRPNが検出された場合、MSBの送信されない事態に陥っていた。(対処)MSBのクリアは即時出力時側で実施するように改めた。おいてシーク時に送信されないNRPNがあるようです。以下のようなデータです。メッセージがシーク時に正常に送信されていないようです。異常が発生するようです。対応状況(2013.09.07)†V6.55にて対応済み。(原因)クリップボードにおいては、CR(0x0d)-CF(0x0a)の2コードを必要とするが、CFの出力処理を失念していた。本障害は初版の時点から内包されていた。(対処)2コード出力するよう改めた。障害報告(2013.09.07)†キーボードの上下キーでリロードを行った際、文法エラーがあるとその内容がクリップボードに出力されるが、テキストエディタに貼り付けると部分的に文字化けしたり、本来2行の内容なのに改行をしなかったりする。対応状況(2013.07.22)†V6.54にて対応済み。(原因)Museは極力無駄なコントロールメッセージを音源に送出しないようにして音源負荷を低下させる工夫を施している。その一環として、同一のMSBやLSBが続く場合は送出の省略を実施している。このため、単独のデータエントリーでコントロール値を変更する場合が存在する。途中再生時において、シークを効率的に実施するため、波形加工のメッセージはその最終値のみを一括送出するようにしている。曲頭から再生した場合は矛盾は起きないが、途中再生時の場合に単独のデータエントリーに対して省略されているLSBの種別が食い違う可能性があった。V6.41までは、この食い違いを発生させないように最終的に発行したMSBとLSBをシーク処理の最後に再発行していたが、V6.50でシーク処理全体を組み直した際、この再発行処理を取り除いてしまっていた。(対処)最終のLSB再発行処理を復活させた。MSBの方は、波形加工の一括送出処理の特性上、種別の食い違いが発生しないため、再発行しないままとしている。(再現性)VSCでは本症状は再現しなかったが、これはVSCの特殊な音源仕様が理由である可能性が高い。VSCの波形加工(周波数)は、Q=�,�における�と�が独立ではなく、どちらを指定しても同じ1つの効果だけをサポートしている模様。�を指定しても、�を指定しても、最後に指定した値でもう片方を律則してしまう。(波形加工の確認ダイアログで実験したところ、かなりの確度で本推論が正しいと思われる)もしこの推測が正しいとすると、LSBの種別が食い違うというバグがあっても、VSCは不具合が起きていないかのように振舞うことになる。以下のデータは最初から再生した際には問題はありませんが、途中から再生すると「Q=64.64」が反映されないようです。"途中再生"Q=64.64d1冒頭の「Q=1.0」や、「Q=0.:2」を外した場合や、「Q=64.64」の部分を「Q=64.64:i1」のようにするのはOKです。バージョンは、V6.50以降から発生しているようで、V6.41では未発生でした。Timidityです。GS等30MBレベルのSFなら再現できると思います。VSCでは、演奏終了時のメモリ解放を有効にするか否かで挙動が変わる場合があったかと思います。対応状況(2013.07.13)†V6.53にて対応済み。(原因)V6.50にて音源メニューの構築処理を効率化した際、コンフィグファイルが存在しない場合に、構築ループを脱出してしまうという不具合を埋め込んでしまった。具体的には、continueとすべきところをbreakとしてしまった極めて初歩的なミス。(対処)コンフィグファイルの有無に拠らず処理を継続する様に改めた。報告させていただきます。v6.50辺りからのようです。対応状況(2013.07.03)†V6.52にて対応済み。以下の様な演奏停止から演奏再開までの処理がほぼ共通して実行される。上記一連のシーケンスで、繰返し演奏が他の操作と異なる点は�と�の間のインターバルにある。�と�の間にあえて2秒程度のインターバルを与えていた。このインターバルは待ち時間の間でもキーやマウスの入力を受け付けるよう、Sleep()処理ではなくタイマイベントを使ったカウンタ方式を使っていた。この方式のインターバルを取り払うと症状が改善したため、本インターバル処理に問題があると推測される。※問題の箇所は絞られたが、真因として合理的説明が付かないため、本件に関しては断続的に追跡を試みる。<追記>Elekenさんの分析により、真因が明確となった(下記、掲示板からの転載を参照のこと)(対処)リピート処理において、�と�の間のインターバルを除去した。タイマイベントを使ったカウンタ方式は、マークコマンド刻みに位置決めする逆方向のシーク操作でも利用しているが、こちらに関しては現時点で支障が生じていないため、現状維持とした。プレーヤーとしては即応型の繰返し演奏となり少々バタツキ感があるが、Museデータの曲頭、曲尾に休符を配しているデータも多くそちらに委ねる事とした。エンドレスタイプの演奏に関しては逆に有利に働くと判断している。21:11:58私も同じ音源を使っています。本件に関しては断続的に追跡を試みる。なっているので、おせっかいかもしれませんが、少し問題解決のヒントを書いてみます。信号を受信したときの音源の挙動に関わる、音源固有の問題です。「繰り返し演奏」固有の問題でないことは、以下のデータを最初から再生したときと途中から再生したときの挙動の違いから明らかです。受信するタイミングに関わっているようです。有効化されるようです。音源の仕様だと思われます。途中から再生したときの挙動の違いから明らかです。受信するタイミングに関わっているようです。有効化されるようです。音源の仕様だと思われます。人工的に2秒ほどのインターバル挿入して、そこから徐に演奏を開始していました(以降の[*2]の発行となります)。存在するといった状況ですね。・・・実は、昨晩から今に至るまで、MIZさんにトライアル版を何度も送りつけては状況を確認してもらっていました。MIZさんとの実験の結果、このインターバルを取り払うと症状が改善する事実がわかりました。ある音源の問題として、インターバルの無いメッセージで欠落が起きるというのがあるため、インターバルが無い方が症状が改善するという事態に、私もMIZさんも戸惑っていたのです。合理的説明を付けられずにいました。Elekenさんの今回の見解で、一気に霧が晴れた気分です。おせっかいじゃありません!救世主です!!つまり、こういうことだったんですね。�そのインターバルを取り払うことで、[*1]と[*2]がほぼ同時に発行されるようになった。この�と�では、音源側のメッセージの扱いが異なる。現在のMuseは、繰返し演奏は�となり、それ以外の停止/再生では�となる。したがって、現象は繰返し演奏でのみ出現した。--------------------------------------------------そう言えば追跡の最中、MIZさんが「ROOMコマンドの有無で症状が変化するのが気になる」と言ってました。MIZさん、良い勘してますっ!そして、どうもこの「ほぼ同時」という部分がかなり微妙みたいですね。実はMIZさんの実験によると、インターバルが挿入されているMuse(V6.51)にて、1回目の演奏:データ部のエックスクルーシブが効いている。2回目の演奏:データ部のエックスクルーシブが効いていない。3回目の演奏:データ部のエックスクルーシブが効いていない。4回目の演奏:データ部のエックスクルーシブが効いている。・といった感じで、なんと4回目に効いている状態に戻っていました(苦笑)。なんにしても、音源仕様ということで納得です。Elekenさんのご記帳を、そのままMuseWikiに掲載させて頂きました。感動しちゃったんだもん(笑)。以下のデータを「繰返し演奏」させると、1回目と2回目で音色が変化してしまう。対応状況(2013.05.11)†V6.41にて対応済み。オールサウンドオフとコントローラリセットが不要となることに気づき撤廃。初期化ファイルにて送信の有無を切り替えられるように改良。この時点で、GSリセットを送信しない設定をした場合、GSリセットの送信をせず、オールサウンドオフとコントローラリセットも送信しないという状況となり、確実な発音停止ができない症状に陥った。(対処)GSリセット送信をしない設定の場合は、オールサウンドオフとコントローラリセットを送信するように改修した。一時停止の際にノートオフが送信されません。音が鳴りっぱなしになってしまいます。手持ちの他の音源では、ハードウェア音源も含め、症状は発生しません。