Muse掲示板

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

過去ログ表示

過去ログ3 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1302件 (761-780 を表示) / 全ページ数 / [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.8852/Re[3]: 次期Museにおける文法非互換情報
■投稿者/ Eleken -(2013/04/09(Tue) 21:23:13)

    開発者様

    お返事ありがとうございます!
    なぜこの仕様変更がセットで行われたのか、頂いたレスを読んで理解が深まりました。

    > 新しく連符内連符が無限の階層で記述できるようになったため、
    > あまり複雑なルールを持ち込むと、一体今どのアクセント値になっているのか迷子になってしまうと考えました。
    なるほど、確かに私の提案では、2次以上の連符を念頭に入れていませんでした。
    また、連符全体へのアクセントも存在することを考えると、これはうまくいきませんね。

    > そこで、
    > 「群音内で指定したアクセント値は、その外に継承しない」
    > と、極めてシンプルな仕様にしました。つまり、省略音長と同じです。
    新仕様のように、C における変数のスコープのような定義にすれば、任意次の連符や連符全体へのアクセントに対して
    シンプルかつ直感的な表現になるというわけですね。
    今回のご説明で新仕様の合理性がよくわかりました。

    > さて問題は、
    > 新仕様において期待する演奏を行いたい場合ですが、
    > そこで、ちょっとトリッキーですがゼロ音長を使う手があります。
    > w+40d0 (wd8rm)2 (wf8slc) w<d2>
    なるほど、ゼロ音長を使えば確かに、私の思うような記述に近いものになりますね!
    (今のうちに、今まで作ったデータをチェックして、このスタイルの記述にしておかなければ・・・)


    今回なぜこのような提案をしたのかと考えてみました。
    新仕様は音長と同じ仕様でシンプルだという点は、うすうす気づいていましたが・・・
    私の中では、アクセント "w" とは楽譜でいう ">" や "∧" のような、音符1つに対して
    表現上の効果を及ぼす記号のイメージでした。
    これは連符内にあろうがなかろうが、同じ記号は同じ意味ですよね。
    ゆえに、アクセント指定子は連符とは独立であるべきと思ったわけです。

    他方音長というのは、連符内にあると楽譜上の 8 分音符は 16 分音符にも 32 分音符にもなり得ます。
    したがって、絶対的な音長は連符の有無に依存するわけですから、
    音長指定のスコープは連符内で閉じていてしかるべきだと思います。

    > ・・・極めてシンプルな仕様にしました。つまり、省略音長と同じです。
    ということでしたが、以上の理由により、アクセントと音長では連符への依存性が
    違うので、音長とは違う仕様のほうが自然なのでは?と思ったわけです。

    しかし、Muse の文法って連符全体へのアクセント指定も許しているんですよね。
    この2つのアクセント指定を共存させるとなると、スコープ式の定義以上に
    シンプルな定義は難しいのですね・・・。

    (あと、毎度毎度、些細ともいえる問題に長文でレスしてしまって、スミマセン・・・(笑))

    #ところで今気づいたのですが、スコープ式の定義にした場合、
    譜面モニタで強弱を見た場合に問題になりませんか?
    譜面モニタで「w」とだけ表示されているのに、譜面モニタでひとつ前にある
    アクセント量とは違う再生がされるという状況もありうると思います。
    これも想定の範囲内でしょうか?
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8854/Re[4]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/09(Tue) 22:22:14)

    > しかし、Muse の文法って連符全体へのアクセント指定も許しているんですよね。
    > この2つのアクセント指定を共存させるとなると、スコープ式の定義以上に
    > シンプルな定義は難しいのですね・・・。
    そうなんです。

    それにしても、流石Elekenさんですね。
    1を聞いて10も100もご理解されているご様子に感服します。
    私が何週間も考えたテーマを小一時間で解き明かしているみたいです。

    > 私の中では、アクセント "w" とは楽譜でいう ">" や "∧" のような、音符1つに対して
    > 表現上の効果を及ぼす記号のイメージでした。
    > これは連符内にあろうがなかろうが、同じ記号は同じ意味ですよね。
    > ゆえに、アクセント指定子は連符とは独立であるべきと思ったわけです。
    本当は、このElekenさんのイメージが最もシンプルで美しいのかもしれません。
    私が、アクセントを連符や和音の括弧全体に掛けることができるという
    欲張りな仕様にしたため、事を複雑にしてしまった模様です。(苦笑)

    複数音からなる装飾がある時、それを連符で書くと音長の調整も楽なのですが、
    そこに一括してアクセントを付けたくなるんです。
    時折、和音にガツンとアクセントを付けたくなる時もありますし・・・。
    そのために、この欲張り仕様にしてしまいました。

    >(あと、毎度毎度、些細ともいえる問題に長文でレスしてしまって、スミマセン・・・(笑))
    いえいえ、私も長文ですのでお互い様ですし、読んでて楽しいです。
    それに「些細」では無いと思います。
    なにせ今回の非互換データ数ダントツの案件ですから。

    ちなみに、今最終調整に入っているのですが、未だにバグがちらほら見つかりまして(苦笑)。
    で、別件ですがまた仕様が変更されてしまいました。
    「D連符内和音のアルペジオ」です。
    これも無視しがたい量の非互換データ数になってしまいましたorz。
    アクセントもさることながら、こちらは結構曲想に影響があるので、
    私にとってはこちらの方が心が痛いです(苦笑)。

    > #ところで今気づいたのですが、スコープ式の定義にした場合、
    > 譜面モニタで強弱を見た場合に問題になりませんか?
    > 譜面モニタで「w」とだけ表示されているのに、譜面モニタでひとつ前にある
    > アクセント量とは違う再生がされるという状況もありうると思います。
    > これも想定の範囲内でしょうか?
    想定範囲といえばかっこいいですが・・・。
    本件は、お許し下さいっていう感じです(笑)。
    そもそも、vとwを足さないと本当の強弱値がわからないですし。

    まあ、譜面モニタの属性表示は、他にも曖昧な部分が多々ありまして、
    打ち込んだ文字をそのまま出すことで位置ズレを確認するといったレベルです。
    あくまでもMusing支援用とお考え頂けると幸いです。
    私はよく行内の場所がわからなくなると、w+1 w+2 w+3 などと仮挿入して、
    デバックライトとして使ってます(笑)。

    なんにしても、貴重なご意見ありがとうございました。
    情報公開してよかったです。
    また何かお気づきの点あれば言って下さい。
    必要なら、作り直す覚悟もありますので。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8856/Re[5]: 次期Museにおける文法非互換情報
