Muse掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (301-320 を表示) / 全ページ数 / [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]

No.8356/Re[1]: つぼやいてみた
■投稿者/ そな -(2012/10/03(Wed) 22:58:20)

    お・・・・落ちなくてヨカッタ・・・・
記事No.8352 のレス / 関連記事表示
削除チェック/

No.8361/Re[2]: つぼやいてみた
■投稿者/ Ayakong -(2012/10/04(Thu) 15:52:13)

    今回、オリジナル曲だけを7曲同時に送ったけど、どれか1曲落ちる気がずっとしてた、でも…全部殿堂入りして良かったw。
記事No.8352 のレス / 関連記事表示
削除チェック/

No.8362/Re[3]: つぼやいてみた
■投稿者/ T君 -(2012/10/04(Thu) 17:08:58)

    いやほんと、4曲とも通ってよかったです(汗)

    しかもその精鋭揃いのラインナップの中★が頂けたなんて…光栄です。
記事No.8352 のレス / 関連記事表示
削除チェック/

No.8374/楽譜出力と連譜
■投稿者/ 木下 -(2012/10/11(Thu) 17:18:24)

    V6.2から導入された楽譜出力で,連譜の音符が連譜全体の音価になっています。
    短い音価になるはずと思います。
    付点符の連譜は特に違和感が強いです。
    以下のデータで楽譜出力してみて下さい。
    レミファが4分音符の3連譜です。8分音符が3個になりません。
    ソラソミレは付点4分音符の5連譜です。16分音符が5個になりません。

    d4 (rmf) (slsmr)4. d8

    拍や小節の概念が無いミューズでは付点符の連譜の表現が怪しくなる?
    いやそれでも実際には原則に従うだけで問題ないように感じています。

    「原則として実際の音価より長い音符の中で一番近いものを使う」
    −ウィキペディア『音符』より抜粋


親記事 / 関連記事表示
削除チェック/

No.8375/Re[1]: 楽譜出力と連譜
■投稿者/ 開発者 -(2012/10/11(Thu) 23:21:58)

    木下さん、新機構の試行、ありがとうございます。

    > V6.2から導入された楽譜出力で,連譜の音符が連譜全体の音価になっています。
    > 短い音価になるはずと思います。
    > 付点符の連譜は特に違和感が強いです。
    私も今ままでの自分のMuseデータで試して、そのままでは違和感ありまくりだと思いました。
    ただ、LilyPondの連符指定はMuseと異なり、少々厄介な演算が必要で、
    その値に少しでも矛盾があるとすぐにエラーが出て楽譜が出力できなくなります。
    という訳で、ここは慎重に自動化への検討を進めようと思っています。

    それまでの間は、お手数ですが明に音価を指定してもらえますか?
    例えば、以下の場合は、

    > 以下のデータで楽譜出力してみて下さい。
    > レミファが4分音符の3連譜です。8分音符が3個になりません。
    > ソラソミレは付点4分音符の5連譜です。16分音符が5個になりません。
    > d4 (rmf) (slsmr)4. d8


    d4 (r8mf) (s16lsmr)4. d8

    としてみてください。
    V6.2に添付してあるSample1.musは、久々の更新をしたのですが、実はこの理由です。(苦笑)。

    なお、最後の音符が連桁で連結(これはLilyPondが勝手にやってしまう自動処理です)
    されてしまうので、スルーコマンドで以下の様に指定するとそれを分断することができます。


    d4 (r8mf) (s16"["lsmr"]")4. d8

    LilyPondの範囲指定 [ ] 等は、利用者からすると直感的ではなく、
    どちらかというとプログラム処理がしやすいように定義されているので注意が必要です。

    ちなみに、
    > いやそれでも実際には原則に従うだけで問題ないように感じています。
    > 「原則として実際の音価より長い音符の中で一番近いものを使う」
    > −ウィキペディア『音符』より抜粋

    この原則ですと、上記例の2番目の連符の音価は16分音符ではなく、
    8分音符なのではないかと思いますが、実はかくいう私も
    16分音符の方が楽譜としての印象は自然のような気がします。
    このように例外的な事例が多いことも、自動化することを躊躇する要因の一つです。

    一般に下手な自動化をすると「小さな親切、大きなお世話」になる場合が多く、
    それよりも、手動で明に指定すれば所望の楽譜が出力できるのであれば、
    そちらの方がいいかな、って今現在は考えている次第です。

    でも、自動化は後追いで強化していく分には上位互換も保てるので、
    下手ではない上手な自動化を目指して、継続的に検討いたします。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8379/Re[2]: 楽譜出力と連譜
