Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (861-880 を表示) / 全ページ数 / [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.8949/Re[1]: V6.41公開
■投稿者/ MIZ -(2013/05/18(Sat) 23:09:13)
□U R L/http://n119ogmz.miraiserver.com/

    バージョンアップお疲れ様でした。＞開発者さま

    > (1)Readme.txtの開発後記を読み返していたのですが、
    > 　　2008.02.06の記述で、MIZさんを呼び捨てにしてました(苦笑)。
    > 　　長い間、気づかずにゴメンナサイ。m(__)m

    気づいてましたけど……^^;
    むしろ嬉しかったのでそのままにしてましたｗｗｗ
記事No.8948 のレス / 関連記事表示
削除チェック/

No.8950/まさに、キーボード(笑)
■投稿者/ 開発者 -(2013/05/26(Sun) 22:52:27)
□U R L/http://n119ogmz.miraiserver.com/

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

No.8951/Re[1]: まさに、キーボード(笑)
■投稿者/ MIZ -(2013/05/27(Mon) 04:58:43)
□U R L/http://n119ogmz.miraiserver.com/

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

No.8952/Re[1]: まさに、キーボード(笑)
■投稿者/ けーご -(2013/05/27(Mon) 16:12:49)
□U R L/http://n119ogmz.miraiserver.com/

    > これぞまさく、どの方向から見てもキーボードですねぇ〜。
    > http://medias.audiofanzine.com/images/normal/creative-labs-prodikeys-dm-362802.jpg
    >
    > なんだか妙に、ときめく製品ですね。もう売ってないかなぁ〜。
    なんじゃこりゃあ〜ｗ
    弾けなくても欲しくなりますねえ。
    テンキー省いてそこにタッチパッドでも

    近所のHardにはSK-88proだったか鍵盤つきのが置いてありましたね
記事No.8950 のレス / 関連記事表示
削除チェック/

No.8953/U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 楠本 -(2013/06/08(Sat) 19:12:13)
□U R L/http://sinfonia.6.ql.bz/

    新着記事がないので。（けっして愚痴ではありません。＾＾；）
    U指定で、：16を付けて、以降、：だけの記述をしていて、リロードすると、エラーが出た。
    U指定は、：だけの記述は駄目だったのに気が付かず、全て書き直した。Orz
親記事 / 関連記事表示
削除チェック/

No.8954/Re[1]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/08(Sat) 22:20:27)
□U R L/http://sinfonia.6.ql.bz/

    > 新着記事がないので。（けっして愚痴ではありません。＾＾；）
    楠本さん、ご記帳ありがとうございます。
    掲示板ページが空っぽだと淋しいですよね。^^;

    > U指定で、：16を付けて、以降、：だけの記述をしていて、リロードすると、エラーが出た。
    > U指定は、：だけの記述は駄目だったのに気が付かず、全て書き直した。Orz
    お手間を取らせて申し訳ありません。
    お気づきの通り、現在のMuse文法仕様では遅延系音長を省略できません。
    アルペジオは省略できますが、テンポ、音量、強弱、ピッチ、Ｘ指定、ステレオ、残響、揺らぎ、コーラスなど
    すべて省略不可となっています。

    もし省略可能とするならば、これらの遅延音長は独立した省略値を持っていた方が良いと考えていますが、
    更に、メンバー単位、フィンガー単位で独立した記憶が必要と思われます。
    掛け算で効いてくるのでかなりの記憶量になります。
    プログラム上はメモリが多少圧迫されるだけなのであまり気にしてないのですが、
    実際の使用において利用者の方が迷子になってしまいそうで不安です。
    フィンガー情報に最終値を提供すべきと思いますが、大変な賑わいになりそうです(苦笑)。
    （現在でもアルペジオ省略値は表示して無いんですけど）

    一方、省略記法というのは別の意味で有効活用できることに気づいています。
    例えばマクロを省略状態で定義しておけば、その遅延音長は呼び出し側で直前に記述した音長が採用されるので、
    遅延音長が変数化された状態でマクロを活用することができます。
    仕様として如何にあるべきかを考え始めると、なかなか奥の深い領域です。

    なんにせよ、今のところ安易にサポートするのを控えております。
    一度サポートすると、互換性を維持するためにもう後戻りできないからです。
    逆に省略可能の方向に仕様変更する場合は、互換性を気にする必要は無いのでやる気になればいつでもやれます。

    行きはヨイヨイ帰りは怖い〜♪
    ってとこでしょうか。(笑)
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8955/Re[2]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/09(Sun) 09:20:09)
□U R L/http://sinfonia.6.ql.bz/

    そうですねぇ、同種の直前の遅延音長を省略時の遅延音長にしてほしいと思ったことは、記憶にないですねぇ。
    遅延を繰返す場合は、大抵元に戻す命令とセットになるので、一緒にマクロにしてしまうことが多い気がします。
    たとえば {U+120:1_1U0} みたいに。
    (やったことありませんが、[(drmfslc<d>){(v+64:1_v-64)}]1[(rmfslc<dr>){}] とかありですか?)

    そういえば、遅延音長の省略時に、直後の音符(というか特に休符)の音長になるといいなと思うことは、ときどきあります。
    たとえば、V+127:1`3^2^4..^i30_1`3^2^4..^i30 みたいなときです。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8956/Re[3]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/09(Sun) 14:28:46)
