この記事は2017年5月17、18、19日に米国カリフォルニア州マウンテンビューにあるAmphitheatreで行われたGoogleの開発者向けカンファレンスGoogle I/Oの3日目に「DevTools: State of the Union 2017」というタイトルで行われたセッションの内容です。

はじめに

Google I/O、Chrome Dev Summitと日に日に進化をし続けているChromeのDevTools。Google I/O 2017でも多くの進化が報告されました。

登壇者はwebっ子ならば泣く子も黙るDeveloper AdvocateのPaul Irish。軽快なトークで淡々と新機能が話された40分をまとめてみました。

ConsoleでのDebug

ConsoleはDebugには欠かせない機能。なので、我々はConsoleの進化に対して投資を惜しまず、かつ、楽しんで行っています。

Object Preview

今までも、ConosleでObjectの値の閲覧は可能でしたが、要素要素でクリックしないと内容の閲覧はできませんでした。それを解消しました。

旧表示が左側、現在Canaryでの表示は右側のような表示になっています。

Autocomplete

開発者の皆さんにはConsoleでの作業はできるだけ素早く、ストレスなく行ってもらいたいと思っています。ですので、Consoleでは常にAutocompleteがされるようになっています。

例えば、document.head.childNodesの内容を参照したい場合、document.headの要素が何であるかをDevToolsは知っているのでchildNodesなど要素名をサジェストをすることもできましたし、続けて例えば0番目の要素にアクセスをするためにdocument.head.childNodes[0]と入力して内容を参照することも可能でした。

しかし、その先はどうでしょう。今までですと、続けて.を入力してdocument.head.childNodes[0].とし、その要素を参照しようとしても表示されずにエラーとなっていました。しかし、現在では要素へのアクセスも可能で、もちろん要素名もサジェストしてくれます。

