---

Xcode日記 (2)

長嶋 洋一

(一部　「openFrameworks日記」かも)

(一部　「Unity日記」かも)

(一部　「Max7日記」かも)

(一部　「続・Myo日記」かも)

(一部　「Kinect日記」かも)

---

→ Xcode日記(1)

→ Xcode日記(3)

2015年5月20日(水)

ついにXcode日記がpart2になるとともに、1限に「音楽情報科学」、2限にゼミ(Unity勉強会)、という充実の水曜日である。 1限の「音楽情報科学」では、4回生の2グループにセンサを提供し、Kinectを使う2グループに各2台ずつ貸し出し、大型ジョイスティック(ゲーセン仕様)を使いたいグループに多数を貸し出し、「好きな夢をみることが出来る装置」でちょっと遊び、さらに2グループからそれぞれ、「音声→テキスト」変換というのと「Kinect→ボーン座標」変換という宿題を受けとった。(^_^;)

そしていよいよゼミである。 今日は院生の杉浦さんが風邪でお休みしたが、他のメンバーはそれぞれパソコンを持参して集合、ブンちゃんと石井さんには1106のMacBookAir(Unityインストール済)を貸し出して、上のように盛大に藤石さんを講師としたUnity勉強会が始まった。 以下は僕のMacBookAirのスクリーンショットの一部であるが、たった30分でもだいぶ進んだ気がする。 学生は3D Studio Maxを使っているので、むしろ僕よりもこういうのに慣れているので、付いていくのが大変だ。(^_^;)

そして昼休み前には、筑波大の内山先生からのメイルが届き、 日本バイオフィードバック学会 に絡んで打診していた、筑波大学での特別講義について、前々日と前日に開催できそう、との連絡を受けた。 これで、ゼミの希望者とともにSUACのステップワゴンで7月上旬に筑波に遠征して、特別講義とBF学会の連チャンの4泊5日ツアーの可能性が大きく高まったので、メンバーに参加希望を打診するとともに、事務局の台帳に書き込んでクルマを予約した。 SUAC公用車で学生とともに遠くに遠征、というのは、 MOM2010 や MOM2012 以来で、近場では アカペラ合宿 以来である。

そして1106研究室のテーブルには、 mbed日記(3) 以来となる久しぶりの、上のBITalinoとe-Healthを出してきた。 研究の次のステップに向けた仕込みも必要なのである。 昨日、皮膚に貼る電極の追加注文をしていたが、業者から「納期：即納（弊社山形支店に在庫がございます）」とのメイルが来た。 やはり、国内でもやっている人がいる模様である。(^_^;)

そしてここで、1限の宿題として、グループ「ナスビーズ」の成瀬さんから「音声→テキスト」変換という宿題に関して、 ここ と ここ の情報が来たのを受けて、上のようにとりあえずやってみた。 判ったのは、日本語の認識モジュールをダウンロードしていても、MacOSの環境として英語であると(僕は普通は英語モード)、暖かく無視されて英語での音声認識になってしまう、という事だった。 まぁ、マルチメディア室のMacは日本語なのでOKだが、この音声認識モジュールが1.2GBもあるので、これを落として入れないといけない。 さらに、Maxの「textedit」オブジェクト内に、ちゃんと認識された日本語が表示されたが、以下のYouTubeのように、音声認識をスタートさせるために「Fnキーを2度タップ」してマイクにしゃべって、その入力の最後に「再びFnキーを1度タップ」しないと、変換してくれない、という機能の本質的な問題点がある。 ここはおそらく、成瀬さんたちが今後、作品にするために工夫すべきポイントになるだろう。 とりあえず、これで宿題の1つは完了である。(^_^)

YouTube

さて、軽音の顧問として書類にサインしたり、CGクリエイター検定の受験手続きをしたり、という学生アポに対応していてここらで4限になったが、いろいろ注文していた部品なども揃ってきたので、ここで以下のようにテーブルに並べてみた。 今日はあれこれやったので、ここからのハンダ付けは無しで、色々と明日以降に向けての整理である。

下はleap motionである。 これは既に、「2個を同時には使えない」・「ただし1個で両手の10本の指を追いかけられる」・「検出範囲は半径30〜40cmの半球内だけ」・「Max用には赤松さんのオブジェクトがあるので使うのは簡単」などの結果が出て、早くもお蔵入りしかけている。 あまりにも多くの人が使っていて、新しい面白い使い方がなかなか見えないので、半分「終わコン」である。(^_^;)

下は2個のMyoである。 これはまだまだしばらく、これから活躍してもらう事になる。 既にdeep sleepモードが出来たので、この2個も静かにdeep sleepしている。

下は東急ハンズのクリアケースから3種類ほど、試しに仕入れたものである。 「うにうに」センサを8個ないし10個使って、新しい楽器を作るために、スグに着手せずにそのフォルムに関して思考中なのだ。

下は24GHzと10.5GHzのドップラーレーダーモジュールである。 これを何に使うか、は当面、秘密である。 いずれそのうち、学会発表することで公開される計画なのだ。

下は「うにうに」センサであり、2個追加購入したので11個ある。 右側の専用コネクタケーブルも届いたので、製作は可能であるが、楽器としての造型部分でもう少し悩みたいので、ちょっと待機時様態である。 宮本+山崎グループに渡した「うにうに」センサは1個なので、NucleoF401REを使ってA/D変換してMaxのserialに115200で送ったが、新楽器では複数使用するので(例えば10個使いだとA/Dは20チャンネル、さらに制御用に20ビット出力)、マイコンはmbedでなくPropellerの出番と想定している そのために、手前にあるのが、新たに購入した「8チャンネルA/D(SPI出力)」というICである。 これは一度、Propellerで対応ライブラリを作ってしまえば、今後の新プロジェクトで相当に活用できると思うので、30個も購入した。

下はI2Cインターフェースの9軸センサモジュールである。 Myoがここまで使いこなせていなければ、とっくにこれと格闘していた筈だが、あまりに便利なMyoに同等のものが入っているので、当面は休業状態なのだ。(^_^;)

そして下が、明日にでも着手する予定の、BITalinoとe-HealthとNucleoF401REとArduino汎用シールドである。 これは7月あたりまでには実験を完了して学会発表するので、早目に予備実験をしておきたいので、明日に着手する予定だ。

そしてここから1時間ほど、あれこれ札幌のあたりをネット検索して一日が終った。 なんせ先々週の週末には新宿2丁目のカラオケバーで5時間熱唱、先週の週末には社会人カラオフで9時間熱唱したが、今週末はアカペラ新歓カラオケで9時間熱唱、来週末は別の社会人カラオフで7時間熱唱の予定があり、その翌週末には音知学会発表で札幌に行くので、どこで熱唱するかお店の調査とかオフ会の仕込みとか、いろいろあるのだ。(^_^;)

2015年5月21日(木)

朝6時過ぎに研究室に出て来て、朝日に輝く葉から芽くんの以下のような順調な成長を記録してWebに上げて、今日も一日が始まった。 今日は4限の学生委員会しか予定がない、お仕事に集中できる日なのだ。 大学教員のお仕事と言えば「教育」「研究」「地域貢献」であるが、もちろん教育は日々の講義で学生を伸ばし、そして研究ではあれこれいろいろ進めては学会発表し、そして4月からは某社(T○Y○T○と3文字も伏字にすれば判らないだろう(^_^;))の依頼で新たな共同研究という産学協同も始まって、葉から芽くんに負けず、こちらもなかなかに充実している。

そして10時頃から延々と頑張って、4限の会議直前までに、 このように BITalinoのEDAセンサ回路をArduinoシールドに載せて、さらにe-HealthのEDAセンサ出力も使って、NucleoF401REの上に3階建てにした、以下のような「2チャンネルEDAセンサ」システムを完成してしまった。(^_^)

このセンサを何に使うか、というのは、6月の札幌での音知学会で発表する予定であり、その結果は9月の札幌でのEC2015で報告する予定なので、これから実験システムを作って、被験者を募って実験して・・・という事になる。 実験結果がどうなるかの予測/見通しは、ちょっとまだ不明であり、それだけ先行研究の無い、未開の荒野に踏み出すことになるのだ。

2015年5月22日(金)

今日も朝7時前には研究室に出て来て、葉から芽くんの成長を記録してWebに上げてスタートである。 ロシアのDenisからメイルが届き、2冊目のopenFrameworks本は1冊目のアドバンスではなくて、より美味しいエッセンスを初心者向けにしたもの、と判明した。 2週間ぐらいで英国の出版社から届きそうである。 その他にも、かつてKickStarterで仕入れたMOSSに関して、開発者から これ とか これ とかの動画の 情報 が届いた。 以下の「Check your work with X-ray Vision!」というのが気になるのだが、どこをクリックしてもショップのページに飛ばされて追加購入を強いられるので(^_^;)、ちょっと詳細不明である。

そして、昨日の将棋名人戦第4局のおよそをネットでフォローしていたら午前中かかってしまった(^_^;)。 午後をブチ抜いて某プロジェクトの打ち合わせがあり、これにて今週はほぼ終わりである。 このプロジェクトでもちょうど重要な話題としてCVが浮上しているので、「音楽情報科学」の2グループのテーマ関連も含めて、来週にはCVとkinectあたりを、具体的には「OpenCV」と「openFrameworksのCV」と「cv.jit関係」とを、じっくりと攻略することになりそうだ。

2015年5月25日(月)

先週末にはMyoのArmBandManagerのアップデート、そしてMyoのファームウェアアップデートを実行していたのだが、スクリーンショットを撮るのを忘れるほど速攻で完了してしまったので、写真は次回のアップデートまでお預けである(^_^;)。 7月の筑波大での特別講義の相談もぼちぼち進めていて、リクエストに応えていく予定だ。 昨日は第73期将棋名人戦第4局の棋譜を仕入れて、 名局を求めて のページの最後に加えて、じっくりと棋譜を追いかけてみたが、どこで逆転したのか、本当に判らない将棋だった。

今日も朝6時過ぎには研究室に出て来て、上のように葉から芽くんの成長を記録してWebに上げてスタートである。 とりあえず今週の宿題としては「CVチェック」と「FMC3再訪」の2点があるが、Xcodeも放置すると忘れていくので、たまに触っておかないといけない。 Denisの本の第3章「Particke System」というのは、サンプルを走らせるだけでなく、例えばOSC経由でMaxから叩く、というのに格好の題材なので、ここから始めることにした。

まずは最初の単純な「01-SimpleParticle」、つまりインタラクションが無く、単一のparticleが自分のアルゴリズムで次々と描画されつつ残像を消していく、というものを上のように走らせたが、先週あれこれ悩んで解決した段取りを思い出すのにちょっとかかった。 やはり、まだモノになっていないので、繰り返すことが重要だ。 そして、次の「02-ParticlesEmitter」のサンプルについては、OSCのaddonも加えて、これまでは逆方向、つまりopenFrameworksからMaxにOSCを投げてMaxで表示していたのを、今度はMax側からOSCを送ってopenFrameworksで受けて、このサンプルの「各Particlesの回転角度」と「Particlesの総数」をライブにぐりぐり制御する、というのを実装してみた。 ビデオに撮ってYouTubeに上げるほどのこともないのでスクリーンショットであるが、以下のように関係性は明確で。、なかなかに奇麗である。 これはjitterでも出来るのだろうが、ライブグラフィックスをopenFrameworksに切り分ける、という実験でもある。

そして次の「03-ParticlsForces」はほとんど同じなのでOSC制御も省略して以下のように単にサンプルを再現するだけとした。 さらに「04-Particles」は、以下のようにウインドウ内にGUIのバーを出して、多くのパラメータを動かしたりプリセット化したり・・・というのがメインで、Particlesとしてはほとんど目新しいものは無かった。 このようなGUIを使うことはたぶんほとんど無くて、MaxからOSCで与えたり、Myoやmbedからリアルタイム制御する、という事が中心になるので、GUIはあまり深入りしないで次に進むことにした。 これで第3章まで終わりであり、ちょっと先の章には「OpenCV」というのもチラッと見えた(^_^)。 ここで1限が終る頃となったが、水曜日のゼミではまたまたUnity勉強会で先に進む・・・というように、日々、新しいことが押し寄せて来るので、今日のopenFrameworksはここまでである。 とりあえず「忘れない程度に触っておく」日々が大事なのだ。

そして次に着手したのは、「MaxでのCV関係の整理」である。 これは水曜日の「音楽情報科学」で2グループほどがWebカメラかKinectを使った画像認識系のインスタの実験をするためにも必要であり、さらには先週のミーティングを受けて、某企業との共同研究でも乗点ポイントとして浮上してきている。 これを整理した上で、openFrameworksと絡めてOpenCVについても調べて、さらにProcessingにも同様のライブラリが完備しているので、それも調べることになる。

とりあえず手元にあるのは上のようなものであり、膨大な「cv.jit」と、さらに特化した「Eye_tracker」、さらに「jit.freenect.grab」という、Max用にkinectの情報を取得するライブラリも全て、IAMASのJean-Marc Pelletier氏が開発して、フリーで公開しているものである。 彼は僕がSUACで開催(大会委員長)した国際会議 NIME04 にも来てくれたし、あとはICMCやNIMEなど、海外で再会することがほとんどである。

まず先に上の「Eye_tracker」について解説すると、これはIAMASの学生作品プロジェクトのために、人間の両眼を抽出する、という機能に特化させたCVモジュールであり、あれこれ動いてみると、なかなかに素晴らしいものであると体感できる。 前年度の後期の「サウンドデザイン演習」で、チーム「週末バイト戦士」がこれを使った一種のゲームを制作した。 これ である。

そしてとりあえず深度情報のあるkinectを後回しにして、単純な2次元のWebカメラで、上のようにJean-Marc Pelletier氏が丁寧なリストとして並べてくれている「cv.jit」を順に調べて、今後の画像認識センサとしてどう使えるか、を自分なりに整理する、という作業である。 これまで何度も「やらなくては・・・」と思っていたものの、なかなか直面してこないとやらないので、過去には去年の「音楽情報科学」の これ ぐらいであった。 せっかくなので、ものによってはヘルプのサンプルを自分なりにすこし整理したパッチも作っていくことにした。 Sortは「by Name」と「by Group」とあるので、以下は「by Group」で順になぞっていく。

cv.jit.label

上の「cv.jit.label」は「Assign a different value to each connected component in a binary image」ということで、「jit.op」でスレショルドを設定して2値化した元画像に対して領域に分割して複数のIDを付与するもので、サンプルでは微妙に調整すると顔面がいくつもの色に塗り分けられた。 「cv.jit.label」のスレショルド入力を設定すると、その数値以下の小領域への分割を無視する。

cv.jit.floodfill

上の「cv.jit.floodfill」は「Isolate a single connected component from a binary image」ということで、「jit.op」でスレショルドを設定して2値化した元画像に対して、サンプルの左画像内をクリックしたマウスカーソルから取得した値で塗りつぶせる領域だけを抽出して(その領域だけ画素を白にして)出力する。

cv.jit.blobs.sort

上の「cv.jit.blobs.sort」は「cv.jit.label」と伴に使うもので、「Try to keep blob labels in order」というもので、動画の画像環境などで付与されたIDがずれた場合に再度付け直すものである。

cv.jit.blobs.recon

上の「cv.jit.blobs.recon」は「Compare each connected component to a pre-calculated model」というもので、OCRなどで読み込んだ形状データを「cv.jit.leam」によって取り込んで「.mxb」という紛らわしいデータと比較して、同じ形状の2値画像の領域を抽出するものだという。 あまり使えそうもない。(^_^;)

cv.jit.blobs.orientation

上の「cv.jit.blobs.orientation」は「Return the orientation of each connected component」というもので、入力された2値画像が結合されたコンポーネントからなるとして、その方向を判断してくれるというものである。 これはなかなか使えるかもしれない。

cv.jit.blobs.moments

上の「cv.jit.blobs.moments」は「Return moments and invariants of each connected component」とあったが、詳細はちょっと不明である。 blobsというのは要するに2値化された画面内を複数のブロック化したもので、そこから7階層の距離とか形状を分離するらしい。

cv.jit.blobs.elongation

上の「cv.jit.blobs.elongation」は「Return the elongation (thinness) of each connected component」というもので、blobsのそれぞれのthinness(鋭さ?)を計測するものだという。 これはちょっと、キープである。(^_^;)

cv.jit.blobs.direction

上の「cv.jit.blobs.direction」は「Return the direction each connected component points to」ということで、2値化画像からblockにしたそれぞれの方向を検出するものである。 自分の顔画像ではちょっとイマイチだったが、もう1つのサンプルの、多数の矢印がある2値画像では、それぞれにきちんと方向ベクトルが検出されていて、これまた使えそうで、キープである。(^_^)

cv.jit.blobs.centroids

上の「cv.jit.blobs.centroids」は「Return the center of mass of each connected component」ということで、2値化画像からblockにしたそれぞれの領域の「重心」を計算して出してくれるものである。 これはおそらく、現実世界を単純化して認識していく場合のもっとも基礎となるものであり、活用することになるだろう。

cv.jit.blobs.bounds

上の「cv.jit.blobs.bounds」は「blobs」のグループの最後で、「Return the bounding boxes of each connected component」ということで、2値化画像からblockにしたそれぞれの領域の境界を矩形で返してくれる。 いろいろノイズの多いWebカメラでの顔画像でも、「jit.op」でスレショルドを設定して2値化する匙加減で、見事にいくつものブロックを検出してくれている。 これはもう、さっそくアレに使いたい・・・というほど、キープである。 ここでだいたい3限が終わり、4限「サウンドデザイン」の講義のため、マルチメディア室に向かうことにした。 続きはまた、明日である。

2015年5月26日(火)

