> なんか呼ばれたような気がしたのですが……
はいっ！呼びました(笑)
> Muse の readme.txt については、ファイルを分けると全文検索がしづらくなることが
> 懸念されるので、章ごとぐらいが希望です。
> 特に第 3 章と第 4 章についてそう思います。
> 章を跨いでの全文検索は私はあまりしないような気がします。
冷静に考えてみると、少なくともReadme.txtに関しての改善は、
インクルードといった大袈裟な構造を採るのではなく、
単に、各章ごとに分けたテキストファイルでいいような気がします・・・(笑)。
しかも、演奏対象は【第２章】だけですから、他の章はHTML化できますよね。
ただし、章単位の分割では、諸熊さんの言う
「初見で威圧感を感じるような行番号」の件は解決しそうに無いですね(笑)。
------------------------------------------------------
【第１章】 アプリケーション概説 133 行
【第２章】Ｍｕｓｅコーディングの手引き 3,762 行
【第３章】 機能概要 843 行
【第４章】 Ｍｕｓｅ文法リファレンス 1,162 行
開発後記 2,622 行
その他（目次／著作権）など 222 行
------------------------------------------------------
開発後記、でかっ(笑)。
> > ちなみに、ご提案のインクルード構想で仕様を明確にしなければならないと感じた点は、
> > インクルード先のファイルが見つからなかった際の挙動、文法エラーとするか無視するか、でした。
>
> これについては、インクルードの場合、データ作成者が意図したデータの一部が
> なくなることを意味するので、エラーとするのがよいと思います。
> あるいは、インクルード構文で挙動を選択できるとさらによいかもしれません。
正直なところ、Museデータそのものに対するインクルード機構に関しては、私は少々否定的です。
確かに、諸々のメリットが存在することは認めますが、対して影の部分もいっぱいあると感じています。
インクルードと聞いて一番初めにイメージしてしまうのが、DLL Hell です。
１つの曲を聴くのにいくつものファイルをロードしなければならない。
しかも、その１つでも欠けていたら再生できません。
Museデータを作る時も、たぶんテキストエディタをいくつも起動して行ったり来たりすることでしょう。
安易にコピペして、あるフレーズを複数ファイルに書き散らした後、
それらの手直しをしなければならない状態を想像してみて下さい。
Αφροδιτηさんが、Readme.txtの件で「ファイルを分けると全文検索がしづらくなる」
と仰ったのと同じことが、ここでも起こります。
多分、Musingにはgrepコマンドが必須になることでしょう。
インクルードでいろいろなファイルに分散していくと、きっとフォルダで整理したくなるでしょう。
更に、複数の楽曲で共有できるインクルード(つまりライブラリ)の欲求が起こるのは必至です。
ライブラリ化は、この手の機構の最大のメリットの一つですから。
そうなると、サーチパスの管理も必要になってきますし、DLL Hellの二の舞になるでしょう。
多分「音楽を創る」時間よりも、「データを管理」する時間の方が多くなると予想しています。
結局、DLLの構想もそうだと思うのですが、この手の制御機構は
完璧に管理されている理想状態においては「天国」となりますが、
そうでないラフでルーズな管理においては、一転して「地獄」になると思うのです。
そして、我々愛すべき人間は、基本的にラフでルーズです(笑)。
> サウンドフォントについては、コメントスイッチと連動させて、
> 選ばれたサウンドフォントに応じたスイッチが有効になると便利かと思います。
おおっ！ これは見事な発想ですね！！
以前、コメントスイッチの議論をした時、if文を設ける検討まで踏み込んだのですが、
結局、if文の存在意義は“変化するインプット情報”がなければ意味がない、
という見解を述べました。でないとif文は常に同じ判断をするからです。
Αφροδιτηさんの上記発想は、
まさに「再生側パソコンでのサウンドフォントの有無」という
“変化するインプット情報”を活用することになりますね。
素晴らしいです。検討リストに加えておきます。
> それと、サウンドフォント、といいますか、VirtualMIDISynth (VMS)に関連して
> もう一つ提案したいのですが、あびやでも話題に上りましたが、VMS はたまに
> note on/off のどちらかを飛ばすことがあるらしく、持続系の音色で note off が
> 飛ばされると鳴りっ放しになってどうもよろしくありません。
> VMS v.1.4.0 から確認されている現象ですが、未だに改善される気配がないので、
> 可能かどうか分りませんが、Muse の側で note off を重ねて発行して飛ばされる
> 確率を減らすというのはどうでしょうか?
実に斬新な発想に脱帽です！
でも、ノートONと対にならないノートOFFを送信してしまうと、
多重ノートONを形成しているMuseデータで、良からぬ副作用を生じてしまうと思います。
それと、これは実験してみないと断言はできないのですが、
VMSにおける音飛びや鳴りっ放しの現象は、その下のBASS-MIDIドライバが、
MIDIイベントの交通渋滞を処理しきれなくなった時に発生すると推測しています。
とすると、ノートOFFという新しい車を投入することで、
交通渋滞を助長させてしまうかもしれません。
VMSの音飛びや鳴りっ放しに関しては、私も困惑しておりまして、
実は秘めやかに、実験を繰り返しています。
今般、少し期待できるかもしれない改善案に辿り着けました。
次回のMuseバージョンに組み込んでみます。
ぜひ試して頂き、またレポートして頂けると幸いです。
|
