Ｍｕｓｅ掲示板

使い方 新規投稿 新着記事 ツリー表示 ワード検索 過去ログ 管理モード

過去ログ表示

過去ログ1 を表示

表示ログ 過去ログ1 過去ログ2 過去ログ3 過去ログ4
過去ログ5 過去ログ6

過去ログ検索は 検索 より行えます。
記事数 / 1474件 (621-640 を表示) / 全ページ数 / [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73]

No.5148/Re[3]: ちょっと不具合が・・・（：：）
■投稿者/ まるでばらん -(2007/10/23(Tue) 16:28:51)
□U R L/http://homepage3.nifty.com/marudebaran/

    > 　皆様、どうもありがとうございました。
    > 　TXTファイルなら、どうなるのか、確かにそこは死角であって、一度やってみましたが、やはり無音、そこで、音源を「MIDIマッパ−」から、「GS Wavetable」に変更しましたところ、ありがたい！無事に再生できました。
    > 　museはしょっちゅう使っているので、「おれ、こんなの、いつ変えたのだろう」と思いました（やはり呑んでたときか(^^;)）。
    >
    > 　とにかく直りました。楠本様、諸熊様、管理人さんのまるみぎ様、どうもありがとうございました。感謝、感謝！！
    >

    　今日の今日なのですが、こんにちは。
    　今朝、直ったのですが、正直な話、ど〜いうことなの〜！ってなわけで、やっぱりダメなのですな。事実、対応策と考えられる動作をすれば、そのときだけは正常に戻るのです。それで安心して、PCを終了させて、次に電源を入れると、やっぱり「mus」ファイルが全部、無音だ〜〜！
    　こんなことってあるのかな？とシンケンに思う私です。でも、助言をくださったかたがたありがとう、ということには、変わりはない。　あとは自分で勝手に四苦八苦いたしますので、ヨロシク。
    　追伸としてのご報告まで・・・。
    　
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5149/Re[4]: ちょっと不具合が・・・（：：）
■投稿者/ 開発者 -(2007/10/23(Tue) 18:35:59)
□U R L/http://homepage3.nifty.com/marudebaran/

    > PCを終了させて、次に電源を入れると、やっぱり「mus」ファイルが全部、無音だ〜〜！
    ということは、再起動するとMIDIマッパーに戻っているということですか？
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5150/Re[5]: ちょっと不具合が・・・（：：）
■投稿者/ まるでばらん -(2007/10/23(Tue) 21:25:43)
□U R L/http://homepage3.nifty.com/marudebaran/

    >>PCを終了させて、次に電源を入れると、やっぱり「mus」ファイルが全部、無音だ〜〜！
    > ということは、再起動するとMIDIマッパーに戻っているということですか？

    　こんばんは。開発者さんということは、加藤様ですよね。ご無沙汰してございます,ｏｈａｚｕｋａｓｉｉｋｏｔｏｄｅｓｕｇａ，ｍａｒｕｄｅｂａｒａｎｎｄｅｓｕ．

    。
    　正直なところ、何で？ｓｉｋａｍｏ，
    　ｗｈａｔ　ｏｂｊｅｃｔ　Ｉ don't see it.
    　ｎａｎｎｄａ〜，ｋｏｒｅｈａ！！

    ｕｅ，ｎａｎｎｄｅｒｏ−ｍａｚｉ？！
    　ｔｅ，ｗａｋｅｄｅ，ａｋｉｒａｍｅｍａｓｉｔａ．

    　ｎａｎｎｊａ，ｋｏｒｅｈａ？
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5152/Re[6]: ちょっと不具合が・・・（：：）
■投稿者/ まるでばらん -(2007/10/23(Tue) 22:01:45)
□U R L/http://homepage3.nifty.com/marudebaran/

    　ごめんなさい、日本語ＩＭＥが、なぜか戻りました、なんだ？
    　ほんとのところ、↓のことなど、加藤様ほかのみな様かた、すみません。ただわたしも、フザけてやったのではないのです。勝手になったわけなのです。
    　んんんぐん〜！！！　何でだ？！　て言いながら、わけは分かっているわけなのですが、んんんぐ、うっとしいことですよね？！ほんとはわからん！
    　
    　muse開発者の加藤様、「MIDIマッパー」に設定していたのですが、（←とは関係なく）さっきのさっき、ローマ字ばかりになったことは、自他ともにみとめてくださるところでしょう（しつこいが、わたしのわざとではない、タノム）。

    　と、いうわけで、ちよっとわたしも、ひと休みしたいところです、いいっかな〜。すみません、ちと疲れたぜ。
    　
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5153/Re[7]: ちょっと不具合が・・・（：：）
■投稿者/ まるでばらん -(2007/10/23(Tue) 22:42:40)
□U R L/http://homepage3.nifty.com/marudebaran/

    　本当にすみませんのですが、開発者の加藤様まで、わずらわしいことをお付き合いしてもらい、しかも、そうなのに、ローマ字になってしまって（ただ、これは、わたしのせいでは無いと思う）、しかし、それにしても申し訳ない。しかし、何が何だか、分からなくなった（ローマ字）。
    　やっぱり、わたしが一人で、何とかせにゃ、と思うものであります。
    　とにかく、気にしないで下さいね。

    　今、「mus」ファイルではなく、そこからの「MIDI」ファイル、そしてそこからの「WAVE」ファイルにおいての、不具合が出ているわけなのです。と言いますのは、一応拡張子「WAV」にして、しかも「WMA」に変換してからでないと、「WMV（←難しいことではない、ウインドウズのメディア、ヴィデオ）」には対応できないからです。(逆に言うと、それをやればすぐできる？！)。

    　というわけで、もうちょっと、一人でやってみますので、少なくとも悪く思わないで下さいね。とにかく、お付き合い、あり〜（ありがとう）！
    　 　
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5154/Re[8]: ちょっと不具合が・・・（：：）
■投稿者/ DM -(2007/10/23(Tue) 23:17:48)
□U R L/http://homepage3.nifty.com/marudebaran/

    > 　本当にすみませんのですが、開発者の加藤様まで、わずらわしいことをお付き合いしてもらい、しかも、そうなのに、ローマ字になってしまって（ただ、これは、わたしのせいでは無いと思う）、しかし、それにしても申し訳ない。しかし、何が何だか、分からなくなった（ローマ字）。

    「A」キーのよこの「Caps Lock」キーを押したのでは？
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5155/Re[9]: ちょっと不具合が・・・（：：）
■投稿者/ まるでばらん -(2007/10/23(Tue) 23:39:41)
□U R L/http://homepage3.nifty.com/marudebaran/

    > 「A」キーのよこの「Caps Lock」キーを押したのでは？

    　しつこいのですが、まるでばらんというやつなのですが、
    　ああ、↑[A]の←のキー？、ありがたいご指摘なのですが、ありがと〜、だが、悪いが、そんなことではございません、と、「言いたい」といたします（急激なローマ字などのことでしょう？）。
    　ただ、本当にごめんなさい！あとは、わたしで、正常化に向けて勝手にやりますので。本当にごめん、ありがとうございました。

    　ただ、やはりそれでも、楠本様、諸熊（←熊は隈ではないのか）、まるみぎ様、そして開発者の加藤様、ありがとうございました。弁が重複いたしますが、四苦八苦いたしましても、ひとりで勝手にやる所存ですので、そこのところ、よろしく！
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5156/Re[10]: ちょっと不具合が・・・（：：）
■投稿者/ まるでばらん -(2007/10/24(Wed) 00:12:51)
□U R L/http://homepage3.nifty.com/marudebaran/


    　失礼！！ありがたいのかたがたを羅列したわけですが、ＤＭ様、うっかりと忘れたわけではないのですが、すぐのことであって、それこそ、うっかりしましたです。ＤＭさま、お気を悪しないでね！しょせん、おたがい（ｋｏｔｔｉ，ｍａｒｕｄｅｂａｒａｎｎ　　ｍａｔａｋａ，ｔａｍｒｉｋｉ）ｄｅｓｕｋａｒａｎｅ．

    　ｔｅ，ｍｏｕｏｗａｒｉｄｅｓｕ，ｉｒｏｉｒｏｔｏ，ａｒｉｇａｔｏ〜！！


    　
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5157/Re[8]: ちょっと不具合が・・・（：：）
■投稿者/ 開発者 -(2007/10/24(Wed) 19:43:27)
□U R L/http://homepage3.nifty.com/marudebaran/

    まるでばらん様
    > というわけで、もうちょっと、一人でやってみます
    了解いたしました。健闘を祈ります。
    また何か行き詰まってしまったら、お気軽にご相談下さい。
