ABC2017が開催されました

October 14, 2017, 7:08 am

≫ Next: 今後の出没予定地(TFoM、Node学園祭、ビルダーズサミット)

≪ Previous: ROLI Blocks ハッカソンとかABC2017とか

2017年10月14日、川崎市産業振興会館‎でABC2017 (Android Bazaar and Conference 2017) が開催されました。私としては今までAndroid絡みの適当な出し物もないのでABCには参加してこなかったのですが、Web Music Developers JPのブースを出すという事で割と適当に見繕って持ち込んできました。話に聞いていた通り、結構みなさん好き勝手に持ち込んでいる印象でAndroidとの関係とか誰もあまり気にしていない集まりのようです。そういうものだったか。という事でカンファレンスの方は全く聞いていないのですが、展示にどんなものがあったか目についたものをざっくりと。

Web Music Developers JPのブース。私が持ち込んだのはWebMIDIからDMX照明を制御するデモです。

日本アンドロイドの会の各地の支部活動のブースと企業ブースが半々くらいの感じですかね。なんだかよくわからないけど九州方面の人が島原そうめんを配っていたのでもらってきました。それはそれとして、このところIoT IoTってあまりに聞き過ぎて、最近ちょっとあれなんかこの言葉古臭いんじゃね? とか思うようになってしまいました。こういう言葉の運命のようなものだと思うのだけど、多分こういう変化って一気にくるんじゃないかなぁ。そろそろ危険なのかもね。

↧

今後の出没予定地(TFoM、Node学園祭、ビルダーズサミット)

November 5, 2017, 2:41 pm

≫ Next: モジュラーフェスティバル TFoM 開催

≪ Previous: ABC2017が開催されました

11月18-19日はRed Bull Studios Tokyoで東京モジュラーフェスティバル(TFoM)が開催されます。もう来週の末ですね。ブースを出しますので色々準備中です。詳細はこちら : Tokyo Festival of Modular

その翌週、11月25-26日はnode.jsのカンファレンス「東京Node学園祭」が開催されますが、25日のアフターパーティで少しパフォーマンスをやります。場所は法政大学富士見ゲートです。詳細はこちら : 東京Node学園際

更に翌週、12月2日は北の丸公園の科学技術館でアナログシンセビルダーズサミットです。こちらにも出展する予定です。詳細はこちら : 第17回アナログシンセ・ビルダーズ・サミット

意外と予定が詰まっちゃったなあと思いつつ、どれかに参加される方、会場でお会いしましょう。

↧

モジュラーフェスティバル TFoM 開催

November 19, 2017, 5:54 pm

≫ Next: Sonarの開発/生産が終了するらしい

≪ Previous: 今後の出没予定地(TFoM、Node学園祭、ビルダーズサミット)

11月18日(土)、19日(日)の二日間、国内最大のモジュラーイベントである東京モジュラーフェスティバル(TFoM) 2017が渋谷の RedBull Studio Tokyo および Contact tokyo で開催されました。展示会場のRedBull Studioの様子をざっと紹介します。

g200kgブースはCVtoDMXのインターフェースとDMX照明を持ち込んでいます。

Hiraki Instrumentsさん。このあたりの国内ガレージ勢はみんなお馴染み

そういえばDigiLogさんが会場内を流しで放浪していたので机の隅っこに並べてもらった

おむかいにいたのはペルーから参戦しているAtomoSynthさん。アナロギッシュな感じでその筋では評価が高いです。

これは初めてみたテルミンとシンセサイザーを合体させたTheresyn。テルミン音源とシンセ音源の両方が鳴っていてミックスできます。ミュージックメッセとかにも出てたみたいですね。

これはROLI Blocksをモジュラーラックにマウントして8系統のCVを出す仕掛け。私は出れなかった先日のROLIハッカソンで作ったものらしいです。こんな所に展示場所を確保していたとは、やるねー

BitWigさん! DAWの中でモジュラーに一番を力を入れているのはBitWigです!との事。DAW内のデバイスでLFO等を組み合わせて生成した信号をExpertSleepersのI/F経由で直にCVとして出します。

Modular8さんのブースではビデオ系モジュールを組み合わせてカメラ入力からのVJデモ。

Teenage Engineeringさんもいます。シンセ以外のプロダクトも色々試行錯誤しているようですので今後どういう方向に行くのか予想が付かないですね。

Waldorf kb37、ユーロラックモジュールが入れられるキーボード付きのケースです。良い

Deckard's Dream。クローンではなく往年のアナログシンセに最新技術を持ち込む。DIYキットもあるようです。好きな人にはたまらんだろうね

モジュラーらしくないでっかいディスプレイの1010music、toolbox、bitbox、synthbox、fxbox。タッチ操作もできます

一方ライブ会場、1日目のトリはSUGIZOさん+HATAKENさん。モジュラーイベントでは普通見られない最前列を女子が固める態勢

そして2日目のトリ、Phewさん。いやン十年前にレコードを買って凄く良いなと思った事があるんですよ。まさかの懐中電灯スタイル

ちょっと風邪ひいてたし体力が持つかどうかが危ぶまれた2日間でしたがなんとか乗り切れました。今回は展示会場とライブ会場を完全に分けて距離的に両者の間が徒歩10数分くらい離れていたのですが、結果的にこれが正解ですね。今まで同一会場で展示とライブをやっていた時の爆音ライブ中の横で機材の説明を求められたときの無駄なあがき感が解消されました。ライブ会場となったContact tokyoですが、特にスタジオルームでのサブソニックの鳴りが相当にエグくて、足から来る振動がマッサージ的に気持ちが良いレベル。やはりこういう所で鳴らさないとな、と。そして二日目のトリだったPhewさん、昔レコードを買って気に入ったものの、その後の消息を一切知らなかったのでまさかモジュラー使いとしてこのイベントで見る事になるとは思いもしませんでした。ボイスを織り交ぜたドローンという感じ? 良いです。