■投稿者/ 木下 -(2012/10/12(Fri) 17:20:55)

    ◆開発者さん

    > それまでの間は、お手数ですが明に音価を指定してもらえますか?
    > 例えば、以下の場合は、
    > ↓
    > d4 (r8mf) (s16lsmr)4. d8
    > としてみてください。

    迂闊でした。この方法がチラッと浮かんだのですが「変わりないだろう」と確認していませんでした。
    この例で音価の指示可能な事が判りました。

    > V6.2に添付してあるSample1.musは、久々の更新をしたのですが、実はこの理由です。(苦笑)。

    ここの記載された技巧なども見ると,開発段階で様々に検討されている事が良く判りました。
    指定頂いた方法で対処する事にします。

    ◆Αφροδιτηさん

    > 『要出典』がないのが不思議なくらいです。

    連譜だけを参照して項目を詳細に見ていなかったです。
    ご指摘の通り「原則」に関しては個人見解の可能性があると感じます。

    > Muse の仕様としては、「実際の音価に一番近いものを使う(()内の最初の音価が省略された場合)」でいいような気もしていますけれども。

    ここで掲載した例では4/4拍子でした。
    確かにこの場合は16分音符の方が良いような気もします。
    しかし付点音符の連譜が使われるのは6/8などと思われ鱒。
    そうすると,原則の方法のままで良いように感じます。

    ◆浅川さん
    有意義な情報を有難うございました。
    ここの例も「原則」に沿っているのですね。

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

No.8376/Re[1]: 楽譜出力と連譜
■投稿者/ Αφροδιτη -(2012/10/12(Fri) 05:06:26)

    > 「原則として実際の音価より長い音符の中で一番近いものを使う」
    > −ウィキペディア『音符』より抜粋

    ウィキペディアは、信頼できる出典を明記することで記事に信頼性を付与する方針のように思えます。
    逆に言えば、出展が明記されていない記述の信頼性は疑っておいた方がよさそうだということです。
    この記事は、恥ずかしながら、見たことありませんでしたが、出典の記載が全くないばかりでなく、初っ端の音符の部位の名称も、私の手元の音楽辞典(音楽中辞典、音楽之友社)と食い違いがあります(手元のでは、ぼうが『符尾』、はたは『符鉤』)。
    『要出典』がないのが不思議なくらいです。

    同じ辞典には、連符に使う音符について特に原則は書かれていません。
    記譜例はあって、3/4 拍子の 1 小節に渡る 2 連符が 4 分音符で書かれています。
    同様の指摘がすでに開発者さんからありますが、2 連符(2:3)などは、こちらの方が一般的に思えます。
    Muse の仕様としては、「実際の音価に一番近いものを使う(()内の最初の音価が省略された場合)」でいいような気もしていますけれども。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8378/Re[2]: 楽譜出力と連譜
■投稿者/ 浅川 -(2012/10/12(Fri) 15:40:24)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

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

