Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ1 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1474件 (981-1000 を表示) / 全ページ数 / [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.5490/Re[6]: ↑↑↑ V5.33 リリース
■投稿者/ BnKayak -(2008/03/04(Tue) 16:13:30)
□U R L/http://ameblo.jp/bnkayak/

    > 3月4日修正
    > 　番号付近のみに反応するようにしたんですね。それならば問題なく動きます。

    この件につきましては了解しました。今までは任意の小節線上を
    右クリックしていました。

    マニュアルのハ音記号 → ヘ音記号の件、よろしくお願いします。＞開発者さま。
記事No.5478 のレス / 関連記事表示
削除チェック/

No.5492/誤植ご指摘のお礼
■投稿者/ 開発者 -(2008/03/04(Tue) 21:56:20)
□U R L/http://ameblo.jp/bnkayak/

    BnKayakさん
    > それと、マニュアルの482行、「ト音・ハ音の大譜表」は「ト音・へ音の
    > 大譜表」ではないかと思います。

    ありがとうございます！
    こういったご指摘を頂けることで、Museの品質が着実に向上いたします。
    次回のリリースで修正反映いたします。

    それにしても人間って、過去の常識や経験に照らし合わせ、
    無意識に脳内で、誤植を変換修正してしまうのですねぇ〜。
    なかなか、間違えに気づきません。(苦笑)
    その意味でも、今回のご指摘、
    BnKayakさんに心から感謝いたします。
記事No.5478 のレス / 関連記事表示
削除チェック/

No.5491/譜面モニタの小節線移動について
■投稿者/ 開発者 -(2008/03/04(Tue) 21:55:44)
□U R L/http://ameblo.jp/bnkayak/

    BnKayak さん、H.N.WPKIDSさん、
    掲題の件についての書き込みありがとうございます。

    > 3月4日修正
    > 番号付近のみに反応するようにしたんですね。それならば問題なく動きます。

    その通りです。
    今回障害対応に便乗して、敢えてこの仕様に変更しました。

    私自身Musingの際、譜面モニタのマウスによるスクロールを頻繁にするのですが、
    ガサツな性格ゆえ、思わず小節線をグリップしてしまいイライラする事が多かったのです。
    考えてみれば、小節線移動の頻度はスクロールに比べると桁違いに少なく、
    しかも操作のセンシビリティ感も異なります。
    優れたインターフェースは、操作の感度レベルを意識しているものが多いです。
    大雑把な操作を常とする場合は、その反応エリアを大きくし、
    繊細な操作を必要とするものは、反応エリアを小さくします。

    以上のような根拠から今回、
    小節線移動の反応エリアを小節番号付近に限定することにしました。
記事No.5478 のレス / 関連記事表示
削除チェック/

No.5485/質問です
■投稿者/ PT2K -(2008/03/03(Mon) 14:28:38)
□U R L/http://ameblo.jp/bnkayak/

    d *TEXT"!" r

    はエラーになりませんが、

    d ! *TEXT"!" r

    はエラーになりますよね（d " r と解釈される）
    クォーテーションよりブロックコメントの方が優先度が高いからだと思いますが、
    これで引っかかって苦労された方って、いらっしゃらないんでしょうか？

    その他、
    d ! *TEXT";!" r
    だとうまくいくのも、個人的には（理屈はわかるけど）いまいちわかりにくいところ

    私見ですが、クォーテーションの中のエクスクラメーションマークやセミコロンは無視してしまう方が、
    データのデバッグが楽になるのでは？ と思います
    いかがでしょうか？
親記事 / 関連記事表示
削除チェック/

No.5486/Re[1]: 質問です
■投稿者/ Pascal -(2008/03/03(Mon) 17:26:37)
□U R L/http://ameblo.jp/bnkayak/

    >>d *TEXT"!" r

    「常にブロックコメントがクォーテーションより優先される」ならば
    これは「d *TEXT"」(!以後はコメントになる)と解釈されてエラーになるはずですね。
    !は、ブロックコメント開始のときはクォーテーションの内か外かを考慮しているが、終了のときはそれを考慮していない、ということでしょうか。

    コメント開始と終了のときの解釈を揃えた方が、文法としては一貫します。
    開始のときも終了のときも「クォーテーション内の!は無視」とすると、
    クォーテーションの内か外かを気にしながら終了の!を検索する必要がありますが、
    クォーテーション内で!が自由に使えますね。
記事No.5485 のレス / 関連記事表示
削除チェック/

No.5487/Re[2]: 質問です
■投稿者/ るう -(2008/03/04(Tue) 00:10:55)
□U R L/http://ameblo.jp/bnkayak/

    > >>d *TEXT"!" r
    >
    > 「常にブロックコメントがクォーテーションより優先される」ならば
    > これは「d *TEXT"」(!以後はコメントになる)と解釈されてエラーになるはずですね。
    > !は、ブロックコメント開始のときはクォーテーションの内か外かを考慮しているが、終了のときはそれを考慮していない、ということでしょうか。
    しかしそれだと、次のような場合にどうするか悩ましいところです。

    ! わざと"1コだけ !

    ちなみにC言語のコンパイラでは、

    /* " */ " … クォーテーションが閉じていないエラー
    " /* " */ … コメントの開始がないエラー

    となり、現状のMuseと同様の処理になっているようです。
記事No.5485 のレス / 関連記事表示
削除チェック/

No.5493/ダブルコーテーションとセミコロン＆ビックリの関係仕様について
■投稿者/ 開発者 -(2008/03/04(Tue) 21:57:31)
□U R L/http://ameblo.jp/bnkayak/

    PT2Kさん、Pascalさん、るうさん
    掲題の件に付き、動議ありがとうございます。

    本件に関しては、かなり以前からこの仕様で落ち着いてはいますが、
    私自身、どうも座りが悪い解釈だと感じていました。
    そこで今回の動議をきっかけに、本掲示板にて仕様の検討会を開催したいと思います。

    皆さんの「こういう解釈をして欲しいなぁ〜」という思いを、
    どしどし書き込んでいただき、１つの落着点を見出したいと思います。
    そして、それを次回の改版に反映できたらと考えています。

    多少互換性が崩れることが予想されますが、
    コメント部分の記述ですので、大勢に影響は無いだろうと楽観しています。

    また、
    ダブルコーテーションをダブルコーテーション内に記述するための
    エスケープシーケンスなども本件に伴い議論の範疇にして結構です。

    ぜひ、活発な議論をお願いいたします。
記事No.5485 のレス / 関連記事表示
削除チェック/

No.5494/Re[4]: ダブルコーテーションとセミコロン＆ビックリの関係仕様について
■投稿者/ るう -(2008/03/05(Wed) 00:44:52)
□U R L/http://ameblo.jp/bnkayak/

    ダブルクォーテーションとコメントの関係についてはこのままでも良いと思います。
    コマンド中に!のあるコードをコメントアウトしたい場合、折角!!〜!!!!!!!!も使えるのだからそれを使えばいいわけで。

    > ダブルコーテーションをダブルコーテーション内に記述するための
    > エスケープシーケンスなども本件に伴い議論の範疇にして結構です。
    C言語に準じて\"というのも考えましたが、そうすると*WAVEコマンドの内の\を全て\\に変えなければならないので非常に致命的ですね。
    VBやC#(の@""文字列)では\は普通に解釈し、""を1つの"に置換するという文法になっています。Museでもこれを採用するのはいかがでしょう？

    あとあるといいなと思うのは、Unicode文字への対応ですね。ハートなど、Unicode文字の中にも需要の高いものは多いと思います。
    VBの文字列解釈では\xuuuuのようなエスケープシーケンスが使えない代わり、ソースコード自体をUnicodeで記述することで直接Unicode文字を扱えます。
    Muse自体が、ShiftJIS・UTF-16BE・UTF-16LE・UTF-8の4種類(メモ帳で扱える文字コード)に対応してしまうというのはいかがでしょうか？
    その際は、文字コードを明示的に指定するコマンドを用意しておくとよいかと考えます。
記事No.5485 のレス / 関連記事表示
削除チェック/

No.5495/Re[5]: ダブルコーテーションとセミコロン＆ビックリの関係仕様について
■投稿者/ PT2K -(2008/03/05(Wed) 18:02:36)
□U R L/http://ameblo.jp/bnkayak/

    > Muse自体が、ShiftJIS・UTF-16BE・UTF-16LE・UTF-8の4種類(メモ帳で扱える文字コード)に対応してしまうというのはいかがでしょうか？
    > その際は、文字コードを明示的に指定するコマンドを用意しておくとよいかと考えます。

    UTF-16（BE/LE）は、先頭から読んでいった場合に、Shift-JIS と明確に区別できるのでしょうか？
    つまり、文字コードを指定するコマンドに辿り着く前に Muse が音をあげちゃうんじゃないか、心配です
    UTF-16（BE/LE）は UTF-16 と違って BOM が使えないので……
    私、UTF-16 は全然詳しくないので、この辺間違ってたらごめんなさい

    UTF-8 は 0x00〜0x7F は ASCII と同じなので、
    「*CODE コマンドは全角文字が現れる前に記述しなければならない」という制限を加えれば、
    あとは、コード変換の問題だけですから、実装は比較的やりやすいかも
    Shift-JIS <-> UTF-8 の変換テーブルは、拙作 qmus や DendoPlayer でも使っているので、
    よかったら、ソースを見てみて下さい # と宣伝してみる f(^^
記事No.5485 のレス / 関連記事表示
削除チェック/

No.5496/Re[6]: ダブルコーテーションとセミコロン＆ビックリの関係仕様について
■投稿者/ るう -(2008/03/06(Thu) 08:33:52)
□U R L/http://ameblo.jp/bnkayak/

    > UTF-16（BE/LE）は、先頭から読んでいった場合に、Shift-JIS と明確に区別できるのでしょうか？
    > つまり、文字コードを指定するコマンドに辿り着く前に Muse が音をあげちゃうんじゃないか、心配です
    > UTF-16（BE/LE）は UTF-16 と違って BOM が使えないので……
    > 私、UTF-16 は全然詳しくないので、この辺間違ってたらごめんなさい
    UTF-16のBOMは0xFEFFですので、これをチェックすれば大丈夫です。また1文字目が半角カナ以外の半角文字であれば、BOMがなくても必ず0x00が1バイト目(BE)か2バイト目(LE)に来るので、これを見て判別することもできます。

    あと、調べればファイルの文字コードを自動判別するライブラリも結構あるかと。
記事No.5485 のレス / 関連記事表示
削除チェック/

No.5435/殿堂チャート
■投稿者/ くさば -(2008/02/01(Fri) 00:06:50)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    殿堂チャート2007年度版を更新しました。

    これは、集計期間が2007年2月〜2008年1月のものです。
    1年分の集計ということでMuser歴が長い人にも短い人にも平等に上位に食い込むチャンスがあります。
親記事 / 関連記事表示
削除チェック/

No.5437/Re[1]: 殿堂チャート
■投稿者/ くさば -(2008/02/01(Fri) 10:10:20)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#y4e2258c

    殿堂チャート2008年2月1日版を更新しました。

    集計期間は全期間です。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5438/Re[2]: 殿堂チャート
■投稿者/ 開発者 -(2008/02/02(Sat) 10:42:55)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#y4e2258c

    > 殿堂チャート2008年2月1日版を更新しました。
    >
    > 集計期間は全期間です。
    ごくろうさまです。
    楽しく拝見しました。ありがとうございます。

    一つの要望ですが、全集計統計、
    例えば、全登録曲数とか、全登録者数とか、全演奏時間とか
    が集約されたページがあると更に興味が湧きますね。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5439/Re[3]: 殿堂チャート
■投稿者/ くさば -(2008/02/02(Sat) 11:21:27)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    > 一つの要望ですが、全集計統計、
    > 例えば、全登録曲数とか、全登録者数とか、全演奏時間とか
    > が集約されたページがあると更に興味が湧きますね。

    まあ、集計は簡単ですね。
    現在の状況は以下の通りです。

    全登録曲数：2361曲
    全登録者数：451人
    全演奏時間：295時間50分56秒

    そういえば、メンバー数をデータとして登録しておきながら集計で使ってないんだよな……。
    殿堂チャートを集計するためのデータは現在すべてOracle 10g XEに入っています。なので、SQLでできることはやろうと思えばできてしまいます。
    ただ、データとしてEXCELに貼り付けるまではいいのですが整形するのに一番時間がかかってしまうというところが問題点。
    EXCELで整形後、JustSystemのPDF CreaterというのでPDFにしています。

    何かうまい方法はないだろうかと思う今日この頃。

    一つ考えてある手はJavaでJDBC経由でSQL発行＆データ取得してiTextというのでPDF出力というのも考えていたり……。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5440/Re[4]: 殿堂チャート
■投稿者/ 開発者 -(2008/02/02(Sat) 12:58:08)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    > そういえば、メンバー数をデータとして登録しておきながら集計で使ってないんだよな……。
    「何を」集計したり分析したりするかが肝だと思います。
    例えば、
    「平均何日間で１曲が殿堂登録される換算となるか」とか
    「殿堂における１曲あたりの平均ファイルサイズ」とか
    この辺は、皆さんに分析項目を公募しても面白いかもしれませんね。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5441/Re[5]: 殿堂チャート
■投稿者/ くさば -(2008/02/02(Sat) 17:34:15)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    > この辺は、皆さんに分析項目を公募しても面白いかもしれませんね。

    いいですね。
    とりあえず、分析項目を募集してみましょう。
    いや、取り入れるかどうかは別問題ですよと予防線。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5442/Re[6]: 殿堂チャート
■投稿者/ Pascal -(2008/02/03(Sun) 21:43:01)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    どこかに既に記載されていたら申し訳ないのですが、

    これまでの、歴代全museファイルの
    (圧縮前)ファイルサイズはどのくらいでしょうか。

    ミューズ・コミュニティの広がりと、皆さんによって入力された
    ひとつひとつの音符、文字の連なりが感じられるのではないでしょうか。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5443/Re[7]: 殿堂チャート
■投稿者/ くさば -(2008/02/04(Mon) 21:46:10)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    > これまでの、歴代全museファイルの
    > (圧縮前)ファイルサイズはどのくらいでしょうか。

    圧縮前はデータがないのでわかりません。
    すでに入手不能になっている分もありますし……。

    圧縮後のファイルサイズは30991504バイトです。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5444/Re[7]: 殿堂チャート
■投稿者/ 開発者 -(2008/02/05(Tue) 00:08:01)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#j328db44

    > これまでの、歴代全museファイルの
    > (圧縮前)ファイルサイズはどのくらいでしょうか。
    「殿堂」チャートという主旨からは外れますが、
    好学のためにお伝えしておきます。

    殿堂落ち作品も含めて、
    とにかく私が皆さんから受け取ったデータ（私自身のデータも含まれます）笑
    の総計は、
    161,897,725byte です。

    同梱されていたmp3やwavを除く、
    純粋なmuseデータのみの総計です。
    尚、1999/02/22のタイムスタンプが最古です。
記事No.5435 のレス / 関連記事表示
削除チェック/

No.5497/Re[1]: 殿堂チャート
■投稿者/ くさば -(2008/03/06(Thu) 17:32:35)
□U R L/http://tomokusaba.bne.jp/MuseWiki/index.php?%C5%C2%C6%B2%A5%C1%A5%E3%A1%BC%A5%C8#cbad7b13

    殿堂チャート2008年3月5日版を更新しました。
記事No.5435 のレス / 関連記事表示
削除チェック/

パスワード/

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