□U R L/http://sinfonia.6.ql.bz/

    Αφροδιτηさん、ご意見ご感想、ありがとうございます。

    省略記法をサポートする際に、私が特に留意しようと思っているのは、
    前向きにガンンガンMusingしている最中よりもむしろ、データ完成後しばらくして手直しするフェーズです。
    その際、省略されている部分の実際の値が比較的容易に判別できるようにすべきだと考えています。
    うまく設計しないと、たとえ自分のデータであっても大変イラつくことになりそうですから。

    その意味で、現在の音符の音長における省略記法は、
    大概、省略された音符の傍に実音長があるのでこの条件を満たしていると思います。
    (アルペジオはちょっと危ないですね)苦笑

    > そういえば、遅延音長の省略時に、直後の音符(というか特に休符)の音長になるといいなと思うことは、ときどきあります。
    > たとえば、V+127:1`3^2^4..^i30_1`3^2^4..^i30 みたいなときです。
    確かにこの状況は、結構ありますね。特に音長がこの例の様に繊細な指定の場合は尚更です。
    この方向での対応ならば、実音長が常に傍にありそうなので上記の条件も満たしそうですね。

    残された課題は、簡潔明瞭な文法ルールに昇華させていくことですね。
    特に、参照先が直前ではなく直後にあるという点が今まで無かったタイプなので、
    慎重に検討する必要があるかもしれません。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8957/Re[4]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/09(Sun) 18:42:50)
□U R L/http://sinfonia.6.ql.bz/

    > (アルペジオはちょっと危ないですね)苦笑

    アルペジオの音長省略は結構使うと思います。
    これは「元に戻す」必要がないので。
    省略時の音長に限らず、任意の時点で暗黙に保持している状態というものがかなりあって(たとえば遅延の対象になっているものはすべて)、それらはみな同様の危険を孕んでいるように思います。
    でも、それらをいちいち明示指定してはいられないので、それはシーケンサの、というかテキストの宿命のような気がします。
    Muse は、安全と利便のトレードオフの取り方が絶妙と思います。

    > 特に、参照先が直前ではなく直後にあるという点が今まで無かったタイプなので、
    > 慎重に検討する必要があるかもしれません。

    v を除いて、フィンガー毎の指定値をメンバ毎のデフォルト値に使用する点も今まで無かったタイプでしょうか。
    とにかく私は思い付きで書いていますので、慎重にご検討いただければと思います。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8959/Re[5]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/09(Sun) 21:05:35)
