開発者様．
バグの解析，修正お疲れ様です．
その間にも"&"の仕様に関する様々な是非の話がありますが，
自分の見解では，
更に「"&"の効果範囲を1フィンガーに制限する」という新仕様で
"&"の Muse 文法内での立場が明確になったように思います．
というのは，v5.1以前では Muse のコンパイル処理が
以下の手順で行われている，あるいはそれと同じ結果が得られていました：
1) フィンガー属性を参照しながら，各音符の音程，発音位置，
止音位置，音量を読み取って，データを並べていく．("&"はいったん無視)
2) 「"&"指定の直前の音」の止音のタイミングで発音する
同音低の音をつなぐ．("&"が記述されているフィンガー以外の音もつなぐ)
3) その他，P,V,Wなどのコントロール処理．
(実際，v5.1をv5.2で既に上書きしているため，
確認作業は出来ていませんが，間違っていたらお許しを)
この仕様では，"&"がかなり広い範囲に効果を持っていて，
T指定と同等の存在感を感じます．
また，v5.20，v5.21(の目標とされた仕様)では，次のような処理と思えます：
1) p,q，スタッカート以外のフィンガー属性と記述から，
各音符の音程，発音位置，止音位置，音量を読み取って，
データを並べていく．("&"はいったん無視)
2) 「"&"指定の直前の音」の止音のタイミングで発音する
同音低の音をつなぐ．("&"が記述されているフィンガー以外の音もつなぐ)
3) p,q，スタッカートの処理を施す．
4) その他，コントロール処理．
この仕様では，フィンガー属性のp,qが，
他のフィンガー属性に比べて特別扱いされている感じがします．
また，"&"は，かなり広い範囲に効果を持っているにも関わらず，
フィンガー属性p,qより優先的に処理されるという，
かなり強力なコマンドにも思えます．
一方，v5.22(で決定するであろう仕様)では，次のようだと思えます：
1) まず，記述変換処理で"&"も処理する．
(「{c4//d4e&e}2→c4//d4e2c4//d4e2」，
「[ce&g]4e&[eg]2→[e1]0[ce]4_4g2」等)
2) 変換処理した記述をp,qも含めたフィンガー属性を加味し，
各音符の音程，発音位置，止音位置，音量を決定し，データを並べていく．
4) その他，コントロール処理．
この場合，"&"は省略音長やマクロなどと同じレベルの記述を考えられ，
"&"を記述した前後の記述のみで結果がどうなるかを予想できます．
まぁ，実際に記述変換処理などは Muse 内では行っていないと思いますし，
上記はあくまでも，「Muse のコードを見た人間が，
どのような結果になるか予想する場合」のアルゴリズムですが．
また，フィンガー属性 x,o,\ は，「同一音程」かどうかの判定に必要なので，
フィンガー属性の参照は上の 2) 以外にも用いられてはいますが．
...と長々と書きましたが，p,qと&の互換性については，
実は自分は方法で解決されると思っていました．
何かというと，新しい文法の提案になるのですが，
音長を変えない zero-staccato なるものを導入すればどうかと思ったのです．
例えば，
#A0x1q~64 e4g2<c4> |
#A1x1q0 c2e |
を"無理やり" & を使って書くと，(旧仕様, v5.1以下)では，
x1q~64 [c^64e4]4&[cg^64]&[e^64g4]&[e<c>]
となりましたが，q 指定を無視するスタッカートで，
音長を変えないもの(例えば "/0" という記号)を使えば，
x1q~64 [c/0e4]4&[cg/0]&[e/0g4]&[e<c>]
と書ける，といった具合です．まあ，一時的な q0 指定みたいなもんです．
とまあ，新文法の宣伝はこのくらいにしておきます(笑)．
長文失礼しました．
> こうしてMuseの真髄とも言える記述解釈問題を通じて、
> 旧友あいまみえることに痺れるような快感を感じています。
> αさんのお陰ですね。
σです......が...
|
