[[FrontPage]]
#contents
*(V6.26)曲頭付近のペダルオフ(Y0)が出力されない場合がある [#d2902aac]
**状況(2012.11.18) [#ea21165c]
V6.27にて対応済み。~
(原因)~
Museは演奏時のモタレを抑止するため、極力無駄なMIDIコマンドを音源に送信しないようにしている。~
例えばペダルに関しては、直前にY0が指定されていた場合、続いてY0を指定してもカットされる。~
ペダルの初期値はY0であるため、初めに検出したY0はカットされるというシーケンスになっていた。~
しかし本件の様な記述の場合、実際の演奏時には先にY1が発行されるため、Y0をカットしてはいけない。~
(対処)~
１パス目の読込みではY0カットせず、後処理で実施している“連続する同値のコントロール(それはYに限らず)のカット処理(後送をカット)”~
に縮退効果を委ねることにした。ただしこの対応では、演奏冒頭のY0指定をカットせず、すべからく音源に送信してしまう。~
１パス目で先読みの処理を行えば理想的対応は可能だが、処理速度の低下を招く恐れがあるため~
冒頭のY0カットは行わないことを制約として本対処を採用する。~
~
改めて考察してみると~
他のコントロールコードも音源の初期値が明確でないことから、~
初回のコマンドはカットしないようにしているため、~
今回の仕様で、より全体の整合が図られたとも言える。~
**概要(2012.11.18) [#ndd3bd78]
例えば以下のデータで
#A0| d4r @Y0 mf
#A1| @Y1 _1
フィンガー #A0 の Y0 が発行されないのは仕様でしょうか？
*(V6.26)MARK文字列がテキストエリアに表示されない場合がある [#a6dc89ca]
**状況(2012.11.24) [#l4a87ce0]
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文の内容)を、別の手段(デバッグライトなど)で表示させた場合、~
現象が起こっている際にも正しく表示されることから~
単純なメモリ破壊などの問題ではない。~
過去のバージョンをVS2005でビルドし直し、WinXPで再現テストを実施した。~
V5.70のバージョン以前は、テキスト文字列の記憶域を１バイト多く取り、~
それを文字列区分(TEXT/MARK/SOTP)のフラグとして利用していたため、~
再現データのパラメータの方を１文字減らしてみた。
これにより、同様の症状が出ることを確認した。~
~
こうしてバージョンを遡っていくと、~
結果としてソースコードが現存しているV3.1においても症状が出ることが確認できた。~
極めて基本的な部分に真因があることが予想される。~
**概要(2012.11.11) [#y7556a79]
●(2012/11/11) 21:33 ＜himajin925さん＞
Ver6.26 にアップしました。
いろいろやってみたんですが、
（１）譜面モニタをメインウィンドと同じ幅、４／４表示にして、
（２）小節線１１０〜１１３がモニタの左端に来るようにして
（３）小節線の左で右クリック
→２．戦いの…が鍵盤上部に表示されない
ようです。
画像を上げておきました。
#ref(MARK1.jpg)
画像を見てもらえたようですので、この現象がおきることがある、
のは分かっていただいたと思います（指揮棒カーソルは２．を過ぎているが、鍵盤の上は１．のまま）
私のところでも、同じ条件で毎回起きるわけでもないようで、？？です。
ただ、画像の場所で右クリック、２．戦いの…が表示されたら、また右クリック、
と数回やっていると高い確率で発生するようになる、らしいのですが、
初回でも起きる場合があるし、何回も起きない場合があるし、ってまったく？？です。
まったく困ってはいないのですが(^.^)
もっと前から（先頭からも？）演奏した場合も同様の場合があるようですが、
再現しない場合もあって、やはりよく分かりません。
（２）の場所が条件なのかもまったく？です（たぶん条件ではないのでしょう）
●(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を動かした時では発生しませんでした。
#ref(MARK2.png)
●(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さんのご指摘の通り、演奏時点での症状から追跡するのを止めて、~
データロード時点の不具合を追跡してみようと思います。~
[8450]で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 ＜開発者＞ ~
経過報告です。~
＞ [8450]で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) 02:20 ＜Elekenさん＞
あまり自信はないですが、
複雑なデータをロードした後の状態が、ヒープの断片化を起こしていて、
リロードした後、テキスト構文のメモリ確保の段階で
末尾に丁度 32 バイト分の空きがあるヒープ断片が存在して、
VS2005 の malloc がそこを優先的に割り当ててしまうということなのでしょうか。
もしカーネルのバグだとすると、それ以外のライブラリは全て仕様内の動作をしているので、解決策は
・SendMessage で送信する文字列の NULL 終端 の次のバイトがヒープの外にならないようにする
という一点で、そのためには、
(1) 文字列領域は 1 バイト多く確保する
(2) 別に用意したヒープ末尾でないバッファに文字列を一旦コピーして、それを SendMessage する
(3) ヒープ断片化が起こらないように、ヒープは自分で管理する。リロードの度に HeapDestroy -> HeapCreate
…のどれかをとればいいように思います。
*(V6.25)演奏会場の設定で[COPY]押下するとクリップボード末尾に不正文字が付く場合がある [#w42c4af9]
**状況(2012.10.25) [#s67717d5]
V6.26にて対応済み。~
(原因)~
V6.10より音源メニューにおける各音源のバージョン表示を撤廃したが、~
その際、演奏会場の設定ダイアログからの変数削除が完全でなかったため、~
初期化されていない文字列を添加して、クリップボードに出力していた。~
(対処)~
バージョン表示に関する不要な変数を完全に削除し、クリップボード出力の際に、~
それを添加しないようにした。~
(補足)~
本障害対応とは別件であるが、利用ＯＳによって切り分ける処理を施し、~
テキスト表示エリアの背景色は、極力メニューバーの配色と等しいデフォルト色を~
採用するよう工夫した。~
**概要(2012.10.24) [#n38ad6b3]
演奏会場の設定ダイアログにて[COPY]ボタンを押下すると、現在選択されている~
演奏会場設定のMuse文法記述がクリップボードに出力される仕様であるが、~
その際、出力された文字列の末尾にゴミが付いてしまう。
*(V6.24)楽譜スルーを指定するとセミコロンのコメントで文法エラーになる場合がある [#o37cc339]
**状況(2012.09.23) [#ff4350aa]
V6.25にて対応済み。~
(原因)~
LilyPondに対応する前は、マクロ記述直後にダブルコーテーションを記述すると~
文法エラーとなるため、何の考慮もせずに次の文字処理に移行させていた。~
V6.2より、楽譜スルー指定の新設によりダブルコーテーションもコマンドの先頭を~
識別するデリミッタ文字となったが、上記の処理シーケンスに手を加えることを~
失念していた。そのため、ダブルコーテーションの内外判定で不整合を生じた。~
(対処)~
マクロ終了時に、デリミッタとしてダブルコーテーションを検出した際~
フリップフロップのフラグを立てて処理を継続するように改修した。~
**概要(2012.09.23) [#w7444ded]
Muse V6.24 において、
${macro} "r4" d4 ;
$macro{}
が、「d4; が記述ミス」というエラーを発生させます。
ちなみに、行末のセミコロンを削除した
${macro} "r4" d4
$macro{}
は正常に動作します。
*(V6.23)移調楽器yでパラメータ省略すると、PDF出力楽譜の音程が狂う [#oac0b972]
**状況(2012.09.13) [#o37bb18f]
V6.24にて対応済み。~
(原因)~
移調楽器コマンドでパラメータが省略された際に、メンバー属性値を採用する処理が欠落していた。~
(対処)~
省略時にメンバー属性値を採用する処理を追加した。~
(補足)~
V6.24より、muse.exeのプロパティに版権やバージョンをセットすることとした。~
**概要(2012.09.13) [#ibb780d2]
例えば、y+++ や y/+5 といった形式で、移調楽器のパラメータ(調性や移調)を省略すると、~
PDFに出力した楽譜の音符が、極度の低音側に記譜されるなど乱れた状態になる。~
ただし、演奏は正しく行われている。~
*(V6.22)同時刻内のＯＮ／ＯＦＦノート整列処理がうまく効かない場合がある [#m39237d7]
**状況(2012.09.02) [#ce9752e2]
V6.23にて対応済み。~
(原因)~
タイ(＆)による音符の統合処理の際、OFFからONへのポインタを更新していないにもかかわらず、~
同時刻内の整列処理において、そのポインタを参照して条件判定を実施していた。~
そのため、統合処理で除去されシステム上不定状態となったノートの値を参照することとなり、~
レアケースでの不具合が生じることとなった。~
(対処)~
OFFとONのノート間を双方向ポインタに強化すると共に、統合処理の際にリアルタイムに更新し、~
整列処理に影響を与えないようにした。~
また整列処理の条件も見直し、強弱ゼロ(v0)の音符に対してより効果的な順序変更を施すようにした。~
**概要(2012.08.31) [#bd2f3bdc]
V5.5より同時刻内のＯＦＦノートを前方に、ＯＮノートを後方に整列させる処理を組み込んでいるが、~
その処理が(非常にレアケースではあるが)、機能しない場合があった。~
*(V6.21)Windowsの古いOS(Win95/98/Me)で起動しない [#d7d4055c]
**状況(2012.09.01) [#y2f72db7]
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) [#dff9bf90]
V6.20からWindowsの旧バージョン(いまだにWindows Meですが...)対応されなくなったんですね。~
起動時に「...新しいバージョンのWindowsが必要です...」~
のメッセージが表示され起動できませんでした。~
*(V6.20)未定義の起動パラメータ文字を指定するとシステムエラーのダイアログが出現する [#tbbdaf45]
**状況(2012.08.19) [#tc87074b]
V6.21にて対処済み。~
~
(原因)~
従来から内包していた潜在バグ。~
オプション文字の解析をする際、未定義文字を検出した場合の脱出条件にミスがあった。~
具体的には、文字のデリミッタ到達で判定するところを、文字アドレスがNULLであるかの判定をしていた。~
なおMuse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更した。~
従来不運にも症状が出なかったのは、コンパイル結果の実行モジュールにおけるメモリ管理方式の差異と考えられる。~
(対処)~
正しい脱出をするように改修した。~
(補足)~
今回の改修に伴い、オプションの列挙記述も可能とした。~
**概要(2012.08.19) [#p52afc5b]
(その１)~
従来のショートカットのままMuseを起動したところ、エラーが出るようになりました。
v6.1までは発生しないエラーです。
---------------------------
〈Muse〉システム状況
---------------------------
ファイルがオープンできません
\\hoge\muse\-$
---------------------------
(その２)~
不正なコマンドライン文字列を与えると、長時間ハングした後にエラーを返す。
数十秒ハングした後、意味不明なエラーを返すので、是非改善すべきかと思います。
*(V6.20)初期化ファイル(muse.ini)に指定したテキスト背景色が正しく反映しない [#t6750463]
**状況(2012.08.19) [#r967a343]
V6.21にて対処済み。~
~
(原因)~
Muse(V6.20)より、Museのビルド環境をVC++6.0からVS2008に変更した。~
そのコンパイル処理の差でsscanf()関数の書式指定の処理仕様に変更が生じた模様。~
１６進文字を数値に変換する際に正しい結果が得られなくなった。~
(対処)~
sscanf()ではなく、strtol()を利用することで回避した。~
(補足)~
今回の改修を機に、ソース内のすべてのsscanf()をstrtol()に変更した。~
これにより、muse.exeのサイズが(極僅かではあるが)コンパクト化するという副次効果を得た。~
**概要(2012.08.19) [#v35c7f3b]
テキストエリア背景色の設定が反映されない。~
muse.ini に TCL パラメータを指定したとき、赤成分が無視され、常に 0 と見做されるように見えます。~
*(V6.02)途中再生で演奏を開始すると各種コントロール指定が無効になってしまう [#oe14d2e4]
**状況(2011.11.26) [#oe285c35]
V6.03にて対処済み。~
~
(原因)~
途中再生からの演奏開始指定において、そこまでのコントロール属性をそれ以降の演奏に反映させるため~
時系列に内容をバッファリングし、最終的なコントロール属性のみを音源に送信する機構を組み込んでいる。~
それらの送信は演奏開始の冒頭で、短時間に一気に実施される訳であるが、~
特にプログラムチェンジ(楽器指定)コマンドは、音源側での処理に時間がかかるため、~
高い密度でコマンドを送信すると処理渋滞が発生し、その後に続くコマンドの処理に欠落が生じてしまう。~
(対処)~
プログラムチェンジの送信に関しては、一定のインターバルを与えて送信するように改修した。~
(補足)~
なお本件とは直接関係は無いが、今回のマナーアップにて、Windows7向けのUI改善も施した。~
・ウィンドウ移動におけるディスプレイの四隅フィッティングの調整~
・デフォルトのMuseカーソルの形状変更~
・デフォルトのテキストエリア背景色の変更~
・メインウィンドウのシークバー上下マージンの調整~
・ドラムの試聴におけるドラムセット選択ボタンを標準化~
**概要(2011.11.18) [#x44d092c]
・メンバー属性の一部（特にV指定）が無視されている。（恐らく初期設定のV127になっている）~
・V指定について遅延命令が有効にならず、階段状に音量が変化する。~
・特定メンバーのS指定が無効になって0になっている。~
・特定メンバーのバンクセレクト(/8)が無効になっている。~
・途中再生で症状が発生し、最初から演奏すると正常な動作を見せる。~
・正常に演奏する場合もある。~
・音源としてSC-88proを使った場合のみに再現される。（MSGS、Timidity+では再現されず）~
なお、W=、R=、Q=の頻用が原因と思われたため、それらを制御していたフィンガーを~
全てコメントアウトすることで症状が抑制するも、やはり時々同じ症状が出た。~
そこで該当フィンガーに絞らず、データ内すべてのW=、R=、Q=指定をコメントアウトしたところ、症状は大幅に抑制された。~
*(V6.01)メニューのプルダウンを出した状態で譜面モニタをクリックすると小節線の表示が切り替わってしまう [#k2415381]
**状況(2011.10.17) [#jdd3305e]
V6.02にて対処済み。~
~
(原因)~
譜面モニタ上のマウスカーソルの位置はリアルタイムに検出し、そのエリアに応じてカーソル形状を変更している。~
その処理に伴って、検出したエリアIDを記憶しておき、マウスクリックが起こった際にエリアIDを参考に処理分類を行っている。~
しかし、マウスが譜面モニタのクライアント領域から外れた際、そのエリアIDをクリアしていなかったため~
メニュープルダウンでのフック状態から復帰した際に、直前のエリアIDに呼応する処理が発動されてしまった。~
(対処)~
マウスが譜面モニタから外れた際、エリアIDをクリアする処理を追加した。~
**概要(2011.10.08) [#ycec2281]
Museの不具合(?)だと思うのですが、~
譜面モニタを開いた状態で、一度「ファイル(F)」などがあるところを開き、~
「開く(O)」などを選択したり、閉じたりせずに譜面モニタをクリックすると、~
勝手に小節などの縦の線が消えてしまいます。~
同様のことを繰り返すと、また出てくるので、モニタの下の部分をクリックしたようになるのです。~
動画を撮りました。
#ref(claw.mpg)
*(V6.00)マクロでＸ遅延を利用すると２回目以降の再現で遅延が効かない [#c5447938]
**状況(2011.07.10) [#p0775c41]
V6.01にて対処済み。~
~
(原因)~
Museコンパイルモジュールにて、遅延のコロンを一時的にNULLに置き換えて文法解析しているが、~
その復帰をエラー時のみに実施していたため、正常系でコロンがNULLのままになっていた。~
マクロを使用しない場合は支障は実用上の無いが、マクロ利用の場合はその文字列空間を再利用しているため、~
２回目以降はコロンが無くなったままになり、遅延指定が成されていないという解釈ミスが生じた。~
~
(対処)~
必要な解析が完了した時点で、文法エラー検出以前に直ぐにコロンを復帰するよう改修した。~
~
**概要(2011.07.10) [#ycec2281]
以下のデータでおかしな演奏になります。~
#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)ドラムメンバーに移調楽器コマンドを指定するとエラーとなってしまう [#h9ae071a]
**状況(2011.07.05) [#ydb0deb1]
V6.00にて対処済み。~
~
(原因)~
移調楽器コマンド'y'は、それがドラムメンバーに指定された場合、~
「エラーとはならないが、その指定は無視される」という仕様であるにもかかわらず~
エラー判定を実施していた。~
~
(対処)~
エラー判定を外した。~
~
**概要(2011.07.02) [#zaf041f8]
転調を頻繁に行うデータを作っているのですが、困ったことが…~
ドラムにまで判定を出してしまっているようです。~
#Z0@ P17
*FING "y"
#Z1 o2rrrr
でエラーになります。ちなみに、~
@Z P17
*FING "y"
#Z1 o2rrrr
では、Zフィンガーがまだ登場していないのでエラーになりませんが、~
@Z P17
#Z1 o2rrrr
*FING "y"
はダメでした。~
~
*(V5.92)演奏状態でシークした際、曲が残っているのに演奏を停止してしまう場合がある [#x323c16c]
**状況(2011.07.05) [#vee1994d]
V6.00にて対処済み。~
~
(原因)~
左右矢印キーやシークボタンなどでスライドバーを移動させた際、~
つまみがシークバーの右端座標に達したかどうかを曲尾到達の判定に利用していた。~
そのため、MARK文前半に対して後半の演奏時間が極端に短い場合、~
後半の演奏が残されているにもかかわらず曲尾に到達したと判断された。~
これは、MARK文前後の演奏時間の差があまりに大きいため、~
後半のシークバーのドット数幅が１以下（実質ゼロ）になってしまうためである。~
~
(対処)~
曲尾到達の判定にシークバーの位置を利用することを止め、~
内部的に処理している演奏時間を参考に判断することにした。~
~
**概要(2011.06.26) [#aefdb7de]
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(ポルタメント)指定が反映されない [#v950530c]
**状況(2011.05.12) [#xff86bc6]
V5.92にて対処済み。~
~
(原因)~
V5.34からV5.35へのマイナーバージョンアップにてシーク高速化処理を施した。~
その一環としてシーク時に出力しても意味のないコントロールを音源に送信しない処理を組み込んだが、~
その対象にポルタメントおよびポルタメントコントローラを挙げてしまった。~
~
(対処)~
シークの際に必要最低限のポルタメント関係のコントロールを送信するよう変更した。~
~
**概要(2011.05.09) [#tc06ae6e]
X65（ポルタメント）についてです。
ポルタメントは、"X65=127" のように指定しますが、他のX指定と異なり、~
この指定は途中再生に上手く対応していないように思います。~
演奏中に"X65=127" の位置を通るとポルタメント状態になりますが、~
その位置より後から途中再生すると、ポルタメント指定が行われていないかのような
状態で演奏されてしまいます。~
これについて、S-YXG50 と MU1000 の音源で確認しましたが、~
VSCのような他の音源で同じ現象が再現されるかどうかは確認していません。~
（ポルタメントは音源によって扱いが異なる場合があるようです）~
Windows XP 上で確認しました。~
~
*(V5.91)HEAD文字列に指定したフォントが反映されない場合がある [#pa1d7c85]
**状況(2011.05.12) [#sfc5dd59]
V5.92にて対処済み。~
~
(原因)~
V5.23からV5.24へのマイナーバージョンアップにてシーク高速化処理を施した。~
その開発途上でシークポイントまでテキスト表示が存在しない場合に~
フォント切り替えを実施する処理を組み込んだが、結果的にそれが不要になるシーケンスに落ち着いた。~
しかるに、開発途上でのフォント切り替え処置の削除をし忘れていた。~
~
(対処)~
フォント切り替え処置の削除を行った。~
~
**概要(2011.05.09) [#y211b962]
HEADタグのフォントの件です。~
通常HEADタグは、それ以前に書かれたFONTタグで指定されたフォントで描画されると思います。~
ところが、HEADタグの後にFONTタグがある場合、再生位置がそのFONTタグの位置の後にある状態で~
Muse のウィンドウを他のウィンドウで隠し、再び Muse のウィンドウを表示させると、~
HEADタグより後で指定したフォントで再描画されてしまいます。~
Windows XP 上で確認しました。~
~
*(V5.90)MARKに位置決めして演奏を開始すると、出だしの音が発音されない [#fb52c104]
**状況(2011.05.06) [#z8d2d40c]
V5.91にて対処済み。~
~
(原因)~
V5.90にて、文字列描画による演奏のモタレを軽減するため、~
同時刻内のノートONの後にテキスト表示イベントを移動する処理を施したが、~
テキスト表示イベントの一種であるMARKコマンドの場合、~
ノートONが発行された後にその位置で停止する状況に陥り、~
MARKから演奏を開始すると出だしの音が発音されたくなった。~
~
(対処)~
MARKコマンドは並べ替えの処理を行わず、~
モタレ軽減の処理は、TEXTコマンドのみを対象とする様、修正した。~
STOPコマンドに関してはV5.90においても本考慮が成されていたため、~
MARKもSTOPと同等の処理とした。
具体的には、MARKやSTOPを検出した際は、~
同時刻であっても異時刻に変化した場合と同じ扱いとした。~
~
**概要(2011.04.29) [#m9f3dad8]
早々で申し訳ありませんがマーキング(*MARK)にジャンプさせたときに~
MARK直後の発音が飛ばされるようなのですが...。~
分かりやすいのは、開発者様の「交響曲第７番（ベートーベン）」を読込んで~
第２楽章にスライダーを右にジャンプさせると第２楽章最初の和音がとんでしまいます。~
*(V5.90)メニュー「データ編集」が正しく機能しない[#r12e3721]
**状況(2011.05.06) [#b3abaf2c]
V5.91にて対処済み。~
~
(原因)~
V5.90にて、バッチ処理モードの際の高速化のために処理の入れ替えを行った際、~
データ編集のためのエディタパスを管理する変数の初期化手順が狂ってしまった。~
~
(対処)~
正しい手順に修正した。~
**概要(2011.04.27) [#j8ed6ec8]
museのver5.9ダウンロードさせていたたぎました~
しかし、データ編集を押すとテキストドキュメント(メモ帳)ではなく、~
それが入ってるフォルダ(?)が出てきます~
前まではちゃんとメモ帳だったと思うのですが、、、~
~
*(V5.87)ＰＣ起動初回で演奏のモタレが生じる場合がある [#pba52f97]
**状況(2011.03.05) [#n4308b61]
V5.88にて対処済み。~
~
(原因)~
バックグランドで処理が走っている場合などの環境下でMuseが初出現のフォントをロードする際~
その処理に時間が掛かるため、演奏がモタレてしまう場合がある。~
(対処)~
Museデータのロード直後に、そのデータに使用されているフォント使って１回ダミー描画し、~
演奏開始時点で初回のフォント読込みを終えている状態とした。~
~
**概要(2010.11.02) [#e6d71198]
私が Musing したデータを Muse で再生すると、曲頭の数音が時間的に詰まって鳴る場合があります。~
パソコン起動後初回に起動した Muse で初回再生の場合には必ずそうなります。~
~
実行環境として、~
・rsync
・cp （cygwin のコピーコマンド）
・Windows のバックアップコマンド
にて、以下のデータを演奏させると、~
*FONT "Times New Roman"
_1d2d *TEXT "" dd
前半２つのドの音と後半２つのドの音との間でモタレが起こります。~
すなわち、TEXTコマンドの位置で遅延が生じます。
*(V5.86)Timidity++で演奏させた後、MIDIマッパーに切り替えて演奏させると落ちる [#jff27456]
**状況(2011.02.04) [#yc449f17]
V5.87にて対処済み。~
~
(原因)~
エクスクルーシブ・メッセージを送信した後、MIDI音源がその処理を完了したタイミングで、
アプリケーション側が用意したバッファを解除する必要があるが、
従来のMuseはその解除タイミングを得るために音源側から発信されるコールバックを活用していた。
Timidity++以外のドライバは、音源処理完了時点でこのコールバックを
アプリケーション側に投げてくれたため、正常な解除処理が行われていた。
しかし、Timidity++ドライバでは何故かそのメッセージを投げてくれないため、
前回のバッファが解除されていない状況で、
次に続くエクスクルーシブ・メッセージを処理する状況となり、
システム上の不整合が生じてハングアップに至る。~
(対処)~
エクスクルーシブ・メッセージを音源に送信した後、
バッファのデータヘッダー要素である状態フラグの監視ループに入り、
その値が完了になった時点でループを抜け出すというシーケンスに改めた。
一種のポーリングではあるが、この方式はコールバックに依存しないため
確実なバッファの解除が実施できると判断した。
また、MIDI音源オープン時にコールバックの定義をする必要が無くなり、
イベントに関する処理負荷も低減させることができたと推測している。~
~
※なお、本件とは直接関わりは無いが、V5.87のバージョンアップにおいて、
Readme.txtの改訂も実施した。
具体的には、利用頻度の高いものを極力早めに解説するという方針の基に
“第２章 Ｍｕｓｅコーディングの手引き”における節立てを組み直した。~
~
**概要(2011.02.01) [#r15c1c31]
(1)Timidity++をインストールし、Museのメニューの「音源(V)」に
Timidity++ Driverが追加された状態にしておく。~
~
(2)Museで“Timidity++ Driver”を音源として選択し、任意データを数秒演奏させる。~
~
(3)音源メニューから“Microsoft MIDIマッパー”に切り替える。~
~
(4)この状態で再び演奏を開始しようとすると、Museがフリーズ状態になった後、
しばらくして落ちる。~
*(V5.85)マクロに関するエラー表示が必要以上に出現する [#wea4fa54]
**状況(2011.01.26) [#g2c02a01]
V5.86にて対処済み。~
~
(原因)~
前回の不具合対応時に、マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施したが、~
その際、マクロ再帰処理に入る前のエラー制御変数の初期化が漏れていた。~
そのため、一番初めに検出したマクロ（エラーがあろうと無かろうと）をエラーの候補として扱ってしまい~
実際にどこか別の場所にエラーがある際に、そこもエラー表示してしまうという不具合を起こしていた。~
~
(対処)~
エラー制御変数の初期化を確実に実施するよう改善した。~
~
**概要(2011.01.21) [#w1b9ddc3]
定義マクロ、$Syn2_0{・・・}を記述せず、Ｘ行目にその展開マクロ${Syn2_0}を記述すると、~
Museはマクロが未定義であるという文法エラーを検出するはずです。~
しかし、このエラーとは直接関係のない以下のエラー表示が出現してしまいます。~
~
(MUSE)文法エラー
対応する定義マクロがありません。
Ｙ行目 → $MC-G1_01
この際、Ｙ行目に関わるマクロには文法的なエラーは存在しません。~
そして［ＯＫ］を押下して上記のエラー表示を閉じると、この段階ではじめて以下の正当なエラー表示が出ます。~
~
(MUSE)文法エラー
対応する定義マクロがありません。
Ｘ行目 → ${Syn2_0}
~
つまり、Ｘ行目にエラーがあると何故かＹ行目がエラーとして検出されてしまいます。~
Ｘ行目のエラーを解決すると、Ｙ行目のエラー表示も出なくなります。~
*(V5.84)マクロ記述されたコマンドが実行されない場合がある [#nde459ba]
**状況(2011.01.19) [#p0c9cbcb]
V5.85にて対処済み。~
~
(原因)~
従前の処理シーケンスは、データに一度だけ記述するタイプのコマンド重複チェックを、~
マクロ展開処理よりも前に実施しており、しかも無名マクロの展開部ではそのコマンドの~
展開を実施していなかった。しかし当初の仕様では、マクロの繰返し数にゼロ指定が~
出来無かったため、定義部は必ず実行されるという前提を置くことができるため~
演奏データとしては矛盾無く翻訳できた。~
更にこの仕様で無名マクロを利用した場合、重複チェックに掛からない状況であったが、~
定義部と展開部が必ず同一の指定となるため、２つの指定が競合することはなく、~
事実上の問題は無いと判断していた。~
~
しかるにゼロ指定を可能としたV5.3以降、定義部でも展開部でもコマンド認識をしない状況が生じ、~
今回の症状が出現するに至った。~
~
(対処)~
マクロ展開を処理しながらコマンド重複チェックも並行するシーケンスに変更する事で、~
マクロ内に記述されたコマンドを正しく展開解析し、重複チェックも厳密に行うようにした。~
なおドラムに関しては、移調(T)および音部記号(?)を無効化する仕様を実現するため、~
マクロ展開処理に先行してドラムコマンドの存在を決定する処置も施した。~
~
**概要(2011.01.02) [#hda326a8]
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)譜面モニタの右クリック・リロードで、指揮棒カーソルが２つ出現してしまう場合がある [#n1f590c3]
**状況(2010.12.23) [#bc2c986c]
V5.84にて対処済み。~
~
(原因)~
譜面モニタがアクティブ状態で右クリックする場合と、非アクティブの状態で右クリックする場合とで~
リライトのイベントと演奏開始イベントの順序が異なり、後者を先に受信した場合に~
排他的論理和で描画している指揮棒カーソルの表示が乱れていた。~
~
(対処)~
右クリック・リロードの際、演奏開始直前で強制的に最描画のアップデートコマンドを送信することで、~
イベントの順序関係を調整し、表示が乱れないように対処した。~
~
**概要(2010.12.20) [#xb73973c]
譜面モニタが非アクティブなウィンドウ状態にある際、右クリックでリロードしようとすると~
そのクリック位置で指揮棒カーソルが２度描画され、クリック位置に指揮棒カーソルの残像が出現する。~
演奏および指揮棒カーソルの動作は正常であり、リライトすると残像も消える。~
*(V5.82)譜面モニタ属性表示にて、未使用メンバの属性が誤って表示される場合がある [#ra6c2606]
**状況(2010.11.8) [#bc2c986c]
V5.83にて対処済み。~
~
(原因)~
未使用メンバーの制御コードをクリアする際、属性値の文字列を解放していなかったため、クリアルーチンの条件から漏れて、そのままデータが残っていた。
MIDIコードの内容としてはゼロであったためＡメンバーのＩＤと一致し、Ａメンバーの属性と解釈されて譜面モニタ上に表示してしまった。~
~
(対処)~
未使用メンバーを検出した際、属性値の文字列も解放するように修正した。~
~
**概要(2010.11.6) [#xb73973c]
以下の様なコーディングをした場合に、譜面モニタでＡメンバーの音量属性(V)を表示させると、~
本来Ｂメンバーの属性値である音量(V60)がＡメンバーの音量として表示されてしまう。
@B V60
#A0 d r m
*(V5.81)MIDIエクスポートにて直前にロードしたHEAD内容が出力されてしまう場合がある [#y22b76ad]
**状況(2010.5.29) [#y3b940bf]
V5.82にて対処済み。~
~
(原因)~
新たにデータをロードする際、HEADコマンドの文字列内容を記憶した領域の１文字目をNULL化することでクリアしているが、~
MIDIエクスポートにおいては、その２文字目から有意な文字として活用しているためクリアされたことが認識できていなかった。~
~
(対処)~
MIDIエクスポートの際、１文字目でHEADコマンドの有無を検出するよう改修した。~
また従来のバージョンでは、HEADコマンドが存在していなくても、シーケンス・トラック・ネームを出力していたが~
今回の改修に伴い、HEADコマンドが無い場合は、そのレコードの出力そのものを行わないように改善した。~
~
**概要(2010.5.29) [#fc92833c]
HEADコマンドが存在するデータを一度ロードし、その直後に今度はHEADコマンドの無いデータをロードする。~
その状態でエクスポートコマンドでMIDIファイルを出力すると、そのMIDIファイルに一回目にロードした~
データのHEADコマンドの内容(文字列)が出力されてしまう。
*(V5.70)ショートカットでメニュー選択するとメンバーがＯＦＦになってしまう場合がある [#zeeea9b6]
**状況(2010.4.13) [#y3b940bf]
V5.71にて対処済み。~
~
(原因)~
メンバー情報ウィンドウにて、コントロールを併用したショートカットキーでモーダル系ウィンドウを使用するメニューを選択した場合、~
そのウィンドウを閉じた時点で、メンバー情報ウィンドウにショートカットキーのアルファベット文字が送信されてしまう。~
しかも、その時点の送信メッセージではコントロールキーの併用を検出する事ができないため、~
Museアプリケーションは、メンバー情報ウィンドウ自体のキーボードによるメンバーＯＮ／ＯＦＦとして反応してしまっていた。~
なおこの障害は、メンバー情報からのメニューショートカット選択をサポートしたV5.30より存在し続けていた。~
~
(対処)~
メンバー情報がキーボードからの文字列を受けた際、その時点のアクティブなウィンドウを検知し、~
それがメンバー情報ウィンドウ自身で無い場合は、メンバーＯＮ／ＯＦＦ機構を発動しないようにした。~
~
※なお、V5.70において、スペースバーやバックスペースなどのキーボード操作における障害も見つかっており、~
V5.71によってそれらにも対処した。
~
**概要(2010.4.13) [#fc92833c]
「メンバ情報」がカレントウィンドである状況下で[Ctrl]+oを押下すると、メインウィンド・メニューの［開く］のダイアログが表示される。~
次に、[ESC]キーにより、［開く］のダイアログを閉じると、O(オー)メンバーの◆が◇(disable)となる。~
本件は、［エクスポート］や［ドラムの試聴］においても、それぞれＥメンバー、Ｚメンバーで同様の症状が発生する。~
*(V5.61)微分音長を使うと鍵盤の色が残ったまま音が鳴りっ放しになる場合がある [#ybfa7781]
**状況(2010.3.11) [#c6e1f997]
V5.62にて対処済み。~
~
(原因)~
微分音長で指定した音長がテンポの関係と相まって極度に短くなり、~
MIDIのティック値が内部処理上ゼロとなると、出音と止音が同時刻に出力されてしまう。~
この状況下において、V5.50で施した同時刻内でのノートオフとノートオンの~
順序入れ替え処理により、出音と止音の順序が反転してしまうため。~
~
(対処)~
１つの音符により発生した出音と止音が同時刻に存在していた場合、~
その状況下で生成されたノートオンとノートオフは、~
論理的には異なる時刻に存在すると解釈することで、~
順序入れ替えの処理を行わなず、次の処理ステップに移行するように修正。~
~
**概要(2010.3.9) [#ad2d54d6]
発見したのは最新版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)楽器の指定が反映されない場合がある [#x5201abf]
**状況(2010.2.9) [#c6e1f997]
V5.52により対応済み~
~
(原因)~
V5.50で施した同時刻内でのノートオフおよびノートオンの順序入れ替え処理において、
曲頭での特殊処理にミスがあったため、冒頭部分のコントロールが演奏リストから
離脱されたままになっていた。
~
(対処)~
曲頭部分の処理を正常化した。
**概要(2010.2.8) [#ad2d54d6]
バグらしき？ものの報告：添付したファイルStorymus.txtをmuse5.50や5.51で演奏しよ
うとするとメンバーごとに楽器指定をしてあるにもかかわらず、全てのメンバーがピア
ノの音色で鳴ってしまうと言う症状です。5.47では大丈夫でした。私の使用環境はXPホ
ームエディションです。学校のXPプロフェッショナルでも同じ症状が出ました。
#A0 dms
#B0 @P49 msc
#C0 @P57 <msc>
#D0 @P26 <<msc>>
*(V5.50)途中から再生(シーク)させると正しく演奏されない場合がある [#p47df2a0]
**状況(2010.2.7) [#sc3a94ae]
V5.51により対応済み~
~
(原因)~
シークの高速化(演奏開始までの待ち時間短縮)のために、最終的に無効となるコントロールコードを音源に送出しない処理を施しているが、コントロール間で順序関係のあるものに関しては本処理に掛けない様にしている。モノオンとポリオンはそのコントロールに該当するが、プログラム上、高速化処理に該当するコントロールとして扱っていた。
~
(対処)~
モノオンとポリオンに関しても高速化処理から外す様、プログラムの修正を行った。
**概要(2010.2.7) [#hc7ba3f6]
打ち込みをやっていたところ、奇妙な現象に遭遇しました。
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)中身の無いマクロを記述するとハングする場合がある [#v23f76b6]
**状況(2010.1.9) [#nc920eec]
V5.50により対応済み~
~
(原因)マクロの解析処理において、展開作業終了後作業用メモリの解放を行っているが、中身の無いマクロに関してメモリ開始アドレスと終了アドレスの位置関係が逆転しており、解放時に管理外のメモリにアクセスする状態になっていた。~
ハング症状が出たり出なかったりする事象は、管理外のメモリ内容がＰＣの使用環境により偶然NULLであったり有意であったりすることで起こったものと推測される。~
~
(対処)マクロの開始終了アドレスをセットする処理部分で中身の無いマクロ状態を認識し、適切な判断材料を記憶する事で上記事態を回避する制御に改めた。~
**概要(2010.1.4) [#z3a66748]
以下の様な記述をするとMuseがハングする
${macro2}
$macro2{ _d }0
$macro1{ }0
症状を起こす条件として以下の２つの条件が成り立つ場合~
・最後に中身の無いマクロが繰り返しゼロで指定されている(macro1)~
・休符から始まる有意なマクロが上記と別に存在する(macro2)~
*(V5.46)演奏会場の設定における残響設定Delayの値が、Muse再起動でクリアされる [#bb297e5c]
**状況(2009.8.14) [#nc920eec]
V5.47として対処版をリリース~
(原因)V5.36で検出されたハード音源(MU90B)への不具合をV5.37で対処した際、大幅な変数配列構造の見直しを図ったが、そこでmuse.iniにおける値範囲の整合チェック部分
の修正に漏れがあった。muse.iniに127以上の値が書かれていた場合にゼロにすべきところが、7以上の値でゼロにしてしまっていた。~
(対処)変数と値範囲の関係を、適切な判定文に修正した。
**概要(2009.8.14) [#z3a66748]
少し前から気になっていたコトをひとつ……。~
演奏会場の設定画面についてなのですが。~
各パラメータをいじったあとで Muse を再起動すると、~
リバーブのパラメータ「Delay」の値だけが 0 に戻るのは~
何か理由があるのでしょうか？^^;~
*(V5.45)和音内連符において連符以降の音にアルペジオ指定が効かない [#rf2e7cea]
**状況(2009.8.10) [#r52e380c]
V5.46として対処版をリリース~
(原因)連符自体にはアルペジオは効かない仕様のため、連符を検出した際アルペジオ指定を無効化していたが、そのため和音内の連符の場合に連符以降の音も無効化されてしまった。~
(対処)連符検出時のアルペジオ無効化時点でアルペジオ情報を退避させ、和音が完結した時点でそれらの情報を復帰する処理を施した。
**概要(2009.8.10) [#of807d03]
和音内に連符を記述した場合、連符以降の音にアルペジオ指定が効かない。~
[dms(<<mfmf>>)<dms>]1:8
上記の例では、始めのdmsにはアルペジオが効いているが、連符後の<dms>には効かない。
*(V5.44)ドラムセットの持ち替えが効かない場合がある [#ud1513a5]
**状況(2009.02.15) [#fc5bdc1a]
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) [#x7c8d316]
(第一報告)
例えばメンバー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)アルバムに１曲も存在しないのにセパレータが表示される場合がある [#t3b73af5]
**状況(2008.10.28) [#afb5288f]
V5.44としてリリース~
(原因)履歴機構において初期化忘れの変数があった。~
(対処)正しく初期化した。~
**概要(2008.10.28) [#of807d03]
履歴メニューの階層下に更に階層がある状態で、
その直下にマウスで複数の曲を登録していくとセパレータが現れる。~
その状態で先程登録した階層直下の曲を次々に削除していくと、
最後の１つを消した段階で本来セパレータも消えるはずのところ、
それが残ってしまう。
*(V5.42)大量の音符が重なった部分で行番号検索を実施すると落ちる [#t3b73af5]
**状況(2008.07.28) [#afb5288f]
V5.43としてリリース~
(原因)表示用文字列配列のガード部分に不完全な判定があった。~
(対処)ガードの不備を改訂した。~
**概要(2008.07.19) [#of807d03]
添付ファイルのデータで今回の目玉機能の音符クリックを行うと
（自宅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)楽器の試聴における方向キーの動作不正 [#w9b187b9]
**状況(2008.07.17) [#ib67e1c1]
V5.42としてリリース済み。~
(原因)ダイアログにおけるコントロール属性のタブグループの設定ミス。~
(対処)タブグループ属性を正しくセットし直した。~
(追記)本対応に便乗し、以下の改良を実施した。~
譜面モニタ行番号検索において、マクロ記述対象の場合、~
その表示行番号を「展開側」と「定義側」の両方とする。
**概要(2008.07.17) [#of807d03]
楽器視聴のウィンドウでP121〜P128列にタブで移動し、上下を押していくと…~
P121で上を押すとおかしな動きをし、~
P128で下を押しても反応ありませんでした。~
他の部分と比べると、一貫性に欠けているような気がします。
*(V5.40)極端に長い演奏を記述すると動作が不正となる [#p6a5cb68]
**状況(2008.07.17) [#y2f79d7e]
V5.41にてリリース済み。~
(原因)Double Word で処理してる演奏カウントが、
オーバーフローする時点でエラー処理を施していなかった。
(対処)エラー処理を追加した。
(追記)本件の対応に伴い、譜面モニタ行番号検索機能の強化も実施する予定。~
・マクロや再現表記の行番号対象を、定義部から展開部へ変更~
・複数の音符矩形が重なっている場合は列挙表示~
・異なるファイル名がロードされた際、行番号表示をクリア~
**概要(2008.07.13) [#y55ed3fc]
{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と音部記号？を組み合わせると調性が狂う場合がある [#u7bdac75]
**状況(2008.07.11) [#y2f79d7e]
V5.40にてリリース済み。~
(原因)今までのプログラムは、調性無視を明に処理しているのは“h”のみであった。
何故なら“b”の方は初めから半音階の音価であるため、
調性記号で指定されるシャープやフラットが掛からない（対象になるはずがない）と
判断したためである。
ところが、音部記号？を使用した場合は、たとえ“b”であっても、
全音部分にシフトする場合がある。
したがって、“b”も調性を無視する処理を加える必要がある。
(対処)以下の処理仕様に改修した。
ドイツ音名の場合、音名“b”は調性を無視する。
また、音名“h”はフラット系の調性を無視する。
(追記)厳密に言うと本件の対処で上位互換が崩れるが、
音部記号と独音名を併用するデータは
極めて少ないと想定され、現実的には問題がないと判断している。
また、本件はあくまでもバグの対処であるため、積極的に互換性を崩す仕様変更ではない。~
**概要(2008.06.27) [#b074da86]
アルト記号の場合のドイツ式表記の場合の ｈ ｂ の扱いに関しての質問です。~
音部記号に関わらず、第３線に音符がある場合、調性（又は臨時）記号で~
フラットが付いている場合 ｂ~
フラットがない場合 ｈ~
と記述する、と思ってきましたが、その理解であっているでしょうか？~
いま入力に挑戦中の曲に♭６つの調が出てきて、ビオラのパートの音が変で、分からなくなってしまいました~
以下の例を演奏してみてください
\------;変ト長調の場合
;ト音記号
#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)にて、演奏会場の設定があると再生ができない [#n19a67fe]
**状況(2008.06.14) [#l132cce1]
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) [#ldc75676]
＜第一報告＞~
このたび「 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)途中再生の際、波形加工が正しく反映されない [#a12ada3b]
**状況(2008.05.18) [#r983634a]
V5.36で対処済み。~
(原因)V5.35でシーク処理を全面的に改良したが、その際ＮＲＰＮ／ＲＰＮの波形加工値制御において、~
全メンバーを１つのフラグで管理していたため、複数のメンバーが絡むと最適化による不要メッセージの~
送出抑止が過度に働き、必要なメッセージも止められていた。
(対処)波形加工値制御のフラグを１６メンバー独立で設け、適切な抑止処理となるよう修正。~
また今回の対処に伴い、ハード音源にも許容できる範囲でシークのインターバルを低減させ、~
より高速にシークできるよう改善した。
**概要(2008.05.17) [#e662b0a6]
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)波形加工遅延の記述があるとシーク(途中再生)の開始が極度に遅くなる [#wab00be5]
**状況(2008.04.25) [#p40e509c]
V5.35で対処済み。~
(原因)Muse内部でのMIDIメッセージ構築の際、重複する無駄なコマンドを除去しているが~
波形加工の遅延による時間軸方向へのデータエントリー展開状況を考慮していなかった。~
そのため、シーク時の高速化処理(最終値を決定しそのメッセージのみ送信)にて、~
波形加工とは異なるＲＰＮコマンドに対して、波形加工遅延で発生した大量の~
データエントリーを音源に垂れ流してしまう状況に陥っていた。~
この様な状況下で演奏が開始されると、メッセージ渋滞が起こり、~
演奏再開時に音源側で、メッセージを高速に処理する現象が出現した。
(対処)無駄なコマンド除去の不具合を修正。~
今回の対応に伴い、波形加工遅延も最終値のみの送信とし、
更に、他のメッセージに関してもシーク最適化を強化した。
**概要(2008.04.09) [#e662b0a6]
{#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が記述エラーとなる[#lc780847]
**状況(2008.03.07) [#s30ffec1]
V5.34で対処済み。~
(原因)単純な実装漏れ。~
アクセントコマンドをサポーとした V5.1から内在していた不具合となる。
(対処)実装した。~
Readme.txtへの記載も漏れていたため対処。
**概要(2008.03.07) [#ge41d985]
FINGコマンドにアクセントwを記述すると、文法エラーが発生しはじかれる。~
FINGパラメータの一番はじめにwを記載したときは正常動作するが、~
二番目以降に列挙した場合はエラーとなる。~
○ *FING"w+10"~
○ *FING"w+10 q-20"~
× *FING"q-20 w+10"~
*(V5.32)音量Vのマイナス方向への相対指定で最終値が負値になる [#lc780847]
**状況(2008.02.23) [#s30ffec1]
V5.33で対処済み。~
(原因)V5.20リリース時点で、ソースプログラムの整理を図ったが、その際に混入したデグレード。~
数値の大小比較における仮変数へのセット手順にミスがあった。
(対処)正しい手続きに改訂した。
**概要(2008.02.23) [#ge41d985]
例えば、@V50 d V-80 m と記述した場合、ミの音が負値(-30)になり、~
そのままMIDI音源に送られるため、逆に大きな音として演奏されてしまう。
*(V5.32)繰返し数ゼロの展開マクロ以降のデータがコンパイルされない [#n6490b5f]
**状況(2008.02.21) [#s30ffec1]
V5.33で対処済み。~
(原因)展開マクロの再帰呼び出し処理において、繰返し数がゼロの際のリターン値が不正であり、~
データ解析処理の終了処理に移行してしまっていた。
(対処)展開マクロの繰返し数がゼロの場合、そもそも解析処理の対象から外すシーケンスに変更した。~
(補足)今回のマイナーアップ(V5.32→V5.33)に伴い、譜面モニタのグリップスクロール操作の改善もついでに行った。~
「譜面モニタの小節線移動(アウフタクト)の反応を、小節番号付近のみとした」~
これにより、ほとんどの小節線上でもグリップスクロール可能となり、~
頻度の高いグリップスクロールの操作性が向上する。
**概要(2008.02.21) [#ge41d985]
繰返し数ゼロの展開マクロを記述すると、それ以降に記述したデータがまったく演奏されない。
*(V5.31)メンバー情報ダイアログの「M」の文字が欠けてしまう [#fd087033]
**状況(2008.02.11) [#s30ffec1]
V5.32で対処済み。~
(原因)★☆記号とメンバー記号（Ａ〜Ｚ）のスタティック部品が微妙に重なっていたため。~
今回のメンバー情報ダイアログのフォントサイズを変更したことで症状が表出した。~
(対処)部品間にマージンを入れて、どの様なフォントであっても重ならないようにした。~
**概要(2008.02.11) [#ge41d985]
ところでメンバー情報を開くと、メンバーＭの字で左側の縦棒が欠けて表示されますが、私だけでしょうか？
http://musewiki.dip.jp/pho/member.jpg
*(V5.30)メンバー情報ダイアログをクローズし再び開くと楽器名が表示されない [#qfa7c8f9]
**状況(2008.02.09) [#qc53163f]
V5.31で対処済み。
(原因)無駄な再描画を極力抑止するための機構に不具合があった。~
現在、表示されている楽器名およびバリエーション番号の記憶域を~
ダイアログクローズの際にクリアし忘れており~
再度オープンした時にまで再描画抑止機構が働いていた。~
(対処)クローズ時に、変数クリアを実施。
**概要(2008.02.09) [#qa8684f6]
演奏途中にメンバー情報ウィンドウを閉じて、再度開いたときに~
メンバーの名前が消えてしまいます。~
楽器の持ち替えが発生したタイミングでメンバーの名前が復活するようです。~
XPクラシックスタイルですが、同様の症状が再現しています。~
*(V5.26)譜面モニタ末尾の右クリックでメンバ色一覧の楽器名が消える [#y1c50e9d]
**状況(2008.01.12) [#sd966c6d]
V5.27で対処済み。
(原因)V5.23の障害を対応した際、譜面モニタ曲尾クリック時に曲頭から演奏を
開始してしまう症状を副次的に発見し、演奏せぬように対応したが、
その対処方法が中途半端であったため。~
V5.25での対処は、右クリックのリロード後、
演奏停止ポイントを曲尾にシフトしておらず、
加えて新たにロードしたデータでのシーク処理も施していなかった。~
そのため、演奏開始ポイントにおける楽器名がクリアされた状態のままとなった。
しかも演奏停止ポイントが未処理だったため、再度演奏を開始させた際、
不安定な状況に陥った。
(対処)譜面モニタ曲尾クリックの際、演奏停止ポイントおよびシーク処理を
完結させ、Museの内部制御状況の矛盾を取り払った。
**概要(2008.01.08) [#pe62a8f1]
譜面モニタ上で、曲の最後の部分（もう演奏される音がない部分）を右クリックすると、
メンバ色一覧の楽器名が表示されなくなります。
また、その状態で鍵盤を左クリックしても音が鳴りません。
さらに、しばらく再生したままにするとエラーが発生し、強制終了されました。
それを何度か繰り返したところ、MUSE自体が正常に作動しなくなりました；；
（曲を再生しようとするとMUSEがフリーズします…）
*(V5.25)履歴メニューの除去操作で追加されてしまう場合がある [#a6d84c31]
**状況(2008.01.02) [#zad4fefd]
V5.26で対処済み。
(原因)プルダウンメニューの階層が深くなり、通常右側に現れるメニューが左側に
折り返す状況になった際、既に存在している裏側のメニューアイテムが
マウスクリックされたと誤解釈することに起因する。
(対処)アイテム検出ロジックにおいて、検出時点で再帰呼び出し処理を打ちきらず、
その時点では検出アイテムを一時退避しておき、全メニューを一通り検索した後、
最後のクリックアイテムを採用することで、階層の深いアイテムを優先させる処理とした。
(追記)本件の障害とは無関係であるが、本対応バージョンにおいて以下の微修正も施した。~
・フィンガー拍数および楽器／ドラムの試聴のウィンドウ色を(Vistaに合わせ)淡い色に変更~
・iniファイル制御における“VRS：演奏停止時に音源リセット送出”のデフォルト値を
“０：しない”とした。
（“１：する”を選ぶと、演奏停止時の負荷でMIDI音源によってはストールする
場合があるため）
**概要(2007.12.28) [#k9a83307]
【報告その１】~
階層のある履歴について最下層の曲を右クリックで削除使用とすると、
その上の階層に現在開かれている曲を登録してしまう。
３階層と４階層で確認しましたが同様でした。
#ref(history_err.png)
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)音域限界の音程にて譜面モニタの表示が乱れる [#oce4d484]
**状況(2007.12.09) [#s20de566]
V5.25で対処済み。~
(原因)譜面モニタの音符位置情報を符合付き１バイト変数にて処理していたため、127を越える演算部分でオーバーフローを起こしていた。
(対処)メモリ節約のため記憶する変数型は従来通りとしたが、描画位置の計算時に一時的に通常の整数にて演算を実施することで、描画を正常になるよう改修した。
(追記)障害追跡の際、譜面モニタのスクロール時に起こる別の障害も自己発見したためV5.25にて対処した。~
譜面モニタのウィンドウ右端に達しない短いデータをスクロールさせようとすると、譜面全体が一気に右端に寄ってしまい、左側に空白が生じる症状。~
スクロール処理の際、そもそもスクロール不可能な状態を検出し、ガードを掛けた。
**概要(2007.12.09) [#y947a84e]
「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)曲中からの再生時に指定したフォントが効かない場合がある [#oce4d484]
**状況(2007.11.25) [#s20de566]
V5.24で対処済み。~
(原因)途中再生を実施する場合、そこまでの各種属性を高速にシークしているが、HEADを除く一回目のテキスト系表記が行われる前にフォント指定がなされている場合、そのフォントをテキストエリアに反映する処置が欠落しており、デフォルトのフォントが採用されていた。
(対処)上記の状況下において、指定されたフォントをテキストエリアにセットする処理をV5.24に施した。
(追記)障害追跡の際、以下の２項目に関する不具合も自己発見したためV5.24にて対処した。~
・途中再生の処理において、同様のシーク処理を２回繰り返していた。~
→シーク処理を最小限に抑え、処理速度の向上を図った。~
・譜面モニタでのマウス右クリックによるリロード時、指定箇所が曲尾の場合、先頭からの再生を実施してしまう。~
→曲尾クリックの場合は再生しないよう修正~
**概要(2007.11.23) [#y947a84e]
(不具合報告その１)~
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指定で後音を前音より先に発音させると連結＆の結果が異常となる [#r2bf2784]
**状況(2007.10.18) [#hded8699]
(原因)pqおよびスタッカートに依存しない連結＆の処理の考慮不足。接続すべきノートOFFとノートONを除去した結果、連結後の残されたノートONとOFFの時間的な順番が逆になってしまい。音が鳴り続ける。しかも、譜面モニタの座標が別のアルゴリズムで処理されていたため表示が発音と食い違ってしまう現象も起きていた。
(対処)接続すべき２音のノートONの後先関係を調べ、上記に該当する状態の場合は連結処理を実施しないように改めた。V5.23で対応済み。
**概要(2007.10.16) [#nb6e8551]
以下のデータを実施した際、異常な解析結果となる。
x2_2
[ceg]4p^2q~2&[ceg]8_
今回の実装では��&�△箸いΦ�述を�，琉銘屬妊�ン、�△琉銘屬妊�フ、
と言う風に内部処理されていらっしゃると、２つめのデータの
モニタ画像で確信しましたが（これもV5.21とは似ても似つかない出力です）、
とするならば、この最後のデータはオフ→オンの順の処理がなされ、
同じ音をもう一度鳴らせてさらにオン→オフの命令を出さない限り
ひたすら鳴りっぱなしになるのではと思っていました。実際
そうなっているようです。譜面モニタではオフとオンが逆になって
音長が表示されていますが実際にCの和音が鳴り始めるのは
モニタのオフの（ように見える）位置でそれから鳴りっぱなしに
なっているようです。
ある意味忠実なコンパイルとも言えますから、これでよいような気も
しますが（そもそもこんな記述は実際は誰もしませんし）、
譜面モニタの表示がずれるのは少々気分が悪いですね…
エクスクルーシブなどを使わずに、妙な現象を引き起こせるので
面白いと言えば面白いですが、このようにコンパイルしてしまって
良いのか、難しいところですね。オンとオフがひっくり返れば
なかなか粋な仕様とも思いますが、さらに&が続いた場合に
収拾がつかないような気もします（苦笑）。難しいところですね。
*(V5.21)連結＆が他のフィンガーのｐｑに影響を受ける [#i9a541c7]
**状況(2007.10.14) [#q00e37c9]
明かな再現性を確認。~
V5.22で対処済み。
(原因)連結処理のアルゴリズムは同時刻のノートOFFとノートONを検出することで行っているが、その検出を高速化するため、ある条件に達した場合に検出作業を打ちきっていた。今回、pqやスタッカートに影響されない仕様に変更したことで、その打ち切り条件を以前よりも広くとらなければならないにもかかわらず、以前のまま実施していた。
(対処)ロード時に、フィンガー毎の時刻キーによるソーティングリストを作成し、それを元に打ちきり条件を決めるように改修した。これにより、今までのコンパイル速度をほぼ維持しつつ、pqやスタッカートに影響を受けない連結を実現した。
(追記)今回の障害対応に伴い、連結＆はフィンガー内でのみ実施するように改めた。従来は、メンバー内のフィンガーをまたいで効果していた。
**概要(2007.10.13) [#nb6e8551]
連結コマンド"&"の仕様が，
次のようなコードではうまく機能しません．
*FING"x1 q~64" [#pb6f27ea]
#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)リロード時のフォント変更反映不備 [#i9a541c7]
**状況(2007.10.12) [#q00e37c9]
明かな再現性を確認。
原因は、シーク時のちらつきを防止するために文字列内容の変更が無い場合に無駄な描画を抑止する処理に置いて、フォントが変更されていた場合は抑止しない考慮が欠落していたため。
V5.21にて修正済み。
**概要(2007.10.12) [#nb6e8551]
FONTコマンドで別のフォントに変更したデータをリロードした際、リロード直後にそのフォントに反映されず、元のフォント状態を維持してしまう場合がある。
*(V5.15)ステレオ指定のエラー検出の不具合 [#i9a541c7]
**状況(2007.09.19) [#q00e37c9]
本件に関して、バグであることを確認。~
原因は、ステレオのプラス側の処理で条件分岐の不手際。~
修正完了。
ただし、近々次期バージョン(V5.20)のリリース予定のため、~
修正版は、次期バージョンに併せて提供する。
なお、現バージョン(V5.15)において、エクスポートもMuse演奏も~
MIDIの数値制約内に強制的に納めており、演奏障害などは起きない。~
文法エラー通知のみの不具合である。
**概要(2007.09.19) [#nb6e8551]
#B1@ _2 S+664 [fl-]1~
数値は99999999までいけました。それ以上は文法エラーになります。~
なお、「-」の方は64以下で本来のエラー検出になります。~
SC-8850の全面ディスプレイでS+100,S+1000などと指定して確かめてみたところR63となっておりS+64相当であることが確認できる。
MIDIにエクスポートしてみたところ同じようにR63であった。
*(V5.14)演奏終了時に異常終了 [#dcaf6c0f]
**状況(2007.08.04) [#d7a311e7]
Ver.5.15にて修正済み。
(原因)
Muse演奏終了時に、諸々のコントロールを一気にクリアし、次の演奏曲を乱さないためにエクスクルーシブ命令を送っているが、その送信にタイムラグを入れていなかったため、音源側が処理しきれずに異常終了となった。
ＰＣの環境やマシン性能により出現しない場合があるが、出現環境では再現性が極めて高い不具合であった。
(対処)
エクスクルーシブ処理に適切なウエイトを挿入することで対応。
**概要(2007.07.16) [#a9527d90]
時間を置いて、異なる２名が不具合報告を開発者へ送付。
症状としては「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)履歴曲追加・除去時の不具合 [#dcaf6c0f]
**状況(2007.07.04) [#d7a311e7]
Ver.5.12にて修正済み
２つの原因が複合した不具合であった。
(その１) プルダウンするメニューエリア以外でのクリックへの対応が漏れており、
制御アドレス外のメニュー項目を削除するという処理が動いていた。
完全なMuseプログラムのミス。
＜対処＞エリア外クリックへのガードを施した。
(その２) WindowsというOSの互換性問題。具体的に言うと、
メニュー上の右クリック時、
XPにおいてはボタンアップのイベントのみが通知されるのに対し、
Meにおいてはボタンダウンのイベントのみが通知される。
V5.11では、アップイベントでのみ処理を実行していたため、Meでは動作しなかった。
＜対処＞ボタンアップに加えボタンダウンでも反応するように改修した。
※アップとダウンの両方のイベントが通知されるようなOSバージョンが存在すると、
処理を二重に実行してしまうため懸念は残るが、その時は別途対処する予定。
**概要(2007.07.02) [#a9527d90]
ver.5.11でも履歴曲、削除の時の右ボタンが効かない感じがします。~
（階層は１階層のみ）(Me)~
ちなみに右ボタンでの曲登録は出来るみたいですが...？~
(USBマウスを使用しています)~
そのあとメニユー（履歴の）項目上などで右クリック
削除確認メッセージが出ると同時（時には表示されないまま）に
システムからの障害メッセージで
http://musewiki.dip.jp/pho/muse_err.png
*(V5.10)履歴機能の不具合 [#y84d189d]
**状況(2007.07.01) [#gdc2d50a]
Ver.5.11にて修正済み
アルバム機構を設定していない場合の履歴管理に不具合がありました。
ある条件文のtrue/falseを逆にしていたため、論理矛盾を起こしていました。
１文字の追加にて修正完了しました。
**概要(2007.07.01) [#ae7c1078]
ところで履歴機能ですが、ファイルをリロードする度に履歴の欄に（なし）という表示が増えていくようです。
右クリックで削除しようとしてもできません。（他の曲を除去していいか聞かれます。）
そして時々Museが強制終了してしまうことがあります。
*(V5.02)アルバムからの選択における履歴更新制御の不具合 [#ge7aa382]
**状況(2007.05.31) [#ye3d938a]
Ver.5.03にて修正済み
確実に再現するバグです。仕様では下記概要の「期待する動作」をイメージして開発しましたが、論理設計のミスで現状動作のようになってしまいました。数行の修正で治りました。
ちなみに次期バージョン(V5.10)ではある理由からこのパラメータを撤廃します。
**概要(2007.05.29) [#bdcc9b8f]
ただ気のせいだったらすいませんが、Muse.iniに追加されたLGS = 1 なんですが、説明通りの動作をしていないようなのが気になります。
説明 ←アルバムからの選択時に履歴を更新 (0:しない／1:する)
期待する動作~
０：「アルバムからの選択」で演奏した曲は履歴に記録されなくて、開くやＤ＆Ｄで演奏した曲は記録されます。~
１：「アルバムからの選択」か否かに関わらず，演奏した曲は全て履歴に記録されます。
現状はこのスイッチは単に履歴機能の有無として動作しているように思えます。
０：履歴が全く更新されません。~
１：「アルバムからの選択」か否かに関わらず，演奏した曲は全て履歴に記録され
ます。
*(V5.01)テキスト系非出力のエクスポートで不正MIDIファイル [#i323ac54]
**状況(2007.05.28) [#j4387201]
Ver.5.02にて修正済み
**概要(2007.05.27) [#aa6992ae]
「MIDIファイル容量を抑えるため、テキスト系コマンドのデータを出力しない」のチェックボックスを選びエクスポートすると、指定もしていないのに所々でスィング演奏する滑稽なMIDIファイルが出力される。
*(V5.00)フィンガー拍数のプルダウンメニューが文字化けする [#i323ac54]
**状況(2007.05.27) [#j4387201]
Ver.5.01にて修正済み
http://musewiki.dip.jp/pho/WS00000022.JPG
**概要(2007.05.26) [#aa6992ae]
http://musewiki.dip.jp/pho/WS00000021.JPG
↑くさば環境(Windows2000)
http://musewiki.dip.jp/pho/mojibake.gif
↑浅川環境(Windows Me)
http://musewiki.dip.jp/pho/WS00000038.JPG
↑くさば環境(Windows Vista)正常例
*(V5.00)フィンガー拍数のプルダウンメニューから「V：音量」が消える [#g8835282]
**状況(2007.05.27) [#wfebf10d]
Ver.5.01にて修正済み
**概要(2007.05.26) [#eb94afed]
Muse起動時にはフィンガー拍数ウィンドウには「V：音量」が設定されていますが、ほかの設定に変えた場合、プルダウンメニューから「V：音量」が消えてしまう。
*(V5.00)Muse演奏終了時に音源がリセットされる [#t0fa07c1]
**状況(2007.05.27) [#x2e4e4ef]
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) [#pbe879d6]
これについてはVer.5.0からの仕様変更ですが、ハード音源を使ってパネルで音をいじりたい場合不都合であるのでINIファイルによって制御可能にする予定。
*(V5.00)S-YXG50を使用時にMuseが落ちることがある [#t6cb015c]
**状況(2007.05.27) [#jbe3bb6c]
V5.01でサポートされたmuse.iniのVRSをオフ(0)にすることで現象を抑えられる。
S-YXG50 を「Microsoft MIDI マッパー」でアクセスするという組み合わせの場合、
VRS=0としておく回避策により解決とみなす。
**概要(2007.05.26) [#t3743dc5]
落ちるタイミングは、ファイル読み込み時、あるいは演奏終了時です。「演奏終了時」がポイントではないかと思います。
ファイル読み込み時は、現在は README.TXT のみ確認しました。
ちなみに、Roland VSC を使ってみると落ちません。
演奏に成功します。README.TXT でも全く落ちません。
ですから、おそらくその「残響制御」が原因なのではないかと思います。
過去のバージョンではそういった事は起こりにくかったです。
実際は「Microsoft MIDI マッパー」にて高確率発生する模様です。
VRS=1の時は発生しました。
VRS=0の時は発生しませんでした。
![[PukiWiki]](/MuseWiki/wiki_baner.png "[PukiWiki]")
