« 2020年04月 | 2020年06月のアーカイブ | 2020年07月 »
2020/06/30
Web Audio API での ADSRカーブその2 audioworklet-adsrnode
さて、前回 Web Audio API のオーメーション関数で ADSR のリトリガーの挙動を実現する際に問題があると書いたのですが、書き忘れてました。これが問題になるのは「モノフォニックシンセ」の場合です。
和音が出せるポリフォニックシンセの場合は当然エンベロープジェネレータ自体もボイス数分確保されていますので、打鍵ごとに今空いているエンベロープジェネレータがアサインされるため、無視できないほどの現在値を持った ADSR をリトリガーしなくてはならない状態が発生するという事は根本的にボイス数が足りないという事になります。ま、リリースをやたら長く設定した場合なんかは割と簡単にそういう状態が発生したりもするので無関係というわけでもないですが。
とにかく、このオートメーション関数による ADSR カーブの生成については私も色々試行錯誤はしたのですが、結論から言うと...面倒くさくなって諦めました。そうじゃなくて、根本的なアプローチとしてこれはオートメーション関数をこねくりまわすのではなくて ADSR 専用のノードを作ってしまうべきだろうという考えに至ったという事です。
つまりこういう事です。
なぜこういうノードが無いのか、と。
元々の思想からすればノードの出力は音信号で制御系はオートメーションという区分けとか、色々と本来の思惑から外れるかも知れませんが。ただ、こうする事でリトリガーの問題だけではなくて制御系信号を多数のノードに分配する際にノード間 connect() が使えるとか、色々とすっきりする事が多いと思われます(ノードの出力を使うと無条件に a-rate 処理になってしまうというのは負荷的には不利な点にはなりますかね)。
まあ、作ってみれば良いんですけどね。今はノードの中身を作れる AudioWorklet があるし。
これなら、ノード内で常に現在のエンベロープ値を把握しているので時刻をトリガーにしてディケイカーブを発動するのではなく、アタックカーブがピーク値に達した事をトリガーにしてノード内部でディケイを発動できるというわけです。
という事で、作ってみたものがこちらになります。
GitHub - audioworklet-adsrnode
せっかくなので attack / decay / sustain / release に加えて、アタックのカーブの曲がり具合を調整する attackcurve というパラメータも追加してあります。
ライブデモ もありますのでチェックしてみてください
posted by g200kg : 8:05 PM : PermaLink
2020/06/29
Web Audio API での ADSR カーブ
Web Audio API でシンセを作る場合、元々 API の思想としてはエンベロープ曲線、いわゆる ADSR のカーブを生成するには各種の オートメーション関数 を使う事が想定されています。つまり、GainNode の gain パラメータに対して
setValueAtTime()
linearRampToValueAtTime()
exponentialRampToValueAtTime()
setTargetAtTime()
等の関数でパラメータを時間と共に変化させるという機能を使用します。しかし実際にそれなりに実用的なシンセを作ろうとするとこれではうまく行かない、あるいはとても面倒くさい、という事が起こります。それが「リトリガーへの対応」です。
ADSR は鍵盤を押した時、離した時のタイミングを基に下の図のような音量変化の曲線を作ります。各部の曲線は基本的に setTargetAtTime() による目標値に漸近する指数曲線 :
\(v(t) = V_1 + (V_0 - V_1)\, e^{-\left(\frac{t - T_0}{\tau}\right)}\)
で作れます。
問題は 2 回連続で鍵盤を素早く弾いた時です。1 回目の打鍵の曲線がまだ収束していない時に 2 回目の曲線が始まり、単に同じ曲線を繋げると不連続点ができてしまいます。この不連続点はノイズとして聞こえますので、対処が必要です。
でどうするかですけど、色々な考え方はあると思いますが、典型的なアナログシンセではどうなるかと言うと、次の図です。現在の値から ADSR 曲線が始まり、その分、2 つ目のピークになる点も少しだけ前倒しされます。ちなみに良くない例でありがちなのはアタック時のピークの時刻、つまり decay の始まる時刻を維持するために上りのカーブの傾きを変えてしまう事ですね。アタックのニュアンスが変わってしまいます。
ところがこれをオートメーション関数で実現しようとすると厄介な事になります。各部の曲線を指定するのはターゲットとなる値と発動する時刻がパラメータとして必要なので、2 回目の打鍵におけるアタック、ディケイ曲線を指定するにはリリース曲線の途中にある値を取得し、そこから 2 個目のピークになる時刻を計算する必要が出てきます。
何故こんな面倒な事になるかというと、Web Audio API のオートメーション機能はすべて時刻ベースのイベントで発動するのに対し、アナログシンセの ADSR では attack の次に decay が発動するタイミングというのは時刻で決まっているわけではなくてサンプル毎に現在の値を計算してゆく中で決まったピーク値になったら発動するものだからです。
という事で、これを根本的に解決するにはこのオートメーション関数のアプローチではちょっと筋が悪いのではないかと思うわけです。。。つまりどうするのが良いか。。。は次回に続く...
Web Audio API での ADSR カーブ (その2)
posted by g200kg : 7:14 AM : PermaLink
2020/06/27
Microsoft Edge 新バージョン到来
かねてより案内があった Microsoft Edge が Chromium ベースになるという話、ついに本日 Windows Update でうちにも自動配信されました。
edge://version でバージョン等確認できます。
ユーザーエージェントには Edg/81.0.416.81 というのが付いています。
設定画面なんかはかなりいじってるようではありますが、デベロッパーツールなんかを開くと大体 Chrome な感じですね。Web Audio の最新機能である AudioWorklet なんかもちゃんと動作しています。まあ Web Audio 関係では最近はどちらかと言うと Apple Safari がアップデートしてくれなくて足並みを乱している感がありますが。
さて、これである意味貴重な HTML レンダリングエンジンである edgeHTML が姿を消し、もう Webkit-Blink と Firefox の Gecko しか残ってない事になるのだが、この先どうなりますかね...。
posted by g200kg : 9:09 PM : PermaLink
2020/06/24
Web Audio API CR 2020年6月11日版 日本語訳
W3C の Web Audio API, Candidate Recommendation が6月11日に更新されてから約2週間、地道に翻訳してなんとか日本語訳をアップデートしました。新しい機能が入ったとかいう事はありませんが各セクションの説明に追加、修正などが行われています。
ものが API の仕様書ですので、読み物として読むにはつらいのと、オーディオ DSP 系とモダンな Javascript の両方の知識が必要なのが厳しい所ですが、これは Web Audio API を使う側向けの説明だけではなく、Web Audio API の内部を実装するために必要な情報が詰まっていますので、単にオーディオ DSP に興味ある人にとっても有意義な内容になっています。
かなりの容量ですが、オーディオ DSP を広く網羅して突っ込んだ内容の文書というのはなかなか貴重なのではないかと思います。
活用していたただければ。
また間違いなどみつけましたら、GitHub issue へ。
Web Audio API, W3C Candidate Recommendation, 11 June 2020 (日本語訳)
posted by g200kg : 3:02 PM : PermaLink
2020/06/12
Web Audio API が更新
昨日6月11日に W3C で公開されている WebAudio API が「W3C Candidate Recommendation, 11 June 2020」として更新されました。
前回の更新で Working Draft (草案) から初めて Candidate Recommendation (勧告候補) になったのが2018年9月なので1年9カ月ぶりですね。今回も Candidate Recommendation 版なのは同じで、基本的に API の説明の細かな間違いや不明瞭な点が修正されているだけですので、新しい機能の追加などはありません。
前回の CR 版との差異については Change Log にまとまっています。
また、Call for Exclusions の申し立て期間が2020年8月10日までとアナウンスされています。これはつまり W3C の定める規格はパテントポリシーとして特許料の支払いが必要なものは基本的には含めないのだけど、もし「この部分はうちの特許に抵触しているので勝手に使わないでくれ」と申し立てをするのなら8月10日まで、という事ですね。
今後の予定がどう進むのかちゃんと把握していませんけど、問題なければ現在の CR から PR (Proposed Recommendation) に進み、4週間以上の諮問委員会によるレビューの後、Recommendation、いわゆる W3C 勧告となるという風に進むようです。
posted by g200kg : 5:32 PM : PermaLink
« 2020年04月 | 2020年06月のアーカイブ | 2020年07月 »
-->
g200kg