Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ4 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1314件 (81-100 を表示) / 全ページ数 / [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.9487/Re[3]: Uについて
■投稿者/ taka -(2014/02/02(Sun) 09:36:42)

    開発者さん＞

    「V」「Q」「R」などは『中心』の位置付けはなく、０％⇔１００％の変化を表すだけであることを踏まえれば、絶対的な指定と相対的な指定の共存が可能だと思います。

    これに対し、「U」だけでなく「S」もそうですが、まずは『中心』の位置付けがあって、この『中心』に対する相対的な上下・左右の動きを表すということを考えると、やはり現状の「0」を中心としたプラス・マイナスでの記述が一般的には優しいルールだと自分は思っています。

    専用機で打ち込んでいたときも思っていましたが、例えば「S」に相当する指定をGUIで行う場合、「0」を中心にプラス・マイナスで左右にPanするようになっていて、直感的に操作しやすいのですが、これをMIDI側で編集しようとすると「64」が中心の位置付けとなるためかなり面倒に感じていました。
    ですので、現状の「U」「S」のルールはとてもわかりやすいです。逆にルールを統一してしまうとわかりにくいものになると思います。

    ちなみに、諸熊さんのご報告にあるような音源への依存性があるのだとすると、手間がかかるかもしれませんが一つ一つの変化の指定を記述していくほうが確実ですね。
    （直感的に個別に変化を刻んでいくほうがわかりやすく、直線的な変化にならないよう細かな調整もできるので、自分は助かってますが）
記事No.9474 のレス / 関連記事表示
削除チェック/

No.9485/Re[4]: Uについて
■投稿者/ 開発者 -(2014/02/02(Sun) 09:22:43)

    諸熊さん

    > 確かにUとは独立してますね。
    > たぶん、RPNのコースチューンだからではないでしょうか？
    なるほど！
    別のコントロールだったんですか。
    合点がいきました。

    > ただし、発音中に変更が効く音源は少ないようです。
    takaさんの方式は、
    無音中にU0の基点をコースチューンでシフトさせる様なので大丈夫そうですね。
    一見、Xの遅延で発音中に発行しているようですが、
    実際のコントロールは交互に現れるU+20とU0の間に散りばめられますので。
記事No.9474 のレス / 関連記事表示
削除チェック/

No.9482/Re[2]: Uについて
■投稿者/ taka -(2014/02/02(Sun) 01:35:43)

    誤） なお、「X6」の指定をこのあとで「64」に戻してあげる必要があります。

    正） なお、このあとで「X6=64」を指定してもとに戻してあげる必要があります。
記事No.9474 のレス / 関連記事表示
削除チェック/

No.9492/Muse標準ヘッダーについて
■投稿者/ Αφροδιτη -(2014/02/02(Sun) 14:59:03)

    Muse標準ヘッダーの文法詳細に

    全角文字はShift-JISコードでなければなりません。

    とありますが、データファイルが Unicode の場合は、それぞれのコードで書けないと大変ですよね。

    でも、Unicode のヘッダに未対応のソフトもあるでしょうねぇ……
親記事 / 関連記事表示
削除チェック/

No.9493/Re[1]: Muse標準ヘッダーについて
■投稿者/ くさば -(2014/02/02(Sun) 21:42:56)

    > でも、Unicode のヘッダに未対応のソフトもあるでしょうねぇ……

    うっ！
記事No.9492 のレス / 関連記事表示
削除チェック/

No.9494/Re[1]: Muse標準ヘッダーについて
■投稿者/ けーご -(2014/02/02(Sun) 23:38:09)

    > Muse標準ヘッダーの文法詳細に
    >
    > 全角文字はShift-JISコードでなければなりません。
    >
    > とありますが、データファイルが Unicode の場合は、それぞれのコードで書けないと大変ですよね。
    >
    > でも、Unicode のヘッダに未対応のソフトもあるでしょうねぇ……

    昔JISやEUCに勝手にしちゃうエディタがあったような無かったような
記事No.9492 のレス / 関連記事表示
削除チェック/

No.9479/（削除）
■投稿者/ -(2014/02/02(Sun) 00:13:55)

    この記事は投稿者に削除されました
親記事 / 関連記事表示
削除チェック/

No.9481/Re[1]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/02(Sun) 01:00:24)

    > #A0 @ X101=0 X100=2 X6=64 X6=76:1 o4 c4 c c c
    > これだけで調査お願いできますか？
    私はＸＧ音源を持っていないので断定は出来ないのですが、
    結論からすると、ＸＧ音源でＧＳリセットをする使用方法が要因と推測されます。
    少なくとも以下の３バージョンでは、途中再生であっても、冒頭からの再生であっても、
    期待した演奏をしてくれています。
    Muse(v6.56)
    Muse(v6.65)
    Muse(v6.70)←まだ公開していません。
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9484/（削除）
■投稿者/ -(2014/02/02(Sun) 09:02:48)

    この記事は投稿者に削除されました
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9486/Re[3]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/02(Sun) 09:28:59)

    > XGリセットを行っても、同様に、上がっていかないようです。音源依存だとすると困ったものです
    単にXGリセットを*DATAで送信しただけではＮＧかもしれません。
    *DATA""でGSリセットを発行しないようにする必要があるかも。
    ただ、*DATA""を指定するとUの有効範囲を決めるコマンドも出なくなるので、
    XGのコマンドで、それに当たるRPNを*DATAで指定する必要も出てきます。

    Elekenさんのサイトが大変参考になると思います。
    http://ydot.ifdef.jp/muse/muse.html
    ↑
    ここの Muse Tips です。
    ↑
    このページの左のメニューに XG Reset や NRPN/RPN一覧 があります。
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9488/（削除）
■投稿者/ -(2014/02/02(Sun) 10:13:48)

    この記事は投稿者に削除されました
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9489/Re[5]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/02(Sun) 10:35:56)

    > X101 X100 X99 X98 のバッファリング・即時送信、あたり（？）をちょっと調べていただけませんか？

    先刻ご紹介したElekenさんのページにある

    Pitch Bend Sensitivity
    ピッチベンドの感度を半音単位で指定 [0-24]

    X101=0 X100=0 X6=x

    を指定する必要があるのでは？
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9490/Re[6]: RPN遅延指定。途中から再生の場合に？
■投稿者/ Eleken -(2014/02/02(Sun) 10:54:33)

    私のウェブページをご参照いただいているようなので、補足もかねて・・・

    #A0 @ R=64.64.64
    X101=0 X100=2 X6=64 X6=100:1 d4 d d d

    このデータで、X101, X100 でのRPN 指定と R= での NRPN 指定が干渉しているのが原因のはずです。
    V6.55 での NRPN の干渉問題と同様だと思います。

    それと、XG と GS で試してみたのですが、諸熊さんのレポートの通り、
    RPN の Coarse Tuning (X101=0 X100=2) は大抵の音源でノート・オン時点ではじめて反映されるようです。
    発音中の指定はピッチベンドのようには反映されません。

    ２系統のベンド（U 指定）を使いたいなら、
    （１）アサイナブル・コントローラやアフタータッチを使う
    （２）XG、GS を見捨てて Coarse Tuning で対応する
    （３）ポルタメントで無理やり対応する
    （４）開発者さんががんばってなんとかする
    のどれかしかないと思います。
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9491/Re[7]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/02(Sun) 14:57:19)

    Elekenさん、的確な分析ありがとうございます。
    > このデータで、X101, X100 でのRPN 指定と R= での NRPN 指定が干渉しているのが原因のはずです。
    > V6.55 での NRPN の干渉問題と同様だと思います。
    う〜む。
    Museのバグである可能性濃厚orz

    > （４）開発者さんががんばってなんとかする
    だとすると、この選択肢しかないような(苦笑)
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9497/Re[1]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/03(Mon) 21:48:29)

    himajin925さん
    Elekenさん

    掲題の件、当方でも確実な再現を見ました。
    Museのバグでした。次期バージョンにて対処版をご提供します。
    発見、そしてご報告ありがとうございました。

    himajin925さんに初めにご報告頂いた[9479]は、こちらで再現しなかったので
    音源の問題であろうと考え、[9488]の方でも再現しないはずという先入観に囚われていました。
    [9488]はこちらでも再現しました。ただ、[9479]の方はやはり別の問題かもしれません。

    Elekenさんには[9490]で優れた純正培養データを提示していただき感謝しております。
    お陰様でデバッグがとっても楽でした。

    (追伸)
    > （４）開発者さんががんばってなんとかする
    というのは「２系統のＵ指定」の話だったんですね。
    こちらの方は、ちょっと難しいかも(汗)
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9498/（削除）
■投稿者/ -(2014/02/03(Mon) 22:10:15)

    この記事は投稿者に削除されました
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9500/Re[3]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/03(Mon) 23:11:58)

    himajin925さん
    > この場合も音程が上がっていかないので（この例ではアタックタイムがだんだん遅くなる）、裏で NRPN を使っている場合、その前に使っている RPN NRPN のどちらを使っているかと Control# を覚えておいて復元してもらう必要があるのでしょうか？
    > 加えて R=64..:1 と遅延が指定されたら…その都度復元してもらえばいいのか？？
    意図が今一つ理解できていないので、もしや見当違いかもしれませんが、
    多分、都度復元するように記述すればいいと思います。
    Muse側で対処するのはちょっと難しいかと思います。
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9501/（削除）
■投稿者/ -(2014/02/04(Tue) 01:17:44)

    この記事は投稿者に削除されました
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9503/Re[5]: RPN遅延指定。途中から再生の場合に？
■投稿者/ 開発者 -(2014/02/04(Tue) 20:57:47)

    himajin925さん
    > 分かりました。この例では
    > #A0 @ X101=0 X100=2 X6=64 X6=100:1 R=64.. X101=0 X100=2 d4 d d d
    > とやればいいんですね。※２
    とりあえず、今回のバグに対応したバージョンをメールで送付しますので、
    上記の記述でうまくいくかどうかを、試してみてもらえますか？

    > このX6=65〜100が「X99=1 X98=99」の DataEntry として評価されてしまう可能性がある、とこう考えたのですが、違ってますか？
    今回送付するMuseは、シークポイントの演奏直前に発行すべきNRPN/RPNを、正しく発行するようにしたつもりです。
    この件も、試してみてください。

    > ※１途中再生の場合、波形加工の NRPN だからバッファリング、であってますか？
    シーク時の処理は他のコントロールとの絡みがあってとても複雑です。

    　NRPN(MSB),NRPN(LSB),RPN(MSB),RPN(LSB),DataEntry(MSB),DataEntry(LSB)が絡み合い、
    　ランニングステータスが施された波形加工の３特性(R= W= Q=)が、
    　それぞれ２ないし３のパラメータで同時並行的に遅延しながらDataEntryを連続的に送信。
    　しかも、Xコマンドの遅延による複数のDataEntryが、そこに不規則に挿入される。
    　加えて、バンクセレクトの様に順番が関係するものや、
    　ポリオン／ポリオフの様な排他的なものなど、が入り乱れている。
    　・・・といった状況なので、様々なタイプのバッファやフラグを駆使しています。

    　実は、このような工夫を一切行わず、
    　再生位置までのコントロールを単純にすべて音源送信してしまえば、プログラムは数行で済みます。
    　しかしそれではシークが極度に遅くなり、音源側もメッセージをロストしてしまう可能性があります。
    　このため、できるだけ最終結果のみを送信する様、かなり手の込んだプログラムになっています。

    よって、
    > ※１途中再生の場合、波形加工の NRPN だからバッファリング、であってますか？
    に対して「あっています」と答えるのは間違いではないのですが、それがすべてではありません。

    > ※２ muse が内部で使用する RPN NRPN はこのR=.. W=.. の場合だけですか。将来的にも増えませんか？
    本課題を回避するためにRPN NRPNコマンドを立ち上げる可能性は、ゼロではないですが薄いです。

    > 開発者様なら、もっとスマートに解決してくれることを祈って。
    継続検討いたします。
記事No.9479 のレス / 関連記事表示
削除チェック/

No.9504/Re[6]: RPN遅延指定。途中から再生の場合に？
■投稿者/ himajin925 -(2014/02/06(Thu) 11:40:07)
□U R L/http://blogs.yahoo.co.jp/himajin925

    送っていただいた、V6.70のベータ版で途中再生の不具合が解消しているようです。
    ありがとうございます
記事No.9479 のレス / 関連記事表示
削除チェック/

パスワード/

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