Muse掲示板

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

過去ログ表示

過去ログ4 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1314件 (361-380 を表示) / 全ページ数 / [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.9786/Re[13]: 演奏会場の設定について。
■投稿者/ 楠本 -(2014/12/06(Sat) 14:08:42)
□U R L/http://sinfonia.6.ql.bz/

    > 音源切り替えスイッチの話題に興味津々で読んでおりましたが、皆様のお話のレベルが高すぎてなかなか入り込めず^^;;;
    私にはもっと難しく感じます。^^;
    音源スイッチをされていたElekenさん、MIZさんに基本的なことをお尋ねしたいんですが、
    お二人ともメイン音源は、XG音源ですね。
    XG音源で GSモード用のデータは作れないと思っているのですが、
    GSモード用のデータは何で作られているのでしょうか。
    Microsoft GS Wavetable Synthでしょうか。
    それともそれ以外のGS音源でしょうか。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9787/Re[14]: 演奏会場の設定について。
■投稿者/ くさば -(2014/12/06(Sat) 14:30:49)
□U R L/http://sinfonia.6.ql.bz/

    > XG音源で GSモード用のデータは作れないと思っているのですが、

    XG音源はGSリセットの命令を受信するとTG300Bモードと呼ばれる
    GS互換モードになります。おおよそ、SC-55相当、一部SC-88相当
    のGSマップおよび命令を受け付けるようになります。
    Museでは明示的にGSリセットなどの初期化を抑止しない限りGSモードでの
    動作をしています。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9788/Re[14]: 演奏会場の設定について。
■投稿者/ MIZ -(2014/12/06(Sat) 14:54:23)
□U R L/http://n119ogmz.miraiserver.com/

    > XG音源で GSモード用のデータは作れないと思っているのですが、
    > GSモード用のデータは何で作られているのでしょうか。
    > Microsoft GS Wavetable Synthでしょうか。
    > それともそれ以外のGS音源でしょうか。

    くさばさんがおっしゃっているように、Museを立ち上げれば自動的に XG音源はTG300BモードというGS互換モードになります。

    GS用のエフェクトを入れたい場合などには SC-88Proを使ってデータを作ることもありますが。
    基本的に GS用データは、XGリセットを入れない「プレーンな状態」のままですね^^;
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9789/Re[15]: 演奏会場の設定について。
■投稿者/ 楠本 -(2014/12/06(Sat) 16:58:29)
□U R L/http://sinfonia.6.ql.bz/

    くさばさん、MIZさん、早速ありがとうございます。
    > 基本的に GS用データは、XGリセットを入れない「プレーンな状態」のままですね^^;
    そうですか。判りました。
    私の音源は、MidRadio Playerで、XGリセットを入れるかどうか悩みましたが、
    結局、XGリセットを入れないTG300Bモードで作ることにしました。
    >おおよそ、SC-55相当・・・
    SC-55相当でしたか。^^;

    ElekenさんもTG300BモードをGS用データとしているんでしょうかね。

    今頃気が付いたんですが、私のデータ記述の使用音源をMidRadio Playerとしていましたが、
    XGリセットを記述していないので、(ただし、TG300Bモードです。)を追記しとかないといけないですね。
    いやー失敗でした。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9790/Re[16]: 演奏会場の設定について。
■投稿者/ Eleken -(2014/12/06(Sat) 18:00:51)
□U R L/http://y-lab.org/

    楠本さん
    実は SC-D70 (SC-8820相当品)という音源モジュールも所有しているので、
    GS用データは主にそれを使って調整しています。

    GS音源で XG に特化されたデータを聴くと、音量バランスのみならず、
    XG のドラムス(特に Neutral Kit)が SFX になってしまうなど
    いろいろな問題があります。
    このへんは、リセットやエクスクルーシブを変えただけではダメで、
    音源それぞれについて調整が必要なところです。

    逆に、XG音源で GS データを聴くと、仮にそれが XG を対象に作られたデータであっても、
    音源本来の性能が発揮できないことがあります。
    MU100 以降の XG 音源は、MU50 由来の音色と MU100 で新たに収録された音色の両方を搭載していますが、
    GS互換モードの音色は MU50 由来の古い音色にマップされているためです。

    開発者さん
    「選別コメント」は汎用性がありそうで良いですね。
    後方互換性を保つのは少し難しそうですが…。
    実装されたら嬉しいです。

    あと、音源スイッチについて、
    るうさんの例は目からうろこが飛び出しそうでした。すごい。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9791/Re[17]: 演奏会場の設定について。
■投稿者/ 楠本 -(2014/12/06(Sat) 18:32:01)
□U R L/http://sinfonia.6.ql.bz/

    Elekenさん、ありがとうございます。
    > 実は SC-D70 (SC-8820相当品)という音源モジュールも所有しているので、
    > GS用データは主にそれを使って調整しています。
    そうでしたか。判りました。
    ありがとうございました。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9792/Re[17]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/12/06(Sat) 22:57:40)
