「Spark project 勉強会 SP3」活動報告

2010年6月13日、Adobe Station 5にてSpark project 勉強会 SP3が開催された。本稿では、本勉強会のレポートをお届けする。

Spark project 勉強会は不定期に開催されており、今回は久しぶりの開催となった。

今回はSpark projectのコミッター9人が発表した。発表者はSpark project代表の@beinteractive氏が制作した、ルーレットによって選ばれた。このルーレットはFlashが乗っていないIPadで動作し、AIR2.0で強化されたServerSocket APIを用いてHTTPサーバーを建て、そのレスポンスによって発表者を決めるというSpark projectならではのGeekな手法が採られた。

Flash Player 10.1でmicrophoneはどう変わったか。

そんなルーレットで選ばれた一人目は@kappaLab氏。Flash Player 10.1で強化されたMicrophoneに対するサポートについて詳細に解説した。

Flash Player 10まで、マイクに対するサポートはアクセスと音量操作のみだった。それが10.1では、音声入力データの取得と加工になったのだ。これにより、録音/再生/保存などのいわゆるボイスレコーダーがRed5(FMSクローン)に頼ることなく、Flashだけで実装できると示した。

また、エフェクトやフィルター処理をかけることで、ライブやカラオケのような効果が得られると言及し、カラオケでエコーが掛かったような"リバーブ"、ある特定帯域をカットする"レゾナンス"のといった効果のデモを行った。

最後に、Flash Playerのみで音声認識のデモを行った。氏は「今回のサンプルは自分の声帯にあわせたもの。個々人にあわせたチューニングをすることでもっと面白いものが作れるのではないか」と述べた。

図1 @kappaLab氏のプレゼン
画像 画像

Androidで遊ぼう

2人目は@daoki2氏 。氏は、AIR for Androidに関して詳細に解説した。

