Muse掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (881-900 を表示) / 全ページ数 / [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.8964/Re[5]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/10(Mon) 00:12:19)

    Αφροδιτηさん
    > メンテの時、必然的に同じになる音長を 2 箇所同じように修正するのは
    > 面倒ではありませんか?

    これ、本当によくありますよね。
    > a4&U+20:8a8&U+90:4a4&U+120:8a4.
    > ^ ^
    >の場合も、^ をつけた音長が省略できることになります。

    ここまで議論が進むと、
    論点は「同じ音長を2度書きたくない」であることが見えてきました。

    そうなると、
    > 参照先が直前ではなく直後にあるという点が今まで無かったタイプ
    という課題を解決する方策も見えてきます。

    すなわち、省略する側を音符(や休符)の音長の方にすればよいのかもしれません。
    ただし完全に省略してしまうと上位互換が崩れるので、例えば新しい文字 n を割り当てます。

    V+127:1`3^2^4..^i30_1`3^2^4..^i30

    V+127:1`3^2^4..^i30_n

    a4&U+20:8a8&U+90:4a4&U+120:8a4.

    a4&U+20:8an&U+90:4an&U+120:8a4.

    てな感じでしょうか。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8967/Re[6]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/10(Mon) 00:42:05)

    > すなわち、省略する側を音符(や休符)の音長の方にすればよいのかもしれません。
    > ただし完全に省略してしまうと上位互換が崩れるので、例えば新しい文字 n を割り当てます。

    遅延音長の省略の方について、これはよい仕様と思います。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8974/Re[7]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/11(Tue) 07:00:32)

    話を蒸し返して恐縮なのですが……

    n 記法に比べて、直後の音長を使う記法の方が有利な点が 1 つありました。
    この話題の発端となった、U+120:16 … U+120: … U+120: … のような需要に、音符の省略音長が効く範囲で対応できるということです。

    たとえば直後の音長を使う方法では、

    U+120:d16U0 U+120:rU0 U+120:mU0 ……

    のように書けます(16 は 1 度だけ書けばよい、+120 の値が違っても大丈夫)が、n 記法では、n が省略できる(そうなると思っていますが)としても、

    U+120:16dnU0 U+120:16rU0 U+120:16mU0 ……

    のように書くしかないように思います。

    (n の省略はちょっと曖昧ですね、U+120:16dn U+120:8r のとき r の音長は 8 (n そのもの) なのか 16 (直前の n に適用された値) なのか)

    ただ、初めに書かせていただいた通り、個人的にはあまりない需要です。

    それと、「今までの Muse に後ろの値を前で参照する記法はない」というのはグレーな気がしてきました。

    和音や連符の括弧内の最初の音符の省略音長は、その和音/連符全体の音長で、明示されたときそれは括弧の後ろに置かれるかと思います。
    文法的に 1 つの要素内での参照なので、明白に「後ろ」とは言い難いですが、少なくともテキスト上は「後ろ」です。

    いずれにしましても、当然ながらご判断は開発者さんにお任せします。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8975/Re[8]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/11(Tue) 20:30:12)

    Αφροδιτηさん
    > n の省略はちょっと曖昧ですね、

    nの名称は「属性音長の再現」だと思います。
    つまり、直前で指定された属性遅延音長をnの位置に、あたかもマクロのように展開するだけ
    という極めてシンプルな仕様だと思います。よって、

    > U+120:16dn U+120:8r のとき r の音長は 8 (n そのもの) なのか 16 (直前の n に適用された値) なのか
    この場合のプロセスを見ると、
    (1)まず、dnのnに直前の16が入る。(nの効能はここまでです)
    (2)省略されているr には、従前の音長省略機構が働いて16が継承される。なお、8にしたければ rnと記述すればよい。

    n 記法は「属性音長の再現」であると定義すると、以下も解決できます。

    > たとえば直後の音長を使う方法では、
    > U+120:d16U0 U+120:rU0 U+120:mU0 ……
    > のように書けます(16 は 1 度だけ書けばよい、+120 の値が違っても大丈夫)が、
    > n 記法では、n が省略できる(そうなると思っていますが)としても、
    > U+120:16dnU0 U+120:16rU0 U+120:16mU0 ……
    > のように書くしかないように思います。

    n 記法で(16 は 1 度だけ書けばよい、+120 の値が違っても大丈夫)とするには、
    U+120:16 dn U0 U+120:n r U0 U+120:n m U0 ……
    とすれば良い訳です
    nは音符の音長だけでなく、遅延音長にさえ使えるという所がミソです。

    しかも図らずも、楠本さんが[8953]でつぶやいてくれた最初の問題に一定の解決を与えられた気がします。
    :省略はできませんが、:n を書き連ねていけば、ほぼ目的を果たすわけです。

    この n 記法を実装するとすれば、多分
    n の値は各属性で独立にせず、せいぜいフィンガー単位の管理に留める事になるでしょう。
    そうすることで逆に、異なる属性間でも共通で使い回せるようになりますし、
    (フィンガー数×属性種)などという膨大な記憶管理をしないで済みます。

    しかしここまで検討が進むと、この n 記法に対してもっと大胆な発想が芽吹いています。
    アルペジオの:だけが異質な扱いなのもちょっと気になりますし・・・。
    もう少し考えてみますね。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8977/Re[9]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/11(Tue) 23:38:20)

    Αφροδιτηさん

    考え始めると、いろいろ面白いケースが湧き出てきます。
    1つ、追記です。

    ド、レ、ミの各音長が異なり、Uの遅延は16分音符で統一したいという状況の場合、
    「直後の音長を使う記法」では、遅延と音符の音長が一致していない限り16を何度も書かなければなりません。

    U+120:16 d4 U0 U+120:16 r2 U0 U+120:16 m8 U0 ……

    ところが、n 記法であれば

    U+120:16 d4 U0 U+120:n r2 U0 U+120:n m8 U0 ……

    と、一発の16で書けますね。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8978/Re[9]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/12(Wed) 20:29:48)

    Αφροδιτηさんご発案の「直後の音長を使う記法」を別の角度から考察してみました。
    この記法は「遅延属性への音符付与」という解釈が可能かもしれません。

    つまり、まず遅延属性が存在しており、
    V+127:1`3^2^4..^i30

    この遅延音長の部分に音符を挿入(付与)できるという解釈です。

    ここにドの音を挿入

    V+127: 1`3^2^4..^i30

    V+127: d 1`3^2^4..^i30

    記述方法は原案と全く変わらないのですが、
    このように解釈すると、斬新かつ面白い記法ですよね。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8982/Re[9]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/13(Thu) 20:06:55)

    > n 記法で(16 は 1 度だけ書けばよい、+120 の値が違っても大丈夫)とするには、
    > U+120:16 dn U0 U+120:n r U0 U+120:n m U0 ……
    > とすれば良い訳です
    > nは音符の音長だけでなく、遅延音長にさえ使えるという所がミソです。

    そうですね。

    > しかしここまで検討が進むと、この n 記法に対してもっと大胆な発想が芽吹いています。
    > アルペジオの:だけが異質な扱いなのもちょっと気になりますし・・・。
    > もう少し考えてみますね。

    遅延音長に使える n は、参照の効く範囲がアルペジオにのそれに近くなったように思います。
    ひょっとしてそれと関係することでしょうか?

    いずれにしても、どんな実装になるか楽しみです。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8969/Re[6]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 楠本 -(2013/06/10(Mon) 01:16:19)