□U R L/http://sinfonia.6.ql.bz/

    Elekenさん
    > 「選別コメント」は汎用性がありそうで良いですね。
    > 後方互換性を保つのは少し難しそうですが…。
    > 実装されたら嬉しいです。
    現在、選別コメントの設計を頭の中で進めています。
    何点か明確にすべき点が出てきました。

    @同一のコメント名称を複数個所に記述できるか?
      →可能にしようと思います。
       これで、一発でいろいろな部分をコメント化したり有効化したりできます。

    A選別コメントの階層記述はできるか?
      →これも可能にしようと思います。
       下位ブロックが有効でも、それを含む上位ブロックがコメントになっていたら、全体がコメントです。
       逆に下位ブロックがコメント指定されていて、上位が有効指定の場合は、下位ブロックのみコメントとなります。

    B従来のブロックコメント!と、今回の選別コメントが、入れ子になっている場合の扱いは?
      →ブロックコメント!の中にある選別コメントは、無効になります。
       また、コメント指定された選別コメントの中にある!は、無効になります。

    C従来のブロックコメント!と、今回の選別コメントが、交錯している場合の扱いは?

    <タイプA>

    !
    P10
    *comment{
    V20
    !
    R30
    }
    Q40

    とか、
    <タイプB>

    *comment{
    P10
    !
    V20
    }
    R30
    !
    Q40

    などです。

    <タイプA>では、
    1行目の!を検出した時点から、次の!が来るまで、すべてコメントになるので、
    選別コメントのコメント/有効にかかわらず、R30 } Q40 だけが認識されます。

    <タイプB>では、
    選別コメントがコメント指定されていたら、R30 だけが認識されます。( Q40 は 後半の! でコメントになる )
    選別コメントが有効指定されていたら P10 Q40 だけが認識されます。( 選別コメントは開きっぱなし状態 )

    ・・・う〜ん、なんだか複雑だなぁ〜。
    でもまあ、交錯している場合は概ね文法エラーが発生してしまうだろうから、これでいいかなぁ〜。
    もっとこう、従来のブロックコメントと一体感のある言語仕様はないものだろうか・・・。
    もう少し考えてみますね。

    現時点では、実装に踏み切るには一番大切な判断材料が少々足りない感があります。
    それは「新しい機構を導入し仕様を複雑にするに値するほど、皆さんの使用頻度が高いかどうか」です。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9793/Re[18]: 演奏会場の設定について。
■投稿者/ 楠本 -(2014/12/07(Sun) 01:32:29)
□U R L/http://sinfonia.6.ql.bz/

    > それは「新しい機構を導入し仕様を複雑にするに値するほど、皆さんの使用頻度が高いかどうか」です。
    的外れかもしれませんが、今進めている話は、
    1、全体的には、例えばGS音源とXG音源のスイッチ。
    これは、結局は、本来はGS音源用データとXG音源用データの二つのMuseデータを一つにして選択してもらうことですよね。
    という事は、例えば、ジャズバージョンのデータの選択とか、
    複数のMuseデータを一つに出来るのであれば、アルバムのように出来るとか、
    クラシックの交響楽が作りやすくなるとか。(実際作ったことがないので作りやすくなるのかどうかは不明。)
    選択なので、連続再生が出来ないのであれば交響楽は?

    2、部分的には、どのような利用価値があるのかよく分かりません。^^;
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9794/Re[19]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/12/07(Sun) 12:37:50)
□U R L/http://sinfonia.6.ql.bz/

    > 的外れかもしれませんが、
    楠本さん、数々の利用アイディアを提示して頂き、
    ありがとうございます。
    決して的外れではないと思います。

    私は言語仕様に関しては少々こだわりがありまして、
    (1)応用範囲の広い記述ほど優れている。
      →例えば、連符がトリルとして活用できるとか、和音が発音タイミングの調整に使えるとかです。
    (2)実際に活用されない記述は死んでいる。
      →ソフトウェアは生物の進化と似ており、使われない機能を抱えていてはいけないと思っています。
       例えば、陸上に上がった生物にはエラが存在しないといったイメージです。

    今回の選別コメントは、プログラミングは楽しそうなんですが、
    上記(1)(2)のフィルターを通過できるか否か、自分自身の感性として微妙なんです(苦笑)。
    もしかしたら、この話題を提起してくれたElekenさんが、最初の書込みで
    > それに、これ以上マニュアルが長くなったら困り物です(笑)。
    と発言されたのも、実は無意識に同じ様なセンスや気持ちを持たれていたから
    かもしれませんね。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9795/Re[20]: 演奏会場の設定について。
