Ｍｕｓｅ掲示板

Αφροδιτηさん
> 他の設定は上のまま MaxVoices=256 とすると、症状が改善しました。
> 4 回ほどの繰返し演奏では、note off 飛びは確認されていません。
ご報告、ありがとうございます！
この様な形で、情報を頂けることを期待していましたので、
大変助かります。

ちなみに、現在Museでは、通常のウンドフォントメニューにおいては、
	MaxVoices=1000
	AdditionalBuffer=500
	EnableHardwareMixer=0
	PreloadSoundFont=0
	RaiseProcessPriority=0

の設定になっています。

★なお、
PreloadSoundFont=0
に関しては、常に0固定で実験してください。
これを1にすると、ほぼ確実に音飛びが改善すると予想していますが、
一回目の演奏開始に、大変時間が掛かるようになるため、
デフォルトでは0とすることに決めているためです。

> ちなみに、C:\Windows\System32\VirtualMIDISynth\VirtualMIDISynth.conf 
> は更新されなかったように見えるのですが、Muse はコンフィグファイルを
> どこに書き込んでいますか?
上記のパスに書き込んでいます。
更新されなかったという症状に関しては２つの可能性が考えられます。

１つ目の可能性は、Αφροδιτηさんの確認タイミングが早すぎた状況です。
更新は音源の切り替え時点では行われません。
切替え後、１回目の演奏を開始する直前に更新されます。

２つ目の可能性は、過去のMuseの不具合によりテンポラリフォルダにゴミが残っている状況です。
掲示板[10095]の処置を施した後、再度実行してみてください。

> >>他の設定は上のまま MaxVoices=256 とすると、症状が改善しました。
> >>4 回ほどの繰返し演奏では、note off 飛びは確認されていません。
> 
> 結局このケースでも症状は出ましたが、これまでの状況と比べても
> 明らかに確率は低くなっているように思われます。
> ざっと 1/4 ぐらいでしょうか。
> 
なるほど。
私が初めに考えたのは、
	EnableHardwareMixer(ハードウェア利用)
	RaiseProcessPriority(ＣＰＵ優先度)
の２つのパラメータのON/OFFの組合せで改善しないか、でした。
しかし、どうも私の環境では改善の兆しがない
（ここはΑφροδιτηさんの環境でも試してみてもらいたいところです）

そこで次に考えたのは、できるだけマシン負荷をかけないようにすることでした。
	メモリ使用量を減らす　→　MaxVoices(同時発音数)を小さくする
	CPU負担を減らす　→　AdditionalBuffer(発音遅延)を大きくする

発音遅延の方は500(msec)以上にすると、
Muse鍵盤表示と実演奏音のズレが目立ち始め、とても鑑賞に耐えないと思い、
ギリギリの500にしてあります。

同時発音数の方は、予想に反して大きい方が改善の兆しがありました。
（ここはΑφροδιτηさんの観測と一致しています）
理由を考えたのですが、もしかしたらメモリ使用量よりもＣＰＵ負荷の方が
影響度が大きく、同時発音数が上限に達した際の処理で症状が出現するのかもしれない
という仮説を立てました。で、現在は最大の1000を指定した次第です。

> > ちなみに、現在Museでは、通常のウンドフォントメニューにおいては、
> > MaxVoices=1000
> 
> これで余り改善されなかったとすると、大きければ良い訳でもないという
> ことでしょうか。
>
もしかすると、
MaxVoicesがある値以上になると、
今度はＣＰＵ負荷よりもメモリ使用量の方が影響してくる領域に
入ってしまうのかもしれません。その位相点を探るのが課題かも。

この仮説が正しければ、今の所、
129以上1000未満の範囲に絞られているということになります。

> しかし、確率事象で運もあるので総計に結論は出せませんね。
そうですね。
いろいろなケースで試して見ないと結論をすぐに出せないでしょう。
長丁場になりそうです。無理をせず、ゆっくりと実験して下さいね。
ご面倒をお掛けしますが、よろしくお願します。
確率が低くてもここで症状が出るっ！というところがつかめていたら
自らやるところですが、どうも私の環境だとその箇所がなかなかつかめないんです。