↧

Sonarの開発/生産が終了するらしい

November 22, 2017, 7:36 am

≫ Next: Node学園祭アフターパーティ

≪ Previous: モジュラーフェスティバル TFoM 開催

ついにこういう事態になってしまったか。多分、日本のユーザーが多かったのではないかと思うのだけどこれはDTM界隈にとってかなりショッキングなニュースではないかなあ。 Studio OneやBitWigなどの新興勢力が力を付けてきたので最近ではあまり目立たなくなっていたものの Windows用のDAWとしてはかつては Cubaseと人気を二分する勢いだったのだけどね。 Sonarの開発を行うCakewalk社と言えばDTM黎明期からのシーケンサー/DAW開発の老舗で2003年にRolandと業務提携、2008年にRolandの子会社となってRolandブランドで DAW のSonarを展開していました。そして2013年にギターで有名なGibsonに買収され、販売は同じくGibsonグループとなっていたTascamブランドで行う、という形が取られていたのですが、ここにきてついに新規開発、販売が終了する、と。既にSNS上では怨嗟の声も飛び交っていますが、このGibson社、実はこういう事は初めてではなく、1998年にOpcode社を買収し人気が高かったシーケンサー、Visionを手の内にしたのですがそのまま塩漬けにして潰してしまったという経緯があります。どういう判断の経緯があったのかはわかりませんが、DTM界隈ではもう不審の目で見られるのは致し方ない所ですかね。何しろ昨年末まで「ライフタイムフリーアップデート」とか言ってもう毎年のライセンスアップデートは必要ないというキャンペーンをやってたのにまだ1年たってないし。今後の方向としてはGibsonは民生オーディオに注力すると言っているようですが、2013年頃からCakewalkを買って、TEACを買って、Philipsのホームエンターテインメントを買って...と、何と言うか迷走しているようにも見えるのですがね...。前回Visionの開発終了の際には移行措置も取られず、サーバー上にプログラムが放置されていたり、およそ正常とは思えない状況になっていたりしましたので、終わらせるなら終わらせるでユーザーから恨みを買うような事がないようにして欲しい所です。

↧

Node学園祭アフターパーティ

November 25, 2017, 9:53 am

≫ Next: 第17回アナログシンセビルダーズサミット(ASBS17)

≪ Previous: Sonarの開発/生産が終了するらしい

11月25日、node.jsのカンファレンス、「Node学園祭」のアフターパーティでライブをしてきました。と言ってもカンファレンス本体とアフターパーティは結構離れた別会場だったので、機材を持ったままうろうろするのを避けてアフターパーティ会場に直行したため、カンファレンス本体の様子はまったくわかっていないのですけどね。

この手のイベントで良く一緒になる@sascacci氏。サーバー系DJという謎な肩書の同僚氏とWebMIDI VJ

パーティーの時に説明し忘れたけど私が使っていたプログラムはGitHub上に置いてあります。ただし自分用で作っているのでドキュメントは整備されていません。特徴としては:

音と映像、照明制御(要専用HW)が同時に扱える
自分のやりたい機能しか作っていないので何でもできるわけではない
コマンドラインインターフェースでプロパティを１つずつ書き換える形式なので一般的なライブコーディングよりリアルタイムに演奏している感が強い
正直あつかいにくい

https://g200kg.github.io/LiveBeats/ 一般的なライブコーディング環境だとある程度構成に合わせて作り込んでおいてコードの抜き差しで変化を付ける的なやりかたができるのだけど、これはコマンドライン直打ちしたものがそのまま反映されるというのが基本です。まあこういうパフォーマンススタイルが一般的なものなるかというとそうはならない気はするんですけどね。ソースを見てみたいという人がいればどうぞ。

↧

第17回アナログシンセビルダーズサミット(ASBS17)

December 3, 2017, 7:13 am

≫ Next: WireとCordとCable

≪ Previous: Node学園祭アフターパーティ

12月2日、北の丸公園の科学技術館で年末恒例、第17回アナログシンセビルダーズサミット(ASBS17)が開催されました。今回は初出展の人も結構いて初めて見るものも多く新鮮でした。 ※前から思ってた事だけど、名前が長すぎて「シンセサミット」とか「ビルダーズサミット」とかいつも適当な省略の仕方をするのでググラビリティ的にどうよと思わなくもない。なおTwitterのタグ的には #ASBS17 で統一されています。

私はいつものDMX照明セットを並べています。もう今年のネタはこれで押し通してしまった

シンセDIY界のレジェンド山下さんがついにEuroRackに手を出しました。ライブ映えを考慮してアクリルパネルにLEDでかなり派手派手な感じに。

denha's channel の原田さんの所はLEDバッジや謎ガジェットの小物がいっぱい

これは凄い。DIYで良くここまで作ったと感心。仕上げも凄いが中身も音色メモリー付きのアナログ6音ポリシンセでぎっしり詰まっている感じ。部屋のスミスさん作。

一方こちらはDigiLogさんのブースにあった段ボール箱シンセ。ご家庭に良くあるamazonの箱に入っています。パンク感が良い感じに振り切れてる。DigiLogさんの出展のメインはOCTAの方だと思うけどこっちが気になる

sigboostさんもASBSに初参戦。MAXで作った楽器のプログラムをFPGAに落としてハードウェア化するという以前IPAの未踏プロジェクトにもなってた奴です

Maker Faireなんかでも見てたのですがASBSは初参戦らしい。risgkさんのArduinoシンセ。8ビットCPUの性能の限界に挑戦して3音パラフォニック。

DCO+アナログフィルターの5音ポリシンセとパラメータ操作用の専用コントローラという構成のシンセ。Yoroheiさん作