■投稿者/ Eleken -(2014/12/07(Sun) 14:37:08)
□U R L/http://y-lab.org/

    > もしかしたら、この話題を提起してくれたElekenさんが、最初の書込みで
    >>それに、これ以上マニュアルが長くなったら困り物です(笑)。
    > と発言されたのも、実は無意識に同じ様なセンスや気持ちを持たれていたから
    > かもしれませんね。
    ニッチなのと必要不可欠でないことは自覚していますが、
    しかし個人的にはあれば便利な機構だと思うので、少し微妙な表現をとってしまいました。

    言語仕様の方針まで話が進むとは予想していませんでした。
    ちなみにもし実装されるとすれば、
    「従来のコメントは選別コメントより優先される」
    というルール一つでいいと思います。
    ちょうど、プログラミング言語の、コメントとプリプロセッサの関係です。
    先ほどの例は、出現順に解釈していたので、複雑に感じるのだと思います。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9796/Re[21]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/12/07(Sun) 17:08:18)
□U R L/http://y-lab.org/

    Elekenさん
    > ちなみにもし実装されるとすれば、
    > 「従来のコメントは選別コメントより優先される」
    > というルール一つでいいと思います。

    なるほど、もしかしたら心配していたほど複雑ではないかも!
    有効指定の選別コメントは、コーディング上は存在していないのも同じですから
    多分まったく問題なさそうですね。

    > ちょうど、プログラミング言語の、コメントとプリプロセッサの関係です。
    > 先ほどの例は、出現順に解釈していたので、複雑に感じるのだと思います。
    従来コメントと選別コメントを、同一パスで解析処理しようとしていたので、
    選別コメントがコメント指定された際、その中にある従来コメント(!)が
    開始、あるいは終了の記号として解釈されなくなるかもしれない・・・。
    やはり、素直にもう1つ解析パスを設けて、まずは従来コメントを取り払ってから
    選別コメントの処理に入った方が無難かなぁ〜(ちょっと処理効率が落ちるのがくやしい)笑
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9797/Re[18]: 演奏会場の設定について。
■投稿者/ るう -(2014/12/09(Tue) 09:04:05)
□U R L/http://y-lab.org/

    > もっとこう、従来のブロックコメントと一体感のある言語仕様はないものだろうか・・・。

    *選別コメントの名前!
    P42 ;選別コメントが有効な場合
    !

    こうですか?

    ;と"の入れ子を応用して、最初の!の数で最大9分岐するメタミュージングを試みていたところ気付いたのですが(9分岐自体は失敗)、
    実は""って、*TEXT等のコマンド構文を前に伴わない場合、コメントと同様に無視されるんですね。
    そう考えると、!〜!の前に「*何か」を置く事でコメントが有効なMuse指定となる、というのも一理ある設計では、と思います。
    入れ子は、従来どおりに解釈すれば十分です。
    これでしたら、危惧するほど「仕様が複雑になる」心配もないのではないでしょうか。

    問題はただ一つ、

    *MARK !何か注釈! "表示文字列"

    みたいな事をしているMuseデータが過去に存在するかどうかだけですが、まあ普通はそんな所にブロックコメントを入れる事はない……はず。
    というか、やめましょうよそういうの。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9798/Re[19]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/12/09(Tue) 18:59:31)
