年末なので今年書いた npm モジュールをまとめてみます。 OscMsg v0.3.0 OSC のメッセージを JSON にデコード/エンコードするライブラリ。去年からちょくちょく OSC を使って Node.js と openFrameworks や Max/MSP と連携する案件を手伝ったりしていたので非常に重宝した。似たようなライブラリに node-osc-min というのがあるのだけど、壊れたデータを渡したときに例外が出るのとかブラウザ対応がいまいち気に入らなかったので自分で作った。とはいえブラウザで使うことはないなーという印象。 WebAudioScheduler v1.0.0 Web Audio API を使うときに必読の この記事 をベースに作ったスケジューリングライブラリ。時間と関数とパラメータを登録しておくと良いタイミングで呼び出してくれる。Web Audio API を

7月25日に WebMusicハッカソン #4 @kyoto というのがあるのですが、ちょうど良い機会なので僕が作ったウェブ音楽用簡単超絶便利ライブラリを紹介したいと思います。 WEB AUDIO SCHEDULER 2 つの時計のお話 - Web Audio の正確なスケジューリングについて - HTML5 Rocks Web Audio で必須な割に難しいのがスケジュール管理で、いちおう上の記事のやり方が推奨なのですが、そのままやるとかなり面倒くさい。のだけど、このライブラリを使うと面倒な部分は気にせず、いつ何をしたいのかを書くだけで良くなる。以下は簡単なメトロノームの例。 var gcguard = []; var audioContext = new AudioContext(); var scheduler = new WebAudioScheduler({ context: a

またか。と言われてしまいそうだけど、またウェブ楽器プログラミング用のライブラリを作った。 以前に timbre.js というライブラリを作ったのだけど、それの刷新版という感じです。 デモ ドキュメント 名前の由来 特徴1: 機能性よりパフォーマンスを重視 以前は多くの動作環境をサポートするためにすべての信号処理を JavaScript で書いていたのですが、それゆえにパフォーマンスに問題があって(Issueでよく指摘された)、neume.js では IE や node.js での動作を諦めて Web Audio API の機能を大活用することでパフォーマンス問題を解決しました。デモでは three.js や gretro と一緒に動作する様子が確認できます。 特徴2: Web Audio API の面倒な部分を抽象化 Web Audio API は多機能なんだけど、部品が細かすぎて使いこな

使い所皆無なんだけど、このプログラムは JavaScript だと "JavaScript" と評価されて CoffeeScript だと "CoffeeScript" と評価される。 { JavaScript: ["CoffeeScript"] }["JavaScript"][0] 検証用コード code = '{ JavaScript: ["CoffeeScript"] }["JavaScript"][0]'; // "CoffeeScript" と評価される eval(CoffeeScript.compile(code, {bare:true})); // "JavaScript" と評価される eval(code); こうしてしまうと、観察者効果でどちらでも "CoffeeScript" と評価されてしまう。 a = { JavaScript: ["CoffeeScript"] }

「CoffeeScript を SuperCollider みたいに処理をしよう ♪♪」をコンセプトに開発していたブラウザ音響プログラミング言語 CoffeeCollider をリリースしました。音響プログラミング言語ということで、とにかく試して聞いてもらうのが手っ取り早い。以下のリンク先で "BOOT" と "RUN" すれば深夜っぽい音が鳴ります。 CoffeeCollider で、なんなの？ SuperColliderってなんだ？という人には 言語 & ライブラリ & 実行環境 という意味で processing.js の音楽版と言った方が分かり良いかもしれない。とにかく音がでる。音しかでない。とにかく音を出してほしいという気持ちで作った。最初はいい加減な気持ちでやっていたのだけど途中から結構がんばりだして、最終的にはカレーを食べにいく趣味ができました。 CoffeeScript拡張

grunt-este-watch で幸せになれるらしいと聞いて試した。 grunt-contrib-watch が重いので grunt-este-watch を試したら幸せになった - てっく煮ブログ そしたら凄く良かったという話です。 CPUの消費量は気にしていなかったのだけど、変更のあったファイルに対して柔軟にタスクが組めるのが非常に便利。今まで変更があるたびに関係ない部分もテストしていたり、それをなくすために複雑な方法を使ったりしていたけどだいたい解決した。しかも速くなった。 今までやりたかったこと 更新したファイルのみ jshint したい 更新したファイルに関連するテストだけ行いたい 更新したテストファイルのテストだけ行いたい 失敗したテストは次回もテストしたい こういうことをしようとしたとき、grunt-contrib-watch ではやりにくかった。というのもサブプロセスでタ