そして、例えば要素名に「-(ダッシュ)」が入っているObject。今までであればclasses[まで入力してもサジェストは表示されなかったのですが、現在ではサジェストされるようになっています。

Consoleへ直接コードを入力する場合の便利機能

ObjectをMapに変換する場合、Consoleへキーボードから入力するだけで変換可能になりました。

また、コードを直接Consoleへ入力する場合、今までは1行で入力する必要がありましたが現在では改行もコードの一部として受け付けるようになりました。インテント、さらには、Syntaxのハイライトもつくようになりました。この機能は去年まではありませんでした。

また⌘キー（Ctrlキー） + Dキー で同一の引数を一挙に変更可能です。

非同期（Asynchronous）なJavaScriptのDebugに対応した新機能

例えば、非同期処理のPromisesのDebugはとても難しかった。しかし現在では下の図のように、例えばCallStackには4つのCo-Frameがありそのうち2つは非同期の処理がある、ということを容易に把握することが可能です。ここで重要なのは、どのように動作したかを目で確認できることです。

ここでの例は非常に短いサンプルの紹介ですのでシンプルですが、実際のアプリではもっと複雑です。例えば下の図のような形です。

先程も述べた通りでここで重要なのは「どのように動作したかを目で確認できること」で、このように長いStackにおいても、どのように処理が流れになっていることがパッと見で分かります。

ブラウザのアプリの処理はsetTimeout()、requestAnimationFrame()、Promisesなどの非同期処理が連なっている同期処理の塊によって成り立っている。例えば、つい最近新たに発表されたReact Fiberのアルゴリズムは大きな処理の塊を小さな塊に分割するように設計されています。

これがあるスクリプトの非同期処理の0.25秒間をどう動作したか表している図です。矢印が非同期処理の流れを示しています。非常に忙しいスクリプトです。

見ての通りDevToolsでは非同期処理から次に何が起こっているかを表示することも可能です。特定の呼び出しから、次はどこの処理に遷移したのかを知ることはとても重要です。

これを手動で調査するとなると、とても時間がかかりますが、DevToolsを使えば、この図を見るだけで把握が可能です。DevToolsでは全ての非同期の処理を記録しているので、ページロード時からの全ての非同期処理を追うことができています。

これによって、プログラムのどこのポイントにおいても非同期処理の履歴を完全に追うことが可能になり、どのように到達したのか、またなぜ到達したのかを知ることが可能になっています。

AsyncのDebug

BreakPointを1つ1つ使って進むDebugもよく行いますが、あまり効率的ではないです。これがリアルタイムにできるようになっています。

例えば、console.log('Processing')にBreakPointを置き、⌘キー（またはCtrlキー）を押すと次にジャンプできる箇所を青色でハイライトします（下図：左）。そしてそれらの1つをクリックすることでそこまで進めることができ、さらにそこでプログラムの動作は停止します。

もちろん、直前のresultの内容も見ることができる（下図：右）。

PromisesのDebug

Promiseの処理の中にインラインでBreakPointを置くことが可能になりました。
14行目にBreakPointを置くと、resultの値が何であったかの確認もすぐにできるようになっています。

さらに、これをもっと簡単に実現しています。
先ほどと同じく⌘キー（またはCtrlキー）を押すと青いハイライトと緑色のハイライトが出てきました。「その行にジャンプできる」という意味では同じですが非同期処理であることを示しています。これをクリックすることで非同期処理の内側で処理を停止することが可能です。

Performance Panel

パフォーマンスを測定するときは、Profiles Panel、Timeline Panel、Network Panelの3つもしくは組み合わせで使っていると思います。このように、ツールが分散しているのが現状ですが、実際のところはJavaScriptのダウンロードが終ってからいつメインスレッドでの動作につながるか、

つまりブラウザのパフォーマンスを見たいはずです。動作と動作の接続されている箇所、例えばJavaScriptの実行完了後、ブラウザはレイアウトを計算し表示するのがいつなのか見られるのがとても重要。ですので、これらを1つのタイムラインで並列に並べて1度に見られるPerformance Panelを作りました。

Profile Panelを使ってJavaScriptの開発をしていた方は、Mainスレッドを広げることでどの時間に何が処理されているのか見ることが可能です。下のペインの”Bottom-Up”のタブが全ての処理でどれだけ時間がかかったかを表す”Self Time”の列でソートされて表示されます。

セッションではこの機能を実際にNestのホームページを使って紹介していますのでぜひご覧になってください。（Nestのホームページを使ったPerformance Panelの解説）

Coverage Profiler

最も速いコードは実は動いていないコード、またそれより速いのはダウンロードすらされていないコード。そこで、何が実際に操作しているのかを何とかして提供することはできないかと考えた。そして実装したのがCoverage Profilerです。

Coverage Panelはここから開きます（下図：左）。

CSSを見てみます（上図：右）。サイトで使われている部分は緑、使われていない部分は赤で表示される。赤はCSSもJavaScriptでも現在のページで使われていない部分なので、動作させることで青に、つまり動作した部分はリアルタイムに反映される。

ユーザにとっては赤色になるByteは不要なのでを送らないようにしましょうね。

3rd Party Attribution

Consoleで⌘キー（またはCtrlキー）+Shiftキー+pキーを押し、Show third party badgesと入力して、一度Enterをします（下図：右）。その後にNetwork Panel等を開くと、Networkリクエスト左側にバッジが表示されます。（下図：左）このバッジが 3rd Party Attribution です。このバッジ内の文字列は3rd Partyの名称のイニシャルです。例えば「GA」ならGoogle Analytics。

Consoleのエラー等の表示にもバッジが表示されるようになっているので、エラー、警告等のConsole出力がどこの誰のスクリプトに由来しているかをひと目で確認できるようになりました（下図：下）。また、Performance Panelのタイムラインでは3rd Partyはグループとしてまとめて表示されるようになっています（下図：上）。

Authoring

Cookie Edithing

Cookieの編集がDevToolsで可能になりました。

Change Tracking

DevTools上で変更した箇所をファイルごとにdiff（差分ファイル）として全ての変更を提供することが可能になりました。まだExperimentalです。（セッションでは月曜日、そらく5月22日の月曜日、って言ってるけどまだ使えないっぽい？）

Screenshot

モバイルデバイスのフレームも入れたスクリーンショットも撮れるようになりました。

さらにフルサイズのスクリーンショットも撮れるようになりました。撮り方は⌘キー+Shiftキー+pキーを入力し”Capture full size screenshot”と入力しEnter。（”Capture Screen Shot”はブラウザウインドウサイズの画像）

Breakpoint Resolving

Breakpointを置いて、例えばそれより若い行に変更を加えた場合、Breakpointは消えてしまっていましたが、DevToolsではBreakpointを置いた行番号が動く変更がされたとしても、出来る限り追従することが可能になりました。

大きな変更が入った場合は恐らく追従できません。Best Effortでの追従ですのでご了承ください。

Auditing

LightHouseはChrome Extention、コマンドライン、Node.jsのモジュールで提供されているwebページの質の向上を上げる、サイトのインサイトを見るためのツールです。私はこのプロジェクトにいます。 多くの形式で提供されていますが、DevToolsから実行はできませんでした。これがDevToolsに組み込まれたらとてもよいです。ということで実装しました。

DevToolsを開き、Audiotsのタブを表示します。すると、ここでLighthouseが実行できるようになっています。Nexus5Xをエミュレートして、ネットワークの速度、CPUの速度の調節して計測しています。ページのロードのパフォーマンス、その他にも多くの計測を行ったり、PWAのアプリとしてどうかという計測等を行って結果を出します。

DevToolsですので、Lighthouseで表示結果の中で、指摘された場所をダイレクトに示すことができる。LightHouseとDevToolsの連携したことでwebサイトのインサイトを見る強力なツールになっています。

セッションでは実際にChrome Experimentsを使ってデモをしていますのでぜひ御覧になってください。 （Chrome Experimentsのページを使ったDevToolsに統合されたLightHouseのデモ）

Headless Chrome

画面を表示しない（Headless）C hromeを使うことで、異なった複数のセッティングでの自動検査を行うツール等を作ることができる。例えば、テキスト抽出、スクリーンショット、PDF生成、リグレッションテスト、ユニットテスト、インテグレーションテスト、セキュリティテスト、サーバサイドでのレンダリングなどの検査です。

Chromeチームではそういったシナリオを実現させたかったので現在使えるようになっています。Linux、macOS、Windows（60で対応）で動作可能です。Seleniumへも対応中です。
現状は低レイヤーのAPIしかありませんが、今後高レイヤーのAPIも実装されます。

Eric BidelmanがHeadless Chromeについて書いたブログポスト（日本語版）がありますのでそちらもご確認ください。

Node.js

去年Node.jsもDevToolsでDebug、Profileを出来るようになりました。ブラウザとNode.jsに多くの時間を使うのでとてもよいことです。ここ2年で進化したNode.jsを、私がLightHouseのプロジェクトで行っているDebug方法で実際にお見せします。

セッションでの実際のデモへのリンクです。併せてご覧になると分かりやすいと思います。

デモ動画

以下のコマンドをTerminalから入力して始めますが重要なのは--inspect-brkの部分です。次に出力されるURLをコピーして表示することも可能ですが、よりよい方法があります。

$ node --inspect-brk lighthouse-cli --pref http://example.com;/

Chromeのアドレスバーにabout:inspectと入力して “Open decicated DevTols for Node” のリンクをクリックします。するとNode.jsにのみ接続されている専用のDevToolsのウィンドウが表示されます。もちろんこのウィンドウ内でもDevToolsの全ての機能が利用可能です。

このNode.js専用DevToolsを開くもう1つのよりよい方法です。
DevToolsを開いておき先ほどと同じコマンドを入力します。

そして、DevToolsを見るとInspect ElementのアイコンのとなりにNode.jsのアイコンが現れます。このアイコンをクリックすることで先ほどと同じNode.js専用DevToolsを表示することが可能です。このNode.js専用DevToolsの良いところは、Debugをして再起動したとしても、Node.js専用DevToolsを再起動する必要がないところ。

まとめ

たくさんの新しい機能を説明してきました。
Twitter、定期的に更新しているドキュメント、バグの報告＆フィードバック＆機能追加のリクエストを行うリンクは以下になります。

• Twitter: @ChromeDevTools
• Docs: devtools.chrome.com
• File bugs & give feedback: new.crbug.com

ありがとうございました！

おわりに

今回も開発者視点で欲しい機能がたくさん追加されました。ブラウザであるはずのChromeですが、DevToolsだけに注目すると「ブラウザっていうか、どちらかというと開発ツールだよね？」と思う（もちろん良い意味で）ことも少なくありません。今までに磨きをかけて更にwebの開発をまたスピードアップできるのではないでしょうか？

セッションの中でPaul Irishは「ユーザからの声が多かった◯◯の機能」「◯◯の開発の手順（ワークフロー）を考えるとこの機能は重要で…」というように常に開発者視点に立った上で機能の追加を行ってくださっていますので、

• こんなツールがDevToolsに欲しい
• こういった開発の手順を考えるとこの機能はDevToolsに欲しい

などをフィードバックすることで、もしかしたらその機能が本当に実装されるかもしれませんので、要望のある方はぜひ上記のURLよりフィードバック、バグ報告等を行ってください!

この記事は2017年5月17、18、19日に米国カリフォルニア州マウンテンビューにあるAmphitheatreで行われたGoogleの開発者向けカンファレンスGoogle I/Oの3日目に「The Future of Audio and Video on the Web」というタイトルのセッションの内容です。

はじめに

タイトルをパッと見て、例えばWeb Audioの話も絡むのか！？と思いきや、内容はビデオでしたが、2000年からwebのみならずリビングにあるテレビ（動画）から、YouTube、SNSでの動画も含めて歴史を追った説明、デモをまじえ動画を中心としたwebサイトの現在できる最高のExperience、そして見えかけている未来のwebでの動画の拡がり、とwebで動画という切り口から幅広く説明をした中身の濃いセッションでした。

登壇したのはこのお二方。Product ManagerのJohn Pallettと、Developer Programs EngineerのFrancois Beaufortです。

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

動画が机、リビングから手の上に乗り外に向けて歩き出す

2000年から10年はほとんど変わらなかった。 2000年は私(John Pallett)がHDのテレビを買った最初の年。この当時はHD動画を録画する機器すらなかったが、直後にHD録画機器も出始めSkypeも同じ頃に登場。2005年にYouTube、2007年にはAmazonのPrimeビデオ、Netflixがストリーミングサービスを開始。しかし、この頃は机、リビングで見るのが主でした。

2010年からは私の娘を軸に見ていきます。 2010年はタブレットが出始めた年。娘はこの頃から場所を選ばず受動的に動画、音楽を聞いたり、一方で能動的に録画、録音するようになっていました。

ちょうどその頃にはFaceTimeが登場し、ビデオチャットが気軽にできるようになり、2011年にはTwitchでゲーム動画の配信、2013年にはSnapchat、2014年にmusical.lyで若者が音楽ビデオを録り、さらにそれを友達同士で配信するようになった。さらに過去数年では、VR、AR、360度動画が出てきたりと、イノベーションがここ数年の動画の進化を加速。

この進化を裏付けるように、現在のインターネットのトラフィックの70%が映像（ビデオ）で、Cisco社は2020年までにこれが80%まで伸びるだろうと予測しています。

モバイルwebでの動画の過去と未来

先程挙げた、Twitch、Snapchat、musical.ly、これらのサイトに行くと実はアプリ（Android, iOS）のインストールを求められます。

しかし、モバイルwebでこれらのアプリを作ればアプリのインストールは不要、そしてすぐにやりたいことができるはずなのに、なぜそうなっていないのでしょう？少し奇妙です。

理由を考えると実はそれにはいくつかの問題、課題がありました。一言でいうと、モバイルwebは動画が得意ではなかったのです。その問題点を見ていきます。

Buffering

動画の提供側はFlashを第一に、第二にHTML5に向けて公開するという時代が続いていて、モバイルwebは眼中の外でした。なぜならモバイルwebで動画にアクセスすると動画のダウンロードに時間がかかり、再生までにかなりの時間がかかっていたからです。

映像のクオリティの低さ

「ダウンロードに時間がかかるのなら、映像のクオリティを落とし、ファイルサイズを小さくしよう！」となりますが、小さくすればするほど映像のクオリティは低下します。

いけてないレイアウト

動画の提供側はモバイルwebは眼中の外だったので、サイト全体のデザイン、レイアウトはデスクトップに最適化されていて、モバイルwebでは動画の一部しか表示されていなかったりした。しかし、この現象は防ぐためのAPIがなかったことが大きい要因で、対策はできなかったかもしれないというのも事実。

オフラインでは利用不可

オフラインでの利用はできなかった。もちろんChromeではOffline時には恐竜ゲームはできて楽しいけど、動画を観たいのに恐竜ゲームを例えば飛行機に乗って数時間するのは現実的ではありません。

では現在のモバイルwebでどうなっているかを紹介します。

デモアプリとしてDeveloper Relations TeamのPaul Lewisが書いたアプリを例に紹介します。アプリの名前は「Biograf」で、アプリとソースコードは以下のURLにあります。

• アプリ bit.ly/pwa-media
• ソースコード bit.ly/pwa-media-code-media

（セッションではここで実際にデモを行います。併せてご覧になると分かりやすいと思います。デモの動画）

（クリックでデモ部分の動画が再生可能です）

特徴は以下です。これはwebアプリですよ！

• Progressive Web App
• Nativeアプリのようにホーム画面からアイコンをタップして起動可能
• 起動アニメーション（Splash）が表示できる
• Chrome（ブラウザ）の枠はなく、全画面でアプリ全体を表示
• スクロールも非常にスムース
• 動画は再生をタップしてから一瞬で開始
• デバイスを横にするとフルスクリーンでも動画の表示が可能
• タイムラインをスクロールすると、サムネイルも表示可能
• フルスクリーン中にタップすると、「再生、停止、コマ送り・戻し」のコントロール画面が表示可能
• 通知エリアにもコントロールを表示することが可能
• 動画のダウンロード機能もあり、ダウンロードした動画はプラウザを閉じても、機内モードでも再生可能（Background Fetch）
• ロック画面からのコントロールも可能
• ロック画面で動画のサムネイルを背景としても表示可能
• 制限付き動画でもライセンスをハンドルして再生可能

これらのExperienceは動画の再生時「ページのロードが遅いとユーザはサイトから離脱してしまう」事実を元に考えると非常に重要な機能でもあります。Akamai社の調査では2秒で表示されないとサイトからの離脱が始まり、また動画の再生に関しては6秒以内に再生されないとユーザは再生開始を待たず離脱してしまうという調査結果を出しています。

では、このアプリを例にExperienceを1つ1つ見ていきましょう。

反応の速い再生(Fast Playback)

これはAdaptive Bitrate Streamingで実現しています。動画を再生するには動画のダウンロードは必須だが、モバイル環境下ではダウンロードするデバイスがトンネルを通ったり、帯域を失ったりする。Adaptive Bitrate Streamingがこれらのネットワークがコンスタントでない部分を解決します。

再生するビデオは複数のBitrateでエンコードして、それらがさらにある時間間隔で断片化して保存する。断片化されたファイルをダウンロードするアプリ側で低域等の状況に合わせてBitrateと断片の組み合わせの最適化を施すことで、反応の速い再生を可能にします。

これを実装したのがOpen SourceのShaka Playerです。

また、再生ボタンをクリック/タップしてからの再生の反応に関しては、Service Workersで動画をPre-Cacheすることで速くしている。これが実装されているのがTHEOPlayerです。Biografにも実装されているが、動画の説明等も一緒に、事前にキャッシュ（Pre-Cache）することで再生までの時間を短縮している。またService Workersを使うとサイト自体のスピードもアップすることが可能です。

VIACOM18のVootという動画サイト（5月25日現在、インドでの提供のみ）ではページロード時間が5倍速くなり、これによってユーザがが77%増加、日々に動画を再生するユーザは15％増加したという結果もあります。

Offline

Offlilneは例えば飛行機に乗っている時など、インターネットアクセスがない場所では非常に重要な機能。BiografではService Workersを使って、ページに表示する動画の説明、また動画に関してはリーズナブルなBitrateで事前にダウンロードしキャッシュとしてブラウザ側に保存することでどこでも再生できるようにしています。このBitrateは開発者側からService Workersのロジックの中で、またはユーザ側が例えばダウンロード開始時に選択することが可能。

Offlineはオーディオにも適応可能です。例えばオーディオブックを考えると、Service Workersを使って事前にブック内のプレイリストのオーディオを事前にキャッシュしておくことで、Offlineでも再生が可能になる。

Biografでは動画をキャッシュするためにBackground FetchというAPIを使っていますが、この機能は現在開発中でExperimental Web Platform features（Chromeのアドレスバーにchrome://flags/#enable-experimental-web-platform-featuresを入力すると変更可能です）をEnableにすることで利用が可能になります。このAPIに関するフィードバックをお待ちしています。

VP9

コーデックに関してです。クオリティを落とさずに2倍のコンテンツを保存できたらよいですよね。VP9は一般的なコーデックに比べると50％程圧縮率が高いので、質を落とさずにファイルサイズを50％減らすことができます。既に20億のデバイスがサポートされている状態なのでとてもよい選択肢。例えばYouTubeではVP9を使うことで他のコーデックで配信したときよりも再生までの時間を15〜80％縮めることができています。

User Experience

Media Session API

ロック画面、通知エリアでサムネイルをバックグラウンドに表示していたのと、コントロールボタンを表示していたのがこのAPI。ウェアラブル側にも表示されます。

実装は簡単でMetadataとしてタイトル、アーティスト、アルバム名、表示する画像を指定をし、コントロール（再生、ストップ等）のボタンが押された時のHandlerをそれぞれ書くことで実装が可能です。

Session Orientation API

デバイスを回転させたときの動作を指定できるAPI。Biografでは横にした場合に全画面表示にしている。縦、横になった場合のHandlerを書くことで実装が可能。

webでの動画の未来

タイトル通りの未来のお話をします。映像周辺の仕様の進化はディスプレイをよりリアルな表現の表示に近づけてくれます。

Wide Color Gamut

まずは色からお話します。現在のテレビ（4Kや8K）で実現されている色がモバイル、デスクトップのwebで表現できるようになります。

現在のディスプレイで表現できている色は目で見えているよりも色の表現は乏しい。その色は存在する色が外側の枠だとすると、最も内側にある三角枠が現在のディスプレイ（SRGB）の守備範囲。これがBT2020になると真ん中の三角枠まで表現できるようになります。

僕の履いている靴、実はこのディスプレイ（登壇者の背面にある）では正しい色で表示されていない。けども4K、8Kではより近い色が出てるはず。
（独り言：もしや登壇者のJohn Pallettさん、このために靴を新調したのかな？）

High Dynamic Range (Brightness)

いままでよりも明るいものは明るく、暗いものは暗く表示できるようになる仕様です。現在の一般的なディスプレイではSDR（Standard Dynamic Range）しか表現できません。これは現実の世界の明るさからするとかなりの差があります。

HDR(High Dynamic Range)をサポートしたディスプレイがこれから市場に出てきます。これはOTF（electric Optical Function、またはガンマFunctionともいう）を変えます。デジタルの数字からディスプレイでどれだけの明るさで表示するかのFunctionのことで、それが変更されるので映像・画像を扱う方はどのディスプレイが何をサポートしているか、またそのディスプレイの特性を知った上で選択する必要が出てくるということです。

Wide Color GamutとHigh Dynamic Rangeのコードは以下です。上部についてです。CSS Media Query Level4で可能になります。現在のChromeではcolor-gamutがサポートされていますが、デバイスでどの色が使えるかをクエリすることが可能で、それによって決定することが可能です。

また下部のコードではVP9がHDRとOTFでどの色で表示できるかをクエリによって決定することができます。

Alliance for Open Media(AOM)

アライアンスです。このアライアンスはYouTube、Google、Amazon、Twitch、Netflix、Microsoft、Mozilla、Hulu、BBCが参加していて、Open SourceでRoyalty-Freeの新しいCodecを作ろうとしています。

HDRだけでなく、Wide Color Gamut、また8K、4K、360どビデオも低いBitrateでも届けることができるようなCodecを考えています。なぜなら世界で皆が同じレベルのネットワークを使えるわけではないから。

このアライアンスではAV1という名前のCodecを開発している。数週間前はまだ開発も終えていないし、使えるフォーマットではなかったが、NetflixがVP9よりも20％高い圧縮率のフォーマットを実現することができたとの報告を受けている。

恐らく疑問に思うのは「AV1がどれだけのデバイスでサポートされているのか？」というところだと思います。ここがwebのユニークで面白いところ。1GHzと3GHzのデバイスでは再生のされ方が違う。ではそこをどうするか、VP9を例にコードを見てみます。Media Capabilities APIを使うことで以下のようにいろいろな値を指定することが可能です。

APIにResolution、Bitrate、再生したいCodecを渡すと、指定した形式をサポートしているか、指定した形式でスムースにつまらずに再生できるか、バッテリパワー的に効率的かを返してくれるので、この情報をどのタイプで再生するかのみならず、どのResolutionで再生するか等、ユーザに最適なExperienceを提供することができるようになる。

録音・録画とシェアとSNS

ここ数年、映像とオーディオに関してここ数年で飛躍的に前進している。私の娘がモバイルで音楽の制作、映像の撮影をしている。顔に飾り物をディスプレイ上でつけたりカスタマイズして、そのまま友達とSNSでシェアしてる。これは5、6年前では考えられなかったことです。SNSでは即座に撮影してシェアすることがキーになります。これはwebにはとても得意ところ。なので、ここでSNSやコミィニケーションについて話をします。

WebRTCはあたらしい技術ではないが、ここ数年で急速にブラウザベンダとアプリケーションプラットフォームとしての両方に適応されてきました。そしてWebRTCを使えばLiveStreamingもすることが可能です。

そしてユーザがシェアする動画・音楽の制作に関して、簡単に探せて、簡単に見ることができ、さらにそれを見た友達が動画・音楽の制作ができ…となれば、とてもよいサイクルが生まれます。

このサイクルの実現はwebでなら難しくはありません。それではこのサイクルがwebで実現できるかどうかを、デモを交えてフランソワから紹介してもらいます。

Mustache（髭）

映像とシェアに関わる部分で現在のwebでできることを盛り込んだデモをご紹介します。アプリは「Mustache」という名前です。

Progressive Web Appになっています。ホーム画面のアイコンから起動すると、起動アニメーション（Splash）が表示されます。このExperienceですと、既にwebアプリだと認識するのが難しいと思います。顔には髭、頭には帽子をかぶっています。動かしても映像はとてもスムーズです。動画の撮影も可能で、それをシェアすることももちろん可能です（上の画像の右側）。

Mustacheが利用しているAPI

映像を扱う(getUserMedia())

カメラを扱い、画面に表示するコードが以下になります。

getUserMeida()でカメラの映像と音声を取得します。Mustacheの場合は映像のみを利用します。その他の条件として利用するカメラ（前面、背面）、Framerate、サイズをしています。そして下部のコードで取得した映像を画面に表示しています。

形状の検知（Shape Detection API）

現在、実験中のAPIであるShape Detection APIを使っています。動いている顔へ髭、そして頭に帽子をと、このAPIが重ねる正しい場所を検知することを可能にしています。つい先週完成したばかりのAPIです。

コードは以下のようになります。とてもシンプルです。FaceDetector()に顔を取得するか、また、顔を最大いくつ検知するかの数を指定するだけです。ブラウザ側のAPIなのでインターネットへの接続は不要です。

このShape Detection APIはBarcode、QR Codeを検知するAPIと同時に9月にはChrome安定版でテスト利用という目的で利用可能になります。また、現在でも「Experimental Web Platform features」をEnableにすることで利用可能です。もし要望、バグがあったら知らせてください。

映像の録画（Media Recording API）

Mustacheでは、以下のようにMedia Recording APIを使っています。MediaRecorder()へCodecをVP9と指定して、映像を受け取ったら処理をするHandler、また録画を停止した時のHandlerを書いている。Chromeに公開されて1年になるのでAPIは安定しています。

シェア機能（Web Share API）

シェアボタンを押したときにAndroidのNativeのシェア選択画面が出てきていましたよね。自然過ぎてわからなかったかもしれませんが…。これはWeb Share APIを使っています。
コードは以下です。share()にタイトル、テキストと映像のURLを指定します。このAPIは今年末には利用できるようになるでしょう。

Mustacheは以下のURLで公開しています。
Chrome for AndroidのCanaryを使い、Experimental Web Platform featuresのEnableにして利用してください。

• Mustache

全てのAPIを1つのノードとしてみるとwebではPlug-inなしでこれらノード同士を無限につなげることができます。例えば、Media Streamを使えばカメラからCanvasに描画、アップロード、またマイクからWeb Audioそして、WebRTCのRTCPeerConnectionへと、たくさんのAPIと接続して利用することが可能です。

まとめ

デモに交えてたくさんのAPIを話しました。多くが現在でも利用可能なAPIです。

Biografでは、Service Workers、Media Session API、Full Screen API、Screen Orientation APIなどを使っています。フランソワがこちらに記事としてまとめてくれていますので詳しくはそちらを参照してください。

映像の再生等に関わるProgressive Web Appを書く場合はBiografのコードを参考にするとよりよいExperienceを提供できるでしょう。
そしてMustacheで使っているMediaStream Recording API、Media Capture API、Media Streams APIは現在でも利用可能です。

最後に、以下の3つは特にFeedbackをお待ちしています。

• Background Fetch
• Shape Detection API
• Web Share API

ありがとうございました！

おわりに

個人的に数年前から年に数回はFacebookをモバイルwebから使う儀式をしています。写真や動画を撮ってシェアしたりするのが特にですが不自由な点がありました。

また、QRコードの読み取りも必ずモバイルのNativeアプリ、またはインターネットへの接続が必須とされていました。それを元に考えると近年のWebブラウザの進化には目を見張るところがあり、また同時にその進化を肌で実感できるエキサイティングなプラットフォームの1つだと思います。

今後も映像のみならず、他の分野でのWebブラウザの発展、拡張も期待できそうですし、その進化から目が離せないですね。

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/ にさらなる情報がありますので、お時間がありましたらご覧ください。

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

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

今現在Webで起こっていること

Progressive Web App (goo.gl/WR7yJ3)

Service Worker、Add to Home Screen、App Manifest、Background Sync等を使い、NativeアプリのようなUXを提供するWebアプリを指す言葉です。 Chris氏いわく、23年間Webをやってきているけど、やっと理想だと思っていた世界、ユーザーとのエンゲージ率が高いUXを持つサイトがWebというPlatformのみで制作することが可能になっている。（作り方等の詳細はこちら「The Mobile Web: State of the Union」でとのこと）

けど、ここで話すのは既に利用可能なCutting Edgeな話ではなくて、「New Shiny」と呼んでるWeb PlatformのBleeding Edgeな話をします。なので、まだリリースされていない機能だったりCross-Browser、Cross-Deviceで動かない機能、Experimentalフラグの変更を必要とする機能も含まれます。

ただここではカバーしない機能もあり、その代表的なものの一覧はこちらです。

New Shiny（Bleeding Edge）

開発をより簡単に速くするための機能(導入済み)

Promise

非同期のAPIの記述を一貫性のあるパターンで書く方法です。Callbackのように混乱しやすかったり、散らかりやすくなく、同期APIをブロックすることもなくなります。Web開発はブロッキングをなくすようなデザインをするように考え方を変える必要があります。なのでPromiseは新たなWebのAPIをデザインするときには一般的な方法になっていて、以下はPromiseを使うAPIとしてデザインされている代表的なものです。

• HTMLMediaElement.play()：Promiseに書き換えられました
• Web Bluetooth
• Web USB
• Web MIDI

[実装状況]

Fetch

FetchもPromiseを使っています。FetchはXMLHTTPRequest(XHR)と似ていてNetworkリクエストを行います。XHRとの違いはPromiseを使って可読性が上がっているところ。Fetchで何をしているか分からなくても、見たら何となく内容を理解できるところです。Callback地獄からの脱却、XHRの複雑な部分から開放してくれる。例えば、直接JSONや他のデータ・タイプを扱うことも可能です。

左がFetch、右がXHR。パッと見、XHRとも悪くないけど、Stateのチェックとかしてないから悪くないのであって、本来はもっと長くゴチャゴチャするのでご注意してください。

そしてES6のアロー・ファンクションを使うと、さらにこんなにもキレイになります。

ただ、さらなるチャレンジ。問題はこのままだとデータを完全に取得してからでないとJSONとしてParseができないところ。つまりAtomicで割り込みができない。そこで実装中なのが、このFetchやその他のAPIの本当の能力を引き出す機能、それがStreamです。
[実装状況]

Stream

Streamは基本的な要素で、その使い道はいろいろあると思います。Jakeはこんなことを言ってます。「Streamは2016年の大きな1つの機能になるだろう」と。なぜならStreamはProgressiveなデータ転送を可能にするからです。全てのデータを受け取っていない状態でも、受け取った順に処理することができる。つまり、Progressiveなレンダリングだったり処理が可能になるのです。App Shellアーキテクチャを使う場合等は1度に複数の場所からデータを取得するので、とても重要な要素になります。

画像は左側の「Fetch」の全てが終わらないと真ん中の「Process」に進めない、それに引きづられて最終的な「Render」も遅くなってしまう、を表した図。

Jakeが作成したOffline Wikipediaのサイトで、Streamを使うとどれくらい差がでるかを比較したデモ動画です。左からServer Render、Service Worker Client Render、Service Worker Client+Hacks Render、一番右がStreamを使ったService　Worker Client Renerです。（画像が小さくてすみません。セッションでのビデオ再生はココから見られます）

初期のレンダリングは一番左のServer Renderが他よりも8倍くらい遅い、しかしレンダリング完了までだとnon Streamの真ん中の2つよりも速い。この理由は、真ん中の2つは全てのデータを取得するのを待ち、それから処理を始め、その後最終的にレンダリングされるからです。せっかくのハイパフォーマンスなProgressiveなWebアプリなサイトであるのに、表示が遅くては致命的とも言えるでしょう。実際に、現況ではApp Shellアーキテクチャのがコストが高い（時間がかかる）場合もあります。
[実装状況]

さらにパフォーマンスをテーマに話を続けます。ハイパフォーマンスなWebサイトを作るために実装しているエキサイティングなその他の機能を紹介します。

RequestIdleCallback

多くのWebアプリ、サイト上では多くのスクリプトが動いていることと思います。しかし全てのスクリプトがユーザーが見ている画面に直接関係のあるスクリプトではなかったりしますよね。例えば、Analyticsデータの送信です。スクロール中に動いてしまうとスクロールがロックしたりユーザー体験（UX）の質は下がります。そこで、そういったユーザーが見ている画面に直接影響を及ぼさない処理を空いている時間に走らせよう、という機能がRequestIdleCallbackです。

RequestAnimationFrameはできるだけ60fpsで表示ができるようその処理をスケジュールしています。そして、RequestIdleCallbackはRequestAnimationFrameと一緒に動作しています。レンダリングに関係しない処理を、レンダリング処理が空いているところにスケジュールしてくれる、という動きです。

実装は難しくないけど、ここで動かしたいタスク（処理）の1つ1つはリーズナブルな時間で終わるように分割されている必要があります。時間がかかるタスクは今まで通りWeb Workerで動作させることをおすすめします。ちなみにNetflex、Facebookはこの機能を既に導入しています。
[実装状況]

PassiveEventListener

新しいDOMの機能でChrome 51でShipされます(I/O後の2026年5月下旬にリリースされました)が、ユーザーによりよいスクロール機能を提供するための機能です。導入はすごく簡単。

スムーズなスクロールの機能はWebにとって、特にタッチデバイスでのWebにとってはとても重要です。モダンなブラウザは高コストなJavaScriptがUIスレッドで走っていたとしても、スクロールを別スレッドでハンドリングする機能を持っています。

なのですが、問題はそれがタッチやスクロールeventハンドラを持っていると、最適化で負けてしまうところです。なぜならそれらのハンドラは.preventDefaultをCallすることでスクロールを完全にブロックしてしまうからです。eventハンドリング中に.preventDefaultがCallされるかどうかは分からないので、高コストなJavaScriptの処理が完了するまで待つ必要が出てきてしまうのです。

そこでPassiveEventListenerでは、.preventDefaultをCallしないと宣言し、スクロールがeventによってブロックされないようにするのです。

Chrome for Androidではその80%のTouchEventがブロックされる必要はないのにブロックされている。その10％がスクロール開始までに最低100ms待ち時間が生じた。さらに、その1％は500msの待ち時間がスクロール開始までに生じている。

CNNのサイトで導入したのと、していないのとで比較をしてみます。（ビデオはこちらから：preventdefaultをcallしてないのに遅くなっているのとPassiveEventListenerを使った場合の比較ビデオ）

この違いを生むための実装は、たったこれだけです。

[実装状況]

Intersection Observer

特定のDOM Elementが画面内に入っているかどうかを見る、またその場所も簡単に得ることができるのがこのAPI。今までも実装は可能だったけど、効率的ではなかったし問題もいろいろあった。では、Intersection Observerのコードを見てみましょう。

画面内に入ったかを監視したいターゲットとなるElementを決めましょう。そしてIntersectionObserverのオブジェクトの生成時します。生成時には画面内に入った場合の動作についてのCallbackも渡します。最後に生成したオブジェクトでどのElementを監視するかを指定します。（デモページ：goo.gl/mNdYRv、Chrome 51以降で御覧ください）

デモページはとてもスムーズで超速な無限のスクロールを提供しています。コンテンツ表示はネットワークの遅さをシュミレートしているかのように遅れていますが、Service Workerを使ってキャッシュすると解決します。例えば、たくさんの画像を表示するページ等には持ってこいですね。
[実装状況]

<link rel=”preload”>

Chrome 50でShip済みで、リソースのPreload（事前読み込み）を行います。遷移先のページを事前取得する<link rel=”prefetch”>とは違い、現在のページ内のリソースを読み込む優先順位を指定ができる属性です。
[実装状況]

HTTP Clients Hints

HTTPヘッダにつけることで取得するコンテンツの種類を事前ネゴシエーションすることができる。ネゴシエーションの要求を出すことで、ユーザーのデバイス、環境によってサーバ側が提供されるコンテンツを差替えてServeすることが可能です。サーバ側に実装されるものであって、クライアント側のコードで指定するものではありませんが、以下の様な要求ができるように用意されています。

• DevicePixelRatio(DPR)
• Preferred widt
• viewport-width
• save-data: サーバにデータ転送を節約していることを知らせることができる

Canvas.toBlob

Chrome 50でShip済みで、クライアント側でCanvasをそのままBlobにすることができます。一説によるとこの機能が実現するまでに6年かかったそうです。.toDataURL()から得られるBase64の文字列を操作することなく、画像としてそのままサーバにアップロードしたり、IndexDBに保存したりできるので、より簡単に再利用することが可能になります。
[実装状況]

ImageBitmap

Chrome50でShip済みで、ImageBlobを他のCanvasにそのまま描くことも可能になっています。Canvasに描くために画像をデコードするのはとても一般的ですが、画像のデコードにCPUリソースをとても多く使ってしまうという問題点があります。しかし、Base64とデータの間での処理をすることなく扱えるようになったのです。そうすることで、例えば他の画像、エレメント、ビデオ等をCanvasに描くときと同じように扱えるようになりました。
[実装状況]

Unified Media Pipeline

クライアントではなくてChrome自体のコードの話です。デスクトップ版でもモバイル版でも全く同じ処理がされるようなMediaようにPipelineを持つようにしました。Chrome for AndroidにおいてもOSが持つAndroid Media Stackでの処理は行わないようにしました。これによりCross-Platformでも一貫した処理（例えばキャッシュ、エンコード、デコード）を行うようになっています。よって、Cross-Platformでのデバッグをより簡単にしています。

MediaRecorder

ビデオ、オーディオをキャプチャするだけでなく、エンコードして保存をすることが可能になりました。例えば、取得したオーディオをMP3にクライアント側で変換してサーバにアップロードすることが可能です。 （デモページ：simpl.info/mediarecorder、Chrome 49以降でご覧ください）

コードはこんな感じです。MediaRecorderのオブジェクトをOptionを渡して作成して、データを取得したときのCallbackを.ondataavailableに指定します。Callbackにはどう扱うかを書くのだけど、ほとんどの場合取得したデータ（Blob）をくっつけるだけです。そして、最後にどれだけの長さの動画を作るかを指定して完了です。サーバにアップロードする、ローカルに保存する等ができるようになります。Web Audioでの質問として何度か受けていますが、まさにこれがその解です。
[実装状況]

Media Session

Mediaの動作を操作のカスタマイズ、例えばラップトップのオーディオように用意されたキーを特定の機能に割り当てることができたり、モバイルでは通知エリア(Notification Area)、ロック画面にMedia操作用のUIを出すことができるAPI。もしMediaに関するアプリを作っている開発者であれば一度見てもらいたい。
[実装状況]

CSS Variables

正確にはCSS Custom Propertyとも言いますがChrome 49でShipされています。例えば、同じ属性を何度も繰り返し書くことの削減してくれたり、また色・見た目等のテーマの変更にもとても有効です。
[実装状況]

CSS Containment

CSSを隔離してパフォーマンスを最適化してくれる機能です。例えば、3rd Partyのウィジットを使った場合、そのウィジットのCSSを隔離することで自サイトのパフォーマンスに影響が出ないように最適化してくれます。
[実装状況]

CSS Font Loading API

最初に実装されたのはChrome 35でそこそこ前なんですが、Font LoadingのInterfaceはChrome 48でShipされたばかりです。1つ1つのFont Faceのチェック、またそれらのダウンロード状況を確認できるようになりました。これによりFontが実際にどれくらいダウンロードされたか、どんなFontであるかを知ることができるようになりました。
[実装状況]

Progressiveに速いスピードで短い説明で新しい機能を紹介しまくって、後で調べてね、と言っている感があるように聞こえるかもしれないですので、少し休憩というようなお話をしますね。

（後編の予告など）
ということで、この辺りで前編は終了です。後編はWeb Platformをより先に進めるためにここ1～2年Chromeチームが取り組んでいるアプローチ、Chris氏の大好きなアレ、そしてWeb Bluetoothについてお伝えします。

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をよろしくお願いします！

この記事は、Web MIDI APIを題材にした連載の第二回目です。（第一回目はこちら）

第一回目はWeb MIDI APIでMIDI Inputデバイス、Outputデバイスを列挙し、利用する実装方法を説明してきましたが、詳細の実装の説明までできていませんでした。第二回ではx-webmidiというPolymer Elementを使い、第一回で実装した部分、また実装ができていなかったHotplugを含めて、お手軽に実装してしまう方法をご説明します。

前回に引き続き、今回もMIDIデバイスの準備は不要な内容になっていますので、最後までお試しいただけると嬉しいです。

Polymerとは？

「Web Componentsを簡単・便利にするライブラリ」です。Polymerを使うと簡単にWeb ComponentsのElementを作成することが可能です。本サイトHTML5Expert.jpでも連載記事がありますので、ぜひご覧ください。

• 基礎からわかる Web Components 徹底解説

そして今回は、Web MIDI APIをPolymer Element化したx-webmidiを使って、以下の2つのアプリの実装をしていきます。

1. InputからOutputにMIDIメッセージを中継するアプリ
2. SMF（Standard MIDI File）を再生するアプリ

x-webmidiとは？

Web MIDI APIは、外部のMIDIデバイスとUSB-MIDIで接続するAPIです。API自体には「デバイスをリストする」、「デバイスへMIDIメッセージを送信する」、「デバイスからのMIDIメッセージを受信を行う」、また、接続に関しては「Hotplug」が、それぞれサポートされています。

しかし、これらを実装するのは少し手間がかかります。自分自身の体験としては、複数アプリケーションを書いていると「アイデアをアプリケーションに落としこむ時、MIDIデバイスの制御の部分に労力をかけるのは極力抑えたい」と思うようになりました。そこで考えついたのが、Polymerを使って基本的な操作はElementにしてしまう方法です。そして生まれたのが「x-webmidi 」です。

さっそく実装してみよう

環境整備

連載第一回目の環境整備と同じです。ここでは手短に説明します。
Polymer本体、今回利用するx-webmidiをそれぞれダウンロードします。

• Polymer
• x-webmidi

開発するディレクトリを作成して、ダウンロードした2つのファイルを解凍し、以下の構成になるように配置してください。その後、同一ディレクトリにindex.htmlを作成します。

以上で環境整備は完了です。

では、実際に実際に開発を行っていきましょう。

InputからOutputにMIDIメッセージを中継するアプリ

作成する index.html のコード全体はこちらになります。それでは順に説明していきます。

<script src="bower_components/webcomponentsjs/webcomponents.js"></script>
<link rel="import" href="bower_components/x-webmidi/x-webmidirequestaccess.html">
<link rel="import" href="bower_components/x-webmidi/extras/wm-webmidilink/wm-webmidilink.html">
<link rel="import" href="bower_components/x-webmidi/extras/wm-pckeyboard/wm-pckeyboard.html">
<x-webmidirequestaccess input output></x-webmidirequestaccess>

<wm-webmidilink id="wmlink"></wm-webmidilink>
<wm-pckeyboard id="pckeyboard"></wm-pckeyboard>

• 1行目：Web ComponentsのPolyfillを読み込み
• 2〜4行目：Web MIDI API（x-webmidi）、仮想MIDI Outputデバイス(wm-webmidilink)、仮想のInputデバイス(wm-pckeyboard)のPolymer ElementをImport
• 5行目：x-webmidiをアクティベート

x-webmidiの属性は以下の通りです。

• input： MIDI Inputデバイスを利用する場合に追加
• output： MIDI Outputデバイスを利用する場合に追加
• sysex： System Exclusive メッセージを使う場合に追加

今回、System Exclusive メッセージは使わないので、inputとoutputのみを記述します。

• 7行目：wm-webmidilinkをアクティベート
• 8行目：wm-pckeyboardをアクティベート

以上で準備は完了です。次にMIDIデバイスのリスト表示を行います。

input: <x-webmidiinput id="midi-input" additionalid="pckeyboard" autoselect="PC-Keyboard" autoreselect></x-webmidiinput><br>
output: <x-webmidioutput id="midi-output" additionalid="wmlink" autoselect="GMPlayer(WebMIDILink)" autoreselect></x-webmidioutput>
<br>

x-webmidiinputとx-webmidioutputの属性は以下の通りです。

• additionalid： 仮想のデバイスを追加する場合、そのタグのIDで指定します
• autoselect ： 自動選択して欲しMIDIデバイス名を指定します
• autoreselect ： 現在指定しているデバイスが切断され再接続した場合に自動選択します

今回は仮想のデバイスを追加するため、属性 additionalid に、input側はpckeyboard(wm-pckeyboardタグのID名)、output側はwmlink(wm-webmidilinkタグのID名)をそれぞれ指定しています。最後に入力されたMIDIメッセージを表示する場所を作ります。

<div id="msg" style="margin:30px;"></div>

Inputから受け取ったMIDIメッセージを中継するためのJavaScriptを記述していきます。

var output=document.getElementById("midi-output");
    window.addEventListener("midiin-event:midi-input", function(event){
        for(var i=0, out=[]; i<event.detail.data.length; i++) out.push(("00"+event.detail.data[i].toString(16)).substr(-2));
        var div_msg=document.getElementById("msg");
        var ex_msg=div_msg.innerHTML.split("<br>");
        while(ex_msg.length>19) ex_msg.pop();
        div_msg.innerHTML=out.join(" ")+"<br>" + ex_msg.join("<br>");
        if(output.checkOutputIdx()!="false") {
            output.sendRawMessage(event.detail.data);
        }
    });

• 1行目：MIDI OutputのObjectを取得
• 2行目：MIDI InputからのメッセージはEventとして飛んできますので、EventListenerをつける。Event名は”midiin-event:”に続き x-webmidiinput タグで指定したIDになる。MIDI Inputデバイスから入力したMIDIメッセージは event.detail.data。
• 3行目：「MIDIメッセージを表示する場所」に表示して、分かりやすいように16進数の文字列にキャスト
• 4行目：「MIDIメッセージを表示する場所」のElementを取得
• 5, 6行目：「MIDIメッセージを表示する場所」の表示を新しいメッセージから順に並べるのと同時に表示する行数を絞る
• 7行目：MIDIメッセージを「MIDIメッセージを表示する場所」に表示
• 8〜10行目：Outputデバイスが選択されていたら、選択されているデバイスに対してInputから入力されたMIDIメッセージを送信。

これで、InputからOutputにMIDIメッセージを中継することができました。

SMF（Standard MIDI File）を再生するアプリ

次にMIDIというと必ず出てくるであろうSMF（Standard MIDI File）の再生です。

SMFはMIDIメッセージ1つ1つに時間情報を付加して、規定のフォーマットにまとめたバイナリファイルです。ここで付加された時間通りにMIDIメッセージを音源モジュールに送ることで、自動演奏ができる仕組みになっています。

SMFをWebブラウザ上で再生するには、SMFのバイナリを読み解いて（パース）、付加されている時間通りにMIDIメッセージを音源モジュールに送信する、という手順になります。しかし、このバイナリファイルをパースするためにはSMFのフォーマットを勉強しないといけません。この問題を解決するべく、SMFのバイナリをパースする部分を、「wm-smfplayer」というPolymerのElementにしてみました。このElemetでSMFを再生するアプリを作ってみます。

作成する index.html のコード全体はこちらになります。それでは順に説明していきます。

<script src="bower_components/webcomponentsjs/webcomponents.js"></script>
<link rel="import" href="bower_components/x-webmidi/x-webmidirequestaccess.html">
<link rel="import" href="bower_components/x-webmidi/extras/wm-webmidilink/wm-webmidilink.html">
<link rel="import" href="bower_components/x-webmidi/extras/wm-smfplayer/wm-smfplayer.html">
<x-webmidirequestaccess input output sysex></x-webmidirequestaccess>

• 1〜3行目：「InputからOutputにMIDIメッセージを中継するアプリ」と同じ
• 4行目：SMFをパースするElementを読み込む。SMFの中にはSystem Exclusiveが入っている場合があるので属性を書いています。

<wm-webmidilink id="wmlink"></wm-webmidilink>
<wm-smfplayer id="smfplayer" midifile="contents/ys2_op_gm.mid" latency="1200"></wm-smfplayer>

続いて、wm-webmidilinkタグを記述して仮想のOutputデバイスをアクティベートし、SFMをパースする wm-smfplayer タグを記述しています。wm-smfplayerの属性は以下の通りです。

• midifile： SMFのURL（パス）
• latency ： MIDIメッセージをバッファする時間

Latencyを指定してMIDIメッセージをバッファリングすることで、より時間に正確な再生が可能になります。
次に、MIDI Outputデバイスのリスト表示、SMFの再生制御のためのボタンを追加します。

output: <x-webmidioutput id="midi-output" additionalid="wmlink" autoselect="GMPlayer(WebMIDILink)" autoreselect></x-webmidioutput>
<br>

<button id="startPlay" disabled>Start</button>
<button id="stopPlay" disabled>Stop</button> <br>
<button id="allSoundOff" disabled>All Sound Off</button>

最後に、SMF再生中に取得したMIDIメッセージを、選択されたMIDI Outputデバイスに送信するためのJavaScriptを記述していきます。

var out_elem=document.getElementById("midi-output")
var output=null;
out_elem.addEventListener("midioutput-updated:midi-output", function(event){
    output=out_elem.getOutputDevice();
    document.getElementById("startPlay").removeAttribute("disabled");
    document.getElementById("stopPlay").removeAttribute("disabled");
    document.getElementById("allSoundOff").removeAttribute("disabled");
}, false);
var smfPlayer=document.getElementById("smfplayer");
document.getElementById("startPlay").addEventListener("mousedown", function(){
    if(output!=null) smfPlayer.startPlay(output);
});
document.getElementById("stopPlay").addEventListener("mousedown", function(){
    smfPlayer.stopPlay();
});
document.getElementById("allSoundOff").addEventListener("mousedown", function(){
    var output=document.getElementById("midi-output").getOutputDevice();
    smfPlayer.allSoundOff();
});

各行での処理の内容は以下の通りです。

• 1行目：MIDI OutputのElementのObjectを取得
• 2行目：変数outputの初期化
• 3〜8行目：MIDI Outputがユーザに選択したObjectの取得、再生制御のボタンの有効化
• 9行目：wm-smfplaymerのElementのObjectを取得
• 10-19行目：それぞれの再生制御ボタンが押された時の動作

以上で、実装完了です。

おわりに

今回はWeb MIDI APIをPolymerのElementにしたx-webmidiを使用して、2つのアプリケーションを作りました。そして、第一回目と比べるとコードの量が減るとともに、その多くがJavaScriptによる手続き型の実装ではなく、HTMLによる宣言型の実装になりました。宣言型で書くことで見通しがよく、手軽に実装できるようになります。

ここで「手軽になった」ということは、「アイデアを具現化するまでの道のりが短くなった」ということを示していて、実際に開発を行う際は、考えついたアイデアの実現のみに集中してすることができるようになります。

次回は、MIDIはMusical Instrument Digital Interfaceの略称ではありますが、文字通りの音楽という枠を超えて別の分野でも利用可能、という実例をご紹介しようと思います。

お楽しみに！

この記事は、Web MIDI APIを題材にした連載の第一回目です。

Web MIDI APIはWebブラウザのAPIですが、Webブラウザの中で完結はしません。Webブラウザと外部のMIDIデバイスとの間でMIDIによる通信を行うためのAPIなのです。Webブラウザと外部デバイスとのやりとりでというとGamepad APIを想像される方もいらっしゃると思いますが、Gamepad APIはGame PadからWebブラウザへの一方通行の通信を行うのに対し、Web MIDI APIはWebブラウザと外部MIDIデバイスとの間で、双方向の通信が可能です。

昔ホームページで鳴っていたやつ

ところで、MIDIってご存じですか？ MIDIと聞くと、「昔ホームページで鳴っていたやつ」 を思い出される方が多いと思います。そもそもMIDIとは、「電子楽器の演奏データを機器間でデジタル転送する」ための物理的な回路・インターフェイス、通信プロトコル、ファイルフォーマット等の複数の規格から成り立っている規格の総称です。そして、Web MIDIを語る上で重要になるのが、「MIDIプロトコル」と「物理的な回路・インターフェイス」というキーワードです。

冒頭の「昔ホームページで鳴っていたやつ」 ですが、あれはMIDIの中のファイルフォーマット（Standard MIDI File）を、OSが持つ音源を使って再生したモノとなります。「つまりどういうこと？」という方もいらっしゃると思いますが、この後、解説する、MIDIプロトコルの説明をご覧いただければ理解できるはずです。

まず最初は「MIDIプロトコル」から解説していきます。

MIDIプロトコル

MIDIとは先述した通り、「電子楽器の演奏データを機器間でデジタル転送する」ための規格でした。まず、演奏データ、つまり「音楽」とはどういうモノで成り立っているか、誰もが小学生で触ったであろうリコーダー（縦笛）を例に考えてみまます。

リコーダーは口にくわえて息を吹き込むことで音が出ます。強く吹けば力強い音が出るし、弱く吹けば優しい音が出る、つまり息の強さで 音の強弱が表現 できます。それから、押さえる穴の数を変えれば高い音階の音が鳴ったり、低い音階の音が鳴ったりする、つまり穴の数を変えることで 音程の変化 をさせているのです。これら 音の強弱が表現 、 音程の変化 の2つの情報があれば、音を再現できそうですよね。実はMIDIプロトコルで音を鳴らす部分は、この2つの情報を1つのメッセージとして扱うことで「機器間での演奏データの転送」を実現しています。さらに、MIDIには チャンネル というものがあり、これを使い分けることで16個の独立したメッセージを扱うことが可能になります。

それでは、実際にMIDIメッセージを見てみましょう。「音を出す」、「音を停止」する場合は、このように16進数でに3バイトを1つのMIDIメッセージとして指定します。

音を出す(noteOn)

音を止める(noteOff)

• チャンネル: 0〜15を16進数で指定
• 音階： 21(最も低いラ：27.5Hz)〜108(最も高いド：4186Hz)を16進数で指定
• 音の強さ： 0〜127を16進数で指定（音を停止の場合、機器によって解釈が違う場合もある）

MIDIメッセージの特徴の1つは、このように 「何を」 、 「どのくらい」、 「どうする」 の3つの内容が1組になっているところです。この2つのメッセージが分かれば音が出せるので、早速実装してみましょう。

Web MIDI APIを使って実装する

Web MIDI APIの仕様に中で、実装に必要な処理は以下の4つです。

1. コンピュータに接続されているMIDI Input/Outputの機器を列挙
2. 利用したい、MIDI機器を選択
3. MIDI Input機器からの入力はEventで上がってくるので、EventListenerで処理を書く
4. MIDI Output機器にMIDIメッセージを送信する

今回は単純に、MIDI Input機器からの出力をブラウザで中継して、MIDI Output機器に送信するプログラムを書いてみたいと思います。まずはライブデモを御覧ください。

inputのリストから「PC-Keyboard」をoutputのリストから「GMPlayer(WebMIDILink)」を選択してください。

左：inputのリストから「PC-Keyboard」を選択し、横に表示される鍵盤のアイコンをクリックした図、
右：outputのリストから「GMPlayer(WebMIDILink)」を選択し、横に表示されるMIDI端子のアイコンをクリックした図

環境の整備

今回は、PolymerとPolymerのElement(x-webmidiというElementのExtraのElement)を使いますので、ダウンロードしてきます。

• Polymer
• x-webmidi

例えば、 hx_webmidi_01 ディレクトリを作成して、その下に bower_components ディレクトリを作成し、リンクからダウンロードしたファイルを保存してください。(x-webmidiは解凍するとファイル名にバージョン番号が付いてしまいますので削除してください)
そして、これからコードを追加していく index.html を作成します。

以上で環境整備は完了です。

Polymerのコードを実装

では、次に実装するコードを見てみましょう。今回作成する index.html のコード全体はこちらになります。早速、HTML部分を上から説明していきます。

<script src="bower_components/webcomponentsjs/webcomponents.js"></script>
<link rel="import" href="bower_components/polymer/polymer.html">
<link rel="import" href="bower_components/x-webmidi/extras/wm-webmidilink/wm-webmidilink.html">
<link rel="import" href="bower_components/x-webmidi/extras/wm-pckeyboard/wm-pckeyboard.html">

<wm-webmidilink id="wmlink"></wm-webmidilink>
<wm-pckeyboard id="pckeyboard"></wm-pckeyboard>

input: <select id="midi-input"><option>SelectOne</option></select><span id="virtual-input"></span><br><br>
output: <select id="midi-output"><option>SelectOne</option></select><span id="virtual-output"></span><br>
<br>

<div id="msg" style="margin:30px;"></div>

Web MIDI APIで列挙したMIDIデバイスを選択するためのSelectタグを書いておきます（9行目、10行目）。また、MIDI Inputデバイスから受けたMIDIメッセージを表示するエリアもつけています(12行目)。尚、今回は、MIDIデバイスがなくても楽しめるようにPolymerを使っています（1行目から7行目）が、ここでは深く触れません。Selectタグの直後の<span></span>も同様にPolymerに関連する記載のためここでは触れません。

MIDIデバイスの列挙

続いてWeb MIDI APIを使った実際の処理の説明です。

navigator.requestMIDIAccess({sysex:false}).then(successCallback, errorCallback);
function successCallback(access) {
  (後ほど詳しく)
}
function errorCallback(msg) {
  console.log("[ERROR] ", msg);
}

requestMIDIAccessはPromiseの形になっていますので、まずは「システムエクスクルーシブ(sysex)」を使用するか・使用しないかを設定し、実行します。成功すればsuccessCallbackへ、失敗すればerrorCallbackへと処理が遷移します。ここで「システムエクスクルーシブ」とはMIDIメッセージの1つで、電子楽器機器固有の機能を制御するために使われます。電子楽器内のデータのバックアップで使うことも多いため、Web MIDI APIではセキュリティの観点から、ユーザの許可（ダイアログを表示）を得ることが利用する条件となっています。

Promiseが成功し、successCallbackへ遷移した場合の説明です。

// MIDI Inputデバイスの配列を作成
var inputIterator = access.inputs.values();
for (var o = inputIterator.next(); !o.done; o = inputIterator.next()) {
    midi.inputs.push(o.value);
}
// 仮想のMIDI Inputデバイスを追加
midi.inputs.push((document.querySelector("#pckeyboard")).getInput());

// MIDI Outputデバイスの配列を作成
var outputIterator = access.outputs.values();
for (var o = outputIterator.next(); !o.done; o = outputIterator.next()) {
    midi.outputs.push(o.value);
}
// 仮想のMIDI Outputデバイスを追加
midi.outputs.push((document.querySelector("#wmlink")).getOutput());

Prmiseが成功すると、コンピュータに接続されているMIDIデバイスの情報を引数で渡されます。MIDI Inputデバイスの場合access.outputs.values() 、MIDI Output デバイスの場合はaccess.outputs.values()を実行することで、それぞれのデバイスのリストをIteratorの形で取得できます。ここでは機器情報の配列 midi.inputs、midi.outputsを作成します。最後に仮想のデバイスを取得して追加しています。

MIDI Outputデバイスのリスト表示と選択時の処理

// MIDI Outputデバイスのリスト表示と選択時の処理
var osel=document.querySelector("#midi-output");                                                                                            
for(var i=0; i<midi.outputs.length; i++) {                                                                                                  
    osel.appendChild((new Option(midi.outputs[i]["name"], i)));                                                                             
}
osel.addEventListener("change", function(event){
    outputSelIdx=event.target.value;                                                                                                        
    // 仮想のMIDI Outputデバイスが選択された時の処理
    if(parseInt(outputSelIdx)>=0 && midi.outputs[outputSelIdx].virtual==true) {
        document.querySelector("#virtual-output").appendChild(document.querySelector("#wmlink").getElement());                              
    } else {
        document.querySelector("#virtual-output").innerHTML=""
    }
});

先ほど作成したMIDI Inputデバイスの配列の要素を、リストとして表示するためにselectタグにoptionとして追加します。（2行目〜5行目） リストの選択の変化に対してEventListenerを設定します。（6行目～14行目）ここで行っているのは、選択された機器に割り振られたIDを記憶（7行目）、続いて、もし仮想デバイスの場合はリストの横にアイコンを追加（9行目～13行目）を行っています。

MIDI Inputデバイスのリスト表示と選択時の処理

// MIDI Inputデバイスのリスト表示と選択時の処理
var isel=document.querySelector("#midi-input");                                                                                             
for(var i=0; i<midi.inputs.length; i++) {                                                                                                   
    isel.appendChild(new Option(midi.inputs[i]["name"], i));                                                                                
}
isel.addEventListener("change", function(event){
    if(inputSelIdx!=null) {
        midi.inputs[inputSelIdx].onmidimessage=null;                                                                                        
    }
    inputSelIdx=event.target.value;                                                                                                         
    midi.inputs[event.target.value].onmidimessage=eventOut;                                                                                 
    // 仮想のMIDI Inputデバイスが選択された時の処理
    if(parseInt(inputSelIdx)>=0 && midi.inputs[inputSelIdx].virtual==true) {
        document.querySelector("#virtual-input").appendChild(document.querySelector("#pckeyboard").getElement());                           
    } else {
        document.querySelector("#virtual-input").innerHTML=""
    }
});

先ほど作成したMIDI Inputデバイスの配列の要素をリストとして表示するために、selectタグにoptionとして追加します。（2行目～5行目）リストの選択の変化に対してEventListenerを設定します。（6行目〜18行目）ここで行っているのは、選択された機器に割り振られたIDを記憶（10行目）、MIDI Inputデバイスからの入力を受ける為の関数をonmidimessageに指定(7行目〜11行目)、もし既MIDI Inputデバイスからの入力を受ける機器が指定されていたらonmidimessageも解除（7行目〜9行目）、続いて、もし仮想デバイスの場合はリストの横にアイコンを追加（8行目～12行目）を行っています。

MIDI Inputデバイスからの入力を受けた時の処理

ここでは、MIDI Inputデバイスから取得したMIDIメッセージを、もしMIDI Outputデバイスが指定されていたら加工はせずにそのまま送信しますので、以下のようになります（7行目～9行目）。MIDI InputからのMIDIメッセージはevent.dataで取得することが可能で、MIDIメッセージは画面表示します（4行目、5行目）。

function eventOut(event) {
// MIDIメッセージを表示
for(var i=0, out=[]; i<event.data.length; i++) out.push(("00"+event.data[i].toString(16)).substr(-2));
    var div_msg=document.getElementById("msg");
    var ex_msg=div_msg.innerHTML.split("
");
    while(ex_msg.length>19) ex_msg.pop();
    div_msg.innerHTML=out.join(" ")+"
" + ex_msg.join("
");

    if(parseInt(outputSelIdx)>=0) {
        midi.outputs[outputSelIdx].send(event.data);
    }
}

以上で、接続されたMIDI Inputデバイスから、指定したMIDI Outputデバイスへメッセージを送信するWebアプリケーションが作成されました。PCのキーボードで演奏ができるようになったはずです。

もし電子ピアノ等の電子楽器をお手持ちの場合はUSB端子がついてないかご確認ください。そして、もしUSBで接続可能であれば接続し、作成したWebアプリをリロードしてみてください。inputもしくはoutputのどちらかに接続したデバイスがリストされるはずです。（ポケットミク、eVY1シールドも操作できます）

また、MIDIメッセージは単なるメッセージですので、音以外に割り当てたり、鍵盤に複数のMIDIメッセージを割り当ててフレーズを再生する等、アイデア次第で様々なモノのコントローラとして活用することができます。今回は、花火をモチーフに（季節外れですが…）こんなアプリケーションを作ってみました。鍵盤を弾くと、音とともに花火の打ち上がります。この音はもちろんMIDIメッセージで音源モジュールを鳴らしています。

おわりに

いかがでしたでしょうか？Web MIDIはそんなに難しくない、いやむしろ簡単であることをお分かりいただけたと思います。普段Webの開発をしていると「外部デバイスと接続して何かをする」という発想はなかったかもしれませんが、Web MIDIを使うとそういった実装もWebだけでできるようになります。「何かを作る」場合に選択の1つに是非Web MIDIを加えてみてください。

さて、今回は「MIDIとは何か？」というところから「Web MIDI APIの実装」、そして「MIDIを別の用途に応用してみる」というところを紹介してきました。しかし「難しくはないけど、少し準備が長い」と感じたりしていませんか？

実はWeb MIDIにはHotPlugの機能もありますが、今回の実装ではそこまで紹介しきれていないのです。そこで次回は、今回の記事にも少し登場した、Web MIDIと仮想デバイスの実装が一瞬でできてしまうx-webmidiというPolymerのElementについて、さらに具体的に紹介する予定です。

お楽しみに！

本記事は、「Polymer 1.0最新情報」の後編になります（前編はこちらから）。Google I/OでPolymer 1.0が取り上げられた「Polymer and modern web APIs: In production at Google scale」のセッションをレポートします。Polymerの最新情報や活用事例、Polymer Catalog、Polymer Starter Kitなど、盛りだくさんのこのセッションの翻訳と解説を前後編に分けてお伝えします。

後編となる本記事では、「ライブサイトへの適用例（後半）」、「Polymer Starter Kitとは」を解説します。

ライブサイトへの適用例（後半）

前編に引き続き、Polymerのライブサイトへの適用例の後半です。コードを交えながら具体的に解説していきます。

Google I/O Web App

このアプリは社内ではIOWA（アイオワ）と呼んでいる。IOWAはModen Web Platformでの良い実装例で、デスクトップでもモバイルでも動作して、コンテンツが最初に読込まれるときマテリアルデザインのエフェクトと共に表示され、ページとコンテントの間の表示での大きなエフェクトついているし、デスクトップでもモバイルでもビデオをクリックすると全画面になる。Webアプリでここまでネイティブアプリ感が出せている。

そのIOWAには想像できる新しいWeb APIのほとんど全てが使われている。

ここからIOWAのポイントは以下です。

• バックエンド：広範囲に渡ってAppEngine上でGoを使用
• Material Designの実装に関して：Web Animation、Promiseで各種エフェクトを実現
• 開発したチーム：ソフトウェア エンジニアではなく、Developer Relationsチーム
• ツール：誰でも使うことのできる3rdパーティ製のツールを使い、Googleの特別なツールは使っていない

ここから実装方法に関しての説明になります。

Templateを使ったSPA（シングル・ページ・アプリケーション）の実現

Google Santa Tracker 2014ではURLルーティングを行うことでSPAを実現していましたが、IOWAではTemplateとHTML Importsを使って動的にコンテンツを読み込でいるそうです。

1. 異なるid属性を付けた複数のTemplateを1つのページに配置
2. ref属性を持ったTemplateタグを配置
3. ref属性に予め埋め込んだTemplateのidどれかを指定

すると、指定したidのTemplateのコンテンツがTemplateの中に差し込まれます。IOWAは予め複数ファイルでページをTemplateとして用意して、必要に応じてそれらのファイルを動的に読み込む（HTML Imports）ことでSPAが実現されている、とのことでした。

Material Designの実現

ビデオ等は遅延ゼロの理想状態でMaterial Desginの動きは説明されているが、Webアプリではそうはいかないので工夫が必要です。IOWAではWeb Animation、Promiseを使い、ロジカルなアニメーションのシーケンスを作ることで実現しているそうです。

1. Promiseが”page-transition-start”のEventを発行し、ページトップ部分の色を変更するのと同時にコンテンツをページ表示領域から外側にスライドしフェードアウトさせる
2. Import Page Method（TemplateとHTML Importを使ったSPA実現方法）を使ってページのコンテンツをAjaxで取得する
3. コンテンツの準備が完了したら、ページ全体のアニメーションを実行する。このアニメーションは基本的にコンテンツを200ms以下の時間でページにスライドさせていて、パララックスのエフェクトもかけている
4. 動的なページ読み込みとアニメーションが完了した時点で、例えばJavaScriptの実行のようなページを構成するために必要な処理が実行できるようになる

このように、PromiseとWeb Animation APIをWrapして利用することでCSSのアニメーションが動いたり、ネットワーク接続が発生したりと非同期な処理が起こっている状態でも、ロジカルな同期が可能です。

オフライン ファーストの実現

IOWAで注目すべき機能で、Service Workersを使って実現している。Service WorkersのおかげでWeb開発者が実現できることの代表例は以下です。

• ページキャッシュ
• プッシュ通知（Push Notification）
• バックグラウンド・シンク
• ネットワークリクエストの横取り

IOWAではこれらの機能を使い、アクセス解析を行うGoogle Analyticsへのリクエストをオンライン時はリアルタイムに、オフライン時は横取りをして一旦IndexDBに蓄積。オンラインになった段階で再現をしてオフライン時のアクセス解析を可能にしています。一般的にも、こうすることで重要なインサイトを逃さず見ることができるでしょう。

オフライン時の動作の実装で注意した点

Webサイトがオフラインでも動作することはユーザは体験したことがないので、例えばオフラインになったときにアプリケーションを終了されてしまうことを防いだりします。またオフライン動作することに驚かれないために、IOWAでは「オンラインからオフライン」に遷移した時にアプリケーション側で何が起こっているかユーザが把握できるよう、トースト（自動的に消える小さなお知らせエリア）で状態を知らせることができるように注意して実装してます。

実際に以下のリストのような事象が起こった場合にトーストを出しています。

• 初回アクセス時：次回からは最初からオフラインで動作します
• オフライン時の情報情報更新：オンラインになった時に情報をサーバに通知します

オフラインとは電波（Wi-Fi、3G、4G等）の状況が悪いとき、Airplaneモード等でインターネットにつながらなくなった状態のことを指しています。

プッシュ通知(Push Notifications)

プッシュ通知はNativeなアプリでは当たり前になっている機能ですが、Webの世界では真新しい機能になります。もちろん、アプリが開いていない状態でも通知を受けることが可能です。

プッシュ通知も新しい機能なので、オフライン時の動作と同じく状況をトーストで通知しています。このプッシュ通知を動作させるためには、ユーザが通知を受ける/受けないを選択することに加えて、通知を受け取る許可をユーザがブラウザに対して行う必要があります。

プッシュ通知を行う目的はWebサイト/アプリへの再訪にあります。IOWAではその効果測定のためにプッシュ通知からどれだけユーザが実際にサイト/アプリに再訪してくれたかをAnalyticsを利用して計測しています。

プッシュ通知の送信は一見難しそうですが、Elementがあるので心配しないでください。実際にはこのような形で実装することができます。

プッシュ通知を使う目的はWebサイト/アプリへの再訪です。なのでIOWAではプッシュ通知からどれだけユーザが実際にサイト/アプリに再訪してくれたかの計測をAnalytics利用して行っています。

ここまでお話してきた、オフライン動作の実現、Service Workers、プッシュ通知に関してもElementが存在していて、Platinum Elementsに実装しています。

リンク：Platinum Elements（英語）

最後に「6ヶ月の出来事のお話しだったので、駆け足の説明で盛りだくさんになってしまった。紹介した2つはライブサイトも動作しているし、ソースコードも公開しているので、詳しくはそちらをご覧ください」と結びました。

(Speaker: Eric Bidelman)

リンク：Google I/O web app [ライブサイト] [コード]

Polymer Starter Kitとは

「PolymerのDeveloper Toolを担当しているAddy Osmaniです」と自己紹介から始まりました。

そして間髪入れず、最近の出来事からの例えを交えて「物事の筋道にはステップを踏まないと思い通りのモノは作れない」ということの説明が始まりました。

Addyの友達に赤ちゃんが生まれたそうで、赤ちゃんのスケッチしてプレゼントしようと考えたそうです。そしてスケッチ方法をGoogle.comで検索をすると「まずは丸を書くことが最初のステップ（Step1）」という結果だったそうです。「実現可能性を確信したけど、次のステップを探した結果がStep2でした。このStep1からStep2への飛躍は非常に大きく、これを目標に続けると最終的にはStep1.5のようになることも少なくない」と続きます。

Polymerはまさに例に挙げたStep1からStep2へ移行しようとしている段階なので、これを避けるべくPolymer Teamは「Polymer Starter Kit」で、この状況の回避を行うとのこと。「Polymer Starter Kit」は、過去1年間でPolymerを使ったプロジェクトGoogle I/O App、Web Starter Kit、Google Santa Trackerを見返して、そこから得られた知見を1つにまとめた結果です。

ここから「Polymer Starter Kitがどのようなものなのか？」の説明に入ります。

Material Design

非常に高いレベルでMaterial Designをサポートしています。Toolbar，Header-Panelのようなモバイルアプリを開発するときに必ず必要になるパーツ、URLルーティングや複数の画面サイズにフィットするような仕組みもサポートしている。CSS Custom Propertyを使って、アプリ全体のテーマカラーを数行のコードで変更する可能で、非常にパワフル。

モバイルWebアプリ開発ではテーマカラーの変更、クロスデバイス（Android、iOS、Windows Phone）でホーム画面へのアイコンリンクの準備も最初からできているので、再訪へとつなげられる。

Adaptive UI

今回のI/OでMaterial Design Teamが発表したガイドライン。これはデバイスによってインタラクションをどう作り込むのがよいのかのガイドラインですが、Polymer Starter Kitはこれらを全てを含んでいる。あくまでもこれらは1つの例でしかないので、必要に応じてカスタマイズすることも可能。

App Template

Navigation Card Layout、住所録のようなアプリに最適なNavigation List Detail Layout、List Card Over Layout(Wider Card View Layout)などが用意されていて、すぐに利用できるLayoutのセットとなっている。

Offline-first (in your app)

Ericもオフラインの重要性を訴えた通りで、またRob Dodsonも「2015年は、もしアプリがオフラインをサポートしていないのであれば、それは本当の意味でのモバイルWebエクスピリエンスを提供できていない、という考え方が現実になるだろう」と言っています。良いことにPolymer Starter Kitはデフォルトでオフライン ファーストになっているので何の設定をすることもなくAirplaneモードや、オフラインになったときにもアプリに含まれる全てのページにアクセスすることが可能。

Service Workers

素晴らしい機能だけど、導入するには多くの設定が必要です。ですが、

> There is an element for that!

で、Polymer CatalogにあるPlatinum Elementsを使えば、Service Workersを使ったキャッシュ機能を簡単に実装することができます。

Service Workersのセット・アップの例です。Service Workersの登録し、キャッシュのストラテジを数行で設定している。例では「Network First」をキャッシュのストラテジとして、キャッシュしたいファイル名を予め宣言しています。

Production-ising Cache

ユーザにできるだけ小さく、できるだけ速いアプリを提供するという意味ではビルドプロセスはとても重要。Polymer TeamはストリーミングビルドシステムのGulpが大好きなので、Polymer　Starter Kitに採用している。

web-component-testerなどのクオリティテスト、Vulcanize等のミニフィケーション等が可能。Browser Syncを使っているので、アプリに変更を加えるとその変更はクロスデバイスで伝搬され（クリック/タップ、スクロールも含む）全てのデバイスで一度に確認することも可能。

実際に「Polymer Starter Kit」を適応して「Paper Reader」という名のRSSリーダアプリを作ったお話は変わります。

使った技術の一覧で、これらの1つ1つにElementが存在しています。

• 記事をGoogle Feedから取得（RSS、Atom、Media RSS feedに対応）
• 既読/未読の管理にはFirebaseを利用
• オフラインでの動作
• 新着のプッシュ通知

まとめると、Polymer Starter Kitは大きく分けて、以下の4つを含んでいる。

• Components
• Layout
• Theming
• Build tools

「これらのElementやPolymer Starter Kitを使って、何を作るかはあなた次第です」

と最後に結び、Matthew McNultyに戻ります。

(Speaker: Addy Osmani)

リンク：Polymer Starter Kit（英語）

まとめ

ここ2年間で、Polymerが約束をして実現したことは以下の通り。

• Web Components
• Interoperability
• 宣言的な書き方ができること

ChromeではWeb Componentsがリリースされて1年、またProductionに耐えられるPolymer 1.0がリリースされた。

Salesforde、Vaadin、Atabistなどの3rdパーティも、PolymerをProduction用に使っている。Google Santa Tracker、Google I/O web appはオフラインで動作します、Polymer Starter Kitも今日から使えるし、今後は1.0には入れられなかった新しい機能、Elementを早いペースで次々に追加する予定です。

Polymerについての情報の取得等のリンクは以下。

• 最新情報：polymer-project.org
• Polymer Teamと直接会話：Slackチャンネル

そして、Polymer単独のカンファレンスの告知がありました。

「2015年9月15日にアムステルダムにて、PolymerだけのカンファレンスPolymer Summitを開催します。1日中、Polymerを、また最先端のWeb開発を学びにくてください」とのことです！

最後に「バグも見つけてね」でセッションは終了でした。

(Speaker: Matthew McNulty)

あとがき

個人的にはPolymerを最初に触ったのが2013年頃で、そのキッカケは楽器系のアプリを作った時に必ず使いたくなるリッチなノブ、スライダ、スイッチ、鍵盤を簡単に配置できる世界を夢見たwebaudio-controlsが開発され始め、それに乗っかって一緒にはじめたことでした。

今回のセッションに参加して、その中で何度もリピートされていた言葉、 “There is an element for that!“（それ、エレメントあるよ！）をwebaudio-controlsを作ってから、実際に自分自身が言っていたことに気が付きました。

また、ブラウザにMIDI機器を接続して遊べるWebアプリを、簡単に作ることができる世界を夢見てx-webmidiというElementも作りました。これを作った理由は「ゼロから書くのはちょっと…という理由で手が出しずらい、という印象を少しでも和らげたい」からでした。

この「手軽に使えること」だったり「ゼロから書くのはちょっと…という理由で手が出しずらい、という印象を少しでも和らげたい」という想いがさらに一般に拡がりElementが量産されたのであれば、その未来はブラウザにはよりプリミティブなAPIが実装されるようになり、ブラウザのAPIをより使いやすくする、APIを組合せることで新たな枠組みを作るためのWeb Componentsが「ブラウザのAPIとWebアプリの中間に新たなクリエイティブな層」を創り出して、Web開発がExtensible Webな時代へ突入するのかな？なんて、Webの未来をモヤモヤ考えさせられる2015年のPolymerのセッションでした。

Polymerは、Google I/O 2015にて1.0が正式リリースとしてアナウンスされました。本記事は、Google I/OでPolymerが取り上げられた「Polymer and modern web APIs: In production at Google scale」のセッションをレポートします。Polymerの最新情報や活用事例、Polymer Catalog、Polymer Starter Kitなど 盛りだくさんのこのセッションの翻訳と解説を前後編に分けてお伝えします。

前編となる本記事では、「Polymer1.0の特徴」、「Polymer Catalogとすぐに使えるElements」、「ライブサイトへの適用例（前半）」を解説します。

Polymer1.0の特徴

Polymerが全体的にどう変わったのか、その特徴をまとめて説明してくれました。Polymer1.0の特徴を全て紹介しきれていないとのことですが、セッションで特に紹介されていたのは以下の通りです。

• 高速化(0.5と比較)：Chromeでは3倍、モバイルSafariでは4倍高速化した
• 軽量化(0.5と比較)：以前より35％コード量減らしPolyfillも含めてgzipをすると19kb-42kb
• Shady DOMの採用：スピードを重視したShadow DOMのPolyfillで100％互換ではない
• CSS Custom プロパティ：プロパティの変更だけでテーマやスタイルの変更を可能に

「PolymerはWeb標準技術であるWeb Componentsのライブラリであって、そのElementを作ることができます。なので、結果的にそれらのElementはWeb標準技術の上に作られたのと同意である。他のブラウザ上でも動作するし、AngularやReactといったFrameworkの中に一緒に共存させることもできる、というところが最大の特徴であり利点でもあります」

セッションでは、これらの説明をコンテナを運ぶ物流システムに例え「標準化を元に作られたコンテナ（Polymer Element）だからこそ、標準化されたボート・電車・トラックで効率的に運ぶことだってできる（ブラウザのInteroperabolity）」という形で説明をしていました。この例えは、Polymer TeamはSan Franciscoのオフィスにいて、普段の会話の中に湾を行き交う輸送船について話すことが多いことに由来しているそうです。

(Speaker: Matthew McNulty)

Polymer Element Catalogとすぐに使えるElements

ここからPolymerを使ってWebアプリを作るときのElementについて話に変わります。

「Polymer Teamは全ての開発者にPolymerを使って高品質なアプリを簡単に作ってもらうことを目標にしています。そして、アプリはElementによって出来が左右されるので、高品質なアプリを作るには高品位なElementが不可欠です。なのでGoogleでは高品質なElementを提供します」

という導入があり、続いて具体的にElementの説明です。

まずは去年から公開されていたElementとして、Iron Element、Paper Elementが紹介されています。そして、新しく追加されたElementとして、Google Web Components、Platinum Elements、Gold Elementsがあります。

• Iron Element (Fe)
  新しく聞こえますが、Core Elementから名称を変更しました。内容は以前と変わらずElementの基本となり、どのアプリケーションにも使うようなエレメントのセット。
• Paper Element (Md)
  Material DesignのリファレンスになるElementのセット。
• Google Web Components (Go)
  Google SDKとも言えるようなElementでGoogleのServiceやAPI（GCP、Drive、Map、Hangout、Calendar、Analytics、YouTube、Docs、Chrome Web Store、アドレス帳など）を利用する際に利用するElementのセット。
• Platinum Elements (Pt)
  オフライン・キャッシング、ServiceWorkers、Push Notificationのようなとてもパワフルな機能を最も簡単に利用することのできるElementのセット。このElementを使うことで、半年前には夢だと思っていたような機能が簡単に実装可能。
• Gold Elements (Au)
  モバイルでの高品質な決済のチェックアウト遷移を作成できるElementのセット。日付、カード番号等の自動Validationが可能。

これらのうち、新しく追加された3つのElementは、Web開発者が特定の問題を解決するために用意しているものとのことです。このPolymer Catalogについては次のように説明しています。

「このサイトの目的は、解決したい問題がある場合は解決策を見つければいいのだけど、例えば、何かに触発されたかったり、思ったこともないようなデザインを見つけたかったり・眺めたかったり、考えたこともないようなアプリケーションを考えたいという場合もあります。この2つ「解決策を見つける」、「インスピレーションを得たい」を実現させる為に、Elementをブラウスでき、デモを動作可能で、ドキュメントも読むことができるのがPoymer Catalogです」

リンク：Polymer Catalog（英語）

Polymerを使ってアプリを実装、公開している3rdパーティとそのアプリの紹介

「Polymer TeamではWeb開発者が「実装したい」と考えるであろう機能は、”There is an element for that!“（それ、Elementであるよ！） と言えるようにりたいと思っていますが、我々の以外でも同じことを想っている方々は多くいます。そこで、ここでは出版関連を行っているAtabist、Enterprise向けのJavaアプリ用のFrameworkを作っているVaadin、そしてSalesforceの3つの事例を紹介します」

Atabist

出版関連を行っている会社で、Web上に本を作るPlatformをリリース。Webは音声、映像、画像、地図、ブラフを一緒に配置して1つにまとめるにはとてもよい媒体で、これらの1つ1つをPolymerのElementにして自由に配置できるようにしたのがこのPlatform。

リンク：Atabist（英語）

Vaadin

Enterprise向けのアプリを書くためのFrameworkを作っている有名な会社の1つで、Front-endのComponentsはPolymer Elementを使って実装している。特に大量のデータを表示することに重きを置き開発されていて、例えば、v-gridというElementを作っていて、これを使うとアドレス帳のようなモノを表示、LazyLoading、行または列の複数選択の機能もElementを実装することができる。グラフを描くElementも作っていてタグ名を変えるだけで、グラフの種類を変更することができる。

リンク：v-grid（英語）

Salesforce

Salesforceは彼らのPlatform上でそのデータを表示するアプリケーションを作るためのSDK、APIを公開している。このアプリケーション開発をより簡単にしたいということで、Polymer Elementでの提供を行っている。

ライブデモ：デザイナ（英語）

Google社内でのPolymerの実用例

最後にGoogle社内でのPolymerの実用例の紹介です。Polymer Teamは「GoogleさんはLiveサイトでPolymerを使っているの？」とよく聞かれるそうですが「もちろん使っている」とのことで、そのうち3つを紹介してくれました。

Translate：Translation TeamはTranslateの質を上げるためにコミュニティのメンバーが参加して作り上げることのできるシステムを新しく作った。サイト全体がPaper Elementを使ったMaterial Designを採用している。このプロダクトはFront-endエンジニア2人で2～3ヶ月の開発期間で完成させることができたとのこと。Paper Elementを使っているので、開発者はどうやってMaterial Desiginを実装するかということは気にせず、アプリケーションの本質部分に集中して開発を進めらたそうです。

ライブデモ（英語）

Play Music：Play TeamもPaper Elementを使ってMaterial Designを採用しているので、アプリケーションの本質部分に集中して開発を進めることができたとのことです。Play Musicは現在はPolymer Elementの組合せで作られていて、同じような音楽再生用WebサイトにElementを再利用することも可能です。（日本からはアクセスできません）

YouTubeのモバイルWebサイト：多くのPolymerを使ったサイトはまだGoogle社内にしか公開されていないのですが、その中の1つ、それがYouTubeのモバイルのFront-End。これも全てがPolymer Elementで作られています。キビキビ動き、アニメーション、トランジションもついていて、とてもよいUIに仕上がっている。またビデオを画面の角にドラッグして動かすというWebでは実現が可能とは予想していなかったであろう動作も実現できている。このようにWebでもNativeのような最高の動作をPolymer Elementで作ることができる。

「Elementはとても素晴らしく、紹介したような素晴らしいElementを作ることができます。Polymer Teamは引続き素晴らしいElementを開発していきます。そして、コミュニティからもっと素晴らしいElementが出てくることを楽しみにしています」

と結び、次のライブサイトへの適用例の説明に移りました。

(Speaker: Taylor Savage)

ライブサイトへの適用例（前半）

ここからはEric Bidelmanにバトンタッチです。彼の3年間を振り返ってのお話からです。

Polymer Teamにいて「これはどうやってWeb Componentsで実現するの？」ということを開発者と話してきて、そこでよく質問にあがる具体例が「どうやってSPA（Single Page Application）をWeb Componentsでどう実装するのか？」、「他言語化やLazyLoad、またURLルーティングはど実現するのか？」というような「Polymerを使ってどう実現したいモノを実装するか？」という部分です。それに対してPolymer Teamはこう答えているそうです。

> There is an element for that!

という掴みがあり、続いてEric Bidelmanが前回のI/Oから数多くの実験を実際に行い、Google.com上のアプリを作りそれらを公開して、実際に使えるのかを試してみた、というストーリで実例を2つ紹介してくれました。

「これらの事例ではPolymer1.0ではなく、ちょっと遅いけどGoogle.comで公開されているのは0.5。なんだけど、1.0と書き方が少し違うだけで本質的なPolymerの部分は同じなので、これからお話をする事例には影響は特にないのです」

と捕捉があって、Google Santa Tracker 2014とGoogle I/O Web Appの説明が始まります。

Google Santa Tracker 2014

このアプリは12月に公開されたアプリで、サンタ村を訪れることができ、12月中は毎日新しいゲームを提供したりしているAdvent Calendarのアプリ。日々提供されるゲームだったり、そのSceneのことを社内ではLaunchと呼んでいて、それらの全部がElementになっていて、Web AudioだったりWeb GLだったりを使っているものもある。クリスマスイブには今どこでサンタがプレゼントを配っているかも見ることができる。もちろんそれもElementになっている。

コード的な説明です。<santa-app> が全体をオーケストレーションするElementで、Google Analyticsに、また音楽の再生・停止をするEventの発火を行う。<santa-app> の内部にはさらにElementが入っている。URLルーティングもElementを作って対応していて、LazyLoadingのElementとを結びつけ、ユーザがSceneを選択したときにJavaScript、CSSが動的に読み込まれるような仕組みになっている。このプロジェクト全体的にElementはDeclarativeにしていて、各Sceneのプログレスバー、背景色、背景画像もそのおかげでHTMLのAttributeでの設定が可能になっている。

Google Santa Tracker 2014の説明は以上でした。

リンク：Google Santa Tracker [ライブサイト] [コード]

（後編に続きます）

ブラウザ上で音を扱うというと、直接音を加工できるWeb Audio API、ブラウザから直接MIDIデバイスと接続できるWeb MIDI APIの2つがここ数年の間に利用可能になり、実際のWebサイトでも使われるようになりました。
今回は「ハンズオンだともっとよかった」というお声をいただきましたHTML5 Conference 2015での講演内容を元に、2つのAPIの説明と、実際にブラウザ上に電子楽器の1つであるシンセサイザーを作ってしまうという記事です。

記事中のサンプルはGitHubに公開していますので、そちらも合わせてご参照ください。

利用するAPIの説明

Web Audio API

短く一言で説明すると「ブラウザ上で音を直接作ったり、いじったりすることのできるAPI」です。もう少し難しく言うと「ブラウザ上で波形処理を可能にしたAPI」となります。
Web Audio APIの理解を深めるためにまず「音」とは何かを考えてみたいと思います。Wikipediaには以下のように書かれています。

響き、振動、音波と出てきました。実は、音を目に見える形にすると波になるのです。Web Audio APIも原理は同じで、波を与えて音として出力しています。そして、その波の形（波形）をいじる（処理）して様々な音を作り出すとご理解いただけばよいと思います。

原理の説明はここまでにして、最初に声を取得して、その声をWeb Audioでピッチシフト（音を高くしたり、低くしたりする効果）、Delay（音を遅らせる効果）の加工を行うデモをご紹介いたします。（できるだけマイクとヘッドホンをご用意ください）ピッチシフト＆Delayのライブデモ

ノブとボタンの説明▼

(1) PitchShift ON/OFF

(2) Shiftの種類：(上:高い、下：低い)

(3) Delay ON/OFF

(4) Delayの種類：並列/直列

(5) Feedback量

(6) Delay時間

ノードグラフ（Web Audioでは処理をする1つ1つをノードと呼び、それらをつなぎ合わせて1つのグラフにします）は上図のようになっています。ピッチシフト＆DelayのライブデモのDelayをONにして、種類を直列にする（（4）のスイッチを下にする）とこのような接続になります。直列につなげると、マイクで拾った音が(6)Delay時間だけ遅れてスピーカから出るようになります。
このノードグラフをWeb Audio APIで書くとこうなります。（ピッチシフト部分、Delay部分をObjectにしてまとめている関係上、ゼロから書くともう少し長く、複雑になります）（ライブデモ）

var ctx=new AudioContext();
var mic;
var psin=ctx.createGain(), psout=ctx.createGain();
var delayin=ctx.createGain(), delayout=ctx.createGain();

navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia;
navigator.getUserMedia({audio : true}, successCallback, errorCallback);
function successCallback(stream) {
    mic = ctx.createMediaStreamSource(stream);
    mic.connect(psin);
}
function errorCallback(msg) {
    console.log(msg);
}
var pshift=new pitchShift(ctx);
psin.connect(pshift.getSrc());
pshift.connect(psout);

var delay=new delayProcess(ctx);
delayin.connect(delay.getSrc());
delay.connect(delayout);

psout.connect(delayin);
delayout.connect(ctx.destination);

このように、Web Audio APIを使うと、今まではプラグインを使う以外に方法がなかったWebブラウザ上でのリアルタイムな波形処理を、比較的簡単に行うことが可能です。

Web MIDI API

短く一言で説明すると「ブラウザとデバイス間でMIDIメッセージを送受信するためのAPI 」です。MIDIとは Musical Instrument Digital Interface の略で、電子楽器の演奏データをデバイス間でデジタル転送するための世界共通規格であり、物理的な送受信回路・インタフェース、通信プロトコル、ファイルフォーマットなど複数の規定からなっています。Web MIDI APIは特にこの中の通信プロトコルをWebブラウザへの実装したAPIです。

Web MIDI APIの特徴は外付けのMIDIデバイス※0とWebブラウザが直接接続できるところです。ですのでWeb Audio APIのようにそれ単体で音が鳴ったりする訳ではなく、MIDIデバイスからWebブラウザで動くアプリケーションをコントロールしたり、またWebブラウザからMIDIデバイスコントロールするために利用します。よって本記事では最初にWeb Audio APIを使った電子楽器アプリケーションを作り、それをWeb MIDI APIを使って外付けのMIDIデバイスからコントロールするというシナリオで進めさせていただきます。

なお、やや長い記事になってしまいましたので、ソースコードの量の少なさを体感していただき、その解釈は後回しにしてデモを触っていただくのがよいと思います。「電子楽器を実装する」というと難しそうに聞こえるかもしれませんが、そこまで難しくもありませんので実装に挑戦していただけるとうれしいです。

Web Audio API で電子楽器を実装する

電子楽器と言ってもその種類は複数あります。今回はその中からアナログシンセサイザーとFMシンセサイザーを実装してみます。

Web Audio API でアナログ・シンセサイザー

アナログ・シンセザイザーはアナログ回路を用いて信号処理を行うことで音を出す方式のシンセサイザーです。そのアナログ回路をWeb Audio APIを使って実装していきます。まずはどんな音が出るか完成形のデモで試してみてください。

画面上にある２つのスライダを動かすと音色を大きく変化させることができると思います。それでは原理を見てみましょう。

このシンセサイザーは以下の3つの部品を使っています。

• 基本の信号・波形を作り出す発振機※1 （VCO0、VCO1）
• 波形を加工するフィルタ（VCF）
• 低い周波数の制御信号を発振機から発生させて送ることで周期的な変化を与える（LFO）

これらを接続して下図のノードグラフを作ります。

ソースコードは以下のようになります。（ライブデモ、ソースコード）

var ctx=new AudioContext();
var vco0, vco1, lfo, vcf;

vco0=ctx.createOscillator();   // VCO0を作成
vco1=ctx.createOscillator();   // VCO1を作成
lfo=ctx.createOscillator();    // LFOを作成
vcf=ctx.createBiquadFilter();  // VCFを作成

vco0.connect(vcf);             // (1)の接続
vco1.connect(vcf);             // (2)の接続
lfo.connect(vco0.frequency);   // (3)の接続
lfo.connect(vco1.frequency);   // (4)の接続
lfo.connect(vcf.detune);       // (5)の接続
vcf.connect(ctx.destination);  // (6)の接続

// 値を変更
//vco0.type="sawtooth";
//vco1.detune.value=-35;
//lfo.frequency.value=2;
//vcf.frequency.value=10000;

// Oscillator（発振機）を動作させて発音
vco0.start(0);
vco1.start(0);
lfo.start(0);

// 音階を変える
vco0.frequency.value=440;
vco0.frequency.value=440;

これで発音されます。が、このままですとそのままの音が出るだけですので面白くありません。そこで、それぞれのノードのパラメータを変更してみます。コメント化していた「値を変更」の以下4行を生かしてみます。（ライブデモ、ソースコード）
先程より音色が明るくなったと思います。完成形のデモのVCFのスライダを右に動かしたのと同様な値の変更を行いました。VCFは設定値より低い周波数を通す（ローパス）フィルタになっていて、そのパラメータを大きくしてより多くの明るい部分を通して明るい音色を出しています。

さらにシンセサイザーっぽい音にするべく、音量や音高などを時間で変化させるADSR※2 と呼ばれてるエンベロープ※3 の機能実装します。ここではこのエンベロープを発振機（Oscillator）の音量（VCO0、VCO1）に適応しますので音量を調節するGainNodeを(1)、(2)へ追加します。そのソースコードは以下のようになります。（ノード作成、接続部分のみ抜粋）

※2 ADSR：下図のように波形を処理する場合のそれぞれも部分を指しています。

• A (Attack) :音の出始め（例えば鍵盤を押した瞬間）から最大音量に到達する時間
• D (Decay) : Attackで到達した音量最大からSustainに到達するまでの時間
• S (Sustain) : Decayから音が出続けている間保つ音量
• R (Release) : 演奏終了（例えば鍵盤を離した瞬間）から音量ゼロまで到達する時間

※3 エンベロープ： ピーク（最大値）を描いた曲線。特にここでは音量のピークを描く曲線のことを指しています。

var ctx=new AudioContext();
var vco0, vco1, lfo, vcf;

vco0=ctx.createOscillator();
vco1=ctx.createOscillator();
lfo=ctx.createOscillator();
vcf=ctx.createBiquadFilter();

// GainNodeを追加
vco0gain=ctx.createGain();
vco1gain=ctx.createGain();

vco0.connect(vco0gain); // vco0の接続先を変更
vco1.connect(vco1gain); // vco1の接続先を変更
vco0gain.connect(vcf);  // vco0gainからvcfへ接続
vco1gain.connect(vcf);  // vco1gainからvcfへ接続
lfo.connect(vco0.frequency);
lfo.connect(vco1.frequency);
lfo.connect(vcf.detune);
vcf.connect(ctx.destination);

// Oscillator（発振機）を動作させて発音
vco0.start(0);
vco1.start(0);
lfo.start(0);

続いて、実際にエンベロープを適応していきます。Web Audioには今回のエンベロープのような時間と目標値を指定して、その間を連続的に値を変化させるオートメーションの機能も提供されており、非常に簡単に実装することが可能です。今回は「指定した値まで直線的に連続して値を変化させる」linearRampToValueAtTime()を使いオートメーションを行います。 ソースコードは以下になります。（エンベロープ部分のみ抜粋）

var now=ctx.currentTime;
var attack=0.5, decay=0.5, sustain=0.5, release=0.5;

var rootValue0=0.8; // Attackの目標値を0.8
vco0gain.gain.cancelScheduledValues(0);  // スケジュールを全て解除
vco0gain.gain.setValueAtTime(0.0, now);  // 今時点を音の出始めとする
vco0gain.gain.linearRampToValueAtTime(rootValue0, now + attack);  
// ▲ rootValue0までattack秒かけて直線的に変化
vco0gain.gain.linearRampToValueAtTime(sustain * rootValue0, now + attack + decay);
// ▲ sustain * rootValue0までattack+decay秒かけて直線的に変化

var rootValue1=0.8;
vco1gain.gain.cancelScheduledValues(0);
vco1gain.gain.setValueAtTime(0.0, now);
vco1gain.gain.linearRampToValueAtTime(rootValue0, now + attack);
vco1gain.gain.linearRampToValueAtTime(sustain * rootValue0, now + attack + decay);

1つ前のライブデモにエンベロープを適応させたライブデモはこちらになります。（ソースコード）

以上でアナログ・シンセサイザーの骨格が完成しました。楽器にするためには、パラメータをコントロールするスライダー、ノブ、VCOの周波数を変えて音階決める鍵盤を取り付ける作業を残すのみとなります。より個性的な音を作る場合、例えばノードグラフにVCOをもう1つ並列に追加したりすることで、更に多彩な音色を作ることが可能になりますので試してみてはいかがでしょうか。

ちなみに完成形のデモで使っているノブ、鍵盤は楽器、Audio系のアプリケーションには欠かせないカッコイイノブが簡単に取り付けられるスゴク便利なツールwebaudio-controlsというPolymerエレメント（詳しくはこちらをご覧ください）を利用して実装しています。

アナログ・シンセサイザーの実装の説明は以上になります。

Web Audio API でFMシンセサイザー

FMシンセサイザーのFMはFrequency Modulationの頭文字を取っていて、その名の通り周波数を変調して音を作り出す方法で、周波数変調と呼んでいます。（しかしながら、Web Audio APIに用意されている発振機では周波数変調ができません。よって、ここでは複数の波を掛け合わせFMシンセサイザーっぽい音を作っていることにご注意ください。本当のFMシンセサイザーを作るためには周波数変調可能な発振機の作成が必要です）
それでは、どんな音が出るか完成形のデモを試してみてください。

アナログ・シンセサイザーよりももう少し金属音的な音が出ていると思います。画面右上のプルダウンメニューにて音色も変更することができるようになっていますので、ぜひお試しください。

さて、実装に関してですが複数の発振機（Oscillator）を接続していきます。ここで、掛け合わせる側の発振機（Oscillator）をモジュレータ、その影響を受けて掛け合わされる側の発振機（Oscillator）をキャリアと呼びます。今回の実装はモジュレータとキャリアを1つづつ直列に接続し、更にモジュレータを自身にFeedbackしするような接続にします。ノードグラフに表すと以下のようになります。 少し余談ですが、モジュレータの数が増やすと接続の組み合わせによって複数の接続方法が考えられます。その接続方法の1つ1つをアルゴリズムと呼んでいます。

ソースコードをみてみましょう。（ライブデモ、ソースコード）

var ctx=new AudioContext();
var modulator, carrier;
var modulatorGain, carrierGain, feedbackGain;

modulator=ctx.createOscillator();  // モジュレータを作成
carrier=ctx.createOscillator();    // キャリアを作成
modulatorGain=ctx.createGain();    // モジュレータの振幅を制御するためのGainの作成 (1)の途中にある
carrierGain=ctx.createGain();      // キャリアの振幅を制御するためのGainの作成 (2)の途中にある
feedbackGain=ctx.createGain();     // フィードバックの振幅を制御するためのGainの作成

// 接続
modulator.connect(modulatorGain);          // モジュレータとモジュレータGainの接続
modulatorGain.connect(carrier.frequency);  // モジュレータGainとキャリアの接続
carrier.connect(carrierGain);              // キャリアとキャリアGainの接続
carrierGain.connect(ctx.destination);      // キャリアGainとDestinationの接続
modulator.connect(feedbackGain);           // モジュレータとフィードバックGainの接続
feedbackGain.connect(modulator.frequency); // フィードバックGainとモジュレータの接続

carrier.frequency.value=440;

// 値を変更
//var presetList={ "name":"Elec.Piano1", "freqRatio":[1,9], "feedback":"0", "outRatio":[99,55]};
//var freq=540;
//modulator.frequency.value=presetList.freqRatio[1]*freq;
//carrier.frequency.value=presetList.freqRatio[0]*freq; // 音階を変える
//feedbackGain.gain.value=presetList.feedback;
//modulatorGain.gain.value=(presetList.outRatio[1]/100)*1024;
//carrierGain.gain.value=(presetList.outRatio[0]/100);

// 発振機（Oscillator）を動作させて発音
modulator.start(0);
carrier.start(0);

これで発音されます。が、アナログ・シンセサイザーの時と同様にそのままの音が出るだけで面白くないので、ここでもパラメータを変更してみます。コメント化されている「値を変更」の以下7行を生かしてみます。（ライブデモ、ソースコード）
なんと、音がキラキラしてきました。さて、ではアナログ・シンセサイザーのときと同じようにエンベロープを適応してみます。ソースコードは以下になります。（エンベロープ部分のみ抜粋）

var now=ctx.currentTime;
var m_attack=0, m_decay=0.5, m_sustain=0.3, m_release=0.5;
var c_attack=0.4, c_decay=0.3, c_sustain=0.7, c_release=0.4;

var modulatorRootValue=modulatorGain.gain.value;  // Attackの目標値をセット
modulatorGain.gain.cancelScheduledValues(0);      // スケジュールを全て解除
modulatorGain.gain.setValueAtTime(0.0, now);      // 今時点を音の出始めとする
modulatorGain.gain.linearRampToValueAtTime(modulatorRootValue, now + m_attack);
// ▲ rootValue0までm_attack秒かけて直線的に変化
modulatorGain.gain.linearRampToValueAtTime(m_sustain * modulatorRootValue, now + m_attack + m_decay);
// ▲ m_sustain * modulatorRootValueまでm_attack+m_decay秒かけて直線的に変化

var carrierRootValue=carrierGain.gain.value;      // Attackの目標値をセット
carrierGain.gain.cancelScheduledValues(0);        // スケジュールを全て解除
carrierGain.gain.setValueAtTime(0.0, now);        // 今時点を音の出始めとする
carrierGain.gain.linearRampToValueAtTime(carrierRootValue, now + c_attack);
// ▲ rootValue0までc_attack秒かけて直線的に変化
carrierGain.gain.linearRampToValueAtTime(c_sustain * carrierRootValue, now + c_attack + c_decay);
// ▲ c_sustain * carrierRootValueまでc_attack+c_decay秒かけて直線的に変化

1つ前のライブデモにエンベロープを適応させたライブデモはこちらになります。（ソースコード）

FMシンセサイザーの骨格もこれで完成しました。完成形のデモではパラメータの集合に音色名をつけて選択できるようにしていますが、アナログ・シンセサイザーのときのように、ノブやスライダでパラメータをコントロールするという方法も実現可能ですので、いろいろとお試しいただくと楽しいと思います。

アナログ・シンセサイザーとFMシンセサイザーの実装を通して「Web Audio APIで電子楽器を作ってみる」をやってきましたが、印象はどうでしょう。「Web Audio APIって簡単で楽しいな〜」と感じていただけているととても嬉しいのです！

さて、それでは次のセクションでは作成した電子楽器を本物の楽器のように鍵盤から演奏できるように、MIDIの接続を説明します。

Web MIDI APIを使う

先ほど少しだけMIDIとWeb MIDI APIについてご説明させていただきました。さらに理解したいという方はDTM界隈で著名な藤本健さんの”DTMステーション”に「今さら聞けない、「MIDIって何？」「MIDIって古いの？」」というMIDIを理解するのにドンピシャな記事が公開されましたので、詳細はそちらにお任せするとしてここでは粛々と実装を行っていきたいと思います。

ちなみに2015年3月現在でWeb MIDI APIが動作するブラウザはGoogle Chromeだけとなっています。また、その使用にはフラグの変更（Web MIDI APIを有効にする方法）が必要ですので、お試しになる前にフラグの変更を忘れないようにお願い致します。（MIDIデバイスがお手元になく、Macをお使いの場合はEasy MIDI Freeをお使いいただくと演奏できるはずです）

コンピュータに接続されているMIDIデバイスをブラウザで取得するには以下のコードを書き、MIDI InputとOutputのデバイスリストを取得します。

var inputs, outputs;
navigator.requestMIDIAccess.then({sysex:true})(successCallback, errorCallback);
function successCallback(midiAccess) {
  var inputIterator=midiAccess.inputs.values();
  for(var o=inputIterator.next(); !o.done; o = inputIterator.next()) {
    inputs.push(o.value);
  }
  var outputIterator=midiAccess.outputs.values();
  for(var o=outputIterator.next(); !o.done; o = outputIterator.next()) {
    outputs.push(o.value);
  }
}

MIDI Inputを使う場合、例えば使いたいMIDI Inputデバイスがinputsの先頭にリストされた（index=0）とします。その場合は以下のようにイベントハンドラをつけてあげます。

inputs[0]=function(event) {
  console.log("[MIDI Message] " + event.data + " [Timestamp] " + event.timestamp);
}

こうすることで、inputsの先頭にリストされている外部MIDIデバイスからMIDIメッセージが飛んできた場合にMIDIメッセージとタイムスタンプをコンソールに出力するようになります。

MIDI Outputを使う場合、例えば使いたいMIDI Outputデバイスがoutputsの先頭にリストされた（index=0）にあったとします。

outputs[0].send([0x90, 0x45, 0x3f], performance.now()+0);

とすると、outputsの先頭にリストされたMIDIデバイスに対して0x90, 0x45, 0x3fというMIDIメッセージを今すぐ(第２引数)送信します。MIDIメッセージ0x90, 0x45, 0x3fは、A4の音（0x45）を、50%の音量（0x3f）でチャンネル1を音を鳴らしなさい(0x90)、です。

といっても、MIDIに慣れ親しんでいない場合は実装のハードルが高いと思っています。そこでWeb MIDI APIの実装を簡単にするPolymerエレメントを公開しています。それが、 x-webmidiです。x-webmidiを使うとHTMLタグを5つ追加する（そのうち1つはWeb ComponentsのPolyfill）だけで、コンピュータに接続されているMIDIデバイスを取得して、セレクトボックスを生成して表示する、までを行ってくれます。MIDI InputデバイスからのメッセージはEventハンドラを、またMIDI Outputデバイスへのメッセージの送信は.sendRawMessage()を使い生のMIDIメッセージを、.sendHRMessage()を使いMIDIに慣れていない方でも分かるようにメッセージを送信できるようになっています。コードにするとこうなります。

<script src="path/to/webcomponents.js"></script>
<link rel="import" href="x-webmidirequestaccess.html">
<x-webmidirequestaccess sysex="true" input="true" output="true"></x-webmidirequestaccess>
<x-webmidiinput id="midi-input"></x-webmidiinput> 　　// MIDI Inputデバイスのセレクトボックスを表示 
<x-webmidioutput id="midi-output"></x-webmidioutput> // MIDI Inputデバイスのセレクトボックスを表示

// MIDIメッセージを受信する
window.addEventListener("midiin-event:midi-input", function(event){
    // MIDIノートナンバーと、対応する周波数をConsoleに出力
    console.log("[noteNumber] "+event.property.noteNumber+" [frequency] "+event.property.frequency);
});

// outputsの先頭にリストされたデバイスにMIDIメッセージを送信する
var outputs=documenet.getElementById("midi-output");
outputs[0].sendHRMessage("noteon", 0, ["d4", 127], performance.now()+0);

それでは、Web Audio APIで作ったシンセサイザーを、MIDIデバイスから操作できるように実装していきます。演奏するためには、音階を変えるのですが、そのためには発振機（Oscillator）の周波数を変更する必要があります。MIDIの鍵盤は1つ1つに連番の番号がついていてこれをMIDIノートナンバー（ノートナンバーでページ内を検索）と言いますが、そのMIDIノートナンバーから周波数に変換する必要がありますが、それをコードにすると以下のようになります。

var freq=440.0 * Math.pow(2.0, (noteNo - 69.0) / 12.0); // noteNoはMIDI鍵盤の鍵盤番号

しかし、x-webmidiを使うとEventの引数として演奏した鍵盤の番号とそれに対応する周波数が取得することができるので、MIDIノートナンバーから周波数の変更をする必要はありません。これらをアナログ・シンセサイザーとFMシンセサイザーに実装をするとこのように実装できます。

• （単音）アナログ・シンセサイザー：ライブデモ（ソースコード）
• （単音）FMシンセサイザー：ライブデモ（ソースコード）

でもこのままだと単音しか出なくて楽しくないので、和音も出せるようにしちゃいます。そうするとこうなります。

• （和音可）アナログ・シンセサイザー：ライブデモ（ソースコード）
• （和音可）FMシンセサイザー：ライブデモ（ソースコード）

自作した楽器を両手で演奏できちゃいますよね。立派な楽器のできあがりです！「Web Audio APIとWeb MIDI APIを接続するのって簡単で楽しいな～」と感じていただけているととても嬉しいのです！

番外編

2015年3月13日（金）にWeb MIDI APIはGoogle Chromeにおいて実験的APIから標準のAPIとなることが承認されました。これによって、フラグを変更することなく（これが不要になる ▶ Web MIDI APIを有効にする方法）、Web MIDI APIを利用することが可能になります。この変更がChromeに適応されるまでにはもう少し時間がかかりますが、実現するとWeb MIDI APIがChrome APPsでの利用も可能になります。（Chrome Appsとは：英語）Chrome Appsにしてしまえばオフラインでも利用可能※4になります。ですので、ユースケースとして例えばライブでWeb Audio API、Web MIDI APIを使った自作楽器でパフォーマンスを行いたい、という場合に活躍してくれることでしょう。

そこで、今回ご紹介した2つのシンセサイザーをChrome Appsにして公開してみました。（Web MIDI API部分の動作はしません：2015年3月14日現在）

• アナログ・シンセサイザー
• FMシンセサイザー

細かいところですが、Chrome AppsはCSP（Contents Security Policy）によってスクリプト（JavaScript等）をHTMLファイルへインラインで書くことが禁止されていますが、これら2つのアプリにはPolymerエレメントを使っています（インラインJavaScirptが書かれたHTMLファイルです）のでちょっと困ったことになります。それを解決してくれるBuildツールにvulcanizeがあります。”csp”オプションをつけてツールを実行することでHTML部分ととスクリプトを分けてくれますので、ソースコードの変更なしにCSPに合致したソースコードを生成することが可能なのです。

$ vulcanize --csp -o build.html index.html

Google Chromeのフラグの変更なしにWeb MIDI APIの利用が可能になることで、Web Audio API、Web MIDI APIを使ったブラウザで作った電子楽器の使えるシーンがより拡大されることを期待しています。manifest.jsonとバックグランドで動作させるJavaScriptの2つのファイルを用意することで簡単に実現できますので、ぜひ試してみてください。

おわりに

いかがでしたでしょうか？Web Audio APIで用意されている発振機（Oscillator）は正弦波、ノコギリ波、矩形波、三角波の基本的な波形しかなく、それ単体では単調な音しか出なかったのが、少し波形処理をしてあげることで楽器らしい音にすることができたと思います。さらにはWebブラウザに鍵盤をつなげると、和音まで演奏できるようになってしまいました。

さて、自作で楽器が開発ができるのはWebブラウザが初めてでしょうか？いえ、そんなことはありません。Windows、Mac、Android、iOS等の所謂Nativeな環境でも開発することは可能でした。では、Webブラウザで開発できるようになった利点はなんでしょう。それは楽器を開発するということに対するハードルが一段と低くなったところです。WebアプリケーションはWeb標準言語で開発します。Web標準言語の開発はブラウザとテキストエディタで行います。ですのでコンピュータを買ってきたその日から開発が可能です。さらにご説明させていただいた通り、こんなにも簡単に楽器を開発することができるのです。

今までは難しそうなイメージがあった音楽を使ったアプリケーション。しかしWeb Audio APIを使うと音を作ることができます。またWeb MIDI APIを使うと外部のMIDIデバイスとの双方向の操作が可能です。開発するWebアプリケーションに音を鳴らす要素を追加してみる、または遊び心でMIDIデバイスからWebアプリケーションを操作してみる等、ほんの少しの遊び心があなたのWebアプリケーションをより面白くする可能性があります。これを機会にいろいろなとことで試してみてはいかがでしょうか？

セッションの資料と動画

2015年1月25日に行われたHTML5 Conference 2015の当日の資料と動画へのリンクです。こちらも合わせて御覧ください。

動画

スライド