Muse掲示板

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

過去ログ表示

過去ログ1 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1474件 (681-700 を表示) / 全ページ数 / [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] [66] [67] [68] [69] [70] [71] [72] [73]

No.5162/Re[4]: ★★ご報告(V5.23)
■投稿者/ 岡林 -(2007/10/26(Fri) 09:18:50)

    nagopa様

    > フィンガーをまたがる連結について。
    > もし、ピアノの普通の奏法として、鍵盤を押した指を別の指で押し直す
    > ことにより、音を延ばすというのがあるのなら、旧仕様は実世界を表す適切な
    > 文法と言うこともできるのですが、ピアニストの方、どうでしょうか?
    これは指使いの都合でそう珍しくないことだと思います。
    その後の音が自然に弾けるように、ある程度長い音で押しっぱなしのまま
    指を変更することはありますね。「エリーゼのために」ぐらいの曲でも
    右手の5の指を1に変えるところがありますし…

    > そのような奏法があったとしても、5本の指を5つのフィンガーに割り当てて
    > データ入力する人などいないでしょうから(でもそうするとカラフルで面白い
    > かもしれない)、上記は詭弁でしょうかね。
    私もフィンガー=指と考えるなら和音の連結は手全体で考えるのが
    自然かな、等と考えたりしましたが、Museのフィンガーの実際の性質は
    そういうものではないですから、まああまり関係ないかもしれないですね。

    > 加藤さんの強い意志が示されたことで、新仕様でFIXすることが濃厚になって
    > きましたが、自分のデータを新仕様にあわせて修正しようかと思っている人や、
    > 殿堂に投稿しようと思っている人にとっては、最終的に仕様をFIXする期日を
    > 明確にしたほうが良いと思います。
    同感です。私も基本的にそうなるものと認識していますが、
    書き込みをためらっていらっしゃる方もいるのかなと思い、一応
    思いつく限りの保守的な意見は挙げてみました(笑)
    ころころ変えるべきものではないですから、最終決定の
    タイミングは決めておいた方がよいと思います。
記事No.5141 のレス / 関連記事表示
削除チェック/

No.5166/Re[5]: ★★ご報告(V5.23)
■投稿者/ nagopa -(2007/10/27(Sat) 22:22:31)

    岡林様、
    ピアノ奏法の説明ありがとうございます。

    > 私もフィンガー=指と考えるなら和音の連結は手全体で考えるのが
    > 自然かな、等と考えたりしましたが、Museのフィンガーの実際の性質は
    > そういうものではないですから、まああまり関係ないかもしれないですね。

    そうですね。この論法は取り下げます。
記事No.5141 のレス / 関連記事表示
削除チェック/

No.5165/Re[5]: ★★ご報告(V5.23)
■投稿者/ 浅川 -(2007/10/27(Sat) 19:41:56)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    【余計な考察】
    もし
    > フィンガー=指と考え
    ないならばなにか問題があるのかな・・・
    と思っての考察です。
    新たにMuseを始める方への説明でフィンガーの概念の説明が
    少し難しくなるくらいでしょうか?
    たしかメンバやフィンガーの概念って、最初はちょっと難しかった様に思います。
    (記憶によると私自身も確か…???^^;)

    フィンガー=指でない部分もあったのでなにも問題はないかもしれません。
記事No.5141 のレス / 関連記事表示
削除チェック/

