g200kg Music & Software

2021 NAMM 「Believe In Music」

来年1月の NAMM ショーは COVID-19 の影響でオンラインイベント「Believe In Music」に変更されたみたいですね。2021年夏、2022年冬の NAMM ショーの案内も出ているので今回だけの特別措置だと思いますが、オンラインでこういうイベントがあるのは気軽に見れて良いかも知れないな。

https://www.namm.org/support/believe-in-music-week

Posted by g200kg : 2:40 AM : PermaLink

zoom-ms-utility スタンドアローン版

タイミングを逸して今更感はあるのだけど ZOOM マルチストンプ用のパッチ編集アプリを Web アプリからスタンドアローンアプリ化したものを公開しました。と言っても NW.JS に突っ込んだだけなんですが。何年か前にもやろうとしたけど、当時はまだ NW.JS に多少問題があってできなかったのをそのまま放置してしまっていました。

実行形式をZIPで固めてありますが、Mac版については GateKeeper がありますので、$ spctl コマンドで自分で一時的に止めるなどの作業が必要になります。Catalina でも起動できるのは確認していますが、今後どうなるんですかね。

https://github.com/g200kg/zoom-ms-utility

Posted by g200kg : 5:57 PM : PermaLink

MIDI2.0とVST3.7

最近 MIDI 2.0 周辺の状況がそろそろ気になり始めたので色々と様子をうかがったりしています。先月末には VST SDK が 3.7 にアップデートされたのですが、その中にも MIDI 2.0 への言及が少しだけ追加されています。

https://www.steinberg.net/en/newsandevents/news/newsdetail/article/new-vst-37-sdk-available-5605.html

追加されたのはドキュメントだけで実装はもう前の版からやっているよ、という事みたいですが ( いや、やってるのかな? どこまでやってるのかは知らないけど)。

まず双方向通信で機器間のネゴシエーションをする MIDI 2.0-CI (Capability Inquiry) とか、プロファイルによるオートコンフィグレーション、プロパティ交換などは基本的にホストアプリの責任なのでプラグインがどうこうするという事は無いというスタンスで良いんですかね。

ホストアプリとプラグインの間の VST 規格として関係してくるのはプロトコルまわり、つまり MIDI 2.0 になって、ベロシティやコントローラー(コントロールチェンジ)の解像度の向上やパーノートコントローラーというあたりが追加されたのですが、これらが VST ではどう扱われるか、になってきます。

VST ではホストアプリとプラグインの間はノートオン、ノートオフ等の MIDI イベントの他、コントロールチェンジ的な各種パラメータは Parameter での受け渡しで密に繋がっていて、また音符毎に付与できるパーノートコントローラーに相当するものとして VST 3.5 で導入された NoteExpression があります。また、ベロシティやポリプレッシャーについては VST3 でのプラグインへの受け渡しは 32bit float なので、MIDI2.0で16bit/32bit int になってもまだ戦える、という事です。

いずれにしても、これらの MIDI 2.0 経由で入ってくる情報を VST のパラメータ等にどうマッピングして行くのかはホストアプリの責任、という事になります。プラグインとしては入ってくるパラメータを変に切り捨てたりせずに素直に使っていれば MIDI 2.0 の高解像なコントローラー等が使えるという事になりますね。

MIDI 1.0 => MIDI 2.0 => VST 3 の対応

Posted by g200kg : 12:42 PM : PermaLink

2020/08/08 (2020年08月のアーカイブ)

USB-IFがMIDIデバイスv2.0向けUSBデバイス・クラス仕様を公開

気が付いてなかったのだけど、先月こういうニュースがあったのだね。
USB-IFがMIDIデバイスv2.0向けUSBデバイス・クラス仕様を公開

usb.org のプレスリリースはこちら:
USB-IF Publishes USB Device Class Specification for MIDI Devices v2.0

MIDI1.0から2.0への変化はかなり大がかりなものなので、普及も簡単ではないだろうなとも思うのだけど、既に色々と動きはあるようですね。
とは言え...、

本格的に使われるには DAW の対応が必要だしそれには OS レベルで API が整備されていないといけないのだけど、この辺の動きはどうなんだろね。 iOS では coreMIDI が既に MIDI 2.0 に対応しているとかいう話もちらっと聞いたりしたけどそれは MIDI 1.0 へのフォールバックの話のような気がするし、Windows 系だと MIDI 系の API って今どうなってるっけ? ユニバーサル Windows プラットフォームでの API だと今は完全に MIDI 1.0 の切り口なのでこの辺に増設する事になりそう(大変そう)。