■投稿者/ Eleken -(2013/04/09(Tue) 23:28:48)

    > 複数音からなる装飾がある時、それを連符で書くと音長の調整も楽なのですが、
    > そこに一括してアクセントを付けたくなるんです。
    いまいちわからなかった連符に対するアクセントの存在意義は、こういうことだったのですか。
    なるほど確かに、そういうシチュエーションはよくありますね。
    ちなみに私は今まで連符へのアクセントの代わりに、両端に v を付けて、
    v-20 (drmf)16 v+20 s4
    などと書いていました。
    そうしないと、(drmf) のどれかに「相対的な」アクセントをあとで追加したくなったとき、
    v-20 (dw-20rmf)16 v+20 s4
    という具合に書けないものですから。

    > それに「些細」では無いと思います。
    > なにせ今回の非互換データ数ダントツの案件ですから。
    そうですね・・・。
    今一度自分の過去のデータを見直していて、互換性のない記述の多さに辟易してしまいそうです。
    たとえば、ドラムスパートだけ見ても、こんな感じです。
    #Z0|,8__, (_w-40,),_w, |,8__, (_w-40,),__ |w-20,8___ ,(_w,)(_,)_
    #Z1|_8_,(_w-50,) __,(_w,)|_8_,(_w-50,) __,_ |_8_,(_w-50,) __,(_w,)
    これは、ヤバそうな感じです。

    > で、別件ですがまた仕様が変更されてしまいました。
    > 「D連符内和音のアルペジオ」です。
    > これも無視しがたい量の非互換データ数になってしまいましたorz。
    > アクセントもさることながら、こちらは結構曲想に影響があるので、
    > 私にとってはこちらの方が心が痛いです(苦笑)。
    むしろ、今までアルペジオは連符でスケーリングされていたということに初めて気づきました(笑)。
    というより、すべての遅延表記はスケーリングされていたのですね。
    いや〜、何かがおかしいとは思っていたのですが(笑)。
    こっちの変更は、データによっては大変なことになっていそうですね。

    > まあ、譜面モニタの属性表示は、他にも曖昧な部分が多々ありまして、
    > 打ち込んだ文字をそのまま出すことで位置ズレを確認するといったレベルです。
    > あくまでもMusing支援用とお考え頂けると幸いです。
    なるほど、デバッグ用途の趣が強いわけですね。納得です。

    > なんにしても、貴重なご意見ありがとうございました。
    > 情報公開してよかったです。
    そう言って頂けると嬉しいです。
    忌憚なく勝手気ままに発言していますが、さすがにあるものを作り直せとまでは要求しませんので(笑)、
    1ユーザのたわごととして聞き流して頂ければ幸いです。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8857/Re[6]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/10(Wed) 00:02:33)

    > #Z0|,8__, (_w-40,),_w, |,8__, (_w-40,),__ |w-20,8___ ,(_w,)(_,)_
    > #Z1|_8_,(_w-50,) __,(_w,)|_8_,(_w-50,) __,_ |_8_,(_w-50,) __,(_w,)
    > これは、ヤバそうな感じです。
    う〜む。やっぱり罪悪感を感じるなぁ〜(苦笑)。
    今まで皆さんが精魂込めて創り上げた演奏ですからねぇ〜。
    上記は、具体的なアクセント値が書いてあるものは大丈夫ですが、
    そうでないwのみの記述は、1つ1つ指定することになりそうですね。

    ・・・やはり、どうにかして互換を維持した方が良いでしょうか。
    例えば、アクセント値は連符や和音のスコープを無視して、一直線に継承される。
    ただし、連符や和音の直前に掛かるアクセント指定はその連符や和音の要素全体に作用する。
    その際、連符や和音の途中でアクセント値が切り替わった場合は、
    その場でアクセント値が切り替わる。

    これなら互換を保ちつつシンプルでしょうか。
    譜面モニタの表示も、現在考えている仕様よりは信憑性も増しそうですし・・・。

    > そうしないと、(drmf) のどれかに「相対的な」アクセントをあとで追加したくなったとき、
    > v-20 (dw-20rmf)16 v+20 s4
    新しい一直線継承の仕様ならば、
    w-20 (dw-40rw-20mf)16 s4
    と書けそうですね。
    連符内では、アクセントが v の役目をする所が逆説的ですけど(笑)。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8860/Re[7]: 次期Museにおける文法非互換情報
