マイコン・インフィニット☆ひなまつりPRO-68K 告知

悪友イモリに誘われてマイコン・インフィニット☆PRO-68Kにイモリプロダクション名義で参加します。

・日時：2017/03/12(日)
・場所：秋葉原 UDX GALLERY 4F
●第一部 展示・即売会　13:00～16:00
￥1,000- (高校生以下無料)
●第二部 懇親会・講演　16:30～18:00
￥4,500- (事前予約制・締切りました)
※第一部から通しで入場できます。

だそうです。

展示はイモリと僕とで絶賛準備中なわけですが、ひとまず僕の方から出す予定の物を紹介したいと思います。

CP/Mega88 - AVRで動作するCP/M

だいぶ古いネタで恐縮ですが、2009年から2010年にかけて制作したATMEGA88上で動作するCP/Mエミュレータです。エレキジャック・フォーラムで発表させて頂き、それなりに好評だったようです。当時、FPGAによるレトロPCの再現が流行っていたわけですが、本業が論理設計だった私は、敢えてマイコン1つでCP/M互換機を再現するという暴挙に出ました。

スライドのセンスが7年間変わっていなくてショックです。

Applerm II - ARMで動作するApple II BASICでLチカ

同じコンセプトでApple IIをLPC1114ワンチップで実装したもの。こっちはもっと最近の制作です。本来Apple IIはシリアルコンソールで動作するようなものではないのですが、VRAMの動きをトレースしつつ、シリアル端末情報に変換しています。画面スクロールとかの検出が大変だった。Apple IIのI/OにLPC1114のGPIOをマップしてあげているので、BASICからのPOKE命令でLチカできます。

4KBしかRAMがない中で、本来それより大きなRAMを必要とするBASICを動かすには、結構な黒魔術が必要でした。



雑誌の付録になっていたMARY-MB基板を使った動画もあります。

MegaZ-80K - AVRで動作するMZ-80K

CP/Mを作った後に、次はビデオ出力込みで何か作れないかな、という事で制作。4個のAVRを使ったヘテロマルチコア構成。ビデオ出力はATMEGA328が担当。RAMの大部分をVRAMとして使いつつ、クロック数えながらビデオ信号を生成しています。Z80エミュレーションはATMEGA644上で行っており、必要に応じてVRAMへの書き込みをフォワードするわけですが、書き込み可能な期間がVSYNCの間だけに限られているため、ATMEGA328との間にバッファとしてATTINY2313を挟んでいます。このチップはサウンドエミュレーションも兼任しています。また、キーボード代わりのファミコンコントローラ制御に別途ATTINY2313を1つ使っています。これらのチップは共有バスを通じて通信します。USARTベースの独自仕様。

SoundCortex - 80円で再現したPSG+SCC音源

Qiitaで何回か記事を書いていますが、（当時）80円のLPC810というARMを使ったPSG+SCC音源モドキです。I2Cで制御できるのがポイント。

今回はRas Pi上で動作する魔改造MSXエミュレータを通しての演奏デモを予定しています。写真のようにSDスナッチャーのオープニングを流す予定。

YouTubeにはGRADIUS 2を演奏するデモもあります。

今回このファームウェアを焼いたLPC810を持ち込み、実費＋α（というか、送料考えると赤字）の100円で配布しようかなぁ、と思っています。実際に遊んでくれるユーザーを増やしたいので。まぁ10個くらいですかね。

SION2HD - X68k用ゲームをHTML5でHD化

X68k用のシューティングゲーム、SION2を最新の技術を駆使してウェブ上で動くようにしてみました。しかもハイレゾ化やステレオ表示といった謎の拡張が施されています。

実際に遊んでもらう方が早いかも。bit.ly/sion2で遊べます。また、黒魔術の詳細については以下のスライドで説明しています。

第2回html5jゲーム部勉強会 Oh! JavaScript 夢の続きを語ろうよ〜emscriptenの逆襲 - html5編 from Takashi Toyoshima

Chrome 43 beta with Web MIDI

こちらでもアナウンスしたのですが、大切なことなので日本語でも言っておきますよ。しかも、もっと詳しく。