現行 MIDI 1.0 の仕様も長い時間の中で色々と不満が出てきていて、各社勝手に色々と拡張を試みたりし始めていたので、ばらばらになる前に統一規格にしようという動きは良いんじゃないですかね。まあ予想外に根本的な所からの刷新ではありましたが。

ここに至るまでに出てきていた色々...。

ROLI MPE 規格 : ROLI 5次元キーボード対応で1つのノートに複数チャンネルを使う奴。設定に使うのは RPN 6
Hi-Res Velocity Prefix : ピアノでベロシティの解像度が足りなくなったのでノートオンの前に付けるタイプ、 CC#88 (58H)
eXtended Precision MIDI : ヤマハ製のピアノのベロシティ拡張 CC#16 (10H)

Posted by g200kg : 5:07 PM : PermaLink

2020/08/05 (2020年08月のアーカイブ)

MIDI (SMF) ファイルのレガシーなノウハウとか今後とか

どこかにこういうものはあるだろうと思っていたのに意外と見当たらなくて、いきなり MIDI-dump ユーティリティなんか作ったりしましたけど、SMFの扱いはそれなりに癖があるのでメモ。

https://github.com/g200kg/midi-dump

ちゃんとした規格は AMEI のページから見れます。
http://amei.or.jp/midistandardcommittee/MIDIspcj.html

すっかりレガシーなノウハウになってしまいましたが、これから初めて SMF を触ろうとしているなら、はまりやすいのはこんな所です:

NoteOn のベロシティ 0 は NoteOff として扱う事。これと次のランニングステータスとの合わせ技でファイルサイズが小さくなる。
( 場合によっては処理が面倒な事になったりするのだが ) ランニングステータスをちゃんと処理するのを忘れないように。最近はデータサイズにあまり敏感では無くなったので忘れられがち。
チャンクの構造はビッグエンディアンだけどベンドデータなんかはリトルエンディアンなので混同しないように。
Track Name 等のテキスト系メタイベントのエンコーディングは基本無法地帯。日本で作られたMIDIファイルは s-jis 文字列が入っている事が多い。内容から自動認識するしかないが、CP1252 (ISO-8859-1) と S-JIS が混ざったりすると割とお手上げ。
読み込みの際に知らないタイプのチャンクはちゃんと読み飛ばす、チャンクのサイズはチャンクのlengthをリスペクトする事。XFフォーマットとか一部のMIDIファイルには追加のチャンクタイプが存在する場合がある。
データの読み込みでメタイベント End of Track にエンカウントしたら以降のデータは無視する事。各トラックのデータは EOT の後ろにゴミデータが存在する場合がある。

と、ここまでは復習。

ここからは予習。

既に MIDI 2.0 規格が発表されているわけで、今後 MIDI ファイルも 2.0 対応になっていくはずですが、MIDI 2.0 での MIDI ファイルがどうなるかはまだ不明です。MIDI 2.0 は双方向通信でネゴシエーションするのが大きな特徴なのだけど、MIDIファイルは基本的に楽曲再生用シーケンスデータとして使われるという事を考えると、ネゴシエーションは実機での接続に任せて MIDI ファイルはネゴシエーション後にシーケンサーに読み込むためのデータという事になるのかなあ。知らんけど。

MIDI 1.0 に対する下位互換はありますが、MIDI 2.0 で拡張された分解能の向上なんかが使えないと意味がないので、本命はやはり MIDI 2.0 ネイティブの UMP をファイル化する方法ですかね。つまり今までバイトストリーム状態でランニングステータスなんかを使って割とせこせことサイズ削減していたのが、Uint32 ベースのパケットストリームを扱う感じでしょうか。1楽曲あたりのサイズは増えそうだけどそこは時代の流れですね。

UMP のパケットストリームに適当なデルタタイムが付いている感じだとして MIDI 2.0 で追加された JR タイムスタンプ (Jitter Reduction) との関係はどうなるのか?

とか、まだ色々面倒な事がありそうですが、そのうち仕様が出てくるのではないかと期待。
まあテキスト系メタデータにエンコーディング指定が付いててくれればそれだけで...

