サウンドプログラミング

>935
http://klablog.okiraku-pc.net/logs/current-bbs/161/xqqrlz.html
これ読んで出直して来い。

ヘッドフォンで「後ろから音が聞こえる」という状況って
どうやれば作れるんでしょうか？

バイノーラル録音でググれ！
計算で求めるのはそれなりにホネが折れる

これを使うのは簡単ですか？
ttp://www.vector.co.jp/soft/win95/prog/se334955.html

MIDIクソって言ってる人いるけど、鳴らす音源によって全然音変わってくるじゃん。

それで？

>941
だから（再現性がないから）クソって言ってるんじゃないの？

MIDIはインターフェースなんだが

そういや昔MIDIってレーベルがあったなぁ（遠い目

MIDI規格の策定には楽器メーカーとPC関連企業が参加したが、
楽器メーカーは楽器ごとの個性を生かせる規格を主張し、
PCメーカーは同じコマンドを送ればどの楽器でも同じ音が出るべきだと主張した。

音源をPCの周辺機器と見るか、PCを楽器のコントロール装置と見るかの
立場の違いだ。

>944 に同意。
よって、通信速度が遅いからクソって言ってるんじゃないの？

大昔の規格だからしょうがないよ。

まぁmidiを音楽ファイルのひとつとしか捕らえてないようなのはさすがに痛い

通信速度さえ速くなれば問題ないってことか？

mlanとかいうのをYAMAHAが提唱してなかったっけ

いいかげんUSB使った新しい規格出さないと、業界全体が萎んじゃうよ。

>950
通信速度が上がるなら、多少データを冗長なものにして編集しやすくして欲しいな。
１命令４バイトの倍数単位とかで。
レコポかなんかの形式がそうじゃなかったかっけか。

そして次スレは>970くらいでいいのかな？

>>953
>>949で言っているのは恐らく君のことだ。
MIDIのプロトコルとSMFフォーマットをごっちゃにしてる匂いがするぞ。

シーケンス的には、発音：消音とコマンドを分けるのではなく
発音+ゲートタイムとした方が編集しやすいと常々思っているのだが
プログラムの問題だしどうでもいいな。

>>953
いや、950を越えてるから、もうそろそろ建てないと　このまま落ちてしまうよ。
俺は建てられない。

tatemasuta

サウンドプログラミング2
http://pc5.2ch.net/test/read.cgi/tech/1091054082/

このスレの存在に始めて気づいた
(ﾟдﾟ)ｳﾏｰ
もう、DSPっていったらFFTの今の時代
FIRに走ってる俺は・・・orz

>>954
もともとMIDIは電子楽器同士の制御用の規格だし。
（ちなみに初めてMIDI端子を搭載したシンセはあのYAMAHA DX7）

シンセで弾いた演奏を他のシンセの音で鳴らしたりとかするためのものだから、
ノートオン・ノートオフそれぞれ別に送らないと困る。
鍵盤を押し下げた時点では音長などわからん。

んで、SMFもMIDIの信号に時間軸の情報を与えただけのものだから、
まあそういうことだ。

人間の演奏速度を考えるとデータ転送速度は今のままでもあまり問題にならないのかな？

>>957
俺はいまだにIIRが主だよ

>>960
モマエはMIDIを常に一人分の演奏データしか転送しないものと思っているのか？

>>962
もともとは1人の演奏用に作られたんだと思うよ。その命令体系からしてさ

命令体系はどう見ても、多人数で複数の楽器を扱えるようにしか見えないが、
どこをどう見たらそう思えるのか理解できない。

モノフォニック・シンセサイザーの時代なら今の通信速度でも十分だったろうけど、
16chフルに使ってる楽曲とか、もたついてるのが聞いた耳で解るよ。
>960
ここはプログラム板だし、人間の演奏速度は議論対象外じゃね？