□U R L/http://y-lab.org/

    > > もっとこう、従来のブロックコメントと一体感のある言語仕様はないものだろうか・・・。
    >
    > *選別コメントの名前!
    > P42 ;選別コメントが有効な場合
    > !
    >
    > こうですか?
    言語仕様で相談に乗っていただけるミューザーがいて心強い限りです。
    るうさん、ありがとうございます。

    > 実は""って、*TEXT等のコマンド構文を前に伴わない場合、コメントと同様に無視されるんですね。
    いいえ。単独の""にはとても大切な機能が割り当てられています。
    それは、LilyPond(楽譜出力)のスルーコマンドです。

    > そう考えると、!〜!の前に「*何か」を置く事でコメントが有効なMuse指定となる、というのも一理ある設計では、と思います。
    > 入れ子は、従来どおりに解釈すれば十分です。
    > これでしたら、危惧するほど「仕様が複雑になる」心配もないのではないでしょうか。
    現時点の私の記法案は、
    従来コメントのエリア指定文字が ! !
    選別コメントのエリア指定文字が { }

    というものでしたが、るうさんのアイディアは、
    従来コメントのエリア指定文字が ! !
    選別コメントのエリア指定文字も ! !

    共に同一のエリア指定文字にしてしまうことで、
    従来のブロックコメントと一体感のある仕様にしてしまおうという案ですね。
    同一の文字なので、入れ子が交錯するという事態そのものが、言語仕様で解消しちゃいそうです。
    これは、実に良案だと思います!

    従来のブロックコメントに、名前(*name)を付与することで、
    選別機能が利用できるようになる、という無理のない拡張感も心地よいです。

    この案で一番戸惑うケースは、以下の様な記述かな。

    @ !
    P10
    A *name !
    V20
    B !
    R30
    C !

    と書かれていたとき、@とAの ! がペアと解釈され、
    *nameはそのエリア内のただのコメント文字になります。
    そしてBとCが対になりますね。
    つまり、閉じ側の ! に名称 *name を付けても意味がない訳です。
    ブロックコメントの指定文字が開き側も閉じ側も同一の ! であるため、
    局所的な判断ができず、これはMuseのブロックコメントの判りにくい点の1つですね(苦笑)

    まあ、入れ子にしたいのであれば、以下の様にすればいいんだから許容できるかな。

    @ !
    P10
    A *name !!
    V20
    B !!
    R30
    C !

    となると
    従前の指定文字 { } の案だと、入れ子の階層は無尽蔵でしたが、
    今回の新案だと、!!!!!!!! の8階層までとなりますね。

    *name1 !
    ・・・

    *name2 !!
    ・・・

    *name3 !!!
    ・・・
    !!!

    ・・・
    !!

    ・・・
    !

    でも、8階層あれば実用上問題ないですよねぇ〜。

    > 問題はただ一つ、
    >
    > *MARK !何か注釈! "表示文字列"
    >
    > みたいな事をしているMuseデータが過去に存在するかどうかだけですが、まあ普通はそんな所にブロックコメントを入れる事はない……はず。
    選別コメント機構がMuseに実装されたら、この場合のMARKはコマンドIDではなく、選別コマンドの名称と解釈することになりますね。
    そして、続く"表示文字列"はスルーコマンドとして解釈される。
    今までと全く異なる解釈となるので上位互換はもろに崩れます。でも、

    > というか、やめましょうよそういうの。
    あはははっ(笑) そうですね。
    これはさすがに、上位互換が保てない例として許される気がします。

    もう1つの懸念事項は、
    選別コメントの名前はミューザーが自由に与えることができるので、
    今後、新しいコマンド *XXXX" ... " を立ち上げようとした際、
    名称の競合でデータ上位互換が崩れてしまうという事態への恐れです。

    先刻の案で選別コメントのエリア指定文字を { } にしておいたのは、実はこの辺の配慮なのですが、
    もしかしたら、! ! でも大丈夫かもしれない・・・。
    検討してみます。

    他にも懸念事項やトリッキーな例外など気づきましたら、
    ご記帳頂けると幸いです。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9799/Re[20]: 演奏会場の設定について。