> 1 回の試行に数十分かかるというのが如何ともしがたいところですが。
まるで、カミオカンデのニュートリノ実験みたいですよね(笑)。

> > ★なお、
> > PreloadSoundFont=0
> > に関しては、常に0固定で実験してください。
> > これを1にすると、ほぼ確実に音飛びが改善すると予想していますが、
> > 一回目の演奏開始に、大変時間が掛かるようになるため、
> > デフォルトでは0とすることに決めているためです。
> 
> そのつもりです。
> 問題の症状は、一回目の演奏開始に長い時間がかかっていたときも
> 同様に出ていたので、今更試す価値もないかもしれません。
おおっ、これも有益な情報ですね。
プリロードしても症状は出るのか！

> コンフィグの内容は反映されている(サウンドフォントはちゃんと切換わっているし、
> 症状の出方も変わっている)ので、これも大丈夫そうです。
> 
> ……やっぱり Windows は謎。

もう１つの可能性がありました。
もし、Αφροδιτηさんが64bitOSをお使いであるならば、  
C:\Windows\SysWOW64\VirtualMIDISynth\
の方が実体かもしれません。

Αφροδιτηさん、
手間の掛かる実験、本当にありがとうございます。

> 改善の見えた MaxVoices を弄る方向で実験を進めてみました。
> MaxVoices=512 生起確率の比: 約 1/2
> MaxVoices=384 生起確率の比: 約 1/1
> MaxVoices=256 生起確率の比: 約 1/4 (試行 2 回目)
> 生起確率の比は、確率そのものではなくて、MaxVoices=128 の場合の生起確率を 1 とした比率で、かなり大雑把です。

やはり、256がマジックナンバーでしょうか。
傾向がまったく掴めないですね(苦笑)。

  1.0    *            *
         *            *
  0.5    *            *     *
         *      *     *     *
  0.0    *      *     *     *
       100  200  300  400  500  600

> 上の順序は試行した順序と同じです。
もし試行順序も関係するとなると、あまりに過酷な実験ですね。

> MaxVoices を 384 から 256 に書換えて、Muse を一旦停止しただけで再生したときは、えらく成績が悪かったのですが、これではまだ反映していませんね。
はい。その通りです。

> 上の 256 の結果は、その後別の音源で別のデータを再生してから元に戻して試行したときのものです。
これで大丈夫だと思います。
音源を切替え直せば、反映するはずです。

> 私の環境でも、発生個所はその都度違います。
ご苦労をお掛けします。m__m

頂いたこの貴重な情報を大切に扱い、
今度のバージョンのMaxVoicesは256にするつもりです。

> うーん、32 ビットです。
そうですか。
やはり、不可解ですねぇ〜。
あれから、私の環境でも何度か試したのですが、
こちらでは、ちゃんとconfファイルの書き換えを確認できてます。
不思議です。

Αφροδιτηさん

実験報告、ありがとうございます！

だいぶいろいろな情報が溜まってきたので、整理してみますと、

�@MaxVoices=256
�AAdditionalBuffer=500
�BEnableHardwareMixer=1
�CRaiseProcessPriority=1

といったところでしょうか。
�Bに関しては、Αφροδιτηさんの方で改善を確認して頂けたので、ほぼ確定としたいと思います。

�Cに関しては、Αφροδιτηさんも私も改善は見られないのですが、悪化もしていないので、デフォルトの=1を採用しようと思います。

�Aに関しては、今の所500が良さそうですが、ゼロと500の間の250あたりでも実験してもらえると方向性が見えるかともいます。

�@に関しては、２のべき乗に絡んだ値を実験してもらいたいなぁ〜、と思っています。できれば500以上の値の状況が欲しいです。
	以下の４通り。特に512と640は、もしかしたら良い結果が出るのではないかと・・・。まったく根拠ありませんが(笑)。

	512
	640 = 512 + 128
	768 = 512 + 256
	896 = 512 + 128 + 256

> なお、順序は一応気にしていますが、今のところ順序に依存する結果は出ていません(そもそも順序だけ変わるようなケースをあまり試していませんが)。
順序に関する件、了解しました。