□U R L/http://sinfonia.6.ql.bz/

    Αφροδιτηさん

    > 任意の時点で暗黙に保持している状態というものがかなりあって(たとえば遅延の対象になっているものはすべて)
    なるほど。その通りですね。
    Museの遅延指定は終了値と遅延音長のみで、開始値は現在の値を採用する方式なので、
    同じ事が言えるわけですね。流石、ご明察です。

    > Muse は、安全と利便のトレードオフの取り方が絶妙と思います。
    ありがとうございます。
    遅延で開始値を指定しないという方式は、実は私の発案ではなく、
    開発初版の頃に助言してくれた私の友人(百元さん)のアイディアです。
    その後、私自身も幾多のMusingを行いましたが、この記法はとてもエレガントだと思いました。

    こと音楽に関しては、その瞬間々々にそれぞれの属性がある値を保持しており、
    通常はその値を基点に変化することがほとんどです。つまり開始値というのは現行値そのものなわけです。
    一方、開始値を明に指定したければ遅延無しの記述を直前に書いておけば良い訳ですから、
    表現力も犠牲にしている訳でもない。誠に見事な記法だと思います。
    この遅延記法を私に授けてくれた百元さんに、今でも感謝しています。

    私が単独で設計していたら、プログラム言語の様な(From,To)の文法を組んでいたかもしれません(苦笑)。
記事No.8953 のレス / 関連記事表示
削除チェック/

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

    ちょっと横から失礼いたします。(^o^)/

    > たとえば、V+127:1`3^2^4..^i30_1`3^2^4..^i30 みたいなときです。

    確かに、同じようなことを思うとき、ありますね〜
    ただコレ、フィンガーを目的別に分けている前提での話ですよね？

    フィンガーを分けると見た目はすっきりします。
    ただ、微妙な設定をした場合などは、フィンガー間で同期を取るのが意外に面倒で、
    ひとつにまとまっているほうがその後の微調整・メンテがラクだと、最近感じてます。
    この場合、遅延指定のあとには直接「音」を指定することになるのですが…

    省略記述は確かに便利かもしれません。
    がしかし、遅延指定のあとに休符を指定する場合もあれば、そうでない場合もあるわけで、
    解析ロジックとともにルールの設定が難化するのではないかと思います。

    自分の場合、特に「U指定」での遅延効果には拘りを持っていまして、直線的なピッチシフトを
    避けるようにしてます。

    例えば、ある音をオクターブ上にピッチシフトさせるとしたら、

    a4&U+120:2a2.

    と指定するのが無難な気がしますが、実際の演奏を考えると結構不自然に聞こえます。
    そこで自分は、「初速」⇒「定速」⇒「終速」のように複数の遅延タイミングを持たせて、

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

    という指定をするのですが、こういった場合は同一フィンガー上で指定するほうが直観的に扱え、
    かつ自然なグリッサンドに聞こえると思います。

    なので、「遅延効果を省略する」という発想がそもそもありませんでした。
    （考える人は考えるものなのだと驚いています）
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8960/Re[4]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/09(Sun) 21:27:01)
□U R L/http://sinfonia.6.ql.bz/

    takaさん

    > ちょっと横から失礼いたします。(^o^)/
    いえいえ、ご意見、大歓迎です。
    いろいろな角度から、考察や分析が渦巻いて楽しくなります。
    楠本さんのつぶやきのお陰で、なんだか面白くなってきました＼(^o^)／

    > そこで自分は、「初速」⇒「定速」⇒「終速」のように複数の遅延タイミングを持たせて、
    > a4&U+20:8a8&U+90:4a4&U+120:8a4.
    > という指定をするのですが
    なるほど。直線ではないのですね。
    別の話題になるかもしれませんが、これを簡便に記述する文法を考えるのも面白そうなテーマですね。
    すぐに思い付くのは、

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

    といった感じでしょうか。つまり
    「連続する同一属性の遅延は発行位置を遅延音長分、連続的に進行させていく」
    という仕様です。

    これで、連結＆の間に挟む場所は一箇所に集約できます。
    でも、文字数にしたらほんの少しの節約にしかならないし、
    コーディングイメージと演奏の対応関係という意味で、かえって見通しが悪くなっちゃうかも(笑)。

    他にも何か良いアイディアがあるといいんですが。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8961/Re[5]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ taka -(2013/06/09(Sun) 22:17:46)