WebWorker は便利だけどデバッグしにくい。僕は根っからのプリントデバッガーなんだけど、WebWorker は console.log が使えなくて困る。しかし泣いてばかりもいられない。 WebWorker で console.log を使う WorkerConsole というやり方がある。下記は簡略版だけど、WebWorker側に console というグローバル変数を用意して、log とか error メソッドで呼び出し元に引数を postMessage する。そして、呼び出し元の onmessage でコンソールに表示する。 このやり方には若干問題があって、postMessage を通過出来るものしか表示できない。つまりオブジェクトを表示して DevTools で属性を確認したりとかできない。 // worker.js global.console = {}; ["log",

独立したスクリプトを grunt でそれぞれ watch して変更があったらコンパイルみたいなことをやっていたのだけど、毎回全ファイル処理すると時間がかかってイライラする。変更があったファイルだけ処理する方法が分からず、ずっと悩んでいたのだけどやっと出来たのでメモ。他に良い方法ありそうなので知っていたら教えてください。 とりあえず全ファイルを対象にする 変更のあったファイルをメモっておいてフィルタリング options:nospawn:true がないと子プロセスで呼ばれてメモった内容が消える 追記３ http://mohayonao.hatenablog.com/entry/2013/03/26/093554 追記２ コンパイルエラーがあった場合、grunt自体が止まるので良くなかった。。 追記 grunt-contrib-watch じゃなくて grunt-regarde だと nos

新しく書き直した。 以前のバージョンと全然互換性がなくて申し訳ないのだけど、可読性とかかなり使い勝手が良くなっていると思います。ライブラリ自体のコードも分かりやすくなっているはず。 http://mohayonao.github.com/timbre.js/ Chrome, Safari, Firefox あと node.js で使えます。 あとついでに SuperCollider みたいな関数を集めたものも用意しました。 http://mohayonao.github.com/subcollider.js/ timbre.js と合わせてアルゴリズム的なものを作るのに使えます。 デモ どういうことができるのかは簡単なデモで確認できます。 http://mohayonao.github.com/timbre.js/beatbox.html http://mohayonao.github.c