No.5163/Re[3]: ★★ご報告(V5.23)
■投稿者/ 木下 -(2007/10/26(Fri) 18:00:27)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    Musingのスタイルで今回の仕様変更の影響は様々と思われますので
    ひとつの例として報告します。

    −−集計
    > (A)和音内の連結&解釈の新仕様
    > (B)連結&の対象をフィンガー内に留めるという仕様
    > (C)pqスタッカートに対して非依存の連結を行うという仕様
    >
    殿堂登録データ(20曲)で集計しました。
    (A)なし
    (B)2
    (C)6
    (A)(B)(C)6


    −−私の推奨案は下記です。
    > [1] (A)(B)(C)すべて実施(つまり現在のV5.23)
    (たぶん)全てのデータはV5.23の方が意図通りに演奏されると思われるからです。
    ただ登録データの修正は現状では大変に困難なので見通しが立っていません。

    −−個々の仕様について以下にコメントします。
    (A)
    []内の連結が/などで選択的に排除される仕様に対して,兎に角まとめて連結したり或いは連結したい音を明示的に表現するなどを選択できるV5.23の仕様が好みです。
    ただ仕様の差が嗜好程度と思われるのに記述の変更が大きいのが気になる所です。

    (B)
    すいませんがフィンガー内だけで効果すると勘違いしていました。
    私が複数のフィンガーを使うのは,同じ楽器で複数の奏者が異なる演奏をする場合です。
    このような場合では,&がメンバー全体に効果する仕様では他のフィンガーからの影響に
    配慮するのは大変のような気がしますのでV5.23に賛成です。
    という訳で私のデータの差異は他のフィンガーの影響を無視していた結果と思います。

    (C)
    元々改正をお願いした内容と同一ですので賛成です。
    旋律で多用するqの設定に影響されないで&が効果して欲しいからです。
    (いちいち&の直前でq0を挿入して,元のq*に正しく戻すのが煩わしい)
    多くのデータで相違が見られますが,大抵はq0の入れ忘れと思います。
    (1曲だけ確認)

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