■投稿者/ Eleken -(2013/04/10(Wed) 21:05:45)

    何度もすみません・・・。
    > 新しい一直線継承の仕様ならば、
    > w-20 (dw-40rw-20mf)16 s4
    > と書けそうですね。
    > 連符内では、アクセントが v の役目をする所が逆説的ですけど(笑)。
    群音への "w-20" って「群音内の v を -20 する」ではなくて、
    「初期アクセント値 -20 をセットした上で、群音内の全ての音に "w" を付加する」という意味なんですね!(勘違いしてました)
    だから、こういうような逆説的な表記になるわけなんですね。
    これは「周りの音より 20 だけ小さい音」を表現するのに "w-40" と記述しているのが、何か少し妙な感じがします。
    私の感覚では、群音への "w" と音符への "w" は、違うローマ字を割り振りたいくらい違うものに感じます。
    (ローマ字は 26 個しかないので、わがままは言えないのですが)

    もしかしたら、アクセントの重ねがけをできるようにしたらうまく行くのかな・・・?
    上記の例は w-20 (dw-20rmfs)16 s4 と書きたいです。
    重ねがけに加えて「w の省略は時間的に前の w の値を使う」とでもすれば、互換性はだいぶましになると思います。
    そんなことをしたら、Muse のインタプリタ(を書く人)に大きな負担を強いることになりそうですが・・・(苦笑)

    > ・・・やはり、どうにかして互換を維持した方が良いでしょうか。
    私のデータでは、ゴーストノートがゾンビノートになってしまいかねない変更なので(笑)、ちょっと意見してしまったのですが、
    答えのない問題なので、開発者さんの一存にお任せします!

    あと、言い忘れていたのですが、アルペジオだけは連符でスケーリングしない
    という新仕様に関しては、自然で合理的であるように私も感じています。
    こっちの仕様変更は積極的に賛成です!
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8862/Re[8]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/10(Wed) 22:17:30)

    Elekenさん
    >> 新しい一直線継承の仕様ならば、
    >> w-20 (dw-40rw-20mf)16 s4
    >> と書けそうですね。
    > それに「周りの音より 20 だけ小さい音」を表現するのに "w-40" と記述しているのも、何かおかしい気ようながします。
    あはははっ。確かに。
    本件は、ちょっとした思い付きでした。忘れて下さい(苦笑)。

    アクセントの重ねがけというElekenさんの煌くような発想は、次々版の楽しみに取っておくとして、
    今回の非互換アクセント仕様(つまりスコープ方式)についてです。
    あれからもう一度熟考いたしまして、やはり冒頭でElekenさんから頂いた案に近い、
    「一直線の継承方式」に再編することに腹をくくりました。
    この部分、作り直します!

    この一直線仕様を再掲しますと
    ・アクセント値は連符や和音の括弧(スコープ)を貫いて、一直線に継承される。
    ・ただし、連符や和音の直前に掛かるアクセント指定はその連符や和音の要素全体に作用する。
    ・連符や和音の途中でアクセント値が切り替わった場合も、その場でアクセント値が切り替わる。
    となります。

    これでデータ互換は維持され、
      G群音に掛かるアクセント
      H群音内で指定したアクセントの値
    の非互換リスト項目は、撤廃できるわけです。(祝)

    また、この方式ならば、現在のアクセント値で迷子になることも無いと思います。
    なんせ一直線ですから(笑)。
    この案の採用に踏み切った一番の理由は、
    「考えてみると、w の親分にあたる v だって、一直線じゃん」
    です。

    > あと、言い忘れていたのですが、アルペジオだけは連符でスケーリングしない
    > という新仕様に関しては、自然で合理的であるように私も感じています。
    > こっちの仕様変更は積極的に賛成です!
    ご賛同頂き、嬉しいです\(^o^)/
    実際に、ギターストロークなどで試してみると、
    @P25 [dmsc<m>]2:i30(,:,:,:) ,:
    と完全に省略して書いても自然な感じであることがわかります。
    現在のMuse(V6.3x)では、連符内では別途微調した値を指定しないとちょっぴり不自然な感じです。
    まあ、微分音長レベルの話なので、注意深く聴かないと分からないごく僅かな差なんですけど。
    8,333データ中212データの非互換が生じますが、お許しいただきたいと思います。

    ※それと、連符内でスケーリングしないコマンドがもう一つありました。
     テンポの遅延です。これは、本来はスケーリングした方が良いと思うのですが、
     プログラミングの都合上、対応が難しいので断念しています。ご容赦下さい。

    あとこれは蛇足です。
    今回非互換状況を色々と調査してみて気づいたのですが、
    和音の逆アルペジオを書いているデータがあるということです。
    [dms]4:32-
    なんと100を越えるデータがありました。
    現時点のMuseでは、エラーにせず正順アルペジオとして演奏しています。
    これらのデータは次回のMuseから自動的に逆アルペジオで演奏を始めます。
    かなり以前のデータが多いのですが、これって遠い未来のMuseを予測してたの!?(笑)
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8863/Re[9]: 次期Museにおける文法非互換情報
■投稿者/ Eleken -(2013/04/10(Wed) 23:13:28)

    > 「一直線の継承方式」に再編することに腹をくくりました。
    これまで通り、アクセントは連符に対して独立になるということですね。
    これで、私のデータのゴーストノートも生き返ってゾンビノート(笑)にならず済むわけで、ほっとしております。

    > 和音の逆アルペジオを書いているデータがあるということです。
    > なんと100を越えるデータがありました。
    > かなり以前のデータが多いのですが、これって遠い未来のMuseを予測してたの!?(笑)
    流石の一言ですね。

    今まで私の意見に対し、いろいろとご検討頂き、何度も長文で返信を下さいまして、ありがとうございました。
    新バージョン楽しみにしています。

    #蛇足ついでに・・・
    プログラミングもさることながら、マニュアルの改訂も大変そうに思いますが、
    マニュアル 4567 行目の "sus2" は 4565 行目にあるべきかと思うので、改訂ついでに修正して頂ければと思います。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8864/Re[10]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/11(Thu) 00:00:07)

    > > 「一直線の継承方式」に再編することに腹をくくりました。
    > これまで通り、アクセントは連符に対して独立になるということですね。
    はい。Elekenさんの設計思想を採用させて頂きました。
    本当にありがとうございます。

    > 今まで私の意見に対し、いろいろとご検討頂き、何度も長文で返信を下さいまして、ありがとうございました。
    とんでもありません。
    Elekenさんの書込みが、より良い仕様へと私を導いてくれました。
    そして何より、500以上のデータを非互換から救ったのです!

    > プログラミングもさることながら、マニュアルの改訂も大変そうに思いますが、
    > マニュアル 4567 行目の "sus2" は 4565 行目にあるべきかと思うので、改訂ついでに修正して頂ければと思います。
    ご指摘、ありがとうございます!
    今後とも、よろしくお願いいたします。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8865/Re[9]: 次期Museにおける文法非互換情報
