Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ2 を表示

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

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

No.6869/Re[5]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ PT2K -(2009/11/11(Wed) 07:20:21)

    >>,（半角カンマ 99997個 略）,
    > この場合と、
    >
    > {,}99999
    >
    > この場合とでは有意差は出るでしょうか。(snip)

    ああ、これには気づきませんでした。なるほど。早速やってみました。

    t2.mus → T2.mid：2.82±0.02 秒
    t2.mus → T2.mid：2.79±0.01 秒
    p ≒ 0.00019609298316743300

    99.98 % の確率で有意差あり、と出ました

    マクロを使った短い記述でも、処理効率が上がるようです

    ただし、その差はわずか（1.06 %）なので、データの制作効率を落としてまでマクロを使いまくるよりは、ベタ打ちの方がいい場合も多いでしょう
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6870/Re[6]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ MIZ -(2009/11/11(Wed) 07:59:15)
□U R L/http://n119ogmz.hobby-site.com/

    > t2.mus → T2.mid：2.82±0.02 秒
    > t2.mus → T2.mid：2.79±0.01 秒
    > p ≒ 0.00019609298316743300
    >
    > 99.98 % の確率で有意差あり、と出ました
    >
    > マクロを使った短い記述でも、処理効率が上がるようです

    実に興味深い（どっかであったセリフ？^^;）ご検証ありがとうございました。

    マクロに対しては
    「展開されるたびに（定義された）マクロを読みに行く」というイメージがなんとなくあったもので(？？？汗)、
    妙にホッとしてしまいました……^^;
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6871/Re[7]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ 開発者 -(2009/11/11(Wed) 19:13:29)
□U R L/http://n119ogmz.hobby-site.com/

    > 記述量が増えれば、Museの処理時間は増える？
    楠本さん、“実に興味深い”話題のご提供、ありがとうございました。
    そしてPT2Kさん、学術的雰囲気の漂う、すっげーかっちょいいレポートいかしてました。

    > それぞれ、最初の 3回を捨てて、10回の平均と標準偏差を取った
    この科学的かつ客観的なアプローチ、本当にスマートで素敵です。

    ちなみに、
    「Museの処理時間」といったとき、以下の３つに大別されます。
    (1)ロード時間（ここでMuse文法の解析を行っています)
    (2)演奏時の処理
    (3)MIDIエクスポートの処理

    お分かりとは思いますが、PT2Kさんの実証は、(1)+(3)の処理時間となります。
    この、マクロや再現表記を活用した場合の方が短時間にコンパイルが完了するという事実は、
    実は開発者である私も意外でした。両者とも大変込み入った処理を行っていますので・・・。
    もちろん、メモリ効率や処理効率を極限まで高める事に心魂したつもりです。
    その甲斐があったことを、今回のPT2Kさんの検証が示してくれた様な気がします。
    改めて深く感謝いたします。

    一方、
    MIZさんは特に(2)に関しての効率に危惧されていたようですが、これに関してはご安心下さい。
    マクロにしても再現表記にしても、定義部を展開する処理はロード完了時点で解決しています。
    Muse演奏時点での負荷に関しては、あらゆるものに優先して排除するよう心掛けたつもりです。

    その意味で、(3)のMIDIエクスポートは文字通り一瞬で完了するはずです。
    (2)の段階で処理に負荷を与えないためには、
    その時点で(3)で必要とする構造がほとんど出来上がっていなければならないからです。

    以上のMuseの内部処理のシナリオは、PT2Kさんのレポート
    > また、生成された T1.mid と T2.mid は、ファイルサイズが同じであり、diff を取ってみてもまったく同一のファイルであることが証明された
    が、一種の裏付けとなっております。

    (追伸)
    > 加藤さん、再来年あたり一発、本でも書いてみませんか？
    キャハハハッ。
    でもその前に、自分のサイト、更新しなきゃねぇ〜(笑)
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6872/Re[5]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ 楠本 -(2009/11/11(Wed) 22:29:09)
□U R L/http://sinfonia.6.ql.bz/

    開発者さん、PT2Kさん、MIZさん、ありがとうございます。

    PT2Kさん、最後のお願い聞いて頂けないでしょうか。

    x1
    {[o3cego4cego5ceg]64}100000

    この場合です。
    これで最後にしたいと思いますので宜しくお願いします（笑）。
    あぁ、もっとよく考えて書き込めばよかった（後悔）＾＾；
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6873/Re[6]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ PT2K -(2009/11/12(Thu) 07:26:42)
□U R L/http://sinfonia.6.ql.bz/

    > x1
    > {[o3cego4cego5ceg]64}100000
    またまた、なるほど。やってみました。

    t1.mus → T1.mid：3.63±0.02 秒
    t2.mus → T2.mid：2.84±0.01 秒
    t3.mus → T3.mid：2.78±0.02 秒
    t4.mus → T4.mid：2.74±0.03 秒

    t1-t4：p ＜ 0.00000000000000000001
    t2-t4：p ≒ 0.00000013199219387836
    t3-t4：p ≒ 0.00528395391644895000

    それまでのいずれの記述方法よりも処理効率が有意に高いと言えそうです
    マクロすごい

    > これで最後にしたいと思いますので宜しくお願いします（笑）。
    いえいえ、面白いネタありがとうございます
    まだ興味深い比較がありましたら、ご遠慮なくどうぞ（^^
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6876/Re[7]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ るう -(2009/11/15(Sun) 02:35:45)
□U R L/http://sinfonia.6.ql.bz/

    何やら私の心をくすぐる話題がｗ
    というわけで各結果を考察してみました。

    ＞t1.mus(全てベタ書き)
    10000回全てについて構文解析が入るため、他のパターンよりも極端に遅くなる。

    ＞t2.mus(カンマをベタ書き)
    「,」は全て初回のデータを参照するため、時間はかからない。ただし「,」自体を毎回構文解析するため無駄が生じる。

    ＞t3.mus(カンマをマクロ化)
    「,」は初回のデータを参照するため、時間はかからない。また、「,」自身は1回のみ構文解析され、残りはコピーされるだけなのでt2.musよりも高速になる。

    ＞t4.mus(最初からマクロ化)
    初回のデータが構文解析されたものが直接コピーされるため、一旦「,」の内容を検索する必要のあるt3.musよりも高速になる。

    所要時間の差を考えるとこんな感じかと思うのですが、いかがでしょうか？＞開発者様
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6877/Re[8]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ σ -(2009/11/15(Sun) 06:19:37)
□U R L/http://sinfonia.6.ql.bz/

    ファイルの処理時間膨張 / 短縮の大きな要因はファイルサイズではないでしょうか?
    少なくとも t1, t2, t3 の比較においてはそれが主な原因のような気がします．

    実際，t1.mus のファイルサイズは t2.mus のそれの約 20 倍，
    t3.mus に関しては t2.mus と比べてほぼ 0 に等しくなっています．
    なので，仮に処理時間差が完全にファイルサイズの差に比例するとしたならば，
    t1-t2 の処理時間差は t2-t3 のそれのほぼ 19 倍であることになります．
    [6873] によると t1-t2 の処理時間差は平均値で 0.79 [sec]，その 1/19 倍は約 0.042 [sec]．
    t3 の観測結果の分散が高いこともあるので，
    t2-t3 の真の期待値が 0.04 [sec] 程度である確率はさほど低くないと思われます．

    また，Muse がファイルを読み込むには HDD にアクセスする必要があります．
    一方 Muse がファイルの文法解析等を行うのは RAM 上になります．
    (Muse が中間ファイルなどを出力している様子はないため．)
    RAM の読み書き速度は圧倒的に HDD のそれに勝ります．
    なのでこの実験では文法解析に掛かる処理時間はあまり
    表に出てきていないように思われます．

    ただ，t3-t4 の比較では，再帰記号「,」の定義参照を毎回する必要があるかどうかの
    違いが表に出ている様に思われます．
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6879/Re[9]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ PT2K -(2009/11/15(Sun) 15:36:31)
□U R L/http://sinfonia.6.ql.bz/		 

    > ファイルの処理時間膨張 / 短縮の大きな要因はファイルサイズではないでしょうか?
    やってみました

    t1.mus は以前のもの

    ---t2_2.mus---
    x1
    [o3cego4cego5ceg]64
    ,（半角スペース 18個）
    （99997行 略）
    ,（半角スペース 18個）
    ---t2_2.mus---
    2,000,003 bytes

    t1.mus と t2_2.mus のファイルサイズを揃えてみました

    結果：
    t1.mus   → T1.mid  ：3.62±0.01 秒
    t2.mus   → T2.mid  ：2.81±0.01 秒
    t2_2.mus → T2_2.mid：2.85±0.01 秒
    t1 - t2_2：p ＜ 0.00000000000000000001
    t2 - t2_2：p ≒ 0.00000000187865488725
    ファイルサイズの比較 t2/t2_2： 5.0%
    コンパイル時間の比較 t2/t2_2：98.6%

    ファイルサイズの差による影響は微々たるもののようです
    これは、実験プロトコールで最初の 3回を捨てていますので、
    mus ファイルは最初の読み込みの際にメモリ上にキャッシュされ、
    2回目からはオンメモリのファイルが読み込まれることになるからでしょう
    因みに、1回目からのコンパイル時間は、3.07秒→2.81秒→2.81秒 と経過しました
    t1.mus、t2.mus でも同様に、1回目だけ非常に時間がかかっています

    るうさんのおっしゃる構文解析のコストと、メモリのアロックのコストが、
    コンパイル時間の差の大きな原因なのではないでしょうか？ ＞ 開発者様
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6882/Re[10]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ 開発者 -(2009/11/17(Tue) 21:53:29)
□U R L/http://sinfonia.6.ql.bz/

    σさん
    > ファイルの処理時間膨張 / 短縮の大きな要因はファイルサイズではないでしょうか?
    > 少なくとも t1, t2, t3 の比較においてはそれが主な原因のような気がします．

    るうさん
    > 初回のデータが構文解析されたものが直接コピーされるため、一旦「,」の内容を検索する必要のあるt3.musよりも高速になる。
    > 所要時間の差を考えるとこんな感じかと思うのですが、いかがでしょうか？＞開発者様

    PT2Kさん
    > ファイルサイズの差による影響は微々たるもののようです
    > るうさんのおっしゃる構文解析のコストと、メモリのアロックのコストが、
    > コンパイル時間の差の大きな原因なのではないでしょうか？ ＞ 開発者様

    PT2Kさんの「大量の半角スペースを埋め込んでファイルサイズを揃えたデータ」方式の
    実験結果から、私もファイルサイズは大きな要因ではないと思いました。
    （こういった実験方式を思いつくこと自体がPT2Kさんの才能の素晴らしさがうかがえます）

    私も、一番大きい要因はメモリアロケーション処理のような気がします。
    マクロや再現表記は定義部で確保したメモリ域をそのまま活用するよう工夫しているので、
    新たなメモリアロケーションもしていないし、直接コピーも行っていません。
    無論、定義域へのアドレスを記憶するためのノードはメモリ確保しますが、
    それはマクロや再現表記の大きさに依存しない小さな構造体です。
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6898/Re[11]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ σ -(2009/11/22(Sun) 05:01:00)
□U R L/http://sinfonia.6.ql.bz/

    PT2Kさん
    更なる実験ありがとうございました．

    2 つの点で私の仮説が否定されましたね．
    1 つ目の点は，2 回目以降の試行ではメモリ内にキャッシュされたデータから読み込むので殆ど時間がかからないということ．
    2 つめの点は，実際にファイルサイズはロード時間に殆ど影響しないということ．

    「ファイルサイズが大きいため読み込みには時間が掛かる」という先入観があって，
    実際に差分を計算してやると妙に計算が合ったので・・・．
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6874/Re[6]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ MIZ -(2009/11/12(Thu) 08:17:36)
□U R L/http://n119ogmz.hobby-site.com/

    > 開発者さん、PT2Kさん、MIZさん、ありがとうございます。
    ワタシは楠本さんのご質問に便乗させていただいちゃっただけで、
    お礼を言われるようなコトは何も……^^;;;

    今回の楠本さんのご質問がきっかけで、
    ワタシ自身長年ココロにひっかかっていた心配がはっきり解消できました。
    ワタシのほうこそお礼を言わせてください。
    楠本さん、ありがとうございました^^

    PT2Kさん、
    教え方が大変上手な先生から数学の授業を受けているようでしたｗ
    心から納得ができる説明をもらえるって、ホントに気持ちがいいモンです^^

    加藤さん、
    改めてMuseの安定感・すごさを再確認です。
    マクロ・再現表記もコレで安心して使っていけます^-^;

    ■musデータ → MIDIエクスポートで
    “どれだけサイズが膨れ上がるデータを作れるか”追求してみたくなったり……(笑)
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6875/Re[6]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ 楠本 -(2009/11/12(Thu) 20:27:34)
□U R L/http://sinfonia.6.ql.bz/

    PT2Kさん、本当にありがとうございました。
    最後はしつこくなってしまいましたが、ちょっと心に引っかかりが有ったので・・・。
    でも、これですっきりしました。改めて深く感謝いたします。
    マクロも再現表記も凄いですね。勉強します＾＾；
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6864/Re[1]: しつも〜ん！記述量と処理時間との関係について
■投稿者/ MIZ -(2009/11/10(Tue) 21:40:29)
□U R L/http://n119ogmz.hobby-site.com/

    > 記述量が増えれば、Museの処理時間は増える？それとも変わらない？どっちでしょうか。

    ワタシもコレ知りたいです……^^;
    特に「マクロ」。
    ワタシはマクロ記述を結構多用しているのですけども。
    マクロにより記述量が少なくできたとしても、マクロの数・種類があまりに多いのは Museには逆に負担かけるんでしょうか？(汗)
    　（……あれ、そういえばマクロ数って上限あるのかな？？^^;）

    > 凄いデータで、記述量も凄いのでは・・・と思いきや「えっ、たったこれだけの記述量で？！」とビックリする時があります。

    前述のとおりマクロや再現表記を多用してるせいか、エクスポート後のファイルのサイズが驚くほど膨れ上がるときがありますね〜^^;
    連続可変タイプのコントロール（Vとか Uとか）の遅延をたくさん記述していた場合は特に大きくなるようです^^;
    （エクスポートすると、遅延の「中間値」が１コ１コすべて吐き出されますゆえ）(汗)

    　※でもネットで拾った MIDI ファイルを MID2MUS で musデータに変換すると、逆にサイズ大きくなるコトが……(笑)
