« 2015年12月 | 2016年01月のアーカイブ | 2016年02月 »
2016/01/23
Web Audio API に NoiseGeneratorNode が欲しいな
Web Audio API にノイズジェネレータが欲しいな...みたいな事をGitHubのissueに書き込んだら、意外とみなさん乗り気なんだね。
なんだよみんな欲しかったのかよって。今まで一向に出てくる気配がなかったから、もうどこかで「いらないだろ」的なポリシーが出来上がってるのかと思ってました。
まあ今から本当に仕様のディスカッションが始まったとしても、実際にブラウザにポーティングされるのはいつになるやらわかりませんけど。
今まで適当なノイズは多分みんな ScriptProcessor で生成したりしていたのだと思うけど、Deprecated になっちゃったし、いいタイミングではあるよね。
https://github.com/WebAudio/web-audio-api/issues/705
posted by g200kg : 10:45 AM : PermaLink
2016/01/20
Web Audio API メソッドチェーン
Web Audio API の WD10-Oct-2013 と WD08-Dec-2015 の違いとしてメソッドチェーンに関するサポートがあります。両者のIDLを並べてみるとこんな感じになります。
一番上の connect(AudioNode) の戻り値が void から AudioNode に変わっています。ここで返されるAudioNode は接続した先の AudioNode です。これで何がしたいのかというと...
var ctx = new AudioContext(); // オーディオコンテキストに...
var osc = ctx.createOscillator(); // オシレータと
var gain = ctx.crateGain(); // ゲインがあるとして
// 今までは
osc.connect(gain); // オシレータをゲインに繋いで
gain.connect(ctx.destination); // ゲインをデスティネーションに繋ぐ
//だったのが、これからは
osc.connect(gain).connect(ctx.destination); //オシレータ => ゲイン => デスティネーション を一気に繋ぐ
同じように AudioParam のオートメーションに関しても API が変更されています。
オートメーションメソッドの返り値が軒並み AudioParam に変更されています。 connect に比べるといまいちですが、こんな書き方でしょうか。
ctx = new AudioContext();
gain = ctx.createGain(); // ゲインがあります
// 今までは
gain.setValueAtTime(1, ctx.currentTime + 0.1); // 0.1Sec後に 1
gain.setValueAtTime(0, ctx.currentTime + 0.2); // 0.2Sec後に 0
// だったのがこれからは
gain.setValueAtTime(1, ctx.currentTime + 0.1).setValueAtTime(0, ctx.currentTime + 0.2);
// 一気に0.1Sec後に1、0.2Sec後に0
posted by g200kg : 5:27 PM : PermaLink
Web Audio API WD08-Dec-2015 日本語訳完了
Web Audio API Working Draft 08-Dec-2015 翻訳完了しました。
http://g200kg.github.io/web-audio-api-ja/
Working Draft としては WD10-Oct-2013 から2年振りの更新ですが、どう変わったのか軽く見てみます。
ScriptProcessor の廃止予定と AudioWorker の追加
JavaScript で直接音データを操作する ScriptProcessor ノードが廃止予定となり、代わりに AudioWorker が定められました。変更として多分これが一番大きいもので、仕様書上も AudioWorker 関係がかなりの部分を占めています。
そして困った事にこの AudioWorker を実装したブラウザはまだ存在しません。@mohayonaoさんが polyfill を作ったりしていますので、試してみたい方はこのあたりを見てください。
AudioWorker を試してみる
AudioWorker は JavaScript でマルチスレッドを実現する WebWorker の応用で今まではメインスレッド1本でオーディオ処理までやっていたのをスレッドを分けられるようになります。それから自分専用のカスタムノードとして AudioParam パラメータを追加して別ノードから接続する機能があったりファクトリ経由なので複数のノードを作ったりが簡単にできるようになります。ただしワーカー用スクリプトを準備したりと今までと比べるとちょっと扱いは面倒です。
今のところまだ ScriptProcessor がすぐに使えなくなる訳ではないですが、今から何か作るならどうするかと言われるとなかなか微妙ですね。
実は ScriptProcessor は問題があったんだよ-みたいな言い訳じみた文章が仕様書にひそかに入っています。
「実装は一般的に AudioContext の currentTime と AudioProcessingEvent の playbackTime の差を最小化する事を目指します。 ScriptProcessorNode が廃止予定となった事でこの考慮はその内問題とならなくなるでしょう...」
Context の suspend / resume / close
AudioContext を一時停止したり再開したりできるようになりました。使わなければ使わないで困る事もないですが、これは基本的にモバイル系機器等でハードウェアを一時休止してパワーダウンしたりできるようにする事が目的のようです。実装も既に入っているようですが、ちゃんと機能しているのか私も確認していません。
Promise 化
オーディオデータをデコードする decodeAudioData とオフラインのレンダリングをする startRendering は Promise を返すようになりました。
関数名はそのままですので、新しい API がサポートされているのかどうかちょっと気を付けないといけません。まあこれは最近の HTML5 的に時間がかかる処理のコールバックを止めて Promise にしようみたいな流れですが、ばっさり切るわけには行かなかったようで、仕様書にも「歴史的な理由からコールバック"も"サポートします」みたいな文言が入ってしまってたりします。
StereoPanner の追加
今までも Panner は存在していたのですが、いわゆる 3D ゲーム系に適した API になっていて音楽系アプリで良く使われるステレオのパンを振る機能がないという状態だったのですが、これで解消されました。他のノードからの接続でパンを制御する事もやっと普通にできるようになったのでオートパンが一発で作れるようになりました。
SpatialPanner の追加 (そして今までの Panner が廃止予定)
今までの Panner に相当する 3D 系のパンナーが SpatialPanner になって古い Panner は廃止予定(仕様書上まだこのあたりが混乱してます)です。今までのパンナーはパラメータが AudioParam でなくちょっと異質だったのですが、今度はちゃんと AudioParam 経由になっています。
IIRFilter の追加
BiquadFilter だけじゃ満足できない人用に汎用 IIRFilter が追加されました。伝達関数の分子分母の係数を自由に指定できますが、どちらかと言えば BiquadFilter でできなかった奇数次フィルター用で、パフォーマンス的に BiquadFilter で済むなら BiquadFilter を使ってくださいというスタンスです。
ノードの disconnect が割と柔軟になった
実際にアプリを作るとノードを繋ぐのは良いとして切断するのがまとめて切断しかできずに困ったりしていたのですが、コネクションを１つずつ自由に繋いだり切ったりできるようになりました。意外と便利(というか今までが不自由)
後、こまごまとメソッドが追加されたり、挙動が変わったり....
AudioBuffer の copyFromChannel / copyToChannel --- バッファの部分的な読み出し/書き込み
AnalyserNode の getFloatTimeDomainData --- Floatでの時間領域データ取得
BiquadFilter パラメータが a-rate に
・
・
・
色々あるのですが、後ドキュメントとして今まで実装から想像するしかない曖昧だった所がかなり加筆されています。
◆ FFT の窓関数のかけ方とか
◆ フィルター係数の算出方法とか
◆ オシレータの位相の決め方とか
これ真面目に全部読めば、なかなかためになる文書だと思いますよ (以前からコンポリューションリバーブのディレイを抑える実装方法とかも入ってたしね。今凄く見つかりにくい奥の方に入ってるけど)。
posted by g200kg : 4:55 AM : PermaLink
2016/01/17
Web Audio API 日本語訳更新
Web Audio APIのWorking Draftが2年ぶりに08-Dec-2015版に更新されていますので、日本語訳の方にも手を付けました。
中身の方がもうごっそりと変わっていますので文章の差し替えレベルでは済まず、全体をやり直すのに近い作業が必要でまだ半分できてない気もしますが、とりあえず懸案の suspend、resume、close、AudioWorker 周りだけは翻訳したので公開しています。
http://g200kg.github.io/web-audio-api-ja/
大きな変更点としては、AudioWorker、Contextのsuspend/resume/closeあたりですが、他にもdecodeAudioDataとstartRenderingのPromise化、StereoPanner、IIRFilterなどかなり変更が入っています。肝心のAudioWorkerのブラウザへの実装がまだpolyfillしかありませんので、ちゃんと触ろうにも触れない微妙な状態がまだ続きますが、とりあえず気になる追加されたノード周りを優先的に順次日本語版を整備していきます。
posted by g200kg : 10:05 PM : PermaLink
2016/01/13
KiCad用標準ロジックライブラリ CD74HCxx.lib作りました
ここに置いてあります
CD74HCxx.zip
全部を一覧できるように並べた図がこちら
CD74HCxx.pdf
今年に入ってからKiCadを触り始めていてまあ結構使えるかなとは思っているのですが、やはり部品ライブラリについては自前での整備がかなり必要そうです。取りあえずこれはどうしたものかと思ったのが標準ロジックのシンボルなのですが、サイズがでかいんです。
ゲート1個がオペアンプよりかなり場所を取るのはなぁ...どうもなぁ...。
デジタルオンリーで書いてる内は良いかも知れないけど混ざるとかなりの違和感。遠近感がおかしい感じに。
という事で自分が使う奴だけでもと思ってちまちま作り直しはじめたのですが、
それが結構揃ってきてしまったのでまとめておきました。単体のロジックICは流通量も少なくなってきていますが、74HCxxシリーズで現在でも千石電商とか秋葉原の店で普通に入手可能なものだけ90種を詰め込んであります。逆に言えばこのライブラリ内のものだけで組めば(当面は)部品入手で困る事はないかと思います。
できれば本家にマージしてもらえれば良いんですが、過去の遺産との互換性やら何やらもあるしなかなか大変そうです。使いたい人はご自由にどうぞ---
- 一部作ったものの方が幅が広がっているものがありますが、これはKiCadの新しいライブラリルールで「端子を100milグリッドに載せる」というのがあるのを意識しています
- ピン名はデフォルトのライブラリはモトローラぽいのですが、これはTIのピン名に準じています
- 電源ピンの扱いはKiCad本家でも色々議論されているようですが、とりあえずデフォルトライブラリと同じで各ユニットに非表示でくっつけています
posted by g200kg : 7:25 PM : PermaLink
2016/01/06
EagleからKiCadに乗り換えてみる?
今まで基板を作る時はCadsoft社のEagleというCADを使っていたのですが、今年はEagleのライバルであるKiCadというものも使ってみようかと思っています。それぞれどんな感じかと言うと、
・Eagle --- 基板CADとしては低価格で、小さな基板で非商用ユースならフリーで使えます。DIY系のユーザーの絶大な支持があり、ライブラリは充実しています。特に部品メーカー自身がEagle用のライブラリを公開している場合もあり、そのまま使えると凄く楽ができます。操作体系は癖があるにしてもこなれていますので機能面でそんなに不足はありません。
http://www.cadsoftusa.com/
・KiCad --- オープンソースの基板CADでCERNがサポートを表明して最近勢いづいている感じです。ライブラリはまだまだ少ないので基本的に自前で部品ライブラリを作る覚悟が必要です。操作体系はやっぱり癖があります。いいところと足りないところがそれぞれ結構あります(個人的な感想)。
http://kicad-pcb.org/
左がEagle、右がKiCadの画面で、結構似た感じになっています。
最大の違いはライブラリの構成で、Eagleの場合回路図のシンボルと基板上のフットパターンが密結合、KiCadは疎結合になっています。このため基本的なワークフローに違いがでてきます。
EagleでもKiCadでも回路図をかくためには部品のライブラリがまず必要なのですが、Eagleの場合は回路図をかき始める前に回路図のシンボルと実際の部品外形に基づいた基板上のフットプリントを用意する必要があります。KiCadの場合はとりあえず四角にピンを並べただけの回路図シンボルでも用意すれば回路図をかき始める事ができ、基板のパターン設計を始める段階でフットプリントに割り当てる事ができます。
まあ最終的に基板レイアウトまでちゃんと作るのなら必要な作業を先延ばしにしているだけではあるんですが、ちょっと試しに回路図をかいてみようかなという時に、ライブラリにない部品を使おうとするとEagleの場合フットプリントがどうなっているかまでいちいち気にしないといけないのでテンションが下がる事はあります。逆にKiCadだと回路図から基板レイアウトに移る時に部品１つ１つについてフットプリントの割り当て作業が必要になるのでこれを面倒と思うかどうかが分かれ道かも知れないですね。
その他、KiCadに関してあれこれ
・Eagleに慣れている人はデフォルト設定だと拡大縮小時にカーソルを見失いがち。「拡大縮小時にカーソルを中心へ移動」のオプションは外した方が良い
・とりあえずキーボードショートカットを覚えないとまるで効率が上がらないので M / R / C / V / E / Delあたり必須
・ブロック操作関連がEagleに比べてちょっといまいち感があるけどとりあえず慣れるしかないか
・ワイヤーをひいたり消したりして残るジャンクションが面倒。自動で消してくれれば良いのに...
・点Aから点Bにワイヤーを引く時にEagleだとメニューでの切り替えが必要で面倒だった曲がり方がマウスの動かし方だけで指定できたり些細な所で気が利いてたりする
・基板の3D表示機能が割と楽しい。3Dモデルを自分で作る気があればこんなのもできる
「火を噴く電解コンデンサ」
(この3Dモデルはここにあります。 20160106ecap5fire.x3d)
・使えるオートルーターは外部に頼っています。Webアプリのfreerouting.netとのI/Fが準備されていますが、最近このfreerouting.netが諸般の事情により公開を終了したようです。外川さんのページにfreeroutingをスタンドアローンで使う方法が説明されていますが、自分でビルドする必要があり結構手間です。今後どうなるかちょっと不安。
http://www.geocities.jp/kiki3000x/mouse_TechInfo.htm
こんな感じなのですが、自分でライブラリを作る覚悟があるなら結構使えるのではないかと思います。最初のとっつきはあまり良いとは言えないので、いきなり触って覚えるより、基本操作は一度ちゃんとドキュメントを読んだほうが良いかも知れません。日本語のドキュメントもかなりしっかりしたものが整備されています。
ちなみにkicad.jpの中の人のツイッターが実はbotではないかという疑いがあるくらい、kicadという単語の入った使い方がわかんねー的なツイートをするとすぐに補足されて回答が来たりしますので困ったらツイートしてみるのも良いかも知れません。
posted by g200kg : 3:57 PM : PermaLink
« 2015年12月 | 2016年01月のアーカイブ | 2016年02月 »
-->
g200kg