最新のChrome BetaでWeb MIDI APIが標準でサポートされるようになりました。このAPIはAndroid版と全てのデスクトップ版Chromeで利用可能になります。

MIDIはご存知の通り30年以上の歴史を持つ古い規格。よくSMFと混同されがちなのですが、音楽ファイルというわけではなく楽器同士の通信プロトコルです。その通信内容を時間情報とともにダンプしたファイルがSMF。演奏情報を記録する事でカラオケや着メロの楽曲データとして利用されてきた経緯もあり、その印象から（チープな音で演奏される）音楽ファイルとして誤解されがちですが、あくまでもそれは一応用、という事で。

なんでそんな古いものをまた……と思ったそこのあなた。Webも25年近い歴史を持つ古い技術です。垣根を超えてつながることで発展してきた、という意味ではどちらも似た志を持っており、絶妙な割り切りが的を得て発展・成功した仲間です。ここでこの2つが分野を超えて繋がることで新しい応用が広がるかと思うと、なんかワクワクしませんか？

Web MIDI APIはJava ScriptからMIDIの入出力を可能にするAPIです。具体的には電子ピアノやシンセサイザーなどのキーボード類、電子ドラム、あるいはDJ機器からの入力を受け取ることが出来るようになります。一方で、各種電子楽器に対して演奏情報や設定情報などを送信することが可能になります。これにより

• 電子楽器の音色管理ソフトウェアをWeb上で構築
• サイトを通じて自動演奏ピアノに曲を提供
• Web Audioなどで作られたソフトウェア音源をキーボードから演奏
• 演奏情報をWebからリアルタイム配信
• Web GLなどを使って作成したVJソフトを演奏情報に同期させる

などがWeb標準技術を用いて実現可能となります。すでに多くの開発者がソフトウェア音源を作ったり、DAWソフトを作ったりしていますが、これからも多くの応用が生み出されていくと期待しています。

今現在ではWeb Audioの実装で先行していたChromeのみがWeb MIDI APIをサポートするブラウザとなっています。が、仕様はW3Cで標準化されており、同じくWeb Audioの実装を持ったFirefoxも開発を進めているところです。IEは今まさにWeb Audioの対応を進めているところであり、今後に期待と言ったところです。

Web Music Platform 魔改造

YAMAHAさんのWeb Music Platform。
bower使ってmodule化されつつあり、自分のモジュールを追加した魔改造もしやすくなってきてます。とりあえず自分の方でもtssやtmalibなんかをPolymer化、bowerで突っ込めるようにして、2つばかりVisualizerとして追加、さらにHerokuにdeployできるようにした魔改造版を作ってみました。

実際にdeployしたデモはこちら。

そう言えばHeroku、ここ2ヶ月くらいで変な最適化が入ったのか、謎な挙動をしますよね。例えばpostinstallのスクリプト中にgit cloneしたリポジトリから特定のrevisionをcheckoutしようとすると、そこはrepositoryじゃないよ、的な事を言われてcheckoutできない。Google Codeからだとbranch作ってbranch直指定でcloneする以外に解決方法見つからなかった。GitHubの場合はtagを切ってないモジュールをbowerでinstallしようとしても、同じように怒られる。さらにbowerが途中でエラーするとbuild directoryから最終的なdeploy先にbower_componentsの中身がコピーされない？　こっち系はあまり詳しくないので、詳しい人がいたら対処法というか裏で何が起きてるのか教えてもらえると嬉しいです。というか、今日ささださんとお昼食べるから聞いてみれば良いのか。

それはそうとscript tag injectionとかXHR、そのままだと並列読み込みとか扱いが面倒なので、Promise化してPromise.allで一気に待つようにしてみたら結構お手軽に高速化できた。もうPromiseなしでは生きていけない。

ニコファーレ完結編

イベント終了。突貫工事だったけど、なんとかそれなりに仕上げることができたかなぁ、と。イベント中はプロの映像制作屋さん・オペレータの2名と一緒にLED照明卓に張り付いていたので、プロの作業を仕込みの段階から長時間見ることができたのが何よりの収穫。