今日は4-5限の「企画立案演習」と放課後にアカペラがあるが、CGクリエイター検定試験を受験する学生が次々に手続きのために研究室にやって来る日である。 朝イチで「 誰がやっても勝つ、弱い将棋FLASH 」というサイトの情報を発見して、さっそくやったみたら、以下のように本当に弱かった(^_^;)。 ・・・というより、飛角桂香落ちに勝てない人っているのかなぁ。 エンタテインメントコンピューティングの世界では既に何年か前から、将棋ソフトの研究者のテーマは「いかに人間の棋士に勝つか」ではなくて、「いかに人間に気付かれないように程よく負けてくれるか」となったが、まさにその流れのソフトだった。

さて、昨日の届きの「cv.jit」の前に、今日も少しだけopenFrameworksを進めておこう。 第4章は「Images and Textures」であり、2次元の静止画データの処理である。 openFrameworksではラスター画像もベクター画像も対応しているというのは、さすがである。 たしかProcessingはラスター(ビットマップ)だけ??と一瞬思ったが、そんな筈は無く(^_^;)、まぁProcessingもMax/jitterも、両方OKである。

・・・ところがなんと、ここから1時間ほどトラブって、ハマッてしまった(^_^;)。 上のように、「01-ImageDraw」のサンプルをコピペして、とやっていると、どうも画像素材の提供者のCopyright表示のところで、ofApp.hの中に普通じゃない文字コードが紛れていてエラーが出る。 該当する行を削除したり、あらゆる文字コードに変えても駄目なのだ。 昨日はあまりに快調に来たが、今日はいきなりの急ブレーキである。

そして結局、上のようになんとか、用意されたPNG画像をただ出すだけ、というXcodeプログラムが完成した。 経験則的な注意点としては、以下がこの章の全体に波及しそうである。

• 問題の文字コードを含むofApp.hは、上のようにXcodeのソース画面内では文字化けするが、テキストエディタで開くと正しいので、文字化けを気にしない(^_^;)
• 画像データの置き場所は、上のようにプロジェクトのbin以下のdataフォルダの中である

なんか面倒であるが、仕方ない。 この章では同じサンプル画像を使っていて、サンプルのofApp.hが問題なので、ずっとこれが続くことになるかと思うと気が重い。

そして、次の「02-ImageSpiral」では、ofApp.hの中身が何もなく同じである事を確認することで、上のように、なんとか昨日と同じようにあっさりとビルド成功まで通達した。 ここまでが長かったが、原因さえ判ればうまく回避していけるのだ。 そして、続く「03-ImageTransp」も、以下のように奇麗に出来た。 要するにここらは、Processingのサンプルで、ラスター画像をトランスペアレンシー属性まで含めて拡大・縮小・回転・移動して重ねて描画できる、という基本のサンプルということで、openFrameworksならでは、という目新しいものは何もない。

そして昼休みになったが、区切りまで、とさらに続けた。 以下の「04-ColorWaves」は、画像ファイルを参照しないで画素ごとに色付けする「数理造型」プログラムであり、滑らかなグラデーションのために、色の分布のところに時間変化するsine関数を使う、という定番である。 デジャヴとして、これはたしかProcessingでもjitterでもやったなぁ・・・という気がした。

以下の「05-ImageModify」は、画像ファイルに対して、推理的に指定した部分のカラー情報にエフェクトをかけるというものである。 静止画にこれをしてもあまり面白くないが、いのcv.jitでやっているように画像認識でカラー加工する領域が動的に移動・変化するとなれば、途端にインスタレーション的な面白さが出て来る。 たとえばWebカメラで顔を撮って、ライブで(動いても)その両頬がうっすらと赤くなっていく(酔っぱらいみたいに)・・・などというのは簡単な関係性だが面白いだろう。

そして次のサンプルでは、ちょっと「隣村の阿部古部おじさん」の素材画像もネットから拾って(^_^;)、「06-HorizontalDistortion」を作ってみた。 これも定番の静止画エフェクトで、時間とともに横方向に歪ませるのに、やはり自然なカーブとしてsine関数を使うというものである。 これまた、Processingのサンプルで見たような記憶がある。 動画でもいいのだが、スクリーンショットを連打してみた。

これで、第4章も最後のサンプルとなったが、以下は「07-VideoMapping」というもので、素材画像の四隅を数字キーで指定してカーソルキーで動かすと、元は矩形である素材画像がアフィン変換される、というものである。 draw()で刻々と描画を繰り返しているので、この座標指定を外部のセンサ等からOSCあたりで送れば、センサで静止画をぐりぐりと変形させる、というのは簡単だろう。 スタートでトラブったために、ここまでで3限も半ばとなってしまったが、まぁopenFrameworksについてはさらに進んだ、ということで、これも良し、としよう。

さて、「企画立案演習」のクラス作業スタートを見届けて研究室に帰れば、ここからいよいよ今日の「cv.jit」タイムである。 ただし、いきなり昨日の続きの以下は、それぞれ「no help file found」と出た。 いずれも、別のcv.jitパッチから呼ばれるサブ機能モジュール(ユーティリティ)であり、単体のヘルプが無いのだった。

• cv.jit.track.draw Drawing utility for cv.jit.track
• cv.jit.snake.draw Drawing utility for cv.jit.snake
• cv.jit.shift.draw Drawing utility for cv.jit.shift
• cv.jit.lines.draw Drawing utility for cv.jit.lines
• cv.jit.features.draw Drawing utility for cv.jit.features
• cv.jit.faces.draw Drawing utility for cv.jit.faces
• cv.jit.centroids.draw Drawing utility for cv.jit.centroids
• cv.jit.blobs.orientation.draw Drawing utility for cv.jit.blobs.orientation
• cv.jit.blobs.orient.draw Drawing utility for cv.jit.blobs.orientation
• cv.jit.blobs.elongation.draw Drawing utility for cv.jit.blobs.elongation
• cv.jit.blobs.direction.draw Drawing utility for cv.jit.blobs.direction
• cv.jit.blobs.colour Paint each connected component a different color
• cv.jit.blobs.color Paint each connected component a different colour
• cv.jit.blobs.centroids.draw Drawing utility for cv.jit.blobs.centroids
• cv.jit.blobs.bounds.draw Drawing utility for cv.jit.blobs.bounds

そしてこの次から、また画像認識関係のリストが続いた。

cv.jit.canny

上の「cv.jit.canny」は「Extract a binary edge from a greyscale image」というもので、スレショルドを調整すると、グレースケール画像からバイナリ境界を抽出するものである。 他のカラー操作のjitオブジェクトと組み合わせると、ちょっと使えそうである。

cv.jit.binedge

上の「cv.jit.binedge」は「Extract edge pixels from a binary image」というもので、スレショルドを調整すると、バイナリ画像からバイナリ境界を抽出するものである。 エッジを強調するにはこちらも使えるかもしれない。

cv.jit.threshold

上の「cv.jit.threshold」は「Obtain a binary image using adaptive thresholding」というもので、パラメータはたった3つ、(1)ネガポジ反転のトグル、(2)スレショルド値、(3)輝度判定をする粒度、というだけなのだが、チラチラっと変化させるだけで、こんなにも楽しい画像が簡単に出来てしまった。 粒度を変化できるのがポイントで、「adaptive thresholding」と言うだけのことはある。 これだけを使って、何か楽しい「自分撮り」インスタレーションが出来そうである。(^_^)

cv.jit.open

上の「cv.jit.open」は「Morphological open operator (erode+dilate)」というもので、ONピクセルノイズを除去するためにerode+dilateという処理を行い、結果としてちょっとだけsmall gapsが大きくなるという。 ただし、これに続いて、そのり組み合わされているという個々のオブジェクト、さらにopenの反対のcloseという以下があったが、どうも違いはよく判らなかった。(^_^;)　

• cv.jit.erode Morphological erosion
• cv.jit.dilate Morphological open operator
• cv.jit.close Morphological close operator (dilate+erode)

そして。この次からは「movement」、つまり「動きの検出」のカテゴリに入ってきた。

cv.jit.open

上の「cv.jit.opticalflow」は「Estimate optical flow using a variety of methods」というもので、何もしないで静止していると画面は単調に塗りつぶされるが、左右にゆらゆらと揺れ動いてみると、その移動方向にopticalflowがいろいろなパターンで現れた。 ここから運動を検出するにはまだステップが必要だが、その端緒になるパターン認識だろう。

cv.jit.lkflow

上の「cv.jit.lkflow」は「Use the Lucas-Kanade method to estimate optical flow」というもので、Lucas-Kanadeアルゴリズムというりもので(詳細不明)、パラメータ「radius」(粒度)が1から7まで整数で変わるだけだが、「ガチョーン」とWebカメラに向かって距離を変化させている掌だけが着色されて、つまりはkinectのようにダブルカメラでないのに、ちゃんと「深度方向」の動きを検出しているのである。 これって結構、凄いことだと思う。(^_^)

cv.jit.hsflow

上の「cv.jit.hsflow」は「Use the Horn-Schunk method to estimate optical flow」というもので、Horn-Schunkアルゴリズムというもので(詳細不明)、同様に動きを検出しているらしいが、何だかよく判らなかった。(^_^;)

cv.jit.framesub

上の「cv.jit.framesub」は「Find the difference between the current frame and the previous one」というもので、まさに「動き検出」の基本中の基本というか王道、前フレームの画像との差分を検出するものである。 思えば、いちばん初めにjitterで画像認識のインスタレーションをやったのはもう9年前、 ここ の先頭にある作品、下の キになるキ だった。 ここではビデオカメラ画像を2値化して、前後のフレームの差分だけを白くして、その変化した全面積がある値以上になると、画面内のFlashムービーの「木」が成長する、というものだった。

人間はジャンプすると木が伸びるので自然に感じたが、実はこれは「急速にしゃがむ」という下向きでも同じイベントとなり、木は上に伸びるのであるが、そういう事をする来場者がいない、というのがポイントだった(^_^;)。 ・・・これで「movement」カテゴリまでのチェックが完了である。 5限に入り、ちょうどいい時間となったので、今日はここまでである。

・・・と書いてから、皆んなが集まるまで、朝に発見した「 誰がやっても勝つ、弱い将棋FLASH 」というのと対戦したところ、負けると次第に駒落ちが少なくなっていき、最後は平手になった。 平手でもなんとか勝ったら、次はもっと強くなっていって負けかけたところでメンバーが集まってきて、投了せずにウインドウを閉じたが、たぶんこれはcookieを消さないと、この強さから再開しそうである。(^_^;)

2015年5月27日(水)

昨日は痛恨のミスを犯していた事に朝イチ(7時前)に気付いた。 いつものように朝6時半には葉から芽くんの成長を記録したのだが、その時にデジカメ内に写真が残っていたのでいつものように消してから撮影したが、実は昨日の朝イチで撮影していたこの写真、忙しくて [パソコンに取り込みWebに上げる] という作業をしていなかったのだった(^_^;)。 早回し成長記録を撮影しているjitterの方の自動撮影プログラム(6分ごとに1枚、1時間で10枚、1日で240枚)は引き続き順調に撮影中であるが、「葉から芽」日記の方は1日だけスキップしてしまった。 まぁ仕方ない。

そして昨日の最後にやった 誰がやっても勝つ、弱い将棋FLASH を初期化するためにブラウザのcookieとともに全てのキャッシュや履歴をクリアしたために、昨日どこまでWebニュースをチェックしていたかの情報も消えてしまい(^_^;)、ちょっと半日以上も前からのチェックとなった。 どうやら、講義がまとまっている週の前半は要注意である。 今日も1限に「音楽情報科学」、2限にはゼミ(またUnity講座だぁ(^o^))、そして5限に学科会議があり、その合間にあれこれ進めることになる。 金曜日に人間ドックがある関係で今週は禁酒週間なので、朝から落ち着いて「cv.jit」をさらに調べていこう。

cv.jit.snake

カテゴリは新しく「patterns」に入って、上の「cv.jit.snake」は「Fit a shape to image edges」というもので、ちょっと正体不明である(^_^;)。 Maxウインドウには、ズラズラと多数の「OpenCV error」というのも出て来た。

cv.jit.lines

上の「cv.jit.lines」は「Find straight lines in a greyscale image」というもので、スレショルドや感度、ラインの長さなどのパラメータを設定して、指定した領域に多数のラインを引く、というものであり、調整するとほぼ「塗りつぶし」も出来るようだ。

cv.jit.hough2lines

上の「cv.jit.hough2lines」は「Use the Hough space to find straight lines in an image」というもので、Hough空間というもの(詳細不明)を使って、画像中の直線成分を検出して描画するのだという。

cv.jit.hough

上の「cv.jit.hough」は「Calculate Hough space」というもので、まさに謎な「Hough空間」そのものを演算してビジュアル化しているが、なんとも詳細は不明である。 かなり重そうな処理だ。

cv.jit.features

上の「cv.jit.features」は「Find salient points in a greyscale image」というもので、与えられた画像の「要点」となるポイントを抽出してくれるものだという。 密度やスレショルドのパラメータは完備しているが、何が「要点」なのか、は不明である。

cv.jit.faces

上の「cv.jit.faces」はその名の通り、「Find faces in a greyscale image」というもので、ようやく判りやすいものがあった。 認識・追従する「顔」の候補は1つだけでなくいくつも指定できるようなので、これは多数の学生で実験してみたい。 ここまでで「patterns」カテゴリが終ったが、ここで9時に近付き、1限の講義のマルチメディア室に向かうことになった。

そして2限、久しぶりに全員が揃って、いよいよゼミである。 話題としては、筑波で僕と杉浦さんに合流する藤石さんが東京でバイト参加する コンテンツ東京2015 の中の 第1回 先端コンテンツ技術展 の話とか「背中にGがかかる方法」よりも、学生は圧倒的に 第4回 クリエイターＥＸＰＯ に食い付いてきた(^_^;)。 また、僕が札幌に出張に行くと言えば「白い恋人」「じゃがいもコロコロ」との声が上がり、僕が新潟に出張に行くと言えば「日本酒」の声とか 新潟ぽんしゅ館 の情報が届いたり、と盛り上がった。 さて、今日は院生の杉浦さんもMacを持参、他のメンバーはもそれぞれパソコンを持参して集合、ブンちゃんと石井さんは1106のMacBookAirで、上のように盛大に藤石さんを講師としたUnity勉強会が始まった。 以下は僕のMacBookAirのスクリーンショットの一部であるが、たった30分ほどでも、またまただいぶ進んだ気がする。

そして今年のゼミがこの6人でほぼ固まったということで、「ゼミ総決起集会」という名の懇親会を6月15日の晩に開催することが決まった。 これで、超ストイックに過ごしたゴールデンウイークが明けてからというもの、毎週のようにカラオケ熱唱するという日々が、5/9新宿・5/16浜松・5/23浜松・5/31浜松・6/6札幌・6/12京都・6/15浜松・6/18新潟・6/21浜松・6/26名古屋・7/3筑波・・・と間断なく続くことになりそうである(^_^;)。 午後になって、5限の学科会議までに何を進めようか、とフト考えたが、「Xcode日記」であるならば、ここはopenFrameworksの続きということになるが、「音楽情報科学」のCVテーマのグループの事を考えると、まずは「cv.jit」の整理を片付けてしまって、さらに出来ればProcessingとkinectでの「ボーン認識」を調べてみたいのだ。

cv.jit.undergrad

cv.jitのカテゴリはその名も「recognition」(認識)となり、上の「cv.jit.undergrad」は「Very simple pattern learning and recognition」というもので、画像の中で要素のリストをいくつ認識するか、というのを学習するものらしい。

cv.jit.learn

「recognition」カテゴリのもう一つ、上の「cv.jit.learn」は「Simple pattern learning and recognition」というもので、パターン認識の学習機能をシンプルに実装したもので、認識モデルとの距離(へだたり)を刻々と取得することが出来る。

cv.jit.perimeter

ここからは「shape」カテゴリである。上の「cv.jit.perimeter」は「Count the number of edge pixels in a binary image」ということで、2値画像の中で境界ピクセル数をカウントしている。 Webカメラ等の自然画像の場合には、この数値がある程度まで小さくなるように、2値化のスレショルドを自動調整するようにする、というのが「使える手」になると思う。

cv.jit.orientation

上の「cv.jit.orientation」は「Find the orientation of an image from its moments」ということで、画像の移動(変化)から。何らかの方向を認識して角度として出力してくれる。

cv.jit.moments

上の「cv.jit.moments」は「Calculate moments of inertia and shape invariants for an image」ということで、画像の慣性モーメントと形状の不変量を計算してパラメータとして出力するものである。

cv.jit.mass

上の「cv.jit.mass」は「Sum all the pixel values togther (char data is normalized between 0 and 1)」ということで、画素ごとの重みの総和、つまり2値化した時の画面の明るさを計算するものである。 これを前フレームと現フレームとで比較することで、「大きく変化した」という検出が可能となる。

cv.jit.elongation

上の「cv.jit.elongation」は「Calculate how thin a shape is from its moments)」ということで、画像の「鋭さ」(thinness)を計算するものだという。 もっと単純な図形で調べた方がよかったかも。

cv.jit.direction

上の「cv.jit.direction」は「Calculate the direction of a shape from its moments」ということで、図形として認識した上で、その方向を計算して示すものである。

cv.jit.circularity

上の「cv.jit.circularity」は「Calculate how compact a shape is」ということで、詳細不明なのでパッチ内の解説をコピペすると、「cv.jit.circularity computes how compact a shape is. That is to say, circularity is defined as a ration between a shape's area and its perimeter. Theoretically, the most compact shape is the circle. In digital images, however, due to aliasing, shapes such as squares may seem more compact. The higher the circularity, the more compact a shape is, with a perfect circle returning 1. The closer to 0 circularity is, the more jagged is the shape's outline. cv.jit.circularity also returns the perimeter.」 とのことである。

cv.jit.centroids

上の「cv.jit.centroids」は「Calculate the center of mass of the image」ということで、これは判りやすい、図形の重心位置を検出するものである。 これで「spahe」カテゴリまで終ったところで4限も終った。 あと少しかなぁ。