■投稿者/ 浅川 -(2013/04/11(Thu) 06:55:40)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    横からすみません

    > ※それと、連符内でスケーリングしないコマンドがもう一つありました。
    >  テンポの遅延です。これは、本来はスケーリングした方が良いと思うのですが、
    >  プログラミングの都合上、対応が難しいので断念しています。ご容赦下さい。
    いずれぜひ対応していただきたい機能ですね...。
    気長に待っています。
    特にアドリブ部分などが編集しやくなりそうです。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8866/Re[10]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/11(Thu) 19:21:03)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    浅川さん

    テンポ遅延の連符内スケーリングの件。
    > いずれぜひ対応していただきたい機能ですね...。
    > 気長に待っています。
    > 特にアドリブ部分などが編集しやくなりそうです。

    自分でも「やるべき」と思っており、そしてそれを待っている人がいる・・・。

    そうなると、たとえ技術的障壁が高くても頑張って登ってみたくなります!
    浅川さんに背中を押されたので、挑戦してみます。
    いつもなら、検討リストに入れて次々版以降でゆるりと対応なのですが、
    本件は、今話題の非互換性をはらんでいますよね。
    だとしたら、この機に乗じてやってしまいたい気分です。

    ざっと確認してみたところ、8,333曲中98データが非互換に引っ掛りそうです。
    ただ、内容を見ると連符内スケーリングを期待してコーディングされているものも多々ありそうです。
    またしても、未来のMuseを予見していたのかっ!(笑)
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8886/Re[10]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/15(Mon) 19:43:02)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    えー、誠にお恥ずかしい次第なのですが、告白します。
    連符内のテンポ遅延の件ですが、これは実はバグであることがわかりました。

    というのは、2001/01/07の掲示板で、
    名越さんから以下のご指摘を受けていたのです。
    --------------------------------------
    加藤様、
    次の@とAを比べてみると、
    @A P41
    #A0o4 %40V100(%200:2d2d4rmfs)4 (lc<drmf)4 (slc<drm)4 ; @
    #A0o4 %40V100(V30:2d2d4rmfs)4 (lc<drmf)4 (slc<drm)4 ; A

    @の%に付けた遅延は、連符の外の音長に対して働き、
    AのVに付けた遅延は、連符の中の音長に対して働くという違いがあるのですが、
    これは仕様でしょうか。
    ======================================


    これに対し私は、当時こう答えていました。
    --------------------------------------
    仕様ではありません。バグでした。
    申し訳ありませんでした。そして、発見ありがとうございます。
    仕様上はAが正しく、%の場合もAの様な解釈をすべきでした。
    すぐに直します。
    本体表記バージョンは変わりませんが、muse401.lzh となる予定です。
    ======================================

    そして確認したところ、muse401の時点では確かにテンポもAの仕様になっていました。
    興味があったので、一体いつの時点で先祖返りしてしまったのか調べてみたところ。
      〜V5.5 まではOK
      V5.6〜 で先祖返り
    という事実がわかりました。

    V5.6は譜面モニタの属性表示を1つだけ、初めて実装したバージョンであり、その属性とは「テンポ」でした。
    この時、テンポの連符内スケーリング処理を潰してしまうという障害を発生した模様です。
    確かに今回対応してみてわかったのですが、メモリ効率を高めるためにいろんな工夫をしてまして、
    属性のテンポ表示と連符内スケーリングの両立が難しかったのは事実です。

    でもそれを乗り越えて、V6.4ではきっちり両立させましたのでご安心下さい。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8858/Re[6]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/10(Wed) 00:19:17)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > むしろ、今までアルペジオは連符でスケーリングされていたということに初めて気づきました(笑)。
    > というより、すべての遅延表記はスケーリングされていたのですね。
    はい。
    属性の遅延指定は、以前はスケーリングされていなかったのですが、昔、あるミューザーの方に指摘されて改良した覚えがあります。
    アルペジオをサポートしたのは更にその後なのですが、単に対称性だけでアルペジオもスケーリングしてしまったのが、
    私の設計ミスだったと反省しています。

    連符内に書かれた強弱などの属性は、確かにスケーリングした方が把握しやすいし、
    再現表記などでの使いまわしがしやすいと思うのですが、
    アルペジオの方はスケーリングすると指定が大変厄介です。
    前者はいくつもの音符に掛かる時間を相対的な感覚で指定するのに対し、
    後者は絶対的な時間のズレを維持したい場合が多いからだと思います。

    > いや〜、何かがおかしいとは思っていたのですが(笑)。
    > こっちの変更は、データによっては大変なことになっていそうですね。
    そうなんですよねぇ〜。
    でも、こちらの方は互換を崩しても変更に踏み切りたい気分です。
    困りました(笑)。

    ★追伸:
    よくよく考えてみたら、属性の遅延値については連符内のスケーリングが必須ですね。
    例えば、11連符の3音目から7音目までの間で遅延を使って滑らかに音を大きくしたい、
    なんていう要請に応えるには、スケーリングが無いと大変です。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8873/Re[2]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/13(Sat) 09:26:15)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    もう1つ非互換を伴う仕様変更を追加しました(してしまいました)苦笑

    Nフィンガー宣言によるアクセント指定の継承性
    http://musewiki.dip.jp/MuseWiki/index.php?V6.4%A4%CB%A4%AA%A4%B1%A4%EB%C8%F3%B8%DF%B4%B9%BB%C5%CD%CD

    それと、現時点での非互換データリストをアップしました。
    http://www1.c3-net.ne.jp/kato/data/list.txt

    ・ファイル名は、私の感性で変更してしまっているものがあります。
    ・殿堂入りしていないデータも含んでいます。
    ・非互換項目が多岐に渡っているため、多少漏れがあるかもしれません。
    ・非互換のほとんどは、連符内アルペジオの音長だと思います。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8875/Re[3]: 次期Museにおける文法非互換情報
