Muse掲示板

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

過去ログ表示

過去ログ4 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1314件 (641-660 を表示) / 全ページ数 / [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.10077/Re[1]: WAVE コマンドを使う MUS ファイルの SMF への変換
■投稿者/ 開発者 -(2015/09/04(Fri) 20:45:47)

    > 大変ご無沙汰しています。Kobarin です。
    > もう覚えていらっしゃらないかもしれませんが KbMedia Player の作者です。
    覚えていますとも!
    かの有名なKbMedia Playerの開発者を忘れるわけがありません。
    その節は、Muse起動オプション文字の変更への対応、ありがとうございました。

    > Muse 7.04 で WAVE コマンドを使う MUS (例えば sample02.mus) をコマンド
    > ラインで SMF に変換しても反映されていないような気がします。
    はい。ご明察の通りです。
    今回のV7.0xから、WAVEおよびFONTの文字列出力を廃止いたしました。
    何か積極的な理由が見つかった場合は、柔軟に復活させますが、
    現時点では、廃止状態を維持しようと考えています。

    Readme.txtに明示的にそのことを書いておいた方が良いですね。
    次回バージョンで注釈を添えたいと思います。
    改善のヒント、ありがとうございました。

    > あといつの間にか UNICODE に対応していたのですね。
    > 曲名表示が文字化けしてしまうので対応しておかなくては。
    はい。
    V6.6にて対応を開始しました。(2013.11.10)
    お手数をお掛けしますが、よろしくお願い致します。
記事No.10075 のレス / 関連記事表示
削除チェック/

No.10078/Re[2]: WAVE コマンドを使う MUS ファイルの SMF への変換
■投稿者/ Kobarin -(2015/09/05(Sat) 00:08:29)

    早速の回答ありがとうございます。

    WAVE コマンドを使用したデータは Muse 以外のソフトでは再生出来ない
    ということになってしまいますよね。ちょっともったいないかな、という
    気もします。

    廃止状態を継続されるということであればそれはそれで諦めますが、
    もしまた復活されたなら、仕様変更があれば(簡単に対応出来るなら)
    追随しますし、仕様変更なしでの復活なら API の PlaySound で再生
    出来る形式であればそのまま対応出来ます。

    Muse.exe と同じように再生出来るのかどうかは分かりませんけど。
記事No.10075 のレス / 関連記事表示
削除チェック/

No.10079/Re[3]: WAVE コマンドを使う MUS ファイルの SMF への変換
■投稿者/ 開発者 -(2015/09/05(Sat) 11:45:20)

    > WAVE コマンドを使用したデータは Muse 以外のソフトでは再生出来ない
    > ということになってしまいますよね。ちょっともったいないかな、という
    > 気もします。
    ありがとうございます。
    先ほどのKobarinさんの書き込みで、もしやとは思っていたのですが、
    KbMedia Playerは、PlaySoundによるWAVEコマンドに対応していたのですね!

    DAWという用語が一般的になる前から提供していたWAVEコマンドは、
    実は私の自慢なんですが、レイテンシーを考慮しない粗末な作りなためか
    Muse界ではあまり普及しませんでした。(苦笑)

    なので、こうして着目してくれる方がいることがとっても嬉しいです\(^o^)/
    という訳で、復活させることにしました!
    ちょうど近々V7.05をリリース予定なので、そこでサポートを再開します。
    もちろん以前と同じ仕様です。
    リリース前にKbMedia Playerでの動作を確認しておきますね。
記事No.10075 のレス / 関連記事表示
削除チェック/

No.10080/Re[4]: WAVE コマンドを使う MUS ファイルの SMF への変換
■投稿者/ Kobarin -(2015/09/05(Sat) 16:09:37)

    なんか催促したみたいですみません。(^^;

    今のところ MIDI 音源を使用して再生時だけの対応です。
    kbfmmidi.kpi とか kbtim.kpi のような PCM 波形を取るようなタイプで再生時は
    WAVE コマンドは無視します。本当はこういうタイプこそレイテンシに依存しない
    完璧なタイミングで再生出来るのですが、WAVE コマンドを活用したデータはまだ
    少ないようなので対応は見合わせています。

    > レイテンシーを考慮しない粗末な作りなためか
    > Muse界ではあまり普及しませんでした。(苦笑)

    KbMedia Player の場合、PlaySound をディスク上のファイルからの読み込み指定で
    再生するだけで、発音の必要が生じるまで前もって準備をしておくわけでもないので、
    データの置き場所がハードディスクか SSD か CD ドライブなのかによっても発音タイ
    ミングが変わります。おそらく Muse.exe でも同じか、遅延を減らすためにせいぜい
    メモリバッファに入れて準備しておく程度なのでは、と思います。

    他にも MIDI 音源のレイテンシと、PlaySound やそのとき使われる WAVE デバイスの
    レイテンシがどうしても動作環境に依存するので、制作者が意図した通りの再生を
    制作者とは別の環境で再現するのは正直難しいと思います。

    なので、発音のタイミングがシビアでないような使い方をした方が無難でしょうね。
    WAVE コマンドを活用しまくった、ものすごく気合が入ったデータほど、別の動作環境
    で再生すると悲しい結果になるかもしれません。
記事No.10075 のレス / 関連記事表示
削除チェック/

No.10081/マイナスの音長に対するエラーメッセージ
■投稿者/ Αφροδιτη -(2015/09/05(Sat) 22:46:37)

    最近、いささか不便を感じることに遭遇しました。

    1: [d]
    2: ,8~4

    (左は行番号)のようなファイルを Muse に渡すと

    「音長がマイナスの値になりました」

    というメッセージとともに、行番号 1 が表示されると思います。

    打楽器パートなどで , のみが複数行に渡って連続しているような場合、
    実際に誤っている箇所の行番号が表示されないため、探すのに苦労します。

    また、

    d8~4^2

    (個々の値は適当です)の場合、音長全体としてはプラスであるのに、
    8~4 を計算した時点で上のエラーが表示されてしまいます。

    d8^2~4

    と書けばよいのですが、表現上そう書きたくない場合もあり、
    いつもおねだりばかりで恐縮ですが、いかがでしょうか?
親記事 / 関連記事表示
削除チェック/

No.10082/Re[1]: マイナスの音長に対するエラーメッセージ
■投稿者/ 開発者 -(2015/09/06(Sun) 01:12:44)

    > 最近、いささか不便を感じることに遭遇しました。
    >
    > 1: [d]
    > 2: ,8~4
    >
    > (左は行番号)のようなファイルを Muse に渡すと
    >
    > 「音長がマイナスの値になりました」
    >
    > というメッセージとともに、行番号 1 が表示されると思います。
    >
    > 打楽器パートなどで , のみが複数行に渡って連続しているような場合、
    > 実際に誤っている箇所の行番号が表示されないため、探すのに苦労します。
    Αφροδιτηさん、貴重なご意見ありがとうございます。
    上記の件、私も共感いたします。連符の再現表記()の場合も同様ですね。
    早速、手を入れました。次回(V7.05)で提供できると思います。

    マクロの場合は、展開先ではなく展開元を指示した方が親切なので、
    そのようにしていますが、再現表記の場合は逆でした。
    あまり深く考えずに、マクロの場合の処理を水平展開していました。
    現仕様では、折角のエラーメッセージが台無しですね(苦笑)。

    いつもΑφροδιτηさんのご指摘はMuseを進化させますね!
    MuseにはΑφροδιτηさんのDNAがたっぷり入ってます。
    そして、心から感謝しております。

    > また、
    >
    > d8~4^2
    >
    > (個々の値は適当です)の場合、音長全体としてはプラスであるのに、
    > 8~4 を計算した時点で上のエラーが表示されてしまいます。
    こちらの方なのですが、これは当方では再現しませんでした。
    バージョンが違うかとも思ったのですが、
    かなり過去バージョンに遡ってもエラーになりませんでした。
    もう一度、ご確認いただけますか?
記事No.10081 のレス / 関連記事表示
削除チェック/

No.10083/Re[2]: マイナスの音長に対するエラーメッセージ
■投稿者/ Αφροδιτη -(2015/09/06(Sun) 08:41:48)

    >>1: [d]
    >>2: ,8~4
    >>(左は行番号)のようなファイルを Muse に渡すと
    >>「音長がマイナスの値になりました」
    >>というメッセージとともに、行番号 1 が表示されると思います。
    > 上記の件、私も共感いたします。連符の再現表記()の場合も同様ですね。
    > 早速、手を入れました。次回(V7.05)で提供できると思います。

    ありがとうございます。
    とても助かります。

    >>d8~4^2
    >>(個々の値は適当です)の場合、音長全体としてはプラスであるのに、
    >>8~4 を計算した時点で上のエラーが表示されてしまいます。
    > こちらの方なのですが、これは当方では再現しませんでした。
    > バージョンが違うかとも思ったのですが、
    > かなり過去バージョンに遡ってもエラーになりませんでした。
    > もう一度、ご確認いただけますか?

    この例では再現しませんね。
    余計な手間を取らせてしまい申し訳ありませんでした。

    目下、再現するケースを見失っております。
    また遭遇しましたら改めてお願いいたします。
記事No.10081 のレス / 関連記事表示
削除チェック/

No.10084/Re[3]: マイナスの音長に対するエラーメッセージ
■投稿者/ るう -(2015/09/07(Mon) 19:23:41)

    > >>d8~4^2
    > >>(個々の値は適当です)の場合、音長全体としてはプラスであるのに、
    > >>8~4 を計算した時点で上のエラーが表示されてしまいます。

    たぶん関係ないとは思うのですが、

    d4 {d~8}^3

    とすると

    d4 d~8 d~8 d~8

    d4 d8 d0 d0~8

    と展開されてマイナス音調エラーが発生しますね。
    (正しいような正しくないような不思議な感覚……)
記事No.10081 のレス / 関連記事表示
削除チェック/

No.10085/Re[4]: マイナスの音長に対するエラーメッセージ
■投稿者/ 開発者 -(2015/09/08(Tue) 00:14:45)

    えーと、まず

    > d4 {d~8}^3

    は、

    d4 {d~8}3

    の誤植ですよね?

    > d4 d~8 d~8 d~8
    > =
    > d4 d8 d0 d0~8
    >
    > と展開されてマイナス音調エラーが発生しますね。
    > (正しいような正しくないような不思議な感覚……)

    これは設計通りの動き、つまり仕様となります。
    この仕様のお陰で、Readme.txtの(1-24)で例示した演奏が可能になります。

    v127 [(dms<d>)1]8 {v-10,}12 _1. _2.
記事No.10081 のレス / 関連記事表示
削除チェック/

No.9977/museの読譜についてアドバイスを下さい
■投稿者/ muse初心者 -(2015/07/01(Wed) 21:39:48)

    museの読譜についてアドバイスを下さい

    museエキスパートの方に質問です。

    どういった練習をどのくらいの期間続けたらmuseファイルが譜面のように読めるようになりましたか?

    私はReadme.txtを読んでmuse文法を解読できるようにはなったんですが、全く楽譜としてイメージできていません。おたまじゃくしを見ながらピアノを弾いていた時は、視覚的な画像情報から手の感覚や指の距離感で処理していたらしく、(例えば)ラの音を意識して弾いてはいなかったようです。(薬指を軽く伸ばせば届くのでそれを弾く…感覚です。)
    そのためか、museファイルのアルファベットの記号群を読んでも音程がイメージできず困っています。

    譜面は練習を重ねて弾けるようになったので、museファイルも同じかな?と思っていますが、みなさんはどういう練習をして自分のものにしましたか?また読譜の練習となるオススメのmuseファイルはありますか?

    宜しくお願いします。
親記事 / 関連記事表示
削除チェック/

No.9978/Re[1]: museの読譜についてアドバイスを下さい
■投稿者/ sana -(2015/07/02(Thu) 17:47:46)

    museエキスパートでもなんでもありませんが、muse歴は10年くらいです(自分で調べてみてびっくり(^_^;))。

    > どういった練習をどのくらいの期間続けたらmuseファイルが譜面のように読めるようになりましたか?

    そもそも、譜面のように読もうと思ったことがないです。
    自分で打ち込んだものであっても、それを見ながらピアノを弾いたりはできないと思います(^_^;)
    museファイルと譜面は別物という感覚です。

    > そのためか、museファイルのアルファベットの記号群を読んでも音程がイメージできず困っています。

    譜面は、ぱっと見て音の高低がわかりますが、museファイルだと<や>の数を数えないとわからなかったり、人によっても書き方が様々なので、譜面のように読むというのはかなり難しいかと…。

    museファイルを譜面化する機能がありますが、それではダメなのでしょうか?

    (余談ですが、私は逆にmuseを始めてから忘れていた楽譜の読み方を思い出しました。)
記事No.9977 のレス / 関連記事表示
削除チェック/

No.9979/Re[2]: museの読譜についてアドバイスを下さい
■投稿者/ muse初心者 -(2015/07/02(Thu) 23:36:02)

    回答有難う御座いますm(_ _)m

    私は文字を綺麗に書くことが苦手なのですが、それでいて作曲や編曲が好きで趣味で続けています。

    最近になって、書きなぐり(メモ程度)の五線譜の山に気づき、ダンボールに入った紙をいつか整理したいと思いはじめました。とはいえ、鉛筆を持つことが苦手な私なのでじっくり机に座って清書することは不可能です。

    そこでパソコンで譜面入力を試みたのですが、一音一音マウスを置く作業に苛立ち、これも挫折しました。(どうも細かい根気の要る作業が苦手なようです。。)

    話は変わりますが、数ヶ月前にJAVA言語というのを知りまして、書籍を読んでいるうちに、オブジェクト指向に感銘を受けました。このmuseファイルをソースコードと呼んでいいのか分りませんが、museのマクロは私にとって「目からうろこ」でした。最小の手数で最大の効果を生みそうだと。

    鍵盤も必要なく、ノートパソコン一台あればいい、これも私にとって画期的でした。仕様も素晴らしいし、機材も必要ない、あとはソースコードの可読性かな?と思っています。

    プログラムでいえば、美しいソースコードはバグが少なくデバッグがしやすいはずで、さらにLoadせずとも(テキストのままで)イメージが頭の中に浮かぶのでは?と思っています。それが出来ていないのは私の熟練度が足りないから。(もしかするとその考え方自体が間違っているかもしれませんが。。)

    楽譜PDF出力は試していません。別途インストールが必要なことと、出力したmidiをパソコンの譜面ソフトで編集しようと思っているからです。

    最後にですが、ソースの可読性でいえばカッコを規則的に配置してから入力を始めれば良くなるのかな?と思っていますが、先輩方のファイルをみるとそうしている人は少ないです。やっぱり素人考えなのか…とモヤモヤしています。

    (_)4 (_)4(_)4(_)4|(_)4 (_)4(_)4(_)4

    すみません、質問する側がまだ質問の整理できていないようです。将来Google Driveのようなcloudにファイルを入れていつでもどこでも執筆し、必要に応じてmuseを起動して確かめたいのです、そのためにはソース上でイメージできるよう練習しないといけないと思っています。
記事No.9977 のレス / 関連記事表示
削除チェック/

No.9980/Re[3]: museの読譜についてアドバイスを下さい
■投稿者/ 開発者 -(2015/07/03(Fri) 18:00:29)

    「museの読譜」という興味深い話題のご提供、ありがとうございます。

    ご相談の答えにまったくなっていないし、
    少々話題が逸れてしまうかもしれませんが、
    ご容赦下さい。

    > プログラムでいえば、美しいソースコードはバグが少なくデバッグがしやすいはずで、さらにLoadせずとも(テキストのままで)イメージが頭の中に浮かぶのでは?と思っています。それが出来ていないのは私の熟練度が足りないから。(もしかするとその考え方自体が間違っているかもしれませんが。。)
    あながち間違ってはいないと思います。
    確かに、醜いコードは内容が把握しにくいと、経験上ほぼ断定できます。
    しかし、美しいコードなら必ず内容が把握しやすいかというと、
    それは残念ながら、断定できないと思います。
    世の中にはとても美しいバグもあり、治すと汚くなる場合もあります(苦笑)。
    (扱う対象自体に例外があったり、非対称部分があったりするからですが・・・)

    文字列による表現は、一望のもとに内容を把握するという点に限界があって、
    読み手に対し、部分々々の内容を自身の頭の中で再構築することを強要します。

    プログラム言語はその限界を補うために、UMLといった図表によるプログラム仕様の表現形式が存在します。
    さしずめ、プログラム言語がMuseコードで、UMLが楽譜といったところでしょうか。

    プログラム言語(Museコード)と、UML(楽譜)との大きな違いは、
    前者が、プログラム実行(演奏)に耐えうる情報量を「緻密に」持つのに対し、
    後者は、仕様上のポイント(発想記号)や、全体の関係(楽曲構成)を「ざっくりと」表現している点です。

    この両者の情報特性は互いに補い合うものであり、一方だけで完結しないと感じています。
    逆説的かもしれませんが、「緻密」であればあるほど内容を把握しにくくなることがあり、
    まずは「ざっくり」と説明を受けた方が瞬時に理解できる場合が多々あります。

    楽譜を見ながらリアルタイムに演奏できるのは、楽譜が「グラフ表現」であることも大きいですが、
    情報量が「ざっくり」している点も見逃せないと考えています。
    単純に情報量だけで「前者は後者を包含する」と言い切れないのではないかと、
    Muse開発時、LilyPond対応に苦闘しながら身をもって感じた次第です。

    そして、
    「緻密な」多くの情報から、どこに着目して「ざっくり」とした疎の情報にするか、
    その「枝刈り行為」自体に、付加価値の高い情報が存在しているような気がします。
    だとするとその情報(価値)は、前者ではなく後者にのみ存在していることになります。
    よって、包含関係が成り立たない・・・。

    もちろん、
    他者の演奏を聴くだけ(ソフトを利用するだけ)ならば、前者のみあればいい。
    でも、作曲したり演奏したりする者(クリエーター)にとっては、むしろ後者の方が重要であり、
    前者の創出は他者に委ねても良い類なのかもしれません。

    なんにせよ、とても面白い思索のテーマだと思います。
    ご相談の答えになっておらず、申し訳ありません。m__m
記事No.9977 のレス / 関連記事表示
削除チェック/

No.10069/Re[4]: museの読譜についてアドバイスを下さい
■投稿者/ Josef -(2015/08/30(Sun) 00:56:52)

    こんにちは、Josefと申します。
    非常に興味深い話題と開発者様のメッセージに、
    つい掘り起こしてしまいました。

    答えになっていないとおっしゃいますが、
    開発者様の考察(思索)もとても興味深いと思いました。

    私もsanaさんと同じで、通常は譜面のように読もうと思ってはいないです。
    一方、いったん入力を終えたものをデバッグしたり後から追加したり修正したり、
    そういったときに、自分の書いたMUSEのコードを「読譜」する必要が
    確かにあります。

    そういったときに私にとって有効だったのは、
    テキストエディターの機能で勝手に色分け強調表示してくれる、
    いわゆるシンタックスハイライトでした。
    正規表現も含め特定の文字列の並びに対するシンタックスハイライトを
    カスタマイズできるエディターを使って、MUSEの文法(のうち自分が使う主要なもの)
    を見やすくして、それで後から読んでもある程度わかるようになっていきました。

    ただ、読めると言っても、楽譜のように音楽が浮かんでくるような
    読み方ではなくて、音への再現はMUSEにやってもらいながら、
    その音の元となっているコードの場所を探り当てて、
    ここをこう変えればこうなるはずだ、という一連の作業が
    だんだんスムーズにできるようになっていった、ということです。

    また何か続く話題がありましたらコメントをお願いいたします。
    それでは失礼いたします。

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

No.10070/Re[5]: museの読譜についてアドバイスを下さい
■投稿者/ sana -(2015/08/30(Sun) 11:30:48)

    私もあれからいろいろと考えてはみたのですが、考えがまとまらず、タイミングを逃してしまっていました。
    muse初心者さんがまだ見てくださってるとよいのですが…。

    私の場合で考えてみました。、
    最終目標は「Museに演奏してもらうこと」なので、いろんな指示(強弱やテンポ変化など)を
    音の合間に埋め込んで書いていることが「読譜」のしにくさになっていると思います。
    ですので、「読譜」を目的とするならば、そういった指示を省いた上で楽譜の見た目に近づけて書いてみると、
    かなり見やすくなるのではと思いました。

    (例)ノクターン2番冒頭 
    <修正前>
    \---%66
    #A1 o4v55c8& | c32v60<s2~32v55f8v50sv60f4.v50m4/.v60>c8 |
    v65<s4v68d32&v60(dw+5r-d>c=<d)16.v70<d4v60>s8v65c4.v55l4/.v60s8
    #C1 o3_8 | {v45v40:4_[s<m][>c<ms]>}v45v40:4_[l<r][d-rl]>{}2 |
    v50v40:4_[s<m=][>c<m=s]v55v40:4_[>s<m=][dm=c]
    {v45v40:4}_[>f<r-][>c<r-m=]{}_[>f<d][>l<df]
    #C2 o2%45:8_8 | v55m8/%66:8__v50<m_%60:8_%66:4v55>m_%55:8_%60:8v60r_%50:8_ |
    %60:8v65d%55:8__v60<d%66:4__%60v55>f%66:8__v50f%50:4__
    #C0 @ABC_8~64 | {{Y1_4.~64Y0_64}3Y1_4~64Y0_64Y1_8} | _8Y1_4~64Y0_64{Y1_4.~64Y0_64}3

    <修正後>
    \---%66

    #A1 o4c8 | <s2 f8 s8 f4. m4 >c8 |
    #C1 _8 | o2m8<[s<m][>c<ms]>m[l<r][d-rl]>>m<[s<m][>c<ms]>>r<[s<m][>c<ms]> |


    #A1 <s4 d32&(dr-d>c=<d)16.<d4 >s8 c4. l4 s8
    #C1 >d8<[s<m=][>c<m=s] >d[s<m=][dm=c] >>f<[f<r-][>c<r-m=]>>f[<f<d][>l<df]

    強弱やテンポ変化を省略し、スペースを使って右手と左手の音符の位置を揃えました。
    また、修正前は左手部分を#C1と#C2に分けていましたが、これを#C1に統合し、#C0に割り振っていたペダル指示もなくしました。
    これでかなりシンプルになりました。


    <>や省略音長については迷いましたが、曲の流れによって使い分ける方がいいかもしれません。

    テキストエディターの色分けは、私も使っています。併用するとさらに見やすくなると思います。

    「Museデータを素早く読む方法」ではなく、「読みやすいMuseデータを書く方法」になってしまいましたが、こんな感じでいかがでしょうか?
    もっと良い方法があれば教えてください。
記事No.9977 のレス / 関連記事表示
削除チェック/

No.10071/Re[6]: museの読譜についてアドバイスを下さい
■投稿者/ sana -(2015/08/30(Sun) 11:35:51)

    ありゃ、肝心のスペースが反映されてませんね(^_^;) ↓

    > <修正後>
    > \---%66
    >
    > #A1 o4c8 | <s2 f8 s8 f4. m4 >c8 |
    > #C1 _8 | o2m8<[s<m][>c<ms]>m[l<r][d-rl]>>m<[s<m][>c<ms]>>r<[s<m][>c<ms]> |
    >
    >
    > #A1 <s4 d32&(dr-d>c=<d)16.<d4 >s8 c4. l4 s8
    > #C1 >d8<[s<m=][>c<m=s] >d[s<m=][dm=c] >>f<[f<r-][>c<r-m=]>>f[<f<d][>l<df]


    「スペースを使って右手と左手の音符の位置を揃え」ているものとして読んでくださいませ…。
    ちなみに「 |」は小節線です。
記事No.9977 のレス / 関連記事表示
削除チェック/

No.10072/Re[7]: museの読譜についてアドバイスを下さい
■投稿者/ 開発者 -(2015/09/01(Tue) 19:55:41)

    > ありゃ、肝心のスペースが反映されてませんね(^_^;) ↓
    そんな時は、
    この掲示板の書込みオプション「図表モード」を使うと良いですよ ヽ(´▽`)ノ
    こんな感じになります。(返信引用をそのまま使っています)


    <修正後>
    \---%66

    #A1 o4c8 | <s2 f8 s8 f4. m4 >c8 |
    #C1 _8 | o2m8<[s<m][>c<ms]>m[l<r][d-rl]>>m<[s<m][>c<ms]>>r<[s<m][>c<ms]> |


    #A1 <s4 d32&(dr-d>c=<d)16.<d4 >s8 c4. l4 s8
    #C1 >d8<[s<m=][>c<m=s] >d[s<m=][dm=c] >>f<[f<r-][>c<r-m=]>>f[<f<d][>l<df]
記事No.9977 のレス / 関連記事表示
削除チェック/

No.10073/Re[8]: museの読譜についてアドバイスを下さい
■投稿者/ sana -(2015/09/01(Tue) 20:35:33)


    > そんな時は、
    > この掲示板の書込みオプション「図表モード」を使うと良いですよ ヽ(´▽`)ノ

    おお(@_@) ありがとうございます!

    「図表モード」ってそういう使い方をするものだったんですね。
    勉強になりました。



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

No.10074/Re[5]: museの読譜についてアドバイスを下さい
■投稿者/ 開発者 -(2015/09/01(Tue) 21:21:32)

    Josefさん、ご記帳ありがとうございます。

    > また何か続く話題がありましたらコメントをお願いいたします。
    Josefさんの興味深いお話に触発されました。
    思い付いたことを徒然に綴ってみようと思います。

    > そういったときに私にとって有効だったのは、
    > テキストエディターの機能で勝手に色分け強調表示してくれる、
    > いわゆるシンタックスハイライトでした。

    色分け強調すると判りやすくなることは万人が認めることと思いますが、
    それが何故なのかを自分なりに考えてみました。

    ちょっと論理の飛躍があるかもしれませんが、思い付いたのは『アイコン』でした。
    アイコンというのは、
    “コンピュータ画面で選択操作ができるように、その指図にちなむ形を表した図形”
    と定義されています。

    しかし私たちは、コンピュータが世の中に出現する遥か以前から
    『アイコン』を知っていたし、それを日常生活で当たり前のように利用していた、と考えています。
    それは『漢字』です。

    文字には漢字に代表される表意文字と、アルファベットに代表される表音文字がありますが、
    前者はまさしくアイコンそのものだ、というのが私の持論です。

    以下の文章を読んでください。

    「ひがさしてきたからひがさしてきた」

    ちょっと、解読に苦労しますよね?
    ところが、

    「日が射してきたから日傘して来た」

    これらなら、咀嚼が楽です。
    表音文字である「ひらがな」は、ベタ書きだと判りにくいですね。
    対して表意文字である「漢字」は、イメージで内容を汲み取ることが可能です。
    漢字という1つの“塊”は、まさにアイコンそのものです。

    では、もう一つの例です。

    「IthinkthereforeIam」

    これもちょっと解読に苦労します。
    しかるに、

    「I think therefore I am」

    これなら、英文であることは判ります。
    意味は「我思うゆえに我あり」です。
    中国語だと

    「我思故我在」

    となります。

    中国語と日本語はスペースが不要ですが、
    英文は、単語を分かち書きにする必要があることが分かります。
    表音文字を組み合わせて表意単語を作っているため、単語の塊を明示するスペースが必要な訳です。

    前置きが長くなりましたが、ひるがえってMuseの言語仕様について考えてみましょう。
    この文法を設計するに当たり、私が貫いた基本的なポリシーは、
    打ち込みを極限まで省力化するために1つの機能を1文字で表現することでした。

    そのポリシーはほぼ実現できたと思っていますが、
    反面、戦略無く臨むと、Museデータはまるで計算機の機械語のような様相になってしまいます。
    上記の例でいうと「IthinkthereforeIam」のような印象ですね(苦笑)。

    Muse文法は1文字に1機能を割り付けていますから、本当は表意文字であるはずなのですが、
    利用している文字がアルファベットなので、結果として表音文字に近い可読特性になってしまうのでしょう。

    sanaさんが、適度なスペーシングで可読性が高まることを示してくれましたが、
    まさに「演奏タイミング」という、Museにとっては一種の「単語の区切り」に相当する
    スペースを付けてくれたお蔭だと思います。Museデータには「時間」が埋め込まれているんですね。

    そして、今回の本題であるエディタによるシンタックスの色分けは、
    アルファベット(表音文字)を、機能記号(表意文字)いわばアイコンに昇格させる効果があるのではないか、
    という考えに至りました。

    いかんせん徒然に綴ったので、長文でかつとても読みにくい論旨展開になってしまいました。
    まったくもって可読性の悪い文章だなぁ〜(苦笑)

    脳内エディタに読込んで、色分けして読んでください(笑)。
記事No.9977 のレス / 関連記事表示
削除チェック/

No.10086/Re[6]: museの読譜についてアドバイスを下さい
■投稿者/ Josef -(2015/09/11(Fri) 23:01:10)

    開発者様、さらなる発展をしていただきありがとうございます。

    > しかし私たちは、コンピュータが世の中に出現する遥か以前から
    > 『アイコン』を知っていたし、それを日常生活で当たり前のように利用していた、と考えています。
    > それは『漢字』です。
    そうですね! 表意文字はアイコンとか、ピクトグラムとかいうものに近いと思います。
    しかも、現代の世界で現役で使われている表意文字は少ないですよね。
    それだけユニークで偉大なのだと思います。韓国では数十年前にそれを手放したのは
    少しもったいなかったように感じますが……。


    > 前置きが長くなりましたが、ひるがえってMuseの言語仕様について考えてみましょう。
    > この文法を設計するに当たり、私が貫いた基本的なポリシーは、
    > 打ち込みを極限まで省力化するために1つの機能を1文字で表現することでした。
    これは知りませんでしたが、聞いて納得です!
    最近Lilypondの文法を少し学びまして、Lilypondでは、音名のアルファベットも
    スペースで分けて書かないと、読み込んでくれないようだ、ということが
    わかりました。例えばMUSEでは、cc+d と打てるのに、Lilypondでは、
    c cis d のように、いちいちスペースを挟まなければならず、それでは、
    キーボードを鍵盤に見立てた演奏するようなコーディングはできず、
    MUSEの方が洗練されているな、と感じたところです。

    それが、MUSEの言語設計思想で、1文字1文字を表意文字のように
    とらえているから、ということが貫かれているゆえ、とは気付きませんでした。
    実に興味深いと思いました。

    > sanaさんが、適度なスペーシングで可読性が高まることを示してくれましたが、
    > まさに「演奏タイミング」という、Museにとっては一種の「単語の区切り」に相当する
    > スペースを付けてくれたお蔭だと思います。Museデータには「時間」が埋め込まれているんですね。
    確かにそう感じます。MUSEの文法で、半角の | をスペースと同等の予約文字
    (予約文字ではなくて意味を与えない文字? ですか?)として確保し続けているのは
    任意に小節線として使っていいよ、のようなイメージがあるのかもしれませんが
    実におしゃれで示唆に富んでいると思います。
    スペースと | と、各種全角文字を使って、可読性を高めることは、
    確かにあり得ることだと思います。

    書いてくださいましたように(上記引用部分)、
    言語の設計思想で、可読性より入力の効率性を追求されているというのは
    とても重要なことだと思います。
    再現したいのになかなか時間が……、というもどかしさは、
    とても感じているところですので……。無名マクロや各種省略記法なども含め、
    素晴らしい洗練された機能性だと思っています!
記事No.9977 のレス / 関連記事表示
削除チェック/


パスワード/

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