![[PukiWiki]](/MuseWiki/wiki_baner.png "[PukiWiki]")
|
Muse Ver.5.2よりpqを指定してあっても連結するようになった。 これについてのMuse掲示板での議論は以下の通りである。 [5094] Re[1]: ●●●いきなりV5.21のご報告(笑)●●●
投稿者：σ 投稿日：2007/10/13(Sat) 10:12:07
恐縮ですが，修正直後の新たなバグ報告です．
連結コマンド"&"の仕様が，
スタッカートや止音指定"q"でも有効になるように変更になり，
自分はp,q指定を多用するので，
今回の更新で&が使えるようになったのはかなり嬉しいのですが，
次のようなコードではうまく機能しません．
*FING"x1 q~64"
#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分音符刻みにする）とちゃんと音がつながる．
などが判っています．
[5095] Re[2]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/13(Sat) 10:51:09 σ 様 障害報告、ありがとうございます。 確実な再現性を確認しましたので、明らかに今回のMuseのバグです。 しかも、自分としてはかなり致命的な部類に入ります。 できるだけ速やかな対処をしたいと思います。 しかし、正直とてつもなく不可解な現象に戸惑っています。 この手の症状は、大概の場合 極めて単純なプログラムミスか、あるいは根の深い解決難航の仕様問題の どちらかです。前者であることを祈りつつ、これから障害解析に入ります。 > 恐縮ですが，修正直後の新たなバグ報告です． とんでもございません。 いくつかの状況も添えた報告を頂き、大変感謝しています。 心から御礼申し上げます。 これからも、よろしくお願いします。 [5097] Re[3]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：σ 投稿日：2007/10/13(Sat) 22:45:36 やはり，複雑な挙動ゆえ根深いバグである可能性がありますか... 自分としては見守るぐらいしか出来ませんが， いずれにせよ単純なバグであることを祈っています． （最も，自分が祈ると大概裏目に出てしまうのですが...今日も阪神負けたし． まぁ，私の祈りは余り気にしないでください(笑)） >>恐縮ですが，修正直後の新たなバグ報告です． > とんでもございません。 > いくつかの状況も添えた報告を頂き、大変感謝しています。 > 心から御礼申し上げます。 実は，今朝このページを見て v5.20 が出ていることに気付き，早速導入し， & コマンドの手持ちの Muse ファイルとの互換性をチェックしていました． 自分は p,q 指定を多用しているので，& コマンドを使用しているファイルが 1つしか無かったのですが，その1箇所でこのバグを見つけました． 早速，発生条件を調べて，報告しようと再びこのページを見ると， いきなり v5.21 が出ていたので， 修正後いきなりバグ報告もどうかとちょっとためらってしまいました． [5098] Re[4]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 00:22:37 σ様 返信と心強い祈り(笑)ありがとうございます。 中間報告です。 お陰様で、挙動の全貌と症状の根本原因がわかりました。 したがって、pqやスタッカートに影響されない連結＆の処理方法もすぐに導け、 実際に仮実装まで終わっています。 ただし、音符単位(正確に言うと一つの音符毎にONとOFFの２つずつ)の総当たり処理となり、 コンパイル処理が実用に耐えられない程遅くなってしまいました。 Museは、ロード時にファイルを読むだけでなく、Museデータの解析も一気に行っています。 よってコンパイルが遅いと、ユーザには「ロード時間がかかる」と感じられます。 私の第九データはV5.21では１秒程度でロード＋コンパイルが完了していたのですが、 今の仮実装では７５秒もかかってしまいました。 話になりません。これでは使いものになりません。 どうにかして、完全性のある高速処理を捻出しなければならい。 ・・・継続して考えます。 阪神が勝てば、うまく行く気がするのですが・・・(苦笑) [5099] Re[5]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：るう 投稿日：2007/10/14(Sun) 03:06:30 単純な総当りではなく、二分木を使ってみてはいかがでしょうか？ 総当りの時と比べると、O(n^2)→O(log n)と、大幅な時間短縮が実現できるはずです。 [5100] Re[5]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/14(Sun) 05:05:16 加藤様 すっかりご無沙汰しておりましたが、バージョンアップおめでとうございます。 最近は新機能のテストすらままならない状態だったのですが、マイナー更新も含め 最新MuseのDLだけは欠かさないようにしておりました。 久々の投稿でこんなことを申し上げるのはどうかとも思ったのですが、 僭越ながら今回の更新で一つ気になったことを述べさせていただきます。 今まさに掲示板で話題になっている&の連結の仕様変更ですが、 相当面倒な検証作業を経ての実装と思いますから、大変申し上げ にくいのですが、正直なところ私には以前の仕様の方が分かり易かったです。 あまりにブランクが出来てしまって、以前かなり研究していた ここら辺の正確な仕様も忘れてしまいましたが、基本的には、 以前は&の前に同タイミングでオフとなる記述があれば連結するという シンプルなものだったと思います。 ところが、今回の仕様変更ではコーディング時の一つ一つの音の記述の 連結という意味合いにかわってしまいました。これはごく一般的な 記述作業では確かに記述の簡便化は期待できると思うのですが… むしろ、&で連結される手前の音に関するスタッカートやpqの指定について、 連結されたときに、どれが連結後有効なものでどれが無効なものか、 入力時に非常に解釈がややこしくなりそうな気がします。さらに 和音などをトリッキーに用いた場合の様々な例外処理を考えますと、 Muse内部の処理もまさに > 音符単位(正確に言うと一つの音符毎にONとOFFの２つずつ)の総当たり処理と せざるを得ない気がしますし、入力側も凝ったデータを作っていると 記述量は減っても、思考量は逆に増えてしまうような気がするのです。 以前なら新旧仕様を正確に把握した上で徹底的に検証作業を 行っていたところなのですが、今の私にはその時間と気力が ありません。申し訳ありません。ただ、休符代わりに スタッカートを使って記述をシンプルにしたデータ等の互換性が 崩れることがどうも気になりますし、記述の仕方に依存する 仕様はバグの取れた統一的なものが出来ても、入力時に&の効果が 直感に反する例が多々出てきそうな気がするのです。 x2[c2//]4&c これとかがまぁ新旧で互換性の崩れる例ですが（こんな記述は 実際にはまずあり得ませんが）、こういう風に何かと 入り組んできますと、むしろ旧来の仕様の方がすっきりするような 気がいたしまして… pqが絡むとさらに厄介な気がします。 新仕様を正確に把握しておりませんので、具体例は出せませんが （連結する部分以外のpqの機能の仕方が気になるところです。そこに さらに連結された場合なども）、まぁとにかくどうもすっきりしません。 こんなことを考えるのは、まぁ必要以上にコーディングに こだわるごく一部の人間だけでしょうが、私にはどうしても 旧来の仕様の方が統一感があって美しく思えてしまいます… 十分に検証もしないまま失礼なことを申し上げてすみません。 ただ上位互換を崩してまで行うべき「改良」なのか 私には少し疑問が残ります。 改版履歴を見てどうも気になったので、最低限のテストを 行った上で書き込みさせていただきましたが、加藤さんは どの様にお考えになりますか？ 加藤さんのことですから、これについても何らかの加藤さんの 信念に基づいた仕様変更なのだと存じますが、あまりに 内部処理まで煩雑にしてしまうようでしたら、そこまでして 互換性を崩すこともないのではないかと思わざるを得ないのです。 久々のコメントがこんなもので申し訳ありません。 問題提起した以上これについては、何とか時間を見つけて Muse文法をさらった上で、感覚的問題の生じそうな例を いくつか検証してみようと思います。 [5101] Re[6]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 10:18:09 ■るう様 アイディアありがとうございます！ ただ、二分木もそう簡単に採用できません。 理由は、 (1)二分木を構成するにはソーティングキーが必要ですが、 今回の場合、そのキーの抽出自体が難しい。 (2)仮に何らかの抽出の手段を見つけたとしても、 二分木そのものを構築する処理自体に時間がかかる恐れがある。 です。 ここは、Museデータロード時に順次読み込む各情報をうまく活用しながら 連結処理のための下準備をするといった、Muse独自の情報量の工夫が必要だと 思っています。もう少し考えます。 ■岡林様 お久しぶりです！ また書き込みを頂いて、とても嬉しいです。 しかも凄い長文。されど一気に読んでしまいました。 岡林さんの文章は論理的で、長さが気になりません。素晴らしいです。 さて、本題です。 正直、今回のpqスタッカート非依存連結＆の仕様よりも、 旧仕様の方が良いとする考えが存在することに思いも寄りませんでした。(苦笑) コーディング簡便性に関する議論を置いておくと、 確かに仕様の明快さは旧仕様の方が優れているのかもしれません。 この辺は、また皆さんのご意見も頂きながら、更に深く考察し、 いざとなれば、元に戻すこともやぶさかでは御座いません。 互換性が多少崩れる部分で、あまり頻繁に行き来したくないですが・・・(笑) ただ、今回は２つの理由から、 まずはとことん非依存連結の仕様で作り込んでみようと考えています。 (1)今の状態で元に戻したら、ある山の山頂を目指した登山家が途中で引き返し、 「あの山は登るべき山ではなかった」と負け惜しみを言うようで気分が悪い。 (2)非依存連結に関しては、当初より実施したかった仕様であるが、面倒臭いので 制約とさせてもらっていた。決して「敢えて」そうしていた訳ではない。 旧仕様と非依存連結仕様の優劣を決めるためにも、完全性のあるMuseを 一旦作る必要があると考える。処理速度も含めた比較をする意味でも。 [5102] Re[7]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：nagopa 投稿日：2007/10/14(Sun) 11:00:17 加藤さん、岡林さん、お久しぶりです。 岡林さんとほぼ同じ立場(昔のMuser)から別の意見を述べます。 私は、今回の仕様変更に全面的に賛成です。 [1] スタッカートやｑ指定の音符に連結＆を効果させる件 [1.1] 互換性について d4//d&d 従来のデータに上記のような記述があったとして、作者の意図には、一応2つ の解釈ができます。 (a) 連結されることを期待して書き、連結されないことに気が付かなかった。 (b) 連結されないことを承知で意図的に書いた。 可能性が高いのは(a)だと思います。というのは、(b)のように意図的に書く理 由が思いつかないからです。従って、理由がみつかれば、仕様変更に対する意 見も変わるかもしれません。 (a)の可能性が高いとすると、今回の仕様変更により作者の意図通りに鳴るよ うになるので、良いと思います。 [1.2] 分かりやすさについて これは人により異なると思うので、岡林さんの意見への反論はありません。 自分の感覚で述べますと、 ・属性であるqよりも、直接的な記述の&が優先される方が分かりやすい。 ・音長に対する補助記述である//よりも、音符に対する補助記述の&を優先す る方が分かりやすい。 従って、今回の仕様の方が分かりやすいです。 [2] 和音内の＆記述 [2.1] 互換性について [dm&s]4[dms] 上記の記述で、従来はdmの両方が結合されたのが、今回はmだけが連結されま すので、互換性は崩れています。この件に関しても、６千曲のMuseデータに対 するバイナリレベルでの一致を確認されているのでしょうか。 自分が作ったデータでは、問題となるところはありませんでした。 一箇所だけ、[f+c2.&]2s4 というのがあったのですが、なぜ&があるのか意味 不明です(笑)。 [2.2] 分かりやすさについて 最初は従来の「“&”記号の前方にある和音内のすべての音符が連結対象とな る」方が分かりやすいと思ったのですが、前記の例のように真ん中の音だけを 連結しようとすると、従来の仕様では、 [m&ds]4[dms] と、音符の順番を変えなければならないので、今回の仕様の方が書きやすいで すね。 ただ、開発後記の、 「今までは、音尾部分の音長を調整することで和音内の連結を一音毎に制御す ることが出来たのですが、今回の改訂でそれが出来なくなったためです。」 この記述の意味が分かりません。多分、内部的な処理のことを書かれているの でしょうが、外部的には、「今までは和音内の連結を一音毎に指定することが できなかったのを、できるようにした」という理解で良いでしょうか。 [5105] Re[8]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 15:42:49 nagopa様 お久しぶりです！nagopaさん！！ 岡林さんといい、nagopaさんといい、 こうしてMuseの真髄とも言える記述解釈問題を通じて、 旧友あいまみえることに痺れるような快感を感じています。 αさんのお陰ですね。 障害追跡の最中ですので、 快感に酔いしれている場合ではないのですが・・・(苦笑) でも、このような形で深い検討と考察を共に出来る同志を持っているということは、 開発者としてこれほどの幸せはありません。 お二人とも、かなり核心をついたポイントを、実に明晰な論理で突いて頂いており、 私は、皿のソースをすべて平らげてもらったフランス料理人のような気分でいます。 さて、現在の作業進捗報告です。 今、処理速度も前バージョンと同等を維持した状態で、 非依存連結仕様の完全版ができました！ 代償としてはロード時に多少メモリを食いますが、 そもそもMuseは、当初からメモリ節約を心掛けた作りをしておりますので、 ２１世紀の巷のソフトに比べればゴミのようなものだと思います。(笑) しかも、ロード＋コンパイル直後に、 ちゃんとワークメモリを解放するようにしておきました。 それらの処理も含め、充分実用域の速度に達していると思います。 更に、今回の対処の中で、また仕様を変更してしまいました。 ・・・マイナーバージョンなのに、こんな改変をしていいのだろうか？ でもまあ、フリーソフトですからお許し下さい(苦笑) 改変内容は以下の通りです。 ----- 従来の連結＆は、フィンガーを越えて同一メンバー内に作用していたが、 今回の仕様は、同一フィンガー内でのみ効果する。 ----- 実はこの仕様も、V5.20段階で一気に盛り込みたかったのですが、 コンパイル解析の改修が大掛かりになるために尻込みしていました。 今回、障害レベルの対応で、大掛かり改修をせざるを得ないことになりましたので、 一気に片付けてしまいました。 新仕様の議論をしている最中に、 更に新しい議事テーマを追加して心苦しいですが、 本件も含めてご意見頂ければ幸いです。 もう少しテストしてから、V5.22をリリースします。 以下、nagopaさんの問い掛けへの回答です。 ‖[dm&s]4[dms] ‖上記の記述で、従来はdmの両方が結合されたのが、今回はmだけが連結されま ‖すので、互換性は崩れています。この件に関しても、６千曲のMuseデータに対 ‖するバイナリレベルでの一致を確認されているのでしょうか。 ‖ 申し訳ありません。 明らかに互換性が崩れることがわかっていたので、確認しませんでした。 Readme.txtに書いた一致確認テストは、全音域対応のみ行った段階で実施しました。 これは完全互換であるはずですので、テストにより不備がないか検証したかったのです。 ただし、姑息ではありますが自分のデータだけは連結＆の互換テストをしました。 ラフマニノフのピアノ協奏曲で一ヶ所互換が崩れるところがありました。(苦笑) ‖「今までは、音尾部分の音長を調整することで和音内の連結を一音毎に制御す ‖ることが出来たのですが、今回の改訂でそれが出来なくなったためです。」 ‖この記述の意味が分かりません。 ‖ 妙に意味深で、わかりにくい文章を綴ってしまい赤面の至りです。 従来の仕様では、 [d4m/...s4]&[dms] などとすると、ドとソだけ連結させることができます。 私は過去、この記述をよく使いました。上記Readme.txtの行はそれを表しています。 でも今にして思えば、和音内に記述する音符の順番を考慮すれば、 従来の仕様でも充分一音毎に制御可能ですね。→ [ds&m] [dms] 開発時点で私が何を勘違いしたのか、それとももっと何か考えがあったのか、 はたまた非依存連結のプログラム作成時点でなんらかの不都合が存在したのか、 実は・・・わからなくなってしまいました。 私の脳細胞、アルツハイマーが微量混入し始めているかもしれません(苦笑) [5103] Re[7]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/14(Sun) 15:28:43 nagopa様本当にご無沙汰しております。 もしかしたらこの話題にはnagopaさんは食いつかれるのではと 思っていたのですが、期待通りの鋭い分析に感嘆しております。 nagopaさんの仰っていることは、概ね私も考えていたことですので、 特に反論はありません。文法面から眺めるとnagopaさんの仰るように 新仕様が妥当のように思いますし、何より加藤さんが >(2)非依存連結に関しては、当初より実施したかった仕様であるが、面倒臭いので > 制約とさせてもらっていた。決して「敢えて」そうしていた訳ではない。 > 旧仕様と非依存連結仕様の優劣を決めるためにも、完全性のあるMuseを > 一旦作る必要があると考える。処理速度も含めた比較をする意味でも。 とお考えだったのであれば、私はこれ以上旧仕様に固執するつもりもありません。 ただ、スタッカートはまだしも >・属性であるqよりも、直接的な記述の&が優先される方が分かりやすい。 というのはある意味では同じ考えなのですが、同時に pqはあまりにも強烈な効果（特に+と^）を持っていて、 部分的に無効にして不自然な事例が起こらないだろうかと 少々心配なところがあったのです。 どうも、テストデータでさえ作るのが久しぶり過ぎて まだめぼしい場面での挙動すら確認しきれてはいないのですが、 バグと考えるべきものは一つ確認できました。 x2 p0q^8[ceg]2&p~16[cfa]_ p0q~8[ceg]2&p~16[cfa]_ 旧来の仕様ではドの音は両方とも連結しませんが、新バージョンでは 最初の和音は連結せず、後のものは連結します。 これは新仕様では両方連結すべきと考えますが、 何とも言えない違和感を感じなくもありません。 （既に掲示板にあがった件でもう修正済みかもしれませんが） 結局の所、慣れた仕様が変更されるのが嫌なだけかもしれません（苦笑）。 もう少し色々な場面について検証してみますが、現在の所、新仕様で 不自然な現象が起こりそうなところは、適切な処理が為されている ようです（例外は上に挙げたものぐらいです）。 お騒がせして申し訳ありませんm(_ _)m [5104] Re[8]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/14(Sun) 15:41:07 ＜補足＞ さっきのテストデータは色々試しているときに出来たものですので この現象だけを考えるなら、こっちの方が簡明かもしれません。 x2 p0q^8[ceg]2&,_ p0q~8, &,_ [5106] Re[8]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 15:56:14 > バグと考えるべきものは一つ確認できました。 > > x2 > p0q^8[ceg]2&p~16[cfa]_ > p0q~8[ceg]2&p~16[cfa]_ > > 旧来の仕様ではドの音は両方とも連結しませんが、新バージョンでは > 最初の和音は連結せず、後のものは連結します。 ありがとうございます。岡林さん。 大変込み入った処理を施していますので、こういった検証データがとても欲しかったところでした。 頂いたパターンは、現在手元にあるV5.22βにて、両方とも綺麗に連結することを確認しています。 リリースに向けて一層自信がつきました。 心から感謝いたします。 [5107] Re[9]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/14(Sun) 17:18:49 > 大変込み入った処理を施していますので、こういった検証データがとても欲しかったところでした。 > 頂いたパターンは、現在手元にあるV5.22βにて、両方とも綺麗に連結することを確認しています。 かなり悪趣味な検証データを作ってみましたので、 これがうまく動作するかもご確認いただけますか？ V5.21ではやはりドの音が連結しませんが、新仕様ならば 連結して全音符の長さでならねばならないはずです。 x2 *TEXT"実際の出力" _1p^2q~2 [ceg]4p0q0&c_p^1q~1&[eg]4 p0q0 *TEXT"新仕様でのしかるべき出力" [c1e4g]4[eg]_1 *TEXT"旧仕様での出力" [c4e2g]2_4c_2 私の新仕様に感じていた気持ち悪さはこのデータの気持ち悪さに ほぼ集約されています。もっというと、pqの効果で完全に前後関係が 狂った場合の&の挙動、&の後の連結される音のオフのタイミングが 連結前の音オフの手前になったときの挙動などが気になるところです。 こういうのがごちゃごちゃするのでそもそもpqと言うのがあまり 好きではないのですが、これなら偶然出来た仕様とはいえ &の直前のオフが同じタイミングの方がシンプルですっきりするように 感じてしまうのですよね… [5108] Re[10]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 17:41:12 > かなり悪趣味な検証データを作ってみましたので、 > これがうまく動作するかもご確認いただけますか？ お陰様で、うまく行っているようです。 ↓ http://www1.c3-net.ne.jp/kato/data/chain.png > こういうのがごちゃごちゃするのでそもそもpqと言うのがあまり > 好きではないのですが、これなら偶然出来た仕様とはいえ > &の直前のオフが同じタイミングの方がシンプルですっきりするように > 感じてしまうのですよね… なるほど、確かにpqが入り乱れると、 むしろ実発音での連結＆として見た方が挙動が把握しやすいのかもしれませんね。 ただ、pq指定が対象とするコーディング部分から離れた箇所にある場合は、 新仕様の方が直感的かもしれません。 とは言うものの、所詮pqを常に意識しておかないと、 品質の高いMusingなどできない訳だし・・・。 振り返ってみると、私自身、pqは局所的な部分にしか使ってませんねぇ〜。 怖くて、すぐにp0q0で戻してます。(笑) どちらにしろ、視点が異なるので意見が分かれるところかもしれません。 [5109] Re[11]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/14(Sun) 18:44:15 > お陰様で、うまく行っているようです。 > ↓ > http://www1.c3-net.ne.jp/kato/data/chain.png こんな妙な記述は絶対しませんから、常識的なデータなら 問題なく動作する水準になっているようですね。 > （新旧仕様に関して） > どちらにしろ、視点が異なるので意見が分かれるところかもしれません。 そうですね。私が問題にしていることは基本的には実際に Musingしている際にはまず起こらないことですから。 ちなみに下記のデータは新バージョンではどういう風に 解釈されるのでしょうか？ 一応連結される要件は 整っているはずですが、どの様に例外処理すべきかは 判断の難しいところのように思います。 x2_2 [ceg<c>]4p^2q~2&[c2.]0&[e2]0&[g4.]0&[<c4>]0_1 p0q0 [ceg]4p^8q~8&[c4.]0&[e8]0&[g16.]0_1 まぁ、こんなデータ故意に作らないと絶対に出来ませんけど（苦笑）… 因みに&をフィンガー単位というのはどうでしょう… メジャーの変更以上に深刻に互換性に関わる問題な気がします… 両手の和音がタイの場合に後の記述にまとめて&を使ってる方など いるかもしれないと思いますが… [5110] Re[12]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 19:11:52 > ちなみに下記のデータは新バージョンではどういう風に > 解釈されるのでしょうか？ ゼロ音長に関する記述ですね。 V5.22では、以下のように解釈されました。（って、他人が作ったソフトのような言いようですね）笑 ↓ http://www1.c3-net.ne.jp/kato/data/chain2.png > 因みに&をフィンガー単位というのはどうでしょう… > メジャーの変更以上に深刻に互換性に関わる問題な気がします… > 両手の和音がタイの場合に後の記述にまとめて&を使ってる方など > いるかもしれないと思いますが… 確かに、互換性問題が懸念事項です。 ただ、やるなら早い方が良いとも言えます。 また、過去のデータに対するダメージの可能性も考慮したいところです。 私の直感では、あまりダメージがないのではないかと思っているのですが、 楽観かもしれません。 それに、心を込めた大切なデータは、たとえ１曲であってもダメージはダメージですから、 どうしようかまだ迷っています。 幸いにも、フィンガーを越えての連結仕様に戻すことは、プログラム上すぐにできるように作り込んであり ます。 広く皆さんのご意見も判断材料にしたいところです。 [5112] Re[13]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/14(Sun) 19:56:47 > V5.22では、以下のように解釈されました。（って、他人が作ったソフトのような言いようですね）笑 > ↓ > http://www1.c3-net.ne.jp/kato/data/chain2.png おお、予想していたとおりです。こう解するのが 最もエレガントだと思います！ ここまで美しく 作り込まれているのなら新仕様に不満は全くありません。 ただ一つだけ…さっきのデータに組み込んでおけば良かったのですが x2_2 [ceg]4p^2q~2&[ceg]8_ これはどうなります？ エラーにするか&を無効にするか しかないだろうと考えますが… > 確かに、互換性問題が懸念事項です。 > ただ、やるなら早い方が良いとも言えます。 > また、過去のデータに対するダメージの可能性も考慮したいところです。 > 私の直感では、あまりダメージがないのではないかと思っているのですが、 > 楽観かもしれません。 確かに致命的なダメージはあまりない気もしますが、&はある種の メンバー属性と認識していたのでどうなのでしょうね。 他のMuserの皆さんはどの様に使っていらっしゃるのでしょうか… [5114] Re[14]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 22:06:31 > x2_2 > [ceg]4p^2q~2&[ceg]8_ > > これはどうなります？ エラーにするか&を無効にするか > しかないだろうと考えますが… 何とも異様な結果となりました。 ↓ http://www1.c3-net.ne.jp/kato/data/chain3.png ロードするとき、何が起こるか不安で手が震えました。(笑) しかしある意味、こういうものだと言えるかもしれません。 数学のパリティ問題のような感じですね。 この例題こそが、岡林さんの「実音での連結の方がわかりやすい」という主張を 端的に表している気がします。従来仕様は、確実に“無視”でした。 [5129] Re[15]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/16(Tue) 21:21:05 > 何とも異様な結果となりました。 > ↓ > http://www1.c3-net.ne.jp/kato/data/chain3.png > ロードするとき、何が起こるか不安で手が震えました。(笑) > しかしある意味、こういうものだと言えるかもしれません。 > 数学のパリティ問題のような感じですね。 この譜面モニタ画像だけを見ると、最もエレガントに解釈、 コンパイルされたようにも見えましたが、再生してみると… ある意味予想通りですが、これは微修正が必要かもしれません。 今回の実装では��&�△箸いΦ�述を�，琉銘屬妊�ン、�△琉銘屬妊�フ、 と言う風に内部処理されていらっしゃると、２つめのデータの モニタ画像で確信しましたが（これもV5.21とは似ても似つかない出力です）、 とするならば、この最後のデータはオフ→オンの順の処理がなされ、 同じ音をもう一度鳴らせてさらにオン→オフの命令を出さない限り ひたすら鳴りっぱなしになるのではと思っていました。実際 そうなっているようです。譜面モニタではオフとオンが逆になって 音長が表示されていますが実際にCの和音が鳴り始めるのは モニタのオフの（ように見える）位置でそれから鳴りっぱなしに なっているようです。 ある意味忠実なコンパイルとも言えますから、これでよいような気も しますが（そもそもこんな記述は実際は誰もしませんし）、 譜面モニタの表示がずれるのは少々気分が悪いですね… > この例題こそが、岡林さんの「実音での連結の方がわかりやすい」という主張を > 端的に表している気がします。従来仕様は、確実に“無視”でした。 エクスクルーシブなどを使わずに、妙な現象を引き起こせるので 面白いと言えば面白いですが、このようにコンパイルしてしまって 良いのか、難しいところですね。オンとオフがひっくり返れば なかなか粋な仕様とも思いますが、さらに&が続いた場合に 収拾がつかないような気もします（苦笑）。難しいところですね。 [5132] Re[16]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/17(Wed) 21:15:57 岡林さま > コンパイルされたようにも見えましたが、再生してみると… > ある意味予想通りですが、これは微修正が必要かもしれません。 > > 譜面モニタの表示がずれるのは少々気分が悪いですね… > > 面白いと言えば面白いですが、このようにコンパイルしてしまって > 良いのか、難しいところですね。オンとオフがひっくり返れば > なかなか粋な仕様とも思いますが、さらに&が続いた場合に > 収拾がつかないような気もします（苦笑）。難しいところですね。 仰有るとおりです。 この記述に対するV5.22のコンパイル仕様は、 やはり不味いと私も思いました。 次のマイナーアップにて「＆を無視する」仕様に変更します。 仕様としては、p指定により、前音の出音(ON)タイミングよりも、 後音の出音(ON)タイミングが先になる場合に無視します。 ※本当は、前音の出音(ON)タイミングよりも、 後音の止音(OFF)タイミングの方が先になる場合に無視する という様にしたかったのですが、プログラム上の都合で諦めました。 現在進めている６０００曲の互換統計の集計が一段落したら、 リリースするつもりです。 [5134] Re[17]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/18(Thu) 22:18:49 互換統計の集計が終わりました。(大仕事だったぁ〜) 従来仕様に対して、 ----------------------------- (A)和音内の連結＆解釈のみ新仕様にした場合 (B)連結＆の対象をフィンガー内に留めるという仕様のみ施した場合 (C)pqスタッカートに対して非依存の連結を行うという仕様のみ施した場合 (D)上記(A)(B)(C)のすべてを施した場合（すなわちV5.22) ----------------------------- という４つの互換性をチェックしました。 対象データ数：6,010 非互換となったデータ数は以下の通り、 (A) 84 (1.4%) (B) 188 (3.1%) (C) 433 (7.2%) (D) 605 (10.1%) (D)の数値が(A)+(B)+(C)と等しくないのは、 複数タイプの非互換性を同時に持ったデータが存在しているためです。 さて、 この数字を許容範囲と見るか、多いと見るかは 意見の分かれるところだと思いますが、 いくつかデータを眺めたところ、 最も多い(C)に関しても、恣意的に行っているわけでなく、 本当は接続したかったのに、 従来仕様のため、意志に反して接続していない といった風に見受けられました。（贔屓目でしょうか）苦笑 尚、どのデータが実際に互換にひっかかったかは、 http://www1.c3-net.ne.jp/kato/data/Chain_Report.txt に掲載いたしました。 ただし、 ファイル名を私自身が判別しやすいように変えてしまっているため、 殿堂でのファイル名と異なっていますし、 殿堂落ちしたデータもすべて入っています。 そこで、今度は殿堂入りしているデータを対象に、 ファイル名を殿堂ネームそのままに、 チェックして公開しようと思っています。 もうしばらくお待ち下さい。 なお、岡林さんに発見してもらった掲示板[5129]の対処版を V5.23としてリリースしました。近々、アップされると思います。 また本件に関しては、記録に残すためにも「不具合」扱いとし、 MuseWikiに事実関係を記載しておきました。 しっかし、チョーなっげースレッドになっちまったぜぃ。 タイトルのV5.21から２つもバージョン上がってるし(苦笑) [5135] Re[18]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：nagopa 投稿日：2007/10/18(Thu) 23:38:51 加藤さん、互換調査およびV5.23 お疲れ様です。 タイミングを逸してしまい、返信が遅くなりました。先日の疑問への回答ありがとうござ いました。和音内の連結の仕様を変えた理由が分かりました。 非互換で問題があるのは、自作曲のデータではないでしょうか。 作者の意図とは違う鳴り方をしても、それに恐らく作者しか気が付かない。聴く人は、 下手な曲だなと思ってしまうかもしれないので。 同一性保持権なんて問題にはならないとは思いますが。 殿堂にあり作者に連絡がとれない場合は、掲載を中止する等の運用を考えた方が良いかも しれません。 [5136] Re[19]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/19(Fri) 00:01:53 > 同一性保持権なんて問題にはならないとは思いますが。 > 殿堂にあり作者に連絡がとれない場合は、掲載を中止する等の運用を考えた方が良いかも > しれません。 やっぱりそこまで考慮した方が良いでしょうか。 実は、今回V5.2xでは、フォント選択の互換性も崩れています。 それにひっかかるデータも調査した方がよいでしょうか？ [5137] Re[20]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：るう 投稿日：2007/10/19(Fri) 00:20:25 > 実は、今回V5.2xでは、フォント選択の互換性も崩れています。 > それにひっかかるデータも調査した方がよいでしょうか？ フォントについては要らないのでは？ 今までは指定フォントがあることを前提にコーディングしてるはずですから。 [5138] Re[20]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：nab_k 投稿日：2007/10/19(Fri) 00:27:19 > やっぱりそこまで考慮した方が良いでしょうか。 > 実は、今回V5.2xでは、フォント選択の互換性も崩れています。 フォントですか？ [5139] Re[20]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：nagopa 投稿日：2007/10/19(Fri) 00:29:08 すみません。ちょっと大げさなことを書いてしまったでしょうか。 作者に連絡等の対応をするのは殿堂のオリジナル曲に限定し(数は一桁程度に絞られると 予想、でもオリジナル曲かの判断が大変？)、ほかは、フォント選択も含め、皆さん自分 で直してね、で済ませられないかなというのが私の感覚です。 いずれにしても、現役の方の意見を優先してください。 [5140] Re[18]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：kawaguti 投稿日：2007/10/20(Sat) 02:01:38 > > 尚、どのデータが実際に互換にひっかかったかは、 > http://www1.c3-net.ne.jp/kato/data/Chain_Report.txt > に掲載いたしました。 > これを見るとクラシック曲のデータにもたくさん影響があるようです。 これらは修正はかなりきついように思えます。 旧バージョンをパソの片隅に残しておいて、 旧バージョンでのデータはそっちで聴く。 という風にするのがミューザーとしては無難な選択なのかもしれません。 何ら建設的な事言ってませんがすみません。 [5161] Re[17]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：岡林 投稿日：2007/10/26(Fri) 08:54:50 ＞加藤様 返信遅くなって申し訳ありません。どこに返信すればいいのか 探すのに苦労しました。ツリー形式も善し悪しですね（笑）。 > この記述に対するV5.22のコンパイル仕様は、 > やはり不味いと私も思いました。 前回もう一度同じ音のオフを出さないとと書きましたが、 冷静に考えたら多重ノートOFFする音源でなければ、 Xで強制的に止めない限り止まりませんね。 通常あり得ない事態とはいえ、Museの統語体系の中で問題なく 記述できるものが、不自然な挙動を取るのは美しくないと 思いますから、やはりこうするのが無難でしょうね。 > 仕様としては、p指定により、前音の出音(ON)タイミングよりも、 > 後音の出音(ON)タイミングが先になる場合に無視します。 > > ※本当は、前音の出音(ON)タイミングよりも、 > 後音の止音(OFF)タイミングの方が先になる場合に無視する > という様にしたかったのですが、プログラム上の都合で諦めました。 ごく普通にあり得る記述なら、私も後者にしていただきたいなと 感じますが、枝葉末節の例外処理ですからこれで十分だと思います。 いつもながら些末なことばかり申し訳ありません。 ただこれで私の新仕様に対する一番の不安は解消されましたので、 （いくつか今回の&無視処理の挙動について試してみたいことはあるのですが…） ここまで作り込まれているならば、pq非依存については 新仕様に積極的に反対するつもりは全くありません。 （旧仕様が好きなのは変わりませんが、多分少数派と思われますし、 nagopaさんの仰るように現役Muserの方の意見が最優先されるべきと思います） しかし、これほどまでに大きく互換性を崩すのはMuse史上 かなり大きな事件ではないでしょうか？ 上位互換の維持に 今までずいぶんと神経を使われていらしたように思いましたので、 ここまで大胆な改変に踏み切られたのには正直驚きました。 流石にマイナーレベルの改訂内容ではない気がしますので、 ３つそれぞれの対応が正式に決まり、方向性が定まったところで 改めてメジャーのバージョンを上げてはどうかとも思いますがどうでしょう？ （個人的には一気にV6.00にしても良いような大改訂だと思っていますが…） 因みに私は(A)(B)の改訂もあまり気は進みません（結局全部ですね（苦笑））。 特に(B)は単なる細部の仕様変更というレベルではなく、根本的に&の認識を 変えなければならないものですから、特に慎重に議論されるべきだと思います。 当初の加藤さんの構想とは違っていたようですが、多くのPower Musersには 既にメンバー単位で働くという感覚が出来てしまっていると思いますから。 確かに私も&で連結した方が、小説線で区切ったときに記述が見やすいので 単音でも&を多用してきましたが、基本的に同一フィンガーなら無理に&を 使わなくとも必要な音長を各音について指定すれば同様のことができます。 そういう意味で他フィンガーとの連結こそが&固有の機能のようにも 思っていました。例えばポリフォニックな音楽で各声部が独立しているのを フィンガーを分けて打ち込むのは比較的自然でしょうし、その時タイの位置が 重なるのはごく自然です。その時慣れたMuserさんなら最下部のフィンガーに &をつけて全て連結、としていたのが、新仕様では各フィンガー&が 必要になるわけですよね。まあ一応こんなのが私がMusingするとして 今までと意識を変えないといけないと思うところなのですが… 上の例のように、メンバー単位の連結の需要もそれなりにはあるので、 新仕様にしなければならない必然性はあまり感じないのですよね。 勿論旧仕様でなければならない必然性もないわけですが、 特別どちらが良いという風には私には思えないので上位互換を 崩してまで仕様変更を行うべきか議論の余地はある様に思います。 (A)ははっきりと新仕様の方がすっきりしていると思います。 単純に互換性をどの程度の方が気にされるか、と言う感じですね。 [5113] Re[13]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：くさば 投稿日：2007/10/14(Sun) 21:18:28 >>因みに&をフィンガー単位というのはどうでしょう… >>メジャーの変更以上に深刻に互換性に関わる問題な気がします… >>両手の和音がタイの場合に後の記述にまとめて&を使ってる方など >>いるかもしれないと思いますが… > 確かに、互換性問題が懸念事項です。 > ただ、やるなら早い方が良いとも言えます。 > また、過去のデータに対するダメージの可能性も考慮したいところです。 > 私の直感では、あまりダメージがないのではないかと思っているのですが、 > 楽観かもしれません。 これは、やっているかなと。 #A1 |x1c4eg2&| % #A0 |x1g1| のような書き方をしているとg音が連結されないということですよね。 [5115] Re[14]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 22:10:07 > これは、やっているかなと。 > > #A1 |x1c4eg2&| > % > #A0 |x1g1| 以下の結果でした。 ↓ http://www1.c3-net.ne.jp/kato/data/chain4.png 期待通り連結されていません。 [5116] Re[15]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：くさば 投稿日：2007/10/14(Sun) 22:51:02 > http://www1.c3-net.ne.jp/kato/data/chain4.png > 期待通り連結されていません。 先ほど加藤さんの方にメールしたとおり殿堂データ「Jealousy」のなかの「Miscast」のボーカルパートに 従来仕様で連結されていたものがメンバー単位からフィンガー単位の連結に変わったことにより連結されな くなると思われる箇所があります。 詳細はメールしました。 [5117] Re[16]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/14(Sun) 23:23:18 現在の所フィンガー内でのみ連結の仕様で進めようと思います。 > 殿堂データ「Jealousy」のなかの「Miscast」のボーカルパートに従来仕様で連結されていたものがメン バー単位からフィンガー単位の連結に変わったことにより連結されなくなると思われる箇所があります。 互換性が崩れて本当に申し訳ないのですが、データ修正をお願いできるでしょうか？ 過去に何通か“何故他のフィンガーと接続してしまうのか？” という問い合わせメールをもらっています。 心を素にして考えると、 フィンガー内でのみ連結の方が自然のような気がしています。 逆に、敢えてフィンガーをまたいで連結する必然性が見つけられません。 ８年にもなるソフトで、 かつ６０００ものデータが蓄積された状態で互換性を崩すのは とても心苦しいのですが、これからMuseに出会う方々の事も考え、 出来るだけ自然な姿にしておきたいと考えております。 何卒、ご理解の程よろしくお願いします。 むろん、私が考えている以上に多くの、そして大きいダメージがある場合は、 改心いたします。 [5118] Re[17]: ●●●いきなりV5.21のご報告(笑)●●●
投稿者：σ 投稿日：2007/10/14(Sun) 23:58:28
開発者様．
バグの解析，修正お疲れ様です．
その間にも"&"の仕様に関する様々な是非の話がありますが，
自分の見解では，
更に「"&"の効果範囲を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の真髄とも言える記述解釈問題を通じて、
> 旧友あいまみえることに痺れるような快感を感じています。
> αさんのお陰ですね。
σです......が...
[5119] Re[18]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/15(Mon) 00:12:09 σ 様 緻密な論旨展開の記帳、ありがとうございました。 私が曖昧に“自然な姿”と表現した根拠を、 ロジカルに示して頂けた気がします。 互換性に関しての新文法も興味を持って読ませていただきました。 ただ、今回の互換性問題は、既に存在しているデータに 「“一切手を加えずに”元の演奏をさせる」という命題ですので、 新文法はそぐわないかもしれません。 >> αさんのお陰ですね。 >σです......が... うわぁ。大変失礼しました。 お許し下さい(冷汗) [5120] Re[17]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：浅川 投稿日：2007/10/15(Mon) 00:47:08 ちょっと気がかりな点が... > 現在の所フィンガー内でのみ連結の仕様で進めようと思います。 もしかしたら復活することもあるのでしょうか？ 以前将来*TEXT""& で＆の将来的な展望をイメージしていたとき。 オペラの各パートのテキストの連結も可能かな… とか思っていたところです。 そうするＴＥＸＴだけ別処理にすると統一性が…どんなものなのでしょう？？？ オペラの場合同一フィンガー内に書き込むと記述様式が狭められ 煩雑になるような気がしてなりません…。 単なる気のせいかもしれませんが…。 そうなるとやっぱり…『*TEXT""&』は廃案かな…？？？ > 逆に、敢えてフィンガーをまたいで連結する必然性が見つけられません。 じっさいの演奏には、鍵盤楽器では同一キーを指を抑え直して…の演奏も可能です。 Museの世界ではソース中に実際の演奏をイメージして入力してもこの場合は、表面的に はなにも意味無いかも知れませんが・・・・ [5121] Re[18]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/15(Mon) 01:01:59 浅川さま > 以前将来*TEXT""& > で＆の将来的な展望をイメージしていたとき。 > オペラの各パートのテキストの連結も可能かな… > とか思っていたところです。 > そうするＴＥＸＴだけ別処理にすると統一性が…どんなものなのでしょう？？？ なるほど、*TEXTですか。 もし、*TEXTに＆をサポートする場合、同じ＆記号ではありますが、 音符に付けるそれとは、根本的に異なるものになると思います。 そもそも*TEXTは現在でも、どのメンバーのどのフィンガーに記述しようとも、 テキストエリアという１つの対象に向けて表示される訳で、 その概念は今後とも変わらないでしょう。 つまり、本質的なところで音符とは異なるものだと考えています。 もしサポートするとしたら、*TEXTの＆はフィンガー内どころか、 メンバーも越えて接続する仕様となると考えています。 そして、*TEXTの＆は「連結」ではなく「追加(アペンド)」と呼ばれることでしょう。 書いていて気付いたのですが、現在以下のような記述をすると、 d *TEXT"I love You"& d ドの音が連結します。 *TEXTの＆記号はもしかしたら、それこそ互換性を崩すことになってしまうかもしれません。 よって、もし望むべき機能を「連結」ではなく「追加」と捉えるなら、 *APNDと言った新しいコマンドを立ち上げた方が素直かもしれません。 >>逆に、敢えてフィンガーをまたいで連結する必然性が見つけられません。 > じっさいの演奏には、鍵盤楽器では同一キーを指を抑え直して…の演奏も可能です。 > Museの世界ではソース中に実際の演奏をイメージして入力してもこの場合は、表面的に > はなにも意味無いかも知れませんが・・・・ なるほど。実際の演奏をイメージすることは、もしかしたら大切なことかもしれません。 ただ今の私は、不用意に他のフィンガーの音符とくっついてしまう 現在の仕様の弊害の方が大きいような気がしています。 [5122] Re[19]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：浅川 投稿日：2007/10/15(Mon) 01:32:12 開発者様 > *TEXTの＆記号はもしかしたら、それこそ互換性を崩すことになってしまうかもしれません。 > よって、もし望むべき機能を「連結」ではなく「追加」と捉えるなら、 > *APNDと言った新しいコマンドを立ち上げた方が素直かもしれません。 安心しました、これでゆくっりやすめそうです。 有難うございました。 [5130] Re[19]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：PT2K 投稿日：2007/10/16(Tue) 22:07:17 > *TEXTの＆記号はもしかしたら、それこそ互換性を崩すことになってしまうかもしれません。 > よって、もし望むべき機能を「連結」ではなく「追加」と捉えるなら、 > *APNDと言った新しいコマンドを立ち上げた方が素直かもしれません。 *STOP と *MARK コマンドにも、それぞれ対応する新規コマンドを作るより、 *TEXT+"〜" なんてのはどうでしょう？ [5131] Re[20]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/17(Wed) 21:01:46 > *STOP と *MARK コマンドにも、それぞれ対応する新規コマンドを作るより、 > *TEXT+"〜" なんてのはどうでしょう？ なるほど。 確かに、深い考えもなくコマンドを増やしていくのは、 Museコンセプトにそぐわないですね。 その意味で、PT2Kさんのアイディアは１つの解を示していると思います。 ただ結局、*MARK+ *STOP+ と設けるんですよね？ +が拡張子であることで、コマンドの識別性は高いですが、 やはりコマンドは増えています。 私の*APNDコマンドのイメージは、*TEXT,*MARK,*STOPすべてに共通です。 直前のコマンドタイプをそのまま引き継ぐ事を考えています。 よって、新規コマンドは１つだけです。 ・・・って、こうして議論・検討していると、 ムラムラと実装したくなってきます。(笑) [5133] Re[21]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：PT2K 投稿日：2007/10/17(Wed) 21:41:40 > 私の*APNDコマンドのイメージは、*TEXT,*MARK,*STOPすべてに共通です。 > 直前のコマンドタイプをそのまま引き継ぐ事を考えています。 > よって、新規コマンドは１つだけです。 あぁ！！！ *TEXT"Foo" _ *MARK+"Bar" なんて記述はナンセンスなんですね orz 前言撤回 *APND 案、賛成ですぅ # 実装は（今のメインストリームの議論よりは）難しくないのでは？ [5123] Re[17]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：くさば 投稿日：2007/10/15(Mon) 07:40:43 > 現在の所フィンガー内でのみ連結の仕様で進めようと思います。 >>殿堂データ「Jealousy」のなかの「Miscast」のボーカルパートに従来仕様で連結されていたものがメン バー単位からフィンガー単位の連結に変わったことにより連結されなくなると思われる箇所があります。 > 互換性が崩れて本当に申し訳ないのですが、 > データ修正をお願いできるでしょうか？ ここだけだったらいいけども他にないとも言い切れないので全データの精査が必要です。 しかし、手動でやっていたらたぶん漏れが発生するかと思います。 新旧のMuseのコードを利用する形でチェックツールみたいな物を作ることができませんか？ 影響が出るところがわかればデータ修正は容易だと思います。 [5124] Re[18]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/15(Mon) 07:50:25 > 新旧のMuseのコードを利用する形でチェックツールみたいな物を作ることができませんか？ > 影響が出るところがわかればデータ修正は容易だと思います。 検討してみましょう。 ただし、影響の有無を示せるだけで、 コーディング上の場所の特定までは難しいと思います。 それは次の段階で検討させてください。 今回、非互換要素が３つ混在しています。 (1)pqスタッカート非依存 (2)和音内＆記述解釈 (3)フィンガー内のみ連結 まずは、それぞれの要素が ６０００曲のデータの内、どれ程の曲に影響を及ぼすのかを 厳密に調査してみようと思います。 ううっ・・・開発するより大変そう(苦笑) [5125] Re[19]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：るう 投稿日：2007/10/16(Tue) 08:24:31 > まずは、それぞれの要素が > ６０００曲のデータの内、どれ程の曲に影響を及ぼすのかを > 厳密に調査してみようと思います。 > > ううっ・・・開発するより大変そう(苦笑) これはコンパイル後のバイナリ比較では上手くいかないのですか？ 旧コンパイル→新コンパイル→比較、という手順を バッチ処理するだけでいいような気もするのですが。 [5126] Re[20]: ●●●いきなりV5.21のご報告(笑)●●● 投稿者：開発者 投稿日：2007/10/16(Tue) 10:12:03 > これはコンパイル後のバイナリ比較では上手くいかないのですか？ > 旧コンパイル→新コンパイル→比較、という手順を > バッチ処理するだけでいいような気もするのですが。 もちろん、その方法でうまく行きますし、その方法を取るつもりです。 問題は、 (1)pqスタッカート非依存 (2)和音内＆記述解釈 (3)フィンガー内のみ連結 を切り分けたMuseをそれぞれ作り上げることです。 かなり絡み合ってますので(苦笑) [5141] ★★ご報告(V5.23) 投稿者：開発者 投稿日：2007/10/20(Sat) 13:33:32 岡林さんに見つけてもらった掲示板[5129]の対処版を V5.23としてリリースしました。 再三に渡る更新で恐縮ですが、ダウンロードをお願いします。 また、殿堂登録曲における非互換データの集計も終わりました。 ↓ http://www1.c3-net.ne.jp/kato/data/Dendo_Report.txt 従来仕様に対して、 ----------------------------- (A)和音内の連結＆解釈のみ新仕様にした場合 (B)連結＆の対象をフィンガー内に留めるという仕様のみ施した場合 (C)pqスタッカートに対して非依存の連結を行うという仕様のみ施した場合 (D)上記(A)(B)(C)のすべてを施した場合（すなわちV5.23) ----------------------------- 対象データ数：1,881 非互換となったデータ数は以下の通り、 (A) 24 (1.3%) (B) 100 (5.3%) (C) 241 (12.8%) (D) 331 (16.5%) 殿堂登録曲は、手の込んだMusingが多いため、 比率も前回のものより上がっているようです。 kawaguti さま > 旧バージョンをパソの片隅に残しておいて、 > 旧バージョンでのデータはそっちで聴く。 > という風にするのがミューザーとしては無難な選択なのかもしれません。 > 何ら建設的な事言ってませんがすみません。 とんでもございません。 ミューザーの皆さんにお手数をお掛けして申し訳有りません。 自衛手段の発案ありがとうございました。 しばらく様子を見るとともに、皆さんのご意見も参考に、 元の仕様に戻すかどうか再考したいと思います。 [5142] Re[1]: ★★ご報告(V5.23) 投稿者：浅川 投稿日：2007/10/20(Sat) 21:12:38 > 従来仕様に対して、 > ----------------------------- > (A)和音内の連結＆解釈のみ新仕様にした場合 > (B)連結＆の対象をフィンガー内に留めるという仕様のみ施した場合 > (C)pqスタッカートに対して非依存の連結を行うという仕様のみ施した場合 > (D)上記(A)(B)(C)のすべてを施した場合（すなわちV5.23) > ----------------------------- > 対象データ数：1,881 こんなときにMuseにwarningリファレンス機能があると便利な感じがします。 例えば *WARN"[スイッチ]" のようなコマンドを用意して ［スイッチ］on（デフォルト:offで）のときのみチェックでもかまいません。 (warningチェック結果は「譜面モニタ」上に何かマーキング…) みたいなのはどうでしょうか？ [5143] Re[1]: ★★ご報告(V5.23) 投稿者：くさば 投稿日：2007/10/20(Sat) 22:17:58 > ----------------------------- > (A)和音内の連結＆解釈のみ新仕様にした場合 > (B)連結＆の対象をフィンガー内に留めるという仕様のみ施した場合 > (C)pqスタッカートに対して非依存の連結を行うという仕様のみ施した場合 > (D)上記(A)(B)(C)のすべてを施した場合（すなわちV5.23) > ----------------------------- &と書いている以上今までつながってなかったのがつながるようになったというのは少なくとも つなぐ意志があって&を書いていると思うので問題は少ないかと思います。 ただ、(B)は今まで音を繋ごうとして今までつながっていたのにそれがつながらなくなってしまうという のを問題にしたいかと思います。 もっとも、こうやって問題のあるデータのリストが出てきましたので今までのデータについて修正が できてしまえば問題はなくなるのかなと。 要するにこれからはフィンガー単位に連結するということを前提にデータを書けばいいのですから。 [5158] Re[1]: ★★ご報告(V5.23) 投稿者：Kentaro 投稿日：2007/10/24(Wed) 23:52:51 開発者様 非互換データの集計、お疲れ様でした。 個人的な意見といいますか要望なのですが、 旧仕様と新仕様を選択できる機能をMuseに持たせる、 というのは難しいでしょうか？ 自分の殿堂登録曲では (A)和音内の連結＆解釈のみ新仕様にした場合 に３曲(koi.mus,liarlira.mus,run.mus)が非互換となります。 殿堂に登録していない自分の個人ＰＣ内に保存されている曲もおそらく多数該当します。 自分の場合データの打ち込みは楽曲のスコアを見てほぼその通りに行います。 その際に [dms&]8[dms]4 のような記述を多用しており、 今回のバージョンアップに伴って今まで連結されていた和音がブチブチと切れるようになってしまいました。 データ集計の結果を見ますと、 (A)のみが非互換となる曲は全体の1.3%とかなり少数派で、 あまり問題になってはいないのかもしれませんが・・・。 今まで音を繋ごうとしていたのに繋がらなる、というのはやはり気になってしまいます。 [5159] Re[2]: ★★ご報告(V5.23) 投稿者：開発者 投稿日：2007/10/25(Thu) 23:17:40 Kentaro様 > 旧仕様と新仕様を選択できる機能をMuseに持たせる、 > というのは難しいでしょうか？ ご提案、ありがとうございます。 Museという「楽器ソフト」にとって、 演奏行為そのものに当たる「Museデータ」は、 それによって始めて命が吹き込まれる源泉であることを 強く認識しております。 それは、コンピュータとソフトウェアの関係にも等しく、 Museは、Museデータがなければ「ただの空き箱」にすぎません。 その意味で、互換性は大変重要なポイントであると考えています。 ただ、Museは私の「こだわり」を結晶化したソフトであり、 私の「音楽ソフト」に対する「美意識」を、 あらゆるものに優先させたいという気持ちがあることも事実なのです。 互換を維持するための「スイッチ」は、その両者を満足させる とても優れた手法かもしれません。 しかし、私の「完全性」を求める気持ちが、 開発上の経緯で設けられた機能を設置すること拒みます。 自然界の有様が、妥協を許さない生存根拠で成り立っているように、 自ら生み出すソフトウェアもそうありたいと思ってしまうのです。 ですから今回の場合、 私の選択肢は以下の３つの新仕様の組み合わせになります。 (A)和音内の連結＆解釈の新仕様 (B)連結＆の対象をフィンガー内に留めるという仕様 (C)pqスタッカートに対して非依存の連結を行うという仕様 具体的には、以下の９種類の選択肢です。 [1] (A)(B)(C)すべて実施（つまり現在のV5.23) [2] (A)(B)のみ実施 [3] (B)(C)のみ実施 [4] (C)(A)のみ実施 [5] (A)(C)のみ実施 [6] (A)のみ実施 [7] (B)のみ実施 [8] (C)のみ実施 [9] 一切実施しない 大変、都合の良い見解で申し訳有りませんが、 今の私は、[1]を推すことを皆様にお許し頂きたい気持ちです。 もし、譜面通りの入力と言うことであれば、 私の独り善がりかもしれないのですが、 [dms&]8[dms]4 よりも [dms]8&[dms]4 あるいは [d&m&s&]8[dms]4 の方がより相応しいと思えるのです。 データの修正作業という、大変なお手間を取らせますが、 修正すべき方策は明確ですので、 何卒ご理解の程、宜しくお願いしいます。 [5160] Re[3]: ★★ご報告(V5.23) 投稿者：nagopa 投稿日：2007/10/26(Fri) 00:19:28 フィンガーをまたがる連結について。 もし、ピアノの普通の奏法として、鍵盤を押した指を別の指で押し直す ことにより、音を延ばすというのがあるのなら、旧仕様は実世界を表す適切な 文法と言うこともできるのですが、ピアニストの方、どうでしょうか？ そのような奏法があったとしても、5本の指を5つのフィンガーに割り当てて データ入力する人などいないでしょうから(でもそうするとカラフルで面白い かもしれない)、上記は詭弁でしょうかね。 個人的には、オーケストラで複数のパートに分かれたホルンを複数のフィンガー で入力するような使い方が多かったので、フィンガーをまたがる連結は扱いにくい 仕様だと思っていました。 とはいえ、修正箇所を一番特定しにくいのがこの仕様変更なので、 上記のような旧仕様を支持する理由がみつかれば、この仕様変更は外すという 選択肢もあると思います。 加藤さんの強い意志が示されたことで、新仕様でFIXすることが濃厚になって きましたが、自分のデータを新仕様にあわせて修正しようかと思っている人や、 殿堂に投稿しようと思っている人にとっては、最終的に仕様をFIXする期日を 明確にしたほうが良いと思います。 文化の日11月3日でどうでしょう。 [5162] Re[4]: ★★ご報告(V5.23) 投稿者：岡林 投稿日：2007/10/26(Fri) 09:18:50 nagopa様 > フィンガーをまたがる連結について。 > もし、ピアノの普通の奏法として、鍵盤を押した指を別の指で押し直す > ことにより、音を延ばすというのがあるのなら、旧仕様は実世界を表す適切な > 文法と言うこともできるのですが、ピアニストの方、どうでしょうか？ これは指使いの都合でそう珍しくないことだと思います。 その後の音が自然に弾けるように、ある程度長い音で押しっぱなしのまま 指を変更することはありますね。「エリーゼのために」ぐらいの曲でも 右手の５の指を１に変えるところがありますし… > そのような奏法があったとしても、5本の指を5つのフィンガーに割り当てて > データ入力する人などいないでしょうから(でもそうするとカラフルで面白い > かもしれない)、上記は詭弁でしょうかね。 私もフィンガー＝指と考えるなら和音の連結は手全体で考えるのが 自然かな、等と考えたりしましたが、Museのフィンガーの実際の性質は そういうものではないですから、まああまり関係ないかもしれないですね。 > 加藤さんの強い意志が示されたことで、新仕様でFIXすることが濃厚になって > きましたが、自分のデータを新仕様にあわせて修正しようかと思っている人や、 > 殿堂に投稿しようと思っている人にとっては、最終的に仕様をFIXする期日を > 明確にしたほうが良いと思います。 同感です。私も基本的にそうなるものと認識していますが、 書き込みをためらっていらっしゃる方もいるのかなと思い、一応 思いつく限りの保守的な意見は挙げてみました（笑） ころころ変えるべきものではないですから、最終決定の タイミングは決めておいた方がよいと思います。 [5166] Re[5]: ★★ご報告(V5.23) 投稿者：nagopa 投稿日：2007/10/27(Sat) 22:22:31 岡林様、 ピアノ奏法の説明ありがとうございます。 > 私もフィンガー＝指と考えるなら和音の連結は手全体で考えるのが > 自然かな、等と考えたりしましたが、Museのフィンガーの実際の性質は > そういうものではないですから、まああまり関係ないかもしれないですね。 そうですね。この論法は取り下げます。 [5165] Re[5]: ★★ご報告(V5.23) 投稿者：浅川 投稿日：2007/10/27(Sat) 19:41:56 【余計な考察】 もし > フィンガー＝指と考え ないならばなにか問題があるのかな・・・ と思っての考察です。 新たにMuseを始める方への説明でフィンガーの概念の説明が 少し難しくなるくらいでしょうか？ たしかメンバやフィンガーの概念って、最初はちょっと難しかった様に思います。 （記憶によると私自身も確か…？？？^^;） フィンガー＝指でない部分もあったのでなにも問題はないかもしれません。 [5163] Re[3]: ★★ご報告(V5.23) 投稿者：木下 投稿日：2007/10/26(Fri) 18:00:27 Musingのスタイルで今回の仕様変更の影響は様々と思われますので ひとつの例として報告します。 −−集計 > (A)和音内の連結＆解釈の新仕様 > (B)連結＆の対象をフィンガー内に留めるという仕様 > (C)pqスタッカートに対して非依存の連結を行うという仕様 > 殿堂登録データ（２０曲）で集計しました。 (A)なし (B)2 (C)6 (A)(B)(C)6 −−私の推奨案は下記です。 > [1] (A)(B)(C)すべて実施（つまり現在のV5.23) （たぶん）全てのデータはV5.23の方が意図通りに演奏されると思われるからです。 ただ登録データの修正は現状では大変に困難なので見通しが立っていません。 −−個々の仕様について以下にコメントします。 (A) []内の連結が/などで選択的に排除される仕様に対して，兎に角まとめて連結したり或いは連結したい音を 明示的に表現するなどを選択できるV5.23の仕様が好みです。 ただ仕様の差が嗜好程度と思われるのに記述の変更が大きいのが気になる所です。 (B) すいませんがフィンガー内だけで効果すると勘違いしていました。 私が複数のフィンガーを使うのは，同じ楽器で複数の奏者が異なる演奏をする場合です。 このような場合では，＆がメンバー全体に効果する仕様では他のフィンガーからの影響に 配慮するのは大変のような気がしますのでV5.23に賛成です。 という訳で私のデータの差異は他のフィンガーの影響を無視していた結果と思います。 (C) 元々改正をお願いした内容と同一ですので賛成です。 旋律で多用するqの設定に影響されないで＆が効果して欲しいからです。 （いちいち＆の直前でq0を挿入して，元のq*に正しく戻すのが煩わしい） 多くのデータで相違が見られますが，大抵はq0の入れ忘れと思います。 （１曲だけ確認） [5164] Re[4]: ★★ご報告(V5.23) 投稿者：開発者 投稿日：2007/10/26(Fri) 23:50:23 nagopaさま、岡林さま、そして木下さま 更には、Kentaroさま、kawagutiさま、くさばさま、浅川さま、るうさま 今回の私の独善にも近い仕様変更に対して、 真正面からの深い考察と提言の数々、 本当にありがとうございます。 当事者意識のない発言をお許し頂けるならば、 今回の件がどうなろうと、 皆さんから受けたこの一連のメッセージを 私は一生忘れないことでしょう。 ●nagopaさま[5160] > 自分のデータを新仕様にあわせて修正しようかと思っている人や、 > 殿堂に投稿しようと思っている人にとっては、 > 最終的に仕様をFIXする期日を明確にしたほうが良いと思います。 > 文化の日11月3日でどうでしょう。 まさしくその通りですね。 互換性を崩した状態で、かつそれを維持するのか破棄するのかを 明確にしない期間を長引かせるべきではありません。 nagopaさんが提案してくれた１１月３日を、 今回の「その時」としたいと思います。 文化の日・・・ですね。 ●岡林さま[5162] > 書き込みをためらっていらっしゃる方もいるのかなと思い、一応 > 思いつく限りの保守的な意見は挙げてみました（笑） ご配慮、ありがとうございます。 岡林さんの書き込み真意がヒシヒシと伝わってきます。 > ころころ変えるべきものではないですから、最終決定の > タイミングは決めておいた方がよいと思います。 上述の通り、１１月３日と致します。 できれば、その時までに できるだけ多くの方のご意見を聞きたいです。 ●岡林さま[5161] > しかし、これほどまでに大きく互換性を崩すのはMuse史上 > かなり大きな事件ではないでしょうか？ 実はV1.5の時点で、和音の音長指定の互換性を崩しました。 それ以前の仕様は、和音内の省略音長は和音直前の音長を引き継ぐものでした。 例えば、 f8 [dms]4 と書くと、f8 [d8m8s8]4 となっていたのです。 多分、今回よりもダメージの大きな改変だったと思います。 ただ当時はMuseデータが100に満たなかったので、大きな問題にはなりませんでした。 改めて「Museデータ」こそがMuseの世界を造り上げていることを実感いたします。 Readme.txtを読み返すと、V2.1とV2.3、そしてV3.1も互換崩しをやっているようです。 ただ、確かに今回ほどドラスティックな影響は出なかった模様です。 > 基本的に同一フィンガーなら無理に&を使わなくとも > 必要な音長を各音について指定すれば同様のことができます。 確かにそうとも言えますが、ただ管弦楽の場合は 発音中に音量を変えるなどの場合があり、その際は、 d2& @V40:1 d1 という風に、音長加算記号(^)では記述できない指定が可能となります。 > メンバー単位の連結の需要もそれなりにはあるので、 > 新仕様にしなければならない必然性はあまり感じないのですよね。 > 勿論旧仕様でなければならない必然性もないわけですが、 > 特別どちらが良いという風には私には思えないので上位互換を > 崩してまで仕様変更を行うべきか議論の余地はある様に思います。 この考察は、音楽を表現する文法がどうあるべきかという 本質的な命題を提示している様に思えます。 私が文法を考えるとき、 ・入力の簡便性 ・指定の木目細かさ という２つの背反する要素のバランス点を強く意識しています。 例えば今回の例では、 フィンガー単位の＆にすることで、より木目細かい指定が可能となります。 あるフィンガーは連結するも、同一タイミングの他のフィンガーは連結しない といった指定が出来るようになるからです。 しかし反面、すべてのフィンガーを接続したかったら 同音程の音を１つのフィンガーに集めたり、 連結タイミングですべてのフィンガーに＆を付けたりしなければなりません。 つまり入力の簡便性が損なわれます。 このような背反する事象の選択決断の際に私が使用する指標は 「出現頻度」と「可読性」です。 定量的な根拠はありませんが、体感的に私は (B)連結＆の対象をフィンガー内に留めるという仕様 を推すべきだろうと考えています。 ●木下さま[5163] >> (A)和音内の連結＆解釈の新仕様 >> (B)連結＆の対象をフィンガー内に留めるという仕様 >> (C)pqスタッカートに対して非依存の連結を行うという仕様 > (A) > []内の連結が/などで選択的に排除される仕様に対して， > 兎に角まとめて連結したり或いは連結したい音を明示的に表現するなどを > 選択できるV5.23の仕様が好みです。 ご賛同ありがとうございます。 > ただ仕様の差が嗜好程度と思われるのに記述の変更が大きいのが気になる所です。 (B)や(C)は、その記述が意図的なのか否か判断しにくいので、かなり難しいのですが、 逆に(A)は変換ルールが明確なので、機械的な変換ソフトを作れる可能性があります。 もしニーズがあれば開発し、ご提供しても良いと思っています。 [5168] ＞＞ Muse(V5.2)連結＆仕様Fix宣言。 ＜＜ 投稿者：開発者 投稿日：2007/11/03(Sat) 23:21:27 掲示板[5164]にて予告いたしました、掲題の件についてです。 多くの方々のご意見を頂き、また私としても多量データの互換検証を 実施させていただきました。 その後、少数の方々ではありますが、 新仕様ＯＫの意志を受け取りました。 (A)和音内の連結＆解釈の新仕様 (B)連結＆の対象をフィンガー内に留めるという仕様 (C)pqスタッカートに対して非依存の連結を行うという仕様 の３仕様に関して、 すべからく新仕様にてFixすることをここに宣言いたします。 本件に関して、情報の通知が行き届いておらず、 再度、何らかの支障を感じられる方がおられましたら、 どうぞお気軽にご意見下さい。 基本的に、今後仕様をぐらつかせることはしないつもりですが、 知恵を絞って、誠実に対応策を検討しようと思っております。 今後ともMuseの世界の活性化と、華麗なる発展に向けて、 ご協力ほど、よろしくお願いいたします。 |