Hitoteさんの謎楽器。ボタンが2オクターブ2段の鍵盤になっていてシンプルなんだけどこれは面白い。ライブとかで映えそう

うーえさん。Native Instruments の Massiveのようなシンセをアナログハードウェアで実現するという壮大な計画。24VCO/72VCA/32EG/32LFO 等々えらい事になっている模様

今回若い人の参戦が増えてだいぶ出展者の平均年齢が下がりましたかね。しかも皆ポリフォニックのハードウェアアナログシンセのようなかなり高度なものを手掛けています。やる人はやるもんですね。未来は明るいんじゃないかな。

↧

WireとCordとCable

December 15, 2017, 7:55 am

≫ Next: Web Audio API のノードの組み合わせでAutoWahを作る

≪ Previous: 第17回アナログシンセビルダーズサミット(ASBS17)

例外も多いし、多分これに沿っていなくても誰にも怒られない知見。
いわゆる電線をワイヤーとかコードとかケーブルとか呼ぶ使い分けについて

ワイヤーは電線そのもの。導体1本でもワイヤーだし絶縁する被膜がなくてもワイヤー
コードは主に家電機器の電源を繋ぐために使用される電線を指す言葉。電安法が「コード」を使ってるからそういうニュアンスが強くなった模様
ケーブルは複数の電線をまとめて更に被膜(シース)でくるみ、1本にしたもの

まあ慣例的にこうじゃないものも多分たくさんあるし、割とどうでも良い話ではあるけど。

ただまあ
「ワイヤー」は凄く細そう
「コード」は柔らかくてひょろそう
「ケーブル」はコードよりごつそう
というイメージではある。スピーカーコードよりスピーカーケーブルの方が高そう。

あー、後は「シールド」というのもあるな。楽器に直接ささるシールドケーブル限定で略す時に前半分が残った感じだけどこの言い方をするのはほぼギター/ベースプレーヤー。英語圏だと多分通じない。CableとかGuitar cable とか言っている感じ。

↧

Web Audio API のノードの組み合わせでAutoWahを作る

December 16, 2017, 10:04 am

≫ Next: Web Audio API のノードの組み合わせでBitCrusherを作る

≪ Previous: WireとCordとCable

これは「WebAudio/WebMIDI API Advent Calendar 2017 Advent Calendar 2017」用の記事です。 Advent Calendar にはこの他にもWeb MIDI/Audio 関係の記事がありますのでよろしければどうぞ。 https://qiita.com/advent-calendar/2017/webaudiowebmidi

WebAudioAPIのノードの組み合わせでオートワウを作ってみるサンプルです。WebAudioAPIってノードの組み合わせだけで結構色んな事ができるんですけど、何をどう組み合わせれば良いかを考えるのはエフェクトの中身がわかっていないとなかなかハードルが高いですね。さて、「オートワウ」あるいは「タッチワウ」と呼ばれるエフェクターですが、ギターのエフェクターでみょんみょん言う奴ですね。中身は単なるQが高めのレゾナントフィルターなんですが、これのカットオフ周波数をペダルで操作できるようにしたものが「ワウペダル」で、それをピッキングの強さで自動的に変化させるようにしたものが「オートワウ」です。ピッキングの強さで変化するというのは入力される信号の振幅の大きさを取り出して制御に使うわけですがこの部分をエンベロープフォロワと呼びます。ノードの繋ぎ方は下の図のようになります。左上の方にWaveShaperとBiquadFilterがありますがこれがエンベロープフォロワに相当します。WaveShaperのカーブは0を中心に左右対称の[1,0,1]になっていますのでマイナスの入力は全部プラスに折り返されてしまいます。そしてBiquadFilterのlowpassを通りますがこのカットオフは3Hzという非常に低い周波数になっていますので音声波形そのものではなく、大体の音量の変化に追従した値が得られます。後はこれに適当な倍率を掛けてフィルターの周波数を操作するだけです。後、右側半分の方にあるのはOn/Offのバイパススイッチや波形表示をしているだけです。 WebAudioDesignerというツールで作っていますので、実際に動作を確かめられます。下のリンクから飛んで左上の[Start]ボタンを押すと音が出ます。[On]のボタンでエフェクトのOn/Offが切り替わります。このエンベロープフォロワの部分は他にも色々応用が効きますので覚えておいて損はないかと思います。 AutoWah Sample

↧

Web Audio API のノードの組み合わせでBitCrusherを作る

December 19, 2017, 12:04 am

≫ Next: Web Audio API のノードの組み合わせでDimensionを作る

≪ Previous: Web Audio API のノードの組み合わせでAutoWahを作る

これは「WebAudio/WebMIDI API Advent Calendar 2017 Advent Calendar 2017」用の記事です。
Advent Calendar にはこの他にも Web MIDI/Audio 関係の記事がありますのでよろしければどうぞ。

https://qiita.com/advent-calendar/2017/webaudiowebmidi

Web Audio API のノードの組み合わせでビットクラッシャーを作ってみるサンプルです。ビットクラッシャーは意図的に信号のビット数を減らして Lo-Fi な音を作り出すエフェクターですね。デジタルで処理するエフェクトとしてはとても簡単なので DAW 等におまけ的に付いていたりして一般的に認知された気がします。ギター用等のハードウェアのエフェクターとしてもあまり数はありませんが無くはないです。

このサンプルは WebAudioDesigner というツールで作っていますので、実際に動作を確かめられます。下の方にあるリンクから飛んで左上の[Start]ボタンを押すと音が出ます。[On]のボタンでエフェクトの On/Off が切り替わります。

処理の内容としては WaveShaper で階段状のカーブを作っておき、それに通すだけになります。
このカーブは画面上ではただの直線に見えますが、長さが1023の配列で -1～+1 の範囲の 256段の階段状のカーブです。 "curve"の文字列の部分をクリックすると出てきますが、作成部分は下のコードのようになっています。