MIDI 2.0 の規格はまだ英語版ですが AMEI のページからダウンロードできます。

http://amei.or.jp/midistandardcommittee/MIDI2.0/MIDIspcj2.html

結構大きな仕様なので、どこから読めば良いのか戸惑い勝ちだけど、100から104に順番に行くのが正攻法ですかね。ただ CI の周辺は今までにまったくなかった概念なのでなんとなくもやっとして全体像がつかみにくいので MIDI 2.0 プロトコルの UMP のあたりの話の方がとっつきやすいかも知れません。

何にしても MIDI 2.0 の規格は MIDI 1.0 の知識がある事を前提として書かれているので、MIDI 1.0 の内容を知らずにこれだけ読んでも多分なんだかよくわからなくなります。

Posted by g200kg : 12:38 PM : PermaLink

2020/08/02 (2020年08月のアーカイブ)

midi-dump : midi (SMF) ファイルを読みやすくダンプするユーティリティ

今更だし、大したものではないのだけど、ちょっと MIDI ファイルの中身を確認したい事があったので作った。
取り合えずのものなので、適当な所が残っている。

こういうちょっとしたツールのようなものはもう大体 Web アプリで良いかなと思っている。

GitHub Repository : midi-dump
"midi-dump" Utility

Posted by g200kg : 1:32 PM : PermaLink

2020/07/29 (2020年07月のアーカイブ)

Appleがハードウェア寄りなAPIの実装を拒否している件

Web MIDI、Web Bluetooth、Web USB、Web Serial...

と近年ハード寄りなブラウザ API がどんどん出てきていて、そこそこのものなら(ハードウェアの能力を限界まで絞り出すようなネイティブアプリがある以上完全に、とは言わないけど) Web アプリで済む世界は近いと思ってはいるのだけど、その一方でこういう話もあるのだよね。

元記事は6月末の頃のもののようだ。

厳しいなあ。
Gigazine : 「Appleが「プライバシー上の懸念あり」としてSafariへの一部ウェブAPIの実装を拒否」

面白そうな API が軒並み実装拒否対象になっている。まあ Web USB なんかが出てきた時に Web アプリからそんな所を触って大丈夫なのか? と多少は思ったというのも確かにあるけどね。Web MIDI は許して欲しいな、勝手な希望なのは承知しているけど。

対象の Web API は以下の通り :

・Web Bluetooth
・Web MIDI API
・Magnetometer API
・Web NFC
・Navigator API: deviceMemory
・NetworkInformation API
・Battery Status API
・Web Bluetooth Scanning
・AmbientLightSensor API
・EME Extension: HDCP Policy Check
・Proximity API
・WebHID API
・Serial API
・WebUSB
・Idle Detection

Posted by g200kg : 11:13 AM : PermaLink

2020/07/26 (2020年07月のアーカイブ)

ノブのラベルはどう配置するべきか

特に気にしていない人には本当にどうでも良い話だとは思うのだけど、GUI画面のツマミの周辺の配置をどうするべきかちよっと迷ったりする事が多いんですよね。つまり、下の図のラベルとリードアウトをノブに対してどこに配置するかという話です。

幾つか考えるべき点はあって、まず実際のハードウェア機器ではリードアウトは普通存在しないので、ノブとラベルの位置関係だけになります。これがどうなるかというと、世の中の趨勢としても個人的な嗜好としても、家庭用オーディオやラックマウント機器のようなものならラベルはノブの上、小型のガジェットや鍵盤付きシンセのような平置きして使うものなら下、かなあ。絶対ではなくてあくまで傾向ですけどね。

というのも実際のハードウェア機器だと視線の問題があって機器の形によって見下ろす視線で使うものと見上げる視線で使うものでノブの陰にならないようにしないと使いづらいという事情があります。

ソフトウェアGUIになるとどこに置いても陰にはならないのでこういう呪縛がなくなるわけですが、ハードウェア機器へのリスペクトの高さによって、傾向としては残るんでしょうね。ハードウェアエミュレート系のソフトウェアならなおさらです。

そして現在のパラメータを表示するリードアウトですが、エミュレーション系ならそんなもの付いてないのが当たり前なんですが、せっかくのソフトウェアのメリットでもあるので個人的には付けたくはなりますね。