No.8381/Re[2]: 楽譜出力と連譜
■投稿者/ 開発者 -(2012/10/12(Fri) 20:48:11)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    Αφροδιτηさん
    Wikipediaにおける情報信憑性に対する警鐘、ありがとうございました。

    > Muse の仕様としては、「実際の音価に一番近いものを使う(()内の最初の音価が省略された場合)」でいいような気もしていますけれども。
    そうですね。確かにこれならばシンプルな原則であり、
    かつ常識的に受け入れられる自動化(つまり省略時の音価自動補正)が実現しそうです。

    今回、木下さんとΑφροδιτηさん、そして浅川さんから頂いたご意見や情報に触発されて、
    私が開発時に頭の中でのみ考察したイメージを、整理しておこうと思います。
    文法にまつわる考察や議論は、自らの洞察力を深めてくれるような気がして楽しいですね。
    (実装は地獄である場合が多いですが)笑
    こんな機会を与えて頂き、その意味でも皆さんに感謝しております。ありがとうございます。

    さて、
    Museの連符記述に自由度があるが故に、ことは少々複雑です。
    ・連符内の音長はすべて等しくなくても良い
    ・連符内の音符においても連符内に閉じた範囲で省略音長を利用できる

    これらのMuse文法の仕様があるため、
    「連符内音符の音長省略時の音価自動補正」における“省略”とは何なのか
    を明確にしておかなければなりません。

    この省略は、あくまでも
    「連符内の1音目の音長が省略された場合に、連符の閉じ括弧に添えられた音長が採用される」という場合の“省略”であり、
    「連符内の音符は左から右に向かって一般の省略音長のルールが適用される」という場合の“省略”ではない、
    というのは明白だと思います。

    これを前提として「実際の音価に一番近いものを使う」という仕様を実現すると、
    例えば、(drmf8sl)4 の場合、前半のdrmは「音価自動補正」が働き16分音符に、後半のfslは明に指定した8分音符となります。
    この仕様を美しいとするか不味いとするかは極めて主観的な話なのですが、少なくとも私は今ひとつかなぁ〜と感じています。
    なぜなら、実際はdrmの方がfslよりも音が長いのに、逆のイメージで記譜されてしまうからです。
    対して自動補正を行っていない現仕様は、少なくとも音長比率は常に正しく記譜されます。

    自動化すると比率が乱れ、自動化しないと比率は乱れない・・・。
    これは、自動化対象音符を部分的にせざるを得ないが故の、逆説的事実だ思います。
    いっそのこと連符内はすべて自動演算に委ねる、という仕様も考えられますが、代償として手動指定ができなくなってしまいます。

    むろんほとんどの連符は、
    「連符内の音長はすべて等しく、かつすべての音長は省略されている」のだから大抵の場合は問題なかろう、
    という考え方も現実的だとは思います。

    ただ今回の場合は、
    手動で明に指定すれば所望の結果を得られる手段が存在していますので、利用者にこの複雑な自動化仕様を説明するよりも、
    「連符内の音価は、省略音長も含め記述に従って記譜されます」の単純明快な一言で済ませたいというのが、今の私の気持ちです。

    以上、なんだか理屈っぽい長文になってしまい申し訳ありませんでした。
    今後も継続的(正確に言うと断続的)に、検討は続けたいと思います。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8382/Re[3]: 楽譜出力と連譜