No.5164/Re[4]: ★★ご報告(V5.23)
■投稿者/ 開発者 -(2007/10/26(Fri) 23:50:23)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    nagopaさま、岡林さま、そして木下さま
    更には、Kentaroさま、kawagutiさま、くさばさま、浅川さま、るうさま

    今回の私の独善にも近い仕様変更に対して、
    真正面からの深い考察と提言の数々、
    本当にありがとうございます。

    当事者意識のない発言をお許し頂けるならば、
    今回の件がどうなろうと、
    皆さんから受けたこの一連のメッセージを
    私は一生忘れないことでしょう。

    ●nagopaさま[5160]
    > 自分のデータを新仕様にあわせて修正しようかと思っている人や、
    > 殿堂に投稿しようと思っている人にとっては、
    > 最終的に仕様をFIXする期日を明確にしたほうが良いと思います。
    > 文化の日11月3日でどうでしょう。
    まさしくその通りですね。
    互換性を崩した状態で、かつそれを維持するのか破棄するのかを
    明確にしない期間を長引かせるべきではありません。
    nagopaさんが提案してくれた11月3日を、
    今回の「その時」としたいと思います。
    文化の日・・・ですね。

    ●岡林さま[5162]
    > 書き込みをためらっていらっしゃる方もいるのかなと思い、一応
    > 思いつく限りの保守的な意見は挙げてみました(笑)
    ご配慮、ありがとうございます。
    岡林さんの書き込み真意がヒシヒシと伝わってきます。

    > ころころ変えるべきものではないですから、最終決定の
    > タイミングは決めておいた方がよいと思います。
    上述の通り、11月3日と致します。

    できれば、その時までに
    できるだけ多くの方のご意見を聞きたいです。

    ●岡林さま[5161]
    > しかし、これほどまでに大きく互換性を崩すのはMuse史上
    > かなり大きな事件ではないでしょうか?
    実はV1.5の時点で、和音の音長指定の互換性を崩しました。
    それ以前の仕様は、和音内の省略音長は和音直前の音長を引き継ぐものでした。
    例えば、
    f8 [dms]4 と書くと、f8 [d8m8s8]4 となっていたのです。
    多分、今回よりもダメージの大きな改変だったと思います。
    ただ当時はMuseデータが100に満たなかったので、大きな問題にはなりませんでした。
    改めて「Museデータ」こそがMuseの世界を造り上げていることを実感いたします。
    Readme.txtを読み返すと、V2.1とV2.3、そしてV3.1も互換崩しをやっているようです。
    ただ、確かに今回ほどドラスティックな影響は出なかった模様です。

    > 基本的に同一フィンガーなら無理に&を使わなくとも
    > 必要な音長を各音について指定すれば同様のことができます。
    確かにそうとも言えますが、ただ管弦楽の場合は
    発音中に音量を変えるなどの場合があり、その際は、
    d2& @V40:1 d1
    という風に、音長加算記号(^)では記述できない指定が可能となります。

    > メンバー単位の連結の需要もそれなりにはあるので、
    > 新仕様にしなければならない必然性はあまり感じないのですよね。
    > 勿論旧仕様でなければならない必然性もないわけですが、
    > 特別どちらが良いという風には私には思えないので上位互換を
    > 崩してまで仕様変更を行うべきか議論の余地はある様に思います。
    この考察は、音楽を表現する文法がどうあるべきかという
    本質的な命題を提示している様に思えます。
    私が文法を考えるとき、
    ・入力の簡便性
    ・指定の木目細かさ
    という2つの背反する要素のバランス点を強く意識しています。

    例えば今回の例では、
    フィンガー単位の&にすることで、より木目細かい指定が可能となります。
    あるフィンガーは連結するも、同一タイミングの他のフィンガーは連結しない
    といった指定が出来るようになるからです。

    しかし反面、すべてのフィンガーを接続したかったら
    同音程の音を1つのフィンガーに集めたり、
    連結タイミングですべてのフィンガーに&を付けたりしなければなりません。
    つまり入力の簡便性が損なわれます。

    このような背反する事象の選択決断の際に私が使用する指標は
    「出現頻度」と「可読性」です。
    定量的な根拠はありませんが、体感的に私は
    (B)連結&の対象をフィンガー内に留めるという仕様
    を推すべきだろうと考えています。

    ●木下さま[5163]
    >> (A)和音内の連結&解釈の新仕様
    >> (B)連結&の対象をフィンガー内に留めるという仕様
    >> (C)pqスタッカートに対して非依存の連結を行うという仕様

    > (A)
    > []内の連結が/などで選択的に排除される仕様に対して,
    > 兎に角まとめて連結したり或いは連結したい音を明示的に表現するなどを
    > 選択できるV5.23の仕様が好みです。
    ご賛同ありがとうございます。

    > ただ仕様の差が嗜好程度と思われるのに記述の変更が大きいのが気になる所です。
    (B)や(C)は、その記述が意図的なのか否か判断しにくいので、かなり難しいのですが、
    逆に(A)は変換ルールが明確なので、機械的な変換ソフトを作れる可能性があります。
    もしニーズがあれば開発し、ご提供しても良いと思っています。
記事No.5141 のレス / 関連記事表示
削除チェック/

No.5167/● Muse大賞2007 ノミネート ●
■投稿者/ 開発者 -(2007/11/02(Fri) 19:58:03)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    恒例の、Muse大賞2007のノミネート・リストを発表致しました。
    本サイトメニュー[Muse大賞2007]をクリックして下さい。
    リストからデータへのリンクも張られています。

    今年は、昨年より4曲ダウンしましたが、
    それでも62曲もの作品がノミネートされました。
    皆さん、一年間ありがとうございました。

    ※この一年で複数の殿堂入りを果たしたデータに関しましては、
     私の感性にて、1曲を選考させていただきました。(苦しみました)笑
     もちろん、制作者の意向を尊重したいと思います。
     賞の分類も含め、大賞選考期日(2007.12.28)までにご一報頂ければ、
     変更いたしますのでお気軽にお知らせ下さい。

    なお、Muse大賞の詳細に関しましては、
    下記、MuseWikiをご覧下さい。

    http://tomokusaba.bne.jp/MuseWiki/index.php?Muse%C2%E7%BE%DE

    なお、今回より各賞のカテゴリー副題を少々変更いたしました。
    各カテゴリー作品数の均等化と、分類の一意性を図るためです。

    <変更内容>
    ・エラトー賞(ソロ)→(ソロ系)
     純粋なソロだけでなく、比較的楽器パートの少ないデータも含めることとした。
    ・タレイア賞(ユーモア)→(激情)
     しっとりとしたメルポメーネ賞(感涙)に対して、メリハリのある曲想分類とした。
     それに伴い、ユーモアセンスのあるものはテルプシコラ賞(演出)に含めることとした。