という事で身の回りの音楽系プラグイン等を数十程度ざっと見てみたのですが、まずラベルがノブの上に来るのか下に来るのかという事で言えば、下派がやや優勢で、上40%、下60%程度かと思います。やはり家庭用オーディオ機器よりもシンセやストンプエフェクターなんかの方が近い存在なんですかね。

そしてやや意外だったのが、リードアウト付きの比率が結構低いようです。リードアウト付きは全体の20%～30%程度でしょうか。付けても機能的にマイナスになる事は基本的に無いと思いますが、これはやはり楽器系ソフトウェア特有のハードウェアリスペクトの高さによるものなのでしょうか。

それで全体の2～3割の選択として、リードアウトを付けるとすると、ラベルとの配置の兼ね合いが割と厳しくなります。上か下ははともかく、ラベルとリードアウトを同じ方向に付けると下の図のようになるわけですが、やっぱりちょっとごちゃごちゃした感じになってしまいます。実際こういうパターンのもそれなりに存在するし駄目ではないんですが。

という事で結局ラベルとリードアウトをそれぞれノブの上と下に振り分けるというパターンが無難な感じにはなるんですが、それで上下にどう振り分けるかとなると、どっちを重視するかみたいな話で、どうするのが良いかもうわからない。ただ個人的にはラベルを上、リードアウトを下という方向でなんとなく収束しつつある気はしています。

大して変わらんと言えば変わらんのだけど、ただ、1画面内でラベルが上にあったり下にあったり混在しているのは流石に避けるべきかなとは思います。

Posted by g200kg : 2:31 AM : PermaLink

2020/07/20 (2020年07月のアーカイブ)

webaudio-controlsのフロントページを作りました

今まで GitHub にそのまま置いていただけなのですが、ちょっとそれらしい形にしました。

そしてアプリケーションノート的なドキュメントも書こうとして色々と実装が不完全な所が露呈して結構本体にも手を入れる事に。@atsushieno さんのKnobのサイズの件とかも。まだ完全に理想通りではないかもだけど。

ついでに npm パッケージ (g200kg/webaudio-controls) にしてあります。なお npmjs ではなくて GitHub Packages なので npmjs しか使っていない人は少しだけ npm の設定が必要になります。

https://g200kg.github.io/webaudio-controls/docs/index.html

Posted by g200kg : 2:03 PM : PermaLink

2020/07/08 (2020年07月のアーカイブ)

ADSR がチョットワカルようになる記事

これまでに ADSR 関係の記事を幾つか書いてきたのだけど、ADSR についてはまだ言いたい事があるのだ。あなたの ADSR の実装、間違ってないだろうか? と。ADSR はシンセを構成するモジュールとしては簡単な方だし、ソフトウェアで実現するのもそれほど難しくはない。が、ここで説明する点は特に勘違いしやすいので注意して欲しい。

ADSR はざっくりと下の図のような説明がされている事が多い。ADSR の概要を説明するにはこれで問題はないのだけど、この図を見て、「完全に理解した。アタックのピークを過ぎた後は、減衰の曲線が Key On の間は Decay で Key Off になると Release に切り替わるんだね」と言う風に理解してしまうとまずい事になる。

次のような設定にした時を考えてみる。
Decay ⇒ 小、Release ⇒ 大、Sustain ⇒ 小。

音の出始めにガツンと強いピークがあり、そのまま消えるのではなく、その後も薄く鳴り続けリリースの消え際も長い、という感じの音だ。これでアタックのピーク近くの瞬間にキーを離してしまったらどうなるか...。

「Key Off になるとディケイからリリースに切り替わる」だと、緑の線のようになりますよね。これに違和感があるのは明らかでしょう。アタックの一瞬だけのはずだった音量でしばらく鳴り続けるのだから。
正解は次の図

紫の線のように KeyOff の後、Sustain レベルまでは Decay の速さ + Release の速さで減衰しないといけない (減衰は漸近線なので、Decay の減衰カーブだけの場合は Sustain レベルに辿り着けないのはわかると思う)。

また Attack のピークに至る以前に Key Off が発生した場合も同様で、次の図のように Key Off 時点の現在値が Sustain レベルより高い間は Decay の減衰 + Release の減衰、現在値が Sustain レベル以下ならば Release の減衰が適用される。