(()=>{
  var r=new Float32Array(1023);
  for(var i=0;i<512;++i){
    var v=((i/512)*128|0)/128;
    r[511+i]=v;
    r[511-i]=-v;
  }
  return r;
})()

パラメータは"Bits"の1つだけで 2ビットから8ビットまで可変できますが整数に限らず少数でも構いません。通常のやり方だとこのパラメータによって任意の段数のカーブを作り直すのですが、ここでは少し違うやり方で、信号の振幅の方を調整してカーブの一部のみを使う事で任意の段数に変換しています。

それが WaveShaper の前後にある Gain で Math.pow(2,x)/256 および 256/Math.pow(2,x) の部分です。

とにかくノードの数を減らしたいという場合は別ですが、毎回カーブを作り直すよりはこの方が応用は効くんじゃないですかね。

この curve のパラメータのテーブルは以前は補間をするべきかどうかが仕様で定まっておらず、テーブルのサイズが小さいとブラウザの実装によって勝手に階段状になったり直線になったりしていたのですが、現在の Web Audio API の仕様では直線補間されると明確に定義されたので、階段をちゃんと表現するにはそれなりのサイズが必要になります。

この WaveShaper というノードはディストーション系の効果を得るために使うというのが主な用途になります。BitCrusher もディストーションの一種と言えなくもないですが、他にもアイデア次第で面白い使い道がありそうです。

そもそも音声信号に適用するだけではなくて制御系の信号に適用して妙なモジュレーションを掛けたりなんかもできますよ。

BitCrusher Sample

↧

Web Audio API のノードの組み合わせでDimensionを作る

December 20, 2017, 5:25 am

≫ Next: 2017年 Web Audio API はどう変わったのか?

≪ Previous: Web Audio API のノードの組み合わせでBitCrusherを作る

これは「WebAudio/WebMIDI API Advent Calendar 2017 Advent Calendar 2017」用の記事です。
Advent Calendar にはこの他にも Web MIDI/Audio 関係の記事がありますのでよろしければどうぞ。

https://qiita.com/advent-calendar/2017/webaudiowebmidi

Web Audio API のノードの組み合わせでディメンションエフェクトを作ってみるサンプルです。

その昔、コーラスエフェクトが一般的になり始めた頃、ローランドから発売されたのが「Dimension D」というラックマウントのエフェクターです。ディメンションはコーラスの一種ではありますが、通常のコーラスエフェクトで感じるピッチの揺らぎがあまりなく、それでいて良い感じの広がりがあるコーラス感が得られるという事で一般的なコーラスエフェクトとは一線を画す地位を確立しました。

「ディメンション」自体は商品名に由来する名前ですのでエフェクトの一般名称としては「多層コーラス」のように呼ばれる事もありますが、本家の Dimension D はステレオの左右チャンネルの個別処理を行うだけですので多層というほど色々積みあがっているわけではありません。

さて、Web Audio API のノードの接続としては下の図の通りです。ステレオの左右チャンネルを ChannelSplitter で分離し、個別に Delay をかけて、原音とミックスします。ミックス先は LR 反転が基本ですが、ストレートにミックスするラインに混ぜる事もできます。コーラスの元、揺らぎの元となる LFO からのディレイタイムへのモジュレーションはかなり控え目で、さらに LR のチャンネルでモジュレーションの極性が反転しています。

下のリンクから飛んで、左上の [Start] ボタンで音が出ます。ツマミは Rate がモジュレーションの速度、Depth がモジュレーションの深さ、Mix は LR のストレートミックスの量です。
なお、本物の Dimension D は本体にボタンが5つあるだけで、OFF / MODE 1～4 というプリセットされた設定を選択するのみという実に潔い仕様のエフェクターです。絶妙なプリセットのチューニングあってのディメンションですので本物と同じというわけにはいきませんが、雰囲気を感じていただければと思います。

※ あ、ちなみに今の所 Chrome の ChannelSplitter はデフォルトでモノラルの信号を突っ込むと最初の output に信号が出てきません。これは古い仕様のChannelInterpretation に従っているためなのでノードを作成する時に createChannelSplitter(2) とチャンネル数を明示的に指定する必要があります。多分そのうち修正されると思います。

Dimension Sample

↧

2017年 Web Audio API はどう変わったのか?

December 22, 2017, 11:05 am

≫ Next: input-knobs.js : 軽量なノブ用ライブラリ

≪ Previous: Web Audio API のノードの組み合わせでDimensionを作る

これは「WebAudio/WebMIDI API Advent Calendar 2017 Advent Calendar 2017」用の記事です。
Advent Calendar にはこの他にも Web MIDI/Audio 関係の記事がありますのでよろしければどうぞ。

https://qiita.com/advent-calendar/2017/webaudiowebmidi

W3C サイトで公開されている Web Audio API のワーキングドラフトは2年前から変わらず、2015年12月版のままなんですが、GitHub に置かれているエディターズドラフトは2017年も色々と変更が加わっています。

完全には追い切れていませんが、どんな変更があったのかざっと紹介したいと思います。なお昨年中に行われた変更は昨年の記事、「2016年、Web Audio API はどう変わったのか?」の方にありますので併せて見て頂ければ日本語訳を作った2015年12月以降の様子がだいたいわかると思います。

AudioWorklet の詳細設計と実装が進みました

これが一番の大物で、去年の時点で AudioWorker 改め AudioWorklet の設計が始まっていましたが、deprecate になったScriptProcessor で新たに何かを作るのもいまいち気が進まない事もあり、ブラウザに実装されるのを心待ちにしてやきもきしていた人もいるのではないでしょうか。

設計が進む中で、AudioWorkletNode と AudioWorkletProcessor 間の通信方法が、当初 sendData() / ondata ハンドラーだったのが MessagePort に変更されたりしたようです。