そしてここからメディア造形学科会議の会場に行ったが、学科教員が全員集まるまでに時間がちょっとかかって(^_^;)、その間にopenFrameworksの第5章「05-Video」の最初のサンプル「01-VideoPlayback」があっさりと上のようにコンパイル出来てしまった。ダミーで移動先でビルドエラーを出してから戻すこと、サンプルソースのちょっとした書き直しなど、ようやく半ば無意識に出来るようになってきた。 やはり、繰り返しは大事なのだ。(^_^)

2015年5月28日(木)

もう週末である。 今日は月に一度の教授会が4限に予定されているだけであり、明日は朝から人間ドック(;_;)なので、今日は色々と進めておきたい。 朝イチの葉から芽くんは順調であり、来週末には音知学会発表参加の札幌出張(3泊4日)に出かけて水やり出来なくなるので、出発日6/5の午前か、その前日6/4には、ここまで育った葉から芽くんを全て希望者に切り分け進呈して、ちょうど1ヶ月続けた定点観測の記録も終了する予定である。

昨日の続きで今日は「cv.jit」のチェックを完了する、というのはもちろんなのだが、フト思い立って、あてずっぽうで「opencv.org」と入れてみると、上のように OpenCV のサイトが出て来た。 最新バージョンのDownloadのリンクを見ると、対応プラットフォームは「Windows」・「Linux/Mac」・「Android」・「iOS」と完備されている。 要するに、openFrameworksのCVも、Max用の「cv.jit」も、ProcessingのCVライブラリも、全てはこの OpenCV の展開系なのである。 さっそく「Linux/Mac」版をダウンロードしてみるとなんと100MBほどもあり、展開すると以下のように膨大なものだった。

そして、 OpenCV のページから Welcome to opencv documentation! というページに行ってみると、とても気になる Kinect and OpenNI というリンクを含めて、以下のようにまさに充実のラインナップだった。 Max/jitter用の「cv.jit」とかProcessing用のCVライブラリはそれぞれの処理系に特化しているが、考えてみればここのOpenCVは本家なので、openFrameworksの中のaddonのCV、という容れ物を借りなくても、既にXcodeの開発環境があるので、直球でこれらをXcodeから活用できる筈であり、画像認識センサに邁進するとすれば、ここが王道なのだ。

    OpenCV API Reference
        Introduction
        core. The Core Functionality
        imgproc. Image Processing
        highgui. High-level GUI and Media I/O
        video. Video Analysis
        calib3d. Camera Calibration and 3D Reconstruction
        features2d. 2D Features Framework
        objdetect. Object Detection
        ml. Machine Learning
        flann. Clustering and Search in Multi-Dimensional Spaces
        gpu. GPU-accelerated Computer Vision
        photo. Computational Photography
        stitching. Images stitching
        nonfree. Non-free functionality
        contrib. Contributed/Experimental Stuff
        legacy. Deprecated stuff
        ocl. OpenCL-accelerated Computer Vision
        superres. Super Resolution
        viz. 3D Visualizer

    OpenCV4Android Reference
        Android OpenCV Manager
        Java API

    OpenCV User Guide
        Operations with images
        Features2d
        Kinect and OpenNI
        Cascade Classifier Training
        Senz3D and Intel Perceptual Computing SDK

    OpenCV Tutorials

また、YAHOO.COMで「max msp jitter opencv」として検索してみると、「cv.jit」の開発者Jean-Marc Pelletier氏による A Simple OpenCV Tutorial というページのリンクや、kinectを使ったけっこうよくあるインスタレーション作品にOpenCVが使われているらしく、YouTube動画のリンクとして test max msp opencv とか Kinect Projection mapping with box2D physics とか Interactive Wall Installation とかが出て来た。 ここらもおいおい、チェックしていくべきところなので、メモとしてここにリンクを並べてみた。 このページを「音楽情報科学」で画像認識ネタに挑戦するグループが見て勉強してくれれば嬉しいのだが。

cv.jit.sum

さて、いよいよ「cv.jit」で残っているのは、「statistics」カテゴリの5個、「tracking」カテゴリの4個、「utilities」カテゴリの4個、の計13個である。 そして「statistics」カテゴリの「cv.jit.variance」(Calculate the time-wise variance of an image stream)は、実際の画像を使ったヘルプでない、単なるユーティリティだった。 次の、上の「cv.jit.sum」は「Add all the pixel values together」ということで、画面の全画素数(変動しない)と、RGBそれぞれのplaneの画素数(刻々と変化するのは蛍光灯で点滅しているから)、というものだった。 次の「cv.jit.stddev」(Calculate the time-wise standard deviation of an image stream)は、実際の画像を使ったヘルプでない、単なるユーティリティだった。

cv.jit.ravg

上の「cv.jit.ravg」は「Calculate the time-wise running average of an image stream」ということで、これはスグにでも使える素晴らしいものだった。 要するに画素ごとに移動平均をとっているだけなのだが、浮動小数点(0.0〜1.0)の「透過度」パラメータを変えるだけで、残像として残る印象が劇的に変化して、この「cv.jit.ravg」だけで、簡単に「心霊現象リアルタイム画像」が出来てしまうのだ。 これは碧風祭の「お化け屋敷」に使えばよかった・・・と思った。(^_^;)

cv.jit.mean

上の「cv.jit.mean」は「Calculate the time-wise mean of an image stream」ということで、移動平均の「cv.jit.ravg」に対して、resetあるいはstartというトリガからそれ以降の画素ごとの平均をとり続けていく、というものである。 こちらも残像が効果的に残るので、インスタ系ではこちらでうまくトリガポイントをセンサから叩くというのも面白そうである。 これで「statistics」カテゴリが終ったが、次の「tracking」カテゴリの最初の「cv.jit.track」(Track individual pixels)は、なんだか画面に変化がなくて詳細不明である。(^_^;)

cv.jit.touches

上の「cv.jit.touches」は「Track greyscale blobs, useful for multi-touch screens」というもので、画面内の領域を指定したサイズの円を敷き詰めようとしてトラッキングするもので、なかなか動いているのを見ると面白いが、かなり「重い」処理なのがはっきりと判るので、たぶん僕はライブ作品にはこれは使わないだろう。

cv.jit.shift

上の「cv.jit.shift」は「Use MeanShift and CAMShift algorithms to track bright regions」というものだが、画面内のswatchの位置と別ウインドウの画像を見比べると判るように、ほんの小さなパラメータの違いで劇的にトラッキングの結果が変化するので、ライブで使うとかなり効果的な気がする。 これも次に機会があれば「お化け屋敷」で使ってみたい(^_^;)。 次の「cv.jit.features2track」は「Initialize cv.jit.track to salient points in the image」とあったが、何も変化が見出せず、さらに「doesn't understand "precision"」とエラーが出てこのパラメータのトリガが出せないので、もしかするとバグがあるのかもしれない。

cv.jit.resize

ここから最後の「utilities」カテゴリである。 上の「cv.jit.resize」は「Use bi-cubic interpolation to resize a matrix」というもので、パッチのサブタイトルは「Anti-aliased resizing of matrices」、解説は「This object uses bicubic interpolation to resize a matrix. This will yield more accurate smaller matrices than simply using jit.matrix」とある。 元画像の左端の画素を右側に拡大表示しているが、「cv.jit.resize」は一種の「滑らかフィルタ」(Anti-aliase filter)として機能するらしい。 そして「cv.jit.poltocar」(Convert polar coordinates to cartesian form (matrix version))と、「cv.jit.cartopol」(Convert cartesian coordinates to polar form (matrix version))は、実際の画像を使ったヘルプでない、単なるユーティリティだった。

cv.jit.grab

そして最後、上の「cv.jit.grab」は「Cross-platform wrapper for jit.qt.grab and jit.dx.grab」ということで、jitterが標準で持っている「jit.qt.grab」をラップした上位互換のライブカメラということなので、以下のように live_camera.maxpat とまとめてみて、今後はこちらを使うようにした。 これで無事に、「cv.jit-Object Guide.maxpat」は全部チェックしたことになるが、考えてみると標準のjitterオブジェクトにも、同様に一種の画像認識として使うものが多数ある・・・と気付いたので(^_^;)、これも追ってチェックしたいと思う。

そして3限になり、ようやく落ち着いてきたが、実は今週ずっと、特に昨日からさらに、そして今日はほぼ1時間おきぐらいに交互に学生からメイルが来ては対応して、7月の前期・CGクリエータ検定試験の受験者は、およそ以下のように25人近くになった。 なかなか盛況である(^_^)。 Web申し込み期限が今日の夜中で、さらに受験料を納付する期限が来週月曜の朝10時なので、それを持って郵便局に振り込みに行くと、ようやくこの手間もほぼ終ることになる。 あとは皆んな、ちゃんとテキストを勉強して、しっかりと合格を掴み取って欲しいと思う。

・・・そして4限の教授会では、SUAC開学の2000年4月以来の16年間全てのデザイン学部教授会の中で、もっとも、ちゃんと本気・本音で議論できた・・・とも思える熱心な時間を体験した。 終ってぐったり疲れたが、いやいやなかなか、デザイン学部の先生がたも捨てたもんじゃない(^_^;)、という満足感に浸って、研究室に戻ってきても、とてもここからopenFrameworksとかXcodeとかに進む気力もなく、一日が終った。 普段であれば帰途にビールを仕入れて「乾杯」したいところだが、残念、明日は人間ドックなので、今日はグググッッと堪えて大人しくベジタリアンである。 反動で、何も予定の無い土曜日あたりに「一人焼肉」でも行こうかなぁ。

2015年5月29日(金)

午後4時の研究室で、激しく凹んでいる(^_^;)。 今日は朝から人間ドック、まぁ年に一度の儀式ということで、今週は月曜からずっと禁酒してきたが、無事に終れば晩にはピール、そして週末はまたまた飲み歌いのカラオフ(*^o^*)・・・という筈だった。 去年は予約が満杯で胃カメラが受診できなくてバリウム(レントゲン)だったが、今年は胃カメラの予約できる日、と選んだので、1年スキップしたものの、それ以前のデータとの比較も出来る遠州病院(SUACから徒歩5分)の1日人間ドックである。

しかしなんと、今年の胃カメラでは遂に「生検」、つまり明らかにピロリっぽいので胃カメラのパイブから超小型ハサミを入れて胃壁の細胞を切り取って出す、というのをやって、医師から「これは間違いなくピロリです」と断定された。 普通だとこの生体組織を2週間ぐらいかけて検査すると結果が出るらしいが、なんとその場で、以下のように、僕の胃壁の細胞が入った容器をお土産にもらった(^_^;)。 検査するまでもない、という事らしい。 ちょっと赤っぽいのはPH試薬が入っているからで、このピロリ菌が満載の細胞からアンモニアが出てきて、どんどん青くなっていくのだという。

上の写真は、まだ検査着を着たまま、内視鏡検査室の前のベンチで撮ったものだが、下の写真はそれから約30分後、いったん研究室に帰ってきた時に撮ったものであり、やや紫色に化学反応が進んだ。 つまり、膨大なピロリ菌がここで活動しているのだ(^_^;)。 そして人間ドックの検査項目の一つの筈なのに、この内視鏡検査医は、その場でピロリ菌を除去するための2種類の抗生物質の処方箋をサクサクと書いて、さらにその結果を判定するために7月に検査通院(吐息の中のアンモニアを測る)、さらに8月の最終診断通院(もう一度、吐息の中のアンモニアを測って減ったことを確認する。駄目だったら抗生物質の強さを1ランク上げる)、の予約まで入れてくれた。 スマートでありがたい事だ、と、この時には心から、思った。

しかし、病院で受けとった紙には「胃カメラで生検をした人は、その日はアルコールもコーヒーも駄目」と書かれていた。 刺激物で胃からさらに出血してはいけないので当然だが、毎日、朝イチからドリップコーヒーで始まるのに今日は検査前の飲まず食わずだった僕にとって、人間ドックが終って研究室に帰ってきて、今日の最初の一杯のコーヒーが「駄目」というのは、じわじわ悲しくなってきた。 さらに今夜の楽しみ、1週間、禁酒してきた後のビールも駄目、と気付いて、さらに大きく凹んだ。 そこに追い打ちをかけて、内視鏡検査の医師は「アルコールはまぁ控え目に」と言っていたので暖かく無視するつもりだったのに、抗生物質の処方箋を持っていった薬局の人が「これを飲んでいる1週間は、アルコールは我慢して下さい」と宣言してくれて、ここに決定的に凹んだ。

こうなれば、藁にもすがる思いで、助けを求める先はネットである。 YAHOOで「胃カメラ 生検 アルコール コーヒー」で検索して、いやいやそんな事なくて、検査当日に飲んだって大丈夫だったよ・・・的な情報が出て来ることに期待した。 ところが出て来る情報は皆、「当日はアルコールもコーヒーも我慢」ばかりで(^_^;)、ひどいのになると「生検の後3日間はアルコールもコーヒーも我慢して」などというのもあり、これは断固として無視することにした。 結論として、せっかく高額な検査と抗生物質処方があるので、アルコールはこれまで1週間の禁酒がさらに1週間の延長(;_;)(;_;)、そして今日はとにかくコーヒーを我慢して、明日からコーヒーは再開、ということになった。 ビールが無いなら焼肉も道連れで「ナシ」である。 これはどう考えても、凹みまくるしかない。

そんな中、唯一の救いは、SUACに戻って事務局のメイルボックスに届いていた、上のDenisの新しい本「openFrameworks Esentials」である。 まだ1冊目の1/3ぐらいまでしか読み進めていないが、こちらも早々にザッと眺めてAmazonに英語で書評を書いて、さらに国内の学会等に紹介していかなければ・・・という新しい宿題が発生した。 そこでまずは、日曜日に予定されている社会人カラオフにドタキャンの連絡をした。 体調不良のドクターストップではないのだが、やはり僕には「飲まず歌い」というのは、あまりに悲し過ぎるので、ここは一転してストイックにこの悲しい境遇を満喫すべく、この土日は研究室に籠ってお仕事三昧することにしたのだ。 じっと堪えて投薬治療を済ませて、ちょうど来週末は音知学会で札幌である。 「すすきのでサッポロビールにジンギスカン、そして飲み歌い」というのを頭に描いて、ただただ大人しく来週を過ごそう。(;_;)

2015年5月30日(土)

凹んだ週末である。 昨夜は気持ちを切り替えて、普段なら絶対に飲もうとも思わない、以下のノンアルコールビールを仕入れて帰宅して夕食時に試してみた。 ノンアルコールビールなんてのは生まれてこのかた、親父を見送った火葬場での「御斎」の時に一度だけ飲んだが、その時の味なんて記憶に無いので、まったく初めてである。 以下のように、一応、黒ビールっぽいのとスーパードライっぽいのだったが、黒いやつは何故かトマトの味がしたし、いずれもお刺身と一緒の時だけソコソコ飲めたものの、やっぱり駄目だった。 ・・・結論としては、さらに凹んだ(^_^;)。

そして爪楊枝を使っていたら奥歯の小さな欠片が取れて、こりゃ明日(土曜日)には急遽、いつもの歯科に行かなくては・・・とさらに凹んだ。 大学に出て来ると、なんと昨日の夕方の時点で「さすがにこれは行方の圧勝」と言われていた将棋名人戦第5局が、何故か羽生名人が入玉(驚異の１九玉)して圧勝していたのを知った。 YouTubeに上がっているニコニコ中継動画(2日目の分だけでムービー5本、計9時間分)をザッと眺めつつ将棋スレを追ってみると、あまりに凄かったので 名局を求めて のページの最後に加えた名人戦第4局を上回る逆転劇だった。 ただし今回の棋譜は 名局を求めて のページに加えるつもりはない。 「なめちゃん号泣」 「持将棋を考えるか、詰ますことしか考えてないのが名人とA級1位との差だ」 「入玉されて負け、更に詰まされて負ける。一日に２度負ける奴」 「狐につままれたような将棋だった」 「こないだ行方の精神破壊したからな」 「若い芽を摘み続ける鬼畜眼鏡」 「渡辺が挑戦者にならない限り森内がかつてない衰えを見せてる今、羽生名人が永遠に続きそうだ」 「一年かけて羽生を倒しに来てる森内渡辺と一年中全ての棋士を殴り倒してる羽生とでは格が違う」 「さっき見たとき900くらいで行方有利だったが、羽生の場合ソフトの評価関数は参考にならん」 「散々攻めさせて入玉し相手の入玉はさせず持将棋にもさせず最後には確実に詰ましにいって勝ちきる。もう笑うしかない」 「俺たちは奇跡を目にしている」 「今回も北朝鮮もびっくりするぐらい無慈悲だったな」 「羽生さんにとってA級は名人から落ちたんで行く場所。守るとか上がるところじゃないらしい」 「若手の指導をしているようでいて同時に心も折ってるからなあ」 「羽生は生きながらにして既に歴史上の人物だ」 「行方八段の敗因は41歳という年齢。羽生名人は超人だから年齢関係ない(ファンタジスタ藤井)」 「羽生さえこの世に生まれてなければ、いろんな棋士がいろんなタイトルを取り合って、よーし次は負けないぞー！とかみんなでキャッキャ言い合う明るい世の中になってただろうに。平和な国が魔王に征服された状態だわ」 「駒を置く音だけは羽生に勝ってた行方 」 「森内との名人戦ではこんな盛り上げ方なかったのに、行方とはいったん劣勢に見せながらの逆転を四つもやるって。釈迦の手のひらと孫悟空状態だ」 「なんで勝てるのかわかんない感じがむしろ昔より恐ろしく思える」 「なんか大山風の妖力身につけてきてるよね羽生さん」 ・・・とコメント集をコピペしていたら、やっぱり 名局を求めて に加えたくなってきた。(^_^;)