親記事 / 関連記事表示
削除チェック/

No.5168/>> Muse(V5.2)連結&仕様Fix宣言。 <<
■投稿者/ 開発者 -(2007/11/03(Sat) 23:21:27)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    掲示板[5164]にて予告いたしました、掲題の件についてです。
    多くの方々のご意見を頂き、また私としても多量データの互換検証を
    実施させていただきました。

    その後、少数の方々ではありますが、
    新仕様OKの意志を受け取りました。

    (A)和音内の連結&解釈の新仕様
    (B)連結&の対象をフィンガー内に留めるという仕様
    (C)pqスタッカートに対して非依存の連結を行うという仕様
    の3仕様に関して、
    すべからく新仕様にてFixすることをここに宣言いたします。

    本件に関して、情報の通知が行き届いておらず、
    再度、何らかの支障を感じられる方がおられましたら、
    どうぞお気軽にご意見下さい。
    基本的に、今後仕様をぐらつかせることはしないつもりですが、
    知恵を絞って、誠実に対応策を検討しようと思っております。

    今後ともMuseの世界の活性化と、華麗なる発展に向けて、
    ご協力ほど、よろしくお願いいたします。
親記事 / 関連記事表示
削除チェック/

No.5169/albuMuse αテスター募集
■投稿者/ るう -(2007/11/09(Fri) 22:58:47)
□U R L/http://mixi.jp/view_community.pl?id=1377389

    こんばんは、Muse関連ソフト制作者のるうです。

    先日の第4回MuseOFF会にて話が持ち上がったMuse用アルバム編集ソフト、albuMuseのαテスターを、会員制SNSサイトmixiにて募集中です。
    mixi会員の方でテスト参加希望者の方がいらっしゃいましたら、是非Museコミュに足を運んでみて下さい。

    なお、αテスターの方には以下の特典(?)があります。

    ・いち早くalbuMuseを使える
    ・今なら要望出したい放題(通るかどうかは別問題)
    ・優越感に浸れる

    参加希望や要望などは、全てmixi上で受け付けています。
    mixi会員ではないけれどテストに参加したい方がいるようでしたら、私の方から招待メールをお送りしますのでご連絡下さい。
    よろしくお願いします。
親記事 / 関連記事表示
削除チェック/

No.5170/S-YXGについて
■投稿者/ 境 -(2007/11/13(Tue) 00:47:01)
□U R L/http://mixi.jp/view_community.pl?id=1377389

    同じ音源のハズなのに、日によって残響のかかり具合が違うように聞こえます。
    以前はこのようなことは多分なかったと思うのですが、
    そのときの演奏と比べると残響がひどいときの方が異常であるように思われます。
    現在同時発音数が多い曲を打ち込んでいるのですが、
    発症したときはそこで音が途切れ途切れになり困っています。(正常時はふつうに演奏されます)
    多分Museの欠陥ではないと思うのですが……
    原因が分かる方は教えてください。
親記事 / 関連記事表示
削除チェック/

