状況(2014.02.03)¶

V6.70にて対応済み。

(原因)
V6.41→V6.50の時点でシーク処理の効率化を施した際に埋め込んだ障害。
波形加工によるNRPN音源負荷を低減するため、最終値のみ送信を行っているが、XコマンドによるRPNは即時送信している。
そのため、波形加工とXコマンドのMuseデータ記述順によっては、
シーク時にその順序が逆転し、演奏時に本来あるべきMSB,LSBの指定状態になっていなかった。

(対処)
MIDI規格によりデータエントリがNRPNとRPNで共用されているため、
１つのデータエントリで同時にNRPN、RPNの指定を実施することはあり得ないということを前提に、シーク処理を全面的に見直した。
従来、データエントリ検出時点で即時送信すべきか否かを判定していたが、
その時点では波形加工判断とバッファリングに留め、NRPNあるいはRPNを検出した時点で、
既存のバッファ内容を音源に送信すると共に、検出したNRPNあるいはRPNを新たにバッファリングする方針とした。
これにより、従来諦めていたXコマンド遅延指定時の最終値のみ送信の処理も実装可能となった。
バグを改修しただけでなく、性能も向上したはずである。

概要(2014.02.02)¶

＜報告１＞
再生させてみたのは

*DATA"" 
*DATA "43,10,4C,00,00,7E,00" 
@A P31/0 R80 R=65.64.60 W=64.67.64 T-12 S-24 X7=127
#A0 @ X101=0 X100=2 X6=64 X6=76:1 o4 x1 c4 c c c
*STOP"" 

です。
２つ目以降の音に右クリックで飛び込むと、以降 c 音になって、上がっていきません。
ただ、音がビヨ～ンと揺れているようです。
ビブラート関連の NRPN かほかの RPN が効いてる？のかちょっとわかりませんが

いろいろやってみると、うまく上がっていくケースもあるようです。
どうも、R= と W= を両方削除すると、途中飛び込みでも正常に上がっていくようです。
※GS リセット下（１行目２行目削除）でも、同様のようです

R= と W= が、NRPN を使用しているのかわかりませんが、
X101 X100 X99 X98 のバッファリング・即時送信、あたり（？）
１）途中に飛び込む
２）溜め込んでいた R= W= を NRPN で送信（同じく溜め込んでいた X100、X101 の送信順番は？）
３）遅延指定の X6 が送信⇒２）で送られたメッセージのデータエントリとして評価される
とこんな想像です

＜報告２＞

#A0 @ R=64.64.64
X101=0 X100=2 X6=64 X6=100:1 d4 d d d

このデータで、X101, X100 でのRPN 指定と R= での NRPN 指定が干渉しているのが原因のはずです。
V6.55 での NRPN の干渉問題と同様だと思います