Ｍｕｓｅ掲示板

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

過去ログ表示

過去ログ1 を表示

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

過去ログ検索は 検索 より行えます。
記事数 / 1474件 (741-760 を表示) / 全ページ数 / [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.5249/Xmasプレゼント？
■投稿者/ るう -(2007/12/25(Tue) 08:11:15)
□U R L/http://www60.tok2.com/home/rew/dl/albumuse.lzh

    メリークリスマス！

    本日の私からのXmasプレゼントはalbuMuseのβ版です。
    どうぞご賞味あれ。

    【必要動作環境】Microsoft .NET Framework 2.0
親記事 / 関連記事表示
削除チェック/

No.5227/殿堂へ投稿作品に音源別データの必要性
■投稿者/ まるみぎ -(2007/12/22(Sat) 21:42:36)
□U R L/http://www60.tok2.com/home/rew/dl/albumuse.lzh

    　正直、詳しくないというか、ほとんど知らないので教えてください。

    　Muse殿堂への審査依頼データに、たまに"hoge_88pro.mus"など音源依存というか推奨音源データのような形で、同じ作品でも複数ファイルを送って来てくれる人がいます。
    GS/XGの違いなど、Museのようにmidi音源を扱う場合、こういったことが本来必要なのでしょうか？
    "hoge_88pro.mus" ← こういうのなし！
    　　　　　　　　　　としたら、わかる人から言わせれば困る問題なのでしょうか？
親記事 / 関連記事表示
削除チェック/

No.5229/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ MIZ -(2007/12/23(Sun) 12:10:28)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > Muse殿堂への審査依頼データに、たまに"hoge_88pro.mus"など音源依存というか推奨音源データのような形で、同じ作品でも複数ファイルを送って来てくれる人がいます。
    > GS/XGの違いなど、Museのようにmidi音源を扱う場合、こういったことが本来必要なのでしょうか？

    えーと、
    どちらに賛成とか反対とかはまだ置いておいて(汗)、とりあえず自分なりに思ったコトを書きなぐっていきます^^;

    音源依存のデータを含めた複数ファイルがあるのは、
    愛着ある音源の機能を最大限に引き出したいという意味で *DATA コマンドが書かれているためと思うんですが。

    ちなみにワタシの場合は、 GS・XG 両方に効果するように *DATAコマンド（エクスクルーシブメッセージ）をひとつのデータ内に記述しています（MIDI 規格ではエクスクルーシブメッセージのメーカー ID やアドレスのダブリはありえないようになっているハズ）
    なので、一応どの音源でもそれなりに聴けるようにしているつもりではあります^^;

    でも別社の規格のエクスクルーシブをひとつのデータ内に混在させるのは、音源に対して実は危険なコトなのかもしれませんよね……。
    前述のとおり、MIDI 規格ではエクスクルーシブメッセージのメーカー ID やアドレスのダブリはありえないようになっている“ハズ”ですが、アドレス記述のミスなどで音源がエラーを起こしたりの可能性が無いとははっきり言い切れません^^;;;
    そういう意味では、*DATA コマンドを使った場合には、再生音源別にファイルを作るのは良い対策と言えると思います。

    ……ただやはり出来上がりが MIDI データである以上（エクスクルーシブだけでなく音色やコントロールも含め）自分と同じ環境で再生されるコトは少ないと考えないといけません(汗)　どんなにがんばって *DATA コマンドを記述したところで、再生時にはエフェクトをまったく無視してしまう音源もありますしねぇ（某 MSGS とか）^^;
    音源依存になってしまってるデータは、その音源を持ってない方にはほとんど効果がでません(汗)　そうなると、音源ごとに複数ファイルがあっても意味無く感じてしまう方が出てしまうのも解ります。
    （「再生してくださる方の環境で“たまたま”うまく効果が出てくれればそれでヨシ」と割り切って考えるのがいいのかも）^^;

    ということで、（両側に納得できてしまうので ^^;）まだどっちつかずな状態です
    まとまらないままに書いてしまってすみませんでした(汗)

    > "hoge_88pro.mus" ← こういうのなし！
    ……やはりサーバの容量圧迫が理由なのでしょうか。
    （過去ドでかい WAVE を送りつけてしまったワタシは反省するべきか）^^;
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5230/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 諸熊 -(2007/12/23(Sun) 12:56:03)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > 　Muse殿堂への審査依頼データに、たまに"hoge_88pro.mus"など音源依存というか推奨音源データのような形で、同じ作品でも複数ファイルを送って来てくれる人がいます。
    > GS/XGの違いなど、Museのようにmidi音源を扱う場合、こういったことが本来必要なのでしょうか？
    　私は最近その一人ですね。GM・GS・XG・MSGS対応で分けて作っています。
    私がそうしている理由は、やっぱりできるだけ多くの音源に対応して、最適な環境で聞いてもらうためです。
    また、ソフトを作る時にMidiを盛り込むのですが、いろいろな音源に対応しておかないと、音が出ないとか変な音が出るなどといろいろ言われてしまいまして。
    そういう理由から、最近はもっぱら、データそのものを分けるようにしています。
    　特に、GM2のエクスクルーシブを含んだデータを、MSGSにて再生させると、私がそうしたくなる理由がわかるかもしれません。
    　もし、サーバへの圧迫が問題になるようでしたら、こちらでも何か考えます。
    　予断ですが、LZHよりCAB圧縮の方が、ファイルサイズが小さくなるようですが…
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5231/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ くさば -(2007/12/23(Sun) 13:52:33)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > "hoge_88pro.mus" ← こういうのなし！
    > 　　　　　　　　　　としたら、わかる人から言わせれば困る問題なのでしょうか？

    困ります。
    僕がSC-88Pro専用データとしているのはSC-88Pro以降のGS音源で採用されているEFXを使用しているデータをさします。そして、多くの場合OD1/OD2というエフェクトを使っているのですがこれは音色に大きな影響があります。
    これで、オーバードライブとかディストーションというエフェクトをかけているわけで、対応音源以外で聞くとオーバードライブギターがクリーンギターになってしまいます。
    また、EFXの仕様上コーラスやリバーブやら音量に至るまでの調整をEFXのパラメータで行うことになっています。
    さらに、最近のデータではNRPNの操作にしてもSC-88Pro専用ということでほかの音源を一切考慮しない調整でまさしくSC-88Pro以降でのみ好ましい音が出るようにしてあります。VSCなどのほかの音源で聞いた場合ドラムも変な音がするでしょう。

    一方で、誰もがSC-88ProとかSC-8850といった音源を持っているわけではないという現実を考え、S-YXG50とかVSCとかおそらくもっとも普及している音源に対しての最大公約数的データを用意しています。
    自分の中では妥協しまくりでとにかく手持ちのどの音源に対しても破綻なきように作っているつもりです。(MS GSに関しては無視してるかもしれない)

    自分のスタンスとしては、MIDIっていうのは元々音源依存のものでたまたま、GSとかXGとかいう規格に準拠しているからある程度の互換性があるというだけの話で、表現を追求しようとすれば音源に依存してしまうのは仕方ないと思います。

    また、*DATAに関しても危険といえば危険なもので、やり方によってVSCを落としてしまうことも現実に可能なわけで(VSCのバグですが)ほかの音源、ほかのやり方で同じようなことが起こらないとも限らないので自分的にはその音源にない仕様の*DATAは送るべきではないかなと思います。
    ハード音源においては特に特殊なエクスクルーシブメッセージで音源のファームウェアのアップデートでさえ可能になっているようで……MU128のアップデートもMIDIインターフェース経由でやりました。（たぶん流れているのはエクスクルーシブメッセージだよなあと想像)

    (ときどき殿堂データの中でも*DATAにエラーのあるデータがあったりして冷や汗もの。)
    エクスクルーシブメッセージって前半の音源固有のIDのところを無視すればアドレスとデータで成り立っており、前半部分でXG用のなのかGS用のなのかそれ以外なのかという判別はできるが、今の音源ってXGでもGSでもある程度解釈してしまって変なアドレスに変なデータを書き込まれた場合ってどんな挙動するかわかったものではなくそれこそ前述のVSCのようにWindows巻き添えの上落ちてしまうかもしれません。(VSCの場合はめちゃめちゃGSの範囲内といえるものであるが)

    また、アドレスによって書き込めるサイズというのが決められていてそのサイズを超えてデータを書いた場合、エラーガードが甘ければバッファオーバランのようなことがおきてしまうかもしれない。

    というのは極端な例であったが演奏する音源に規定されてない命令はなるべく送りたくないなということです。

    容量が問題であるならばLHAに代わりZIPあたりにした方が圧縮率は高めだと思います。Windows XP以降であるならばデフォルトで解凍が可能なことですし、殿堂データをダウンロードさせて解凍してMuseで演奏するということの敷居はアーカイバーを導入しなくてもよいという点で下がるかと思います。

    以上、まとまりのない思いでした。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5235/Re[2]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ PT2K -(2007/12/24(Mon) 02:05:17)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > 容量が問題であるならばLHAに代わりZIPあたりにした方が圧縮率は高めだと思います。Windows XP以降であるならばデフォルトで解凍が可能なことですし、殿堂データをダウンロードさせて解凍してMuseで演奏するということの敷居はアーカイバーを導入しなくてもよいという点で下がるかと思います。

    ZIP なら構いません
    CAB は反対です
    Linux（や UNIX）では、解凍はできますが、圧縮は（多分）できません
    MAC でも多分そうでしょう
    それに、CAB の圧縮率の高さはともかく、圧縮にかかる時間が莫迦にならないと思います
    Muse のデータは概して小さいファイルが多い（ほとんどが 1MB 以下）なので、ちょっとばかり圧縮率を上げても、クラスタサイズほどの差は出ないのではないでしょうか
    普及率が高く、プラットフォームを問わず利用でき、圧縮・解凍にあたって（特に まるみぎさんの）負荷が小さい形式を望みます
    # LZH のままでいいんじゃないの？ と思ったりして……
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5236/Re[3]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ PT2K -(2007/12/24(Mon) 02:17:22)
□U R L/http://plaza.rakuten.co.jp/musecon/

    連続投稿すみません、1点訂正
    > CAB は反対です
    > Linux（や UNIX）では、解凍はできますが、圧縮は（多分）できません
    > MAC でも多分そうでしょう
    Linux *では* 圧縮もできるようです
    ただし、広く普及している訳ではないようですし、他のプラットフォームに移植されてもいないようなので、結論は変わらず、ということで f(^^
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5238/Re[4]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 諸熊 -(2007/12/24(Mon) 13:56:25)
□U R L/http://plaza.rakuten.co.jp/musecon/

    　私が率直に感じた事を書きます。
    >>CAB は反対です
    >>Linux（や UNIX）では、解凍はできますが、圧縮は（多分）できません
    >>MAC でも多分そうでしょう
    > Linux *では* 圧縮もできるようです
    > ただし、広く普及している訳ではないようですし、他のプラットフォームに移植されてもいないようなので、結論は変わらず、ということで f(^^
    　私はOSの事についてはあまり詳しくなく、単に圧縮率だけ考えていたのですが、
    自分が使用しているソフトでLZHとCABのmusファイル郡を作ると、LZHは657KBに対し、CABでは352KBとなりました。
    格納ファイル数は332、元ファイル全てのサイズ合計は約2.98MBです。
    圧縮形式は、LZHがLH7、CABがLZX21でした。
    圧縮するものにもよると思うのですが、塵も積もれば山になりますし、どうでしょうか？
    　また、Muse自体はWindowsがメインの動作環境だと私は認識しているのですが、
    他のOSでも使用されているのならともかく、そうでなければ他のOSの事を考える妥当性は薄いようにも感じます。
    あと、CABはWindows上ではそのまま転回できますが、LZHは解凍ソフトが必要だと思います。
    でも確かに、圧縮速度はLZHに比べると遅いですし、圧縮環境なども大きな課題がありそうですね。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5239/Re[5]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ くさば -(2007/12/24(Mon) 15:57:12)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > 　また、Muse自体はWindowsがメインの動作環境だと私は認識しているのですが、
    > 他のOSでも使用されているのならともかく、そうでなければ他のOSの事を考える妥当性は薄いようにも感じます。

    少なくとも、PT2KさんはLinux上でMuseを動作させているようです。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5240/Re[6]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 諸熊 -(2007/12/24(Mon) 16:39:09)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > 少なくとも、PT2KさんはLinux上でMuseを動作させているようです。
    　あ、なるほどですか。動作しているのですね。これは失礼しました。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5241/Re[7]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ くさば -(2007/12/24(Mon) 16:48:01)
□U R L/http://plaza.rakuten.co.jp/musecon/

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

No.5242/Re[8]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 開発者 -(2007/12/24(Mon) 17:39:37)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > 需要があるかどうか不明ですが。
    需要あるようです。
    先日、kaguya(旧HN：輝傀鵺)さんからメールで問い合わせを受けました。
    もちろん、MuseWikiを紹介しておきました。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5232/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 開発者 -(2007/12/23(Sun) 15:30:07)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > midi音源を扱う場合、こういったことが本来必要なのでしょうか？
    > "hoge_88pro.mus" ← こういうのなし！
    > 　　　　　　　　　　としたら、わかる人から言わせれば困る問題なのでしょうか？
    もし、初期化部分だけの差異なら、マクロによる切替えデータで一元化してもらえると嬉しいですね。
    ただ、音源によって演奏コンテンツの仔細な味付けを変化させているとしたら、そこまでマクロで切り分けろというのは酷のような気がします。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5237/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 岡林 -(2007/12/24(Mon) 04:33:57)
□U R L/http://plaza.rakuten.co.jp/musecon/

    先だってのように中途半端に書き込みしたままこれなくなる可能性もあるので
    躊躇していたのですが…

    一応書きっぱなしになる可能性が高いことだけあらかじめご了承いただいた上で
    考えるところを書かせていただきます。

    まず、音源別データはある程度以上音楽表現にこだわる方にはやはり
    必要なことのように思います。エクスクルーシブなど使わなくても、
    ヴェロシティなどでさえ、音源が違えば全く出力が変わります。
    別音源で演奏されたデータを自分の構想した演奏と思われるのは、
    ある程度は仕方ないとしても、制作者としては非常に不本意なことですし、
    可能な限り多くの音源で聴かれるようにするというのは、既に制作者側の
    かなりの妥協ですから…

    それに、容量の問題だとしますと、どう考えてもデータの数や圧縮形式よりも
    バイナリデータを含むMuseデータの容量圧迫の方が大きいのではないでしょうか？
    特に非圧縮のwave形式ファイルを含むものは、確かめてはいませんが
    相当なものではないかと…　一応数理科学かじっている者として、
    オーダーの差には敏感になってしまいますので…　*.mus以外の
    ファイル容量制限、等の方がそういった意味では余程妥当な解決策ではないかな
    等と存じます。（前からちょっと気になっていたことです。）

    後はあまりに小さいファイルが個別にあると、ファイルシステムの問題で
    全ファイル容量以上にむやみに容量を食ってしまいますから、ブロードバンドの
    時代ですし、ある程度ファイルを１つにまとめて圧縮した方が効率がよいかな、
    とは思います。ランキングが利用できなくなってしまいますが…

    殿堂データ管理上の問題なのでしたら、的はずれな発言失礼しました。
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5244/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ ホドナール -(2007/12/24(Mon) 18:24:36)
□U R L/http://plaza.rakuten.co.jp/musecon/

    　皆様の専門的なお話になるほどと学ぶことが多いです。
    ＭＵＳＥ（ＭＩＤＩ）は奥が深いなとあらためて感じました。
    皆さま方の技術レベルの高さにちょっぴり羨ましさと深い憧憬の入り混じった気持ちです（＾＾；）

    そしてまたそのこととは別に

    　まるみぎ様、加藤様をはじめとして、数多くのＭＵＳＥデータを審査されている方々（委員会？）及び
    関係者の方々の日々の努力に、ささやかな一人のMuserとしてお礼を述べなければならないと思いました。

    　たとえ音楽芸術のためと言えども、あまりにも多くのそしてジャンルの様々な音楽データを聴いた上で、
    なおかつそこで殿堂入りさせるかどうかという苦渋の決断を１年間を通して、いえ、ＭＵＳＥ　ＷＯＲＬＤ　
    が始まって以来ずっと続けてこられたお仕事、とその時間的、精神的負担に対して、新参者の私としては
    あまりにも無知、無頓着にすぎていたのではないかと深く反省する思いです。

    　私もささやかながらいくつかＭＵＳＥ作品をこれまで応募させていただきましたが、少なからず差し替えや
    修正版を再応募してきたこともふまえ、その都度、審査委員会の方々の貴重なお時間を使わせていただいて
    もらったことに対して、遅まきながら心からお礼の言葉を述べさせていただきます。

    　そしてまた私だけでなくＭＵＳＥに関わる全ての方々が、ＭＵＳＥを通して音楽に触れている時間という
    ものが、人生にとって常に実り豊かなものであることを願ってやみません。

    　最後になりましたが
    　２００８年もＭＵＳＥ　ＷＯＲＬＤと皆さま方にとってよい年となりますように。
    　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
    　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　草々
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5245/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 雷鵬 -(2007/12/24(Mon) 22:42:12)
□U R L/http://plaza.rakuten.co.jp/musecon/

    どうも雷鵬です。
    いきなり出てきて失礼とは思いますが私見を述べたいと思います

    現在、自分の制作したものをMP3や動画にして発表することが珍しくなくなっています
    相手の環境に関わらず自分の意図する演奏を再現でき、音源による制約なども気にしなくて済みます
    ただ音に拘るだけなら、そっちの方が楽だし優れています
    多音源対応は、かなりの労力がいりますから(私は投げ出しました)

    話は変わりますが、私にとってMUSEはDTMの入り口でした。
    いろいろやってるうちに、MSGSでは足りなくなり音源を買い
    そのうちやりたいことがMUSEやDTM音源の枠内に収まらなくなり色んなものを使ってます
    「MUSEで何かをする」のが目的でなく、MUSEは目的(音楽製作)のための手段の一部となりました

    一方、MUSEは単なるシーケンサーではなく、テキストや譜面モニタなど素晴らしい機能(表現手段)がたくさんあります
    そういった動作画面まで含めて作品です。
    つまりMUSデータが作品であり単なるMIDI(音楽)とは異なります

    すみません結構考えたんですが、言いたいことが多すぎてうまくまとめれなくまりました
    音を求めるならMIDI規格は限界だけど、MUSEは使いたい
    その矛盾を努力で解決してる人たちの意を汲んで音源別データは残して欲しい
    そんなところでしょうか。

    長々とすみませんｍ(_ _)ｍ
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5247/Re[2]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ PT2K -(2007/12/25(Tue) 01:10:26)
□U R L/http://plaza.rakuten.co.jp/musecon/

    > (snip)MUSEは単なるシーケンサーではなく、テキストや譜面モニタなど素晴らしい機能(表現手段)がたくさんあります
    そして、何より、素晴らしい仲間達がいます
    数年前から私は Microsoft とは完全に決別して全面的に Linux に移行していますが、
    このコミュニティからは離れられませんでした

    Muse が MS Windows 専用というのは、もったいない、と思います
    Muse の思想は、今時の MS ユーザよりも 今時の UNIX ユーザにこそ適合するのでは？
    他のプラットフォームへの移植を（しつこくてすみません）強く希望する次第です
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5248/Re[3]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 雷鵬 -(2007/12/25(Tue) 03:10:42)
□U R L/http://plaza.rakuten.co.jp/musecon/

    PT2Kさんはじめまして

    例えばPT2Kさんの曲に対して……
    この曲がGS専用というのは、もったいない、と思います
    この曲は、GSよりも XG音源にこそ適合するのでは？
    他の音源への移植を強く希望する次第です

    と、要望が来たらどうされますか？

    私は、仕事ならともかく私用ならほぼ確実に断ります
    特に強い要望ならなおさらです
    調整なしの変換ぐらいならまだしも
    その要望(完全移植)を満たせるだけの(XG音源の)環境も技術もないからです


    昔、似たような頼みを安易に受けて嫌な思いをしたのと
    フリーソフトである以上、あまりしつこく要求するのもどうかと思いナマイキ言ってみました
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5250/Re[4]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ PT2K -(2007/12/25(Tue) 21:14:30)
□U R L/http://plaza.rakuten.co.jp/musecon/

    御指名ですので、拙いながら返答致したいと思います
    > 例えばPT2Kさんの曲に対して……
    > この曲がGS専用というのは、もったいない、と思います
    > この曲は、GSよりも XG音源にこそ適合するのでは？
    > 他の音源への移植を強く希望する次第です
    >
    > と、要望が来たらどうされますか？

    Muse は C 言語で記述されています
    そして開発者様は、元々 UNIX の経験もある方です
    だからこそ、Muse があるし、このコミュニティがあるのだと思っています
    え？ 前提と結論が解離しているって？
    そう思う方は、UNIX とフリーソフトウェア運動の歴史について、ちょこっと調べてみて下さいませ

    さて、ご質問への返答です
    Muse データは、テキストであり完全な可読性を備えています
    私のデータが XG やら GS やら（私のメイン環境は TiMidity++ + EAW patch）にこそ相応しい！
    と仰るのであれば、
    「あなた、XG 向けに私のデータを調整／改編して送って下さい。あなたと私の連名（共作）として公開しましょう！」
    と、お返事致します
    ソースがオープンになっているからこそできるコラボレーションです

    Muse については、何年か前から開発者様に、
    「オープンソース（できればフリーソフトウェア *1）にしましょう！！！」
    と、折りに触れてせっついてきた経緯があります
    その上での先の発言です
    ソースが手に入れば、*私が* Linux への移植を請け負う所存です
    こんな処で、回答になっていますでしょうか？

    *1 MS Windows の世界と、UNIX の世界では、「フリー（ソフト）ウェア」という言葉の意味する処がまるで異なります（無料という Free と、自由という Free）
記事No.5227 のレス / 関連記事表示
削除チェック/

No.5246/Re[1]: 殿堂へ投稿作品に音源別データの必要性
■投稿者/ 浅川 -(2007/12/25(Tue) 00:59:50)
□U R L/http://www.nns.ne.jp/pri/asakawa/asa/fumen_read/

    私が少し気になった部分を書いてみます。

    > 　Muse殿堂への審査依頼データに、たまに"hoge_88pro.mus"など音源依存というか推奨音源データのような形で、
    > 同じ作品でも複数ファイルを送って来てくれる人がいます。
    > GS/XGの違いなど、Museのようにmidi音源を扱う場合、こういったことが本来必要なのでしょうか？
    おそらくデータの安全性や、表現について考えると音源によって独立したデータにしたほうが良いのかもしれません。
    またこの掲示板に書込みをされる方々では
    > "hoge_88pro.mus" ← こういうのなし！
    より「あり！」の方がほとんどかと思います。

    ただ私としては、音源比較のためのデータにはしりすぎなければ...と少し気になりました。
    投稿されるものは、あくまでデータ作成者の一つの作品と考えると一つの音源（データ成作者がそれぞれで...）に絞ってもいいのかも
    しれませんが、複数の音源に（個別ですが）対応されているＭｕｓｅなので
    従来どおり単一ファイルでも利用者の責任上で...と言うことで処理できるものであれば
    「なし！」でも良いような気もします。

    私もどちらつかずで、参考にもならない内容ですみません。
記事No.5227 のレス / 関連記事表示
削除チェック/

パスワード/

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