作った素材的にはこの辺にあるモノ＋αの15種類くらい。3chのミキサーをMIDIコントローラから制御できるようにしたホストアプリをtmalib上に構築してました。今回のために書いたコードは175 commitsにわたり、コード量も倍増。
% git log -p --full-diff --since Aug | wc -l
23742
だそうです。

Tell Your Worldのステージ中に使った素材の一部

ライブラリ実験用に作った3D版Waypointsがパラメータを変えるだけで色々と使いまわせたのは助かったです。特に直前に追加で作ることになったエンドロールとかは数時間しか作業できなかったので……。フォントからテクスチャ作るライブラリ工事だけで時間切れになっちゃった感じ。

本番のエンドロールはMichael Jackson版Behind the Mask

で、色々と見つかった課題。

• 自分の作ったライブラリで一番まずかった点はミキサーのフェーダ。うかつにも線形に作ってしまったけど、どう考えても対数で作るべきだった。コードばかり書いてて操作をあまりやってなかったので気付かなかった。
• 機能として足りなかったのはプレビューと速度調整。プロの現場だと、次に使う絵をプレビューで先出ししてて、ステージ上の音楽に合うように映像のループ位置や速度を調整して、ここからって場所が来たら瞬時に切り替えて使う。DJアプリと一緒ですね。今のフレームワークでもタイムラインはきちんと管理してるので、UIさえつければすぐにでも動く。けど、性能的にプレビューまで出すのはちょっとキツイ。本番ではFull HDで生成・出力をしていたけど、エフェクトを重ねてると現状でも30fpsに落ちることがあった。そもそもコンソールと外部出力、複数のウィンドウに対して、同じタイミングで絵を送るのがちょっと難しそう。Web Music Hackathonの打ち上げでも話題に出てたけど、それこそOS XのSyphonみたいな仕組みが欲しくなってくる。
• シェーダーのコンパイルに数百msec必要で、その間requestAnimationFrameが届かなくなるため、エフェクトのダイナミックなロードが難しい。フレーム落ちを避けようとすると、基本的に曲の頭で色々なリソースを先読みする事になってしまい、メモリ消費が激しくなりがち。ちなみにこのアプリは起動時に500MB以上食ってたし、デバッグ時には作業しているうちに2GB付近まで増えてタブ落ちする事も。

でもまぁ、ウェブアプリベースで本格的な照明制御を行う実験としてはまずまずかな。思いついた事を全てやるには圧倒的に時間が足りなかったけど、まずまずは満足。

ニコファーレ続き

この週末はコントローラ周り、サウンドからのFFT入力、シーケンスをプログラムするためのライブラリとか用意してた。だいぶTODO潰したけど、まだスケジュールきつい。

昔2D向けに作ったWaypointsを3Dに拡張。ポイントスプライトとして頂点計算しつつ、フラグメントシェーダで火球っぽく描く方法を試してみた。点を打つだけなら10万パーティクルくらいいけそうだったんだけど、ポイントサイズが大きくなってくると1万くらいで厳しくなる。空間が広いので1万パーティクルくらいだと結構スパース。

こっちは前に作ったキューブが飛んでくる奴。ワイヤーフレームで表示するモード作って、エフェクトでぼかしてみたら結構かわいくなった。

あと、関係ないけどherokuにデモdeployする時、postinstallの中でライブラリをクローンして特定のリビジョンをチェックアウトという処理をしてたんだけど、チェックアウトの段階で.gitが空とかいうエラーに遭遇。前は動いてたんだけどなぁ。とりあえずbranch作ってgit clone -b で逃げてるけど、なんか不便だ。

Web MIDI API - the past, the present, and the future -

Web Music Meetup #1で発表したスライドを公開しました。Chromeでの実装についてのまとめです。今までHTML5についてはWebSocketとWeb MIDIについて関わってきましたが、どちらもメディアアート系の人たちに気に入ってもらえているのが嬉しいです。

Web MIDI API - the paster, the present, and the future -

3Dラインアート