Chrome24 と 自作ライブラリのデモページ で確認。 OSごとに以下のバッファサイズを使用するとブチブチにならない。 OS BufferSize OS X 1024 Windows 7 1024 Windows XP 4096 Linux (Ubuntu) 8192 たぶんこんな感じで切り分けする。 var bufferSize = 1024; var ua = navigator.userAgent; if (ua.match(/linux/i) { bufferSize *= 8; } else if (ua.match(/win(dows)?\s*(nt 5\.1|xp)/i)) { bufferSize *= 4; } 簡単にチェックできるページもつくった https://dl.dropbox.com/u/645229/webaudioapi/scriptnode.html

Web Music Developers JP Advent Calendar 2012 の 12日目です。 前回の記事では信号処理用の簡易インターフェイスを紹介しましたが、今日は内部でどういう処理を行なっているのかという話です。 といっても、音を作るための高度な信号処理の話ではなくて、各APIごとの簡単な使い方とブラウザによって使えるAPIが異なるだけでなく、同じAPIでもOSによって動作が異なったりバグっぽいのがあったりという状態なので、それらをできるだけ回避するためのバッドなノウハウ集といった具合、地獄の様相です。 Web Audio API編 やり方 まず使えるかどうかを判断します。 if (typeof webkitAudioContext != "undefined") { } Web Audio APIでは new webkitAudioContext() で作られる Aud

Web Music Developers JP Advent Calendar 2012 の 5日目の記事です。 最後に 色々なブラウザで使えるリアルタイム信号処理用の簡易インターフェイスを作りました。 Chrome, Safari, Firefox, Opera, IE9, iOS6(*1), ブラウザじゃないけど node.js で動作します。 pico.js - Simple interface for a real-time audio processing *1 iPhone4S, iPad3 のSafari (UIWebViewではない)で確認しました 記事はここから さて、タイトルのとおりブラウザから音を出す良さそうなやり方について書こうと思ったのですが、ぶっちゃけたところ現状では良いやり方はありません。WebKit系なら Web Audio API、Firefoxなら Au

Chrome とか Firefox でタイマーを使っているとき、別のタブを選択するとタイマーの精度が落ちる。 音を出すプログラムとかでタイマー制御しているときとかに困る（機嫌よく音を出していたのに急にガタガタになったりする）ので、WebWorkerを使ってバックグラウンドでタイマーを動作させることで、別のタブを選択しても精度が落ちない無敵タイマーというのを考案して使っていたのだけど、それに機能を追加した。 MutekiTimer.use() とすれば window.setInterval と window.clearInterval を無敵タイマーバージョンで置き換えるので、既存のプログラムに導入するのが非常に簡単になる。あんまり試してないけど。 あと、gistのどっかにコードを置いていたのだけどGitHubに移した。GitHub Pagesでデモが動かせるので便利です。 http://m

朝起きたら timbre.js が iOS6 で鳴らないやんけみたいなメールが来ていたので慌てて対応しました。スケールするマリオ も ホーミー も iPhone で、iPad で鳴ります！！ ただ、まだ不安定な感じで、すごくブチブチに鳴ってしまうときと、奇麗に鳴るときがある感じです。UIWebView だと確実にブチブチになる。 僕は JavaScriptNode でゼロから信号処理を行う派ですが、こんな感じにしたら使えるようになりました。 AudioBufferSourceNode を JavaScriptAudioNode に入力してあげないといけないみたいです。 追記 ちゃんと確認していないですが、画面読み込み後等に自動でスタートするのはダメっぽい。 ボタンとか画面をタッチしてから音を鳴らすとかしたほうが良さそうです。 ctx = new webkitAudioContext() s

ちょっとやろうと思ったことがあって、確認と練習がてら色々試したら表題にあるとおりの動画プレイヤーができたので、どんな感じでやるのかを簡単に書きます。 こういう感じのものが出来ます。 Glitched Movie Player 1. ドラッグ＆ドロップで動画を読み込む $(window).on 'dragover', -> false $(window).on 'drop', (e)-> file = e.originalEvent.dataTransfer.files[0] video = document.createElement 'video' $(video).on 'loadeddata', -> video.muted = true video.play() video.type = file.type video.src = URL.createObjectURL file

CnvUI - A tiny UI based on HTMLCanvasElement http://mohayonao.github.com/CnvUI/ timbre というサウンドプログラミング用のライブラリを作ったときに、デモページで使うためにつくったUIの部品です。とりあえず、縦スライダーとノブ（つまみ）とスイッチ、ラベルがあります。jQueryに依存していますが、画像ファイル等は必要ないのでちょっとしたUIが必要なときに便利だと思います。jQueryの依存（$.fn.offsetを使っている）は解消したい。はぁ..

とりあえず疲れた。リポジトリもめちゃくちゃだし。暴飲暴食もした。 timbre - JavaScript Library for Objective Sound Programming http://mohayonao.github.com/timbre/ 新しいデモもつくった http://mohayonao.github.com/timbre/examples/004_timbresynth.html ライブラリにはUIついていないけど、デモのときは分かりやすいのでわざわざ書いた。バッハとJavaScriptは相性が良いとおもう。JSだけに。 そういえば、前につくった これ もバッハだった。 関連エントリ サウンドプログラミング用のJavaScriptライブラリをつくっている

JavaScriptでつくっているサウンドプログラミング用のライブラリ（ timbre ）にいくつかオブジェクトを追加してリズムシーケンサーを書いた。リズムシーケンサーが書けるようになったというよりは、リズムシーケンサーを作るために必要なオブジェクト（タイマーとフィルター）を追加した。あと、インターフェイスを修正したりして最初のデモも読みやすくなったと思う。 001. oscillators http://mohayonao.github.com/timbre/examples/001_oscillators.html 002. rhythm sequencer http://mohayonao.github.com/timbre/examples/002_rhythmsequencer.html このライブラリの最初のアイデアはS式風に音楽を記述するっていうものだったのだけど、昨日の記事

アイデア 例えば Cメジャー のコードは ド ミ ソ で構成される。 和音は加算で書けるので、 ド + ミ + ソ これを、lispよろしくこう記述する。 (+ ド ミ ソ) ドっていうのは、 (sin 523.25) みたいな感じで、523Hzのサイン波 みたいな感じ。位相や振幅も指定できるけど省略している。音色は sin でなくて tri とか saw とかでも良いし、サンプリングした音でも良い。 ピアノみたいな減衰音は、 (adsr 0 1000) こう書くとする。ADSRエンベロープで Attack が 0msec、Decay が 1000msec、Sustain と Release は省略。この場合、1000ミリ秒で減衰する。 振幅はかけ算で書けるので、さっきのコードと合わせて書くと (* (+ ド ミ ソ) (adsr 0 1000)) こう書ける。 詳細に書くなら (* (+

http://mohayonao.herokuapp.com/perfume3 Perfume のモーションデータを使って JavaScript で踊るやつ。Safari や iOS では動かなかったんだけど修正して動くようにした。（Windows版の Safari では動かないみたい） やったこと 動かなかった最大の原因はオーディオファイルの形式で、公式で配布されている wav を ogg に変換して使っていたのだけど、Safari は ogg に対応していないらしいので mp3 も用意した。 それだけで一応は動くようになったのだけど、BVH のデータが iPhone で読むには大きすぎて（1つにつき2MBくらいある）ダメな感じだったので、フレームを間引いて小さくしたモバイル版BVHを作った。PCに比べるともっさりしているけど、動くから良い。 3D処理自体は three.js でやってい