【質問】ブロードバンド時代のＭＩＤＩ
1 ：名無しサンプリング＠48kHz：
ブロードバンドになって変わって欲しいと思うMIDI系
MIDIはその再生手段に個々の端末の状態が反映され
作者の意図としない状態がおおおうに生まれる。
であるからして、MIDIデータ＞端末＞MIDI音源Serverへ送信＞
デジタル再生＞端末へ返りスピーカーへという手段はできないものか。
Yamaha系、ローランド系の音源をServerでデコードしリアルタイムに
返送するのである。これで個人的には立派な音源を用意しなくても
いい。メーカーは多数の通信用セッションを処理できるように
多チャンネルServer用MIDI音源を開発するのです。
MIDIはその再生手段に個々の端末の状態が反映され
作者の意図としない状態がおおおうに生まれる。
であるからして、MIDIデータ＞端末＞MIDI音源Serverへ送信＞
デジタル再生＞端末へ返りスピーカーへという手段はできないものか。
Yamaha系、ローランド系の音源をServerでデコードしリアルタイムに
返送するのである。これで個人的には立派な音源を用意しなくても
いい。メーカーは多数の通信用セッションを処理できるように
多チャンネルServer用MIDI音源を開発するのです。
|
|
|
2 ：名無しサンプリング＠48kHz：03/12/16 09:53 ID:LwzPUkki
2
3 ：名無しサンプリング＠48kHz：03/12/16 09:55 ID:LwzPUkki
VSCでいいんじゃない？3
4 ：名無しサンプリング＠48kHz：03/12/16 09:57 ID:MESgEq28
キーワード：着眼点は良いけど、いくら回線が速くてもMIDIにはミリセカンドでの
オペレーションが必要なので厳しい
VoIPのようにISP同士でインターリンクのMIDI専用VPNでも作らないとな
http://pc.2ch.net/test/read.cgi/network/997496053/l50
オペレーションが必要なので厳しい
VoIPのようにISP同士でインターリンクのMIDI専用VPNでも作らないとな
http://pc.2ch.net/test/read.cgi/network/997496053/l50
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
>おおおうに生まれる
6 ：名無しサンプリング＠48kHz：03/12/16 10:07 ID:LwzPUkki
クライアント側に巨大な仮想音源データを置いてmidiだけ飛ばし、
相手側の同一の仮想音源をコントロール。
遅れは光の速度がある以上ある程度は仕方がないのでは？
相手側の同一の仮想音源をコントロール。
遅れは光の速度がある以上ある程度は仕方がないのでは？
7 ：名無しサンプリング＠48kHz：03/12/16 10:55 ID:QGfPdFqS
っかさー
まずは、MIDIがシリアルDATA通信だって事を考えろよ。新たに大量データ送信向けのプロトコルを構築しなおす必要があんだろ？
でも、イベント型だからね、パケット通信とかに向かないかもね。
しかし、ちゃんと標準化できれば利権はデカいよ。通信カラオケも格段に進化するし。
まずは、MIDIがシリアルDATA通信だって事を考えろよ。新たに大量データ送信向けのプロトコルを構築しなおす必要があんだろ？
でも、イベント型だからね、パケット通信とかに向かないかもね。
しかし、ちゃんと標準化できれば利権はデカいよ。通信カラオケも格段に進化するし。
8 ：名無しサンプリング＠48kHz：03/12/16 11:00 ID:MESgEq28
カラオケ利権でアジアジャック
音楽家はこれで生き残りましょう
音楽家はこれで生き残りましょう
9 ：名無しサンプリング＠48kHz：03/12/16 11:11 ID:QGfPdFqS
>>8
そう言われるとなんだかな〜って感じだけど。
携帯の着メロも、通信カラオケも、MIDIがベースだしね。
MIDI規格が制定された頃にはまったく想像もしてなかった使用方法がされている。
なぜか、唯一の音楽(演奏)データのディファクトスタンダードになってしまった。
さすがに、新しい規格は必要だとは思うよ。
ただ、MIDIで情報量が事足りているのも、また事実なんだけどｗ
そう言われるとなんだかな〜って感じだけど。
携帯の着メロも、通信カラオケも、MIDIがベースだしね。
MIDI規格が制定された頃にはまったく想像もしてなかった使用方法がされている。
なぜか、唯一の音楽(演奏)データのディファクトスタンダードになってしまった。
さすがに、新しい規格は必要だとは思うよ。
ただ、MIDIで情報量が事足りているのも、また事実なんだけどｗ
10 ：名無しサンプリング＠48kHz：03/12/16 11:34 ID:MESgEq28
「ローランド系の音源をServerでデコードしリアルタイムに返送」
この手法について論じて頂けませんでしょうか。課題点、問題点などなど。
この手法について論じて頂けませんでしょうか。課題点、問題点などなど。
11 ：名無しサンプリング＠48kHz：03/12/16 11:39 ID:QGfPdFqS
>>10
なんかのリサーチですか？
なんかのリサーチですか？
12 ：名無しサンプリング＠48kHz：03/12/16 11:54 ID:QGfPdFqS
ま‥ なんでもいいか。
SMF とか GX とかじゃ、不満だと言いたいのか？
問題点は技術面と、法制面に大別されるが。
1 の案だと、音源著作権みたいな新たな利権を生む可能性があり、これが、いいのか悪いのか‥って感じですね。
現状、シンセの音やサンプリングCDは、ロイアリティフリーなのが一般的なので、それに順ずるのか、準じないのか。
つまり、出力される物が出版権の範疇を超えてしまう可能性あると思うよ。
それより、新MIDI規格としては、フォルマントデータとかも扱える様な拡張とか、技術的にはそっちの方が興味あるな。
SMF とか GX とかじゃ、不満だと言いたいのか？
問題点は技術面と、法制面に大別されるが。
1 の案だと、音源著作権みたいな新たな利権を生む可能性があり、これが、いいのか悪いのか‥って感じですね。
現状、シンセの音やサンプリングCDは、ロイアリティフリーなのが一般的なので、それに順ずるのか、準じないのか。
つまり、出力される物が出版権の範疇を超えてしまう可能性あると思うよ。
それより、新MIDI規格としては、フォルマントデータとかも扱える様な拡張とか、技術的にはそっちの方が興味あるな。
13 ：名無しサンプリング＠48kHz：03/12/16 13:18 ID:UqO3TVyY
そのサーバー上のMIDI音源から
スピーカーに流れてくるデジタルデータは
44.1の16bit？それとも、もっとレート低い？高い？
どっちにしろ最初からWAVかMP3にしておくのと何も変わらないじゃん。
スピーカーに流れてくるデジタルデータは
44.1の16bit？それとも、もっとレート低い？高い？
どっちにしろ最初からWAVかMP3にしておくのと何も変わらないじゃん。
14 ：名無しサンプリング＠48kHz：03/12/16 13:30 ID:QGfPdFqS
>>13
元々 MIDI って規格自体、電子楽器を演奏する為のデータのプロトコロだからね。
それがたまたま、アナログ回線時代に通信カラオケ等の音楽配送目的で使われるようになっちゃった。
だから、本来 MIDI は、音色を再現する必要は無いんですよね。
それじゃ困るって、カラオケ屋や携帯屋は、自分達の都合の良いプロトコルを作って標準化すりゃいいんじゃないのかな？
別に、MIDI に拘る必要はない。
もし、カラオケ屋が"原盤権に抵触せずに"、よりリアルな音楽配送をしたいと思ってるなら、それは無理だと思われる。
元々 MIDI って規格自体、電子楽器を演奏する為のデータのプロトコロだからね。
それがたまたま、アナログ回線時代に通信カラオケ等の音楽配送目的で使われるようになっちゃった。
だから、本来 MIDI は、音色を再現する必要は無いんですよね。
それじゃ困るって、カラオケ屋や携帯屋は、自分達の都合の良いプロトコルを作って標準化すりゃいいんじゃないのかな？
別に、MIDI に拘る必要はない。
もし、カラオケ屋が"原盤権に抵触せずに"、よりリアルな音楽配送をしたいと思ってるなら、それは無理だと思われる。
15 ：名無しサンプリング＠48kHz：03/12/16 15:03 ID:QGfPdFqS
結局『Server用MIDI音源』ってのは、技術的に可能かもしれないけど。楽曲制作に必要な総ての音源をServerに仕込まないといけない。
じゃ、その音源の権利関係とかロイアリティとかをどうするかって事なんだろうと思うよ。
もちろん配送なら課金も可能なんだろうけどねって話で。
で、その上で再生された音源をミックスダウンするプロトコルが必要だよね、ボリューム情報だけなら簡単だが。ダイナミック系やアンビエンス系のパラメーターとかも載せるのか？とか。
やはり、めんどくさい実装しても、完全な再現性は保証されないよね。
けっきょく、オーディオ情報のストリーミングでいいじゃんって事になるよね。
非常に、ビジネスモデルが確立しにくいね。
じゃ、その音源の権利関係とかロイアリティとかをどうするかって事なんだろうと思うよ。
もちろん配送なら課金も可能なんだろうけどねって話で。
で、その上で再生された音源をミックスダウンするプロトコルが必要だよね、ボリューム情報だけなら簡単だが。ダイナミック系やアンビエンス系のパラメーターとかも載せるのか？とか。
やはり、めんどくさい実装しても、完全な再現性は保証されないよね。
けっきょく、オーディオ情報のストリーミングでいいじゃんって事になるよね。
非常に、ビジネスモデルが確立しにくいね。
16 ：名無しサンプリング＠48kHz：03/12/17 08:27 ID:KT+x8Y+b
ＭＰ３やＷＡＶは情報としては音楽だけど
データとしての音楽情報はＭＩＤＩでしょ
譜面がなけりゃ真の音楽情報とはいえない
データとしての音楽情報はＭＩＤＩでしょ
譜面がなけりゃ真の音楽情報とはいえない
17 ：名無しサンプリング＠48kHz：03/12/17 08:27 ID:KT+x8Y+b
ＭＰ３やＷＡＶは情報としては音楽だけど
データとしての音楽情報はＭＩＤＩでしょ
譜面がなけりゃ真の音楽情報とはいえない
データとしての音楽情報はＭＩＤＩでしょ
譜面がなけりゃ真の音楽情報とはいえない
18 ：名無しサンプリング＠48kHz：03/12/17 11:32 ID:pLxetkSh
19 ：名無しサンプリング＠48kHz：03/12/17 13:55 ID:jjLK0gLm
>地球上には譜面の存在しない音楽なんて無数にあるのにな。
今のはそういう話ではないかと。
今のはそういう話ではないかと。
20 ：名無しサンプリング＠48kHz：03/12/18 09:50 ID:niz3nyCP
音源のデコーダってどういった技術なのでしょう？
何処へ質問スレ立てればいいのかな？
何処へ質問スレ立てればいいのかな？
21 ：名無しサンプリング＠48kHz：03/12/18 10:10 ID:VDNReCS+
>>20
デコードってのは、エンコードされたデータが存在して初めてデコードなので、
こういう場合には使わないと思うよ。 mp3 や mpeg とかの圧縮技術と間違えてんじゃない？
話を聞く限り、ようはソフト音源じゃない？ どうやってソフト音源作るかは‥
↓ VST プラグイン自作するスレとかで聞いてみたら？
http://pc3.2ch.net/test/read.cgi/dtm/1030621741/l50
デコードってのは、エンコードされたデータが存在して初めてデコードなので、
こういう場合には使わないと思うよ。 mp3 や mpeg とかの圧縮技術と間違えてんじゃない？
話を聞く限り、ようはソフト音源じゃない？ どうやってソフト音源作るかは‥
↓ VST プラグイン自作するスレとかで聞いてみたら？
http://pc3.2ch.net/test/read.cgi/dtm/1030621741/l50
22 ：名無しサンプリング＠48kHz：03/12/18 11:59 ID:anyUCXOE
クライアント側から MIDI データを渡して、サーバでそれを正しく音声ファイルに変換し、
クライアントに返すという、MIDI to Audio C/S システムを構築すれば、
MIDI が持つ再現性のなさという欠点が克服され、めでたしめでたしなのであります。
(1) サーバには、多数の MIDI インターフェイスを介して、
さまざまなハード音源(ソフト音源も可)がつながっている。
(2) サーバはこれらの音源を個別にコントロールできるシーケンサを搭載している。
(3) サーバには、これまた多数の Audio インターフェイスがあり、
MIDI 音源の出力はこれを通じてサーバに戻され、
WAV, WMA, MP3 等、任意の形式でリアルタイムにディジタル化することができる。
これにインターネット接続機能を加えると、こうなる。
(1) クライアントから、ブラウザを通じて MIDI ファイルまたはその URLを WEBサーバに送る。
併せて、再生音源と変換後のファイル形式、品質、
および再生形式(Download/Stream)を指定する。
(2) WEB サーバは、URL が指定されていれば、そこからMIDI データをダウンロードした上で、
MIDI/Audio サーバにファイルを渡す。
(3) MIDI/Audio サーバは、指定の音源に MIDI データを送り、
指定の形式で音声データに変換し、Stream ならそのままだらだらと、
Download ならすべて変換したあと、ファイルをクライアントに返す。
(4) クライアント側で再生、またはファイル保存される。
クライアントに返すという、MIDI to Audio C/S システムを構築すれば、
MIDI が持つ再現性のなさという欠点が克服され、めでたしめでたしなのであります。
(1) サーバには、多数の MIDI インターフェイスを介して、
さまざまなハード音源(ソフト音源も可)がつながっている。
(2) サーバはこれらの音源を個別にコントロールできるシーケンサを搭載している。
(3) サーバには、これまた多数の Audio インターフェイスがあり、
MIDI 音源の出力はこれを通じてサーバに戻され、
WAV, WMA, MP3 等、任意の形式でリアルタイムにディジタル化することができる。
これにインターネット接続機能を加えると、こうなる。
(1) クライアントから、ブラウザを通じて MIDI ファイルまたはその URLを WEBサーバに送る。
併せて、再生音源と変換後のファイル形式、品質、
および再生形式(Download/Stream)を指定する。
(2) WEB サーバは、URL が指定されていれば、そこからMIDI データをダウンロードした上で、
MIDI/Audio サーバにファイルを渡す。
(3) MIDI/Audio サーバは、指定の音源に MIDI データを送り、
指定の形式で音声データに変換し、Stream ならそのままだらだらと、
Download ならすべて変換したあと、ファイルをクライアントに返す。
(4) クライアント側で再生、またはファイル保存される。
23 ：名無しサンプリング＠48kHz：03/12/18 12:27 ID:niz3nyCP
＞クライアント側から MIDI データを渡して、
＞サーバでそれを正しく音声ファイルに変換
＞再生音源と変換後のファイル形式、品質、
＞および再生形式(Download/Stream)を指定
この変換・再生形式の指定に関するサーバー音源の
対応パラメータ設定が一番のポイントになるのかなあ
その技術は可能なのかな？これが一番の肝。
＞サーバでそれを正しく音声ファイルに変換
＞再生音源と変換後のファイル形式、品質、
＞および再生形式(Download/Stream)を指定
この変換・再生形式の指定に関するサーバー音源の
対応パラメータ設定が一番のポイントになるのかなあ
その技術は可能なのかな？これが一番の肝。
24 ：名無しサンプリング＠48kHz：03/12/18 12:54 ID:DabkPw++
複数のサーバーでの処理の結果が、完全に同一であるためには、
異なるサーバーのサーバーウェアが同一である必要があるわけで。
例として、サーバーAにはYAMAHA製の、サーバーBにはRoland製の
ソフトが入っていたら出音が変わっちゃうじゃん。
だから、完全にどこかのソフトが独占しなきゃC/Sにする意味がない。
仮にサーバーが１台でも、MIDIデータ側から見れば、結局は独占に過ぎない。
ってことはだよ。なにもサーバーサイドでやらんでも、ローカルでやっても
結果が同じじゃない。同じソフト使えば。
まあ、ユーザーサイドから見たらソフトのインストールしなくていいという
メリットはあるが、それなら最初から制作者がMP3で配布すればいいし。
というわけで、進展はないのではと。
異なるサーバーのサーバーウェアが同一である必要があるわけで。
例として、サーバーAにはYAMAHA製の、サーバーBにはRoland製の
ソフトが入っていたら出音が変わっちゃうじゃん。
だから、完全にどこかのソフトが独占しなきゃC/Sにする意味がない。
仮にサーバーが１台でも、MIDIデータ側から見れば、結局は独占に過ぎない。
ってことはだよ。なにもサーバーサイドでやらんでも、ローカルでやっても
結果が同じじゃない。同じソフト使えば。
まあ、ユーザーサイドから見たらソフトのインストールしなくていいという
メリットはあるが、それなら最初から制作者がMP3で配布すればいいし。
というわけで、進展はないのではと。
25 ：名無しサンプリング＠48kHz：03/12/18 13:13 ID:LnYQfOh9
サーバーの使用料、もしくは運営コストを考えると、音源買ったほうがマシって気付かない？
演奏が同一、ってことなら、MP3でいいし。
演奏が同一、ってことなら、MP3でいいし。
もし、これを実現するして
大手MIDI音源メーカが共同開発する必要がある上に、
結局はMIDI(楽譜)→信号の変換処理なので
そこまでMIDIにこだわる必要性が見えません。
もともとMIDI規格は音源に一定情報を伝えるためのものなので
MIDI音源とよばれる、こてこてのMIDI機器以外の
シンセサイザー等でも当然使われているわけで
>>MIDIはその再生手段に個々の端末の状態が反映され
>>作者の意図としない状態がおおおうに生まれる。
この問題は主としてナロードバンド生んだ問題なわけで、
それほど作者の意図に従いたいならば、
ハード・ソフトを購入する必要があるわけです。
それに、
1さんがおっしゃるようなシステム自体はかなり簡単に構築できると思いますが
(1さんの構想程度なら現行のMIDIに音源情報を埋め込むだけで十分ですしね)
音源の権利の問題が大きい上、このシステムを運営していくメリットが
はっきりしていないというか。利益が無ければ作るわけもないので。
24さんのおっしゃる通り進展はないでしょう。
大手MIDI音源メーカが共同開発する必要がある上に、
結局はMIDI(楽譜)→信号の変換処理なので
そこまでMIDIにこだわる必要性が見えません。
もともとMIDI規格は音源に一定情報を伝えるためのものなので
MIDI音源とよばれる、こてこてのMIDI機器以外の
シンセサイザー等でも当然使われているわけで
>>MIDIはその再生手段に個々の端末の状態が反映され
>>作者の意図としない状態がおおおうに生まれる。
この問題は主としてナロードバンド生んだ問題なわけで、
それほど作者の意図に従いたいならば、
ハード・ソフトを購入する必要があるわけです。
それに、
1さんがおっしゃるようなシステム自体はかなり簡単に構築できると思いますが
(1さんの構想程度なら現行のMIDIに音源情報を埋め込むだけで十分ですしね)
音源の権利の問題が大きい上、このシステムを運営していくメリットが
はっきりしていないというか。利益が無ければ作るわけもないので。
24さんのおっしゃる通り進展はないでしょう。
>>24
ソフト音源と違うよ。
サーバには、実在するハード音源をそのまま接続するから、
異なったサーバでも同じ機種がつながっておれば同じ音になる。
サーバＡ、B ともに MU2000 も SC8850 も CM-64 もつながっている。
もちろんつながっていない音源を指定されたら ERROR を返す。
>>25
自分でMIDIデータを作って公開する場合は MP3 でも WMA でも
好きにできるが、既にさまざまな機種に依存した MIDI データがあるわけで、
それらのデータを聞くためにそのつど音源をそろえるのは
金もかかるし置くとこもない。
ワープロ文書の変換サービスみたいなもんだと思えばよい。
RUPO のデータも書院のデータも文豪のデータもOASYSのデータも
MS-WORD に変換しますよとかね。
(1) 実現する上で技術的な問題はないと思われる。
(2) 法律上の問題はクリア可能 (最終的にはカネで) と思われる。
(3) ユーザーとしてこのシステムに魅力を感じる人が
少なくとも２人くらいはいるようだ。
(4) しかし、商売として考えたとき、どれほど多くの人が利用し、
どの程度の利用料負担に耐えられるかは検討する必要がある。
頭の体操として、おもしろい課題だと思う。
ソフト音源と違うよ。
サーバには、実在するハード音源をそのまま接続するから、
異なったサーバでも同じ機種がつながっておれば同じ音になる。
サーバＡ、B ともに MU2000 も SC8850 も CM-64 もつながっている。
もちろんつながっていない音源を指定されたら ERROR を返す。
>>25
自分でMIDIデータを作って公開する場合は MP3 でも WMA でも
好きにできるが、既にさまざまな機種に依存した MIDI データがあるわけで、
それらのデータを聞くためにそのつど音源をそろえるのは
金もかかるし置くとこもない。
ワープロ文書の変換サービスみたいなもんだと思えばよい。
RUPO のデータも書院のデータも文豪のデータもOASYSのデータも
MS-WORD に変換しますよとかね。
(1) 実現する上で技術的な問題はないと思われる。
(2) 法律上の問題はクリア可能 (最終的にはカネで) と思われる。
(3) ユーザーとしてこのシステムに魅力を感じる人が
少なくとも２人くらいはいるようだ。
(4) しかし、商売として考えたとき、どれほど多くの人が利用し、
どの程度の利用料負担に耐えられるかは検討する必要がある。
頭の体操として、おもしろい課題だと思う。
>>27
いや、ソフトでもハードでも結局一緒じゃん。論点ずれてる。
たとえばさ。MIDIデータを作る人が居るとして、その人はMU2000向けに
データを作るとします。
その人はシーケンサーを起動して、MIDI鍵盤の電源を入れて。
で、いざ作るとき、音源はどうするの？まさか音無しでデータ入力するの？
普通はMU2000を接続して作る訳じゃん。MU2000向けなんだから。（※１）
そしてできあがったデータをSMFかなんかで保存して、サーバーで変換…？？
じゃ、MU2000から直接録音してMP3で公開すればいいじゃん。BBなんだし。
C/Sにするメリット無し。
※１に関して、MU2000以外で作るって言うなら、今のXG規格等と変わるところは
ない。要は規格内でしか完全再現不可。
XG→GSのような変換がご希望なら、ずいぶん前からそういうソフトあるし。
いや、ソフトでもハードでも結局一緒じゃん。論点ずれてる。
たとえばさ。MIDIデータを作る人が居るとして、その人はMU2000向けに
データを作るとします。
その人はシーケンサーを起動して、MIDI鍵盤の電源を入れて。
で、いざ作るとき、音源はどうするの？まさか音無しでデータ入力するの？
普通はMU2000を接続して作る訳じゃん。MU2000向けなんだから。（※１）
そしてできあがったデータをSMFかなんかで保存して、サーバーで変換…？？
じゃ、MU2000から直接録音してMP3で公開すればいいじゃん。BBなんだし。
C/Sにするメリット無し。
※１に関して、MU2000以外で作るって言うなら、今のXG規格等と変わるところは
ない。要は規格内でしか完全再現不可。
XG→GSのような変換がご希望なら、ずいぶん前からそういうソフトあるし。
>>28
だから、他人が作った自分の持っていない機種用のデータを
再生することを想定しているんだってばぁ。
自分で作ってるデータは何とでもなるよ。
XG→GSのような変換が希望というわけではない。
また、同じGSでも SC55mkII と SC88 と SC88Pro と SC8850 では音が違う。
だから、他人が作った自分の持っていない機種用のデータを
再生することを想定しているんだってばぁ。
自分で作ってるデータは何とでもなるよ。
XG→GSのような変換が希望というわけではない。
また、同じGSでも SC55mkII と SC88 と SC88Pro と SC8850 では音が違う。
30 ：名無しサンプリング＠48kHz：03/12/18 15:45 ID:DfLJ2UBo
だから
M P 3 で い い じ ゃ ん 。
M P 3 で い い じ ゃ ん 。
31 ：名無しサンプリング＠48kHz：03/12/18 23:58 ID:mpbqSqHG
>>30
ばか。
ばか。
32 ：名無しサンプリング＠48kHz：03/12/19 01:01 ID:gb1y9sSW
いや
M P 3 で い い だ ろ 。
M P 3 で い い だ ろ 。
33 ：○○ル ◆Mu1000UKvE ：03/12/19 01:07 ID:7cZPLsAj
全然関係ない+どーでもいいのですが自分はmp3よりOggが好きです。
34 ：名無しサンプリング＠48kHz：03/12/19 03:23 ID:SEq88dfR
送られてきた MIDI データをサーバ管理者が楽譜表示で見て鼻で歌って
リアルタイムに配信するなら面白いんじゃないの？
『ブロードバンド時代のはなうた君』
後は頼んだ＞老国
じゃっ。
リアルタイムに配信するなら面白いんじゃないの？
『ブロードバンド時代のはなうた君』
後は頼んだ＞老国
じゃっ。
35 ：名無しサンプリング＠48kHz：03/12/19 03:36 ID:xuJXYFYZ
36 ：名無しサンプリング＠48kHz：03/12/19 07:12 ID:BHYIxyKi
OK、わかった、要するにMP3とMIDIを同時に配布すれば満足するだろ？
けど、おまえんちの糞スピーカーじゃ意図した演奏になりそうにないなぁ（＾＾；
けど、おまえんちの糞スピーカーじゃ意図した演奏になりそうにないなぁ（＾＾；
37 ：名無しサンプリング＠48kHz：03/12/19 10:11 ID:eGFIc5NA
せっかくスレ立ててくれたんだから。
もっと建設的な、新MIDI規格のブレストしない？
いまやUSB1.1のチップなんて安いから、通信規格はUSB1.1を使うとして。
USB-MIDI は普通にあるけど、ぜんぜん帯域を使いきれてないよね？
どういう拡張が考えられる？
もっと建設的な、新MIDI規格のブレストしない？
いまやUSB1.1のチップなんて安いから、通信規格はUSB1.1を使うとして。
USB-MIDI は普通にあるけど、ぜんぜん帯域を使いきれてないよね？
どういう拡張が考えられる？
38 ：名無しサンプリング＠48kHz：03/12/19 10:47 ID:UoNrJZr3
横から入って質問で済みません。
興味本位の質問なので、スルーしてもらっても構いません。
PC等を使って、WAN側とMIDIをリアルタイムでやり取りできるソフトってあるんですか？
今、手元の鍵盤を弾いて（タイムラグはあるものの）同時にネットの向こうのMIDI音源が鳴るような。
トランジスタ技術とかをみていると、リアルタイムでRS232Cをやり取りするハードがあるようですね。
MIDIに特化してPCだけで出来るやつ。あったらいいなぁ。
興味本位の質問なので、スルーしてもらっても構いません。
PC等を使って、WAN側とMIDIをリアルタイムでやり取りできるソフトってあるんですか？
今、手元の鍵盤を弾いて（タイムラグはあるものの）同時にネットの向こうのMIDI音源が鳴るような。
トランジスタ技術とかをみていると、リアルタイムでRS232Cをやり取りするハードがあるようですね。
MIDIに特化してPCだけで出来るやつ。あったらいいなぁ。
39 ：名無しサンプリング＠48kHz：03/12/19 10:50 ID:UoNrJZr3
そういえば、最初期の電子音楽って、電話で聞いたんだよね。
電話会社のサービスで3音ポリだっけかな？リクエストして。
違ってたらメンゴ。
電話会社のサービスで3音ポリだっけかな？リクエストして。
違ってたらメンゴ。
40 ：名無しサンプリング＠48kHz：03/12/19 11:10 ID:eGFIc5NA
もしかして、NTTの方ですか？(藁
>>38
MIDIoverIPって事でしょ？ 実在するかどうかわからないけど。キャッシ付きで非同期でMIDIストリーミングみたいな事は当然可能ですよね。
7,8年前に研究してた人が居るのは知ってるんだけど‥
パケット通信で、タイミングなシビアな物は、キャッシュするしかないですよね。もちろん、帯域が十分に広ければ同期も可能ですけど。
↑の話なんですけど、その時期最高速のUNIXワークステーションでは、リアルタイム関数使っても苦労してましたね。ヨレヨレで:-)
いまは、CPUもネットワークも速くなったんで、それなりに動くと思いますよ。
>>38
MIDIoverIPって事でしょ？ 実在するかどうかわからないけど。キャッシ付きで非同期でMIDIストリーミングみたいな事は当然可能ですよね。
7,8年前に研究してた人が居るのは知ってるんだけど‥
パケット通信で、タイミングなシビアな物は、キャッシュするしかないですよね。もちろん、帯域が十分に広ければ同期も可能ですけど。
↑の話なんですけど、その時期最高速のUNIXワークステーションでは、リアルタイム関数使っても苦労してましたね。ヨレヨレで:-)
いまは、CPUもネットワークも速くなったんで、それなりに動くと思いますよ。
41 ：名無しサンプリング＠48kHz：03/12/19 21:00 ID:WtwfYu8d
>>39
懐かしい。ファミコン初期もＦＭ３ポリ。スーマリ等。
♪みみっみっ、どみっそ！♪
確かこの最後の「そ」がCsus4で３音じゃなかったっけ？
右脳ミスでしたらスマソ（ｗ
つい先日任天堂ファミコン製造停止。
要はサーバー主導でフォーマット管理、でマーケットの一元化を狙うと。
その需要は置いておくとして、技術的な問題点を突き詰めれば、
確かにＮＴＴあたりコンテンツ戦略として利用しそうだね（藁
懐かしい。ファミコン初期もＦＭ３ポリ。スーマリ等。
♪みみっみっ、どみっそ！♪
確かこの最後の「そ」がCsus4で３音じゃなかったっけ？
右脳ミスでしたらスマソ（ｗ
つい先日任天堂ファミコン製造停止。
要はサーバー主導でフォーマット管理、でマーケットの一元化を狙うと。
その需要は置いておくとして、技術的な問題点を突き詰めれば、
確かにＮＴＴあたりコンテンツ戦略として利用しそうだね（藁
42 ：名無しサンプリング＠48kHz：03/12/19 23:27 ID:ztG4/31L
「ファミコン初期もFM3ポリ」はツッコむところですか。
43 ：名無しサンプリング＠48kHz：03/12/20 11:20 ID:eKMzhESJ
とりあえず用語解説をお願いします。
「C/S システム」
「新MIDI規格のブレスト」
「USB1.1のチップ」
「RS232C」
「WAN側」
「MIDIoverIP」
「C/S システム」
「新MIDI規格のブレスト」
「USB1.1のチップ」
「RS232C」
「WAN側」
「MIDIoverIP」
44 ：名無しサンプリング＠48kHz：03/12/20 11:59 ID:xhwapfwT
>>38
WindowsならMIDIOVERLAN+つーのがある。
http://www.musiclab.com/products/rpl_info.htm
Mac OSX用にはiMIDI（未だﾃｽﾄ中）
http://www.grantedsw.com/imidi/
それぞれのプロトコルは独自に作ってるだろうから互換性はないと思うけど。
WindowsならMIDIOVERLAN+つーのがある。
http://www.musiclab.com/products/rpl_info.htm
Mac OSX用にはiMIDI（未だﾃｽﾄ中）
http://www.grantedsw.com/imidi/
それぞれのプロトコルは独自に作ってるだろうから互換性はないと思うけど。
45 ：名無しサンプリング＠48kHz：03/12/20 12:49 ID:MNiVgOAH
46 ：名無しサンプリング＠48kHz：03/12/20 13:37 ID:eKMzhESJ
とりあえず用語解説をお願いします。
「C/S システム」
「新MIDI規格のブレスト」
「USB1.1のチップ」
「RS232C」
「WAN側」
「MIDIoverIP」
「C/S システム」
「新MIDI規格のブレスト」
「USB1.1のチップ」
「RS232C」
「WAN側」
「MIDIoverIP」
47 ：名無しサンプリング＠48kHz：03/12/20 14:48 ID:dseFrJE2
>>46
ググれ
ググれ
48 ：名無しサンプリング＠48kHz：03/12/20 15:43 ID:WCKVHquA
http://homepage2.nifty.com/~Qwer/index.dir/qtma_sf2.dir/main.html
を見て思い付いたんだが
サーバー側に多種多様なSFを置いてMIDIを再生すればよいのでは？
曲を提供する側がSFセットを指定
（独自の音を聞かせたい場合はSFも転送する）
サーバー側でテンプレートになったSFセットと自作SFを鳴らして再生
>>1の＞ MIDIはその再生手段に個々の端末の状態が反映され
作者の意図としない状態が怏々に生まれる。
は少なくとも解決されるし難しい技術はいらないと思うしどうよ？
まあMODですでに解決してる気もするが、、、
を見て思い付いたんだが
サーバー側に多種多様なSFを置いてMIDIを再生すればよいのでは？
曲を提供する側がSFセットを指定
（独自の音を聞かせたい場合はSFも転送する）
サーバー側でテンプレートになったSFセットと自作SFを鳴らして再生
>>1の＞ MIDIはその再生手段に個々の端末の状態が反映され
作者の意図としない状態が怏々に生まれる。
は少なくとも解決されるし難しい技術はいらないと思うしどうよ？
まあMODですでに解決してる気もするが、、、
49 ：名無しサンプリング＠48kHz：03/12/20 21:50 ID:IMCPTegO
50 ：名無しサンプリング＠48kHz：03/12/21 11:19 ID:jxq+ICBx
43.46は、話についてこられなくなった1ではないのか？
それなら素直に1を名乗り、これからこのスレをどうするか、考える。
それなら素直に1を名乗り、これからこのスレをどうするか、考える。
51 ：名無しサンプリング＠48kHz：03/12/21 13:15 ID:WzVHarux
52 ：名無しサンプリング＠48kHz：03/12/21 14:22 ID:jxq+ICBx
>>49
素晴らしいね。うちmacで9環境だからどうかな？
対応しているとは書いてあるけど、OMSから見えないんだろうな。
サブマシンに入れて確認してみましょう。
枯れたマシンをこれ専用にするのも良いのかな？
素晴らしいね。うちmacで9環境だからどうかな？
対応しているとは書いてあるけど、OMSから見えないんだろうな。
サブマシンに入れて確認してみましょう。
枯れたマシンをこれ専用にするのも良いのかな？
53 ：名無しサンプリング＠48kHz：03/12/21 16:03 ID:gC9r4nDQ
すんません、別に>>1では無いのですが
とりあえず用語解説をお願いします。
「C/S システム」・・・・何の略？
「USB1.1のチップ」・・・
「RS232C」・・・・・・・
「WAN側」・・・・・・・
「MIDIoverIP」・・・・・検索ゼロ
とりあえず用語解説をお願いします。
「C/S システム」・・・・何の略？
「USB1.1のチップ」・・・
「RS232C」・・・・・・・
「WAN側」・・・・・・・
「MIDIoverIP」・・・・・検索ゼロ
54 ：名無しサンプリング＠48kHz：03/12/21 16:18 ID:P9HCYyma
>>53
だから、そのくらい自分で調べてみろよ。
だから、そのくらい自分で調べてみろよ。
55 ：名無しサンプリング＠48kHz：03/12/21 16:22 ID:8+bxGP4x
>>53
とりあえず、かわいそうなので今調べてみた。
リンクはっときますね。
「C/S システム」・・・・http://www.google.co.jp
「USB1.1のチップ」・・・ http://www.google.co.jp
「RS232C」・・・・・・・ http://www.google.co.jp
「WAN側」・・・・・・・ http://www.google.co.jp
「MIDIoverIP」・・・・・http://www.google.co.jp
これで多分分かるかな。
とりあえず、かわいそうなので今調べてみた。
リンクはっときますね。
「C/S システム」・・・・http://www.google.co.jp
「USB1.1のチップ」・・・ http://www.google.co.jp
「RS232C」・・・・・・・ http://www.google.co.jp
「WAN側」・・・・・・・ http://www.google.co.jp
「MIDIoverIP」・・・・・http://www.google.co.jp
これで多分分かるかな。
56 ：名無しサンプリング＠48kHz：03/12/21 17:04 ID:ysPHbMVl
C/Sシステムって
Client Server Systemの略でだよ。
サーバーを中心に、パソコンがぶらさがってる
LANシステムのこと。
USB1.1はいま標準で使われてるUSBの制御チップだろ
USB2がこれからの標準
RS232Cはぱそこんの通信ポートの企画
Macでは使われてない
WANはルーターで、外側のこと
MIDIoverIPは俺しらん。
で、結論から言うと
>>53は板違いだ
Client Server Systemの略でだよ。
サーバーを中心に、パソコンがぶらさがってる
LANシステムのこと。
USB1.1はいま標準で使われてるUSBの制御チップだろ
USB2がこれからの標準
RS232Cはぱそこんの通信ポートの企画
Macでは使われてない
WANはルーターで、外側のこと
MIDIoverIPは俺しらん。
で、結論から言うと
>>53は板違いだ
57 ：名無しサンプリング＠48kHz：03/12/21 21:43 ID:RJFFpYXN
MIDI over TCP/IPのことじゃないのか？
ネットワーク間のセッションがどうとかの。
何かの記事でみたことあるような。。
ネットワーク間のセッションがどうとかの。
何かの記事でみたことあるような。。
58 ：名無しサンプリング＠48kHz：03/12/22 05:51 ID:BOmaV6Cr
マルチメディア用語辞典とか買って読むのが一番いいのでしょうが、
取り敢えずﾓｲﾗが答えてみよう。
MIDI over IPってのは、IP（INTERNET PROTCOL）つまりネットを間に挟んで、
向こうとこっちで、MIDI信号のやり取りをするっていうこと。
IP電話は音声信号をやり取り。MIDI over IPは、MIDI信号をやり取り。
リアルタイムでね。（ここがポイント）
RS232Cは、パソコンなどに付いている、シリアル信号の規格です。
これの仕様を（ちょっとだけ）変えたのが、旧MACについている、
RS422(MODEM PORT /PRINTER PORT)です。
USB1.1のチップは、1個数百円で買えます。（業者のまとめ買いなら桁が一つ下）
安いんだから、なんにでもつけてくれ。と言っているのしょう。
WAN側とは、一般にインターネットの世界。プロバイダーにつながないと（普通はいけない）ところ。
新MIDI規格のプレスト ＝新しいMIDI企画を作るんだったらこうしてくれという、AMEI以外の
ユーザーや開発者の意見。とでもしましょうか。
C/Sってのは、こっち（クライアント）から「ﾁｮﾒﾁｮﾒしてよ」とサーバーにお願いすると、
「ハイよ」とサーバー側のコンピューターでいろいろやって（計算とか）「ﾁｮﾒﾁｮﾒが出来ました」
と、応えてあげるシステム。
例えば、ﾁｮﾒﾁｮﾒは検索でもいい。それをｲﾝﾀｰﾈｯﾄの世界でやってるのはGOOGLEとかYAHOOとか。
そういうこと。
取り敢えずﾓｲﾗが答えてみよう。
MIDI over IPってのは、IP（INTERNET PROTCOL）つまりネットを間に挟んで、
向こうとこっちで、MIDI信号のやり取りをするっていうこと。
IP電話は音声信号をやり取り。MIDI over IPは、MIDI信号をやり取り。
リアルタイムでね。（ここがポイント）
RS232Cは、パソコンなどに付いている、シリアル信号の規格です。
これの仕様を（ちょっとだけ）変えたのが、旧MACについている、
RS422(MODEM PORT /PRINTER PORT)です。
USB1.1のチップは、1個数百円で買えます。（業者のまとめ買いなら桁が一つ下）
安いんだから、なんにでもつけてくれ。と言っているのしょう。
WAN側とは、一般にインターネットの世界。プロバイダーにつながないと（普通はいけない）ところ。
新MIDI規格のプレスト ＝新しいMIDI企画を作るんだったらこうしてくれという、AMEI以外の
ユーザーや開発者の意見。とでもしましょうか。
C/Sってのは、こっち（クライアント）から「ﾁｮﾒﾁｮﾒしてよ」とサーバーにお願いすると、
「ハイよ」とサーバー側のコンピューターでいろいろやって（計算とか）「ﾁｮﾒﾁｮﾒが出来ました」
と、応えてあげるシステム。
例えば、ﾁｮﾒﾁｮﾒは検索でもいい。それをｲﾝﾀｰﾈｯﾄの世界でやってるのはGOOGLEとかYAHOOとか。
そういうこと。
59 ：名無しサンプリング＠48kHz：03/12/22 13:19 ID:RMaGti6s
みんな>>1の卒論の手伝いしてあげてるのか。偉いな。
60 ：名無しサンプリング＠48kHz：03/12/22 13:25 ID:s0s5q/9B
49 はMIDIをIPでストリーミングすると言う意味では実用的な実装だと思うけど。
1 はマンゾクしないんじゃ？どうも話を読んでると音源の規格化をしたいらしいから。
どうも、興味はソコだけらしい‥
折れは、それはMIDI規格の範疇外だと思うんだけど。
1 はマンゾクしないんじゃ？どうも話を読んでると音源の規格化をしたいらしいから。
どうも、興味はソコだけらしい‥
折れは、それはMIDI規格の範疇外だと思うんだけど。
61 ：名無しサンプリング＠48kHz：03/12/22 16:50 ID:sCmUEEmC
考える分には結構おもしろい話題のような気がしますね。
MIDIoIPとAudio over IPって事なんかな？
VST System LinkをoverLANでやってる
http://www.fxteleport.com/
なんてのも面白い規格ですよね
AUプラグインづくりのメドもたったので、近々。
MIDIoIPとAudio over IPって事なんかな？
VST System LinkをoverLANでやってる
http://www.fxteleport.com/
なんてのも面白い規格ですよね
AUプラグインづくりのメドもたったので、近々。
62 ：名無しサンプリング＠48kHz：03/12/25 21:47 ID:7pEQEXXv
age
63 ：名無しサンプリング＠48kHz：03/12/25 22:35 ID:roS98tCc
>>61
すでにポシャったような気が、、、
すでにポシャったような気が、、、
64 ：名無しサンプリング＠48kHz：03/12/26 15:58 ID:4hzRLiv7
この手法を用いると
どういったビジネスが
考えられるのでしょう？
法的に可能？技術的に可能？
どういったビジネスが
考えられるのでしょう？
法的に可能？技術的に可能？
65 ：名無しサンプリング＠48kHz：03/12/28 00:05 ID:gOO7lvsj
要するに、誰が何処からアクセスしても
満足のいくプリプロデータの交換が出来れば良いわけよ。
MIDIoverIPって個人レベルでも出来るんじゃないの。
マーケットはオーディションでしょ。
満足のいくプリプロデータの交換が出来れば良いわけよ。
MIDIoverIPって個人レベルでも出来るんじゃないの。
マーケットはオーディションでしょ。
66 ：名無しサンプリング＠48kHz：03/12/28 20:04 ID:gOO7lvsj
つーかＤＴＭ版って帰省している人多いみたいね。
何でこんな人少ないんだろ？
何でこんな人少ないんだろ？
67 ：名無しサンプリング＠48kHz：03/12/28 20:30 ID:jvAaQaYi
帰省はしていないが反省している。
68 ：名無しサンプリング＠48kHz：03/12/28 21:44 ID:AO0AQ/H4
申年なだけにな
69 ：名無しサンプリング＠48kHz：03/12/28 23:00 ID:yuXUZ0vt
70 ：名無しサンプリング＠48kHz：03/12/30 04:28 ID:QkgjPYzJ
1が言ってるのはアーティストでなくてリスナーが利用するサービスなんだろうけど
mp3でのデータ配付に比べてリスナー側になんらメリットがないなあ(既出)。
単なる思いつきだけど、制作側が利用するサービスで、サーバにある希少な電子楽器を
手元のキーボードで操作できるシステムとか考えてみた。でもハード音源だから
タイムシェアリングになるから不便極まりないか．．
mp3でのデータ配付に比べてリスナー側になんらメリットがないなあ(既出)。
単なる思いつきだけど、制作側が利用するサービスで、サーバにある希少な電子楽器を
手元のキーボードで操作できるシステムとか考えてみた。でもハード音源だから
タイムシェアリングになるから不便極まりないか．．
71 ：名無しサンプリング＠48kHz：03/12/30 09:35 ID:1fEYgKEO
だからさ、携帯とかでインストを配信して、ボーカルオーディションの簡略化
ってのは結構、業界受けするんじゃ無い？A○EX系の音とかだと
最近は簡単に模倣できるような状況だし。
ってのは結構、業界受けするんじゃ無い？A○EX系の音とかだと
最近は簡単に模倣できるような状況だし。
72 ：名無しサンプリング＠48kHz：03/12/30 11:06 ID:bDwCce4S
MIDIは既に配布用ではないという事で。
73 ：名無しサンプリング＠48kHz：03/12/30 11:53 ID:1fEYgKEO
着メロはＭＩＤＩ配信が圧倒してるよ
74 ：名無しサンプリング＠48kHz：03/12/30 22:48 ID:1fEYgKEO
映像の世紀見てるかい
75 ：名無しサンプリング＠48kHz：03/12/31 02:59 ID:97xa7NNE
あのー、>>48 で結論が出ているように思うのだが...。
1が問題としているのは「MIDIはその再生手段に個々の端末の状態が反映され
作者の意図としない状態がおおおうに生まれる」ってことなんだろう？
つまり「どの端末でも作者の意図通りに再生させたい」ってことだよな？
だったら48の言うように、MIDIファイルの中にサウンドフォントデータも含めてしまえば、
多少ファイルサイズは大きくなるけど、作者の意図どおり、全く同じ音で再生できるんじゃねーか？
しかもmp3とは違って再編集可能だぜ。もちろん48も指摘してるが、MODで実装済みの技術だが。
それにもし1が言うようなシステムを構築した場合、例えば俺が同じMIDIファイルを何回も再生すると、
下りの回線、つまり Serverー端末間に、膨大な音声データが、何回も流されるわけだよな。
いくらブロードバンドだからって、ネットワーク効率が悪すぎじゃないか？
1が問題としているのは「MIDIはその再生手段に個々の端末の状態が反映され
作者の意図としない状態がおおおうに生まれる」ってことなんだろう？
つまり「どの端末でも作者の意図通りに再生させたい」ってことだよな？
だったら48の言うように、MIDIファイルの中にサウンドフォントデータも含めてしまえば、
多少ファイルサイズは大きくなるけど、作者の意図どおり、全く同じ音で再生できるんじゃねーか？
しかもmp3とは違って再編集可能だぜ。もちろん48も指摘してるが、MODで実装済みの技術だが。
それにもし1が言うようなシステムを構築した場合、例えば俺が同じMIDIファイルを何回も再生すると、
下りの回線、つまり Serverー端末間に、膨大な音声データが、何回も流されるわけだよな。
いくらブロードバンドだからって、ネットワーク効率が悪すぎじゃないか？
76 ：名無しサンプリング＠48kHz：03/12/31 10:12 ID:nt9ACRGh
Server-ＰＣ端末
Server-携帯端末
だとネットワーク運用に違いが出る。だからして
「Server-ＰＣ端末・・・製作者用」
「Server-携帯端末・・・リスナー用」
と別々に構築するのはどうでしょう。リスナーがガイドメロ
に生歌なぞる事で立派なプリプロデータ完成じゃないですか？
Server-携帯端末
だとネットワーク運用に違いが出る。だからして
「Server-ＰＣ端末・・・製作者用」
「Server-携帯端末・・・リスナー用」
と別々に構築するのはどうでしょう。リスナーがガイドメロ
に生歌なぞる事で立派なプリプロデータ完成じゃないですか？
77 ：名無しサンプリング＠48kHz：03/12/31 12:22 ID:nt9ACRGh
ＲＳＶＰ，ＤｉｆｆｅｒＳｅｒｖ
78 ：名無しサンプリング＠48kHz：03/12/31 13:34 ID:nt9ACRGh
年末なのに盛り上がらないなあ
79 ：名無しサンプリング＠48kHz：03/12/31 18:11 ID:nt9ACRGh
あ、もっと大事な課題として、ＢＢになれば
動画ストリーム（遅い）と音声（速い）の問題は
完全に解決がつくのでしょうか？そうした時に
完全な同期ライブ配信みたいなものが
可能になるのでしょうか？
キーワード：携帯・双方向・ビジネス
それでは今年はこれにて。
動画ストリーム（遅い）と音声（速い）の問題は
完全に解決がつくのでしょうか？そうした時に
完全な同期ライブ配信みたいなものが
可能になるのでしょうか？
キーワード：携帯・双方向・ビジネス
それでは今年はこれにて。
80 ：名無しサンプリング＠48kHz：04/01/01 00:20 ID:suoBs4b6
>キーワード：携帯・双方向・ビジネス
悪いけどそんなキーワードで企画書いてる広告代理店はとっくに干されてる。
悪いけどそんなキーワードで企画書いてる広告代理店はとっくに干されてる。
81 ：名無しサンプリング＠48kHz：04/01/01 13:40 ID:wj3WLHyP
別に煽るわけじゃないが79よ、お前の言いたい事がよくわからん。
> もっと大事な課題として...
どんな課題と比較して「もっと大事な課題」とか言ってる？
> 動画ストリームと音声の問題
これって具体的にどんな問題よ？
> 完全な同期ライブ配信みたいなものが可能になる
画質音質をけちれば、ある程度同期配信は可能だと思うのだが。
それにそれが可能になったからどうなるの？どんなビジネス展開ができるの？
TVじゃだめなの？IP上でこれが可能になったら、
誰に、どんなメリットがあるの？
なんか79の妄想にコメント求められてるようで、見てて痛い。
ま、もっともこのスレが1の妄想みたいなものではあるが。
ってことでsageます。
> もっと大事な課題として...
どんな課題と比較して「もっと大事な課題」とか言ってる？
> 動画ストリームと音声の問題
これって具体的にどんな問題よ？
> 完全な同期ライブ配信みたいなものが可能になる
画質音質をけちれば、ある程度同期配信は可能だと思うのだが。
それにそれが可能になったからどうなるの？どんなビジネス展開ができるの？
TVじゃだめなの？IP上でこれが可能になったら、
誰に、どんなメリットがあるの？
なんか79の妄想にコメント求められてるようで、見てて痛い。
ま、もっともこのスレが1の妄想みたいなものではあるが。
ってことでsageます。
82 ：名無しサンプリング＠48kHz：04/01/02 12:44 ID:AhT3Yjuc
もっと建設的な、新MIDI規格のブレストしない？
いまやUSB1.1のチップなんて安いから、通信規格はUSB1.1を使うとして。
USB-MIDI は普通にあるけど、ぜんぜん帯域を使いきれてないよね？
どういう拡張が考えられる？
メリットは着メロ屋にしか無いかもしれないけど。
いまやUSB1.1のチップなんて安いから、通信規格はUSB1.1を使うとして。
USB-MIDI は普通にあるけど、ぜんぜん帯域を使いきれてないよね？
どういう拡張が考えられる？
メリットは着メロ屋にしか無いかもしれないけど。
83 ：名無しサンプリング＠48kHz：04/01/02 14:01 ID:AhT3Yjuc
＞８０
じゃあ今のキーワードは何なのか教えてくれ
じゃあ今のキーワードは何なのか教えてくれ
84 ：名無しサンプリング＠48kHz：04/01/02 15:08 ID:an5YXd4O
お前には教えない。
85 ：名無しサンプリング＠48kHz：04/01/02 22:08 ID:AhT3Yjuc
そういや韓国ではＭＩＤＩはどうなんだろ？
ＢＢの普及度は世界随一と聞いているが。
ＢＢの普及度は世界随一と聞いているが。
86 ：名無しサンプリング＠48kHz：04/01/03 11:03 ID:T81oO+aa
age
87 ：名無しサンプリング＠48kHz：04/01/03 14:57 ID:T81oO+aa
そうだボーカルトラックのＭＩＤＩ化について
何処かで研究してないかなあ
リアルタイムで携帯とかから
アップ出来ればすばらしいのに
何処かで研究してないかなあ
リアルタイムで携帯とかから
アップ出来ればすばらしいのに
88 ：名無しサンプリング＠48kHz：04/01/03 16:10 ID:zF7wqXpx
89 ：名無しサンプリング＠48kHz：04/01/03 16:57 ID:T81oO+aa
ＤＴＭのソフトならそりゃあるだろう。
じゃ無くて携帯のチップに埋め込めるのかい？
あくまで携帯に実装じゃなきゃ駄目だろうＢＢ時代じゃ。
じゃ無くて携帯のチップに埋め込めるのかい？
あくまで携帯に実装じゃなきゃ駄目だろうＢＢ時代じゃ。
90 ：名無しサンプリング＠48kHz：04/01/03 23:42 ID:T81oO+aa
ほれレスつかなくなった
91 ：名無しサンプリング＠48kHz：04/01/04 03:43 ID:EqJWrdv7
92 ：名無しサンプリング＠48kHz：04/01/04 03:45 ID:sli9z6W0
こういうことこそ大事な論議かも〜w
93 ：名無しサンプリング＠48kHz：04/01/04 13:50 ID:FidQDnT6
結局大事な議論なの？実装は可能だとか何だとか。。。
誰かまとめてくれない？面白そうな要素あるみたいだし。。
誰かまとめてくれない？面白そうな要素あるみたいだし。。
94 ：名無しサンプリング＠48kHz：04/01/04 16:40 ID:KkIjg5f/
671 名前：名無しサンプリング＠48kHz ：04/01/04 15:37 ID:FidQDnT6
＞デジタル信号処理技術の技術底辺の向上
ここについての解釈をお願いします。
例えばこの技術によって可能となる
ビジネスですとか。携帯電話には
実装可能なシステムなのでしょうか？
672 名前：名無しサンプリング＠48kHz ：04/01/04 16:01 ID:5TiFYfZF
>>671
そんな具体的なことを言ってるわけじゃないとおもうが。
シロウトにもVST作る技術が備わってくれば、それ相応の
ハイレベルな製品がベンダーからでてくるだろう、子供だ
ましな製品は淘汰されるだろう。
ってことじゃないの？
673 名前：名無しサンプリング＠48kHz ：04/01/04 16:29 ID:FidQDnT6
要するにソフトシンセを自作する事で
クリエイターの底上げって事ですかね？
＞デジタル信号処理技術の技術底辺の向上
ここについての解釈をお願いします。
例えばこの技術によって可能となる
ビジネスですとか。携帯電話には
実装可能なシステムなのでしょうか？
672 名前：名無しサンプリング＠48kHz ：04/01/04 16:01 ID:5TiFYfZF
>>671
そんな具体的なことを言ってるわけじゃないとおもうが。
シロウトにもVST作る技術が備わってくれば、それ相応の
ハイレベルな製品がベンダーからでてくるだろう、子供だ
ましな製品は淘汰されるだろう。
ってことじゃないの？
673 名前：名無しサンプリング＠48kHz ：04/01/04 16:29 ID:FidQDnT6
要するにソフトシンセを自作する事で
クリエイターの底上げって事ですかね？
95 ：名無しサンプリング＠48kHz：04/01/04 19:07 ID:FidQDnT6
そこまで晒さなくても。。。
96 ：75=81：04/01/04 21:49 ID:34YxzF/p
まともなコメントにアホなレスがつくのはこのスレッドでつか？
ってな煽りはいいとして、結局ここで何を話し合いたいのかわからん。
「ブロードバンド時代のMIDI（音楽データ？）のあるべき姿」なのか
「高速回線を用いた携帯端末のサービスについて」なのか
「音源のクライアントサーバモデルの可能性について」なのか
「ビジネスを語る」のか「夢を語る」のか。
それに「ブロードバンド」と一口にいっても
PC端末でのことだか、モバイルのことだかはっきいりしとらん。
でも少なくとも、1が指摘した、
「再生手段に個々の端末の状態が反映され
作者の意図としない状態がおおおうに生まれる。 」
と言う問題は48で解決していると思うのだが…。
97 ：名無しサンプリング＠48kHz：04/01/04 21:54 ID:BISIP7YT
>と言う問題は48で解決していると思うのだが…。
いや>>30で既に解決してる。
いや>>30で既に解決してる。
98 ：名無しサンプリング＠48kHz：04/01/06 08:42 ID:ht/P602L
「高速回線を用いた携帯端末のサービスについて」
「音源のクライアントサーバモデルの可能性について」
これを同時に解決する手段は何か無いか、って事でしょう。
ブロードバンドをモバイル環境で利用出来るようになれば
サーバー立ち上げて何かビジネスが出来るんじゃないか、どか。
「音源のクライアントサーバモデルの可能性について」
これを同時に解決する手段は何か無いか、って事でしょう。
ブロードバンドをモバイル環境で利用出来るようになれば
サーバー立ち上げて何かビジネスが出来るんじゃないか、どか。
99 ：名無しサンプリング＠48kHz：04/01/06 09:28 ID:rIESDVPS
クライアントなのにサーバーでしかもモデルなの？
知ってる単語全部並べただけ？
知ってる単語全部並べただけ？
100 ：名無しサンプリング＠48kHz：04/01/06 11:18 ID:ht/P602L
いや、＞９６に書いてある単語
101 ：名無しサンプリング＠48kHz：04/01/07 01:20 ID:X+EJDFhX
sage
102 ：名無しサンプリング＠48kHz：04/01/07 17:49 ID:X+EJDFhX
上げ
103 ：名無しサンプリング＠48kHz：
せっかくブロードバンドなんだから、音声だけでなく
映像も同期してMIDI over IPってのどうよ。
maxnatoあたりでプログラミング出来んだろうか。
映像も同期してMIDI over IPってのどうよ。
maxnatoあたりでプログラミング出来んだろうか。