つまり Decay の減衰の発動条件は、
　「Attack フェーズ以外で、現在の値が Sustain レベルより高い時」であり、
Release の減衰の発動条件は
　「Attack フェーズ以外で、現在のキーの状態が Off の時」なのだ。
そしてこの二つの減衰は重なり合う事もある。
また Attack フェーズとは、
　「Key On でトリガーされてから現在値を増加させて行き、ピーク値に到達する、または Key Off になるまで」である。



if( detectKeyPositiveEdge )
    AttackPhase = true
if( CurrentValue >= PeakLevel or Key == OFF )
    AttackPhase = false
if( AttackPhase ){
    increase CurrentValue by AttackRate
}
else{
    if( CurrentValue > SustainLevel )
        decrease CurrentValue by DecayRate
    if( Key == OFF )
        decrease CurrentValue by ReleaseRate
}

これだけの事で以前書いたリトリガーの問題も解決する　(そして残念な事に、このように現在の値を基に曲線をトリガーしたり、複数の減衰曲線を重ねたりしようとすると Web Audio API のオートメーション関数ではとても面倒な事になるのだ)。

ハードウェアで作る時は大体参考にする公開された回路図通りに作る事から始めるケースが多いので間違える事は少ないのだが、ソフトウェアでは最初の ADSR の波形を見ながらスクラッチから自分で実装しようとして失敗する場合があるので気を付けて欲しい。

Posted by g200kg : 9:31 PM : PermaLink

2020/07/08 (2020年07月のアーカイブ)

新しいWebSynthを作ってみた (WebGrowler)

先日 AudioWorklet で ADSR を出力するノードを作ったのですが、これまでに他にも楽器系に使える各種ライブラリを作ってきたのでそのあたりを全部まとめて使ってみようか、という事で作ってみました。

WebGrowler という名前です。コンセプトとしては、「適当にツマミをいじってもそれなりに派手な音がする」です。audioworklet-adsrnode は ADSR をノードの出力として出せますので、音信号だけでなく制御系信号をノード間の connect() で処理できるのが特長です。これを活かすためにエンベロープと LFO をソースとする大き目のモジュレーションマトリックスを付けてあります。

使用しているライブラリは次のとおりで、どれも GitHub に置いてあります。

webaudio-controls : 楽器系 GUI パーツライブラリ

webaudio-pianoroll : ピアノロール表示ライブラリ

webaudio-macronodes : Web Audio API のノードとして動作する各種エフェクターライブラリ

audioworklet-adsrnode : ADSR カーブを出力する audioworklet ノード

GitHub Repository : https://github.com/g200kg/webgrowler

デモページ : https://g200kg.github.io/webgrowler/demo.html

Posted by g200kg : 2:15 PM : PermaLink

2020/07/04 (2020年07月のアーカイブ)

デノーマル問題は今どうなっているのか

もう今から 10 年近く前の話になりますが、ソフトシンセ等の楽器系ソフトウェアではデノーマル問題というのがちらほらと起こっていました。これは扱うデータが通常の浮動小数点では表現できないほど小さい ( 0 に近い) 状態になると、単に 0 に切り捨てるのではなくて CPU がデノーマルモードという特殊なモードで近似的に扱う代わりにパフォーマンスが極端に悪い状態になる事を指します。

ソフトウェアのジャンルによってはこれでも特に問題はなかったのですが、楽器系ソフトウェアはリアルタイム処理が命で処理が間に合わないとノイズが発生する等の結果になったりしますので特に敏感だったわけです。そしてこの問題はネイティブアプリだけではなく、Javascript 上でも同じように存在していて Web アプリでシンセを作ろうとするとやはり気にしないといけなった、というのが大体 9 年前。↓の記事でブラウザ上のデノーマル問題について少し検証しています。

「Javascriptでもデノーマル問題はあるんだよ!」

その後、Chrome のバグトラッカーにこの問題があがって対策されたのが 5、6年前くらい。これでもう Web アプリでデノーマルに悩まされる事は無くなるのかなー、やったね。
という事があって、もうデノーマル問題の存在すら忘れかけていたのですが、今になってちょっと引っかかった問題をきっかけにこのあたりを掘って見ると、見つけてしまいました。デノーマル再来。

問題は TypedArray です。

倍精度の場合は
$ 2.22 \times 10 ^{-308} $、

単精度の場合は
$ 1.17 \times 10 ^{-38} $