さらにいよいよあと数日となった 葉から芽くん の希望者募集をWebに上げて、歯科に行き、ついでに耳鼻科にも寄った(鼓膜のアトピーを定期的に治療)。 そして、大学に戻ってここまでをまとめていた午後2時頃に、遂にSketching2015の詳細情報が届いた。 これを精読して今日から明日にかけて対応する必要があるので、今日はここまででおしまいとなりそうである。 凹んだ週末なので、これでも上出来だ(^_^;)。 さらに、なんか急な運動後の筋肉痛みたいな感じがあるので、「ピロリ菌 除去 抗生物質 副作用」と検索してみると、お腹が緩くなる、という言われていた副作用の他に「倦怠感」というのが出てきた。 なるほどこれか、と判ったが、そうすると来週一杯、凹んだ上に倦怠感で過ごすことになるのだ。・・・なんだかなぁ。

2015年5月31日(日)

昨日の夕方には、Denisから熱いメイルが届いて、応えて長く熱いメイルを返信したために、Sketching2015の詳細情報への対応はまるまる今日に持ち越しとなった。 朝に研究室に出てみると、Sketchingコミュニティの情報として、下の 新しいジェスチャセンサ の情報が届いた。 ドップラーレーザとリアルタイム解析システムの専用チップを開発して、空中の指先のジェスチャであらゆるIT機器の新しいコントローラとするという発想で、kinectよりもleap motionよりも小型である。 どうやらGoogleの研究チームの仕事らしい。 さすがである。

ただし、これはleap motionよりも到達距離が小さいので、ますますComputer Musicパフォーマンスのための「楽器」としては、leap motionよりも「使えない」ものなので、まぁ安心、というところもある。 ローテクだけれども古典的な電磁気学的(人体に浮遊する静電容量)距離センサのテルミン、そして赤外線とか超音波の距離センサの方が、身体を全部使った音楽パフォーマンスとしては、嬉しいのだ。 ちなみにCVのテクノロジーで認識性能は拡張しているものの、Wiiリモコンやkinectなどの画像認識センサも、いまだ心を許しきれない。 やはりここはCVはお勉強していくとしても、一つの軸足としてMyoなどの筋電センサを活用し、さらにtactile、じかに触りまくる「うにうにセンサ」を多重に並べる、というやつを進めていこう。

・・・そして午前中、3時間ほどかかって、Sketching2015の宿泊費用送金、帰途の空港近くのホテル予約、参加者全員が行うプレゼンの情報などを登録したが、ここで気付いたのが、ピロリ菌除去の抗生物質の副作用である。 もちろんお腹もかなり緩くなっているが、全身倦怠感というのが予想以上に実感できて、Sketching2015の対応を終えてみると、もうそこからopenFrameworksとかXcodeとかCVとかProcessingとかMaxとかに着手しよう、というヤル気が出てこないのだ。 これはなかなか面白い現象だが、まぁ仕方ない。 結局、ドタキャンしていたカラオフ会にドタ参すると表明して大学から徒歩で駆け付け、昼前から17時まで、初体験の「飲まず歌い」で計21曲を熱唱した。 これでちょっと未経験の不思議な週末はおしまいである。(^_^;)

2015年6月1日(月)

2015年も後半戦に入ってしまったこの日、ピロリ菌除去の抗生物質も7日間の4日目とだいぶ身体も慣れてきて(副作用のうち全身倦怠感はほぼ脱出したものの快調に下痢ピー(;_;))、新たな週のスタートである。 今週後半に葉から芽くんの新しい里親となる学生の希望はまだ満席になっていないので、これまでのゼミとアカペラから拡大して、講義ページに載せての告知も始めよう。

7月2-3日に1日半のワークショップを行う筑波大の内山先生からのメイルが届き、筑波大の皆さんからのリクエストとして 演奏方法から考えて新しい楽器を試作する というお題をいただいた。 主たる素材はなんと「段ポール」である。 素晴らしい(^_^)。 ちょうど僕も、多数の「うにうに」センサをどう並べて新楽器を作ろうか・・・と構想している最中で、まさにこのテーマは現在進行形なのである。 合わせて裏テーマではmbedというお題もいただいて、いずれも楽しみなことになってきた。

そして午前10時、締め切りとなって、今年の前期(7月)のCGクリエイター検定試験の受験者は上のように30人と確定した。 ここから、集めた受験料を持って暑いところを郵便局まで行き、20万円を越える高額振込なので免許証のコピーを取られてさらに書類を書かされて、送金手続きを完了した。 あとは当日の試験監督だけであるが、ここまでの段取りというのはけっこう手間なので、典型的A型人間でないと無理かもしれない。 後期のCGクリエイター検定試験(11月)については学会出張とのバッティングがあるので、以下のようなメイルをだいぶ前からメディア造形教員MLに出して打診しているのだが、まったく音沙汰が無い(^_^;)ので、たぶん1回スキップ(SUACでは開催せず)となりそうである。

これまで約10年間、CGクリエイター検定の団体/会場責任者としてSUACを団体登録して担当してきました。
毎年2回(7月・11月)の試験のたびにポスター広報、受験手続き(受験料をとりまとめて郵便局から送金)、試験会場
手配、当日の試験監督(補助は院生バイト)、答案送付、結果配布・・といった仕事です。
最近では前期に受験する学生が多く(例年20名から30名)、後期は募集期間が短いこともあり数名とかです。
そして現在、前期(7/12(日))に向けて、学生が次々に申し込みをしているところです。
ここで皆さんに打診したい事が2点あります。

(1)もう私は10年以上やってきましたが、このあたりでどなたかにバトンタッチをお願いしたい、という事です。これは過去の
学科会議でもチラッと申し上げていることです。ご希望の方はどうぞ手を挙げて下さい。いつでも待っています。(^_^;)

(2)こちらは単発の依頼打診です。今年の秋ですが、開催の11/29(日)は、私は学会出張の予定があり、担当できません。
このままだと、この秋だけSUACでの団体受験はスキップとなります。その場合、受験したい学生は自分でCG-ARTS協会の
Webサイトから申し込み、受験料も自分で振り込み、浜松からの最寄りだと、静岡か名古屋の会場まで受験に行くことに
なります。これを、SUAC団体責任者ごと全て臨時にバトンタッチして引き受けていただける先生を募集したい、という打診です。
試験当日の監督者だけ、というのはNGです。誓約書を出し、当日朝8時前に会場着のWeb報告をして・・・と多くの責任が
ありますので、受験料の回収・振り込み送金から全ての業務を担当していただかないと、当日の監督だけの代打では、何か
あった場合に責任問題となるので、当日の監督だけはお願いできません。
上記の(1)に移行していただければbestですが、今年の秋の試験をSUACの団体責任者を完全に交代して全て引き受けて
いだたくことが必須です。やってみたい、という方はどうぞ手を挙げて下さい。何もなければこの秋はSUAC開催はスキップします。

そしてここから、いくつもの懸案を切り崩していくことにした。 宿題というのは常にpriorityが変動するのだが、とりあえず現在抱えている案件でpriorityの高そうなものとしては、「DenisのopenFrameworksの2冊目をザッと読んでAmazonにreviewを投稿する」・「DenisのopenFrameworks本(1冊目)を最後までチェックする」・「ProcessingのOpenCVライブラリを調べてチーム[うみうし]にサンプルを提供する」・「この週末の音知学会のためのプレゼンを作る」・「その翌週の京都市立芸大でのワークショップの準備をする」あたりである。 これだけでも満腹だが、一番「見えていない」のは「ProcessingのOpenCVライブラリを調べてチーム[うみうし]にサンプルを提供する」であり、ヘタにハマると時間を大幅に消耗するリスクがある。 Denisへの返信メイルではちょっと下駄を履かせて「ここ1-2週間のうちにAmazonにreviewを投稿するよ」と書いておいたので、いきなり2冊目でなく、まず1冊目を最後まで(あと2/3ぐらい)進めておく、というのが当面の作戦なのだ。

・・・というところに、「半日*2」のワークショップテーマを打診していた、京都芸大・構想設計の学生からメイルが届いた。 「昨年、Arduino、スピーカー、加圧センサーを使用した作品をつくったのですが、センサーや情報量などの要素を増やしていくと制御がうまくいかず失敗してしまいました。基本的なことが分かっていないので基礎から解説していただけると嬉しいです」「また、LEDの制御について理解できず昨年の作品では光を使用できなかったので、ワークショップ楽しみにしています」とのこと。 これは貴重な情報で、このあたりが多くの学生の引っかかってくるという、いいテーマである(^_^)。 以下のように返信すると、速攻で「まさにそれです」というリプライがあり(^_^)、このセンで行くことにした。

Arduinoのサイトなどのサンプルは、話を簡単にするために、
「1個のLEDを点灯させる」
「1個のセンサを監視する」
みたいになっていますが、実際に具体的な作品に応用しようとすると、
　・たくさんのLEDを点灯させたい
　・たくさんのセンサに反応したい
　・プログラミングが下手で重く(遅く)なる
というあたりの「壁」に突き当たります。これはまぁ、色々なテクニックとコツがあるので、なるべく伝授したいと思います。

上記の状況だと、まずはおそらく、たくさんの要素(入力[センサ]、出力[LED、スピーカ等])を組み合わせてリアルタイムに
動作させるという「時分割多重化」というものが大きな壁になっているものと思います。半日*2だと、そこを突破するだけでも
その半分ぐらいかかります。

あと、標準的なArduino Unoだと、たしか
　・センサ(アナログ電圧)　6チャンネル
　・ディジタルポート　12ビット　(うちPWM[連続値]のLED出力が6ビット)
だったかと思います。「たくさん使いたい」については、この数の範囲内でいいのか、それとも外部回路を追加してもっとたくさん、
例えば
　・センサ(アナログ電圧)　24チャンネル
　・ディジタルポート　24ビット
とかに拡張するのか、でハードの難易度が変わってきます。「標準的なArduino Unoが持っているポート数の範囲内で、それらを
同時にたくさん使いたい」という事でいいでしょうか。ここは確認しておきたいです。

LEDの制御についてはたぶん、例えばArduinoのポートとしてPWM出力で連続値制御(ON/OFFでなくじわーっと変化)して、
そこにLEDリポンのように多数のLEDがあるやつを繋いで一斉に同じようにじわーっと変化させたい・・・というような事ではないか
と思います。こういう感じです。
	http://www.youtube.com/watch?v=Af210cqoh5c
	http://www.youtube.com/watch?v=991jm_JEWIQ
	http://www.youtube.com/watch?v=Z4fgXdpbkmY
	http://www.youtube.com/watch?v=ZC_pI9Q-O8Q
	http://nagasm.org/1106/installation3/kabayama.mp4
これは、Arduinoに直接LEDを繋ぐと、ドライブできる電流の制限からポートごとにLEDを1個程度しか繋げないので、ドライブ
回路(トランジスタ1個でOK)を入れれば、一気に表現力が拡大します。このあたりを伝授すると、美味しいでしょうか。
ちょうど上のYouTubeの作品のような感じで、最大6個の赤外線距離センサで体験者の近接を検知して、最大6系統のPWM
ポートからドライブ回路を経て、6種類の別々に光る多数のLED、というようなことであれば、半日*2でもなんとかいけると思います。

「スクリーンのシルエット」関連情報

「スクリーンのシルエットと同じポーズをするとストーリーが進む」というテーマを掲げたチーム「うみうし」のCV調査という宿題に関しては、まず、日本語「シルエット」の綴りがGoogle翻訳で「Silhouette」と判明し、YAHOO.COMで「Silhouette kinect processing」と検索してみると、出るわ出るわ、 Kinect Physics Tutorial for Processing とか、 Silhouette depth image using Kinect とか、 How to play a movie inside a user's silhoutte using kinect とか、 Kinect Silhouette and Kinect dot cam using Processing とか、 Robust Silhouette Extraction from Kinect Data とか、 Using the Kinect with Processing とか、 Kinect and Processing とか、 Getting Started with Kinect and Processing とか、 http://processingforum.blogspot.jp/2013/09/kinect-silhouette-with-particles.html とかが出てきて、関連した(ヘタするとそのものずばり)動画も、 これ とか、 これ とか、 これ とか、 これ とか、さらに下のような ここら全部 とか、多数を発掘した。 これはもう、この情報から調べる、というのは学生のまさに課題なので、既に僕の宿題としてはオシマイ、「解決」だ(^_^)。

・・・ここで1時半となり、次の4限には「サウンドデザイン」でGarageBand2週勝負の前半戦(リアル音源編。後半戦はソフト音源編)なので、ここから中途半端にopenFrameworksを進めるのでなく、講義に向けてテンションを上げつつ気合いを充電するために、コーヒーを淹れて(やっぱりドリップコーヒーは美味しい(^_^))、しばし瞑目瞑想した。 カフェインとともにウトウト昼寝、というのは1本勝負の講義前の細やかな贅沢である。 そして、オープンキャンパス2015スタッフ募集に1番乗りで申し込みしていた高田花波ちゃんから、これまでやった事のなかった「GarageBandリアル音源のデモ」(ウケ狙い100%)のアイデアを思い付いた。

・・・ところが実際にやってみた際に、サンプリングしたサウンドトラックを複製して、片方のボリュームを0%→100%、もう片方を100%→0%とすることで音像を移動させるところを、それぞれトラックのパンポットをいじったために、結果としてミックス音像は動かない、という間抜けな結果になってしまった。やはり不調だぁ(^_^;)。 そして夕方になって、「125万人の個人情報流出＝職員端末にサイバー攻撃 - 年金機構」というニュースが流れてきた。 今夜というか明日以降に大騒ぎになること確実だが、とりあえずこの第1報に対して「自演」に1票、とここで記しておこう。

2015年6月2日(火)

人間の身体の適応能力とは凄いもので、ピロリ菌除去の抗生物質はあと3日続けるのに、副作用がほぼ消えてきて、つまりは「慣れて」しまった。 今朝は5時起床、6時に研究室に出て葉から芽くんの濡れティッシュを交換した。定点観測カメラに対する位置がちょっとずれたが、ここまで来ればもう誤差である(^_^;)。 インテルがアルテラを2兆円で買収、というニュースは業界の人にしかインパクトが無いし、たいしたお仕事メイルも届いていない事を確認して、今日はガンガンにopenFrameworksの残りを攻略することにした。 以下のように、「05-Video」の2つ目から、という状況である。

この章はビデオを対象としているが、サンプル素材のムービーがあまり面白くないので、とりあえずサンプル素材を差し換えるところから始めた。 以下のように、2本のサンプルムービーのサイズは「640×480」と「800×480」と異なっていてフレームレートはいずれも25fps、QuickTimeで「フォトJPEG」の圧縮となっている。 Max/jitterとの比較を考えれば、例えばMP4が再生できるかどうかも試してみたいところである。

そこで、ビデオのopenFrameworksサンブルのチェックを楽しく過ごすために(これは今後、「音楽情報科学」の講義のjitter解説でも使える)、見栄えのするサンプルmovieを作ることにした。 以下のように、教材用HDDに格納されているムービーは現在、4492本で計295GBほどである。 品質を落として多数の教材を格納するためにほぼ全てのmovieはMP4で(一部はFLV)、フレームレートも15fpsにしているので、激しい動きの動画ではかなり画質が低下するが、DVDからそのまま無圧縮のQuickTime Movieにした場合に比べて、ファイルサイズは100分の1ほどに圧縮されている。 見栄えと言えばやはり「ももクロ」か「橋本環奈」だろう、という事で、以下から各2本ほど抜き出して、サンプルmovieに変換した。

・・・しかし驚いたのは、1本が20秒、1本が1分、あと2本が各1分半ほど、と短いムービーのつもりだったのに、QuickTime7ProでMP4から「フォトJPEG」で書き出したmovieのサイズがそれぞれ80MB、150MB、各250MBほどになった事である。 忘れていたが、「ムービーのファイルサイズはデカい」のだった(^_^;)。 研究室WiFiでなくLAN経由のファイル共有だというのに、計775MBの転送には12分ほどかかった。 「フォトJPEG」の品質をBestにしたのが敗因だと思うが、今時のパソコンで250MB程度のmovieがサクサク流れないようでは失格なので、openFrameworksの実力を試すためにも、このまま行くことにしようかなぁ。

この転送に時間がかかっている合間に思い付いて、この4本のサンプルmovie素材(サウンドはOFFのサイレント)を、色々なオプションでエクスポートして、サイズを調べてみることにした。 条件は以下のようなものである。

• 4本全て、サイズ「640×480」、15fps、サイレント
• 元movie - QuickTime、「フォトJPEG」圧縮、jpeg品質「Best」
• movie[a] - QuickTime、「フォトJPEG」圧縮、jpeg品質「High」
• movie[b] - QuickTime、「フォトJPEG」圧縮、jpeg品質「Medium」
• MPEG4 - QuickTime、「H.264」圧縮、Encoding Mode「Best quality (Multi-pass)」、Streaming OFF

すると、4本いずれでも劇的にファイルサイズが違ってくることが判明した。 以下の例はもっとも短い(19秒)ムービーだが、jpeg品質「Best」では82.7MBなのにjpeg品質「High」にすると29.8MB、jpeg品質「Medium」にすると18.3MBとなり、H.264のMP4ではなんと2.6MBであるが、パッと見たところでは画質の違いは感じられない。 もう1本の橋本環奈(1分7秒)ではさらに劇的で、jpeg品質「Best」で263MBがH.264のMP4ではなんと8.7MBである。 こうなると、openFrameworksでのサンプルは無駄にデカいものは本当に無駄なので(^_^;)、「Medium」品質の[b]を使うことにした。

そして、改めて4本の「Medium」品質のサンプルmovie素材をMacBookAirに転送して、前回やっていた「01-VideoPlayback」のサンプルの参照動画の部分に差し換えて(binフォルダの下のdataフォルダ内に置く)、以下のようにちゃんとループmovieが再生されることを確認した。 お気に入りの素材を使えば、やっぱりテンションが違うことまで確認した。 だいぶ遠回りしたが(^_^;)、ここからスタートである。