記事No.6862 のレス / 関連記事表示
削除チェック/

No.6878/新文法 / 機能の提案
■投稿者/ σ -(2009/11/15(Sun) 06:30:19)
□U R L/http://n119ogmz.hobby-site.com/

    お久しぶりです σ です．覚えてらっしゃいますでしょうか?
    Muse に対する要望がいくつか温まり，固まってきたので提案したいと思います．
    かなりの長文になっております．ご容赦ください．

    (i) 負音長の休符の導入
    説明するまでもないかもしれませんが，負音長の休符とは，
    「現在のフィンガーの，譜面上の記述位置を "巻き戻す" 休符の体をとった記号」
    という意味です．

    私の musing のスタイルは，楽曲を (概ね) 4 小節ごとに区切って，
    その 4 小節ごとに全メンバー，フィンガーの内容を記述していくものです．

    しかし弱起の曲などでフレーズをマクロ化したいときなどに
    最初の部分がこの「4 小節」からはみ出して，
    なかなかきれいにマクロ化しにくいことがあります．

    また，メンバー属性の P, V などはその音を鳴らし始める 1, 2 小節前に
    設定しておくのが慣例ですが，その指定を「前の 4 小節」の部分に記述することが
    余儀なくされるためどうしても見にくいソースコードとなります．

    前者のマクロ化に対しては今のところ，フィンガー属性 p, q と
    和音記号 [ ] で対処していますが， p, q を変更することになるので
    p, q に特別な値を指定していた場合には注意が必要になります．
    また，後者のメンバー属性に関しては「見にくい形」を認めざるを得なくなります．

    致命的に解決策がないわけではないのですが，負音長の休符に対する欲求がある上に
    「零音長や音長の引き算 ~ は認められているのになぜ負音長がないのか」
    という疑問が舞い降りてきて，日増しに相互強化してきています (私の中で)．

    導入を是非ともご検討頂ければと思います．


    (ii) 一時的なフィンガー属性の変更
    このアイデアの元は TeX のグルーピングと変数の変更の仕様からです．
    TeX は (主に文字ベースの) 文書を作成するソフトなのですが，
    この "グルーピングと変数の変更の仕様" は次のような感じです:

    ここは通常サイズの文字．{\large 大きい文字と \small 小さい文字です．} 通常サイズに戻りました．

    上のようにソースファイルに書いてコンパイルすれば，
    想像される通りの文字サイズで上の文章が出力されます．
    つまり，グルーピング { } の中で設定 / 変更された変数は，
    グルーピングの外では元の値に戻ります．

    この TeX のグルーピング { } と類似のものが Muse にもあれば，と思いました．
    メンバー属性やフィンガー属性の一時的な変更は (もちろん良く行われますし)，
    もう一度元の値に戻す必要が出てきます．その「元の値」は何なのかを確認するために
    一度ソースコードをさかのぼる必要が出てきますし，音量の調整などで頻繁に
    変更する場合などは作業が煩雑になってきがちです．
    フィンガーの音量 v の一時的な設定には w が使えますが，
    o, p, q などにはありませんし，このグルーピングの仕様は
    w の機能の拡張になるでしょう．
    (とは言っても w がお役御免になることは決してないと思いますが．)

    例えば次のような構文ではどうでしょうか?
    グルーピングを #{ #} としています．(あまりきれいな記号でないかも・・・)

    @AP26
    #A1x1v100o4
    #A1 c4(c#{o6v60c8#})gg | a(a#{o6v60a8#})gg |
    f(f#{o6v60c8#})ee | d8#{#{(ev70dc)#}v90(d#{v80e8#})4#}c2 |
    #A2@ {Y1_1~32Y0_1~}3 | _4Y1_4~32Y0_4~Y1_2~32Y0_2~ |

    上のコードは次のコードと同義です．

    @AP26
    #A1x1v100o4
    #A1 c4(co6v60c8o4v100)gg | a(ao6v60a8o4v100)gg |
    f(fo6v60c8o4v100)ee | d8(ev70dcv100)(v90dv80e8v100)4c2 |
    #A2@ {Y1_1~32Y0_1~}3 | _4Y1_4~32Y0_4~Y1_2~32Y0_2~ |

    「また #o{ #o} でグルーピングすると，o フィンガー属性については
    グループの中での変更がグループの外でも有効になる」といった拡張も考えられます．

    しかし，この「一時的な変更」はメンバー属性に対しては適用しないほうがよさそうです．
    なぜなら，「元の値に戻す」タイミングが現在のフィンガー位置になるためです．
    例えば次の例では，あたかも A メンバーのフレーズは 2 小節を V50 で
    鳴らしているように見えますが，実際に V の値を元に戻すのは 1 小節目の終わりです．

    *FING"x1"
    @ABV100
    #{
    #A1@ V50c4def | gab<c> |
    #B1@ V50c4def #} | gab<c> |


    (iii) フィンガー属性に "フィンガー色の透明度" の追加
    これは文法の記述がきれいになる / ならないの問題とは全く無縁の要望です．

    私の Muse が好きな最も大きな理由の 1 つが，曲が鍵盤上で踊ることです．これを観ているのが大好きです．

    普段 Muse で曲を作るときは譜面モニタを表示してデバッグをしていますが，
    曲を聴くときは譜面モニタを閉じて鍵盤を観ています．
    (譜面モニタを表示していると，どうしても理解しやすい (≒ つまらない) 譜面の方に視線がいってしまうのと，
    先の盛り上がりが予想できてしまうことが理由です．)
    大きな盛り上がりのある箇所で，一斉に鍵盤が色付いていくのは何回見ても壮観です．

    「フィンガー色の透明度」はこれをもっと楽しめるようにと考えて浮かんだアイデアの 1 つです．

    例えば，伴奏を 70% 程度の不透明度にし，メインメロディを 完全不透明にすれば
    メロディラインをある程度容易に確認できるかも知れませんし (あくまでも想像ですが)，
    多彩なアニメーションの可能性も考えられます．(フェイドイン / アウトするときなど．)
    単なるテキスト表示でも度肝を抜くアニメーションが開発されているのを考えると，
    更なるアニメーションの「可能性」は容易に想像できますが，「限界」は想像できません．


    以上が要望 / 提案です．

    (ii) についてはもっといい記号がないかと考えているのですが・・・．

    蛇足で私的な見解ですが，
    私自身が欲しいと思う度合いは (i) > (ii) > (iii) の順になっています．
    私が想像する限りの実装の難しさは (i) < (ii) < (iii) でしょうか．(あくまでも，「私が想像する限り」ですが．)
親記事 / 関連記事表示
削除チェック/

No.6881/Re[1]: 新文法 / 機能の提案
■投稿者/ 浅川 -(2009/11/16(Mon) 02:49:12)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > (i) 負音長の休符の導入
    > (ii) 一時的なフィンガー属性の変更
    については賛同しかねますが
    > (iii) フィンガー属性に "フィンガー色の透明度" の追加
    はあるといいなと思いました。

    （以下は夢です...zzz。）
    さらに複数色の指定でグラデーションができたりして...
    また一音単位で色指定できたらとか...
記事No.6878 のレス / 関連記事表示
削除チェック/

No.6883/Re[1]: 新文法 / 機能の提案
■投稿者/ 開発者 -(2009/11/17(Tue) 21:56:39)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    σさん、ご無沙汰しております。
    以前は確か、複数のフィンガーに一括して属性指定する
    機能の提案をされましたよね。
    今回も長文の力作書き込み、ありがとうございました。

    >(i) 負音長の休符の導入
    実に興味深くユニークな発想です。
    ４小節ごとに几帳面にMusingするために、きっちりそのエリアにコマンドを納めていきたい
    というお気持ちはよく理解できましたが、そのための方法として「負音長」があるとしたら
    少々、大袈裟過ぎるような気もしました。他のミューザーの方が活用する局面が私には
    イメージしにくいのも事実です。申し訳ありませんが、今ひとつ検討に乗り気になれません。

    >(ii) 一時的なフィンガー属性の変更
    元の値が何なのかわからなくなるためにグルーピングし、改めて望むべき値を書くのであれば、
    グルーピングなどわざわざせずに、単に次に望むべき値をそこに書けばいいのではないでしょうか？
    グルーピング機能をサポートしても、どこからどこまでグルーピングすべきかの判断など、
    やはり多くのミューザーは戸惑うだけのような気がして、今ひとつ検討に乗り気になれません。

    >(iii) フィンガー属性に "フィンガー色の透明度" の追加
    「透明度」というよりも「明度」や「彩度」と言った方が正確かもしれませんね。
    ちなみに、色関係の強化は既に検討リストに記載されています。
    浅川さんの「複数色の指定でグラデーション」までは検討リストに入れていませんが・・・(苦笑)
    「Vやvと連動して、明度が反応する」といったアイディアもあります。
    演奏がフォルテッシモになって盛り上がるとき、鍵盤色が鮮やかになると言う寸法です。(笑)
    ホドナールさんのテキスト文字色も検討リストに既に記載されています。
    これをサポートしたら連鎖的にテキストエリアの背景色も指定できるようにすべきですね。

    ただ私としては、
    あまり色関係に懲りすぎないように気を付けようと思っているのも事実です。
    Museの主人公は、やっぱり「音」ですので。

    また、限られた世界（１６色の鍵盤色とか、一行のテキストエリアとか）で
    如何にイメージを表現していくかというアプローチも、
    それはそれで素晴らしいことだと思うのです。
    以前にも書きましたが「５・７・５と季語で制限された、俳句の世界」
    にも通じるものがあると思っています。

    現在のMuseの色や文字は、程々に適度な制約バランスであるように自負しています。
    MIZさんのテキストアニメーションや、
    楠本さんの譜面モニタ絵画が、その証ではないかと思うのです。

    逆に「３２ビットフルカラーで、フィンガー単位に指定可能」にしたら、
    皆さんのデータは次第に、単に写真を貼り付けるだけ、
    といった傾向になってしまうような気がしますが如何でしょうか？(苦笑)

    ちなみに、話題は外れますが・・・。
    >曲を聴くときは譜面モニタを閉じて鍵盤を観ています．
    >(譜面モニタを表示していると，先の盛り上がりが予想できてしまうことが理由です．)
    σさんのこの感性、親近感を強く覚えました。
    私も鍵盤だけで音楽を鑑賞した方が実際のコンサートで聴く時のイメージに近いと常々思っておりました。
    鍵盤も無しにするとやはり駄目で、一気に無機的なプレーヤーになってしまう・・・。
    演奏者の指使いや息使いが感じられるからでしょうか、鍵盤による視覚レベルが「丁度良い」んですよねぇ〜。
記事No.6878 のレス / 関連記事表示
削除チェック/

No.6884/Re[2]: 新文法 / 機能の提案
■投稿者/ MIZ -(2009/11/17(Tue) 22:53:40)
□U R L/http://n119ogmz.hobby-site.com/

    テキスト部分の話が出ているので、
    ワタシもひとつ“願望”を……（あえて“要望”とは書きません^^;）

    【譜面モニタのテキスト入力位置表示を非表示にできる】ボタンかオプションが
    あると良いなと思います。

    これは本体プレイヤー側の機能ですので、データ制作側では工夫のしようがなく……^^;

    小節線と異なるタイミングでテキスト入力したときなど
    小節線との区別がまぎらわしくなってしまう（細かい入力間隔では小節線が見えなくなってしまう）こともありますし……。
    なにより茶色のタテ線や表示文字が多くなると画面がうるさくなって、
    せっかくの譜面モニタの景観が損なわれてしまってるなぁと思ってしまいます(汗)

    　※たとえば、拙作『帰ってきたヨッパライ』などでは、
    　「おらおらおらおら……」とまるでケンカ売ってるような表示になってたり(^^;;;;;
    　……美しくない(汗)

    なのでモニタのテキスト表示・非表示を好きなときに切り替えられると良いかなと……。
    加藤さまの御心の片隅に置いて頂ければと思います。
記事No.6878 のレス / 関連記事表示
削除チェック/

No.6887/Re[3]: 新文法 / 機能の提案
■投稿者/ 開発者 -(2009/11/18(Wed) 21:25:15)
□U R L/http://n119ogmz.hobby-site.com/

    > 【譜面モニタのテキスト入力位置表示を非表示にできる】ボタンかオプションが
    > あると良いなと思います。
    先程、念力インストールによってMIZさんのMuseをバージョンアップしておきました。
    譜面モニタ上の上部、すなわちテキスト表示エリア部分のマウスクリックで
    願望が満たせるようになったはずです。（マウスカーソル形状が変化する場所です）

    > 　※たとえば、拙作『帰ってきたヨッパライ』などでは、
    > 　「おらおらおらおら……」とまるでケンカ売ってるような表示になってたり(^^;;;;;
    > 　……美しくない(汗)
    >
    あはははっ(笑)
    本当だぁ〜、「おらおらおら」って煽ってますね。
記事No.6878 のレス / 関連記事表示
削除チェック/

No.6890/Re[4]: 新文法 / 機能の提案
■投稿者/ MIZ -(2009/11/19(Thu) 05:52:50)
□U R L/http://n119ogmz.hobby-site.com/

    > 譜面モニタ上の上部、すなわちテキスト表示エリア部分のマウスクリックで
    > 願望が満たせるようになったはずです。（マウスカーソル形状が変化する場所です）

    し、失礼いたしましたっ！(汗)

    ……今まで知らなかった(＠＠;;;
    こんな大事なコト、マニュアル読み飛ばしてしまってたなんて(大恥)
記事No.6878 のレス / 関連記事表示
削除チェック/

No.6891/Re[4]: 新文法 / 機能の提案
■投稿者/ 楠本 -(2009/11/21(Sat) 11:16:24)
□U R L/http://sinfonia.6.ql.bz/

    私もMIZさんに便乗して・・・＾＾；

    譜面モニタや自動譜めくり、また、メンバー情報等々の表示／非表示はコマンドラインの起動のオプション設定によって演奏開始時に自動で表示出来るようになりますが、テキスト情報の表示／非表示は手動です。
    これらをデータ内で設定する事によって各データ毎に表示／非表示出来るようにはならないでしょうか。
    そうすればMIZさんや私のように製作者の願望が反映された状態で演奏を聴いてもらえるのでは・・・
    現状はデータ内にコメントとして「〜を表示してね。とか、非表示にしてね。」と書いているだけで、みんなが全員データを読んでいないと思いますので・・・
記事No.6878 のレス / 関連記事表示
削除チェック/

パスワード/

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

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

- Child Tree -

Muse