記事No.5144 のレス / 関連記事表示
削除チェック/

No.5093/●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 開発者 -(2007/10/13(Sat) 09:08:19)
□U R L/http://homepage3.nifty.com/marudebaran/

    昨日、メジャーアップ(V5.20)が成されたMuseですが、
    すかさず草場さんから、V5.20の不具合報告を頂きました。
    「リロード時にフォント指定(*FONTコマンド)が瞬時に反映されない場合がある」
    という内容です。確実な再現性のあるバグで、すぐに対処しました。
    （詳細はMuseWikiに記載しております)

    まるみぎさんが既にV5.21をアップしてくれていますので、
    早々のマイナーアップで恐縮ですが、昨日V5.20をゲットした方は、
    再ダウンロードしてください。

    にしても、１日で２００以上もダウンロードされるとは！
    ・・・嬉しすぎます。
親記事 / 関連記事表示
削除チェック/

No.5094/Re[1]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ σ -(2007/10/13(Sat) 10:12:07)
□U R L/http://homepage3.nifty.com/marudebaran/

    恐縮ですが，修正直後の新たなバグ報告です．
    連結コマンド"&"の仕様が，
    スタッカートや止音指定"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分音符刻みにする）とちゃんと音がつながる．

    などが判っています．
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5095/Re[2]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 開発者 -(2007/10/13(Sat) 10:51:09)
□U R L/http://homepage3.nifty.com/marudebaran/

    σ 様

    障害報告、ありがとうございます。
    確実な再現性を確認しましたので、明らかに今回のMuseのバグです。
    しかも、自分としてはかなり致命的な部類に入ります。
    できるだけ速やかな対処をしたいと思います。
    しかし、正直とてつもなく不可解な現象に戸惑っています。

    この手の症状は、大概の場合
    極めて単純なプログラムミスか、あるいは根の深い解決難航の仕様問題の
    どちらかです。前者であることを祈りつつ、これから障害解析に入ります。

    > 恐縮ですが，修正直後の新たなバグ報告です．
    とんでもございません。
    いくつかの状況も添えた報告を頂き、大変感謝しています。
    心から御礼申し上げます。

    これからも、よろしくお願いします。
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5097/Re[3]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ σ -(2007/10/13(Sat) 22:45:36)
□U R L/http://homepage3.nifty.com/marudebaran/

    やはり，複雑な挙動ゆえ根深いバグである可能性がありますか...
    自分としては見守るぐらいしか出来ませんが，
    いずれにせよ単純なバグであることを祈っています．
    （最も，自分が祈ると大概裏目に出てしまうのですが...今日も阪神負けたし．
    まぁ，私の祈りは余り気にしないでください(笑)）

    >>恐縮ですが，修正直後の新たなバグ報告です．
    > とんでもございません。
    > いくつかの状況も添えた報告を頂き、大変感謝しています。
    > 心から御礼申し上げます。
    実は，今朝このページを見て v5.20 が出ていることに気付き，早速導入し，
    & コマンドの手持ちの Muse ファイルとの互換性をチェックしていました．
    自分は p,q 指定を多用しているので，& コマンドを使用しているファイルが
    1つしか無かったのですが，その1箇所でこのバグを見つけました．
    早速，発生条件を調べて，報告しようと再びこのページを見ると，
    いきなり v5.21 が出ていたので，
    修正後いきなりバグ報告もどうかとちょっとためらってしまいました．
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5098/Re[4]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 開発者 -(2007/10/14(Sun) 00:22:37)
□U R L/http://homepage3.nifty.com/marudebaran/

    σ様

    返信と心強い祈り(笑)ありがとうございます。
    中間報告です。
    お陰様で、挙動の全貌と症状の根本原因がわかりました。

    したがって、pqやスタッカートに影響されない連結＆の処理方法もすぐに導け、
    実際に仮実装まで終わっています。
    ただし、音符単位(正確に言うと一つの音符毎にONとOFFの２つずつ)の総当たり処理となり、
    コンパイル処理が実用に耐えられない程遅くなってしまいました。
    Museは、ロード時にファイルを読むだけでなく、Museデータの解析も一気に行っています。
    よってコンパイルが遅いと、ユーザには「ロード時間がかかる」と感じられます。

    私の第九データはV5.21では１秒程度でロード＋コンパイルが完了していたのですが、
    今の仮実装では７５秒もかかってしまいました。
    話になりません。これでは使いものになりません。
    どうにかして、完全性のある高速処理を捻出しなければならい。

    ・・・継続して考えます。
    阪神が勝てば、うまく行く気がするのですが・・・(苦笑)
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5099/Re[5]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ るう -(2007/10/14(Sun) 03:06:30)
□U R L/http://homepage3.nifty.com/marudebaran/

    単純な総当りではなく、二分木を使ってみてはいかがでしょうか？
    総当りの時と比べると、O(n^2)→O(log n)と、大幅な時間短縮が実現できるはずです。
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5100/Re[5]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 岡林 -(2007/10/14(Sun) 05:05:16)
□U R L/http://homepage3.nifty.com/marudebaran/

    加藤様

    すっかりご無沙汰しておりましたが、バージョンアップおめでとうございます。
    最近は新機能のテストすらままならない状態だったのですが、マイナー更新も含め
    最新MuseのDLだけは欠かさないようにしておりました。

    久々の投稿でこんなことを申し上げるのはどうかとも思ったのですが、
    僭越ながら今回の更新で一つ気になったことを述べさせていただきます。

    今まさに掲示板で話題になっている&の連結の仕様変更ですが、
    相当面倒な検証作業を経ての実装と思いますから、大変申し上げ
    にくいのですが、正直なところ私には以前の仕様の方が分かり易かったです。

    あまりにブランクが出来てしまって、以前かなり研究していた
    ここら辺の正確な仕様も忘れてしまいましたが、基本的には、
    以前は&の前に同タイミングでオフとなる記述があれば連結するという
    シンプルなものだったと思います。

    ところが、今回の仕様変更ではコーディング時の一つ一つの音の記述の
    連結という意味合いにかわってしまいました。これはごく一般的な
    記述作業では確かに記述の簡便化は期待できると思うのですが…

    むしろ、&で連結される手前の音に関するスタッカートやpqの指定について、
    連結されたときに、どれが連結後有効なものでどれが無効なものか、
    入力時に非常に解釈がややこしくなりそうな気がします。さらに
    和音などをトリッキーに用いた場合の様々な例外処理を考えますと、
    Muse内部の処理もまさに
    > 音符単位(正確に言うと一つの音符毎にONとOFFの２つずつ)の総当たり処理と
    せざるを得ない気がしますし、入力側も凝ったデータを作っていると
    記述量は減っても、思考量は逆に増えてしまうような気がするのです。

    以前なら新旧仕様を正確に把握した上で徹底的に検証作業を
    行っていたところなのですが、今の私にはその時間と気力が
    ありません。申し訳ありません。ただ、休符代わりに
    スタッカートを使って記述をシンプルにしたデータ等の互換性が
    崩れることがどうも気になりますし、記述の仕方に依存する
    仕様はバグの取れた統一的なものが出来ても、入力時に&の効果が
    直感に反する例が多々出てきそうな気がするのです。

    x2[c2//]4&c

    これとかがまぁ新旧で互換性の崩れる例ですが（こんな記述は
    実際にはまずあり得ませんが）、こういう風に何かと
    入り組んできますと、むしろ旧来の仕様の方がすっきりするような
    気がいたしまして…　pqが絡むとさらに厄介な気がします。
    新仕様を正確に把握しておりませんので、具体例は出せませんが
    （連結する部分以外のpqの機能の仕方が気になるところです。そこに
    さらに連結された場合なども）、まぁとにかくどうもすっきりしません。

    こんなことを考えるのは、まぁ必要以上にコーディングに
    こだわるごく一部の人間だけでしょうが、私にはどうしても
    旧来の仕様の方が統一感があって美しく思えてしまいます…

    十分に検証もしないまま失礼なことを申し上げてすみません。
    ただ上位互換を崩してまで行うべき「改良」なのか
    私には少し疑問が残ります。

    改版履歴を見てどうも気になったので、最低限のテストを
    行った上で書き込みさせていただきましたが、加藤さんは
    どの様にお考えになりますか？

    加藤さんのことですから、これについても何らかの加藤さんの
    信念に基づいた仕様変更なのだと存じますが、あまりに
    内部処理まで煩雑にしてしまうようでしたら、そこまでして
    互換性を崩すこともないのではないかと思わざるを得ないのです。

    久々のコメントがこんなもので申し訳ありません。
    問題提起した以上これについては、何とか時間を見つけて
    Muse文法をさらった上で、感覚的問題の生じそうな例を
    いくつか検証してみようと思います。
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5101/Re[6]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 開発者 -(2007/10/14(Sun) 10:18:09)
□U R L/http://homepage3.nifty.com/marudebaran/

    ■るう様
    アイディアありがとうございます！
    ただ、二分木もそう簡単に採用できません。
    理由は、
    (1)二分木を構成するにはソーティングキーが必要ですが、
    　　今回の場合、そのキーの抽出自体が難しい。
    (2)仮に何らかの抽出の手段を見つけたとしても、
    　　二分木そのものを構築する処理自体に時間がかかる恐れがある。
    です。
    ここは、Museデータロード時に順次読み込む各情報をうまく活用しながら
    連結処理のための下準備をするといった、Muse独自の情報量の工夫が必要だと
    思っています。もう少し考えます。

    ■岡林様
    お久しぶりです！
    また書き込みを頂いて、とても嬉しいです。
    しかも凄い長文。されど一気に読んでしまいました。
    岡林さんの文章は論理的で、長さが気になりません。素晴らしいです。

    さて、本題です。
    正直、今回のpqスタッカート非依存連結＆の仕様よりも、
    旧仕様の方が良いとする考えが存在することに思いも寄りませんでした。(苦笑)
    コーディング簡便性に関する議論を置いておくと、
    確かに仕様の明快さは旧仕様の方が優れているのかもしれません。
    この辺は、また皆さんのご意見も頂きながら、更に深く考察し、
    いざとなれば、元に戻すこともやぶさかでは御座いません。
    互換性が多少崩れる部分で、あまり頻繁に行き来したくないですが・・・(笑)

    ただ、今回は２つの理由から、
    まずはとことん非依存連結の仕様で作り込んでみようと考えています。
    (1)今の状態で元に戻したら、ある山の山頂を目指した登山家が途中で引き返し、
    　　「あの山は登るべき山ではなかった」と負け惜しみを言うようで気分が悪い。
    (2)非依存連結に関しては、当初より実施したかった仕様であるが、面倒臭いので
    　　制約とさせてもらっていた。決して「敢えて」そうしていた訳ではない。
    　　旧仕様と非依存連結仕様の優劣を決めるためにも、完全性のあるMuseを
    　　一旦作る必要があると考える。処理速度も含めた比較をする意味でも。
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5102/Re[7]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ nagopa -(2007/10/14(Sun) 11:00:17)
□U R L/http://homepage3.nifty.com/marudebaran/

    加藤さん、岡林さん、お久しぶりです。
    岡林さんとほぼ同じ立場(昔の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]
    と、音符の順番を変えなければならないので、今回の仕様の方が書きやすいで
    すね。
    ただ、開発後記の、
    「今までは、音尾部分の音長を調整することで和音内の連結を一音毎に制御す
    ることが出来たのですが、今回の改訂でそれが出来なくなったためです。」
    この記述の意味が分かりません。多分、内部的な処理のことを書かれているの
    でしょうが、外部的には、「今までは和音内の連結を一音毎に指定することが
    できなかったのを、できるようにした」という理解で良いでしょうか。
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5105/Re[8]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 開発者 -(2007/10/14(Sun) 15:42:49)
□U R L/http://homepage3.nifty.com/marudebaran/

    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]
    開発時点で私が何を勘違いしたのか、それとももっと何か考えがあったのか、
    はたまた非依存連結のプログラム作成時点でなんらかの不都合が存在したのか、
    実は・・・わからなくなってしまいました。
    私の脳細胞、アルツハイマーが微量混入し始めているかもしれません(苦笑)
記事No.5093 のレス / 関連記事表示
削除チェック/

No.5103/Re[7]: ●●●いきなりV5.21のご報告(笑)●●●
■投稿者/ 岡林 -(2007/10/14(Sun) 15:28:43)
□U R L/http://homepage3.nifty.com/marudebaran/

    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
記事No.5093 のレス / 関連記事表示
削除チェック/

パスワード/

(ダウンロード後、拡張子を .htm or .html にしてください)
[前の20件] [次の20件]

全ページ数 / [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73]

使い方 新規投稿 新着記事 ツリー表示 ワード検索 過去ログ 管理モード

- Child Tree -

Muse