■投稿者/ ねこしん -(2013/04/13(Sat) 11:31:55)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    > それと、現時点での非互換データリストをアップしました。
    でも大分減ったっぽいですね。

    後は公開を待つのみかな?
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8876/Re[4]: 次期Museにおける文法非互換情報
■投稿者/ 楠本 -(2013/04/13(Sat) 12:42:56)
□U R L/http://sinfonia.6.ql.bz/

    >和音のアルペジオ指定にて、従来はその要素に休符がある場合はアルペジオのカウントとして無視していたが、
    > 新仕様では休符もカウント対象とした。あえて休符を記述したのであるから、それを忠実に再現させることで、
    > 表現力が高まると判断した。
    この意味が判りません。
    私の解釈では、現状でも休符通りになっていると思いますが。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8877/Re[5]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/13(Sat) 18:15:33)
□U R L/http://sinfonia.6.ql.bz/

    楠本さん
    > この意味が判りません。
    > 私の解釈では、現状でも休符通りになっていると思いますが。
    ご指摘ありがとうございます!
    私の勘違いでした。

    Dアルペジオにおける休符要素の扱い
    この項目に関しては、ご指摘の通り完全互換でした。
    どうりでMIDIバイナリの差分抽出でも「非互換データ:該当なし」のはずです。(苦笑)

    非互換リストを直しておきました。
    http://musewiki.dip.jp/MuseWiki/index.php?V6.4%A4%CB%A4%AA%A4%B1%A4%EB%C8%F3%B8%DF%B4%B9%BB%C5%CD%CD
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8878/Re[4]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/13(Sat) 18:17:48)
□U R L/http://sinfonia.6.ql.bz/

    ねこしんさん
    > 後は公開を待つのみかな?
    もう少しお待ち下さい。
    現在、8,333曲の楽譜出力を日夜バッチで流し続けております。
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8879/Re[5]: 次期Museにおける文法非互換情報
■投稿者/ ねこしん -(2013/04/14(Sun) 12:54:27)
□U R L/http://sinfonia.6.ql.bz/

    > 現在、8,333曲の楽譜出力を日夜バッチで流し続けております。

    すさまじい数ですよね…
    museの歴史を感じます
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8849/Re[1]: 次期Museにおける文法非互換情報
■投稿者/ ねこしん -(2013/04/09(Tue) 18:01:01)
□U R L/http://sinfonia.6.ql.bz/

    連符内連符に対応するんですね!
    いやあー要望に応えていただいて本当にありがたいです。

    3重連符とか4重連符もいけるんですか?

    結構いま狂喜乱舞してます^^
記事No.8847 のレス / 関連記事表示
削除チェック/

No.8851/Re[2]: 次期Museにおける文法非互換情報
■投稿者/ 開発者 -(2013/04/09(Tue) 19:01:59)
□U R L/http://sinfonia.6.ql.bz/

    ねこしんさん
    > 連符内連符に対応するんですね!
    > いやあー要望に応えていただいて本当にありがたいです。
    >
    > 3重連符とか4重連符もいけるんですか?
    はい。いけます。どこまででも(笑)。

    > 結構いま狂喜乱舞してます^^
    そのお言葉に、開発者である私は喜色満面です!
    ありがとうございます。

    今、最終調整していますので、もうしばらくお待ちください。
記事No.8847 のレス / 関連記事表示
削除チェック/


パスワード/

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