氏は、通常のAIRランタイムではandroidアプリ同士を連携するintentがサポートされていないため、それを克服するためにAVM(ActionScript Virtual Machine)の自作を決意。AdobeがMozillaに寄贈したスクリプトエンジンTamarinを使用して独自にビルドしたという(しかし現在、Tamarinはビルド環境としてSnow Leopardがサポートされていないため注意が必要とのこと⁠⁠。

デモでは、実際に動いているAndroidアプリケーションを紹介した。ボタンなどのGUIはAndroidネイティブのものを使用していることに言及し、⁠AIR for Androidには、まだモバイル用のWidgetがないため、GUIをすべて自前で用意しないといけない。デスクトップ用のFlexコンポーネントは重すぎるので、Adobeが推奨していない」と述べた。

AndroidのネイティブWidgetを使用することで、ほかのAndroidアプリと全く同じ使用感で扱うことができ、ユーザーライクにアプリケーションを組むことができるという。ただ現状はprelereaseということもあり、開発のハードルはまだ高いようだ。

氏によれば、⁠ASとJAVA両方のデバッグが必要になるため、デバッグがやりにくい。こんなめんどくさいことするなら、最初から最初からJAVAでもいいのではないのか」と苦言を呈したが、intentのサポートも含め、これらは今後Adobeによって改善されるものと願いたい。

図2 @daoki2氏による、AIR for Androidのデモ。ボタンはAndroidネイ ティブのものを使用している

画像 画像

AIR 2.0で遊んでみた

3人目は@ll_koba_ll氏。氏は、AIR 2.0で追加されたNative Processを使ったデモを披露した。

pingを送受信するシェルスクリプトをNative Processで実行し、その結果が出力された。また、その応用としてAIRアプリで特定ディレクトリ下にある.svnファイルを削除するアプリも紹介した。

氏は、openWithDefaultApplication()メソッドについても解説した。これは指定したファイルを関連づけされたアプリで開くことができるもの。デモでは、AIRアプリからJSFL(Flash Professionalの基本操作をJavaScripで制御できるAPI)を実行し、パブリッシュを行った。

最後に、MacBook Proのキーを叩くとFlash Playerのダイナミックサウンドによって音を生成、音楽が奏でられるサンプルをデモ。氏は、⁠ライブコーディングの時にプログラムを書いてる際、音楽が奏でられるような何かを作りたかった」と述べていた。実際、キーを叩いているだけでもパラメータ次第では、それっぽい音楽を奏でることができるようだ。

AIR 2.0の新機能はそれのみで完結するものではなく、相乗効果によって新たな可能性を開くことができるということを証明するデモだった。

図3 @ll_koba_ll氏
画像

JSFL for Flash Professional CS5

4人目は、本稿の著者である@KaedeASから、Flash Professional CS5で追加実装されたJSFLのAPIについて解説した発表資料はこちら⁠。

デバッグ周り、そしてタイムライン操作に関するAPIが追加されたが、そのひとつ、モーションスパンの長さを設定できるframe.setMotionObjectDurationメソッドのデモを披露した。これは、ショートカットで手軽にモーションスパンを設定できるもの。JSFLの利点はFlashにない、ちょっとした拡張をすぐに実装できる点にあるだろう。

また、Flash Professionalから、Antタスクの実行するJSFLを実行するデモを披露した。Antはビルドツールのひとつで、ソフトウェアのコンパイルやパッケージに用いられる。Flashと連携することで、パブリッシュ後ファイル群をzipし、特定のディレクトリに移動、FTPにアップロードといったことが全自動で行えるようになる。

これら2つのデモは後日、Spark projectにコミットする予定だ。

コンパイル速度高速化のためのTips

5人目は@clockmaker氏。氏は、Flash CS4とFlash CS5のコンパイルに関する検証を発表した発表資料はこちら⁠。

氏によれば、Flash CS4はコンパイルが遅く、一般的に高速になると言われているSWCを利用したコンパイル手法でも、Flash CS4では108秒、CS5ではたった4秒で完了することを説明した。筆者的にはこれだけでもFlash CS5を購入する価値があると思ったが、氏によればこの恩恵はSWCによるコンパイルの時のみで、実ソースコードからのパブリッシュはむしろCS5のほうが遅いと指摘した。

また、氏はFlex SDKのfcshによるコンパイル手法についても解説した。この方法は、コンパイル後キャッシュされるため、コードが数万行も書かれているプロジェクトでもかなり高速にコンパイルすることができ、Flash Professioanlを利用したコンパイルよりも断然早いことが特徴だ。

今後、Flash CS5で素材やアセットをSWCにした上で、fcshを利用してコンパイルするといった手法が主流になるのではないだろうか。

図4 @clockmaker氏
画像

AIR 2.0がリリースされたのでNative Processと戯れる

6人目は、@alumican_net氏。氏はAIR 1.0-1.5の個人的な感想として、⁠AIRアプリからexeを実行できない」⁠多言語のライブラリを取り込めない」⁠ライトなウィジェットにはよい」と言及し、⁠パワー不足が否めなかった」と辛口に評価した。しかし「AIR2.0頑張った」と一転して賞賛。これには会場も笑いに包まれた。

デモでは、Native Processを利用したランチャー、そしてAIRとOpenCVの通信のサンプルを公開した。AIRとOpenCVを通信するのデモは、WEBCamによって得られた映像の上に顔認識でアイコンを重ねるというもの。元来、Flashは重い処理には不向きであり、顔認識などの高負荷な処理をそれが得意なネイティブアプリケーションに任せることで、高速化が実現できる。

また、氏はPTAMを利用したマーカーレスのAR実現を目指しているようだ。これが完成すればFLARToolkit同様、大きな反響を呼ぶことになるだろう。是非期待したい。

図5 @alumican_net氏による、AIRとOpenCVを通信するのデモ
画像 画像

JSFLを何で書くかについて

7人目は、@flabaka氏。氏は屈指のJSFL使いとして著名で、Flash ProfessionalのJSFLエディタは使いづらいとコメント。特に、コードヒントが出ないことを欠点として、シェアの高いActionScriptエディタ「FlashDvelop」でJSFLを扱うプラグインを開発。これをデモした。

JSFLはJavaScriptを用いる。JavaScriptは型のゆるい言語のため、コードヒントの実装は難しいとされている。まだ開発中ということだが、完成が楽しみなプラグインだ。

Flash CS5ではActionScriptエディターにカスタムクラスコード補完がつくなど、よりFlash Builderライクになって完成度が非常に高い。しかし、JSFLエディターはCS3から手つかずの状態だ。筆者的にも、Flashの次期バージョンではぜひJSFLのエディターにも手を加えていただきたいところである。

図6 @flabaka氏
画像

Sound and ...

8人目は、@beinteractive氏発表資料はこちら⁠。Spark projectの代表をつとめ、世界的にも著名な氏曰く、⁠いま、音があつい」という。

氏は、マイクから取得した音声データにトゥイーンをかけるデモを実演した。⁠あー」と話すだけで、ゲームの効果音のような面白い効果が得られることに、会場は驚いた様子だった。

デモの解説では、⁠音声からの波形データは結局数値の集まりであり、動画やタイムラインを操作するのと原理的には変わらない」とコメント。これらのソースコードも、Spark projectで公開されるので、コミットされた際には是非中身をのぞいてみると面白いだろう。

図7 @beinteractive氏による、音声データにトゥイーンをかけるデモ
画像 画像

AIR 2.0でマルチタッチ

最後は、@alternadotin氏。氏は、AIR 2.0で実現するマルチタッチを解説。氏によれば、⁠マルチタッチは取得は簡単だが、管理が大変」として、管理を楽にするクラスを開発したという。氏が開発したMultiTouchSpriteは、当初はとても重く使いにくいものだったが、改めて開発し直し、ArrayをVectorに、dispatchEventは使わない、newはあまり使わないなど、ボトルネックになりやすい部分を徹底的に改善したという。

デモでは、マルチタッチとBox2Dの掛け合わせたコンテンツ、そしてマルチタッチで画像にズームブラーを掛けるといったサンプルを紹介した。

氏は最後に「Flash Player 10.1はインプットがあつい!」とし、⁠GPSやマイクや加速度など、インプット周りがあつくなっているので、おもしろいものが作れるのでは」とコメントした。

図8 @alternadotin氏による、ズームブラーのデモ
画像 画像

まとめに代えて。Flashの進むべく道

久しぶりの開催だったが、やはりSpark projectらしく、DEEPでGEEKなデモと刺激的なプレゼンテーションだった。

AIR 2.0によってアプリケーションとしての幅が大きく広がったほか、じわじわと浸透しつつあるスマートフォンに対応するAPIもでてきた。今、Flashは大きな転機にきているといえる。その行方は少なからず、開発者にも掛かっているだろう。⁠これからもFlashを盛り上げていきたい」そんな熱意が感じられるSpark projectだった。

なお、当日の様子はUstreamにアップロードされているので、ぜひ閲覧してみてほしい。

おすすめ記事

記事・ニュース一覧