No.5171/Re[1]: S-YXGについて
■投稿者/  : -(2007/11/13(Tue) 04:40:13)
□U R L/http://mixi.jp/view_community.pl?id=1377389

    XGリセットしてますか?
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5174/Re[2]: S-YXGについて
■投稿者/ 境 -(2007/11/14(Wed) 00:49:11)
□U R L/http://mixi.jp/view_community.pl?id=1377389

    皆さん、親切な回答をありがとうございます。

    XGリセットはかけています。
    よって、ROOMコマンドは使用していません。また、FIXにも印は入っていませんでした。
    ちなみに、XGリセットをとってみても同じような症状が見られます。
    同時発音数は128音に設定してあります。ですので、症状が出ていないときはふつうに演奏されますし、発症時でも同時発音数が64音のAC-XGよりは音が出ます。
    また、症状が出ているときは、全てのデータで同じような現象が起こります。
    再起動をすると、直っていたり、または逆に最初良かったのに悪くなっていたりします。変化がないこともあります。

    自分でも、いろいろと策は練ってみたのですが……
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5175/Re[3]: S-YXGについて
■投稿者/ MIZ -(2007/11/14(Wed) 20:19:05)
□U R L/http://picicon.hp.infoseek.co.jp/

    > 自分でも、いろいろと策は練ってみたのですが……

    ん〜。
    データ内容がわからないので、有効な対策になるかどうかはわかりませんが^^;

    もしかすると、データ冒頭のエクスクルーシブや各コントロール設定の完了が、
    (曲が始まるまでに)時間的に間に合っていないのかもしれません。
    設定完了までの時間稼ぎのために、
    冒頭1〜2小節ほど“カラ”の小節を挿入してみてはどうでしょうか。

    すでにそうしてあったならごめんなさい、なんですが^^;
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5176/Re[4]: S-YXGについて
■投稿者/ 境 -(2007/11/15(Thu) 00:39:48)
□U R L/http://picicon.hp.infoseek.co.jp/

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

    > 冒頭1〜2小節ほど“カラ”の小節を挿入してみてはどうでしょうか。
    それもやっています。
    ただし、最近は問題が顕著になる部分のみを繰り返し聴いているので、役だっていないのかもしれませんが。
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5172/Re[1]: S-YXGについて
■投稿者/ MIZ -(2007/11/13(Tue) 17:28:24)
□U R L/http://picicon.hp.infoseek.co.jp/

    > 同じ音源のハズなのに、日によって残響のかかり具合が違うように聞こえます。

    > 原因が分かる方は教えてください。

    機能メニュー「演奏会場の設定」で、
    “ FIX ”にチェックが入ったままになっていませんか?
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5173/Re: S-YXGについて
■投稿者/ 諸熊 -(2007/11/13(Tue) 18:08:20)
□U R L/http://picicon.hp.infoseek.co.jp/

    > 同じ音源のハズなのに、日によって残響のかかり具合が違うように聞こえます。
    > 以前はこのようなことは多分なかったと思うのですが、
    > そのときの演奏と比べると残響がひどいときの方が異常であるように思われます。
    *ROOMの設定値が異常であるか、X91=127とか入れているか、GSリセットオフにした後の記述が適切でないかの
    どれかがあるのだと思います。もしかして、レジストリとか影響しましたっけ?
    *ROOM"R(4,0,127,127,0,0)"
    などとすると、残響が莫大になりますし、ディレイ系の設定を使うと怪しいです。
     GMシステムオンやGSリセットを消した場合、残響が思ったより分厚くなるようです。
    *DATA ""
    とだけ記述した場合、初期化がされていないMidiができるので、直前の演奏状況が引き継がれ、
    結果的におかしな演奏になる場合もあります。
     同時発音数は何音でしょうか?初期状態のS-YXG50は確か、32音だったはずです。
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5177/Re[1]: S-YXGについて
■投稿者/ 開発者 -(2007/11/15(Thu) 10:15:42)
□U R L/http://picicon.hp.infoseek.co.jp/

    > そのときの演奏と比べると残響がひどいときの方が異常であるように思われます。
    > 発症したときはそこで音が途切れ途切れになり困っています。(正常時はふつうに演奏されます)
    > 原因が分かる方は教えてください。
    ペダルYを使用していますか?
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5178/Re[2]: S-YXGについて
■投稿者/ 境 -(2007/11/15(Thu) 20:21:17)
□U R L/http://picicon.hp.infoseek.co.jp/

    > ペダルYを使用していますか?
    使用していますが……
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5179/Re[3]: S-YXGについて
■投稿者/ 開発者 -(2007/11/15(Thu) 23:28:03)
□U R L/http://picicon.hp.infoseek.co.jp/

    >>ペダルYを使用していますか?
    > 使用していますが……
    ペダルを踏みっぱなしにしているメンバーがあると出現する症状のように思えました。
    ペダルは発音している音に対して効果しますので、演奏開始ポイントにより
    残響の係り具合が微妙に変わってしまいます。
    (これはMIDI仕様でMuseでは制御できません)
    今回の症状と符合するので、ペダルではないかと推察した次第です。
    ペダルか否かを特定するために、お手数ですが
    一度 Y1 をすべて !Y1! に置換して頂けますか?
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5180/Re[4]: S-YXGについて
■投稿者/ 境 -(2007/11/16(Fri) 21:49:17)
□U R L/http://picicon.hp.infoseek.co.jp/

    > 一度 Y1 をすべて !Y1! に置換して頂けますか?
    置き換えてみました。
    直ったには直ったのですが、まともな演奏になっていません。

    Y1をつけたままでも、調子の良いときにはうまくいくのですが……
    勿論、定期的に踏み換えるようにもしてます。

    やはり、ペダルを使わないようにするほかはないのでしょうか……