つい最近ですが Chrome 64 でフラグ付きですが実装されていますので、遂に実際に動作を試す事ができるようになりました。

エディターズドラフト : AudioWorklet

AudioContext からレイテンシー関係の情報を取れるようになりました

AudioContext に getOutputTimestamp() というメソッド、およびbaseLatency、outputLatencyというプロパティが追加され、これにより JavaScript 上の処理から実際に音として出力されるまでの時間などが取れるようになります。この辺を使うと、音とグラフィックスのタイミングをびっちり同期させたりする事ができそうですね。

getOutputTimestamp()で取れるのは:

AudioTimestamp {
    double              contextTime;
    DOMHighResTimeStamp performanceTime;
}

という形式で、

contextTime : 今現在オーディオデバイスに渡されているデータの AudioContext.currentTime 時間軸上の時刻
performanceTime : このデータが実際にオーディオデバイスによって音として出力される High Resolution Time 時間軸上の時刻

です。

また、プロパティの方は、AudioDestinationNode がデータを受け取ってからオーディオサブシステムに渡すまでのレイテンシーが baseLatency、オーディオサブシステムがデータを渡してから音として出力されるまでのレイテンシーが outputLatency となります。outputLatency はプラットフォーム、ハードウェア依存の話になってしまうので OS 毎にざっくりした値が設定されるのではないかと思いますが今の所まだ仕様だけで実装はされていません。

エディターズドラフト : getOutputTimestamp

AudioContext を作成する時のオプションでサンプルレートが指定できるようになりました

AudioContext を作成する際に、

var audioCtx = new AudioContext({
  latencyHint: 'interactive',
  sampleRate: 44100,
});

というような感じで WebAudioAPI の内部のサンプルレートが指定できるようになりました。またもうひとつのオプションである、"playbackCategory" は "latencyHint" に名前が変わっています。

実装は今の所まだ対応していないようですが、指定されたサンプルレートがオーディオデバイスのサンプルレートと異なる場合は内部でリサンプルが行われる事になっているようです。

エディターズドラフト : AudioContextOptions

MediaStreamTrackAudioSourceNode が追加されました

今まであった MediaStreamAudioSourceNode に加えて MediaStreamTrackAudioSourceNode が追加されました。名前長いよ。

これは MediaStream 中の1つのオーディオトラックを指定して Web Audio API に取り込むためのノードになります。

私も動作を確認していないのですが、これは WebRTC のピアコネクションから送られてくるストリームに複数のオーディオストリームトラックが含まれている時などに id で指定して1本のオーディオを取り込む場合等に使うものだと思います。

エディターズドラフト : MediaStreamTrackAudioSourceNode

各ノードのチャンネル数に関する制限等の詳細が明記されました

今までの仕様で既に StereoPannerNode のように信号が2チャンネルステレオでないと意味を成さないノード等もありました。

各ノードの種類に応じて channelCount、channelCountMode、channelInterpretation の各パラメータの扱いの詳細が説明されています。例えば StereoPannerNode では channelCount は2以上に書き換えられず、channelCountMode は"max"に設定できません。また channelSplitter では channelInterpretation を"discrete" 以外には設定できません。

dictionary AudioNodeOptions {
    unsigned long         channelCount;
    ChannelCountMode      channelCountMode;
    ChannelInterpretation channelInterpretation;
};

これらは(new を使って)ノードを作成する際にオプションとして渡す事ができます。

エディターズドラフト : AudioNodeOptions

パラメータのタイプの変更

幾つかのパラメータで Float32Array しか受け付けなかったものが通常の数値の配列で OK になっているものがあります。

createPeriodicWave の real、imag 引数
setValueCurveAtTime の values
WaveShaper の curve

詳細な説明がどんどん増えていて全部を読むのはちょっと大変になってきていますが、他にも細かい所に変更は色々入っていると思います。

W3Cにあるワーキングドラフトがかなり置いて行かれてる感が強まってきましたので、そろそろワーキングドラフトに反映して欲しい所ですかね...

↧

input-knobs.js : 軽量なノブ用ライブラリ

December 26, 2017, 7:21 pm

≫ Next: input type=range タグをカスタマイズするために

≪ Previous: 2017年 Web Audio API はどう変わったのか?

オーディオ系Webアプリでは欠かせないノブ用のGUIライブラリ「webaudio-controls」、何かWebアプリを作る時はだいたいいつも使っています。しかしフレームワークとして使っている Polymer が既にバージョン 2 になり、このままではいかんと思っていじりかけたりしたのですが斜め上方向に進んで、新たなGUIライブラリを作ってしまいました。 input-knobs.jsは「webaudio-controls」のサブセット的なもので、今の所回転するノブとトグルスイッチ、ラジオボタンのみです。これらは基本的な動作は input type="range" とか input type="checkbox" をそのまま使っていて見た目だけ CSS と Javascript を駆使して差し替えます。 HTML5でサポートされたスライダーのタグ、input type="range" が結構有能なのでだいたいこれでも良いんだけどやっぱり回るノブが良いな。とは言え、webaudio-controls だと Polymer ベースで、特に Firefox、Edge だと webcomponents が polyfill なので DOM の基本構造をごっそり書き換えられて困った事になったりしたのでついついやってしまった。まあ webcomponents でノブ用の独自タグを拡張するという方向が魅力的なので、どのブラウザでも webcomponents がネイティブサポートされれば webaudio-controls で良いんじゃないかとも思うのだけど。HTML imports あたりでいまいち仕様がしゃきっとしないみたいだしもう少し時間がかかるんですかね。 input-knobs.js は 5kB 程度の単一ファイルだし、イベント周りも input タグと同じなので取りあえず input type="range" でプロトタイピングしておいて、input-knobs.js を追加して GUI を整えるというプロセスが快適かな。 GitHub : input-knobs.js input-knobs.js デモページ

↧