>>964
そうか？　誰が誰に送ろうとしてるかの情報が欠落してるように思ったのだが？
送信元が複数だと　ランニングステータスで連続送信してる時に割り込めないしな

>>958
いや、それは分かってるんだが...
だから953がMIDIのプロトコルとSMFフォーマットをごっちゃにしてると書いたのであって。
俺が後段で言及してるのはデータフォーマットのことね。
「レコポかなんかの形式」ってのもデータフォーマットの話だべ。

>954
ノート、バンクチェンジ、コントロールチェンジなんかもMIDI規格内だべ。
デルタタイムの処理ももちろん面倒だが、
これらのメッセージも２バイトだったり省略したりで処理しにくい。

>>966
きちんとチャンネルを設定出来るようになっているだろう。
そもそも割り込めないも何も、時系列で必要なタイミングを処理するのに、
他のデータを送信中に突然割り込む必要性など無い。

>>965
> 16chフルに使ってる楽曲とか、もたついてるのが聞いた耳で解るよ。

単に音源の処理速度が遅いというケースも多々。
ローランドとかローランドとかローランドとか。

つーてもまあ、31250bpsはやっぱり不足なんだけどね。

>>969
いいか、>>962の論理を分析しよう
　・「常に一人分の演奏データしか転送しないものと思っているのか？」　疑問形だが、これは
　・「常に一人分の演奏データしか転送しないものではない。」　となる。さらに反転すれば
　・「マレには２人以上の演奏データを転送する場合がある」　と同義になる

つまり、1人が他のデータを送信中に2人目が突然割り込める必要があるんだ！

まず、MIDIは1対１タレ流し通信なので　2人の演奏データを物理的にマージは出来ない。
もちろん、コントローラが、２つの信号をマージして出せばそれは可能だが、
どちらが演奏しようとした情報かはこの時点で失われる。

そして、ノートON/OFFの制御についてはこのコントローラが負わなければいけない。

結論として 　「マレには２人分の演奏データを転送する場合がある」なら
それはMIDIの外側で実現せねばならず、容易な事ではないということだ。

>972
異議アリ！
そもそも2人分のデータを1台のMIDI機器で演奏する場合がある。。。
たとえば、MIDIキーボードで連弾する場合もあり得るだろう。

このばあい、"突然"割り込む必要はない！

974

ALUTの英語解説読むのが面倒age

age

ASIO 対応の再生ソフトを作りたいのですがＳＤＫがダウソできません。
フォームに適当に入力して送られてきたメールのアドレスにアクセスしても
アクセス権がありませんと怒られます。
ダウソまでの手順がわかる方いませんか？

スレさようなら

979

JAVA SOUND API と C#+DIRECTX って
どちらがサウンドプログラミングしやすいでしょうか？
ドキュメントの面も含めて・・・

C#やるくらいならJAVA

>>981市ね
C++VSTSDKが正解

サウンドプログラミングって何をやりたいの？
FM音源とかのエミュレートなら、低レベルオーディオAPIで十分だよ。

楽なのはDelphiで￥・

>>981
JAVAを少し囓っていて
いまは必要に迫られてC#をはじめたところです。
C#ってBeep鳴らすのも面倒だと判ってこのような質問をしました。

>>983
FFT解析などをしたいと思っています。
DelphiってWin32APIを呼び出すのでしょうか？
それともDelphi独自のサウンドオブジェクトが用意されているのでしょうか？

￥・　ってなんでしょう？

>>984
確かに今のパソコンならJAVA/C#でもFFTかけるだけならリアルタイムに処理させるのは可能だけど
重いんじゃないかなあ

低レベルAPIってのはWin32APIの事だけど
自分はDelphiで低レベルAPIをラップして貼り付けてイベントに書くだけで
リアルタイム処理が出来るようにしてるよ。

たぶん探せばフリーのもあるんじゃないの？

>>985
ありがとうございました、調べてみます。(｀･ω･´)