上の「02-VideoVerticals」は、せっかくの素材動画が判らなくなってしまっているが、元動画の高さ中央のラインで横方向の画素を検出して、それを各ラインで画素の縦方向に並べたものである。 何やら動いているが、この動画からあの橋本環奈のCM動画だ、と見破るのは、よほどのオタクでも無理だろう(^_^;)。 インタラクティブに制御できるのかと思って、projectGeneratorでフロジェクトを作る際に「oxOSC」をONにしたのだが、ここでは使えないので、また以降のサンプルでトライしてみよう。

上の「03-VideoReplacingColors」は、まずsetup()において16要素の粗いカラーテーブルをランダムに設定しておいて、draw()では元の動画の各画素のRGB値をそれぞれ16で割ってこのカラーテーブルを参照した色に変換して描画している。 その結果、まったく元画像の色合いとは異なるものの、動画において「似た色」がそれぞれ似たような色に変換されて、そのつもりで見れば確かに「橋本環奈のあのCM動画だ」、と判る。 人間の動画認識能力にもかなり依存している、面白いサンプルだと言える。

上の「04-VideoSlitScan」は、最初は何も起きない静止画のように見えたが、マウスカーソルを動かしてみると、画面内に過去のフレームの動画が同心円状にクラデーションで混じってきて、なかなか不思議な効果だった。 ただしかなり重くて、もたもたと動く。 Denisの本によれば、このサンプルはかなりCPUパワーを使うので、DebugモードでなくReleaseモードで動かすことを推奨する、とあったが、このモードがXcodeのどこにあるかが判らなかった(^_^;)。 XcodeをQuitして、ビルドしたバイナリ(アプリケーション)を直接に実行させても、この重くてもたもたと動くのは変わらなかった。 ネットであれこれ「Xcode Release mode Debug mode」と検索したが、出回っている情報は過去のバージョンのXcodeなので書かれたメニューやタブが存在していないなど、結局、これは判らないまま断念バーグした。

上の「05-VideoCameraSynth」は、いよいよライブビデオカメラをソースとする、というサンプルなのだが、ここにきて何故かエラー(Warning)が出て、詳細不明ながらももクロ動画も指定しているものの、MacBookAirの内蔵Webカメラの画像が出るだけで何もSynthされなかった(^_^;)。

上は、同じサンプルのsetup()にある、grabber.setDeviceID(0)をgrabber.setDeviceID(1)としたもので、USBに接続した外部のWebカメラの画像に切り替わったところである。 Warningは同じもので、「QTKitGrabberでframe rateがset出来ませんよ」というもので、その後のWarningはおそらく、正しく定義できなかったので、openFrameworksのofGLRendererがここにテクスチャを貼れない・・・というものなのだろう。 そこで、setDesiredFrameRate(30)となっていた数値を「15」「10」「1」と変えてみたが、内蔵カメラでも外部Webカメラでも、全てWarningが同じように出て、変化がなかった。

そしてあれこれ探してみて、遂に上のように、「QTKitGrabber」というところにWarningを発見した。 つまり、またまたここで出てきたのは、「OS10.9以降ではサポートされなくなりますよ」というアレである(^_^;)。 この日記(かpart1)のどこかに書いたように、Max OSX10.10.3のXcode6.3.1では、projectGanaratorで新しいプロジェクトを作った時に、「OS10.9以降ではサポートされなくなりますよ」という膨大なWarningとErrorが出るのを暖かく無視するために、いったん出来たプロジェクトをどこか別の場所に移動させてダミーでビルドしてエラー(ビルド不成功)を出してから、そのプロジェクトを元のprojectGanaratorが作った場所に戻すと、ちゃんとビルド成功する、という「おまじない」を見出した。 これと同じで、Denisの本が出た2013年には、まだOSXが10.7とか10.8で、Xcodeもたぶんバージョン5だったので、将来に出てきたこんなトラブルは予見できるわけが無いのだ。

ここで昼休みを跨いだが、その間に上のようなツールを発掘して改編してインストールした。 openFrameworksのビデオサンプルを走らせていたら、だいぶMacBookAirが熱くなってきたので、CPU温度を計測するツールを入れたわけである。 過去にはフリーのアプリで色々とあったものの、どうもOSX10.10に対応していないらしくて、iStatというのだけ見つかったが、これは「フリー(無料)」とあるのでインストールしたら、なんと2週間で有料に切り替わるものだった。 そこでこれを消したところ、どこかにゾンビのように残っていて、消しても消しても再起動すると再び蘇ってきて気持ち悪かったので、さらにネットで「iStat remove」と検索して確実な殺し方を発見して、ようやく抹消することが出来た。 これに懲りて、簡単なC言語のツールのフリーの温度計を探し出し、オプション無しで動く(エイリアスの)アイコンを叩けば良いように改編した(ソース中にある赤い矢印の部分が、追加した1行)のが、上のツールなのである。

ライブカメラがopenFrameworksで掴めないとすると、ちょっとCVに暗雲が漂うが、とりあえず「05-VideoCameraSynth」をテストしたプロジェクト「test24」はそのまま放置して、同じソースから作ったプロジェクト「test25」では、上のようにカメラのGrabberの代わりに、両方のソースをビデオとしてみた。 すると、カメラを掴むというエラーは出なくなったが、その後のテクスチャを貼るという「ofGLRenderer」のエラー(warningだが何も起きないので実質的にはerror)がズラズラと出た。

・・・そしてさらにみっちりとソースコードを眺めて、遂にバグを発見して、上のように、カメラの問題は別として、2つのムービーの画素の間の処理という、このビデオエフェクトでやりたかった事を実現できた。 「ofGLRenderer」のソース中にWarningが出ていないことを確認して、これは上のトラブルとは別だ。と確信して探した結果である。 表示されるムービーウインドウの位置がおかしいので正しくwidthを取得できていない・・・という推理から、Grabberチェックのループ内にあってうっかり一緒に消していた「synthesizeImage()」を発見して復活させた、というだけであるが、朝から集中してXcodeしてきたからこそ、の発見だ。 ちょうど2時半となり、なんとか4限の「企画立案演習」に行く中断を跨がずに、この問題までクリアできた。 これで放課後にアカペラがあって気持ちよく帰宅するとすれば、普段なら晩酌のビールが旨いところなのだが、あと3日、我慢我慢我慢(;_;)である。

そして15時半、研究室に戻ってきてコーヒーとともに、最集合の17時まで、ちょっとだけ再開である。 抗生物質の副作用に上がっていた「味覚異常」というのもなく、ドリップコーヒー(いつもブルックスの「モカ」200袋入り段ボール5000円を箱買い)が実に美味しい(^_^)。 上の「06-VideoImageSequence」は、片方はムービーで、その上に静止画のコマ送り(ストップモーションアニメーション)を重ねたサンプルとなっているが、地味に今後に活用できるのは、データの入ったディレクトリを指定する方法のところだろう。 これで「05-Video」の章が終った。

そして次は「06-Sound」の章である。 上のように、それっぽいサンプルのタイトルが並んでいるが、Soundsフォルダ内に置かれたwavファイルを鳴らしてみると、とても期待できない(^_^;)ものばかりだった。 どうなるのだろう。

上は、「01-BouncingBall」である。鉛直方向については床の反発係数が1の放物運動(完全弾性衝突)であり、水平方向については衝突のたびにランダムな初速度を設定していて、ぶつかったたびに、その水平方向の座標に対応したピッチ(右ほど高いピッチ)で減衰音の波形を読み出しているようで、高い(右側)方では波形データが終わりとなって音が微妙に切れていた(^_^;)。

上は、「02-SingingVoices」である。鉛直方向については床の反発係数が1の放物運動(完全弾性衝突)であり、水平方向については衝突のたびにランダムな初速度を設定していて、ぶつかったたびに、その水平方向の座標に対応したピッチ(右ほど高いピッチ)で減衰音の波形を読み出しているようで、高い(右側)方では波形データが終わりとなって音が微妙に切れていた(^_^;)。 QuickTimePlayerXのレコーダで、内蔵スピーカから出ている音を内蔵マイクで録音したのが このサウンド であるが、時間的に6つのボイスの音量を変化させているとしても、ちょっとチープ過ぎて寂しくなった。 Propeller日記(3) にあった、全てのディジタルオーディオサンプルごとに、フォルマント要素と楽音要素を刻々と演算している、まさに文字通りに直球の歌声合成による「ボイス」デモ、 これ とか これ とか これ とかに比べて。あまりに安易で低水準の「サウンド」機能に、期待していなかったとしてもちょっとがっかりした(^_^;)。

2015年6月3日(水)

「125万人の個人情報流出＝職員端末にサイバー攻撃 - 年金機構」というニュースの続報として、年金データベースにアクセス出来る所内PCがインターネットにも繋がっていて(この段階で致命的に失格!)、そこに届いたウイルスメイルを職員が開いて感染した(これだと感染PCを外部から遠隔操作で乗っ取って年金データベースにアクセスする高度なステップが必要)というだけでなく、所員がこのPCに年金データベースから取ってきたデータを保存していた事(→超簡単にそのデータをウイルス指定先に送れるので致命的にあり得ない!)、さらにそのうち55万件にはパスワード保護もしていなかった、という事実が判明した。 これはもう、失格とか謝罪とかいうレベルではない。年金機構は解体して、天下りの役員は市中引き回しの上で獄門モノである。 既に多数の年金機構職員なりすまし電話が高齢者に殺到していて、家族など関連個人情報もどんどん獲得できて、さらに「流出したデータを消してあげます」詐欺が大流行するだろう。 名簿業者・詐欺業者にとって垂涎の確実な年金受給者個人情報、1件100円として125万件ならディスカウントしても1億円である。 これはもう、ほぼ確実に「面倒な年金業務をチャラにしたい機構の自演」または「内部関係者がお小遣い稼ぎに加担」のいずれか、と予想しておこう。

今朝はあまり緊急のメイルは届いていなかったが、去年のNIME2014(行けなかった(;_;))をorganizeした、友人のAtau Tanaka氏が、NIME2014のパフォーマンス・ダイジェストの動画をNIMEコミュニティに提供した。 まだ最終版ではない暫定版とのことだが、今日の「音楽情報科学」の講義の中で、この4分ほどの動画を鑑賞することにしよう。 サイズを縦横1/4に、さらに15fpsに圧縮したバージョンは ここ にコッソリ、置いておくことにする(^_^;)。

1限の「音楽情報科学」は朝からの雨のためか欠席者が多くてNIME2014動画も観れずちょっと凹んだが、出席者はそれぞれの収穫があった。 出席不足で単位を落とすのは本人の自己責任なので何も言えない。 ただ、「スクリーンのシルエット関連情報」として紹介していた「Silhouette + kinect + processing」の情報リンクについては、マルチメディア室のiMac(OSX 10.4.6)ではライブラリのエラーが出て SimpleOpenNI が使えない、と判明した。 こうなるとProcessingでなくMax/jitterで攻略する必要がありそうである。

そしていよいよ2限のゼミである。 今週は体調不良のブンちゃんに加えて、1限から連続で無断欠席の石井+佳奈子と3人が欠席ということで、前澤+藤石+杉浦+長嶋、という4人の勉強会となった。 7月の筑波大ツアーに関する情報交換に続いて、上のように、まずは僕のopenFrameworksの進捗報告で、ここまでチェックしたサンプルをザッと走らせた。

そしてこれに続いて、せっかくなのでopenFrameworksのコンパイルの様子を見せる、ということで、上のようにサウンドの章の「03-PWMSynth」を実際に実演した。 ちなみにこれは僕が、尺八の大師範、箏の師匠、笙の演奏家などを引き連れて2001年9月(あのセプテンバーイレブンの翌週(^_^;))にフランス・ドイツに行った 欧州ツアー のKasselとHamburgでのコンサート最後のために作曲した、尺八と箏と2本の笙(440Hzと445Hz)とライブ電子音響のための作品"Japanesque Germanium" ★ ★ の、僕の電子音響パートのためのSuperColliderプログラムと酷似していて、左右方向がピッチであり、上下方向が音色変化のためのPWM値になっている。 さらに、openFrameworksで重いプログラムでパソコンが熱くなる、という流れから、上のように、僕が改訂制作した「 CPU温度計 」を皆んなにも配ろう、と「Unixのターミナルでの操作」勉強会へと発展した。 ただしうまくコンパイル出来ない問題が一部で発生して、これは杉浦さんの来週までの宿題となった。

最後は上のように、いつものように藤石さんを講師としてのUnity講座だったが、今回は欠席者も多いのでちょっとだけ進むことにして、前回のシーンで物体が床に落ちて静止していたのを、それぞれに物理特性を持たせることにした。 僕のサンプルでは、反発係数を最大の1として、また摩擦を全てゼロとしたので、いわば水晶の球体が水晶の床に落ちて跳ね返るような完全弾性衝突となった。

そして何より、今回の最大の収穫は、Unityのテストはアニメーションなのでスクリーンショットのコマ撮りでは雰囲気が伝わらなかったのだが、なんと上のように、QuickTimePlayerXに標準のレコーディング機能には、「Webカメラの動画」と「マイクでの録音」だけでなく、なんと「デスクトップをそのまま動画化」できる、と知った(^_^)。 この機能で撮ってみたUnityのテストのデスクトップ動画が これ である。

そしてちょうど今、まさにこのサンプルとして、お仕事MacにWebカメラを繋いで自分を撮りつつ、さらにこのページのHTMLをじかに手打ちしている様子をそのまま録画してみている。 僕の手打ちのスピードは「かな入力」で、こんなものである。(^_^;) 上はその様子であり、このテストのデスクトップ動画が これ である。

・・・ここまでで膨大な写真とスクリーンショット、さらにデモmovieまで並んできたので、まずは整理してWebに上げていたら3限が終ってしまった(^_^;)。 しかしせっかくなので、ゼミで皆んなに見せたopenFrameworksのデモの一部を、1本撮りであらためて動画として撮ってみたのが、上の これ である。 このデスクトップ動画がかなりの効率で圧縮されているというのはゼミの場で学生たちと確認していたが、さすがにこれは5分40秒と長くてデカくなった(190MB)ので、YouTubeに上げてのリンクとした(^_^;)。

そしてここで、上のように今週末の札幌での日本音楽知覚認知学会2015年春季研究発表会でのプレゼンをまったく準備していない(^_^;)、と気付いて、まずは自分がどんな予稿を書いていたのか、を読み直した。 すると、 今回の予稿 は、けっこう力が入ってよく書けているものだった(^_^)、と自画自賛的に判明したが、とてもこの内容全てを質疑を含んで25分のプレゼンにはまとめられない、と気付いた。 あちこちばっさりとカットして行くか、いっそのこと、ときたまある「プレゼン省略」(この予稿PDFを拡大表示するだけ)というパターンで、Myoでのデモ実演を中心に据えるか、なかなか悩ましい。 たまたま今回の研究会では、1日目の土曜の午後にまるまる前半のセッションがあり、そして僕の発表は2日目の午前のセッションの最後である。 これは経験的に、「研究会に参加してその場の空気を読みつつ、現場でプレゼンを作る(^_^;)」というパターンがbestだ、というナメた結論になった。 なんせ手持ちに世界にこれだけというMyoジェスチャ認識システム(リサジュー解析version)があるので、時間が余ることだけは絶対に無いのである。

ここで安心して、サウンドの章の次のサンプル、上の「04-ImageToSound」をやってみた。 これはライブカメラの動画(何故かこのサンプルではWarningが出なくてちゃんと使える(^_^;))の水平線の部分の画素情報を2次元データの縦軸として、画素のx座標を横軸としたグラフを「波形」と見なしてサウンドとして再生する、というものである。 ただし、コンパイル成功したものを再生するとしても、デスクトップ動画がそこそこ大きくなり(30MB)、これをいちいち YouTube に上げるというのはかなり面倒である、と判明した(^_^;)。 しかし、いくらスクリーンショットをコマ撮りしても、この様子はなかなか伝わらないが、たった1分間、35MBの動画でその関係性・仕掛けが明確に理解できるのだから、やはり、動画というのは凄いメディアなのだ。 今後は、本当に動いている瞬間だけを短く撮って、YouTubeに上げずに静止画と同じ並びにしていこう。

ということで、上はサウンドの章の「05-LoopSampler」である。 マイクからライブ入力したサウンドの音量波形を表示しつつ、用意された画像をそのピッチに対応して水平方向に引き伸びして表示するというもの。 ただし、サウンドの無いデスクトップ動画に撮っても関係性がわく判らないので、これは撮影を省略した。

そして上はサウンドの章の最後、「06-DancingCloud」である。 サンプルとして付録されていた音楽に合わせてリアルタイムCGが変化する、という、つまりは音楽再生ソフトのビジュアライザそのものである。 これについては、せっかくなのでゼロからDenisの本のWebサンプルを、Mac OSX10.10.3でエラーなくコンパイルするための「おまじない」まで含めて、ちょっと長いデスクトップ動画を撮って、YouTubeに openFrameworksコンパイル手順 として上げてみた。
projectGeneratorで作ったプロジェクトをまずは作られた場所と違うところに移動してダミーでコンパイルエラーを出してから元に戻すこと、サンプルそのままではエラーとなるので一部を変更することなど、しばらくして忘れた場合には、これを観れば思い出せるだろう、という保険である。 このサンプルは初見だったので、コンパイルの最初はマイクに声を入れてもウンともスンとも変化せず、ソースとツールを眺めてサウンドファイルが無くてエラーとなったのを発見して、探して移動させて無事にサウンドに同期してCGが踊り出すあたり、なかなかのドキュメンタリーだ(^_^)。

2015年6月4日(木)