■投稿者/ Αφροδιτη -(2012/10/12(Fri) 23:32:46)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    浅川様

    貴重な情報をありがとうございます。
    「主催者」のリンクを辿ると、ご紹介のページは私立学校の音楽科の先生が作られているのですね……

    木下様

    私が参照した辞典でも、3 連符以上は「原則」と同じでした。
    そうなると、やはり「より長い音符の中で」という文言をばっさり捨てるわけにはいきませんね。
    2 連符だけ特別?
    もちろん辞典の信頼性も、全く疑わなくてよいわけではありません。
    言うまでもなく、私の「〜気がします」は最も信頼性が低いです orz

    開発者様

    >> Muse の仕様としては、「実際の音価に一番近いものを使う(()内の最初の音価が省略された場合)」……
    > 例えば、(drmf8sl)4 の場合、前半のdrmは「音価自動補正」が働き16分音符に、後半のfslは明に指定した8分音符となります。
    > この仕様を美しいとするか不味いとするかは極めて主観的な話なのですが、少なくとも私は今ひとつかなぁ〜と感じています。
    > なぜなら、実際はdrmの方がfslよりも音が長いのに、逆のイメージで記譜されてしまうからです。

    念のためですが、「(()内の最初の……」というところにご指摘の問題を回避する仕様を含んだつもりでした。
    あまり積極的に提案する意図ではなかったので、簡単に書いてしまいましたが、もう少し詳しく申しますと、
    ・()内の最初の音長が省略された場合、()内の音長指定された音符も、その実際の音価に一番近いものを使う。
    ・()内の最初の音長が指定された場合、()内の(省略時は直前の)音長指定通りの音符を使う。

    「実際の音価に」が「実際の音価より長い音符の中で」でも同様です。

    つまり、(drmf8sl)4 の場合、()内の最初の d の音長が省略されているので、drm にはそれぞれ 4 分音符の 2/9 の音価が割り当てられるので 16 分音符を使い、fsl には 1/9 の音価が割り当てられるので 32 分音符を使うということです。
    ……複雑ですね。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8384/Re[4]: 楽譜出力と連譜
■投稿者/ 開発者 -(2012/10/13(Sat) 10:03:18)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    Αφροδιτηさん
    > 「(()内の最初の……」というところにご指摘の問題を回避する仕様を含んだつもりでした。
    なるほど!
    最初の音符の音長が省略されているか否かで、全面自動補正か、全面手動指定かを切り分けるのですね。
    これらならば美しい仕様ですね。気づきませんでした。

    浅川さん
    > 連符内の始の音長が省略された場合4分音符が割り付けられたことにしてはいかがでしょうか?
    ニュアンスは異なるかもしれませんが、浅川さんも同様の仕様への帰結を主張されている気がします。
    複数の方が同じ頂点に到達していることが、この仕様の美しさや分かり易さを裏付けているのかもしれませんね。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8383/Re[3]: 楽譜出力と連譜
■投稿者/ 浅川 -(2012/10/13(Sat) 03:39:48)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > 例えば、(drmf8sl)4 の場合、前半のdrmは「音価自動補正」が働き16分音符に、後半のfslは明に指定した8分音符となります。
    > この仕様を美しいとするか不味いとするかは極めて主観的な話なのですが、少なくとも私は今ひとつかなぁ〜と感じています。
    > なぜなら、実際はdrmの方がfslよりも音が長いのに、逆のイメージで記譜されてしまうからです。
    > 対して自動補正を行っていない現仕様は、少なくとも音長比率は常に正しく記譜されます。
    >
    ちょっと荒っぽいですが...

    連符内の始の音長が省略された場合4分音符が割り付けられたことにしてはいかがでしょうか?
     (drmf8sl)4 → (d4rmf8sl)4
    これならdrmの各音価とfslの各音価との比率も2:1となり不自然さはなくなるような気もします。
    (この記譜は(d16rmf32sl)4になる)

    Museサンプルでも何も音長を指定せず
     drmfslc<d
    とした場合4分音符が暗黙の了解に割り当てられていることですし。

    荒い理由付けすぎましたでしょうか?...;^_^A
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8387/Re[4]: 楽譜出力と連譜
■投稿者/ BnKayak -(2012/10/15(Mon) 09:44:15)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    連符の話題とはズレてしまいます。

    ピアノやギダーのような楽器では問題ないのですが
    管楽器、擦弦楽器のような持続音の楽器の場合
    「/.」「/..」などを使用しています。

    するとLilyPondではスタカートとテヌートが
    一緒になった記号がついてしまいます。

    また「/.」などをつけないものが
    Museではスラー表現と私は理解していましたが
    これはLilyPondではスタカート記号もテヌート記号もない
    音符になり、スラーにはなりません。

    まだまだありますが、最初に試してみて
    LilyPondを使用するには相当LilyPondを勉強しないと
    無理と思ったので、当面はLilyPond使用は
    諦めようと思いました。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8388/Re[5]: 楽譜出力と連譜
■投稿者/ 開発者 -(2012/10/15(Mon) 19:20:28)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    BnKayakさん
    新しい話題提供、ありがとうございます。

    既に断念したBnKayakさんにとっては余計なお世話かもしれませんが、
    この掲示板をご覧になっている他のミューザーの方々の参考になるかもしれないので、
    一応、今回書き込んで頂いた2点について、簡単にその対処法を記しておきますね。

    > スタカートとテヌートが一緒になった記号がついてしまいます。
    Museでこれを打ち消すためのコマンドを用意してあります。
    *LILY"- /" を、打ち消したいフィンガーの冒頭に記述します。
    これは、一回記述するだけでOKです。
    詳細は、■ (4)自動記譜の制御(3300行目あたりです)をご覧下さい。

    > スラーにはなりません。
    これは、LilyPondのコマンドで範囲を指定してあげる必要があります。
    例えば、drmfslc という楽譜で、mfsl をスラーにしたい場合は、
    スルーコマンドを使って、以下の様に記述します。

    drm "(" fsl ")" c

    スラー開始のミの直後に"("を
    スラー終了のラの直後に")"を書くことになります。

    括弧で括られた音符がスラー範囲とみなしがちですが、
    LilyPondでは、開始終了共に音符の「直後」に括弧を書くので、
    ちょっとわかりにくいですね。

    > LilyPondを使用するには相当LilyPondを勉強しないと
    > 無理と思ったので、当面はLilyPond使用は
    > 諦めようと思いました
    そうですね。
    楽譜の譜刻はとても繊細で、かつ多くの情報量を扱いますので、
    その分、覚えなければならないことが多くなり大変ですね。

    それを少しでも軽減できればと、MuseのReadme.txtに虎の巻を書いておきました。
    焼け石に水かも知れないけど・・・(苦笑)
    ■楽譜スルー(5350行目あたりです)

    私が思うに、ここに書かれている程度のLilyPond文法を使えば、
    通常は、ほぼ事足りるような気がしています。
    ご参考になれば幸いです。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8389/Re[6]: 楽譜出力と連譜
■投稿者/ BnKayak -(2012/10/15(Mon) 19:39:34)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    開発者さま

    早速のお返事ありがとうございます。

    LilyPondの、スルーコマンドも含めての使用は
    最初はバッハの無伴奏フルート・パルティータのような
    単声部のものから始めていって
    徐々に声部を増やしていくようにします。
記事No.8374 のレス / 関連記事表示
削除チェック/

No.8390/ついっと
■投稿者/ けーご -(2012/10/25(Thu) 21:54:27)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    windows8が発売されますねえ。
    まあ9Xで動く→XPで→vistaで→7で動くときましたんで、8でもmuse動くと思いますけdも^^;

    sc8820がvista、sd90が7までしか想定してないのが気になりますが…
親記事 / 関連記事表示
削除チェック/

No.8391/Re[1]: ついっと
■投稿者/ くさば -(2012/10/26(Fri) 21:10:48)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > windows8が発売されますねえ。

    http://twitpic.com/b7inhz

    とりあえず、速報レベルでMuseをWindows8で動かしてみた図
記事No.8390 のレス / 関連記事表示
削除チェック/

No.8392/Re[2]: ついっと
■投稿者/ けーご -(2012/10/26(Fri) 22:56:33)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > とりあえず、速報レベルでMuseをWindows8で動かしてみた図
    ちょいとばかし好みが分かれますねw色合いが
記事No.8390 のレス / 関連記事表示
削除チェック/

No.8404/NO TITLE
■投稿者/ z -(2012/10/31(Wed) 18:37:20)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    意味不明なソフトだ?
    全然わからん
    曲できるの・・・
親記事 / 関連記事表示
削除チェック/

No.8407/Re[1]: NO TITLE
■投稿者/ 開発者 -(2012/11/01(Thu) 00:05:36)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > 意味不明なソフトだ?
    > 全然わからん
    > 曲できるの・・・

    求めよ、さらば与えられん
記事No.8404 のレス / 関連記事表示
削除チェック/


パスワード/

(ダウンロード後、拡張子を .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]

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

- Child Tree -

Muse