引き続き、制作の敷居を下げるためのライブラリを開発中。今回は3次元座標を引数にした描画関数を用意してあげて、その関数からの描画がニコファーレ全面ディスプレイに自動展開されて描画される、というもの。と言っても本来は立ち位置によってディスプレイに表示される内容は変化しないといけないので、今回はホール中央から見れば歪がないというのを条件にしてる。まぁ、勢いあれば多少の歪みは気にならないという事で。

ニコファーレのシステムに送る画像はこんな感じの展開図

ホール中央から右前を見た視点をレミュレートした出力

シミュレーション上は、ディスプレイの外枠が見えなければスクリーンの境界がまったくわからないくらい綺麗に繋がって見えている。もしかしたら高さ方向の調整はまだ必要かも。視点の高さがスクリーン中央にあることを想定してるけど、実際には結構見上げる感じだった気がするんだよなぁ。

実際に表示できるでもページはこちら。流石にWeb GLを大量に埋め込むとトップページから開いた時に破綻しそうなので。キー操作は「x」「f」「h」「j」「k」「l」。

例によってGLSL Sandbox用のシェーダーを流用

とりあえず流用できる状態にしておけばネタに困ることのないGLSL Sandbox。って事で、今回もさっそく互換フレームを用意してみた。ここからが先が創作っぽくなる部分で、得意ではない部分。……がんばる。



例によって「x」キーで会場エミュレーションモードと展開画面出力（本番用出力）の切り替え、エミュレーションモードでは「h」「j」「k」「l」で視点移動ができます。大画面版は下の画像をクリック。「f」で全画面になり、ディスプレイが1920x1080になっていれば、そのまま本番に入れるデータが出せます。Full HDでうねうねするには、それなりのGPUが必要かも。



※そう言えば、Chrome以外で全く動作確認してません。自分用のツールで時間的余裕もないので……。

ニコファーレ

ニコファーレには結構面白い照明設備があるんだけど、利用価格がお安くない……って事で遊ぶには敷居が高めです。で、今回ちょっと訳あってこの設備向けの作品を作ってるんだけど、フォーマットが特殊。かつ資料だけだと不明な点もあったので会場見学に行ってきました。で、とりあえず現地でのキャリブレーションと本番までの出力確認用に作ったのが下のプログラム。



「x」キーで会場エミュレーションモードと展開画面出力（本番用出力）を切り替えられて、エミュレーションモードでは「h」「j」「k」「l」で視点移動ができます。大画面版はこちら。このシミュレーションモードで出力確認しておけば、本番になって「あれ？違うじゃん」みたいな間違いがなくなるってわけです。

E/Fのスクリーン位置が資料では不明だった点。これらは奥から200pxの位置にあることを確認し、シミュレーションにも反映させました。担当さんの話によれば、これらのスクリーンは移動可能で、取り外すこともできるそうです。ただしステージの袖が見えちゃうので外すのはお薦めではない模様。当日に想定外の位置に設置されていた場合、言えば移動してもらえるそうだけど、基本はこの位置のはずだと言っていました。あと、豆知識としてこの2枚のスクリーンだけは他より2フレームだけ遅延が少ない（早く表示される）そうです。こだわる場合には注意が必要。

天井はスパースなんですよね。同じサイズのLEDが広い間隔で並べられているだけなので、本来あるべき画素サイズと比較すれば、密度（明るさ）は大雑把にはわかります。ただ、LEDのメーカーが違うために天井だけ発色がちょっと青みがかっている。この辺も適当ですがパラメータとしては反映させてます。

って事で、しばらくは久しぶりにGPUをいじり倒す感じ。最近のマシンって新しいからってそんなに体感に影響はないんだけど、GPU触りだすと流石に全然違いますねー。

続・ChromeにおけるWeb MIDI APIの実装状況

昨年末にWeb MIDIの実装状況について書かせて頂きました。その後の更新状況についてまとめたいと思います。

Chrome 34