□U R L/http://sinfonia.6.ql.bz/

    えーっと、つぶやき編集長の楠本です。(笑)
    Αφροδιτηさん、takaさん、開発者さんのお陰で、話が膨らんでいてよかったです。
    >>メンテの時、必然的に同じになる音長を 2 箇所同じように修正するのは
    >>面倒ではありませんか?
    >
    > これ、本当によくありますよね。
    > ここまで議論が進むと、
    > 論点は「同じ音長を2度書きたくない」であることが見えてきました。
    記述していて、これは私も感じていました。
    結果は兎も角として、みなさんのお陰で箸休めには良かったと思います。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8971/Re[6]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ taka -(2013/06/10(Mon) 20:57:11)
□U R L/http://sinfonia.6.ql.bz/

    > V+127:1`3^2^4..^i30_1`3^2^4..^i30
    > ↓
    > V+127:1`3^2^4..^i30_n
    >
    > a4&U+20:8a8&U+90:4a4&U+120:8a4.
    > ↓
    > a4&U+20:8an&U+90:4an&U+120:8a4.
    >
    > てな感じでしょうか。

    とてもわかり易いのではないでしょうか!!(嬉)
    遅延の変化量を指定した上で、遅延時間に対する音長を割り当てるわけですね。
    これなら自分の意図した「流れ」を損なうこともありませんね!!
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8970/Re[5]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ taka -(2013/06/10(Mon) 20:53:16)
□U R L/http://sinfonia.6.ql.bz/

    >> a4&U+20:8a8&U+90:4a4&U+120:8a4.
    > ^ ^
    >の場合も、^ をつけた音長が省略できることになります。
    >メンテの時、必然的に同じになる音長を 2 箇所同じように修正するのは
    >面倒ではありませんか?

    別段、個人的には面倒には感じませんね…。
    見た目で何をやりたいのか・何をやろうとしているのかが自分ではわかるので。

    むしろ省略することで、以前の記述を意識する必要が出てくるほうが面倒な私です。(^^;)
    (まぁ人それぞれですね)
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8972/Re[3]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 浅川 -(2013/06/10(Mon) 22:42:08)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    よこからすみません。(^^;

    > たとえば、V+127:1`3^2^4..^i30_1`3^2^4..^i30 みたいなときです。
    このような使い方ですが
    音にして
    @
     V1V127:1d1
    A
     U0U60:1d1

    @の場合V127になるときに発音をとめるのでV127にはならないのでは...
    Aの場合も同様にU60に発音停止するのでU60にはならないような気がします。
    @'
     V1V127:1~32d1
    A'
     U0U60:1~32d1
    のように発音停止するすこし手前でないとその最後の効果に達しない気がします。

    横からすみませんでした。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8973/Re[4]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/11(Tue) 06:12:30)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    >>たとえば、V+127:1`3^2^4..^i30_1`3^2^4..^i30 みたいなときです。
    > このような使い方ですが
    > 音にして
    > @
    >  V1V127:1d1
    > A
    >  U0U60:1d1
    >
    > @の場合V127になるときに発音をとめるのでV127にはならないのでは...
    > Aの場合も同様にU60に発音停止するのでU60にはならないような気がします。

    (残響部分を除けば)ならないと思います。
    が、指定した値に達しなければならないケースは少ない気がします。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8976/Re[5]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ taka -(2013/06/11(Tue) 21:25:57)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > が、指定した値に達しなければならないケースは少ない気がします。

    まぁ、「なければならない」かどうか、それこそ人それぞれでは…。
    事実として「達しない」ということが共有できればそれでよいのではないでしょうか?
    ⇒達しないことに対してどう対処するのかは、当事者がわかっていればそれでよいかと。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8980/Re[6]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/13(Thu) 07:22:05)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    >>が、指定した値に達しなければならないケースは少ない気がします。
    >
    > まぁ、「なければならない」かどうか、それこそ人それぞれでは…。
    > 事実として「達しない」ということが共有できればそれでよいのではないでしょうか?
    > ⇒達しないことに対してどう対処するのかは、当事者がわかっていればそれでよいかと。

    仰る通りかと。

    ただ、誤解があるといけませんので敢えて付け加えますと、その私の言葉の真意は、
    「指定値に到達させるためには直後の音符より少し短い遅延音長を与える必要があるとしても、なお Musing の全体の中で遅延音長と直後の音符の音長が等しい場合は多いと思います」
    ということです。
    もちろん人によると思いますが。

    ところで、1 つ確認したくなったのですが、ここで共有した「達しない」という「事実」(と私も思っていましたが)は、本当に事実なのでしょうか?
    Muse は、遅延を実現するとき(値は階段状に変化しますよね)、特にその開始と終了において、どういうタイミングで値を変化させていくのでしょうか? > 開発者さま。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8981/Re[7]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/13(Thu) 20:01:37)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    Αφροδιτηさん
    > Muse は、遅延を実現するとき(値は階段状に変化しますよね)、特にその開始と終了において、どういうタイミングで値を変化させていくのでしょうか? > 開発者さま。
    えー、地下の機関室担当でございます。ご質問にお答えいたします。

    同時刻の命令に関しては、音止 → 装飾関係 → 音出、という順番で並びます。
    よって、d1 V10 V90:1 r1 m1 の場合は以下のようになります。同時刻部分を括弧でくくりました。
    ドの音出 →(ドの音止 → V10 → レの音出)→ V11 → V12 → ・・・ → V89 →(レの音止 → V90 → ミの音出)→ ミの音止
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8984/Re[8]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/13(Thu) 22:02:53)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > 機関室担当様
    ご回答ありがとうございます。

    > よって、d1 V10 V90:1 r1 m1 の場合は以下のようになります。同時刻部分を括弧でくくりました。
    > ドの音出 →(ドの音止 → V10 → レの音出)→ V11 → V12 → ・・・ → V89 →(レの音止 → V90 → ミの音出)→ ミの音止

    ということは、レの音止の直前の期間は(指定値 - 1)になるわけですから、やはりこの場合「指定値に達しない」は事実なわけですね。

    そして、音出直後の期間は、遅延の効果は 0 ということですね。

    よくわかりました。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8985/遅延の出力仕様
■投稿者/ 開発者 -(2013/06/16(Sun) 15:14:26)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    地下機関室担当です。
    浅川さん、takaさん、Αφροδιτηさんが取り上げてくれた今回の話題
    「遅延の出力仕様」についてです。

    この話題に関して、かなり以前(もしかしたら10年以上前)にご指摘を受けた記憶があります。
    (申し訳ありません、どなたからのご指摘だったかは失念してしまいました)
    「現在のMuseの仕様では、終了値の反映が1ステップ届かない」というものでした。
    当時は課題山積で即応できず、とにかく検討リストに書き込んだ状態でした。

    それからかなり経って、
    「同時刻におけるコマンドの再整列」という課題に取り組み、
    現在の(音止→修飾→音出)の仕様を実現した際、上記の課題も自然解消したと思い込んでいました。

    しかし今回、この話題が再燃したことで、
    「終了値の反映が1ステップ届かない」という課題がまったく解消していないことを再認識しました。
    お恥ずかしい次第です。そして、この話題がまた持ち上がったことに感謝しております。

    さて、今後の対応ですが、
    > よって、d1 V10 V90:1 r1 m1 の場合は以下のようになります。同時刻部分を括弧でくくりました。
    > ドの音出 →(ドの音止 → V10 → レの音出)→ V11 → V12 → ・・・ → V89 →(レの音止 → V90 → ミの音出)→ ミの音止

    において、終了時点の仕様を以下の様に改めることが可能です。

    現仕様>  → V89 →(レの音止 → V90 → ミの音出)

    新仕様>  → V89 → V90 →(レの音止 → ミの音出)

    互換性がもろに崩れますが、演奏ニュアンスが大きく崩れることは無いと思います。
    むしろ音源側の処理が分散されるため、モタレが軽減する可能性大です。
    また強弱vの仕様との一貫性も出るので、新仕様の方が優れているかもしれません。

    皆様のご意見を聞かせていただければ幸いです。
    ・・・10年前に、真摯に対応しておけば良かったorz
親記事 / 関連記事表示
削除チェック/

No.8987/Re[1]: 遅延の出力仕様
■投稿者/ Eleken -(2013/06/16(Sun) 17:54:43)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    開発者さん

    仕様の検討について、興味深く読ませていただきました。
    >「終了値の反映が1ステップ届かない」という課題
    私は、これは課題でも何でもなく、現在の実装は当然の仕様だと感じています。

    > 新仕様>  → V89 → V90 →(レの音止 → ミの音出)
    では、例えば以下の 2 例で異なる MIDI 信号が出力されることになると思います。
    1) V10V20:4d4 &V30:4d4
    2) V10V30:2d4 &d4
    私の感覚では、これらは同じ演奏となるべきであると感じます。
    (この問題は U でより顕著だと思います)

    例えるなら小数点以下の切り捨て・切り上げと同じような話で、遅延の両端点のウェイトは
    両立できるものではないと思います。

    もしも新仕様が
    新仕様>  → V89 → (V90 →レの音止 → ミの音出)
    もしくは、四捨五入方式
    ドの音出 →(ドの音止 → V10 → レの音出)⇒ V11 → V12 → ・・・ → V89 ⇒(レの音止 → V90 → ミの音出)→ ミの音止
    (⇒は→の半分のウェイト)
    ならば、整合性の取れた仕様であると感じます。

    あと、大抵の楽器にはディケイタイムがあるので、新旧の仕様で
    聴感上の違いはほとんど感じ取れないような気がします。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8988/Re[2]: 遅延の出力仕様
■投稿者/ 開発者 -(2013/06/16(Sun) 21:37:43)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    早速のご意見ありがとうございます。

    ●楠本さん

    > 確認ですが、
    >> ・・・
    >> 皆様のご意見を聞かせていただければ幸いです。
    > と云う事は、舵を切ったわけではないのですね。
    はい。
    ほとんど演奏自体に影響が無い(常人の耳では聴き取れない)内容なので、
    むしろ、多角的な視点で考察したいと考えています。
    その意味で、皆さんのご意見を拝聴したいです。

    > 自分自身、最終値まで行っていると思い込んでいたし、多くの人はそう思っているんじゃないでしょうか。
    > 私は、内容からしても、新仕様の方がいいと思います。
    なるほど、ご参考にさせていただきます。

    ●Elekenさん

    >> 新仕様>  → V89 → V90 →(レの音止 → ミの音出)
    >では、例えば以下の 2 例で異なる MIDI 信号が出力されることになると思います。
    >1) V10V20:4d4 &V30:4d4
    >2) V10V30:2d4 &d4
    >私の感覚では、これらは同じ演奏となるべきであると感じます。
    >(この問題は U でより顕著だと思います)
    流石、Elekenさんです。
    深い洞察に感服すると共に、仕様検討のブレインとして、とっても頼もしいです。

    しかし、Elekenさんも「私の感覚」と書かれている通り、考え方が分かれる部分かもしれませんね。
    あえて異なる記述をしているのであるから、「異なる演奏となるべきである」という考え方も可能かもしれません。
    記述を変えるとそれに反応して結果が変化する方が、利用者の裁量に任せる部分が多い分、柔軟であるとも考えられます。

    > もしも新仕様が
    > 新仕様>  → V89 → (V90 →レの音止 → ミの音出)
    > もしくは、四捨五入方式
    > ドの音出 →(ドの音止 → V10 → レの音出)⇒ V11 → V12 → ・・・ → V89 ⇒(レの音止 → V90 → ミの音出)→ ミの音止
    > (⇒は→の半分のウェイト)
    > ならば、整合性の取れた仕様であると感じます。

    なるほど。素晴らしい考察!
    まず、同時刻内での出力が(音出 → 修飾 → 音止)の順序であることは、変更しない方針で検討したいと思っています。
    本仕様は、多重ノートONの問題や音源処理の矛盾などを一気に解決する手法ですので、保持したいです。
    次に、四捨五入方式。う〜む。なんて数学的で美しい代案でしょう!
    もしかしたら、本来皆さんが自然にイメージしているのがこの仕様なのかもしれませんね。
    でも、実装は大変そうですが(苦笑)。

    ちなみに、試しに新仕様の習作を作ってみたのですが、その過程でとても重要な事実に気づきました。
    たとえ新仕様に改修しても、結局現仕様と同じ結果になる場合があるということです。
      新仕様>  → V89 → V90 →(レの音止 → ミの音出)

    として一旦データを構築しても、時間刻みの分解能の関係で、V90とレの音止が同じ時刻に丸められる場合があります。
    そうなると、上記(音出 → 修飾 → 音止)という絶対条件が発動し、結局、
      現仕様>  → V89 →(レの音止 → V90 → ミの音出)

    になっちゃうんです。こうなると、
    > あと、大抵の楽器にはディケイタイムがあるので、新旧の仕様で
    > 聴感上の違いはほとんど感じ取れないような気がします。
    ということもあり、現仕様のままにしておいた方が無難かもしれませんね。

    (追記)
    それと、今回話題になった「遅延属性の連結」を将来的にサポートする場合、
    もしかしたら、現仕様の方が設計も実装もしやすいような気がしてます。
    Elekenさんもお気づきの通り、現仕様はその開始/終了点での連続対称性を持っているためです。

    U+30:4 = U-20:4 = U+100:2
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8989/Re[3]: 遅延の出力仕様
■投稿者/ Αφροδιτη -(2013/06/17(Mon) 06:18:05)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    たとえば V0V127:1a1 と書いたとき、理想的には音量がどんな変化をすべきかについて、a の発音時刻に 0、止音時刻に127 を通る直線であるべきとするならば、Eleken さんの四捨五入方式が最も誤差の少ない実現と考えられます。

    直線であることよりも、a の発音時刻に 0 であって、止音時刻より前に 127 に達することの方が重要とする向きもあるかと思います。
    また発音の側にも同様の問題はあって、V64a1V127:1&a1 の場合は a の発音時刻に変化を開始、つまり 65 にすべきという考え方もあるかもしれません。
    しかし、これらは場合によりけりであって、Muse はそれらを実現する記法を提供していればよく、遅延自体の仕様とする必要はないと私は思います。

    四捨五入方式は美しいですが、互換性や実装の容易さを犠牲にしてまで導入する価値があるかどうかについては疑問を感じます。
    個人的には、現仕様でもよいと思っています。

    私は、浅川さんのご指摘を検討しているとき、現仕様でも、四捨五入方式は無理ですが、直後の音符の音長と同一の遅延音長を用いて、その音符が発音している間に属性値を望みの終了値に到達させることは、ほとんどの場合に可能であると気付きました。
    遅延音長を、上昇のときは終了値 +1 下降のときは終了値 -1 にすればよいのです。
    たとえば、V64 まで上昇したければ、V65:1a1 のように。

    そうすれば、ほとんどの場合、発音中の最後のステップの属性値が望みの終了値になるはずです。
    止音直後にその終了値にしたいという場合、V65:1a1 V64b1 のように、改めてそこで明示的に遅延なしの終了値の属性指定を置けばよいです。
    遅延音長に指定した 65 の値はここでは再生されないはずです。
    なぜならその値には、遅延期間中には到達しないのですから。

    この方法で望みの終了値に到達できないのは、上昇して上限値に到達させる場合、下降して下限値に到達させる場合、そして、変化が速過ぎて 1 ステップ当たりの属性の変化量が 1 を超えてしまう場合のみかと思います。
    V のように相対指定を備えている属性(V だけ? v は対象外として)については、前 2 者の場合も可能になります。

    これが結局新仕様と、前 2 者の制約を除いて等価になるかと思います。
    そして最後の制約が、開発者さんが書かれた新仕様が現仕様と同じことになる場合を含むものと思います。
記事No.8985 のレス / 関連記事表示
削除チェック/


パスワード/

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