![[PukiWiki]](/MuseWiki/wiki_baner.png "[PukiWiki]")
V6.4において連符内連符の対応を実施した際、互換性を崩すレベルのアクセントに関する仕様変更を予定した。
それに対し、MuseWorld?の掲示板でミューザーからの見解が提示され、議論の末、本仕様変更を撤廃するに至った。
その経緯は、音楽言語としての分析として興味深いものであるため、記録としてここに掲載することとする。
まず最初に開発者から示された互換を崩すアクセントの仕様変更内容は、以下の通りである。
従来のアクセントは、和音や連符などの音群に掛けた場合、違和感のある仕様であった。
#A0 [ d r w+20 m f ]~ #B0 w+80 [ d r w+20 m f ]~
#A0の場合は、アクセントw+20はm だけに掛かり、fには掛からない。
#B0の場合は、d r はw+80となるのは同様だが、m が w+20 となった後、
fにwの指定をしていないにもかかわらず、fまでw+20となってしまい全く一貫性が無い。
ほぼ、バグに近い仕様である。
新仕様の#B0は、d r f は w+80 となり、 m のみが w+20 になる。
→非互換検出データ：１１曲
従来、和音や連符内で指定したw値は、その外に出ても値を保持していた。
w+50 ( d r w+10 m f s l ) w c~
上記の例で、シの音のアクセント値は、+10となっていた。
しかし新仕様では群音内で指定したアクセント値は、その外に継承しないことにした。
上記の例のシのアクセント値は、+50となる。
これによりアクセント値の継承は、省略音長の伝播プロセスと同様となり一貫した設計思想の仕様となる。
アクセント値を記載しない（つまりアクセント値省略の記法）でアクセントをつけた時
w+50 ( wd wr w+10m wf ws wl ) wc~
新仕様では、
w+50 ( w+50d w+50r w+10m w+10f w+10s w+10l ) w+50c~
となる。
連符や和音内の音にアクセント自体を添えなければ、
w+50 ( d r w+10m f s l ) wc~
新仕様では、連符や和音の前につけたw+50が全体のデフォルトとして働き、
w+50 ( w+50d w+50r w+10m w+50f w+50s w+50l ) w+50c~
となる。
→非互換検出データ：５００曲強
これについてのMuse掲示板での議論は以下の通りである。
[8847] 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/08(Mon) 21:53:49 近日、Museの新しいバージョン(V6.4)をリリースする予定ですが、 今回は文法の非互換が数多く発生する予定です。 いずれも軽微であると考えていますが、過去のデータに影響を与えることには違いなく、 あらかじめ皆さんにその内容をお伝えしようと考えました。 以下のMuseWikiにその情報を展開しています。 http://musewiki.dip.jp/MuseWiki/index.php?V6.4%A4%CB%A4%AA%A4%B1%A4%EB%C8%F3%B8%DF%B4%B9%BB%C5%CD%CD 興味のある方はご参照下さい。
[8848] Re[1]: 次期Museにおける文法非互換情報 投稿者：Eleken 投稿日：2013/04/09(Tue) 10:09:04 こんにちは。 Muse今月号はメジャーバージョンアップなのですね。 変更点について、個人的に気になった点を書いてみたいと思います。 > �は族仔發離▲襯撻献� > もちろん、コード表記の無い単純な和音でも逆アルペジオが掛かる。再現表記でも利用できる。 > [dms]:16 ,:- ,: ,:- ,: ,:- これは嬉しい改良ですね！特に、エレキギターのバッキングの記述に役立ちそうです。 いままでは、逆アルペジオが効けばいいのにと思いながら、いちいち [ds<d>]:[<d>sd]:[ds<d>]:[<d>sd]: ... という具合に記述していました。 > ��群音内で指定したアクセントの値 > 新仕様では群音内で指定したアクセント値は、その外に継承しないことにした。 これは賛否分かれそうな気がします。 群音全体にアクセント指定がなくても、群音内のアクセント値は群音外に継承しないということですよね。 たとえば、 (1) w+40d4r8m wfslc <wd2> (2) (w+40d8rm)2 (wf8slc) w<d2> の2つの例で、最後の d のアクセントは、(2) では w+40 にならないということだと思います。 2^N 分音符以外のリズムが現れる音楽では、必然的に連符表現を多用すると思いますが、 そのときに旧バージョンでできていたようなアクセント値の省略表現が 新バージョンではほとんどできないか、使用に大きな制約を掛けられることになるのではないでしょうか。 たとえばシャッフルのリズムを連符で表現している場合などに、顕著に現れる問題ではないかと思います。 少なくとも連符においては、 「群音全体にアクセント値の指定がある場合、群音内で指定したアクセント値は、その外に継承しないことにした。」 という仕様の方がより自然なのではないかと私は考えますが、いかがでしょうか？
[8850] Re[2]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/09(Tue) 18:58:29 Elekenさん、リプライありがとうございます。 > (1) w+40d4r8m wfslc <wd2> > (2) (w+40d8rm)2 (wf8slc) w<d2> > の2つの例で、最後の d のアクセントは、(2) では w+40 にならないということだと思います。 はい。仕様の良し悪しはともかく、現在進めている新仕様はElekenさんのご認識の通りです。 > 少なくとも連符においては、 > 「群音全体にアクセント値の指定がある場合、群音内で指定したアクセント値は、その外に継承しないことにした。」 > という仕様の方が自然ではないかと考えますが、いかがでしょうか？ 確かに妙案ではありますが、しかし、 新しく連符内連符が無限の階層で記述できるようになったため、 あまり複雑なルールを持ち込むと、一体今どのアクセント値になっているのか迷子になってしまうと考えました。 例えば、Elekenさんの案ですと、 ( (w+40d8rm)2 w+10 (wf8slc) ) w<d2> とした途端に、最後のwの値を理解するにちょっと戸惑いませんか？ あるいは、 w+40 (wd8rm)2 (w+30f8slc) w<d2> だと、最後のwの値はどうなるか？ 単に、私の状況把握力が不足しているだけかもしれませんが、 頭がこんがらがってしまいそうです。orz そこで、 「群音内で指定したアクセント値は、その外に継承しない」 と、極めてシンプルな仕様にしました。つまり、省略音長と同じです。 これなら飲み込みの悪い私でも最後のwの値を即答できます(笑)。 さて問題は、 新仕様において期待する演奏を行いたい場合ですが、 まず、 (w+40d8rm)2 (w+40f8slc) w+40<d2> とすべてのアクセントに値を明示する方法があります。 でもこれでは面倒で、何の解決にもなってませんね。 そこで、こんな手があります。 *FING"w+40" (wd8rm)2 (wf8slc) w<d2> しかし、これですと全てのフィンガーに一律にw+40が作用してしまいます。 *FING"A(w+40)"とすればＡメンバーのみになりますが、それでもまだ不満です。 そこで、ちょっとトリッキーですがゼロ音長を使う手があります。 w+40d0 (wd8rm)2 (wf8slc) w<d2> （今回、アクセントのゼロ音長透過を抑止したので好都合でした） 要は、括弧の外でアクセント値を何らかの方法で指定しておけば、 それ以降、アクセント値の付いていないwはその値が継承されるというわけです。 アクセントは休符も透過しないので、もし休符が前半にあるのなら、 w+40_1 (wd8rm)2 (wf8slc) w<d2> でも可能です。 いかがでしょうか？
[8852] Re[3]: 次期Museにおける文法非互換情報 投稿者：Eleken 投稿日：2013/04/09(Tue) 21:23:13 開発者様 お返事ありがとうございます！ なぜこの仕様変更がセットで行われたのか、頂いたレスを読んで理解が深まりました。 > 新しく連符内連符が無限の階層で記述できるようになったため、 > あまり複雑なルールを持ち込むと、一体今どのアクセント値になっているのか迷子になってしまうと考えました。 なるほど、確かに私の提案では、２次以上の連符を念頭に入れていませんでした。 また、連符全体へのアクセントも存在することを考えると、これはうまくいきませんね。 > そこで、 > 「群音内で指定したアクセント値は、その外に継承しない」 > と、極めてシンプルな仕様にしました。つまり、省略音長と同じです。 新仕様のように、C における変数のスコープのような定義にすれば、任意次の連符や連符全体へのアクセントに対して シンプルかつ直感的な表現になるというわけですね。 今回のご説明で新仕様の合理性がよくわかりました。 > さて問題は、 > 新仕様において期待する演奏を行いたい場合ですが、 > そこで、ちょっとトリッキーですがゼロ音長を使う手があります。 > w+40d0 (wd8rm)2 (wf8slc) w<d2> なるほど、ゼロ音長を使えば確かに、私の思うような記述に近いものになりますね！ （今のうちに、今まで作ったデータをチェックして、このスタイルの記述にしておかなければ・・・） 今回なぜこのような提案をしたのかと考えてみました。 新仕様は音長と同じ仕様でシンプルだという点は、うすうす気づいていましたが・・・ 私の中では、アクセント "w" とは楽譜でいう "＞" や "∧" のような、音符１つに対して 表現上の効果を及ぼす記号のイメージでした。 これは連符内にあろうがなかろうが、同じ記号は同じ意味ですよね。 ゆえに、アクセント指定子は連符とは独立であるべきと思ったわけです。 他方音長というのは、連符内にあると楽譜上の 8 分音符は 16 分音符にも 32 分音符にもなり得ます。 したがって、絶対的な音長は連符の有無に依存するわけですから、 音長指定のスコープは連符内で閉じていてしかるべきだと思います。 > ・・・極めてシンプルな仕様にしました。つまり、省略音長と同じです。 ということでしたが、以上の理由により、アクセントと音長では連符への依存性が 違うので、音長とは違う仕様のほうが自然なのでは？と思ったわけです。 しかし、Muse の文法って連符全体へのアクセント指定も許しているんですよね。 この２つのアクセント指定を共存させるとなると、スコープ式の定義以上に シンプルな定義は難しいのですね・・・。 （あと、毎度毎度、些細ともいえる問題に長文でレスしてしまって、スミマセン・・・(笑)） ＃ところで今気づいたのですが、スコープ式の定義にした場合、 譜面モニタで強弱を見た場合に問題になりませんか？ 譜面モニタで「w」とだけ表示されているのに、譜面モニタでひとつ前にある アクセント量とは違う再生がされるという状況もありうると思います。 これも想定の範囲内でしょうか？
[8854] Re[4]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/09(Tue) 22:22:14 > しかし、Muse の文法って連符全体へのアクセント指定も許しているんですよね。 > この２つのアクセント指定を共存させるとなると、スコープ式の定義以上に > シンプルな定義は難しいのですね・・・。 そうなんです。 それにしても、流石Elekenさんですね。 １を聞いて１０も１００もご理解されているご様子に感服します。 私が何週間も考えたテーマを小一時間で解き明かしているみたいです。 > 私の中では、アクセント "w" とは楽譜でいう "＞" や "∧" のような、音符１つに対して > 表現上の効果を及ぼす記号のイメージでした。 > これは連符内にあろうがなかろうが、同じ記号は同じ意味ですよね。 > ゆえに、アクセント指定子は連符とは独立であるべきと思ったわけです。 本当は、このElekenさんのイメージが最もシンプルで美しいのかもしれません。 私が、アクセントを連符や和音の括弧全体に掛けることができるという 欲張りな仕様にしたため、事を複雑にしてしまった模様です。(苦笑) 複数音からなる装飾がある時、それを連符で書くと音長の調整も楽なのですが、 そこに一括してアクセントを付けたくなるんです。 時折、和音にガツンとアクセントを付けたくなる時もありますし・・・。 そのために、この欲張り仕様にしてしまいました。 >（あと、毎度毎度、些細ともいえる問題に長文でレスしてしまって、スミマセン・・・(笑)） いえいえ、私も長文ですのでお互い様ですし、読んでて楽しいです。 それに「些細」では無いと思います。 なにせ今回の非互換データ数ダントツの案件ですから。 ちなみに、今最終調整に入っているのですが、未だにバグがちらほら見つかりまして(苦笑)。 で、別件ですがまた仕様が変更されてしまいました。 「�ハ�符内和音のアルペジオ」です。 これも無視しがたい量の非互換データ数になってしまいましたorz。 アクセントもさることながら、こちらは結構曲想に影響があるので、 私にとってはこちらの方が心が痛いです(苦笑)。 > ＃ところで今気づいたのですが、スコープ式の定義にした場合、 > 譜面モニタで強弱を見た場合に問題になりませんか？ > 譜面モニタで「w」とだけ表示されているのに、譜面モニタでひとつ前にある > アクセント量とは違う再生がされるという状況もありうると思います。 > これも想定の範囲内でしょうか？ 想定範囲といえばかっこいいですが・・・。 本件は、お許し下さいっていう感じです(笑)。 そもそも、vとwを足さないと本当の強弱値がわからないですし。 まあ、譜面モニタの属性表示は、他にも曖昧な部分が多々ありまして、 打ち込んだ文字をそのまま出すことで位置ズレを確認するといったレベルです。 あくまでもMusing支援用とお考え頂けると幸いです。 私はよく行内の場所がわからなくなると、w+1 w+2 w+3 などと仮挿入して、 デバックライトとして使ってます(笑)。 なんにしても、貴重なご意見ありがとうございました。 情報公開してよかったです。 また何かお気づきの点あれば言って下さい。 必要なら、作り直す覚悟もありますので。
[8856] Re[5]: 次期Museにおける文法非互換情報 投稿者：Eleken 投稿日：2013/04/09(Tue) 23:28:48 > 複数音からなる装飾がある時、それを連符で書くと音長の調整も楽なのですが、 > そこに一括してアクセントを付けたくなるんです。 いまいちわからなかった連符に対するアクセントの存在意義は、こういうことだったのですか。 なるほど確かに、そういうシチュエーションはよくありますね。 ちなみに私は今まで連符へのアクセントの代わりに、両端に v を付けて、 v-20 (drmf)16 v+20 s4 などと書いていました。 そうしないと、(drmf) のどれかに「相対的な」アクセントをあとで追加したくなったとき、 v-20 (dw-20rmf)16 v+20 s4 という具合に書けないものですから。 > それに「些細」では無いと思います。 > なにせ今回の非互換データ数ダントツの案件ですから。 そうですね・・・。 今一度自分の過去のデータを見直していて、互換性のない記述の多さに辟易してしまいそうです。 たとえば、ドラムスパートだけ見ても、こんな感じです。 #Z0|,8__, (_w-40,),_w, |,8__, (_w-40,),__ |w-20,8___ ,(_w,)(_,)_ #Z1|_8_,(_w-50,) __,(_w,)|_8_,(_w-50,) __,_ |_8_,(_w-50,) __,(_w,) これは、ヤバそうな感じです。 > で、別件ですがまた仕様が変更されてしまいました。 > 「�ハ�符内和音のアルペジオ」です。 > これも無視しがたい量の非互換データ数になってしまいましたorz。 > アクセントもさることながら、こちらは結構曲想に影響があるので、 > 私にとってはこちらの方が心が痛いです(苦笑)。 むしろ、今までアルペジオは連符でスケーリングされていたということに初めて気づきました(笑)。 というより、すべての遅延表記はスケーリングされていたのですね。 いや〜、何かがおかしいとは思っていたのですが(笑)。 こっちの変更は、データによっては大変なことになっていそうですね。 > まあ、譜面モニタの属性表示は、他にも曖昧な部分が多々ありまして、 > 打ち込んだ文字をそのまま出すことで位置ズレを確認するといったレベルです。 > あくまでもMusing支援用とお考え頂けると幸いです。 なるほど、デバッグ用途の趣が強いわけですね。納得です。 > なんにしても、貴重なご意見ありがとうございました。 > 情報公開してよかったです。 そう言って頂けると嬉しいです。 忌憚なく勝手気ままに発言していますが、さすがにあるものを作り直せとまでは要求しませんので(笑)、 １ユーザのたわごととして聞き流して頂ければ幸いです。
[8857] Re[6]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/10(Wed) 00:02:33 > #Z0|,8__, (_w-40,),_w, |,8__, (_w-40,),__ |w-20,8___ ,(_w,)(_,)_ > #Z1|_8_,(_w-50,) __,(_w,)|_8_,(_w-50,) __,_ |_8_,(_w-50,) __,(_w,) > これは、ヤバそうな感じです。 う〜む。やっぱり罪悪感を感じるなぁ〜(苦笑)。 今まで皆さんが精魂込めて創り上げた演奏ですからねぇ〜。 上記は、具体的なアクセント値が書いてあるものは大丈夫ですが、 そうでないwのみの記述は、１つ１つ指定することになりそうですね。 ・・・やはり、どうにかして互換を維持した方が良いでしょうか。 例えば、アクセント値は連符や和音のスコープを無視して、一直線に継承される。 ただし、連符や和音の直前に掛かるアクセント指定はその連符や和音の要素全体に作用する。 その際、連符や和音の途中でアクセント値が切り替わった場合は、 その場でアクセント値が切り替わる。 これなら互換を保ちつつシンプルでしょうか。 譜面モニタの表示も、現在考えている仕様よりは信憑性も増しそうですし・・・。 > そうしないと、(drmf) のどれかに「相対的な」アクセントをあとで追加したくなったとき、 > v-20 (dw-20rmf)16 v+20 s4 新しい一直線継承の仕様ならば、 w-20 (dw-40rw-20mf)16 s4 と書けそうですね。 連符内では、アクセントが v の役目をする所が逆説的ですけど(笑)。
[8860] Re[7]: 次期Museにおける文法非互換情報 投稿者：Eleken 投稿日：2013/04/10(Wed) 21:05:45 何度もすみません・・・。 > 新しい一直線継承の仕様ならば、 > w-20 (dw-40rw-20mf)16 s4 > と書けそうですね。 > 連符内では、アクセントが v の役目をする所が逆説的ですけど(笑)。 群音への "w-20" って「群音内の v を -20 する」ではなくて、 「初期アクセント値 -20 をセットした上で、群音内の全ての音に "w" を付加する」という意味なんですね！（勘違いしてました） だから、こういうような逆説的な表記になるわけなんですね。 これは「周りの音より 20 だけ小さい音」を表現するのに "w-40" と記述しているのが、何か少し妙な感じがします。 私の感覚では、群音への "w" と音符への "w" は、違うローマ字を割り振りたいくらい違うものに感じます。 （ローマ字は 26 個しかないので、わがままは言えないのですが） もしかしたら、アクセントの重ねがけをできるようにしたらうまく行くのかな・・・？ 上記の例は w-20 (dw-20rmfs)16 s4 と書きたいです。 重ねがけに加えて「w の省略は時間的に前の w の値を使う」とでもすれば、互換性はだいぶましになると思います。 そんなことをしたら、Muse のインタプリタ(を書く人)に大きな負担を強いることになりそうですが・・・(苦笑) > ・・・やはり、どうにかして互換を維持した方が良いでしょうか。 私のデータでは、ゴーストノートがゾンビノートになってしまいかねない変更なので(笑)、ちょっと意見してしまったのですが、 答えのない問題なので、開発者さんの一存にお任せします！ あと、言い忘れていたのですが、アルペジオだけは連符でスケーリングしない という新仕様に関しては、自然で合理的であるように私も感じています。 こっちの仕様変更は積極的に賛成です！
[8862] Re[8]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/10(Wed) 22:17:30 Elekenさん >> 新しい一直線継承の仕様ならば、 >> w-20 (dw-40rw-20mf)16 s4 >> と書けそうですね。 > それに「周りの音より 20 だけ小さい音」を表現するのに "w-40" と記述しているのも、何かおかしい気ようながします。 あはははっ。確かに。 本件は、ちょっとした思い付きでした。忘れて下さい(苦笑)。 アクセントの重ねがけというElekenさんの煌くような発想は、次々版の楽しみに取っておくとして、 今回の非互換アクセント仕様（つまりスコープ方式）についてです。 あれからもう一度熟考いたしまして、やはり冒頭でElekenさんから頂いた案に近い、 「一直線の継承方式」に再編することに腹をくくりました。 この部分、作り直します！ この一直線仕様を再掲しますと ・アクセント値は連符や和音の括弧(スコープ)を貫いて、一直線に継承される。 ・ただし、連符や和音の直前に掛かるアクセント指定はその連符や和音の要素全体に作用する。 ・連符や和音の途中でアクセント値が切り替わった場合も、その場でアクセント値が切り替わる。 となります。 これでデータ互換は維持され、 �┠臆擦乏櫃�るアクセント ��群音内で指定したアクセントの値 の非互換リスト項目は、撤廃できるわけです。(祝) また、この方式ならば、現在のアクセント値で迷子になることも無いと思います。 なんせ一直線ですから(笑)。 この案の採用に踏み切った一番の理由は、 「考えてみると、w の親分にあたる v だって、一直線じゃん」 です。 > あと、言い忘れていたのですが、アルペジオだけは連符でスケーリングしない > という新仕様に関しては、自然で合理的であるように私も感じています。 > こっちの仕様変更は積極的に賛成です！ ご賛同頂き、嬉しいです＼(^o^)／ 実際に、ギターストロークなどで試してみると、 @P25 [dmsc<m>]2:i30(,:,:,:) ,: と完全に省略して書いても自然な感じであることがわかります。 現在のMuse(V6.3x)では、連符内では別途微調した値を指定しないとちょっぴり不自然な感じです。 まあ、微分音長レベルの話なので、注意深く聴かないと分からないごく僅かな差なんですけど。 8,333データ中212データの非互換が生じますが、お許しいただきたいと思います。 ※それと、連符内でスケーリングしないコマンドがもう一つありました。 テンポの遅延です。これは、本来はスケーリングした方が良いと思うのですが、 プログラミングの都合上、対応が難しいので断念しています。ご容赦下さい。 あとこれは蛇足です。 今回非互換状況を色々と調査してみて気づいたのですが、 和音の逆アルペジオを書いているデータがあるということです。 [dms]4:32- なんと100を越えるデータがありました。 現時点のMuseでは、エラーにせず正順アルペジオとして演奏しています。 これらのデータは次回のMuseから自動的に逆アルペジオで演奏を始めます。 かなり以前のデータが多いのですが、これって遠い未来のMuseを予測してたの！？(笑)
[8863] Re[9]: 次期Museにおける文法非互換情報 投稿者：Eleken 投稿日：2013/04/10(Wed) 23:13:28 > 「一直線の継承方式」に再編することに腹をくくりました。 これまで通り、アクセントは連符に対して独立になるということですね。 これで、私のデータのゴーストノートも生き返ってゾンビノート(笑)にならず済むわけで、ほっとしております。 > 和音の逆アルペジオを書いているデータがあるということです。 > なんと100を越えるデータがありました。 > かなり以前のデータが多いのですが、これって遠い未来のMuseを予測してたの！？(笑) 流石の一言ですね。 今まで私の意見に対し、いろいろとご検討頂き、何度も長文で返信を下さいまして、ありがとうございました。 新バージョン楽しみにしています。 ＃蛇足ついでに・・・ プログラミングもさることながら、マニュアルの改訂も大変そうに思いますが、 マニュアル 4567 行目の "sus2" は 4565 行目にあるべきかと思うので、改訂ついでに修正して頂ければと思います。
[8864] Re[10]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/11(Thu) 00:00:07 > > 「一直線の継承方式」に再編することに腹をくくりました。 > これまで通り、アクセントは連符に対して独立になるということですね。 はい。Elekenさんの設計思想を採用させて頂きました。 本当にありがとうございます。 > 今まで私の意見に対し、いろいろとご検討頂き、何度も長文で返信を下さいまして、ありがとうございました。 とんでもありません。 Elekenさんの書込みが、より良い仕様へと私を導いてくれました。 そして何より、５００以上のデータを非互換から救ったのです！ > プログラミングもさることながら、マニュアルの改訂も大変そうに思いますが、 > マニュアル 4567 行目の "sus2" は 4565 行目にあるべきかと思うので、改訂ついでに修正して頂ければと思います。 ご指摘、ありがとうございます！ 今後とも、よろしくお願いいたします。
以降は話題が別のテーマに移行しているが、興味深いため掲載する。
[8865] Re[9]: 次期Museにおける文法非互換情報 投稿者：浅川 投稿日：2013/04/11(Thu) 06:55:40 横からすみません > ※それと、連符内でスケーリングしないコマンドがもう一つありました。 > テンポの遅延です。これは、本来はスケーリングした方が良いと思うのですが、 > プログラミングの都合上、対応が難しいので断念しています。ご容赦下さい。 いずれぜひ対応していただきたい機能ですね...。 気長に待っています。 特にアドリブ部分などが編集しやくなりそうです。 http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/
[8866] Re[10]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/11(Thu) 19:21:03 浅川さん テンポ遅延の連符内スケーリングの件。 > いずれぜひ対応していただきたい機能ですね...。 > 気長に待っています。 > 特にアドリブ部分などが編集しやくなりそうです。 自分でも「やるべき」と思っており、そしてそれを待っている人がいる・・・。 そうなると、たとえ技術的障壁が高くても頑張って登ってみたくなります！ 浅川さんに背中を押されたので、挑戦してみます。 いつもなら、検討リストに入れて次々版以降でゆるりと対応なのですが、 本件は、今話題の非互換性をはらんでいますよね。 だとしたら、この機に乗じてやってしまいたい気分です。 ざっと確認してみたところ、8,333曲中98データが非互換に引っ掛りそうです。 ただ、内容を見ると連符内スケーリングを期待してコーディングされているものも多々ありそうです。 またしても、未来のMuseを予見していたのかっ！(笑)
[8858] Re[6]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/10(Wed) 00:19:17 > むしろ、今までアルペジオは連符でスケーリングされていたということに初めて気づきました(笑)。 > というより、すべての遅延表記はスケーリングされていたのですね。 はい。 属性の遅延指定は、以前はスケーリングされていなかったのですが、昔、あるミューザーの方に指摘されて改良した覚えがあります。 アルペジオをサポートしたのは更にその後なのですが、単に対称性だけでアルペジオもスケーリングしてしまったのが、 私の設計ミスだったと反省しています。 連符内に書かれた強弱などの属性は、確かにスケーリングした方が把握しやすいし、 再現表記などでの使いまわしがしやすいと思うのですが、 アルペジオの方はスケーリングすると指定が大変厄介です。 前者はいくつもの音符に掛かる時間を相対的な感覚で指定するのに対し、 後者は絶対的な時間のズレを維持したい場合が多いからだと思います。 > いや〜、何かがおかしいとは思っていたのですが(笑)。 > こっちの変更は、データによっては大変なことになっていそうですね。 そうなんですよねぇ〜。 でも、こちらの方は互換を崩しても変更に踏み切りたい気分です。 困りました(笑)。 ★追伸： よくよく考えてみたら、属性の遅延値については連符内のスケーリングが必須ですね。 例えば、１１連符の３音目から７音目までの間で遅延を使って滑らかに音を大きくしたい、 なんていう要請に応えるには、スケーリングが無いと大変です。
[8873] Re[2]: 次期Museにおける文法非互換情報 投稿者：開発者 投稿日：2013/04/13(Sat) 09:26:15 もう１つ非互換を伴う仕様変更を追加しました（してしまいました）苦笑 ��フィンガー宣言によるアクセント指定の継承性 http://musewiki.dip.jp/MuseWiki/index.php?V6.4%A4%CB%A4%AA%A4%B1%A4%EB%C8%F3%B8%DF%B4%B9%BB%C5%CD%CD それと、現時点での非互換データリストをアップしました。 http://www1.c3-net.ne.jp/kato/data/list.txt ・ファイル名は、私の感性で変更してしまっているものがあります。 ・殿堂入りしていないデータも含んでいます。 ・非互換項目が多岐に渡っているため、多少漏れがあるかもしれません。 ・非互換のほとんどは、連符内アルペジオの音長だと思います。