• Linuxサポート（ALSAをサポートするシステムのみ）
• Androidは出力のみ対応（ただし、初期化手順の問題で最初の呼び出しは失敗する）
• リアルタイムメッセージのサポート
• システムメッセージ（sysexではない）はパーミッションなしで送信できるように修正
• 送信メッセージにエラーがある場合、詳細情報がエラーメッセージとして書き出されるようになった
• パーミッション許可を求めるinfobarが file://... に対しても表示されるようになった。ただし、セキュリティの都合上、許可・不許可は記憶されない。
• Windowsでtimestampが間違っていたのが修正された

Chrome 35

• PromiseがWeb MIDI向けの機能限定版から、フル機能版に差し替えられた
• Chrome OSサポート
• Androidの入力サポート（初期化手順の問題は未修正）
• OS Xにおいて送信されるMIDIメッセージにCore MIDIのtimestampが正しく付加されておらず、Chromeから送信されるデータをDAWで受信すると、正しいタイミングで録音できない問題が修正された
• MIDIAccess.sysexEnabledアトリビュートが追加された

Chrome 36

• Androidの初期化手順の問題が修正された

Chrome 37（予定）

• LinuxとChrome OS向けの実装が改善された（ALSA sequencer APIに対応）
• Android向けのUI実装完了（infobarと設定画面）

追記：Chromeで実装しているAPIは最新版と若干異なります。最新の使用に合わせて近々更新する見通しですが、それまではこちらの旧APIを参照願います。またMIDIConnectionEventの実装も新APIになるまで見合わせています。

For English readers;

I'd summarize Web MIDI implementation status on Chrome. I also did it at the end of the last year, but in Japanese. So, I'd mention also previous status together.

Chrome 30

• chrome://flags#enablr-web-midi appeared on OS X
• Input ports were available on OS X, but there was a bug on sysex until Chrome 32

Chrome 31

• Output ports were also available on OS X
• Infobar and settings UI were implemented as a part of content settings

Chrome 32

• IAC driver was available

Chrome 33

• Web MIDI worked on Windows, but had wrong timestamp values

Chrome 34

• Web MIDI worked on Linux (but only ALSA supporting systems)
• Also, worked on Android, but only output ports are available
• There was a problem on initialization process, so the first API call didn't work on Android
• Real-time messages were available from this version
• System messages were available without a sysex permission from this version (previous versions required a sysex permission even for system messages)
• Error provided detailed messages on invalid send messages
• Infobar appeared even on local files, but browser could not remember the permission because of security reason
• Wrong timestamp was fixed on Windows

Chrome 35

• Now, Promise is not limited version Promise, MIDIAccessPromise, but fully featured proper Promise
• Now the API is available on Chrome OS
• Input ports are available on Android, but the initialization issue is not fixed yet
• Fix a bug that sending messages had wrong CoreMIDI timestamp and caused a problem that DAW could not record Chrome sending messages with correct timestamp
• MIDIAccess.sysexEnabled attribute is added

Chrome 36

• Android initialization issue will be fixed

Chrome 37 (planned)

• Linux and Chrome OS supports will be improved so to support ALSA sequencer API
• Infobar and settings UI for Android will be implemented

Note: The implemented API is slightly different from the latest W3C spec. You can see the old specification here. Also, MIDIConnectionEvent is not implemented yet. It will be available once new API is ready.

プロジェクション・マッピングとフラグメント・シェーダ

先日、ライゾマティクスさんのワークショップでプロジェクション・マッピングについて教えてもらいました。その際利用したmapamokが、投影データはフラグメント・シェーダで描く（キリッ）って内容だったので、頑張ってシェーダ書きました。近頃はシェーダは（僕の中では）Java以上にポータルなわけで、せっかくなのでWebGL上で動かしてみました。一応、Chrome、Safari、Firefoxで表示できてると思います。

モデルデータはかにひらさんが配布していた物を利用させて頂きました。ただ、元データはメタセコイア形式だったので、ply形式に変換して使ってます。

plyローダ作ったついでに、いくつか有名なデータを読み込んでみたんですが、100万ポリゴンくらいになると辛く、Happy Buddhaは描画レートが数フレームくらいまで落ちちゃいました。このくらいは平気だと思ってたんだけど・・・あまり詳しく原因見てませんので、別に理由あるかも。同僚はミクとか普通に動かしてたし。