あたりよりも 0 に近くなるとデノーマルモードに入ります。Javascript の通常の変数の場合はすべて倍精度浮動小数点として扱われ、10のマイナス308乗あたりよりも小さくなるとデノーマル状態になりますが、どうやら何らかの対策が行われていて特にパフォーマンスが落ちるという事はないように見えます。しかし、これが TypedArray、Float32Array や Float64Array の場合は、昔のようにデノーマル状態でパフォーマンスが 5～6 倍程度落ちるようです ~~(昔よりはパフォーマンスのペナルティは低くなっているようですが)~~。

下に検証用のコードがあります。javascript の通常の変数、Float32Array、Float64Array についてそれぞれ変数の値に 0.1 を掛けて行き、時間を測定しています。
これをそのまま Javascript コンソールに貼り付ければ実際に結果を見る事ができます。


for (f = 0.1; f != 0; f *= 0.1) {
  Time1 = performance.now();
  for (var i = 0; i < 1000000; ++i) {
      result = f * 0.1;
  }
  Time2 = performance.now();
  document.write((Time2 - Time1)+"mSec , "+result+"<br/>");
}
document.write("Loop Exit!! (Normal Variable) <hr/>");

a=new Float32Array(3);

for (a[0] = 0.1,a[1] = 0.1; a[0] != 0; a[0] *= a[1]) {

  Time1 = performance.now();

  for (var i = 0; i < 1000000; ++i) {

      a[2] = a[0] * a[1];

  }

  Time2 = performance.now();

  document.write((Time2 - Time1)+"mSec , "+a[2]+"<br/>");

}

document.write("Loop Exit!! (Float32Array) <hr/>");

b=new Float64Array(3);

for (b[0] = 0.1, b[1]=0.1; b[0] != 0; b[0] *= b[1]) {

  Time1 = performance.now();

  for (var i = 0; i < 1000000; ++i) {

      b[2] = b[0] * b[1];

  }

  Time2 = performance.now();

  document.write((Time2 - Time1)+"mSec , "+b[2]+"<br/>");

}

document.write("Loop Exit!! (Float64Array) <hr/>");

さて、この結果は下の図のようになりました。左側が通常の変数の場合です。デノーマル領域を超えて 0 になるまで特に処理時間に変わりはないようです。しかし、

右側上 Float32Array の場合は $1.17 \times 10^{-38}$
右側下 Float64Array の場合は　$2.22 \times 10^{-308}$

よりも小さいデノーマル領域では処理時間が落ちているのがわかります。

昔みたいに何十倍も遅くなるという程ではないので致命的な問題にはなりにくそうではありますが、逆に、パフォーマンスいまいちだなーとか思いながら気が付かずに使ってしまうという事がありそうですね。 TypedArray を使う時には気を付けた方が良さそうです。

-----(2020/07/04) さっそく追記ですが-----

昔よりデノーマルのペナルティが低くて 5～6 倍というのは勘違いだったようです。事態はもっと深刻とも言えます。
という事で検証用の式と結果を訂正します。

検証で使用した計算式が元は、通常の変数 = Float32Array * 通常の変数になっていました。
この場合、通常の変数にデノーマル数をロードするのが遅いという事はわかりますが演算自体はデノーマルのペナルティが発生しない通常変数で行われています。

Float32Array = Float32Array * Float32Array のように TypedArray のままで演算自体が完結する場合、デノーマル数が発生すると通常の場合よりも 20 倍程度時間がかかるようです。

ただし、TypedArray の演算は通常の変数よりも高速ですのでそれに比べて、という話になります。高速なはずの TypedArray なのにデノーマルを発生させてしまうと通常の変数よりも遅くなってしまうという事でもあります。TypedArray を使う場合は十分に注意する必要がありますね。
なお、この件は Chrome、Firefox 共同じ現象になるようです。

Posted by g200kg : 11:47 AM : PermaLink

2020/06/30 (2020年06月のアーカイブ)

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 (2020年06月のアーカイブ)

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 (2020年06月のアーカイブ)

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 (2020年06月のアーカイブ)

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 (2020年06月のアーカイブ)

Web Audio API が更新

昨日6月11日に W3C で公開されている WebAudio API が「W3C Candidate Recommendation, 11 June 2020」として更新されました。

Web Audio API

前回の更新で 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/01 (2020年04月のアーカイブ)

3Dプリンターで作るマスク