input type=range タグをカスタマイズするために

December 29, 2017, 11:08 pm

≫ Next: Polymer というか WebComponents

≪ Previous: input-knobs.js : 軽量なノブ用ライブラリ

これなんですが　：　

大晦日なんですけどね。 input-knobs.js というライブラリを作ったりして、ちょっとこの HTML の <input type="range"/> タグという奴と格闘していました。タグ1つで連続値を入力するスライダーが書けるのでとにかく便利。個人的に HTML5 で追加されてよかったタグ第一位くらいに位置するのですが...。

ただ、見た目がね。かなりカオスな事になっています。

現状、シンプルに <input type="range"/> と書いた時に表示されるものが下の図です。興味深いです。Macの方はそれなりに統制が取れているんですけどね。ことデザインに関しては Apple に真っ向から盾突くわけにも行かないとかいう事情があるんですかね? 経緯は知りませんけどみんな Apple の Safari に寄せて来てるんですか? 一方 Win の方はみんな自由すぎ。そもそもの MS Edge が一番浮いてるんじゃないですか。ちょっと癖が強すぎ。ここであまり個性は出してほしくないなぁ。

更に Edge の場合はスライダーの操作中だけ数値が表示されます。これはすごく便利ではあるのだけど Edge でしか表示されないのでこれに頼るわけにも行かないのが現状です。結局数値を読み取る必要がある場合には別の場所に表示する事になります。

という事で検索すれば、この<input type="range"/>タグをスタイルシートでカスタマイズする的な情報もちらほらあるのですが、単発のサンプルだけでは中身がよくわからないので、スライダーを構成している各部品がどうなっているのかをちょっとまとめておきます。

このスライダー全体を指すためのCSSのセレクタは input[type=range] とかで指定できるのですが、詳細なカスタマイズをするには背景やツマミなどスライダー内の各パーツに対してスタイルを適用する必要があります。ボタンのスタイリング等で良く使う :hover や :active 等がエレメント全体の特殊な状態を指す「疑似クラス」と呼ばれるのに対し、このエレメント内の一部分は「疑似要素」と呼ばれ、コロン2つに続くセレクタを使用します。

ただブラウザによって実装が違うので割と面倒です。
取りあえずクロスブラウザで同じ表示になるようなスライダーの背景とツマミ部分の塗りを指定するために必要な情報を考えます。

Chromeの場合:

webkit系の場合はカスタマイズをする際にまずエレメント本体である input[type=range] とツマミ部分の ::-webkit-slider-thumb に対して -webkit-appearance:none; を追加してブラウザが独自の描画をするのを止めてから各種の指定をする必要があります。
またこの両方を指定するとエレメントが高さを失いますので height を明示的に指定する必要があります。

::-webkit-slider-runnable-track はエレメント全体の外形と重なっていますが存在するだけで描画にはつかわれていません。

Firefoxの場合:

firefox ではカスタマイズのためにエレメント本体 input[type=range] に対して ::-moz-appearance:none; を指定する必要があります。

::-moz-range-track がスライダーの溝部分の表示に使われていますが、不要な場合、 display:none; を指定しても消えません。height:0; か opacity:0; ならこれを消す事ができます。

また、Firefox では ::-moz-appearance:none; をした状態でもツマミ部分にデフォルトで border と border-radius が付いていますので表示を合わせるにはこの辺も指定が必要です。

Edgeの場合:

結構ごちゃごちゃしていますけど、エレメント本体 input[type=range] に対して ::-webkit-appearance:none; を指定すると ::-ms-track、::-ms-fill-lower、::ms-fill-upper がまとめて表示されなく(存在はしているが透明に)なります。
間違いではなく、「-webkit-appearance:none;」です。このブラウザプリフィックスを騙るような事をするのはどうかと思わなくもないのだけど勢力図的にやむにやまれず、という奴でしょうね。

更にツマミ部分も ::-ms-thumb だけでなく ::-webkit-slider-thumb でアクセスできるようになっているので、結果的に -webkit-appearance:none; が指定されている webkit 向けのカスタマイズコードが完全にとは言いませんが割合それっぽく見えるという事になります。

なお、::-ms-tooltip 部分はいらないなら display:none; を使って別途消す必要があります。このツールチップは、display:none; 以外の色指定やサイズ指定等は全く効かないようです。

さて、以上を踏まえて、クロスブラウザで同じ表示になるスタイルシートを作ります。

  input[type=range] {
    -webkit-appearance:none;
    background:#000;
    height:24px;
    width:240px;
    border-radius:8px;
  }
  input[type=range]::-webkit-slider-thumb{
    -webkit-appearance:none;
    background:#f00;
    height:20px;
    width:20px;
    border-radius:50%;
  }
  input[type=range]::-ms-tooltip{
    display:none;
  }
  input[type=range]::-moz-range-track{
    height:0;
  }
  input[type=range]::-moz-range-thumb{
    background:#f00;
    height:20px;
    width:20px;
    border:none;
    border-radius:50%;
  }

どうでしょうか、せっかくなのでちょっと角を丸めたりしています。
こんな感じになっているはずなんですが

画像
実際のタグ

更に...

疑似要素が厄介な所として、複数を並列しては書けないので冗長な感じになってしまいますがしょうがないですね。それに HTML 内でインラインで書く事はできないし、Javascript から element.style.xxx の様なアクセスもできません。

インラインのスタイル指定で疑似要素にアクセスする方法は10年ほど前に提案されていた案があったようなんですが日の目を見る事なく削除されてしまったようです。

クラスや id を振っておいてスタイルシート内のリテラルでカスタマイズするのは問題なくできるのですが、Javascript でこの辺を扱うライブラリを作ろうとすると非常にやりにくいです。結局要素のインスタンス毎に疑似要素の個別スタイルを与えようとすると id を振っておいてグローバルな場所で id 毎にルールを作るような事しかできません。