昨日はその後、明日の某プロジェクトに関してのやりとりなどしていると、2015年6月号の電子情報通信学会誌が届いた。 なんと「小特集 音楽情報処理技術 ---分析から合成・作曲・利活用まで---」がメインであった。 それぞれの項目の著者は、だいぶ音楽情報科学研究会の世代交代を受けて若手にシフトしているが、パラパラと眺めてみると、概説企画だし、まぁ僕は業界内部にいるので仕方ないが、目新しいものは何も無かった。 だからこそ、まだまだ音楽情報科学研究を続ける意義があるのだ。 特に「作曲」の部分では北原さんと菅野先生が書いていた項目が該当するが、前者の最後、「自動作曲・自動編曲研究の課題と今後の展望」の、要するにまだまだ入口以下だよね・・・という話、これはデジャヴとしては35年前にも同じ事を皆んなで話していたよなぁ・・・という状況だった。 ずっと昔から僕は言っている(そして反発されている(^_^;))が、要するに「耳の無い奴は生成的音楽情報科学研究をする資格が無い」のだ。

今日も朝5時に起き、朝6時に研究室に出て来て、朝日に輝く葉から芽くんの一部は、以下のように葉が2層目へと発展していた。 明日にはそれぞれの引き取り先に旅立つ。

今日は午後に某プロジェクトの予定があるので午前中勝負だが、既に作戦は出来ている。 Denisの新しい本「openFrameworks Esentials」についての書評を書いてしまう、という目標である。 昨日まででDenisが2013年に出した1冊目の本「Mastering openFrameworks: Creative Coding Demystified」は第6章のサウンドまでが終わり、残るは「3D Drawing」「Shader(OpenGL)」「OpenCV」「Kinect」「OSC」という実戦的な章があるものの、既にこの本の半分以上を消化してきた。 ここで判ったのは、openFrameworksというのはその名の通り、色々なFrameworks(Xcodeのための特定目的のライブラリ集)をopen sourceでまとめているだけだ、という当たり前の事実だ。 Max/MSP/jitterをやっている、Processingをやっている、あるいはFlashをそこそこ使える者にとって、ここopenFrameworksで初めてまったく新しいものに触れる、という事は無いのである。 同等のことはMax/MSP/jitterでもProcessingでもFlashでも(より美しく簡単に高速に)出来るが、Xcodeということで実行環境が「普通のアプリ」になる、というのが違いだけなのだ。 これが判ってしまったので、Denisの新しい本(アーティストとの共著)については、ザザッと斜め読みすれば、もう書評は書けるという確信が持てたのである。

まずはAmazonに行ってみると、既にこの 新しい本 には、3件のユーザReviewが書かれていた。 分量もほぼ同じにコンパクトだし、おそらく、Denisの友人などだろう(^_^;)。 そして 1冊目の本 にはこれまでに9件のユーザReviewが書かれていて、僕が書いたものもあった。 しかし、かなり短期間に慌てて書いたので、以下のように、なかなか悲しい英語である(^_^;)。 ・・・まぁ、まったく嘘は言っていないし、最後に書いたように「この本でopenFrameworksに触れてみたいと思う」というのも、1年半ほど遅れたものの、まぁ日々実践しているところなので、間違いのないレビューではある。

Good textbook for programming and media-design

ByAmazon Customer "nagasm"on November 18, 2013
Format: Paperback

Since I really like this cool book, I recommend this book to young people who aim to media art.
I think the author of this book is a young and ambitious researcher. And he is enjoying - not 
only professional programming, but also difficult collaboration with artistic fields.
As a professor, I want to recommend this book to students who aim to media design.
For beginners, this is good text book of "C++ programming" for the first time, and this book 
is full of exciting samples - for performance, for installations and systems generating a 
multi-media in real time.
Because I have enjoyed "Processing", I did not have experienced "openFrameworks". 
But I am thinking that I will try to learn "openFrameworks" with this book.

そしてここから1時間ほど集中して、前回よりも多めに、それも熱くReviewを書いてAmazonにポストした。 すると1分ほどでAmazonからメイルが届いて、無事に以下のように 僕のReview がAmazonに載った(^_^)。 これでDenisとの約束の半分は果たしたことになるが、まだ8時半過ぎ、SUACは営業時間前である。

そしてここから、芸術科学会の会長であるお茶大の伊藤先生に、会員MLへの投稿を依頼する原稿を作ってメイルして、MACS-MLにも以下のような同様の紹介を流して、さらにせっかくなので、 僕のサイトのトップ にも、2冊の本のアイコン(直接リンク付き)を並べてみた。 そして、ここまでの進捗状況をDenisにメイルしたところで一段落した。

MACS-MLの皆様

お世話になります、SUACの長嶋です。

1年半前ほど前に、私の友人の研究者がopenframeworksでMedia Artsというあたりにfocusした本を出版しました。
「Mastering openFrameworks: Creative Coding Demystified」という本で、以下にこの本の情報があります。
http://www.packtpub.com/mastering-openframeworks-creative-coding-demystified/book

今回、この続編、というよりも、実戦的に「ビデオシンセサイザをopenFrameworksで作る(^_^)」という視点から、
たぶんVJ指向の若い学生さんたちに刺激的な教材として、芸術家と組んだ2冊目が出ましたので、紹介させていただきます。
「openFrameworks Essentials」という本で、以下にこの本の情報があります。
http://vimeo.com/125828431
http://www.packtpub.com/application-development/openframeworks-essentials
ちなみにこの著者の最近の仕事は以下ですので、これを眺めて興味のある方はどうぞ。(実験中もあり)
http://thecreatorsproject.vice.com/blog/walk-through-a-digital-house-of-mirrors-in-this-interactive-installation
http://www.youtube.com/watch?v=i8UbTtEOaXs
http://www.youtube.com/watch?v=JpPbCaUMRbU

なお、以下の私のページでこれらの本をチェックして日本語で書いていますので、寄り道が多いですが興味のある方はどうぞ。
http://nagasm.org/ASL/Xcode/

こうなると、このページまで見に来るような酔狂な人は少ないだろうが(^_^;)、なんとしてもDenisのopenFrameworks本、そして今回の「openFrameworksでVJ」本まで、ザッとチェックしていかなければならない事になった。 ただし明日からの週末は音知学会で札幌、来週後半は京都芸大で特別講義、その翌週末は電子情報通信学会研究会で新潟、その翌週末は名古屋方面に出張(RAKASUさんと武子さんのライヴ(^o^))、その翌週は筑波大へのツアー、と毎週の出張月間になる。 さらに来週には、応募していたpaperの採択結果が来て、これで8月にシンガポールに行くのか9月にリンツに行くのが決まってフライトやホテルを予約する、というどたばたも待っている。 いよいよ動きが出てきて、これまで束の間の「落ち着いてお勉強」シリーズから一転、お尻に火がつくのだ。

そして昼前には、しばらくdeep sleepさせていたMyoを目覚めさせてみるとバッテリはほぼそのまま満タンである事を確認した上で、音知学会でのデモに備えてのリハを、昨日、覚えたばかりの「デスクトップ動画」として記録して、 YouTube にして上げてみた。 やはり、ArmBandManagerを起動して、自作の「Myo→OSC」コンバータを起動して、その後にMaxパッチを開く、という手順から忘れかけていた(^_^;)ので、いい思い出しとなった。 なお、ここでのMaxパッチは以前のものから改良(1)していて、さらに今後の学会発表のためにもう1つの大きな改訂(2)も行う予定である。

(1)は、目玉であるLissajous解析に関して、8チャンネルの筋電情報から電極位置の異なる組み合わせとして32パターンを作っていたが、電極が「真裏」に来る組み合わせは重複していて、この4パターンだけ極性を反対にしただけの同じデータをダブルにカウントしている(そのままだと真裏の4チャンネルだけ距離空間での重み付けが2倍になる)、と気付いたので、これをカットして、重複のない28パターンで比較する、という懸案の改良だった。 そして、 このムービー を1発撮りした体感としては、32→28と処理スロットが減った上に全てのパターンが対等に評価されているためか、これまでで一番、認識能力が高かった(スムースに識別できる)ような気がした。 これは次の実験ステップでは、 EDAセンサ と組み合わせて、いわば「顧客満足度」という指標で被験者の反応を抽出して客観的に比較したいところだ。

そして(2)の改良とは、過去の研究(第4世代の筋電センサ+FFT)による、4チャンネル筋電+200バンドFFTというジェスチャ認識システムを、同じ条件とするためにMyo版として実装したいのだ。 これは元となる2つのシステムを統合するにしても、それほど簡単ではないが、一応、札幌に持参して、研究会の「合間に」(^_^;)挑戦する予定である。 ・・・と書いていたら、Denisからのメイルが届いた。 そろそろYekaterinburgも夜が明けたらしい。 「これまでのと違ってムービーが無音だけど・・・」というので、これは「デスクトップ動画」だよ、こちらの方がビデオカメラで撮って変換して・・・というより簡単なので、と速攻リプライで説明した。 地球を挟んで、ロシアと浜松での「ほぼチャット(英語)」である。(^_^)

午後には某プロジェクトのために某社のメンバーが1106にやってきて、夕方まで今日のステップを進めた。 その間に、Denisからは2本のメイルが届いた。 上のような写真とともに、 こんな作家の作品 ★ (拡張された テルミン みたいなもの?)とか、 Denisの学生の作品 (For tracking and visualization Processing is used, for generating melody - PureData is used, and it is played by virtual synth.)とか、の情報を受けとりつつ、こちらもリプライしていろいろ議論した。 一方で このムービー に対して「I see, your program learns point clouds of data-parameters (8-dimentional space of MIO), and then tries to classify new parameters data. Did you use some simple algorithm (nearest neighbourhood method, or just approximation of point clouds with mean and mean square deviation), or more complicated?」との質問を受けて、僕のリサジュー解析のノウハウを解説した英語の論文(国際会議に応募して審査中)をコッソリ提供してみた。 それぞれがある部分でほぼ先端を行く者同士のこういうディスカッションは、お互いにいい刺激になる。(^_^)

その後、昨日の「音楽情報科学」で、マルチメディア室のMacでは「SimpleOpenNI」がエラーで使えなかったのを思い出して、まず1106のお仕事Mac mini(OSX 10.7.5)で試してみたところ、上のようにマルチメディア室と同じメッセージでまったく同様にProcessingがクラッシュした。 これはまぁ、想定内である。

そして同じものを、今度は上のように最新のMacBookAir(OSX 10.10.3)に転送してやってみたところ、何事もなくちゃんと動いた。 つまりは古いMacに対応したライブラリ環境が、何か「悪さ」をしている、ということで、これが判明したことはそれなり に有効である。

ここから明日の出張に向けて、デジカメのバッテリを充電したり、2個のMyoを再びdeep sleepさせたりしているところに、実習指導の前田さんが葉から芽くんを引き取りに来て、2枚を持っていった。 遂に上のように定点観測の状況に大きな変化が生まれた。 明日の午前中にここは片付けることになる。

2015年6月5日(金)

いよいよ5週連続の週末出張シリーズ(札幌・京都・新潟・名古屋・筑波)の初戦である。 まずまず好天の朝6時半には研究室に出てきて、葉から芽くんの最後の写真を撮影して、4週間、28日にわたって定点観測連続撮影してきたWebカメラとMacBookをまずは片付けた。写真は6696枚、計220MBということになったので、USBメモリに回収してお仕事Macに持ってくるだけで20分以上かかる(^_^;)。 今日は2限の冒頭に、里親として名乗りを上げた石井さんと鈴木さんが1106に来て、残った5枚を渡したら、札幌に向けて出発する。

海外に出張する時には、セントレアを朝7時のフライトで成田に飛んで、ヨーロッパでも北米も午前発のフライトに乗り継ぐ(この国内乗り継ぎフライトは無料でマイルは貯まる)ので、いつもセントレア前の東横インに前泊して、そのためら浜松からはe-wing(高速バス)を使う。 ただし今日のように、フライト当日に浜松からセントレアに行くのにe-wingを使うというのは、東名高速などの万一の事故渋滞とかに遭遇すると行きつけなくなるので、リスク回避のためJRと名鉄を乗り継ぐことにしている。 今回の札幌では、帰途もe-wingでなくJRと名鉄で、午後の「サウンドデザイン」の講義に間に合うように月曜日に朝帰りする。 早目にセントレアに着いても、ビールでもWiFiでも何でも無料のラウンジ(ゴールドカード会員の無料特典)があるので問題ない。 ネットで「浜松→中部国際空港」と検索すれば、上のようにサクサクと候補が出てきて、これを1枚プリントすればいい、というのは本当にいい時代になったものだ。

出発前の朝のひと仕事として、上の定点観測連続撮影してきたMacBookのスクリーンショットにある6696枚のjpegを連結した定点観測動画(最近は「タイムラプス」と呼ぶらしい)を作ってみることにした。 といっても、新しくMax/jitterでパッチを作るまでもなく、2002年にCycling'74のKit CraytonがSUACに来て世界で初めてjitterを公開した時から、「jitter examples」には、ツールとして「image2movie」というのがあるので、僕の仕事はそれを探し出すことと、パラメータを設定してスタートすることだけなのだ。

そして上の場所にあることを発見した「image2movie」で、せっかくなので品質を「最高」の上の「ロスレス」にして、変換を開始した。 どのくらいの時間がかかるか不明なので、例の「デスクトップ動画」も一緒に撮ってみた。 2画面のお仕事Macなので、この「デスクトップ動画」を撮っている画面で刻々と変換している裏の画面で、ちょっと暗くなって見にくいものの、ネットニュースのチェックなど、お仕事は続けられるのだった。

最終的には上のように、約17分かけて、ロスレスて1.25GBというQuickTimeムービーが出来上がった。 作業の模様の デスクトップ動画 はとても地味であり(^_^;)、わずかに変化する部分と、あとは時計でも見るしかない。 後半から画面内にActivityMonitorのCPU負荷グラフを入れてみたが、2coreのCPUがそれぞれ100%で頑張っていて、画面上部のツールバーに表示されているCPU温度も、最初は45℃だったのが77℃ぐらいに上がるのも、なかなかリアルである。 ちなみにこのお仕事Mac miniは、常時、外からDCモーターファンで空冷している。 これはYouTubeに上げるにはあまりにデカいので、いつもの条件でQuickTime7ProでMPEG4に変換したが、元々が10fpsなので、 タイムラプス動画 は10fpsにしたところ、サイズは86MBになった。 よーーく見ていると、この4週間のタイムラプス動画(11分9秒、6分ごとに1コマを毎秒10コマ再生しているので1時間が10秒に圧縮されている)の中で、葉から芽クンがじわわっと伸びていくのが「見える」。 タイムマシンである(^_^)。 そして、11分を見ているのが待てない人のために、この動画のカーソルをマウスでえいやっと早送りした ダイジェスト動画 も作ってみたが、ここまでくると、完全に植物がうにうに動くコマ撮りアニメーションである。 ここで1限の時間となったので、openFrameworksとXcodeについては、可能であれば道中に進めてみることにして、パソコンのパッキングなどの作業に移った。

10時半を過ぎると石井さん鈴木さんが1106にやってきて、葉から芽くんを渡してスグに研究室を出て、バスで浜松駅に向かった。 そこからJRと名鉄でセントレアへ、ラウンジで軽く2週間ぶりのビール(^_^)、そして新千歳空港に向かうフライトの機内でもハイボール、JRで札幌駅へ、地下鉄ですすきのの宿へ、と予定通りに移動したが、詳しくは別途に旅行記Webに写真を上げることになるだろう。 その後、晩の某mixiの突発カラオフでどのくらい快調に飲んで歌ったかについては秘密である(^_^;)。

2015年6月6日(土)

そして音知学会の研究会の1日目となった。 ちょっと肌寒い瞬間もあるが、雲間から日差しがあると心地よい、まさにヨーロッパのような気持ち良い日である。 最終的なプログラムでは発表申込件数があまり多くなかったためか、スタートは午後イチとなったので、午前中に札幌をちょっとだけ散歩した。 市電で藻岩山ロープウェイに行ったところ、なんと運行は10:30から、ということで(到着したのは09:45頃)、そこから登ってゆっくりすると研究会に遅れそうだ、と断念バーグして大通公園に戻り、焼きとうきびを食べたりテレビ塔に登ったりして、昼食の「これぞ札幌ラーメン」というやつを堪能して、札幌駅前(1-2階が紀伊国屋書店、2階にはスタバもある)の北海道教育大学サテライトキャンパスの会場に着いたところである。

事前に学会から届いていた プログラム とともに、以下、ちょっとだけメモしつつ参加した。 内職でopenFrameworksやXcodeをするのは無理だが、まだプレゼンをまったく作っていないので、若干のプレッシャーがある(^_^;)。

音程と音量の変化に伴うフレンチホルン奏者のマウスピース力制御

本研究では開発したセンサーを用いて,ホルン演奏時の唇とマウスピースの間に発生する力(マウスピース力)を計測した。音程・音量によるマウスピース力をそれぞれ検討するため,12名のホルン奏者に対してさまざまな音を演奏させた。その結果,演奏する音程が高いほど,また音量が大きいほど発揮するマウスピース力は強くなった。このことからホルン奏者はマウスピース力を調整することで,演奏する音に適するように唇の力学的特性を変化させていると考えられる。

この発表については、予稿でも講演でも、おそらく100回以上の「音程」という単語がどうしても気になって堪らなかった。 音程というのはintervalであって、noteのpitchは音高と言うべし、素人は音程とゴッチャにするがつられないように、と何度となく言われ続けてきたのだが、天下の音知学会の場でこう続くと参ってしまう。 ・・・と思ってツッコミ質問の手を挙げたが、ちゃんと大串先生が指摘してくれたので安心した。

チェロ基礎練習の音響信号を対象とした熟達度の自動推定

楽器演奏における熟達度の自動推定において,従来推定が難しいとされてきた弦楽器のチェロの音響波形を対象としている。演奏の特徴を表す音響パラメータを専門家の意見に基づいて定義し,得られた音響パラメータを主成分分析により圧縮後,線形回帰を用いて10-foldCV(CrossValidation)により推定値を求めている。単純な練習曲では精度良く推定できるものの(r=0.79,n=100),演奏楽曲(J.S.BachのPrelude)では推定精度が低い傾向が確認されている(r=0.69,n=100)。よって,提案する音響パラメータでは,表現力がより必要な演奏に対しては熟達度推定の精度が徐々に下がる様子が確認されている。

