長嶋さん お忙しいところ何度も恐縮ですが、MIDI音源の発音遅延に関する長嶋さんの昨年 の情処学会の論文で、一点疑問がありますので質問します。 論文本文中の -- begin -- 基準MIDIメッセージとして 「MIDI1チャンネル、ノートナンバー60、ベロシティ100でON、その直後にOFF」 という6バイトのMIDI情報を送出して… -- end -- という部分があるんですが、SC-88などの音源のエンベロープジェネレータの動 作を考えると、通常のADSRを想定すれば * * * * ********** * * * * ---------| A | D | | R |-------- | | NOTE NOTE ON OFF という動作になります。これを考えると、GMリセットのピアノ(GM Patch #1)の Attackの時間、あるいはReleaseの時間が仮に十分短かかったとしても、Note ON-OFFの間が僅か3バイト分 (0.96msec) というのは ADSR の動作をさせるには 短かすぎるのではないかと思えます。(ドラムマシンのように、NOTE ONだけで 発音する音源なら別ですが。)Note ONとNote OFFの間を最低でも100msec 程度取らないと、ピアノ音を使う実験では音は出て来ないのではないかと想像します。 言い換えれば、仮に0.96msecの間隔で発音するとしたら、その音源のAttackの時間は 非常に短くなければならないということです。 上記の件についてお暇な時にでもご意見をお聞かせいただければ幸いです。 ------------------------------------------------------------------- 長嶋です。 > MIDI音源の発音遅延に関する長嶋さんの昨年 > の情処学会の論文で、一点疑問がありますので質問します。 この発表に関しては、以下にありますので、適宜参照して下さい。 http://nagasm.org/ASL/10-07/onchi99.pdf あのネタは使い回しで、去年4回発表しているのですが、来ると期待している のに一度も来なかった質問です。お待ちしておりました。(^_^;) > -- begin -- > 基準MIDIメッセージとして > 「MIDI1チャンネル、ノートナンバー60、ベロシティ100でON、その直後にOFF」 > という6バイトのMIDI情報を送出して… > -- end -- > > という部分があるんですが、SC-88などの音源のエンベロープジェネレータの動 > 作を考えると、通常のADSRを想定すれば > > * > * * > * ********** > * * > * * > ---------| A | D | | R |-------- > | | > NOTE NOTE > ON OFF > > という動作になります。これを考えると、GMリセットのピアノ(GM Patch #1)の > Attackの時間、あるいはReleaseの時間が仮に十分短かかったとしても、Note > ON-OFFの間が僅か3バイト分 (0.96msec) というのは ADSR の動作をさせるには > 短かすぎるのではないかと思えます。(ドラムマシンのように、NOTE ONだけで > 発音する音源なら別ですが。)Note ONとNote OFFの間を最低でも100msec > 程度取らないと、ピアノ音を使う実験では音は出て来ないのではないかと想像 > します。 > 言い換えれば、仮に0.96msecの間隔で発音するとしたら、その音源のAttackの > 時間は非常に短くなければならないということです。 ピアノ音は、SustainLevel=0なので減衰はDecayです。Decay途中のKeyOFFで Releaseに行きます。 Attackの途中でOFFが来るというのは普通のことです。スローアタック音色では 常時こればかり、という演奏もあります。 音源内部の動作については、設計側に任されています。Attackフェーズの 最中、つまりまだ最大レベルにまで到達しないうちにノートOFFが来た場合に どうするか、というのは、これは音源ノウハウの一つの極致です。 この対応には、方式ごとにメーカごとにそれぞれ数種類の基本的特許が あります。十数年前から。(^_^;) ちなみに、サウンドで高速アタックのものは最高速なら1-2msec以内で 最大レベルにまで行くようなものもザラですので、この状況で「音が出ない」 という動作をする、というのは、そういうのがあったとしてもおかしくない ですが、それが普通だ、などとは楽器メーカのプロなら死んでも言えない です。なんせ最初の3バイトを見る限り、というか実際には6バイト目の 「同じノートナンバでベロシティが［０］、つまり実はもう即刻OFFなの 　であった(^_^;)」 と知るのは、この6バイト目を受信してからです。4、5バイト目では、その後に 続く情報が未知ですので、この段階では何もできません。ということは、6バイト 目を解釈した時点で、はじめて「おぉ、即刻OFFにしなければ」ということに なります。一方、ONの方は、3バイト目まで完結してから対応するというのは 普通ですが、高速レスポンスを主眼に置くなら、1バイト目のステータスで ノートオンの体制に、2バイト目のノートナンバで過去のそのピッチの発音状況 をサーチして、現状発音ゼロならおそらく次にはそのピッチのONが来るであろう というパラメータは全て完備しておいて、そのアタックレベルの数値の到来だけ を待つ、という状況にしておいて、3バイト目がとりあえずノンゼロなら エンベロープ生成をスタート（ノートオン）させてから、その数値をタッチ カーブなどで変換してDSPの「目標値」に転送する、という作戦が有り得ます。 こうすると、同じ連続6バイトのON-OFFでも、かなり長いdurationとなります。 ADSRのフローがちゃんと最後まで行われるなんてことは楽器では少なくて、 同時発音数の制限があるので、たいていの演奏では例外処理とフローの 途中打ち切りが多重に発生しまくっています。．．．なんていう内部事情 は音源を使うユーザには関係ないことです。ON-OFFを連続して送ったら たぶんとりあえず鳴ってから消えるだろうな、という素人の先入観を 裏切っては失格ということでしょうか。 結論として、連続6バイトのON-OFFでもたいていの音源ではピアノ音で発音 しています。それぞれの中身がどうやっているか、はまた別の問題ですが、 皆さんそれぞれ、苦労して出しています。(^_^;) MIDIのルールでは、鳴って当然です。