□U R L/http://sinfonia.6.ql.bz/

    エラく速い反応だったので戸惑っております。(@o@;)

    > なるほど。直線ではないのですね。

    速いパッセージでは、不自然さを感じる前に音が流れていってしまうため、ほとんど気づきませんが、
    実際の演奏経験からすると、グリッサンドは「ポジションの物理的な移動」によって実現できるものなので、
    初動はともかく、終端間際は間違いなく移動速度が落ちます。

    イメージとしては、「終端間際でポジションを探すため移動速度が落ちる」ってトコでしょうか。
    ⇒単に「下手っぴ」という噂も…(#^_^#)

    > 別の話題になるかもしれませんが、これを簡便に記述する文法を考えるのも面白そうなテーマですね。
    > すぐに思い付くのは、
    >
    > a4 & U+20:8U+90:4U+120:8 a2.
    >
    > といった感じでしょうか。

    なんだか「U指定」をオーバーレイ的に扱えるので、「タイミングに合わせて音をブツブツ切る」という必要が
    なくなりますね。
    「記述量を減らす」ことより「狙った効果の表現のし易さ」があるので重宝すると思います。
    ⇒少なくとも私は。

    でも、通常の「U指定」等は「時間」の概念がないのに、ご提示案では逆に「時間」の概念が必要ですね。
    現在の文法に倣えば「U+20:8U+90:4U+120:8」などという指定はされていないハズですので、
    新たに文法として組み込まれても大きな問題にはならないように思います。
    （とは言え、自分も含め誤記ってる可能性は否めません…）
    しかし、これをロジック化するのが面倒そうで…

    もし喜々としてご検討いただけるのでしたらうれしい限りです。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8962/Re[6]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/09(Sun) 23:01:15)
□U R L/http://sinfonia.6.ql.bz/

    takaさん
    > 現在の文法に倣えば「U+20:8U+90:4U+120:8」などという指定はされていないハズですので、
    > 新たに文法として組み込まれても大きな問題にはならないように思います。
    > （とは言え、自分も含め誤記ってる可能性は否めません…）

    おっと、互換性の件を忘れてました(笑)。
    確かに危ないですね。
    確実に上位互換を狙うならば、現時点で文法エラーになってしまう記法にするしかないですね。

    例えば、

    a4 & U+20:8 -> U+90:4 -> U+120:8 a2.

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

No.8965/Re[7]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/10(Mon) 00:16:55)
□U R L/http://sinfonia.6.ql.bz/

    > a4 & U+20:8 -> U+90:4 -> U+120:8 a2.

    こういうの、私も欲しいです。
    この扱いは同種の属性に対する遅延のみに限ってよいと思われるので、いっそ

    U+20:8 +90:4 +120:8

    でどうでしょう?
    0 のときは、この場合だけ + か - を付けるようにするとかで。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8966/Re[8]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/10(Mon) 00:39:50)