先行研究のピアノとかドラムに対して、チェロのもっとも本質的な音響情報はピッチである筈なのに、それを除いたパラメータで評価するのでは本末転倒では、と質問したところ、確かにピッチが重要なので、いまそれを加味した実験をしている、とのことだった。たぶん実験デザインとして、この逆順は致命的な失敗だと思う。

アンサンブルは「走る」? : 2人組テンポ維持課題におけるテンポドリフトの高速化バイアス

音楽演奏のテンポはしばしば速くなる(「走る」と呼ばれる)。著者らは1人および2人組でのテンポ維持課題を3種類のテンポ(75bpm,120bpm,200bpm)で実施し,テンポおよび人数の違いによるパフォーマンスの変化について検討した。参加者には1人および2人組で,メトロノームと同期してタップを始め,メトロノーム停止後も元のテンポを維持してタップを続けることを求めた。2人組の条件ではテンポ維持に加え,パートナーとの同期も求めた。その結果,いずれのテンポでも1人の時より2人の時において,目標より速いテンポでタップする傾向が観察された。

このあたりで寝不足の後遺症が出てきたが(^_^;)、あまりソソラレない展開だったのも理由の一つである。 音楽的アンサンブルでテンポが引っ張り合うというのは、1990年代に千葉大の堀内さんとか早稲田の大照研とかの研究があったのに対して、これはどうも人間行動学的な視点からやっていて、だいぶ研究の深度として後退しているような印象である。

等間隔で演奏された打楽器音におけるグルーヴ感の評価(第二報)

本研究では,等間隔で演奏された打楽器音を刺激とし,グルーヴ感と関連する言葉,及びグルーヴ感と関連する音響特性を調査した。音楽訓練経験者15名が実験に参加し,8種類の評価語対を用いた主観評価実験を行った。結果,“グルーヴ感がある−グルーヴ感がない”と5%水準で有意な相関が示された評価語対は,“好き−嫌い”,“揺れがある−揺れがない”,“人間的な−機械的な”であった。また,グルーヴ感の評価を従属変数,7種類の音響特性を独立変数とした,ステップワイズ法を用いた重回帰分析を行った結果,IOI(隣接する打点の時間間隔)の標準偏差,IOIの変化率の平均値,音圧の変化率の平均値が有意にグルーヴ感の評価に寄与していることが示された。

冒頭にマイケルジャクションのビリージーンを鳴らす、というのはなかなか音知学会には無かったので良かった。 ただし、実際の研究の内容となると、天下の東京芸大だというのにシンバルを単調に叩くだけの実験素材では、とうていグルーヴなんて無いわけで、だいぶ激しく「外している」気がした。 片寄さんたちの先行研究をちゃんとサーベイして欲しかった。

チュートリアル

桑野園子先生(大阪大学)の「音の流れと連続判断について」ということで、難波先生とともに進めてきた研究の紹介である。 心理学実験において、連続量を対象とした手法のサーベイのようで、これは僕の今後の被験者実験についても参考になるかもしれない。 ・・・というところで、どうも桑野先生のパソコンの色がちゃんとプロジェクタに出ない、という愚痴に、津崎先生の「VGAケーブルを抜いて挿してみたら」という声でやってみると何も出なくなって(^_^;)、そこに救援の学生が駆けつけたらPCの横のお茶のペットボトルを倒して・・・(^_^;)という、ドリフターズのギャグのような一幕もあった。 しかし考えてみれば、僕がこれまでやってきた被験者実験は、だいたいにおいてここで紹介されている「カテゴリー連続判断法」である、と確認できた。 長時間の被験者の反応(評価判定)をMaxで連続的に記録して、後で色々な視点から分析できる、というのは重要なことだ。
また、「時間の流れの中の印象に関する特定箇所の分析」という話はなかなか面白かった。 放送音の音質評価の実験で、素材の音響のあちこちに意図的に色々なファクターの音質劣化条件を加えて、最後には放送の内容というアンケートで被験者の注意を逸らしているもので、注目したい条件だけを加えるのでなく、あれこれ視点を敢えて逸らす、というのはうまい手である。 これを僕の研究にどう応用するかはちょっとピンと来ないが、何かありそうな気がする。 配布された最後のシートの「まとめ」は、ここで手打ちメモしておく価値があるだろう。 以下である。

• 時間の流れに沿って連続的に変化する聴覚的印象を極めてreliableに測定できる
• 日常生活に近い聴取態度で判断できる
• 長時間の実験も可能である
• 特定の刺激に注目させないで実験ができる
• 種々の条件間のトレードオフ効果の検討が可能である
• 時々刻々の印象と全体判断を比較することにより、全体の印象を規定する要因を検討することができる

これはさっそく、いまやっている研究の発展系に使える(^_^)。 こうなると、早々に宿題のMaxプログラミングをしないといけない。 ということは、早々にopenFrameworksを片付ける必要があるぞ。 来年7月末の心理学の国際会議、6月17日にコロナ社から出版される、難波先生が監修した「音と時間」という本の情報もあった。 これも要チェックである。

特別講演

阿部純一先生(北海道大学)の「音楽の心内(脳内)過程解明への一つの視座」という話は、失敗の経験から学ぶ、という材料を提供する、ということだった。 僕が監修者4人に加わったbit別冊「コンビュータと音楽の世界」でも阿部先生に執筆していただいたが、実は個人的にはちょっとずっと引っかかっている部分があるのだが、それを今回、密かに確認できた。 配布資料が無いので、以下、一部の速攻手打ちメモである。

研究が失敗する(成功に至らない)原因を4つ紹介する
	・問題の未分化
		疑問が事前に整理されていないまま実験を行ってしまう
		「神話」が数多くある現象に多い
		「絶対音感」ネタに多かった
		事前に何らかの予見を持っている
	・実力不足
		広く深い専門知識がない
		心理的オクターブと物理的オクターブの違い
		現象の確認・特徴の発見は出来ても現象の説明(考察)が出来ない
	・パワー不足
		単なる研究遂行パワー不足
		言い訳しないで論文まで書くべし !!
	・継続パワー不足
		他人オリジンの研究から発した場合
問題の設定が素晴らしい、知的好奇心を刺激する、というのが良い
研究においては、対象となる問題の設定が重要
	大きくて基本的な疑問がある
研究の成功・失敗に拘らず、あきらめず、頑張ること !

なんと最後には、bit別冊「コンビュータと音楽の世界」に書いてくれた記事まで話に出てきたのは驚いたが、色々と「なるほど」という講演で、収穫となった。 その後、日本音楽知覚認知学会総会、隣のビルの「サントリーガーデン昊」に移動しての懇親会、と粛々と進んだ。 さらに「すすきの2泊目」として、素敵な某スナックと遭遇したことは秘密である。(^_^;)

2015年6月7日(日)

札幌3日目、音知学会の2日目は、朝09:15からスタートした。 遠方の先生は1日だけとか、途中で帰る人もいるらしく、午前のセッションの最後である僕の発表が聞けなくてごめんなさい、という声を何人かから受けたが仕方ない。 たぶん面白いのに。(^_^;)

大学生を対象とした演奏者の“あがり”経験の特徴

本研究では音楽演奏者の経験する“あがり”という現象に関して,“あがり”経験のある演奏者が,実際の演奏場面を前にして何をプレッシャーに感じ,どのような要素が演奏者にとって問題となっているのか,その実態を把握するために,国立大学の音楽科教育を専攻する大学生,大学院生102名(男33名,女69名)を対象として質問紙調査を実施した。普段の演奏の本番での“あがりやすさ”の度数分布については,順に“全くあがらない”(3.9%),“あまりあがらない”(19.6%),“よくあがる”(34.3%),“非常によくあがる”(42.2%)という結果であった。因子分析の結果4つの因子(「自己のおかれている状況の認知」,「認知的変化の経験」,「身体的不全感の経験」,「注意の変化と悪循環」)を抽出した。

「あがり」には英語の定訳は無いらしいが、ここでは「stage flight」としている。 質問紙によるアンケート回答を統計的に分析している研究だが、僕はこういうアプローチは好きではないので、あまり入り込めなかった。 せっかくなら、生体センサを被験者に取り付けて演奏してもらって、その生体情報と本人の事後の「あがった」という感想とを照合する・・・という方向でやってみたい。 また、誰でもあがる事はある、という前提から「あがらない/あがりを克服する」という方向に行くだけでなく、逆に「うまくあがる」(ドーパミンが出て普段よりも良くなる)、という音楽即興学会的な方向もいいと思う。

聴取文脈が音楽演奏の評価に及ぼす影響:生演奏場面と音のみ聴取場面の比較

本研究では音楽演奏者の経験する“あがり”という現象に関して,“あがり”経験のある演奏者が,実際の演奏場面を前にして何をプレッシャーに感じ,どのような要素が演奏者にとって問題となっているのか,その実態を把握するために,国立大学の音楽科教育を専攻する大学生,大学院生102名(男33名,女69名)を対象として質問紙調査を実施した。普段の演奏の本番での“あがりやすさ”の度数分布については,順に“全くあがらない”(3.9%),“あまりあがらない”(19.6%),“よくあがる”(34.3%),“非常によくあがる”(42.2%)という結果であった。因子分析の結果4つの因子(「自己のおかれている状況の認知」,「認知的変化の経験」,「身体的不全感の経験」,「注意の変化と悪循環」)を抽出した。

サイレントバイオリンを生演奏(スピーカ再生)してその前にいる条件と、録音したその音をスピーカから聞いた条件とで、聴取者の印象評価を比較した。 売りとしては、タブレットPCのプログラムを作って、被験者はその2次元印象空間上にタッブしたデータを刻々と記録して、後でビデオ記録と比較して時刻を同定した。 ちょっと残念なのは、せっかくライブ演奏を見ているのに、手元のタブレットPCの画面に視線を落としてタッブする、という動作を強いるのがもったいない・・・と思ったら、タブレット画面を見ないで出来るまで練習するのだった。 また、せっかくなら「生演奏」「演奏の様子の動画」「録音のみ」の3種類で比較する、あるいは「演奏者の記録(身振り)をシルエットに2値化した画像」も比較すると面白いのでは、と思った。

音楽聴取中のリズム変化に対する脳磁界応答-SPMによる検討-

リズムは音楽の要素の一つであり,音楽聴取時には楽曲の印象を決める重要な要素である。本研究では,高い時間分解能を有するとともに活動源推定が可能な脳磁計(Magnetoencephalography,MEG)を用い,旋律のリズムパターン変化に対する脳応答を記録した。同じ長さの2音で構成される標準刺激に対し,1音目が短くなるリズム提示時に強い脳応答が認められた。この脳応答は,標準刺激で音が持続している時間に音圧の減衰が始まることによっておこると考えられ,トップダウン処理によるリズム逸脱に対する応答であると考えられた。

脳波は時間的な分解能が悪いのに対して、このMEG(脳磁計)は相当に時間分解能が良い(音楽情報レベルで音符ごとの反応が取れる)というのは素晴らしい。 MRIでの先行研究と整合している。 等間隔のリズムの前音が短くなった方に反応する、というのは理解できる。 音楽経験がある被験者の方が左半球に強い反応が出た。 津崎先生のコメント「我々はよく純音(サイン波)を使うが、純音というのは滅多にない特殊なサウンドなので注意が必要」は貴重な視点であった。

統合失調症患者における音楽療法:健常者に対して音楽が及ぼす影響との比較

統合失調症患者に対する音楽療法は,陰性症状を改善し,対人交流を賦活させるといわれている。この音楽療法は,近年,認知機能に関しても肯定的に作用する可能性が報告されている。前半部は,音楽が統合失調症患者の認知機能へどのような影響を及ぼすのか,これまでの研究報告をレビューする。これらを踏まえ,後半部は健常者を対象とした音楽条件の違いによる認知課題遂行実験の結果を報告する。この実験では,音楽条件の有無による認知機能検査の課題遂行は,個々人の音楽的背景の影響を受けていた。個人の音楽に対する好みの程度は,認知機能へ影響を及ぼす可能性がある。

音楽療法に関する研究発表をキチンと聞いたのは初めてだったので、いろいろ興味深かった。 ストループテストは面白い。

私たちの脳は調性スキーマをどのように学習するか:コネクショニストモデル研究からの示唆

聞き手の脳は,どのような学習メカニズムに支えられて調性スキーマを習得するのだろうか。本研究では,学習機能を備え,かつ,学習前には(特定の文化を前提としない)普遍的な特徴のみしか備えていないコネクショニストモデル“LeNTS”を作成した。そして,そのLeNTSに,西洋音楽文化圏の典型的なメロディを356曲入力した。すなわち,各メロディとそれに対する(人間の)一般的な調性知覚反応結果とを対にして入力していった。この調性知覚学習によって,LeNTSの調性知覚反応がどのように変化していくのかを観察した。学習の結果,LeNTSは先に西洋全音階に従うメロディとそうでないメロディとの識別を,次いで標準的な和声進行に従うメロディと従わないメロディの識別を行うようになることが示された。LeNTSが示した識別能力の獲得順序は,西洋音楽文化圏の子どもが示すそれと一致していた。本稿では,シミュレーション結果を基に,調性スキーマが学習される脳内メカニズムの特徴について論じる。

計算論的モデルで調性スキーマを獲得する様子を分析して脳内機能を予測する、というのは面白い。

内受容感覚コントローラとしての筋電楽器〜癒し系エンタテインメントのために〜

外受容感覚(五感)に加えて最近注目されている内受容感覚と情動/感情と脳内プロセスモデルの関係について,筋電楽器のジェスチャ認識研究で発見した無意識下のリラックス効果の適用を検討し,癒し系エンタテインメントの可能性について考察した。本稿ではまず,過去に開発した筋電楽器と新世代の筋電楽器を紹介し,筋電センサによるジェスチャ認識の新手法を提案する。次に内受容感覚とソマティック・マーカー仮説と脳機能を予測マシンとしてモデル化した研究を紹介し,内受容感覚から情動/感情が生まれる仮説の検証について検討する。さらに随意筋の制御である筋電ジェスチャ認識の実験から得られた無意識下コントロールの持つ可能性を,心を豊かにする広義のエンタテインメントとして検討した。

結局、プレゼンシート無しでデモ中心に無事に完了(^_^)。 Myoは大人気。 ここで昼食、スープカレー屋で初めての体験。 やはりカレーは普通のカレーが一番だ。

聴覚的臨場感に関する基本印象語・複合印象語リストの検討(4)−4種の再生フォーマットによる12種の音源に対する印象の階層関係−

12種類のさまざまな場面の音響コンテンツを,22.2ch,5.1ch,2ch,1chの4種類の再生フォーマットで再生したものを対象に,空間的な印象や音響的な印象など聴覚的臨場感に関する基本印象と複合印象についての主観評価実験をおこなった。この結果から,基本印象と複合印象が再生フォーマットの違いによってどのように変化するか,また,それらの音響的,空間的な特徴に関わる印象が,コンテンツに対する好ましさや分かりやすさなどの総合的な評価とどのように関係するかについて検討した。さらに,臨場感が複合印象や基本印象とどのような階層関係にあるかについて検討した。

NICTからの委託研究の最終報告。 NHKも必死か。

背景音楽のテンポが映像作品の主観的時間長に及ぼす影響

映像作品の制作における,音楽の効果についての知見を広げるため,10秒前後のニュース映像の音声トラックへ混合する音楽のテンポが,映像音響刺激の主観的時間長に及ぼす影響を調べた。90bpmの音楽を混合した70秒の音声つきニュース映像から,ランダムに10秒の区間を抜き取りこれを基準刺激とし,これと,同様に50,90,140bpmの音楽を混合した同じ映像から8.5~11.5秒の部分を抜き取った刺激との主観的長さを対比較した。その結果,速いテンポの音楽が混合された刺激は基準刺激より短く,遅いテンポの場合は長く感じることが分かった。これは,音楽を聴きながら主観時間を産出した既存の研究結果とは反対の結果であった。

ここに来てスープカレーが睡魔を持ってきたが、なかなか興味深い研究だった。 僕が昔にやった「映像的ビートと音楽的ビート」の研究とも通じるところがありそうで、時間学的にちょっと調べてみたい気になった。 学生の興味からスタートしたのであれこれ条件がイマイチだったという事だが、ここは要チェックである。

平行5度歌唱による主旋律歌唱の干渉について

対位法における平行5度の副旋律の「禁則」の背景に存在する歌唱制御の側面に光を当てるべく,平行5度の関係で副旋律が存在する情況での歌唱音声の基本周波数の分布について検討した。大学もしくは大学院で声楽を学ぶ歌唱者を用いて平行5度下で歌唱する副旋律がある条件での唱歌を歌唱させ,その歌声の分析を行った。対照条件として3度下の副旋律が存在する条件を設け,両条件間の差を検討した結果,5度条件での歌唱は基本周波数の逸脱の大きさ,ばらつきの大きさ,分布の急峻さのいずれの側面においても歌唱の不安定さを示唆する結果が見出された。

これはちょっと面白いかも。 トニックの調的構造からは、完全5度下よりは完全4度下(or完全5度上)の方がいいのでは、と思った。

ピアニストの視聴覚の優先性と演奏方略の関連

初めて読む楽譜を練習なしに演奏する「初見演奏」と,聞いた音楽を演奏で再現する「耳コピー演奏」の得意・不得意には個人差が存在し,両者ともにピアノ演奏方略に影響する可能性がある。演奏に関連するアンケート調査を実施し,初見演奏と耳コピー演奏に対する自己評価,両者の相互関係,過去に受けた音楽教育との関係,音楽の記憶(暗譜)との関係を明らかにするため分析を行った。両者の間には相関はなく,独立した技術であること,幼少時のソルフェージュ教育が耳コピー演奏の得意・不得意に影響する可能性があること,耳コピー演奏が得意であるほど暗譜が得意であり,暗譜にかかる時間が短縮されることを確認した。

合唱指揮者として経験してきたことがデジャヴのように蘇ってきた。(^_^;)