■投稿者/ るう -(2014/12/10(Wed) 01:21:34)
□U R L/http://y-lab.org/

    >>実は""って、*TEXT等のコマンド構文を前に伴わない場合、コメントと同様に無視されるんですね。
    > いいえ。単独の""にはとても大切な機能が割り当てられています。
    > それは、LilyPond(楽譜出力)のスルーコマンドです。
    この私としたことが……楽譜出力は全く使っていない機能だったので、完全に存在を失念しておりました……。
    ま、まあ、"〜" の前に *XXXX をつける事で意味が変わる、という点では同じなのでご容赦を。

    > 従前の指定文字 { } の案だと、入れ子の階層は無尽蔵でしたが、
    > 今回の新案だと、!!!!!!!! の8階層までとなりますね。
    8ですと、微妙に足りなくなりそうな感が全くないわけではない感じですね。まず十分でしょうが。
    場合によっては、折角なので!×32まで許可するように制限を緩める、みたいな方法もあるかもしれません。
    まあ、明らかに開発の手間に対して実入りは少ないので、誰かが要望を出したら、でよいかと……。

    > もう1つの懸念事項は、
    > 選別コメントの名前はミューザーが自由に与えることができるので、
    > 今後、新しいコマンド *XXXX" ... " を立ち上げようとした際、
    > 名称の競合でデータ上位互換が崩れてしまうという事態への恐れです。
    それは大丈夫です。
    というのも、新たな *XXXX"〜" が実装された際、選別コメントは *XXXX!〜! であって、*XXXX"〜" ではないからです。
    ただし、
    > *MARK !何か注釈! "表示文字列"
    の後方互換性を保つため、
    『*XXXX!〜! の XXXX がコマンド命令であった場合に限り、その後の!〜!は通常のコメントであるものとする』
    という仕様にした場合には問題が発生しますが……。

    むしろ問題は、前方互換性にあるかもしれません。
    *MARK !何か注釈! "表示文字列" ← これはまずないケースですが、
    *選別 !〜! "スルーコマンド" ← こちらはそこそこ頻繁に発生しそうなケースなので、
    もしも選別コメントの名前を TEXT や MARK にしてあるファイルがある場合、
    古いMuseでは最悪、エラーにならずに想定外の音が鳴ってしまう、という事もありえます。
    かといって、コマンド名は選別コメント名にできない、などとすると後方互換性の問題に戻ってしまいます。
    もっとも、ReadMe.txtに「コマンド名を選別コメント名にする事は避けるべき」と一言書いておけば十分だとは思いますが。

    余談ですがこの事に関連して、あえてコマンド名を選別コメント名にすることで、

    *STOP !
    選別コメント対応版Muse用コード
    ! "警告:古いMuseを使っています"

    などというメタミュージングも考えたり(未対応版では *STOP"警告〜" と同じ)。

    あっ! そういえば、

    !
    d
    *選別!!
    r
    !
    m
    !!

    こんなケースですと、選別コメントは !〜! 内だから無視、としていいものかどうか悩ましいですね。
    互換性的な観点からだと無視したいところですが、選別コメントのコンセプト的には無視したくない。
    あと、パーサーを開発する時にはたぶん無視したい?
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9800/Re[21]: 演奏会場の設定について。
■投稿者/ るう -(2014/12/10(Wed) 01:39:20)
□U R L/http://y-lab.org/

    ……っと、自己レス恐縮ですが、

    !
    d
    *選別!!
    r
    !
    m
    !!

    これで選別コメント名([9799]では『名』が抜けましたね)を無視しない仕様にしてしまうと、


    !
    d
    *選別!
    r
    !
    m
    !

    の場合も選別コメントを有効にしなければならなくなって、結果として r の部分では、
    「!」と「*選別!」が二重に開くという極めてわけのわからない話になってしまいます。
    もちろんこの場合、「コメントを閉じる!の方が優先される」という仕様でいいのですが、それはそれで整合性がないという見方も。
    やはり、コメント内の選別コメント名は常に無視、の方が単純……?
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9801/Re[22]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/12/11(Thu) 00:07:12)
□U R L/http://y-lab.org/

    > 『*XXXX!〜! の XXXX がコマンド命令であった場合に限り、その後の!〜!は通常のコメントであるものとする』
    という特別な処置は取らずに、「将来に向けての」上位互換を確保しようと思います。
    代償としては、現時点でこの例の様なトリッキーな記述をしているデータは、上位互換が失われることですが、
    これは許してもらおうと思っています。

    > むしろ問題は、前方互換性にあるかもしれません。
    > *MARK !何か注釈! "表示文字列" ← これはまずないケースですが、
    > *選別 !〜! "スルーコマンド" ← こちらはそこそこ頻繁に発生しそうなケースなので、
    > もしも選別コメントの名前を TEXT や MARK にしてあるファイルがある場合、
    > 古いMuseでは最悪、エラーにならずに想定外の音が鳴ってしまう、という事もありえます。
    以前より、下位互換は諦めるというポリシーで開発していました。
    私にとって大切なのは皆さんのミューズデータであり、それを正しく演奏できる「最新版のミューズ」です。
    とにかく、最新のミューズにしてもらえれば正しく聴ける、という状況が作れれば充分許してもらえると思っています。
    「古いMuseでは最悪・・・」という事態を無視することは、今までも何度も実施してきました。
    そのための対処は「最新のMuseを導入してください」となります。

    > かといって、コマンド名は選別コメント名にできない、などとすると後方互換性の問題に戻ってしまいます。
    > もっとも、ReadMe.txtに「コマンド名を選別コメント名にする事は避けるべき」と一言書いておけば十分だとは思いますが。
    ・・・これは正確に言うと
    「将来コマンド名になりそうな名称も含めて選別コメント名にするな」
    と言っていますか?
    それはミューザーにとって、ちょっち酷な話ではないかと・・・(苦笑)

    > あっ! そういえば、
    >
    > !
    > d
    > *選別!!
    > r
    > !
    > m
    > !!
    >
    > こんなケースですと、選別コメントは !〜! 内だから無視、としていいものかどうか悩ましいですね。
    > 互換性的な観点からだと無視したいところですが、選別コメントのコンセプト的には無視したくない。
    > あと、パーサーを開発する時にはたぶん無視したい?
    いえ、多分逆だと思います。
    まだ実装レベルの設計をしていないので確約はできないのですが、
    選別コメントがコメント指定であった場合は、

    !
    d
    !!
    r
    !
    m
    !!

    と同じ解釈をさせることになると思います。
    そして、選別コメントが有効指定であった場合は、

    !
    d

    r
    !
    m

    と同じ解釈をさせることになると思います。
    今回の機構を実装するにあたり、プログラミングで一番気を使う箇所は、まさにこの場合で、
    閉じ側の!!を取り払う処理だろうと予見しています。

    > !
    > d
    > *選別!
    > r
    > !
    > m
    > !
    >
    > の場合も選別コメントを有効にしなければならなくなって、結果として r の部分では、
    > 「!」と「*選別!」が二重に開くという極めてわけのわからない話になってしまいます。
    > もちろんこの場合、「コメントを閉じる!の方が優先される」という仕様でいいのですが、それはそれで整合性がないという見方も。
    > やはり、コメント内の選別コメント名は常に無視、の方が単純……?
    こういう仕様はどうでしょう?
    選別コメントが
    ・有効化指定の場合は、開き側と閉じ側の両方の ! が無いも同然、無色透明となる。
    ・コメント化指定の場合は、*選別 の部分が存在しない通常記述と同様となる。

    つまり前回の例示[9798]と異なり、

    <有効化指定の場合>
    !
    d

    r

    m
    !

    <コメント化指定の場合>
    !
    d
    !
    r
    !
    m
    !

    そしてこの仕様にすれば、もしかしたら無限階層も可能になるかも。
    コメント化指定の場合、選別コメントで指定した開き括弧と閉じ括弧が、
    結果として逆に作用することもあり得る、というのがミソです。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9802/Re[23]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/12/11(Thu) 18:18:33)