記事No.5170 のレス / 関連記事表示
削除チェック/

No.5181/Re[5]: S-YXGについて
■投稿者/ 開発者 -(2007/11/16(Fri) 22:41:34)
□U R L/http://picicon.hp.infoseek.co.jp/

    > 置き換えてみました。
    > 直ったには直ったのですが、まともな演奏になっていません。
    問題をペダルに特定するために実験してもらいました。
    Y1 を !Y1! にすることが、最終的な修正案ではありませんので、
    ご安心ください。

    > やはり、ペダルを使わないようにするほかはないのでしょうか……
    問題がペダル Y1 にあることが判明した今、
    ペダルを使用した状態で、正常な演奏になるよう修正できると思います。

    推測の域を出ていませんが、Y1やY0 の記述の仕方にちょっとした誤解があり、
    Y1やY0の指定が他のメンバーにも効いてしまっているのではないかと思います。
    (もし、先刻ご承知の内容であったら、ご容赦ください)

    Readme.txtの "(2-4) メンバー単位に指定する値" の末尾を参照してください。

    ; ■■■ 重要 ■■■
    ; なおメンバー属性が反映されるメンバーは、それが挟み込まれるフィンガーには直
    ; 接関係はなく、単にタイミングを指定するという意味があるだけです。以下の例は、
    ; #A0フィンガーで音量指定されていますが、それが反映するメンバーはAメンバー
    ; ではなく、直前のメンバー宣言によるBCDの3メンバーとなります。
    ;
    ; @BCD
    ; #A0 d m s V80 d r m V90 d f l V120 d
    ;

    この例では音量 V で説明していますが、ペダル Y も同様のメンバー属性です。
    Y1 や Y0 を書く際、@Y1 @Y0 のように必ずアットマークを添えることで、
    記述ミスを避けることができます。

    もしこの点にお気づきで無い場合、これをお試し頂ければ直る可能性大です。
    逆に、上記は既知の内容であり、既に上記を考慮した記述をしている場合、
    残念ながら、現時点では確信の持てる解決策が思いつきません。
    (ペダル関係で何か別の原因があるはずだとは思うのですが)
    Y1 踏み換えの周期をもっと短くするしかもしれません・・・。
記事No.5170 のレス / 関連記事表示
削除チェック/


パスワード/

(ダウンロード後、拡張子を .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] [66] [67] [68] [69] [70] [71] [72] [73]

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

- Child Tree -

Muse