CSS 内で変数が使える CSS Variables がちゃんと動くようになればもう少し融通が利くようになるのですが、これまた一部のブラウザ上でまだバギーなふるまいがあって今の所まだ実用的じゃなかったりします。もう少しだよ、もう少し。

↧

Polymer というか WebComponents

January 22, 2018, 3:30 am

≫ Next: webaudio-controlsの生WebComponents化

≪ Previous: input type=range タグをカスタマイズするために

Web 開発に革命を起こす、みたいな言われ方をしている WebComponents、私も期待しているのですけど、もう出てきてから5年くらいは経ってるんじゃないですかね。結構長い紆余曲折があった感じです。 WebComponents を構成するテクノロジーは幾つかありますが最終的にカスタムエレメントという形でユーザーが自由に新しいタグを定義して HTML 内で使えるようになるという所がポイントですよね。ところが WebComponents の使い方がなかなか面倒くさい、という事でレガシーブラウザ向けのポリフィルと共にもう少し書きやすくするために Google が作ったライブラリが Polymer な訳ですがこの Polymer 自体もこの数年の間に仕様が結構変わってきています。現在の最新は 3.0 の Preview 版なんですが今年に入ってまた更新されたようです。 Polymer 3.0: New year, new preview

GitHub の方に Polymer を使った GUI ライブラリ、webaudio-controlsが置いてあるんですが、これが使っている Polymer のバージョンは 1.0 のまま。去年の頭くらいに Polymer が 2.0 になった時から対応をどうしようかと思っていたんですけどね。 WebComponents の技術の1つである HTML Import 絡みで各ブラウザベンダーの意見が揃わずゴタゴタやった結果、結局 HTML Import はドロップして、Polymer 3.0 では HTML Import は使わないという方向に修正されるので安定するまではもう少しかかるんでしょうか。元々初期には Polymer はレガシーブラウザ向けの WebComponents のポリフィルという側面もあって、「Polymer が目指しているのは Polymer が普及する事ではなくて Polymer がなくてもカスタムエレメントで普通に Web 開発ができる事だ」みたいな話もどこかで読んだ気もします。まあ徐々にですが各ブラウザの WebComponents 対応が進んできていますし、Polymer のバージョンを追いかけなくても生の WebComponents で書くというのもありかなぁとか思ったり。どうしようか..

↧

webaudio-controlsの生WebComponents化

January 29, 2018, 6:49 am

≫ Next: webaudio-controls がマルチタッチに対応しました

≪ Previous: Polymer というか WebComponents

さて、GUIツマミライブラリ、webaudio-controls のバージョンをいい加減に上げないといけないのだったが、Polymer 2.0 に対応する前に Polymer 3.0 が出てきてしまいそうなので、いっそのこと生 WebComponents (Custom Elementsのみ)化してしまえという方向で書いてみた。というのも、もうすぐ出てくるFirefox 59 で Custom Elements がサポートされるので、これで Chrome / Firefox / Safari でポリフィル無しで動作するようになるのである。素晴らしい! という事で Firefox の Shadow DOM のサポートはもう少し先になるので敢えて使っていません。Edge にも対応したい場合は webcomonentsjs だけ入れれば大丈夫です。なお IE はさすがに切り捨てました。もういいよね? まだちょっと書きかけなので、対応していない機能もありますが取りあえずライブデモは動くくらいにはなっています。 https://github.com/g200kg/webaudio-controls/blob/master/2.0/README.md

ライブデモ 1 ライブデモ 2

↧

webaudio-controls がマルチタッチに対応しました

February 5, 2018, 10:47 am

≫ Next: Rapid SSLの証明書もダメな奴だったらしい

≪ Previous: webaudio-controlsの生WebComponents化

今までマルチタッチに関しては最初の1点しか見ないとか、手抜きなコードばかり書いてたのだけど、真面目に書くと結構面倒。でもこれでミキサー的な奴のフェーダーをまとめて上げ下げしたりできるようになりました。 https://github.com/g200kg/webaudio-controls サンプルはここにあります。 https://g200kg.github.io/webaudio-controls/2.0/multifader.html

↧

Rapid SSLの証明書もダメな奴だったらしい

February 6, 2018, 9:16 pm

≫ Next: CHIRIMEN for Raspberry Pi 3 で WebBluetooth

≪ Previous: webaudio-controls がマルチタッチに対応しました

いつからか良くわからないのだけど g200kg のサイトでコンソールに警告が出るなぁ、とは思っていたのだが。何となく見過ごしてしまっていたのだけど...ちょっと待って、これはダメな奴じゃね?

そもそもシマンテックはその傘下にジオトラストやらたくさん認証局があるのだけど、適切でないプロセスで大量の証明書が発行されているとかなんとかで Google さんとシマンテックさんがバトル。結局シマンテックは認証事業を売却して Chrome はもうシマンテック系列の証明書は信頼しない、と段階的に使えなくしていくという事のようです。が、私が買った激安 Rapid SSL の証明書もシマンテック系だったんですね、へー、じゃない。そのニュースを聞いた時は「へー」とかしか思っていなかったけど、これダメな奴じゃないか。で、ここで出ている警告では「この証明書は M70 から使えなくなるよ」という事で M70 というのが2018年の9月頃の予定。この証明書を導入してまだそんなに経っていないんだけどなー。さくらインターネットで買ったので一応そちらから救済策の再発行ができるらしいのだけど、再発行の日程もバタバタと変更されたり色々しているようで、一部情報が錯綜しているようです。案内とか見落としてないかあわてて過去メールを掘り起こしたりとなかなか面倒くさい事になっています。結局この件に関する案内メールらしいものは見つからなかったので、これから再発行の案内が来るんだよ、ね? 多分。【重要】シマンテック社SSLサーバー証明書に関する再発行対応について