□U R L/http://sinfonia.6.ql.bz/

    Αφροδιτηさん
    > この扱いは同種の属性に対する遅延のみに限ってよいと思われるので、いっそ
    > U+20:8 +90:4 +120:8
    > でどうでしょう?
    > 0 のときは、この場合だけ + か - を付けるようにするとかで。

    新しい文法を考える時、抽象化された概念をきちんと与えられるかということが大切だと思っています。
    具体的には、その記法に明確な「名称」が付与できるかどうかです。
    それはReadme.txtでわかりやすく説明する時にも重要であり、
    明快な文法であるかどうかの試金石でもあると思っています。

    その意味で、この文法には名称を付けることが出来ます。
    「属性の連結」です。

    Αφροδιτηさんの提言は、
    属性記号Ｕを記載しないことで、一気に連結記号も記載不要としてしまうという
    実に大胆かつ秀逸な発想だと思います。

    ただこの「属性連結」は、Ｕだけでなくあらゆる属性に適用可能としたいところです。
    例えば、音量Ｖ。
    音量Ｖはダイレクトに数字が付いているので、Ｖを省略するとその前の遅延音長とくっ付いてしまいます。

    V20:8 -> V90:4 -> V120:8
    ↓
    V20:8 90:4 120:8

    ですから、やはり連結記号はあったほうが良いと考えています。
    ただ、実装の負荷を下げるためにも、その連結記号は１文字にしたいところです。
    上記例では、−＞になっていますが、それに代わるものとして、＝を考えていました。

    a4 & U+20:8 -> U+90:4 -> U+120:8 a2.
    ↓
    a4 & U+20:8 = U+90:4 = U+120:8 a2.

    そして「属性連結は同一属性間のみである」というのも事実です。
    ちょうど「音符連結は同音程のみである」ということと呼応している感じですね。

    ですから、属性記号は省略できます。
    a4 & U+20:8 = U+90:4 = U+120:8 a2.
    ↓
    a4 & U+20:8 = +90:4 = +120:8 a2.

    こうなると、＝で連なった一塊が、本来のＵ指定であるという感じがしてきます。
    上記の例は、ちょど全体で２分音符の音長を持っていますが、
    単一直線で変化する値を、折線で変化させるという概念になります。
    U+120:2
    ↓
    U+20:8=+90:4=+120:8

    てな感じです。
    ただ、音符連結が
    d4 & d8
    ↓
    d4 & 8

    としていないのと同じ理由で、あえて属性記号を省略しない方が判読性が高いかもしれません。
    U+20:8=+90:4=+120:8
    ↓
    U+20:8=U+90:4=U+120:8

    面白いテーマですね。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8968/Re[9]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/10(Mon) 01:01:21)
□U R L/http://sinfonia.6.ql.bz/

    > 音量Ｖはダイレクトに数字が付いているので、Ｖを省略するとその前の遅延音長とくっ付いてしまいます。

    おっと、忘れていました。
    % とかもだめですね。

    > a4 & U+20:8 -> U+90:4 -> U+120:8 a2.
    > ↓
    > a4 & U+20:8 = U+90:4 = U+120:8 a2.
    > ↓
    > a4 & U+20:8 = +90:4 = +120:8 a2.

    こちらもよい仕様と思います。
    値が + か - で始まるときは、連結記号も省略できれば嬉しいです。

    > ただ、音符連結が
    > d4 & d8
    > ↓
    > d4 & 8
    >
    > としていないのと同じ理由で、あえて属性記号を省略しない方が判読性が高いかもしれません。
    > U+20:8=+90:4=+120:8
    > ↓
    > U+20:8=U+90:4=U+120:8

    そうですね。場合によって使い分けるようにしたいです。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8979/Re[10]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ 開発者 -(2013/06/12(Wed) 22:50:59)
