Muse掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (901-920 を表示) / 全ページ数 / [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.8990/Re[4]: 遅延の出力仕様
■投稿者/ るう -(2013/06/17(Mon) 17:57:11)

    > 遅延音長を、上昇のときは終了値 +1 下降のときは終了値 -1 にすればよいのです。
    最終的にある値で発音しているようにしたい、という場合、恐らくは例えば、

    \_

    のように、最後のある時間だけは最終値で発音していたい、というのが望みになるのではないでしょうか?
    だとすれば、これを表現するにはV64:1~64a1のようにすれば十分ですし、むしろより意図に見合った指定方法になる気がします。

    なお私は、Museの文法自体は(X等の一部の指示を除いて)MIDI規格から抽象化されるよう制定されている、と認識しております。
    つまりV64とV65は『MIDIの仕様では』隣接する値になっていますが、Museにおいても(今はともかく)必ずしもそうとは限らない。

    例えばもし、Museが1280段階のボリュームを設定できる新規格に対応した時、終了値±1という指定をしたデータは、全て±0.1に書き換える必要が出てきます。逆に0〜10の11段階しか持たない規格に対応すると、±13に。
    ですので、終了値±1という方法で対応するのは、対応方法としては誤りであると考えます。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8992/Re[5]: 遅延の出力仕様
■投稿者/ 開発者 -(2013/06/17(Mon) 20:50:11)

    るうさん
    > Museの文法自体は(X等の一部の指示を除いて)MIDI規格から抽象化されるよう制定されている、と認識しております。
    まさにその通りです!
    私が最も大切にしている部分をご認識頂き、本当に嬉しいです。
    発音機構はともかく、ことMuse文法に関しては、
    巷のMIDI知識前提のMMLではなく、音楽記述言語として確立したい。
    それが私の切なる想いです。

    そして本件も含めて、油まみれの部分は今後とも機関室担当が対処致します。
    皆様にはぜひ抽象化された美しい世界で、麗しい音楽を奏でていただきたい。
    その調べは、必ずや地下にも聴こえてまいります。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8997/Re[5]: 遅延の出力仕様
■投稿者/ Αφροδιτη -(2013/06/18(Tue) 20:21:26)

    > 例えばもし、Museが1280段階のボリュームを設定できる新規格に対応した時、終了値±1という指定をしたデータは、全て±0.1に書き換える必要が出てきます。逆に0〜10の11段階しか持たない規格に対応すると、±13に。

    その可能性は考慮していませんでした。

    が、そういう場合に Muse が必ず 1280 段階を 1 段ずつ上下するように修正されるかどうかはわかりません。
    開発者さんが予告されていればともかく、どうなるかわからない修正に備えて現在可能な方法を封じるより、現時点で可能なあらゆる方法を尽くし、書き換えが必要になったら書き換えればよいという立場はあってよいと考えます。
    現時点で Muse が 1 ずつ上下することは [8981] で(V については)確認済みです。

    私は、現時点で最適と判断すれば終了値±1 を使うでしょう。
    しかし、るうさんはご自身の信念に基づいて決して使われないかもしれません。
    それは、やはり人それぞれということと思います。
    どちらかが誤りとは言えないと思います。

    もっとも、終了値±1 は、開発者さんが書かれた遅延を半ステップ早く開始する仕様が導入されれば、無効になるというか、そもそも必要なくなる方法ですので、そうなれば私も使いません。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8999/Re[5]: 遅延の出力仕様
■投稿者/ taka -(2013/06/18(Tue) 22:56:19)

    > ですので、終了値±1という方法で対応するのは、対応方法としては誤りであると考えます。

    このやり取りを拝見していて、プログラムロジックを組む際に「50回LOOPする」という条件に対し、
    「カウンターが51になったらLOOPを抜ける」という条件を組み立てるサマが思い浮かばれました。
    求めたいのは「50」回のLOOPなので、直接的には「51」という値は意味を持たず、仕様を混乱させます。

    『V127にしたいときはどうするのでしょう?』という突っ込みもありますが、V127とV126の違いがわかる人
    なんて、いないんじゃないかと私は思います。
    ⇒自分がアナログ世代だからなのかもしれませんが…。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9000/Re[6]: 遅延の出力仕様
■投稿者/ taka -(2013/06/18(Tue) 23:01:30)

    >>ですので、終了値±1という方法で対応するのは、対応方法としては誤りであると考えます。

    ただ、「終了値±1」とせざるを得ないというのも現状の事実ではあるわけで、私としてはスッパリと否定しているわけではありません。

    とは言え、やっぱり判りづらいなぁと感じはしますね…。

    (「V0にしたい!」っていうのも対応できないなぁと思ってみたり…)
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9001/Re[6]: 遅延の出力仕様
■投稿者/ 浅川 -(2013/06/19(Wed) 18:52:01)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > 『V127にしたいときはどうするのでしょう?』という突っ込みもありますが、V127とV126の違いがわかる人
    > なんて、いないんじゃないかと私は思います。
    音量としては確かにそうですね(^^;
    でも延滞はUや%でも使われるため
    たとえばリタルランドなどで
    d4%2%1:i8di2rmfslc<d
    はどうでしょう
    はっきりと違いが聞き取れると思います。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9002/Re[7]: 遅延の出力仕様
■投稿者/ 開発者 -(2013/06/19(Wed) 20:48:08)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    浅川さん
    > でも延滞はUや%でも使われるため

    Uは確かにその通りです。ただ、%は違います。
    Museの%は、正真正銘の誤差ゼロで実現しています。
    つまり、階段の踏みしろはありません。完全なスロープです。
    実は、これを実現したかったために、内部ではテンポが125固定になっています。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9005/Re[8]: 遅延の出力仕様
■投稿者/ 浅川 -(2013/06/20(Thu) 00:51:10)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > Uは確かにその通りです。ただ、%は違います。
    > Museの%は、正真正銘の誤差ゼロで実現しています。
    > つまり、階段の踏みしろはありません。完全なスロープです。
    > 実は、これを実現したかったために、内部ではテンポが125固定になっています。
    これでなんとなくですが%とUのロジックの違いが見えてしまいました。
    すみませんでした。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9004/Re[7]: 遅延の出力仕様
■投稿者/ taka -(2013/06/19(Wed) 23:39:13)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > 音量としては確かにそうですね(^^;
    > でも延滞はUや%でも使われるため
    > たとえばリタルランドなどで
    > d4%2%1:i8di2rmfslc<d
    > はどうでしょう
    > はっきりと違いが聞き取れると思います。

    「U」については確かに違いが出ます。
    逆に私も「X」が使えるようになる前は、弦楽器群の音の干渉を避けるために、
    ・1stVn ⇒ U+1
    ・2ndVn ⇒ U0
    ・Va ⇒ U-1
    というような感じでディチューンさせたりしてました。
    ただ、意外にその「ズレ幅」が大きく戸惑った経験もあります。

    「%」については、そもそも比較の対象が違うと思いますよ。
    特に「%1」と「%2」などを例に出されては、片や「1拍60秒」、片や「1拍30秒」ですから、
    「時速100キロの車」と「時速50キロの車」を比較していることと同じですね。

    それよりも「時速127キロの車」と「時速126キロの車」を交互に走らせて、どちらが速いかを
    答えられる人はほとんどいないんじゃないかってコトです。
    (同時に走らせてしまえばわかるとは思いますが)

    私としては、数値そのものに拘るよりは、全体のバランスを考えて適宜調整することで
    思った効果が得られればそれでいいと思ってます。(あくまでも私の主観です)
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9003/Re[6]: 遅延の出力仕様
■投稿者/ Αφροδιτη -(2013/06/19(Wed) 23:23:30)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > このやり取りを拝見していて、プログラムロジックを組む際に「50回LOOPする」という条件に対し、
    > 「カウンターが51になったらLOOPを抜ける」という条件を組み立てるサマが思い浮かばれました。

    私は最後の要素の添字が要素数-1 になる配列を思い浮かべていました。

    > 求めたいのは「50」回のLOOPなので、直接的には「51」という値は意味を持たず、仕様を混乱させます。

    私もそれは難点だなと思っていました。

    > 『V127にしたいときはどうするのでしょう?』という突っ込みもありますが、

    できませんね。

    初め私は相対指定を使えばできると書きましたが、これは勘違いでした。

    いずれにしても、U や S を初めとするその他の遅延でできないことはわかっていました。
    それで、できるように開発者さんにお願い(これは、taka さんの突っ込みへの答えです)しようと
    目論んでいたのですが、遥かに美しい仕様変更がほぼ確定になりましたから、終了値±1 は
    そのうち不要になるでしょう。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8991/Re[4]: 遅延の出力仕様
■投稿者/ 開発者 -(2013/06/17(Mon) 19:10:54)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    Αφροδιτηさん、刺激的な(むろん良い意味でです)書き込み、ありがとうございます。
    そして私は今、Αφροδιτηさんにとっても感謝しています。
    というのもこの書き込みのお陰で、私はブレイクスルーを得たからです。

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

    本当にそうだろうか?
    ちょっと気になったので、横軸に時間、縦軸に音量の階段状の図を描いてみました。
    以下のような図です。

             /┛
            /┛
           /┛
          /┛
         /┛
        /┛
        ┛

    現在の仕様は、発音時刻で0、止音時刻で127になっており、
    それを結ぶ直線上にきっちり階段の角(谷でなく山の方です)が乗りました。
    つまり、現仕様が最も誤差が少ない(理論上ゼロ)という事になります。

    「誤差が少ない事と実用性が高い事は、必ずしも一致する訳ではないんだなぁ〜」
    などという感慨を持ちながらこの図を眺めていたその時です。

      閃きました! \(^O^)/

    四捨五入とか、発音と止音だけ特別に半分のウェイト、といったキーワードで考えると処理が複雑そうですが、
    なんのことはない、階段全体を半ステップだけ曲頭側にずらせば良いのです!
    単に開始時刻を半ステップ減算するだけ。後に続く連続した発行処理は影響無しです。
    つまり初期値を変えるだけなので、プログラムは一行も増えません。
    これならば実装は驚異的に容易です。多分、実行時のコストもほとんど皆無に等しいと思います。

    発音側で遅延効果の出だしの反応が良くなるし、止音時点でちゃんと最後の値が反映する。
    しかも、全体としてきちんと線形で推移する。良いこと尽くめの気がします。

    Elekenさんご提案の四捨五入方式とは止音部分の出力が微妙に異なるのですが、
    でも以下の要請、
    > 1) V10V20:4d4 &V30:4d4
    > 2) V10V30:2d4 &d4
    > 私の感覚では、これらは同じ演奏となるべきであると感じます。
    は、しっかり満たしてますよ!

    本改修によって、実は理想的直線から外れてしまうことも判明しましたが、
    しかしそれでも尚、私はこの半ステップ曲頭ずらしの仕様の方が実用性は高いのではないかと感じ始めています。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8993/Re[5]: 遅延の出力仕様
■投稿者/ Eleken -(2013/06/17(Mon) 22:53:05)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    すみません、開発者さんの投稿を見て、前回の私の投稿[8987]の誤りに気が付きましたので、訂正させて頂きたく思います。

    > Elekenさんご提案の四捨五入方式とは止音部分の出力が微妙に異なるのですが、
    前回の投稿で、お恥ずかしい話ですが、頭の中のイメージを文字にする際に間違って書いていました。

    > ドの音出 →(ドの音止 → V10 → レの音出)⇒ V11 → V12 → ・・・ → V89 ⇒(レの音止 → V90 → ミの音出)→ ミの音止
    ではなく、
    > ドの音出 →(ドの音止 → V10 → レの音出)⇒ V11 → V12 → ・・・ → V90 ⇒(レの音止 → ミの音出)→ ミの音止
    と言いたかったのです・・・。コピペしたのがいけなかった!
    (こちらでないと、[8987]での要求事項が満たされませんね)

    で、この「真の四捨五入方式」は [8991]での開発者さんの方式と全く同じデータ出力となるはずです。

    [8989]で Αφροδιτη さんに
    > a の発音時刻に 0、止音時刻に127 を通る直線であるべきとするならば、Eleken さんの四捨五入方式が最も誤差の少ない実現と考えられます。
    と仰って頂いたのですが、これは [8987]を「真の四捨五入方式」のように解釈して頂いたのだと思います。

    #余談
    何を持って誤差とするかにもよるのでしょうが、本(開発者さんの)方式は最も誤差が少なくなるはずです。
    本方式は開発者さんの描かれたグラフ上に描くならば、音量の階段はちょうど直線の上に乗るはずです。
    誤差は階段と直線で囲まれる領域の面積だと考えられます。
    この誤差領域を現仕様と比較すると、2 方式ともにたくさんの三角形から成る領域ですが、
    本方式の誤差領域は 2 倍の個数の 1/4 の面積の三角形から成ることがわかると思います。
    よって、本方式の誤差は現仕様の半分 (2 * (1/4) = 1/2) と考えられます。
    また、現仕様から x ステップ(x∈[0,1])曲頭をずらした誤差領域の面積を S(x) とすると、
    S(x) は x=0.5 で最小値を取ります。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8996/Re[6]: 遅延の出力仕様
■投稿者/ 開発者 -(2013/06/18(Tue) 19:46:00)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    Elekenさん
    > [8989]で Αφροδιτη さんに
    >> a の発音時刻に 0、止音時刻に127 を通る直線であるべきとするならば、Eleken さんの四捨五入方式が最も誤差の少ない実現と考えられます。
    > と仰って頂いたのですが、これは [8987]を「真の四捨五入方式」のように解釈して頂いたのだと思います。
    今まで私は、階段の角の部分(そこが音量コマンドの発行点です)が、直線上に乗るのが誤差最小と思っていました。
    しかしこれは、とんだ勘違いでした。orz

    音は鳴り続けているのですから、直線上に乗っている事を確認するための対象は、コマンド発行点(階段の角の部分)ではなく、
    ある音量で鳴り続けている音そのもの、すなわち水平線分(階段の踏みしろ部分)だったんですね。
    そして、その線分の中点(平均点)が、直線と交差していれば誤差最小というわけですね。

    > #余談
    > 何を持って誤差とするかにもよるのでしょうが、本(開発者さんの)方式は最も誤差が少なくなるはずです。
    納得です。これで、更に今回の改修意義が高まりました。
    実施はほぼ決定です!

    ただ一点、互換性が崩れる点が惜しまれますが、まあ問題になるレベルではないと楽観しています。
記事No.8985 のレス / 関連記事表示
削除チェック/

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

    >>a の発音時刻に 0、止音時刻に127 を通る直線であるべきとするならば、Eleken さんの四捨五入方式が最も誤差の少ない実現と考えられます。
    > と仰って頂いたのですが、これは [8987]を「真の四捨五入方式」のように解釈して頂いたのだと思います。

    「解釈」を婉曲表現と解釈した上で、お察しの通りです。

    ……すみません。ちゃんと読んでいませんでした。
    なので、

    >>Elekenさんご提案の四捨五入方式とは止音部分の出力が微妙に異なるのですが、

    これ、何のことだろう? と思っていたのですが、Eleken さんのご説明でよくわかりました。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8995/Re[5]: 遅延の出力仕様
■投稿者/ けーご -(2013/06/18(Tue) 13:17:15)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    しかしあれですね、物凄く細かく出力されてるんですね。
    10tickくらいですか
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8986/Re[1]: 遅延の出力仕様
■投稿者/ 楠本 -(2013/06/16(Sun) 17:41:43)
□U R L/http://sinfonia.6.ql.bz/

    楠本です。お疲れ様です。地下機関室担当者さん。(笑)
    確認ですが、
    > において、終了時点の仕様を以下の様に改めることが可能です。
    >
    > 現仕様>  → V89 →(レの音止 → V90 → ミの音出)
    >
    > 新仕様>  → V89 → V90 →(レの音止 → ミの音出)
    >
    > 互換性がもろに崩れますが、演奏ニュアンスが大きく崩れることは無いと思います。
    > むしろ音源側の処理が分散されるため、モタレが軽減する可能性大です。
    > また強弱vの仕様との一貫性も出るので、新仕様の方が優れているかもしれません。

    > 皆様のご意見を聞かせていただければ幸いです。
    と云う事は、舵を切ったわけではないのですね。
    自分自身、最終値まで行っていると思い込んでいたし、多くの人はそう思っているんじゃないでしょうか。
    私は、内容からしても、新仕様の方がいいと思います。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.8994/Re[1]: 遅延の出力仕様
■投稿者/ 浅川 -(2013/06/18(Tue) 01:33:43)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    延滞機能についてもうひとつ...

    本来このような記述はないかもしれませんが...(^^;
    私なりに次のような仮設をたてて見ました。

    例@
    [srmf]2.:4

    とした場合「f」の音は発音されないのではないか...と

    で実行してみたら
    最後に「f」の音がプッとなりました。

    ためしにさらに
    例A
    [srmf]2.:4^16
    にしても実行結果は同様でした?

    これはもしかしたら時間の逆行を耳にしたか(笑)
    ...とおもいました。(笑)

    -----------
    [srmf]2.:4&,
    なら実際の演奏もあるかもしれませんね。
記事No.8985 のレス / 関連記事表示
削除チェック/

No.9006/Muse(V6.50)リリース
■投稿者/ 開発者 -(2013/06/24(Mon) 19:11:28)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    V6.50がリリースされました。

    今回、Readme.txtの開発後記において、
    V6.3でご協力頂いた方々のお名前を、
    遡って掲載させていただきました。
親記事 / 関連記事表示
削除チェック/

No.9007/譜面モニタについて
■投稿者/ 開発者 -(2013/06/26(Wed) 19:17:54)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    今回は、皆さんのご意見や経験を伺いたく記帳いたします。

    譜面モニタの右端にある垂直スクロールバーですが、
    これを積極的に使ったことがあるでしょうか?

    もし、これが無かったら困るでしょうか?
親記事 / 関連記事表示
削除チェック/

No.9008/Re[1]: 譜面モニタについて
■投稿者/ 浅川 -(2013/06/26(Wed) 20:14:56)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > 今回は、皆さんのご意見や経験を伺いたく記帳いたします。
    >
    > 譜面モニタの右端にある垂直スクロールバーですが、
    > これを積極的に使ったことがあるでしょうか?
    >
    > もし、これが無かったら困るでしょうか?
    小さなモニタ画面での作業のため入力環境を整えるには
    譜面モニタのスクロールは必須です。
記事No.9007 のレス / 関連記事表示
削除チェック/


パスワード/

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