↧

CHIRIMEN for Raspberry Pi 3 で WebBluetooth

March 4, 2018, 3:06 am

≫ Next: Arduino の電源回路

≪ Previous: Rapid SSLの証明書もダメな奴だったらしい

CHIRIMEN for Raspberry Pi 3上の WebBluetooth 経由で BLE ライトの PLAYBULB を制御する記事を Qiita に書きました。 Qiita : CHIRIMEN for Raspberry Pi 3 で WebBluetooth

他の形状のバージョンもありますがこの丸っこい奴が Bluetooth 経由で制御できるライト、PLAYBULB です。しかしまあ、ブラウザ上から Bluetooth のペアリングを設定して制御できるとか、えらいことになってますね。このサンプルは、音に反応して光ったりなかなか楽しい事ができますから PLAYBULB (sphere または candle) をお持ちの方は是非。

↧

Arduino の電源回路

March 10, 2018, 8:07 am

≫ Next: CHIRIMEN for Raspberry Pi 3 で Stepping Motor を回す

≪ Previous: CHIRIMEN for Raspberry Pi 3 で WebBluetooth

今まであまり気にしてなかったのだけど、良く見ると Arduino の電源部分ってなかなか興味深い事になっているのだな。推奨される Arduino に電源を供給する手段としては・DCジャックに 7 - 12V を供給する・VIN端子に 7 - 12V を供給する・USBケーブルを接続して5Vを供給するという方法があり、その他に 5V 端子に 5V を供給する、という手段も良く使われているようです。下の図が Arduino の電源部分の抜粋なのだけど、上の段 X1 がDCジャックで逆流防止のダイオードを通した所が VIN、そこから U1 の NCP1117 がレギュレータで 5V を作っていると。一方下の段、USBVCC が USB からの 5V でこちらは MOS FET のスイッチを通して 5V ラインに直結されます。で、この MOS FET のスイッチは U5 で制御されるのですが、VIN の電圧が 3.3V の 2倍、6.6V 以下であればオンになって USB 側から給電されると。

FETはどうやってオンするの?

しかし、良く見るとこの FET は GS 間の電位差がないとオンしないし、U5の電源も +5V ラインから取っているからそもそもオンしないんじゃ? と思ったけど、この MOS FET って更に良く見ると逆電圧使用になっている。なのでオンしなくても取りあえず寄生ダイオード経由で USBVCC が 5V ラインにだだ漏れしていくと。なるほど。つまりこの FET は USBVCC を完全に切り離すのではなく逆流防止として使われているという事らしい。なかなかトリッキーな気がするけどこういう方法って一般的なのかな?

5V 端子から電源入れて良いの?

そしてもう一つ。電源供給で 5V 端子に外部から 5V を供給するやりかた。この方法を使った事例は良くみるのだけど、一応公式のドキュメントとしては、

5V.This pin outputs a regulated 5V from the regulator on the board. The board can be supplied with power either from the DC power jack (7 - 12V), the USB connector (5V), or the VIN pin of the board (7-12V). Supplying voltage via the 5V or 3.3V pins bypasses the regulator, and can damage your board. We don't advise it.

という事でどうやらおすすめされていない。気になる点としてはレギュレータの NCP1117 の出力側にだけ電圧をかけちゃう事かなぁ、と思ったけどよく考えると DC ジャックを繋がずに USB で駆動している状態と同じじゃないか。これで壊れるなら USB 電源で動かしているだけで壊れるって。という事で先の公式の文言はどうやら、ここに変な電圧をかけるとボードが一発で駄目になるからおすすめしない、という意味での注意ではないかと解釈するのが正しそうだ。そうだよね? となると、そもそもレギュレータの出力端子にだけ電圧をかけてぶっ壊れるという件に対しては大丈夫なのか? という疑問があるが、これはレギュレータ NCP1117 のデータシートに答えがある。

Protection Diodes
The NCP1117 family has two internal low impedance diode paths that normally do not require protection when used in the typical regulator applications. The first path connects between Vout and Vin, and it can withstand a peak surge current of about 15 A. Normal cycling of Vin cannot generate a current surge of this magnitude.

だそうだ。つまり電圧が出力端子>入力端子になっても保護ダイオードが内蔵されているので大丈夫だよ、と。ふむ、という事で安心して 5V 端子から 5V を供給して動かす事にしよう。まあ、5V端子から給電している時にVINに変なものを繋いでるとまずそうだし、直結なので注意しないといけないというのは確かだけどね。 Arduino UNO Rev.3 回路図 Arduino UNO Rev.3 DOCUMENTATION NCP1117 Datasheet

↧

CHIRIMEN for Raspberry Pi 3 で Stepping Motor を回す

March 22, 2018, 7:36 am

≫ Next: 今更だけどWeb Audio API 日本語訳の数式まわりの修正

≪ Previous: Arduino の電源回路

CHIRIMEN for Raspberry Pi 3 でステッピングモーターを回す記事を Qiita に書きました。 Qiita : CHIRIMEN for Raspberry Pi 3 チュートリアル 6. ステッピングモーター編

信号を処理するタイミングが厳しいので Arduino を I2C スレーブデバイスとして使っていますが、この Arduino 用の I2C => SteppingMotor I/F のスケッチは別途 GitHub に置いてあります。 GitHub : arduino-stepping-motor やってみてわかったのは減速レートの処理のあたりがなかなかポイントのようです。現在の回転速度からいつブレーキをかけ始めると指定のステップ数でぴたっと止まるか、みたいな。計算式ベースでオプティマイズして Arduino でパルス周波数 7kHz あたりが限界くらい。まあまあ良いかなと思ってるのだけどこのあたりは計算負荷がきつくなるのでテーブルを引いちゃうのが一般的みたいですね。テーブル化すればもう少し速く回せる気がするけどちょっと負けた気もする。

↧