□U R L/http://sinfonia.6.ql.bz/

    なんだか、立て続けに記帳してしまって恐縮なのですが、
    忘れないうちに書いておこうと思います。

    話は変わって「属性の連結」の方の話題です。

    [8968] Αφροδιτηさん
    >> a4 & U+20:8 -> U+90:4 -> U+120:8 a2.
    >> ↓
    >> a4 & U+20:8 = U+90:4 = U+120:8 a2.
    >> ↓
    >> a4 & U+20:8 = +90:4 = +120:8 a2.
    >
    > こちらもよい仕様と思います。
    > 値が + か - で始まるときは、連結記号も省略できれば嬉しいです。

    情報量が満たされていれば、極力省略の道を開拓しようとする
    Αφροδιτηさんの意気込みに乗じて、一つの考察を加えてみました。

    現在、音符には音長を長くするための手段が２つあります。
    (1)音符の連結 d4 & d4
    (2)音符の加算 d4 ^ 4

    (1)は後半の音符の省略はできません。(2)は省略どころか、そもそも記述しないのが前提です。

    実は今回の属性のテーマに関しては、私はどちらかというと(1)のイメージで検討を進めていたような気がします。
    　　　U+20:8 = U+90:4 = U+120:8

    対して、Αφροδιτηさんは(2)のイメージで本件を掘り下げているのではないか、という憶測です。
    　　　U+20:8 +90:4 +120:8

    つまり、発想に「遅延属性の連結」と「遅延属性の加算」といった違いがあるのではないか、という仮説です。

    前者はあくまでも、U+20:8、U+90:4、U+120:8、がコマンド発行単位であり、それが連結されるというイメージです。
    ですからUや=の省略という概念を持ち込むと後々問題が出るかもしれません。（マクロ記述単位など）

    対して後者は、U+20 という核となる１つのコマンドが発行され、
    そこに付与される遅延音長を加算的に記述（:8 +90:4 +120:8）できるというイメージです。

    どちらが優れているのかという話をするつもりは毛頭ありません。
    現に音符の音長に関しては、今のMuseは両方サポートしているわけですから。
    ただ両者は別物として扱った方が、将来的に破綻する恐れが少ない気がしてきました。

    蛇足かもしれませんが、マクロ記述の柔軟性からいうと(1)がちょっと有利な気もします。
    多分(2)の方向ですと、(これは今のMuseの作りに問題があるのですが)
    部分的に切り出してマクロ化することはできない（つまり、全体で１つの指定として扱われる）仕様になると思います。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8983/Re[11]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/13(Thu) 20:36:36)
□U R L/http://sinfonia.6.ql.bz/

    > 情報量が満たされていれば、極力省略の道を開拓しようとする
    > Αφροδιτηさんの意気込みに乗じて、一つの考察を加えてみました。

    意気込みと仰っていただいてありがたいです。
    実態は惰性だったりします。
    僭越ながら、怠惰はプログラマの三大美徳の一つと固く信じております
    (言うまでもなく、Perl の哲学の受け売りです)。

    > 実は今回の属性のテーマに関しては、私はどちらかというと(1)のイメージで検討を進めていたような気がします。
    > 　　　U+20:8 = U+90:4 = U+120:8
    >
    > 対して、Αφροδιτηさんは(2)のイメージで本件を掘り下げているのではないか、という憶測です。
    > 　　　U+20:8 +90:4 +120:8
    >
    > つまり、発想に「遅延属性の連結」と「遅延属性の加算」といった違いがあるのではないか、という仮説です。

    私如きの発想過程を開発者さんのご思索の対象にお取り上げていただくなんて恐悦ですが、公式の場を借りてさせていただくのは申し訳ない話題ですので、続きはあびやにてといたしたいです。

    > どちらが優れているのかという話をするつもりは毛頭ありません。
    > 現に音符の音長に関しては、今のMuseは両方サポートしているわけですから。
    > ただ両者は別物として扱った方が、将来的に破綻する恐れが少ない気がしてきました。

    同じことをする方法が複数あるのは悪ではないと思います(性懲りありません)。

    Muse がさらにゴージャスになりそうな予感がします。
記事No.8953 のレス / 関連記事表示
削除チェック/

No.8963/Re[4]: U+120:1({また}2つぶやいてみましたぁー)1
■投稿者/ Αφροδιτη -(2013/06/09(Sun) 23:53:51)
□U R L/http://sinfonia.6.ql.bz/		 

    >>たとえば、V+127:1`3^2^4..^i30_1`3^2^4..^i30 みたいなときです。
    > 
    > 確かに、同じようなことを思うとき、ありますね〜
    > ただコレ、フィンガーを目的別に分けている前提での話ですよね？

    No です。

    上の例はそうですが、一般的に「直後の音符(……)の音長」と書いたのは、
    フィンガーを目的別に分ける／分けないに拘らず有効と思われるからです。

    > a4&U+20:8a8&U+90:4a4&U+120:8a4.
              ^        ^
    の場合も、^ をつけた音長が省略できることになります。
    メンテの時、必然的に同じになる音長を 2 箇所同じように修正するのは
    面倒ではありませんか?
記事No.8953 のレス / 関連記事表示
削除チェック/

パスワード/

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