そして無事に、　15時に研究会が終わった。 今年の音知学会の秋季研究発表会は、12月5日(土)・6日(日)に、目黒のヤマハ音楽振興会本部で開催される、とアナウンスされた。 その前週には大阪で基礎心理学会があるし、11月には音楽即興学会(神戸)とリハ工学カンファレンス(那覇)の予定があり、ちょっと旅費枠的に苦しい気がするが、今回の発表の続報、という意味では考慮しておく必要がある。 その後、ホテルに戻ってちょっと休憩して、18時から「すすきの3泊目」として、本来は休業日なのにママさんが開けてくれた某スナックに行き、キンキの煮付け、生牡蛎、などサプライズを頂きつつ3日連続の飲み歌いとなった事は秘密である。(^_^;)

2015年6月8日(月)

そして今、この部分はセントレアから神宮前に向かう名鉄特急の車内である。 音知学会のプログラムがまったく不明の時点で、超早割のフライトチケットを購入したので、前泊+後泊となった今回の札幌出張だが、月曜日の4限「サウンドデザイン」に確実に間に合うために、帰途のフライトは新千歳空港発08:00という朝イチである。 そのために朝5時起きして、6時にホテルを出て、始発のすすきの06:14発の地下鉄で札幌駅に行き、JR快速エアポートで空港に07:10に着いて、売店ではお約束の「白い恋人」と、ゼミ参加のM2の杉浦さんが熱望した「鮭とば」をゲットした。 セントレア行きの機体には、なんだか詳細不明(ポケモンじゃない)のアニメキャラ的な絵が描かれていた。

朝イチで空いている機内では窓際に座り、滑走路の向きと日差しと影の様子から「もしかしてこれは!」と直感して、デジカメを動画モードにして、離陸から8分間ほど撮影した。 予想通りに、離陸した直後から僕の乗っているANAの機影(もろに地面に飛行機の影がくっきり(^_^))が、ずっと小さくなりながら追いかけてきたのを撮影できた。 このためには、「晴れている」「太陽を背にする」という条件が必要であり、さらになんと今回は、そのまま動画を撮り続けていると、うっすらと眼下に雲がスクリーン状になった瞬間に、再び機影が現れて、さらに一瞬、その全体が丸い虹に囲まれる「ブロッケン現象」という凄いのが動画で撮れてしまった。 研究室に戻ったらYouTubeに上げるが、どこまで「見える」かは不明だが。貴重なお土産となった。 さらに長野上空では遠くに富士山もなんとか撮れたが、セントレアに着いてみると、なんと梅雨入りということで雨だった。 札幌のカラッとした空気が懐かしい。(^_^;)

そして気合いで4限「サウンドデザイン」を終えて研究室に戻り、気合いで 音知学会2015・久しぶりの札幌 というフォトレポートをWebに上げて、さらにYouTube動画として キミには「ブロッケン現象」が見えるか? と そのフルversion を上げてリンクも整えた。 ここまでやったら、なんか疲れがドッと出てきて、ちょっと放課後の沖縄音楽のコンサートに出るのは困難と自己診断して帰宅することにした。 明日は午前に医者のはしご、4-5限の企画立案演習ではクラス内中間プレゼン、水曜日は1限に「音楽情報科学」、2-3限にはメディア造形学科の企画中間報告会議がある中にさらに避難訓練(;_;)があり、ゼミは臨時に5限に移動である。 そして木・金と京都芸大でのワークショップ(特別講義)があって土曜帰り、日曜だけ束の間の休養日だが、なんと翌日の月曜日にはゼミの総決起集会(*^o^*)があり、その週の週末には新潟に学会出張・・・とずんずん続く。 openFrameworks+Xcodeをやるか、Myo絡みでMaxプログラミングを進めるか、なかなか悩ましい多忙月間だ。

2015年6月9日(火)

梅雨入りしていまいち盛り上がらず、札幌遠征の疲労感も漂う火曜日である。 午前には2時間ほど外出したが、その合間と昼休みと3限まで使って、今週後半、木金それぞれ半日の 京都芸大・Arduinoワークショップ のページを一気に作り上げた。 そして4-5限の企画立案演習でクラス内中間プレゼンを終えて研究室に戻ってくると、札幌の音知学会でご一緒した中島先生から、今年の「 錯視コンテスト2015 」の案内が流れてきた。 以下の、過去の錯視コンテスト受賞作品のページはなかなか圧巻だが、見ている時間が無い(^_^;)。

• 錯視コンテスト2009
• 錯視コンテスト2010
• 錯視コンテスト2011
• 錯視コンテスト2012
• 錯視コンテスト2013
• 錯視コンテスト2014

そして放課後はアカペラ(札幌土産付き(^_^))で、あっという間に一日が終った。 明日は京都でのワークショップのために。持参する部品とかの準備が忙しそうである。

2015年6月10日(水)

時の記念日である。 例年であれば、この日の付近の土日に日本時間学会の総会が開催されるのだが、今年は先週末に時間学研究所のある山口大学での開催となって、札幌での日本音楽知覚認知学会とモロかぶりしてしまい、参加できなかった。 来年はなんとか、両者の学会の開催日程が例年のようにズレて欲しい。

朝イチ(06:30)に、まずは1限「音楽情報科学」の今日のページを改訂して、「課題不調の救済措置として今年に限り、『錯視コンテスト2015に応募すればそれを課題提出と見なして成績評価する』こととします(出席点は厳然と存在しますので欠席多数なら無駄)。応募したい学生は事前に長嶋に相談して下さい。基礎心理学的な補足/検討を加えて長嶋が2nd Authorに加わって応募します」とした。 この理由には、マルチメディア室のiMacの「古さ」が露呈してきて、kinectの画像認識Processingライブラリに対応できていないという状況がある(来年度には解決する)ので、仕方ないところなのだ。

そして、我が家の2代目のハムスター ★ ★ ★ ★ が天寿を全うしてから「四十九日」も過ぎて、老夫婦には心の支えの欠如がキツくなってきた、ということで、この週末には、3代目をゲットしに行く、と決めた。 僕は葉から芽くんでだいぶ癒されていたが、奥さんは精神的ダメージ(ペットロス)が苦しくて、夜中にハムスターのケージ(片付けず置いてある)付近で何か物音がする・・・などと言っていた。この夜中の物音は僕も聞いていたので、やはり「四十九日」は我慢していたのだ。 人間より寿命が短いので、どうせまた3代目もいずれ看取るしかないのだが、元気な子を探してみよう。 ジャンガリアン限定だ。

2〜3限のメディア造形総合演習II中間審査会議では、研究棟は対象外ということで無事に暖かく避難訓練をやり過ごして会議を続けた。 4限には、上のように、明日からの京都芸大・Arduinoワークショップに持参する部品などを整理した。 そして5限に、今週のゼミとして全員が集合して、札幌土産を美味しくいただきつつ、以下のようにまたまたUnity勉強会を進めた。

上は1106研究室の風景バージョンであり、以下は僕のMacのスクリーンショットである。 今回もだいぶ進んだが、もう毎回、過去のことを忘れているので、「Unityが使えるか」と言えば、残念ながら「触ったことはあります」の域から進展していない(^_^;)。 来週は、ダウンロードした謎の「Unityちゃん」が登場するらしい。

先週知った「デスクトップをそのまま動画化」機能で撮ってみたのが これ である。 ただし、記録ストップを忘れて延々と撮られたいたようなので(^_^;)、なんと13分50秒にもなった。 その後、筑波でのバイオフィードバック学会の見学会と懇親会について、杉浦さんと藤石さんと相談して事務局に連絡した。 東京での見学会と懇親会には2人だけで行くことになり、僕は夕方に筑波に住む母親の顔を見に行く(ちょっとお茶)、ということにした。 生きてるうちの親孝行、というのも大事なのだ。(^_^)

2015年6月11日(木)

今日は研究室でパッキングをして京都芸大ワークショップに向かう日であるが、朝イチで研究室に出て来ると、8月下旬に東京で開催される可視化の国際会議に応募していた論文の審査結果が届いていた。 「倍率は約3倍であり。残念ながらrejectされました」とのことなので、せっかくだからとReviewersのコメントをGoogle翻訳に突っ込んでみた。 1人目のReviewerは、paperの内容について一言もコメントが無く「まったく英語が駄目で、なってない」という門前払いだった(^_^;)。 2人目のReviewerは、来週にPRMUで発表するので詳細を省略しているリサジュー解析の部分についての不満と、視覚的フィードバックによってコントロールの性能が向上した事についての客観的検証不足を指摘した。 これはいずれも自分としても弱点と認めざるを得ない。 3人目のReviewerは、そこそこ中身を読んでくれた上で、リサジュー解析の省略と、英語の拙さによる読みにくさを指摘していて、穏便ながらも明確に不採択理由を書いてくれていた。 ・・・まぁ、短時間にやっつけた「駄目モト応募」なので想定内と言えばそれまでだが、やはり、英語論文は時間をかけないと駄目である(;_;)。 これで、来週に届く予定のシンガポールの国際会議との「連チャン」だけはまず、無くなった。 シンガポールが採択ならこの会議だけのためにゆっくりと行けるし、不採択なら一気にアルスエレクトロニカ視察に方針変更である。

そして、まだ研究室を出発して浜松駅にバスで向かうまで1時間ほどあったので、久しぶりにMyoを取り出して、懸案の「FFTによるジェスチャ認識」システムをMyo販に移植する、という作業にチャレンジ開始した。 するとまず、上のようにMyo ArmBand Managerのバージョンが上がっているのでupdateしてね・・・と出たので、ダウンロードしてインストールした。 そしてMyoを装着すると、さらに上のように、今度は「MyoのFirmwareのバージョンが上がっているのでupdateしてね」と出て、USBでMyoを繋ぐと自動でアップデートされた。 さすが、まさに世界中のユーザからのバグレポートに対応して、どんどんアップデートして性能を上げているのは素晴らしい。(^_^)

そしていよいよ、上のように、「Myo+リサジュー解析」の最新版と、過去の「筋電直接オーディオ入力・FFT販」の両方のMaxパッチを開いて、できればコピペで合体販に移行したい・・・という努力をスタートした。 幸いに、MyoからBluetooth経由で届いた生の筋電情報を、Maxの「sig~」オブジェクトに入れれば、その出力は過去に作った第4世代の筋電センサのフロントエンド筋電信号とほぼ等価なオーディオ信号となり、FFTモジュールのグラフは似たように振舞ってくれた。

そして、ここは今、浜松から京都に向かう新幹線「ひかり」の車内(琵琶湖を過ぎたあたり)であるが、約1時間の苦闘の末に、上のように、なんとかMyoの筋電情報をMaxのFFTで認識・比較する、という動作まで漕ぎ着けた。 ただし、体感としては4チャンネルとしてもちょっと性能が悪すぎるので、パターン比較の部分に、FFTの200バンドの比較の筈が、コピペしたリサジュー認識の28チャンネル分しかループを回していない・・・という感じのバグがある気がする。 ここはもちろんチェックなのだが、少なくとも筋電情報オーディオFFT入力をMyoに置換する、という部分は出来たようなので、来週の電子情報通信学会パターン認識研究会での発表までには、この部分を解決できる可能性が出てきた。 これは大いなる進展(懸案の打破の第一歩)で、幸先良い感じである。(^_^)

そして午後には4時間、上のように京都芸大・構想設計コースの3/4回生5人を相手に、ワークショップの前半を無事に終えた。 とりあえず電源とLEDのお話、Arduinoで初めてのプログラミングまで完了である。

2015年6月12日(金)

この日のワークショップも午後ということで、朝からホテルの部屋で懸案の改訂を進めた。 Xcodeでオリジナル開発した「ダブルMyo」の方の「Myo-OSC」ツールは、静かにしていてもMyo　ArmBand Managerがdisconnectしないように「lock」(Myoが気をきかせて省エネのために勝手にsleepしない)コマンドを入れていたが、肝心のMyo1個のジェスチャ認識システム用のツールにはこれを入れていなかったので、どこかで入れたかったのである。そして以下のように無事に完成して、リサジュー解析販の方のツールはこれでほぼ完了、となった。

しかし、京都に向かう新幹線の中でとりあえずやっつけた「4筋電チャンネル・200バンドFFT」販の方は、どこかにコピペ元のリサジュー販のサブパッチからの移植あたりにバグがあり、なかなか想定する成績が出なくて、この試行錯誤に苦労しているうちに芸大に向かう時間となった。

そして京都芸大に着いてから1時間ほどかけて、過去の第4世代の時のFFT販Maxパッチを発掘して上のように比較して、リサジュー販のMaxパッチを単純に200チャンネルには出来ない(昨日の新幹線の中で成績が悪かったのは予想通りで、かなり少ないデータしか比較していない)、という事が判明してきた。 FFT販では29種類のポーズに対応した200バンドデータを個別にtxtファイルにいったん書き出して、後でそれらを刻々と読み込んでは比較していたのを、チャンネル数が少なくなったリサジュー版ではこのメカニズムを省略していたのである。 こうなると、せっかくMyo→OSC→FFTまで繋がったので、新しいジェスチャ認識パッチを新たに作るぐらいの取り組みが必要だ。

そして午後には4時間、上のように京都芸大・構想設計コースの3/4回生5人を相手に、 ワークショップ の後半を無事に終えた。 皆んなに配布したArduinoソースのサンプルは これ であるが、一部にバグがある(^_^;)。 これで、皆んな、スタンドアロンのArduino応用システムをがんがん、制作していって欲しい。

2015年6月13日(土)

梅雨の晴れ間で蒸し暑い土曜日、京都から浜松に朝帰りする新幹線「ひかり」の車中である。 先週の札幌行きの前に、openFrameworksのサウンドの章までチェックしたところで止まっていたので、ちょっとした思い出しをしておくことにした。 Denisのあの分厚い本は持ってきていないが、なんと個人的に彼からこの本の全部マルマルPDF(364ページ、6.1MB)をもらっていて、MacBookAirに入れていたのに気づいたので、以下のように第7章から本文を読みつつ、続きが可能なのだ。 このPDFはさすがに公開できない(^_^;)。

第7章「3D」は、基本的にOpen-GLのようである。 最初のサンプル「01-TrianglesCloud」は、以下のように3次元空間に球状の配置形状を定義して、そこに多数のシンプルな三角形(プレート)を描画しているが、スクリーンショットだと普通のFlashのアフィン変換でも出来そうだ、と誤解されてしまうので、ごく短時間のデスクトップ動画(7秒、4.4MB)も撮った。 これ である。 この動画により、openFrameworksの凄さが伝わるだろう。(^_^)

次のサンプルは「02-PyramidMesh」であり、以下の画面だけだと地味なようだが、いろいろなオブジェクトを3次元空間に配置するためのメッシュを提供しているようである。 こちらもスクリーンショットだとあまりに地味なので、デスクトップ動画(27秒、7.3MB)も撮った。 これ である。

次のサンプルは「03-PyramidLighting」である。 3Dオブジェクトに対してライティングをするもののようで、あまり僕はこのあたりは深入りしたことがないが、学生は3D StudioMaxで日々、やっているやつだろう。 こちらもスクリーンショットだけでは伝わらないので、デスクトップ動画(39秒、10.9MB)も撮った。 これ である。

・・・ここまでやったところで新幹線は浜名湖を通過して、あと数分でぼちぼち浜松である。 たった3つしかサンプルが消化できなかったが、一連のやり方を思い出した、という意義はある。 新幹線の座席という悪条件、スクリーンショットの編集やこのHTMLまで1画面のMacBookAirでやっている(普段はお仕事Mac miniの2画面にファイル共有でスクショを転送して編集している)ので、まずまずというところだ。 これで大学に戻ってここまでをWebに上げて、さらにお仕事である。

Several folks have asked me about the theme this year. As always, you're free to talk about whatever you want, but the theme this year is "utopias". Here are my thoughts on why I chose it, inspired by Jason Kelly Johnson's response when I wanted to hold Sketching at Arcosanti, an earlier and equally as visionary project as Biosphere 2:
Implicit in every tool is a vision of the world, a utopia. In the enthusiasm of invention it’s easy to imagine how our new tools will make the world better, maybe even perfect in some way. Such visions inspire us late into the night, whether to solder or to paint placards for a demonstration, and they keep projects going when challenges move the goal much further than was originally estimated. Yet when projects really don’t work out, when difficulties grow unsurmountable (as they often do), utopian visions can be dashed, abandoned for sad bitterness. The final crowdfunding update is never sent, the protest placards are packed away. During this Sketching in Hardware I’d like to examine our fondest hopes, our biggest plans, and our bitterest disappointments.

11時前に研究室に戻ると、上のようにSketching2015の主催者Mike Kuniavskyからのメイルが届いていた。 今年のテーマ「ユートピア」に関する説明のようである。 科学技術論文などと違ってこの手の英語が苦手なので、プリントしてじっくり読むことにした。 ここから京都に持参した部品類を部品棚に戻して、持参した機材を元の場所に戻して、溜まったメイルを処理して、このページをWebに上げつつネットニュースを見ていると、なんとカナダのワールドカップの前半、なでしこJAPANが2-0で勝っているという情報に遭遇した。 午後は、ちょうど正午から始まったカメルーン戦の後半を見ながらのお仕事である。

・・・と書いたが、ワールドカップの試合をライヴ(ネット中継)で見ていてお仕事が出来るわけなく、後半45分に1点を返されて、Additional Timeの4分間をはらはらして見守るまで、50分間はまったく何も出来なかった。 なんとか2-1で勝って良かった。 そして、明日の日曜でなく、今日の3時過ぎに3代目ハムスターを探しに行くことにしたので、今日はここまでである。 最後にopenFrameworks+Xcode、ということで「Xcode日記」らしくなり、ここまででHTMLが186kBとpart1をちょっと越えたので、「Xcode日記(2)」はここらを区切りとして、次は Xcode日記(3) としていこう。

→ Xcode日記(3)

「日記」シリーズ の記録