Google loves the web

ChromeチームWeb Platformをより先に進めるために、ここ1～2年取り組んでいるアプローチの紹介です。

まず、前提としてGoogleはWebが大好きです。Googleの同僚は皆、Webが大好きです。そしてChrome Teamには「Webをより先に進める」という重要なMissonがあります。ここで私がWebと言っているのはChrome Webということではなく、全てのWebのことを指していて、それら全てのWebが素晴らしくなってほしいと思っています。

よって、Interoperability（相互運用性）を保ちモダンブラウザの全てにShipされるまでが我々の使命です。なぜならInteroperabilityが保たれずShipしてしまったら、誰でも・いつでも・どこでも利用できるというWebの最も大きく重要な利点の1つが失われてしまうからです。Vender Prefixを廃止したのもそういった理由です。

Chromeにおいては、Web Platformをより先に進めるために4つのアプローチをを持ち取り組んでいます。

Chromeチームが取り組んできたこと

• 複数のチャネルを持つ（Stable, Dev, Canary、Beta）
• 実験的な機能にはExperimental flagを設けONにしないと動かなくしている(chrome://flags のことでWeb Bluetoothもこの1つ)
• Original Trials：実装したAPIをそのままExperimental flagとして提供してしまうと、いつの間にかデファクトになってしまう可能性があります。APIの仕様・実装を吟味してからShipすることがよりよいWebを作るのには必要不可欠です。よって、Feedbackをすることに同意したDeveloperのみ利用を可能にすることで、利用するユーザー数を絞り、さらに期間を区切ることでデファクトすることを防ぎ、実験のIterationのスピードを上げることを目的としています。さらに多くのDeveloperが使い始めた場合は自動的に利用を停止する機能も入っています。
• Incubation of substantial new feature(wicg.io)：Web Incubator Community GroupをW3Cでにて行っています。標準化のProposalの議論をライトウェイトに行うグループです。チャーター（W3Cで議論を進める場合には必ず作成します）を作ったりすることに全ての時間は費やさないものの、正しく管理されるし、Contributionも受け付けることが可能です。もし新しい機能を提案したい場合は是非このグループに提案してください。

しかし、機能を追加するだけではWeb Platformを健康に保つことはできません。よって、機能の削除も行います。削除の理由には、他のAPIとの入替えや、実験的に作ったが上手くいかなかった、というものがあったりします。3つ前までで削除された機能のリストがこちら(goo.gl/5gq1Im)です。今後、requestAutoCompleteだったり、HTML5 App Cacheのような影響の大きな機能も削除しようとしています。まだ使われている機能、APIをいきなり削除しないというようなポリシーもありますので安心してください。

これまでの成功の紹介

それでは、ここ数年での成功を紹介します。私がここに立っている、ということは何のことだか分かる方も多いかも知れませんが、そうですWeb MIDIです。

MIDIは知ってる方もそうでない方もいると思います。仕様ができてから30年以上にもなる楽器のキーボード、シンセサイザー等、電子楽器同士、またはコンピュータとを接続する標準化されたプロトコルです。数年前Web Audioで遊んでいたときに「これを楽器のキーボードから操作したい」と思い立ったW3Cにて標準化を始め、Chromeでは去年Shipされました。

ChromeでのShip以降、多くの楽器メーカがユーザー体験を提供するプラットフォームとしてWebを使い始めました。Yamahaはrefaceという新しいシンセサイザーのラインナップに対してSoundmondoという音色のエディタ、ライブラリアンを提供するWeb MIDIを使ったサービスを展開しています。NovationのCircuit Groove BoxはWebに接続して新しいサンプルをダウンロードします。これらの作業においてソフトウェアを新たにインストール必要はないのです。

そして、間違いなくスゴイことはフランスのEDMアーティストであるMadeonがWeb Audioで作られたRemixBoardをWebサイトで公開したことです。ファンに向けられて作られたサイトで、彼のアルバムの中の音をRemixして遊ぶことができるのです。もちろんMIDIデバイスも接続してプレイすることができるようになっているのです。
（デモ（パフォーマンス？）が始まります。実際の動画を御覧ください）

デモアプリのURLはこちらwww.madeon.fr/adventuremachineです。

「これスゴイでしょ？！」と言いたいのですが、本質はそこではなくて「ハードウェアがブラウザにアクセスできる」ということが大きな可能性を生んだ、ということを伝えたいのです。ちょうど加速度センサから素晴らしいユーザー体験（UX）が生まれ、モバイル・デバイスが大きな可能性を持ったのと同じようにです。他にも接続できることで大きな可能性が生まれるデバイスはたくさんあると思います。我々は、そこにある可能性を積極的に解き放っていきたいと考えています。

（ここでChris氏からFrançois氏に交代）

これから何が起こるのか

Web Bluetooth

Bluetoothの名称の由来の説明から始まります。（詳しくはWikipediaのBluetooth 「名称の由来」をどうぞ）

Bluetoothはいろいろなバージョンで20年成長してきた技術で、最新はBluetooth Low Energy（BLE）が導入されたVersion 4でリリースされてから6年経過しています。Wi-Fi、Ethernetのスピードは継続的に上がっていますが、Bluetoothはちょっと様子が違っています。

なぜなら、今まで接続されていなかった多くのデバイスに搭載できるようにバッテリの消費量を最小限にできるようにデザインされているからです。例えば小型のデバイスが使うバッテリは、通常CR2032です。（2032の20は直径、32は厚さを表すそうです！）なので、転送速度はとっても遅いのです。ですが、BLEはそもそも転送速度が遅くても大丈夫なデバイスをターゲットにしているので問題はありません。

それでは、デモをしてみます。デモはPlaybulb Candleという電球のOn/Off、色をBluetooth通信にて変更できるデバイスをWebアプリから操作します。（映像には全体が映っていませんでしたが、会場ではこんな感じでデモが行われていました）

Bluetooth SIG(Bluetoothの規格の策定、技術利用に対する認証を行う団体)は、これから先2年で96%の電話、タブレットにBLEが搭載されると予想している。そこからも、いろいろな場所でBLEが存在するであろうことがお分かりになると思います。

Web BluetoothのAPIを説明する前に、一度BLEの動作を復習してみます。Bletoothには、以下の2つの機能があります。

• Central：近隣のデバイスを探索する（電話、ラップトップPCの等）
• Peripheral：周囲に向けて継続的に自らの情報を格納したアドバタイジング・パケットをBroadcastする。（心拍センサ、ビーコン、冷蔵庫等）

PeripheralがCentralに接続（ペアリング）されると、Peripheralはアドバタイジング・パケットのBroadcastを停止し、CentralがPeriferalで動作するGATTサーバと通信を開始する。通信に関しては、デフォルトで用意されているバッテリ、心拍のようなサービスも存在していますが、もちろん独自にサービスを作ることも可能になっています。それぞれのサービスにはそれぞれのCharastristicに属性を持っていて、読込み（バッテリーレベルの取得等）、書込み（設定の変更等）、また更新時に通知（心拍数のリアルタイム監視）してもらうことも可能です。Web Bluetooth APIを使って書いたサンプルを説明していきます。

値の読込み

コードはラップトップがCentral、何かしらのデバイスがPeripheralとなっていることを想定しています。まず、Centralのラップトップがnavigator.bluetooth.requestDevice(option)をCallして近隣のデバイスを探索します。optionにデバイスが山ほど列挙されないためにどの種類でフィルタするかを記述します。コードではバッテリのサービスは標準化されているので「batttery_service」と文字列で指定していますが、アドバタイジングパケットにはカスタマイズした値も書込むことが可能です。

navigator.bluetooth.requestDevice(option)をCallすることで探索が開始され、それと同時にアドレスバーの直下に該当するデバイスを列挙するポップアップが出てきます。ユーザがリストからデバイスを選択すると、JavaScript側ではそのデバイスのデバイス名、利用可能なサービスが格納されているオブジェクトにアクセスが可能になります。

ここでセキュリティに関する注意点。
navigator.bluetooth.requestDevice(option)はユーザのインタラクションにて初めて動作します。デモではボタンクリックで開始していました。Localhost以外のホストでWeb Bluetoothを使う場合は、HTTPSでコンテンツがServeされたことを要求している。

device.get.connect()をCallしてGATTサーバと接続をします。その後に、server.getPrimaryService(‘battery_service’)でバッテリサービスを取得、service.getCharacteristic(‘battery_level’)で読込みたいCharacteristicを指定して取得、最後にcharacteristic.getValue()をCallすることで、バッテリのレベルの読込み（取得）をすることができます。

値の書込み

先ほどとは違い、心拍センサをPeripheralとしています。その他、ハイライトされた部分が違います。charctristic.writeValue()にUint8Arrayにて、1バイトを引数に渡すことで書込みを行っています。

更新の受取り

この例でも、心拍センサをPeripheralとしています。この例でも、ハイライトされた部分が違います。characteristicにcharacteristicvaluechangedのイベント名でEventハンドラを設定し、beepという関数をCallbackとして指定しています。characteristic.startNotifications()で、更新の受け取りを開始します。これで、更新がある度にbeepが実行されます。

続いて、心拍センサを動作させるデモです。私（François氏）は心拍センサをつけています。リアルタイムに値を受け取ることができますので、ちょっと見てみましょう。通常私の心拍数は60-80ですが、今はどうでしょう？

（普段の倍近くの心拍数が表示されChris氏も会場も爆笑）
次に実際にリアルタイムに心拍数を受け取っていることを証明するために腕立て伏せをしてみます。（前編の最後に掲載さいた画像はここでの1シーンです）
（が、ペアリングが切断されたのか動作せず……そして、今度はChris氏も会場も大爆笑！失敗するということは、デモがリアルタイムに行われている証拠です！）

私以外にも、Web Bluetoothで遊んでいる同僚たちもいます。

Bluetoothのパケット通信の中身を見るときはAndroidを使うのが最も簡単な方法です。AndroidのDeveloper Optionにある「Bluetooth HCI snoop log」を有効にしてください。（詳しくはこの辺りを参照してみてください）

現在Web BluetoothをサポートしているブラウザはOperaとChromeOS、マシュマロ上で動作しているChrome for Android、Chrome for LinuxでChromeでは chrome://flags/#enable-web-bluetooth （アドレスバーにコピー＆ペーストしてください）を有効にすることで利用することが可能です。Mac、WindowsのChromeへは現在実装中です。

開発の助けになるであろう以下の2つを紹介します。

• Get Start with Web Bluetooth (goo.gl/MLKzj2)：コードジェネレータ
• Web Bluetooth Developer Studio Plugin (goo.gl/c2ype5)：Bluetooth SIGが提供しているBluetooth Developer Studio向けのPlug-in

WebアプリからでもNativeアプリと同じように、Bluetoothでデバイスを操作できるようになりました。また、Webアプリですので、URLをシェアすることで、誰でもスグにアプリを利用できるようになります。当たり前のことかもしれませんが、これがWeb Platformの大きな強みです。

Physical Webとの連携

URLを載せたBluetoothのパケットをビーコンからブロードキャストするPhysical Webですが、これがもしBluetoothのアプリからブロードキャストできたらどうでしょう？

URLをPhysical Web経由で受け取り、そのURLにアクセスするとBluetoothデバイスをコントロールするアプリが表示され、Bluetoothデバイスとのペアリングが完了したら、その直後からBluetoothの利用が可能になりますよね。今までのアプリを検索してインストールする等の作業が一切必要がなくなり、通知エリア(Notification Area)に通知されたURLにアクセスするだけでペアリングも含め、Bluetoothデバイスを利用する準備が整うことになります。

今後、Web BluetoothはPhysical Webの機能を組み込み、前述の動作を一気通貫でJavaScriptで実装できるような機能を追加する予定です。

CodelabもControl a PLAYBULB candle with Web BluetoothとInteractive with Bluetooth devices on the web with Polymerもありますので、是非挑戦してみてください。

（再びChris氏）

Web USB

Web USBは現存する全てのUSBデバイスに接続しようと考えているわけではなくて、Firmwareへのアクセスを許可されているような新しい種類のデバイスに適用されます。

まとめ

ここではカバーしきれなかった、まだまだ多くの以下の様な機能が進行中です。

さらに、まだデザインも始めていないPersistent Storageとか、Web Intents v2もあります。

そろそろ時間です。我々がWeb Platformの未来にワクワクしているのと同じくらいに、皆さんもワクワクしていることを期待しています。

developers.google.com/web/updates/ にさらなる情報がありますので、お時間がありましたらご覧ください。

（というところで、セッションは終了しました）

ありがとうございました＆お疲れ様でしたっ！！！

Meetupを「札幌」で行うキッカケ

2015年10月末はなぜか札幌でのイベントが多かったと思いますが、これ実はW3C Technical Plenary / Advisory Committee(通称：TPAC、てぃーぱっく)というMeetingが札幌で行われたからなのです。

詳細はWeb技術の最新動向と未来を知る！〜Leading the way to W3C TPAC 2015〜【TPAC紹介編】にも書かれていますが、ここでも軽くご説明します。TPACとはWebの標準化団体であるW3Cが年に1回行う全体会合で、通常10月最終週の5日間で北米、ヨーロッパ、アジアのどこかで開催されます。

全体会合とはいえ、5日間通して全体会議をしている訳ではなくて、実際に全体で集まるのはたいて中間日のTechnical Plenary Dayと呼ばれる日。この日だけはアンカンファレンス形式で進められ、当日の朝に話したい内容がある人が場所を確保して分科会(Breakout Session)を行う、という流れになっています。

この日以外は、W3Cにある43のワーキング・グループ（2015年11月6日現在）からそれぞれが議論したい内容、メンバーのスケジュールから日程設定してFace to Faceでのミーティングを行っています。たいていの場合メンバーは世界各国に散らばっているため、普段は電話での会議をしているので顔を合わせてミーティングを行うのは、非常に貴重な時間となっています。

前段が長くなりましたが、ここから本題です。Web Audio API、Web MIDI API（Web Music）の仕様を策定しているのはW3Cのオーディオ・ワーキンググループ(Audio WG)。今回のTPACでは26日、27日にミーティングを行うことになりましたので、せっかくのこの機会に「Audio WGのメンバーとイベントやろう！」と思い立ったのが、今回のMeetupのキッカケです。

「札幌」でWeb Musicは初めて

今まで日本で開催されたWeb Music関連イベントは、東京と京都でのハッカソンとMeetup1回だったので、北海道では初めて。そこで、Meetupにして「Web Musicとはなんぞ？」を中心に伝えられるように、以下の方々に登壇していただきました。

• かわい りょうや（開発者、私です）
• Chris Wilson 氏 (Web Audio/MIDI 仕様の編集者)
• 藍 圭介 氏（開発者）
• 豊島 隆志 氏（ChromiumコミッターでWeb MIDI APIの実装者）
• Joe Berkovitz 氏 (Audio WGの共同議長)
• 渡邊 正和 氏（開発者：VJアプリを主に開発）

セッションの内容

かわい りょうや

Web Audio、Web MIDIとは何か、何ができるのか、どのブラウザで使えるのかを中心に話をしましたブラウザで電子楽器を作ってみよう！でご紹介したWeb Audioで作ったアナログ・シンセ、FMシンセの紹介とデモを行い、基本的な使い方とできることの説明、またそれに加えて今回はServiceworkerを使ったオフラインでの動作のデモ、またデスクトップからアプリを起動できるWebApp Manifestのデモも実施。モバイル上でもWebアプリは進化していてNativeアプリに近づいていることの説明を行いました。
▶ スライド

Chris Wilson 氏

Making the Web RockというタイトルでDrum Machine、ボコーダー、Audio Input Effect、DJと次々にデモを披露していただき、「Web Audio API、Web MIDI APIを使うとWebブラウザ上でここまでできます」という点を幅広く説明してくれました。また「このWebアプリのチューナができたおかげでOSネイティブなチューナーアプリ（iOSやAndroidのアプリ）は全部消した」という実話も披露していただきました。チューナーとは音の周波数（音程）を正しく調整する為に使う器具のことです。
▶ スライド

ここでChris氏の発表の中から「Webアプリのチューナ以外のOSネイティブなチューナーアプリを削除できた」という点について、旬な話題ですので少しだけご紹介します。

どのようにWebアプリのチューナーが実装されているか
チューナーは例えばギターの弦1本1本を正しく調整（チューニング）する為に、1本の弦を弾いた時に発せられる音声を入力して周波数を正しく表示します。この表示に従って、弦毎にあるべき周波数にチューニングをすることで常に正しい音で演奏しています。このチューニングは演奏する間に必ず行うので、自宅のみならず、あらゆる場所で動作することが求められます。ここでまとめるとチューナーという器具には最低限以下の2つの要件を満足することが求められます。

• 入力した音声の周波数を正しく表示する
• 携帯性に優れている

モバイル・デバイスのアプリ（iOSアプリケ、androidアプリ；以後「モバイルアプリ」と略します）で製作したチューナーはこれらの2つの要件を満足します。チューニングに関してはマイクから入力した音の周波数を正しく表示するよく知られたアルゴリズムがありますし、携帯性に関してもチューナーアプリを一度ダウンロードしてインストールしてしまえばネットワークへの接続に左右されることなく携帯端末上で動作することが可能ですので、 場所を選ばずどこでも動作します。
前置きが長くなりましたが、ここからがこの2つの要件をどうやってWebアプリとして再現するのか？という点です。1つ目の「入力した音声の周波数を正しく表示する」に関しては、getUserMedia()を使いマイク入力をWeb Audio APIを使って周波数を割り出せばなんとか出来そうだと、とお気づきになると思います。しかしながら「携帯性に優れている」の点はいかがでしょうか？ネットワーク接続なしにどうやってWebアプリを動作させるのでしょうか？
その解決には Service Worker を使います。Webアプリを最初に起動した時に、アプリ全体をキャッシュしてしネットワーク接続のに場合はそのキャッシュを利用してアプリを動かすのです。WebアプリのチューナのService Workerの実装はココにされています。詳しい解説はここでは割愛しますが、Servive Workerインストール時（最初にサイトを表示した時と考えていただいて問題ありません）に、以下の部分でWebアプリのチューナーに必要なファイルをキャッシュしていることが分かります。

self.oninstall = function(event) {

  var urls = [

    '/',
    '/images/chrome-touch-icon-192x192.png',

    '/scripts/guitartuner-core.js',

    '/elements/audio-processor/audio-processor.html',
    '/elements/audio-visualizer/audio-visualizer.html',
    '/elements/tuning-instructions/tuning-instructions.html',
    '/elements/tuning-instructions/tick.svg',
    '/elements/tuning-instructions/up-down.svg',

    '/third_party/polymer.html',
    '/third_party/webcomponents-lite.min.js',

    '/third_party/Roboto/Roboto-100.woff2',
    '/third_party/Roboto/Roboto-300.woff2',
    '/third_party/Roboto/Roboto-400.woff2',

    '/favicon.ico',
    '/manifest.json'

  ];

  urls = urls.map(function(url) {
    return new Request(url, {credentials: 'include'});
  });

  event.waitUntil(
    caches
      .open(CACHE_NAME + '-v' + CACHE_VERSION)
      .then(function(cache) {
        return cache.addAll(urls);
      })
  );

};

もう1点は起動に関してです。Webアプリとして再現できたのに、起動がブラウザのブックマークからだったり、URLバーが表示されていては少しガッカリです。androidであれば、Webアプリであっても、ホーム画面のアイコンから起動し、URLバーを表示しないことが可能です。また起動時のデバイスの向き、スプラッシュ画面（起動処理中に表示する画像）を設定することも可能です。これを Web App Manifest と呼ばれる機能になります。Webアプリのチューナではココに実装されています。

{
  "short_name": "Guitar Tuner",
  "name": "Guitar Tuner",
  "start_url": "./?utm_source=web_app_manifest",
  "icons": [
    {
      "src": "/images/chrome-touch-icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ],
  "display": "standalone",
  "orientation": "portrait"
}

この数行のJSONを設置して、メインとなるHTMLには以下の1行を追加して読み込ませたらモバイルアプリと同じユーザー体験（ホーム画面からの起動）を提供することが可能になります。

<link rel="manifest" href="/manifest.json">

詳細な説明は割愛してしまいましたが、こういった技術を使ってProgressive Web Appsを作ってみてはいかがでしょうか？

藍 圭介 氏

Web Audio API Creative Codingというタイトルで、moogのアナログシンセのWeb版の2D版、3D版、それ以外にもセンサーを使うことでWahペダルだったり、ライトセーバーのような動きに反応するアプリケーションも作ることが可能というデモを実施。Web Audio/MIDI以外のAPIとの親和性も高く、手軽に使えることから「Web Audio/MIDIは音楽のためのみならず、表現メディアのプラットフォームになり得る」という点をご説明してくださいました。
▶ スライド

豊島 隆志 氏

Chrome Web MIDI 2015というタイトルで発表。実際にChromeに実装をしているので、今までのWeb MIDIの実装の歴史、AndroidのWeb ViewでもOperaでもElectronでもChromeと同じようにWeb MIDIが使えるようになっていること、Firefoxでの実装状況、Web MIDI APIの使われる頻度等、APIを実装するという視点から発表をしてくれました。
▶ スライド

Joe Berkovitz 氏

Music Notation and W3C: Framing the Futureというタイトルでの発表。Audio WGの共同議長でもあり、また2015年7月にW3CでMusic Notation Community Group(楽譜に関するグループ)の立ち上げも行っており、普段はnoteflight Inc.にてブラウザ上で楽譜を表示、演奏するアプリケーションを開発しています。今回の発表では、Noteflightが実際に楽譜表示を軸にどういった機能を実装しているのか、またWeb上で表示できるようになるとどう変わるのかをデモを交えながらの発表でした。
▶ スライド(PDF)

渡邊 正和 氏

ライブパフォーマンス、その他（例えば教育）でのWeb Audio/MIDIの活用事例を紹介。Audio/MIDIがWeb上で使えることで拡がった、音楽の世界を語ってくれました。リサジューのデモも披露。

• Takashi Moriさんの演奏とのコラボ
• NETWORKSとのコラボ
• エレクトロボイスとビジュアルアート

Lightning Talk

3名、1団体からの発表がありました。

• @aklaswadさん: wani[WebAudio N Interface]のデモ
• 高橋さん：ワンセグチューナーから電波を拾ってthree.jsで電波を表示するデモ
• 小池さん：楽譜アプリのpiaScoreの説明とPlasaddがスタッフ募集している件、
• ヤマハ株式会社：MIDI、音楽系でよく使われるOSC(OpenSound Control)と、Web Socketをごちゃ混ぜのシステムでも簡単に構築できるRaspberry Piで作ったシステムの紹介がありました。

Meetupを終えて

今回Audio WGでコアに動いている方のほとんどがMeetupに足を運んでくれたこともあって、日本の皆さんにはもとより、Audio WGの皆様には「こういう使われ方もしている」という現状を見ていただけて、とてもよい機会になったと思っています。今後もこういう機会があったら企画したいと考えています。
▶ 写真等

おまけ：Web Audio、Web MIDIの進捗に関して

W3Cが定める仕様策定までの5段階のうち、Web Audio/MIDI共に、現在は1つ目の段階（WD:Working Draft）です。しかし、Web Audioは次の段階（LC:Last Call）へと進む気配があります。早くて年内、遅くとも来年4月（Web Audio Conference 2016があります）ではないでしょうか。またWeb MIDIに関してもFirefoxに実装が進んでいてMac OSでは動いているとのことですので、こちらも次の段階へ進むことへの期待ができるでしょう。

それでは、今後もWeb Musicをよろしくお願いします！

概要

Google I/O 2014のセッションの1つ「Making music mobile with the Web」のレポート記事です。Officialに公開されているYouTubeはこちらです。

OpenWeb 技術であるWebRTC、Web Audio APIは一度は耳にしたことのあると思います。この2つの技術、そして標準化が始まったばかりのWeb MIDI API（電子楽器とブラウザを直接接続するAPI）を利用した音楽制作アプリケーション「Soundtrap」。これらを使って、実際にセッションのオーディエンス、遠隔地の人とコラボレーションをして、Google I/Oのテーマ曲を作成するデモンストレーション中心のセッションでした。本レポートと合わせて映像もぜひご覧ください！

このセッションでは、主にモバイル端末（Nexus 7、Nexus 5）を使って進行されました。Webアプリといえば、JavaScriptでの構築を想像される方も少なくないので意外でした。しかしながら、「Soundstrap」はDartで開発されていたところでした。(開発言語にDartを選択した理由も、後ほど説明していきます)

それでは内容を見ていきましょう。

※2014/7/4にDartは、ECMA標準仕様として承認されたと発表がありました。

音楽制作

音楽制作にはいろいろな進め方がありますが、このセッションでは以下の順で録音が進められました。

1. リズムの選択 (1:49-)
2. Bass の録音 (3:02-)
3. Guitar(メロディー)の録音 (15:11-)
4. Keyboard(伴奏)シーケンスの作成 (16:28-)
5. Vocal の録音 (23:30-)
6. Mix Down (34:55-)

1. リズムの選択

曲のベースとなるリズムを決めます。Soundtrapにあらかじめ用意されているLoop素材を追加し、リズムを聴きながら「ん～」とか「もっとRockしてるのがいいな～」とかコメントしながら選択を終えました。

2. Bassの録音

Bassの音はあまり耳には聞こえませんが、実は曲の重要な土台となる低音パートです。 Bassの録音をすると、リズムしかなかった曲の輪郭がモヤっと見えてきます。

Bassを録音する様子

Media Capture APIの1つである、getUserMedia()を使って録音します。

getUserMedia()は、マイクからのInput、WebカメラからのビデオStreamを取得する時に使います。マイクからのInputを取得する時は、スピーカーからの出力をマイクが拾わないようにAEC(Acoustic Echo Canceling)、またマイクからのInputのレベルを保つために AGC(Auto Gain Control)を行うことが可能です。マイク以外の入力を取得する場合（Line入力：ギター、シンセサイザー等）は必要ないので、今回もOffにします。コードは以下のように書きます。

navigator.getUserMedia({audio:{echoCancellation: false}}).then((stream) {
  // 実際の処理をここに書きます
});

then() が見慣れない書き方かもしれませんが、これはDartに実装されている Futureという並列処理デザインパターンです。streamを得た時にどんな処理をするのかを、then()の中に書きます。

3. Guitar（メロディー）の録音

Guitarで主旋律パートを録音します。主旋律ですので向かう方向がハッキリします。

Guitarの録音をする様子

Bassの録音と同じく、getUserMedia()を使って録音します。

特にギターの場合、エフェクターという専用の信号処理機械を通して音を作ることが多いです。エフェクトの種類は音を遅らすDelay、音程を微妙にズラすことで複数でコーラスをしているかのようなハーモニーを作るChorus、音を歪ませることで音に角を付け、いわゆるエレキギターと聞いて想像する音を作るFuzz、Distortion、Overdriveがありますが、これらのエフェクトもブラウザで行ってしまいます。（セッション内でのデモ）

これらのエフェクトは、以下のように接続します。

Input(getUserMedia()からのAudioStream)をWebAudioで作成したEffectsを通し、WebAudioでの音声の出力口であるDestinationに接続します。

Delayエフェクトの接続方法を例にとって、実際に説明をします。

Guitarの音(Input)を直接Destination、またDelayに接続します。Delayで任意の時間遅らせて発音した音を、Gainに接続して音量を絞ります。最後にDelayで遅らせ、音量を絞った音をDestinationに接続します。結果としてギターで弾いた音は、山に向かって「ヤッホー」と叫びやまびこを楽しんでいる人の隣で聞いているかのような効果、つまりEffectが得られるのです。

この接続をコードにすると、以下のようになります。

var context = new AudioContext();

// getUserMediaのAudioStreamをWebAudioに接続する
navigator.getUserMedia({audio:true}).then((stream){
  var guitar = context.createMediaStreamSource(stream);
  var speaker = context.destination;
  guitar.connect(speaker);
});

// Delayエフェクトの接続
var delay = context.createDelay();
guitar.connect(delay);

var gain = context.createGain();
delay.connect(gain);

// Delayエフェクトをかけた音を、出力口のSpeaker(Destination)に接続
gain.connect(speaker);

4. Keyboard(伴奏)シーケンスの作成

そして、Keyboardで伴奏パートのシーケンスの作成を行います。伴奏が入ると曲がハッキリし、各楽器通しでハーモニーが生まれます。

左下小窓がMoscone Center West、全体がGoogle San Francisco OfficeからWebRTC でStreamingしている様子

WebRTCを使って、上の画像のように遠隔地から行います。Google I/Oの会場であるMoscone WestとGoogleさんのSan Francisco Officeを接続し、シーケンスを直接Soundtrapに作成します。Keyboardの演奏はWeb MIDI APIを使い、Keybord（電子楽器）とブラウザを接続して演奏データはMIDI Messageの形式(音声データではなく、「どの音を、どの強さで鳴らせ/止めろ」というような指示を表現したメッセージ)で時間と一緒に記録（シーケンスの作成）を行い、再生する時には記録された時間通りにMIDI MessageをSoundtrap上にあるSoftwearシンセサイザーに送信して、Softwareシンセサイザーが音を出しています。

セッションの中で説明はありませんでしたが、Web MIDI APIを使って電子楽器とブラウザを接続するコードを以下に紹介させていただきます。

// 電子楽器と接続
navigator.requestMIDIAccess({sysex:true}).then(successCallback, errorCallback);
function successCallback(access){
　// 入力として利用可能な電子楽器のリストをConsoleに出力
　var inputs=access.inputs()
  console.log(inputs);

　// 入力として利用可能なindex=0の電子楽器から受信したMIDI MessageをConsoleに出力
  inputs[0].onmidimessage=function(event) {
    console.log(event.data);
  }

　// 出力として利用可能な電子楽器リストをConsoleに出力
  var outputs=access.outputs()
  console.log(outputs);

　// 出力として利用可能なindex=0の電子楽器にMIDI Messageを送信
  // A4(ラ：440hz、MIDI Key番号：0x45(69))を最大音量(7F(127)で発音させる例)
  outputs[0].send([0x90, 0x45, 0x7f]);
}
function errorCallback(msg) {
  // 何らかの問題で電子楽器との接続ができなかった場合、Consoleにエラーメッセージを出力
  console.log(msg);
}

※JavaScriptでの書式になります。 .then()に関して、書式はDartとJavaScriptで同じですが、Dartでは Futureという並列処理デザインパターン、一方JavaScriptではPromiseという並列処理デザインパターンですので、内容は正確にいうと異なりますのでご注意ください。

次に、WebRTCの接続についてです。WebRTCは、RealtimeにPeer to PeerでAudio、Video、Dataの3種類のStreamを使ったコミュニケションができるAPIです。接続には、PeerConnectionを使います。Soundtrapにてビデオチャットを行いながら音楽制作を行うためには、ビデオチャットを行うWebcam stream、音楽制作用に楽器のステレオ音声を送るStereo music streamが必要になります。

ビットレートはそれぞれStereo music Streamが128Kbps、Webcam streamがVP8 HD 2Mbpsで、PeerConnectionを使ってStreamしています。

5. Vocalの録音

録音の最後はVocalです。これで曲のメイン素材の録音、作成が完成です。

Nexus 5を片手に会場で歌声を録音する様子

Vocalの録音はNexus 5(携帯電話)を使用して、getUserMedia()を使って録音を行います。実際に歌うのはセッションのオーディエンスです！！（私の声も聞こえるかもです）マイクではなく、携帯電話をマイク代わりにして、Soundtrapに直接録音を行います。

6. Mix Down

「マスタリング」とも呼ばれ、各パート毎に音量の調節、音程の音量調節(Equalizing)、また残響(Reverb、Echo)の調節を行うことで各パートの音のバランスをとり、ハーモニーを深め、そして際立たせます。

SoundtrapはCloud型の音楽制作Webアプリケーションですので、インターネットに接続できる環境があればどこからでも音楽制作に参加することができます。もちろん、Mix Downをすることも可能です。セッションでは、Keyboard を弾いていた場所(GoogleさんのSan Francisco Office内で、セッションはMoscone Westです)でMix Downが行われました。

SoundTrap上に各パートが録音された状態

その結果、Google I/Oのテーマ曲はこのように仕上がりました。（下の画像をクリックすると視聴できます）

波形をWebGL表示した背景と共に再生されました

こちらは Soundtrap内に保存されている音源をそのまま視聴できます 。試聴する

開発言語にDartを選択した3つの理由

冒頭に、Soundtrapの開発にDartが採用されたことに触れました。以下の3点が、Dartを選択した理由だそうです。

親しみやすさ(Familiarity)

Dartはとにかく簡単に学べるようにと考えられて作られいて、Class や単一継承にセミコロン、中括弧を使うところがJavaScriptや、Java、C++にとても似ているので開発者にはとても親しみやすい。

拡張性(Scalability)

Webアプリの開発はとても小さなスクリプトから開始し、それが成長して大規模で複雑なアプリになっていく。従って大規模になった時のことを考えると、スケールアップができる環境で開発を開始することが望まれる。DartではそれをLibrary、またPackageという形で実現している。

Soundtrapの開発は、これらのDartの拡張性によってアプリが大規模になった時でも、開発のスピード（生産性）を落とすことなく進めることができたそうです。

生産性(Productivity)

Dartで開発する時は、Dart Editorを使うことができます。このEditorではコードを静的監視しているので生産性がとても高いです。例えば、静的監視されているので、アプリを動作させなくても、Unitテストを走らせなくても構文エラーをリアルタイムに知ることができるのできます。つまりDart Editorは、世の中にある熟れたIDEと同じような機能が搭載されているツールになっているので、不自由はなく、生産性高く進めることが可能です。

まとめ

Soundtrapは、OpenWeb技術であるMedia Capture、Audio Processiong、Real-time CommunicationのAPIの紹介にはとてもよいアプリケーションです。今回はChrome上で動作させて紹介しましたが、これらの技術はOpenWeb技術ですので、デスクトップ、モバイル環境にある別のブラウザでも動作させることが可能です（可能になるでしょう）。また、これらの技術を使うことのできる世の中のデバイス数は、以下の通りです。

• Web Audio 20億のデバイス（10億がモバイル）
• WebRTC 15億のデバイス（3億がモバイル）

そして Android LのWebViewではChrome V36相当になりますので、Web Audio、WebRTCがほぼすべてのAPIをサポートされた形で使えるようになります。30日でのアクティブユーザ数が10億のAndroidという環境ですので、ものすごく多くのユーザーに対して、これらを使ったアプリケーションの提供が可能になるため、そのインパクトは絶大です。

Q&Aで質問が出た項目

Q. Android LでのAudioのLatencyについて教えてください。

A. 数値の約束はできないが、改善に向けて真剣に取り組んでいる。ICS、JB、Kitkatで20msまでLatencyを短縮することはできた。しかしながら、我々としてもまだまだ満足はしていないので改善していくだろう。

Q. MIDIのサポートについてどこまで進んでいるのか教えてください。

A. Web MIDI APIはOpenWebStandardとして標準化が始まったばかりで、Chromeは先行して実装を行った。次期、またはその次のVersionでは全ての機能の実装を行い、さらにFlagの設定なしでの動作させる予定です。セッション内でSoundtrapで利用しましたが、もちろんセッション内だけなく、Soundtrap内ではMIDIの接続も利用することが可能です。
Chrome以外のブラウザでのサポートに関しては、現状様子見を行っています

Q. Mix Downはクライアントサイドで行っているのか、サーバーサイドで行っているのか教えてください。

A. 音源はクラウド上のサーバー側にあって、再生をクライアントで行っています。サーバサイドはJavaとScalaで利用可能なPlay Frameworkを使っています。クライアント側で再生する時は、サーバー側でMix DownしたMP3ファイルを作成し、それをSoundtrapというクライアントアプリ側で再生をするという仕組みになっています。

セッションを終えて感じたこと

Before Web Audio/MIDIの時代では、DAW（音楽制作用ソフトウェア）を購入し、Audio I/F、キーボード、マイク等のハードウェアを揃えながら満足できる音楽制作の環境を整えるまでには、いささか道のりが長く時間がかかるのが常識で、またそこを楽しむこともありました。

しかし、Webブラウザで、デスクトップはもちろん、モバイルデバイス上での制作、さらには遠隔地とつないで、誰でも手軽に音楽制作に手を伸ばすことのできる時代（味見も含めて）なのだなと改めて感じました。制作はもちろんですが、ツールの作成、エフェクトの作成等、少し頑張れば、かゆいところに手の届くいわゆるオレシステムを作り上げることもそこまでハードルは高くないと思います。

今やアマチュアバンドとはいってもホームページを持ち、そこには自ら制作した楽曲、さらに自らで制作したであろう、とはいえクロリティの高いプロモーションビデオまでも揃えて公開する時代。昔はインスピレーションを得たらその場でフレーズやパターンの作成ができ、モバイルできる音楽制作専用ハードが流行した時もありました。

これからはインスピレーションを得たらポケットからさっとモバイルな汎用デバイスを取り出し、ブラウザを立上げDAWのURLに接続をし、その場でフレーズのみならず全体の流れを録音し楽曲にまとめることも容易になるでしょう。そして、遠隔にいる友人にバッキング、Mix Downしてもらい、その場でプロモーションビデオまで制作する一連の流れを即興でできてしまう、なんていうアマチュアでもプロ顔負けの音楽制作環境を持てる、素晴らしい時代が確実に来るだろうと感じました。同時に、これらの音楽制作に欠かせない技術と他のOpenWeb技術を連携させることでどのような新しい表現方法、また価値、文化が生まれるのかワクワクを膨らませてきた次第です。

W3Cの一員として標準化を進めているWeb MIDI API。今回は少しだけ登場し、スライドとしての説明はありませんでしたが、音楽を制作をする上ではコアになる技術です。標準化までこぎつけられるように強く推進をしていかねばとも感じました。

紹介されたURL等

• Soundtrap：デモで使われたOpenWeb上に構築された音楽制作環境
• Getting Started with WebRTC：WebRTCのチュートリアル（英語）
• Getting Started with the Web Audio API：Web Audio APIのチュートリアル(日本語)
• Get Started with Dart：Dartのチュートリアル（英語）

Web MIDI APIはWeb Audio APIと並ぶ音楽系のAPIです。あまり馴染みのないMIDIですが、Web MIDI APIを使うことであらゆる電子楽器とブラウザの接続が簡単にでき電子楽器からブラウザ上のアプリケーションを操作、また逆に、ブラウザ上のアプリケーションから電子楽器を操作することが可能です。

「HTML5 Conference 2013」では、MIDIの基礎、Web MIDI APIの概要、また10月末に発表された音声合成技術について、AMEI Web MIDI WG/ヤマハ株式会社の河合良哉氏が紹介。ハードウェアに搭載したLSI「NSX-1」を1ボードに収めた「eVY1 SHIELD」を使ったデモアプリケーションや、WebとMusicの世界について語られました。

MIDIの基礎と、Web MIDI APIの概要

現在、MIDI規格の標準化・企画の策定・管理・普及活動（MIDI検定試験）を行っているのは、一般社団法人音楽電子事業協会AMEI（Association of music electronics industry）。2013年9月にWeb MIDI Working Groupを発足させ、W3Cに加盟し、Web MIDI APIの規格策定・普及活動を開始しました。

Web MIDI APIは、あらゆる電子楽器とブラウザの接続が簡単にできる音楽系API。電子楽器からブラウザ上のアプリケーションを操作でき、さらにブラウザ上のアプリケーションから電子楽器を操作することも可能です。

MIDI（Musical Instrument Digital Interface）とは、電子楽器同士を接続するインターフェースであり、31.25Kbpsの非同期方式シリアル通信とデータの単位は8bit（1byte）を用いています。端子はIN、OUT、THRUの3種類があり、端子でつながっている複数の楽器を同時に制御することが可能。また、16チャンネルを持っているので、16個の音色を同時に操ることができます。

MIDIにはチャンネルメッセージ・システムメッセージの2種類があります。チャンネルメッセージでは、チャンネルごとに独立した演奏情報を伝え、システムメッセージでは全体をコントロールする情報を伝えます。システムメッセージには様々なものがありますが、NoteOn（音を発生）、NoteOff（音を止める）、ProgramChange（音色を変える）、SystemExclusive（複数の機器をコントロール）の4つを使うだけでもMIDIをかなり楽しめるでしょう。これらのメッセージでさまざまな表現の可能性を持つのがMIDIです。

注目を集めるWeb MIDI API

MIDIのメリットはいろいろありますが、まず挙げられるのはmp3のようなバイナリデータと違ってデータ量が少ないところ。NoteOn（音を発生）、NoteOff（音を止める）など信号だけをやりとりするため、1分間あたりのデータ量は10kb以下。またMIDIでは接続した機器のON/OFFに強弱がつけられる。さらに「今から1分後にある音を鳴らす」など、シーケンスを書けるところも大きな魅力です。

MIDIのユースケースには音楽用途とそれ以外があります。音楽用途としては、電子機器の複数台コントロール・DAW（Cubase、Gragebandなど）・カラオケ、演奏記録アプリ・遠隔地ライブ配信など。カラオケはmp3配信も増えてきましたが、まだまだMIDIも多い。またヤマハ株式会社では、先日カリフォルニアのホールにいるエルトン・ジョンの歌声を銀座・韓国・ロシア・ブラジルに配信し、遠隔地と同期させる遠隔地ライブ配信を実施したばかり。音楽以外では、Show（MSC：MIDI Show Control）が興味深い。Universal StudioのアトラクションWater WorldやBellagioの噴水のコントロールにMIDIが使われています。

最近ネットワークとの融合で大きな可能性を秘めているMIDIですが、10月末にGoogleと共同でWeb MIDI APIのハッカソンが行われました。優秀賞には、TENORI-ON（16×16のマトリクスボタンで、音楽知識がなくても直感的に音楽を作り奏でられる手のひら大のデバイス）から発生するデータをMIDI信号に解析し、絵を割り当てるアプリVJ（Video Jockey）が選ばれています。

Web MIDI APIでは、他のAPIとのコラボレーションも容易になります。ハッカソン会場では、カメラを使ったGet user mediaとコラボレーションしたアプリもいくつか発表され、注目を集めています。

アプリ作成に関する情報としては、2013年11月末にWeb MIDI APIはアップデートされたばかり。以前より、いく分短いソースコードで表現することが可能になりました。ブラウザは現在Chromeに対応。FireFox、Opera、SafariではWeb MIDI API仕様が容易されています。IEは対応されていませんが、Microsoft connectによると「IE11には載せないが今後は載せたい」と前向きの様子です。

Web MIDI APIを使ったアプリに挑戦してみたい人たちのために、Web MIDI API Wrapperが公開されています。現在sendのみですが、これからreceiveも対応する予定とのこと。MIDIでつながる様々なデバイスをコントロールするアプリの楽しさを、多くの人達に楽しんでほしい、と河合氏はセッションを締めくくりました。

【講演資料・セッション映像】