□U R L/http://y-lab.org/

    現在、頭の中で設計が佳境です(笑)

    > つまり前回の例示[9798]と異なり、
    現時点のご報告。
    やっぱし、[9798]復活の模様。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9768/Re[7]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/11/27(Thu) 00:25:01)
□U R L/http://y-lab.org/

    > ・・・ *DATA"XG"なんて立ち上げなくても、
    > 誰かがXG初期化用のマクロを作ってくれればいいだけか(笑)
    こんな優れたツールがあったことを思い出しました。
    http://n119ogmz.miraiserver.com/sys_ex.php

    これが、リバーブ&コーラス構築・ピッチベンドレンジなど、
    諸々の再設定も自動生成してくれると完璧なんだけどなぁ〜。
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9769/Re[8]: 演奏会場の設定について。
■投稿者/ MIZ -(2014/11/27(Thu) 07:18:45)
□U R L/http://n119ogmz.miraiserver.com/

    > これが、リバーブ&コーラス構築・ピッチベンドレンジなど、
    > 諸々の再設定も自動生成してくれると完璧なんだけどなぁ〜。

    ……すみません。
    VBA もうすっかり忘れてしまいました……。 ;;(・_・);;
記事No.9760 のレス / 関連記事表示
削除チェック/

No.9770/Re[9]: 演奏会場の設定について。
■投稿者/ 開発者 -(2014/11/27(Thu) 19:05:43)
□U R L/http://n119ogmz.miraiserver.com/

    > VBA もうすっかり忘れてしまいました……。 ;;(・_・);;
    VBAの文法は忘れても、Muse文法は覚えてくれていることが、
    なんだか嬉しいっす。
記事No.9760 のレス / 関連記事表示
削除チェック/


パスワード/

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