文の組み合わせも存在しそうに思います。しても、問題は起こりません。ケースは、ヒープ断片化を起こしていると考えられるので、より複雑です。領域」をアロケートする他に、別の領域を使う選択肢があるからです。指定されたときのみ、前者を選択するのではないでしょうか。ソースコードを見ないとわからないので、全く確証が持てません。説明がつきそうですが・・・。バグはなかった!」で良いでしょうね。発生するのでしょうか。すると同様の条件になるケースはありそうだと感じます。説明がつきそうですが・・・。機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。具体的にお示しします。何か考察のヒントになるかもしれません。以下の様な簡素な内容になっています。T_macr;この中の★印の付いたメンバーは、現時点の純正培養Museでは使用していません。そこでこれらの★付きメンバーも剥ぎ取ろうとしたのですが、1つでも取り払うと症状が出なくなってしまいました。しつこいなぁと思われたでしょうが(^_^;)いえいえ、むしろ“真実を追究する”真摯な姿に感動さえしています。人のあらゆる活動で尊重されるべきものだと思います。可変長文字列のmalloc()だけ1バイト余分に確保するようにしようと思います。データのパス、楽譜出力用のタイトル群とスルーコマンド位です。そもそもたった1バイトですので、大勢に影響は無いでしょう。※その対応箇所のコメント文には、今回の趣旨が分かるように書いておこうと思います。ないと10年後の自分が見直した時、無駄なメモリを確保している!と、戻してしまいそうです(笑)。バグはなかった!」で良いでしょうね。よかったよかったとても安堵しています。\(^o^)/でもこの“戦いの踊り”が終わり、お二人とエキサイティングなやりとりもできなくなると思うと、ちょっち淋しい感じもしたりして(苦笑)。記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。バイトのデータが規則正しく埋まっているようです。領域」を導いていたと推測しています。解析を伴うので難しいです。これでゲームクリアとさせていただきます(笑)。バイト余計に確保することはスマートな解決策だと思います。バイトのオーバヘッドは誤差のようなものだと思います。記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。アイデンティティってなんだろうと暫し考えてしまいます。思っていた以上によく考えられて設計されているのだと、ただただ感服するばかりです。今回は難しいパズルを見つけた気がして、少し書き込みすぎてしまいました。楽しんでいたのは私だったかも知れません。対応状況(2012.10.25)†V6.26にて対応済み。初期化されていない文字列を添加して、クリップボードに出力していた。(対処)バージョン表示に関する不要な変数を完全に削除し、クリップボード出力の際に、それを添加しないようにした。(補足)本障害対応とは別件であるが、利用OSによって切り分ける処理を施し、テキスト表示エリアの背景色は、極力メニューバーの配色と等しいデフォルト色を採用するよう工夫した。演奏会場の設定ダイアログにて[COPY]ボタンを押下すると、現在選択されている演奏会場設定のMuse文法記述がクリップボードに出力される仕様であるが、その際、出力された文字列の末尾にゴミが付いてしまう。対応状況(2012.09.23)†V6.25にて対応済み。(原因)LilyPond?に対応する前は、マクロ記述直後にダブルコーテーションを記述すると文法エラーとなるため、何の考慮もせずに次の文字処理に移行させていた。V6.2より、楽譜スルー指定の新設によりダブルコーテーションもコマンドの先頭を識別するデリミッタ文字となったが、上記の処理シーケンスに手を加えることを失念していた。そのため、ダブルコーテーションの内外判定で不整合を生じた。(対処)マクロ終了時に、デリミッタとしてダブルコーテーションを検出した際フリップフロップのフラグを立てて処理を継続するように改修した。記述ミス」というエラーを発生させます。$macro{}は正常に動作します。対応状況(2012.09.13)†V6.24にて対応済み。(原因)移調楽器コマンドでパラメータが省略された際に、メンバー属性値を採用する処理が欠落していた。(対処)省略時にメンバー属性値を採用する処理を追加した。(補足)V6.24より、muse.exeのプロパティに版権やバージョンをセットすることとした。いった形式で、移調楽器のパラメータ(調性や移調)を省略すると、PDFに出力した楽譜の音符が、極度の低音側に記譜されるなど乱れた状態になる。演奏は正しく行われている。対応状況(2012.09.02)†V6.23にて対応済み。同時刻内の整列処理において、そのポインタを参照して条件判定を実施していた。そのため、統合処理で除去されシステム上不定状態となったノートの値を参照することとなり、レアケースでの不具合が生じることとなった。整列処理に影響を与えないようにした。整列処理の条件も見直し、強弱ゼロ(v0)の音符に対してより効果的な順序変更を施すようにした。障害報告(2012.08.31)†V5.5より同時刻内のOFFノートを前方に、ONノートを後方に整列させる処理を組み込んでいるが、その処理が(非常にレアケースではあるが)、機能しない場合があった。対応状況(2012.09.01)†V6.23にて対応済み。(但し、Win95は除く)(原因)Muse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更したため。Micorosoftのポリシーもあり、VS2008の通常ビルドではWindows2000以上のOSを要求するようになった。(対処)ビルド時にWindowsVersion?のマクロを強制的に古いID番号にセットすることで問題を回避を試みた。通常古いID番号をセットすると、新しいAPIを活用できなくなるが、Museは古いAPIだけで組み立てられているので、ビルド時の問題は皆無であった。OSの導入を促す警告ダイアログが出現し、起動はできなかった。そこで、1世代古いビルド環境であるVS2005を採用することにした。Win95は対応できないが、Win98以降のOSであれば起動可能となった。(補足)本対処の模索中に、V6.22がリリースされた。演奏会場およびフィンガー情報のダイアログにて、タブストップによるフォーカス移動を可能とした。Meですが...)対応されなくなったんですね。起動時に「...新しいバージョンのWindowsが必要です...」のメッセージが表示され起動できませんでした。対応状況(2012.08.19)†V6.21にて対処済み。(原因)従来から内包していた潜在バグ。オプション文字の解析をする際、未定義文字を検出した場合の脱出条件にミスがあった。具体的には、文字のデリミッタ到達で判定するところを、文字アドレスがNULLであるかの判定をしていた。Muse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更した。従来不運にも症状が出なかったのは、コンパイル結果の実行モジュールにおけるメモリ管理方式の差異と考えられる。(対処)正しい脱出をするように改修した。(補足)今回の改修に伴い、オプションの列挙記述も可能とした。障害報告(2012.08.19)†(その1)従来のショートカットのままMuseを起動したところ、エラーが出るようになりました。v6.1までは発生しないエラーです。---------------------------〈Muse〉システム状況---------------------------ファイルがオープンできません\\hoge\muse\-$---------------------------(その2)不正なコマンドライン文字列を与えると、長時間ハングした後にエラーを返す。数十秒ハングした後、意味不明なエラーを返すので、是非改善すべきかと思います。対応状況(2012.08.19)†V6.21にて対処済み。(原因)Muse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更した。そのコンパイル処理の差でsscanf()関数の書式指定の処理仕様に変更が生じた模様。16進文字を数値に変換する際に正しい結果が得られなくなった。(対処)sscanf()ではなく、strtol()を利用することで回避した。(補足)今回の改修を機に、ソース内のすべてのsscanf()をstrtol()に変更した。これにより、muse.exeのサイズが(極僅かではあるが)コンパクト化するという副次効果を得た。障害報告(2012.08.19)†テキストエリア背景色の設定が反映されない。見做されるように見えます。対応状況(2011.11.26)†V6.03にて対処済み。(原因)途中再生からの演奏開始指定において、そこまでのコントロール属性をそれ以降の演奏に反映させるため時系列に内容をバッファリングし、最終的なコントロール属性のみを音源に送信する機構を組み込んでいる。高い密度でコマンドを送信すると処理渋滞が発生し、その後に続くコマンドの処理に欠落が生じてしまう。(対処)プログラムチェンジの送信に関しては、一定のインターバルを与えて送信するように改修した。(補足)なお本件とは直接関係は無いが、今回のマナーアップにて、Windows7向けのUI改善も施した。・メンバー属性の一部(特にV指定)が無視されている。(恐らく初期設定のV127になっている)・V指定について遅延命令が有効にならず、階段状に音量が変化する。・特定メンバーのS指定が無効になって0になっている。・特定メンバーのバンクセレクト(/8)が無効になっている。・途中再生で症状が発生し、最初から演奏すると正常な動作を見せる。・正常に演奏する場合もある。・音源としてSC-88proを使った場合のみに再現される。(MSGS、Timidity+では再現されず)なお、W=、R=、Q=の頻用が原因と思われたため、それらを制御していたフィンガーを全てコメントアウトすることで症状が抑制するも、やはり時々同じ症状が出た。そこで該当フィンガーに絞らず、データ内すべてのW=、R=、Q=指定をコメントアウトしたところ、症状は大幅に抑制された。対応状況(2011.10.17)†V6.02にて対処済み。(原因)譜面モニタ上のマウスカーソルの位置はリアルタイムに検出し、そのエリアに応じてカーソル形状を変更している。その処理に伴って、検出したエリアIDを記憶しておき、マウスクリックが起こった際にエリアIDを参考に処理分類を行っている。マウスが譜面モニタのクライアント領域から外れた際、そのエリアIDをクリアしていなかったためメニュープルダウンでのフック状態から復帰した際に、直前のエリアIDに呼応する処理が発動されてしまった。(対処)マウスが譜面モニタから外れた際、エリアIDをクリアする処理を追加した。勝手に小節などの縦の線が消えてしまいます。同様のことを繰り返すと、また出てくるので、モニタの下の部分をクリックしたようになるのです。対応状況(2011.07.10)†V6.01にて対処済み。(原因)Museコンパイルモジュールにて、遅延のコロンを一時的にNULLに置き換えて文法解析しているが、その復帰をエラー時のみに実施していたため、正常系でコロンがNULLのままになっていた。マクロを使用しない場合は支障は実用上の無いが、マクロ利用の場合はその文字列空間を再利用しているため、2回目以降はコロンが無くなったままになり、遅延指定が成されていないという解釈ミスが生じた。(対処)必要な解析が完了した時点で、文法エラー検出以前に直ぐにコロンを復帰するよう改修した。以下のデータでおかしな演奏になります。{d4r}32音がこもっている状態から強めていって、またこもらせる、みたいなプレイをマクロで繰り返しているのですが、なぜか最初の1回しか遅延が働いてくれません。SD-50、S-YXG50両方で確認しています。対応状況(2011.07.05)†V6.00にて対処済み。「エラーとはならないが、その指定は無視される」という仕様であるにもかかわらずエラー判定を実施していた。(対処)エラー判定を外した。転調を頻繁に行うデータを作っているのですが、困ったことが...ドラムにまで判定を出してしまっているようです。o2rrrrでエラーになります。対応状況(2011.07.05)†V6.00にて対処済み。(原因)左右矢印キーやシークボタンなどでスライドバーを移動させた際、つまみがシークバーの右端座標に達したかどうかを曲尾到達の判定に利用していた。後半の演奏が残されているにもかかわらず曲尾に到達したと判断された。後半のシークバーのドット数幅が1以下(実質ゼロ)になってしまうためである。内部的に処理している演奏時間を参考に判断することにした。気になる挙動に遭遇しました。ジャンプすると再生が停止する。発音されず、再生を再開すると発音される)。したり、音符を休符にして同じ操作をしても同様の現象が生じる。以後は少ないほうが限界値が小さくなるようです。対応状況(2011.05.12)†V5.92にて対処済み。(原因)V5.34からV5.35へのマイナーバージョンアップにてシーク高速化処理を施した。その一環としてシーク時に出力しても意味のないコントロールを音源に送信しない処理を組み込んだが、その対象にポルタメントおよびポルタメントコントローラを挙げてしまった。(対処)シークの際に必要最低限のポルタメント関係のコントロールを送信するよう変更した。障害報告(2011.05.09)†X65(ポルタメント)についてです。ように指定しますが、他のX指定と異なり、この指定は途中再生に上手く対応していないように思います。状態で演奏されてしまいます。音源で確認しましたが、VSCのような他の音源で同じ現象が再現されるかどうかは確認していません。対応状況(2011.05.12)†V5.92にて対処済み。(原因)V5.23からV5.24へのマイナーバージョンアップにてシーク高速化処理を施した。その開発途上でシークポイントまでテキスト表示が存在しない場合にフォント切り替えを実施する処理を組み込んだが、結果的にそれが不要になるシーケンスに落ち着いた。しかるに、開発途上でのフォント切り替え処置の削除をし忘れていた。(対処)フォント切り替え処置の削除を行った。障害報告(2011.05.09)†HEADタグのフォントの件です。通常HEADタグは、それ以前に書かれたFONTタグで指定されたフォントで描画されると思います。ウィンドウを表示させると、HEADタグより後で指定したフォントで再描画されてしまいます。対応状況(2011.05.06)†V5.91にて対処済み。同時刻内のノートONの後にテキスト表示イベントを移動する処理を施したが、テキスト表示イベントの一種であるMARKコマンドの場合、ノートONが発行された後にその位置で停止する状況に陥り、MARKから演奏を開始すると出だしの音が発音されたくなった。(対処)MARKコマンドは並べ替えの処理を行わず、モタレ軽減の処理は、TEXTコマンドのみを対象とする様、修正した。STOPコマンドに関してはV5.90においても本考慮が成されていたため、MARKもSTOPと同等の処理とした。同時刻であっても異時刻に変化した場合と同じ扱いとした。早々で申し訳ありませんがマーキング(*MARK)にジャンプさせたときにMARK直後の発音が飛ばされるようなのですが...。分かりやすいのは、開発者様の「交響曲第7番(ベートーベン)」を読込んで第2楽章にスライダーを右にジャンプさせると第2楽章最初の和音がとんでしまいます。対応状況(2011.05.06)†V5.91にて対処済み。(原因)V5.90にて、バッチ処理モードの際の高速化のために処理の入れ替えを行った際、データ編集のためのエディタパスを管理する変数の初期化手順が狂ってしまった。(対処)正しい手順に修正した。対応状況(2011.03.05)†V5.88にて対処済み。(原因)バックグランドで処理が走っている場合などの環境下でMuseが初出現のフォントをロードする際その処理に時間が掛かるため、演奏がモタレてしまう場合がある。演奏開始時点で初回のフォント読込みを終えている状態とした。再生すると、曲頭の数音が時間的に詰まって鳴る場合があります。初回再生の場合には必ずそうなります。dd前半2つのドの音と後半2つのドの音との間でモタレが起こります。TEXTコマンドの位置で遅延が生じます。対応状況(2011.02.04)†V5.87にて対処済み。従来のMuseはその解除タイミングを得るために音源側から発信されるコールバックを活用していた。アプリケーション側に投げてくれたため、正常な解除処理が行われていた。システム上の不整合が生じてハングアップに至る。その値が完了になった時点でループを抜け出すというシーケンスに改めた。確実なバッファの解除が実施できると判断した。イベントに関する処理負荷も低減させることができたと推測している。Readme.txtの改訂も実施した。Museコーディングの手引き”における節立てを組み直した。Driverが追加された状態にしておく。Driver”を音源として選択し、任意データを数秒演奏させる。MIDIマッパー”に切り替える。対応状況(2011.01.26)†V5.86にて対処済み。(原因)前回の不具合対応時に、マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施したが、その際、マクロ再帰処理に入る前のエラー制御変数の初期化が漏れていた。そのため、一番初めに検出したマクロ(エラーがあろうと無かろうと)をエラーの候補として扱ってしまい実際にどこか別の場所にエラーがある際に、そこもエラー表示してしまうという不具合を起こしていた。(対処)エラー制御変数の初期化を確実に実施するよう改善した。定義マクロ、$Syn2_0{・・・}を記述せず、X行目にその展開マクロ${Syn2_0}を記述すると、Museはマクロが未定義であるという文法エラーを検出するはずです。このエラーとは直接関係のない以下のエラー表示が出現してしまいます。対応する定義マクロがありません。$MC-G1_01この際、Y行目に関わるマクロには文法的なエラーは存在しません。[OK]を押下して上記のエラー表示を閉じると、この段階ではじめて以下の正当なエラー表示が出ます。対応する定義マクロがありません。${Syn2_0}つまり、X行目にエラーがあると何故かY行目がエラーとして検出されてしまいます。X行目のエラーを解決すると、Y行目のエラー表示も出なくなります。対応状況(2011.01.19)†V5.85にて対処済み。(原因)従前の処理シーケンスは、データに一度だけ記述するタイプのコマンド重複チェックを、マクロ展開処理よりも前に実施しており、しかも無名マクロの展開部ではそのコマンドの展開を実施していなかった。当初の仕様では、マクロの繰返し数にゼロ指定が出来無かったため、定義部は必ず実行されるという前提を置くことができるため演奏データとしては矛盾無く翻訳できた。事実上の問題は無いと判断していた。今回の症状が出現するに至った。(対処)マクロ展開を処理しながらコマンド重複チェックも並行するシーケンスに変更する事で、マクロ内に記述されたコマンドを正しく展開解析し、重複チェックも厳密に行うようにした。ドラムに関しては、移調(T)および音部記号(?)を無効化する仕様を実現するため、マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施した。{}と書きますと、ドの音が4分音符で一回鳴ります。{}と書きますと、Oのメンバーはドラムに転向しませんでした。*DRUM"O1"は転向します。ひとつのMUSEデータ内で、音源別に2種類の設定を記述しようとして、発見しました。対応状況(2010.12.23)†V5.84にて対処済み。(原因)譜面モニタがアクティブ状態で右クリックする場合と、非アクティブの状態で右クリックする場合とでリライトのイベントと演奏開始イベントの順序が異なり、後者を先に受信した場合に排他的論理和で描画している指揮棒カーソルの表示が乱れていた。(対処)右クリック・リロードの際、演奏開始直前で強制的に最描画のアップデートコマンドを送信することで、イベントの順序関係を調整し、表示が乱れないように対処した。譜面モニタが非アクティブなウィンドウ状態にある際、右クリックでリロードしようとするとそのクリック位置で指揮棒カーソルが2度描画され、クリック位置に指揮棒カーソルの残像が出現する。演奏および指揮棒カーソルの動作は正常であり、リライトすると残像も消える。対応状況(2010.11.8)†V5.83にて対処済み。(原因)未使用メンバーの制御コードをクリアする際、属性値の文字列を解放していなかったため、クリアルーチンの条件から漏れて、そのままデータが残っていた。MIDIコードの内容としてはゼロであったためAメンバーのIDと一致し、Aメンバーの属性と解釈されて譜面モニタ上に表示してしまった。(対処)未使用メンバーを検出した際、属性値の文字列も解放するように修正した。本来Bメンバーの属性値である音量(V60)がAメンバーの音量として表示されてしまう。対応状況(2010.5.29)†V5.82にて対処済み。(原因)新たにデータをロードする際、HEADコマンドの文字列内容を記憶した領域の1文字目をNULL化することでクリアしているが、MIDIエクスポートにおいては、その2文字目から有意な文字として活用しているためクリアされたことが認識できていなかった。(対処)MIDIエクスポートの際、1文字目でHEADコマンドの有無を検出するよう改修した。従来のバージョンでは、HEADコマンドが存在していなくても、シーケンス・トラック・ネームを出力していたが今回の改修に伴い、HEADコマンドが無い場合は、そのレコードの出力そのものを行わないように改善した。障害報告(2010.5.29)†HEADコマンドが存在するデータを一度ロードし、その直後に今度はHEADコマンドの無いデータをロードする。その状態でエクスポートコマンドでMIDIファイルを出力すると、そのMIDIファイルに一回目にロードしたデータのHEADコマンドの内容(文字列)が出力されてしまう。対応状況(2010.4.13)†V5.71にて対処済み。(原因)メンバー情報ウィンドウにて、コントロールを併用したショートカットキーでモーダル系ウィンドウを使用するメニューを選択した場合、そのウィンドウを閉じた時点で、メンバー情報ウィンドウにショートカットキーのアルファベット文字が送信されてしまう。その時点の送信メッセージではコントロールキーの併用を検出する事ができないため、Museアプリケーションは、メンバー情報ウィンドウ自体のキーボードによるメンバーON/OFFとして反応してしまっていた。この障害は、メンバー情報からのメニューショートカット選択をサポートしたV5.30より存在し続けていた。(対処)メンバー情報がキーボードからの文字列を受けた際、その時点のアクティブなウィンドウを検知し、それがメンバー情報ウィンドウ自身で無い場合は、メンバーON/OFF機構を発動しないようにした。※なお、V5.70において、スペースバーやバックスペースなどのキーボード操作における障害も見つかっており、V5.71によってそれらにも対処した。「メンバ情報」がカレントウィンドである状況下で[Ctrl]+oを押下すると、メインウィンド・メニューの[開く]のダイアログが表示される。次に、[ESC]キーにより、[開く]のダイアログを閉じると、O(オー)メンバーの◆が◇(disable)となる。本件は、[エクスポート]や[ドラムの試聴]においても、それぞれEメンバー、Zメンバーで同様の症状が発生する。対応状況(2010.3.11)†V5.62にて対処済み。(原因)微分音長で指定した音長がテンポの関係と相まって極度に短くなり、MIDIのティック値が内部処理上ゼロとなると、出音と止音が同時刻に出力されてしまう。この状況下において、V5.50で施した同時刻内でのノートオフとノートオンの順序入れ替え処理により、出音と止音の順序が反転してしまうため。プした5.50版から現象が発生しているようです。すると出現パターンが変わります。テンポが変わると不都合の出現パターンも変わります。離脱されたままになっていた。(対処)曲頭部分の処理を正常化した。音色で鳴ってしまうと言う症状です。5.47では大丈夫でした。ームエディションです。学校のXPプロフェッショナルでも同じ症状が出ました。対応状況(2010.2.7)†V5.51により対応済み(原因)シークの高速化(演奏開始までの待ち時間短縮)のために、最終的に無効となるコントロールコードを音源に送出しない処理を施しているが、コントロール間で順序関係のあるものに関しては本処理に掛けない様にしている。モノオンとポリオンはそのコントロールに該当するが、プログラム上、高速化処理に該当するコントロールとして扱っていた。(対処)モノオンとポリオンに関しても高速化処理から外す様、プログラムの修正を行った。打ち込みをやっていたところ、奇妙な現象に遭遇しました。オン)で戻した時です。普通に鳴らすと普通に鳴るのですが、途中から鳴らすと...VSCとTimidityで発生、MSGSではドラムでなく普通の楽器でダンパー付ければ発生。オンにならなかったので発生も何もなし。オンが効かず、シンバルが切れます。普通に鳴らすと問題なく演奏しています。途中からの演奏で情報を切り詰める際、最後から見ているような感じですね。メモリの解放を行っているが、中身の無いマクロに関してメモリ開始アドレスと終了アドレスの位置関係が逆転しており、解放時に管理外のメモリにアクセスする状態になっていた。ハング症状が出たり出なかったりする事象は、管理外のメモリ内容がPCの使用環境により偶然NULLであったり有意であったりすることで起こったものと推測される。(対処)マクロの開始終了アドレスをセットする処理部分で中身の無いマクロ状態を認識し、適切な判断材料を記憶する事で上記事態を回避する制御に改めた。muse.iniに127以上の値が書かれていた場合にゼロにすべきところが、7以上の値でゼロにしてしまっていた。(対処)変数と値範囲の関係を、適切な判定文に修正した。前から気になっていたコトをひとつ......。演奏会場の設定画面についてなのですが。対応状況(2009.8.10)†V5.46として対処版をリリース(原因)連符自体にはアルペジオは効かない仕様のため、連符を検出した際アルペジオ指定を無効化していたが、そのため和音内の連符の場合に連符以降の音も無効化されてしまった。(対処)連符検出時のアルペジオ無効化時点でアルペジオ情報を退避させ、和音が完結した時点でそれらの情報を復帰する処理を施した。和音内に連符を記述した場合、連符以降の音にアルペジオ指定が効かない。[dms(<<mfmf>>)<dms>]1:8上記の例では、始めのdmsにはアルペジオが効いているが、連符後の<dms>には効かない。うまく持ち替えられない。Museの不具合として扱い、バージョンアップすることとした。所望のドラムに持ち替える様に、コンパイル・エンジンを書き換えた。ドラムの試聴においても同様の対処を施した。メンバーOをドラムに転向させてドラムセット(2)にします。次にドラムセット(17)に持ち替え(?)更に(2)に戻します。ドラムセットの音は(17)のままなのです。ドラムセット(1)にすればドラムセット(1)の音が発音されているようなのですが・・・。ちなみに音はo2のr(スネア)だけしか確認していませんが。(2)を聞くと(17)のスネアの音が残っているようです。(1)を聞くとリセットされるみたいです。ドラムセット(17)だけでなく(25)も持ち替え出来ない症状が出ました。一度@P1を挿入することでリセットされ(2)に持ち替えることができます。ドラムセットデータV2を送付いたします。対応状況(2008.10.28)†V5.44としてリリース(原因)履歴機構において初期化忘れの変数があった。(対処)正しく初期化した。その直下にマウスで複数の曲を登録していくとセパレータが現れる。対応状況(2008.07.28)†V5.43としてリリース(原因)表示用文字列配列のガード部分に不完全な判定があった。(対処)ガードの不備を改訂した。(自宅PCでは)十中八九落ちてしまいます。{}%*STOP""*STOP""$A{o4c1^1}無論ここまでの使い方をする人はいないと思いますが。ストッパーをかけた方がいいのかな・・・と思います。(2008.07.17)†V5.42としてリリース済み。(原因)ダイアログにおけるコントロール属性のタブグループの設定ミス。(対処)タブグループ属性を正しくセットし直した。(追記)本対応に便乗し、以下の改良を実施した。譜面モニタ行番号検索において、マクロ記述対象の場合、その表示行番号を「展開側」と「定義側」の両方とする。楽器視聴のウィンドウでP121〜P128列にタブで移動し、上下を押していくと...P121で上を押すとおかしな動きをし、P128で下を押しても反応ありませんでした。他の部分と比べると、一貫性に欠けているような気がします。対応状況(2008.07.17)†V5.41にてリリース済み。オーバーフローする時点でエラー処理を施していなかった。(対処)エラー処理を追加した。(追記)本件の対応に伴い、譜面モニタ行番号検索機能の強化も実施する予定。障害報告(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の時より演奏が短くなる。対応状況(2008.07.11)†V5.40にてリリース済み。(原因)今までのプログラムは、調性無視を明に処理しているのは“h”のみであった。全音部分にシフトする場合がある。したがって、“b”も調性を無視する処理を加える必要がある。(対処)以下の処理仕様に改修した。ドイツ音名の場合、音名“b”は調性を無視する。音名“h”はフラット系の調性を無視する。少ないと想定され、現実的には問題がないと判断している。本件はあくまでもバグの対処であるため、積極的に互換性を崩す仕様変更ではない。扱いに関しての質問です。対応状況(2008.06.14)†V5.37にて対応済み。送信効率を高める様にリバーブ・コーラスを1つのエクスクルーシブにまとめていた。この送信方法は他の音源ではうまく機能していたが、MU90Bにおいては動作しないことが判明した。具体的には、以下の条件でMU90B側が動作不良(ハング)となる模様。上述の1つのエクスクルーシブ送信を実現するために、(36h)にもダミーで常にゼロをセットし送信していた。結果として、上記の動作不良条件を満たすことになった。(対処)リバーブとコーラスの指定を分離し、更にリバーブに関しては(35h)までのデータと(37h)データを別々に送信するよう改訂。コーラス内の一連のデータは従来通りまとめて送信させた。今回の改訂内容を、*DATAコマンドで表現すると以下のようになる。<従来>*DATA"41,10,42,12,(40,01,30,r1,r2,r3,r4,r5,r6,00,r8,q1,q2,q3,q4,q5,q6,q7,q8)"<今回>*DATA"41,10,42,12,(40,01,30,r1,r2,r3,r4,r5,r6)"*DATA"41,10,42,12,(40,01,37,r8)"*DATA"41,10,42,12,(40,01,38,q1,q2,q3,q4,q5,q6,q7,q8)"MU90Bにおいても、今回の方式で正常動作することを確認済み。(追記)本件の対処の際、以下の仕様が機能しないという潜在バグを発見したため改修した。曲によって演奏されるものとされないものとがありました(汗)自分なりに調べたところ、「ある時期」を境に古いデータはちゃんと演奏され新しいものは演奏されないことに気づきました。演奏されないようなのです。リセットを入れた2曲だけは、演奏できることにも気づきました。それまで演奏できなかったデータがちゃんと演奏されました。コマンド記述の行をコメントアウトするとやはり演奏できます。f7hというエクスクルーシブがはき出されていました。