コロナ騒ぎでマスク不足の中、イグアス社が3Dプリンター製マスクのSTLデータを公開したと聞いて、家のプリンターで出力してみました。フィルター部は布なり紙なりを自分で張り付けてくださいという事です。

公開ページ :
https://www.iguazu-xyz.jp/knowledge/trend_02

男性用 / 女性用 / 子供用があり、それぞれ厚手と薄手があります。厚手は2mm 薄手は1.2mm くらいの厚さになっています。割れてしまったりしやすそうではあるけど、可能なら薄手の方が良さそうです。家庭用のFDMプリンタではまあまあ難易度は高目ですが頑張ればいけます。

薄手をABSで出力するとそれなりに弾力があるので顔にフィットする感じになりますが、顔に接する側にサポートがびっちり付くので丁寧に取らないとマスクを付けた時に顔にパリが刺さって痛いです。

なお横幅が150mm程ありますので、造形サイズはそれ以上のプリンターが必須です。

この、マスクが足りないなら3Dプリンターで作ろうぜ、という動きは海外のコミュニティー等でも行われているのですが、いかつい感じのが多くてちょっと不審者ぽくなりそうです。イグアス社のはおとなしめで普通に使えるイメージですかね。日本の会社なのでサイズも平均的な日本人に合ってそうです。

対コロナウイルスツールコレクション:
https://cults3d.com/en/collections/useful-3d-printed-coronavirus-covid19-tool

Posted by g200kg : 9:32 PM : PermaLink

2020/03/23 (2020年03月のアーカイブ)

favicon は丸くしようか

去年の9月頃から Chrome でウェブページを表示する際のタブ内のロード中に回転するアニメーションで favicon が表示されるようになりました。

気にするかどうかはデザインにもよると思いますが、角型を目いっぱい使っていると角が欠けてしまっていまいちな感じになりますね。丸形に切り取っても不自然にならないようにした方が良さそうです。更に、ロード中の favicon は微妙に縮小されているようなので確認してみた所、通常 16x16 で表示されている所が 10x10 になっています。

10x10 で表示して丸形に切り取ってもちゃんと視認できる、というのが今後は必要なんですかね。

Posted by g200kg : 12:03 PM : PermaLink

2020/03/11 (2020年03月のアーカイブ)

スナップ式ユーロラックレール

Twitter の方には昨日動画をあげてしまったのですが、スナップ式のユーロラックレール (43HP) を DMM.make のクリエイターズマーケットに登録・公開しました。これは見ていただけれはわかると思いますが、ユーロラックモジュラーシンセのケースを作るためのもので、モジュールをハメ込むだけで固定する事ができるようになっています。

サイドパネルを留める穴はタカチの FFR レールと同じ位置になっていて、先日別途公開したサイドパネル(eurorack_side_2)を使って組み立てる事ができます。

このレールには上下があります。並んだ穴が開いているのが上側のレール、穴がないのが下側のレールです。窓や引き戸等をハメ込むような感じで上側に押さえつけながら入れると入るようになっています。

DMM.make クリエイターズマーケット : Eurorack_rail_snap_43HP

組み立てた状態はこんな感じになります。

また、しっかりとモジュールを固定したい場合は上面の穴に M3 x 6 のネジ (モジュールに良く付属しているサイズ) を入れて締めると完全に固定されます。

組立には M4 x 10～16 程度のタッピングネジが必要です。Amazon等で「M4 タッピング」等で探してください(タカチのレール付属のネジでも良いです)。
対応できるモジュールのパネルの厚さは 2.0mm まで (TipTop Audio の uZEUS の厚さ) です。それ以上厚いパネルのモジュールは止められません。
素材はナイロン樹脂、白のみです。

ネジをいちいち外してのモジュールの入れ替えの面倒臭さはユーロラックモジュラーを触った人じゃないとわからないかも知れませんが、とにかく面倒です。構造的にかなりの高精度な3Dプリンタでの出力が必要なので、小ぶりの割にはどうしても結構値が張る感じになってしまいますが、色々と組み合わせの実験用としていかがでしょうか。

DMM.make のクリエイターズマーケットでどなたでも注文が可能です。
(注文があってから出力するので届くまで1週間近くかかる事もあります)

Posted by g200kg : 6:37 PM : PermaLink

...更に以前の記事...

g200kg

最近の記事

関連記事