Sketching日記(10)
(実際のところは「Max8日記」かも)長嶋 洋一
2021年6月28日(月)
新しい週が始まり、いよいよ今週後半には7月に、つまりこの前期のラストに向けたスパートが始まるという「実りの季節」を迎える。 前の日記の最後あたりで苦闘していた問題点もスッキリと解決して、某X社とのプロジェクトの隔週ZOOMミーティングが予定されているこの日は、朝7時前には研究室に出てきて、以下のようにMax8のパッチの改良と新しい実験にもトライして、色々とクリアになって、ミーティングでの報告が楽しみになってきた。 忘れかけていた「Max8からGarageBandの音源を鳴らす」という方法は、YAHOOで検索してみたら、僕が音楽知覚認知学会での発表で報告していたPDFが出てきて無事に解決して、やはり情報はWebに公開しておくのがいいのだ、と再確認した。 今日の予定は2限に「基礎演習E」の学生のアポがあるぐらいであり、午後イチのZOOMミーティング以外には余裕があるので、どんどん舞い込んできている「基礎演習E」の学生アポに対応するために、あれこれハンダ付けも進めることになる。
そして午後には、ZOOMミーティングからは こんなページ の情報が届き、あとは このように あれこれを進めて、充実した1日が終わった。 明日からもばりばり進めていこう。
2021年6月29日(火)
今日は1限に「基礎演習E」の東本クン、4限にゼミ清水さんのアポが入っているだけ、という余裕のある日なので、朝からあれこれ実験などを進めてみた。 東本クンのArduinoにはSHARPの距離センサと2個の3色LEDが このように 付いていて、mp3シールドのプログラムも去年の「基礎演習E」で実例があったのでそのまま鳴ってくれて、これでArduino回りのハードは完成となった。 あとは東本クンのMacでArduinoのライブラリが完備されれば自力でプログラミング出来るので、勝負は「造形」に大きく進展した。
その後の2限には、某X社プロジェクトの実験でフト思いついたアイデアについて このページ などを調べたり実験を上のように進めたが、どうも期待したような動作には程遠く、とりあえず経過をメイル報告してみることにした。 そして4限にはゼミの清水さんがやってきて、あれこれ同時進行している複数のプロジェクトに色々と支援をした。 「基礎演習E」の吉田さん作品(あれこれ欲張った力作の模様)の支援については、隙間の3限と5限にチラッと このように 少しずつ進めたが、初めてのArduino Megaで3個の3色LED、つまりPWMの9ポートの点灯実験(Firmata+maxuiono)は明日になりそうである。
2021年6月30日(水)
「SUAC爆破予告メイル」が届いたために全学入構禁止となった日である。 2限のゼミはZOOMで開催予定と告知していたが、体調不良でゼミの永井さんからは進捗報告画像と欠席連絡と発注依頼が届いた。 リモートのご時勢に「乾杯」をテーマとした作品のために、既に3種類のジョッキ(強化プラスチック製)を入手して実験した結果、角形の以下のものを採用するということで追加発注なのだが、Amazonに出店しているのは全て「中国・深セン」の販売元だった。 実は最初の購入で、2個のうちの1個に、以下のような見事な「穴」が開いていたので、業社には「このどこからでも結構ですが、値段は問わないので、1個単位であれば5個、2個セットなら3セット欲しいのですが、なるべく確かなところからお願いします。1個ぐらい穴が開いていても諦めますが、5個のうち3個が駄目、というのは避けたいのです」と希望したが、まぁ似たり寄ったりだろう。
そして、2限では久しぶりの「ゼミZOOM」が以下のように進んで、さらに全体ゼミ終了後には杉山さんとの作戦会議を進めた。 ちなみに(リンク切れするが)全38分の記録動画は これ である。
そして午後には、明日にアポが入っている「基礎演習E」の吉田さん作品のためのLEDテープ3系統・ArduinoMegaのシステムを このように 作った。 バルサ材に貼り付けたLEDテープには「+12V」・「R」・「G」・「B」と書かれているのに、作ってみたらこれは「白色専用」だった・・・と気付いたが、いつそのこと5cmブロックを3つのテープのままにすれば良さそうだ、ということで以下のようになんとか完成した。 これで明日のアポには何とか間に合ったのだ。(^_^)
2021年7月1日(木)
いよいよ今年も後半戦、7月に入って前期の学期末に向かっていく。 午前にはマツダに定期点検に行ったりしたが、今日の3限のアポでは「基礎演習E」の吉田さんが1106に来て、 このように あれこれと進めた。 3色LEDテープの基板部分の不良で折りまげると電源ラインが断続的に繋がったり切れたりするので、新しいテープに付け替えたりしたが、まずまず準備としては着実に進めることが出来た。 これで勝負はまさに「造形」(→そしてプログラミング)という感じになってきた。
その後は某X社ブロジェクトの実験として、いよいよ全身スーツを着用して、学部事務室の事務員さんに隣に座ってもらって(緊急時にモジュールを引き剥がすため)実験をしていたが、以下のようなパッチでX社システムのバグ??のような現象に遭遇して、今日はここまでとなった。 なかなか面白いところに入っていけないが、新しい試みというのはそういうものなのかもしれない。
2021年7月3日(土)
ようやく週末となった。 昨日の金曜日は、某X社に報告したバグに的外れの回答が返ってきて、朝イチでの以下のようにトラブルレポートを送ったりして1限「サウンドデザイン」に向かったが、2限「音楽情報科学」までの休み時間にマルチメディア室でWiFiを繋いでメイルをチェックするとまたまた的外れの回答が返ってきて返信したり、マルチメディア室のMacが一種の初期故障で駄目になって情報室に電話したり・・・とどたばたした。 昼休みから3限には4-5限「基礎演習E」の中間発表の学生データ20件ほどをあたふたとダウンロードして準備し、「基礎演習E」の合間の休み時間にもWiFiを繋いでメイルをチェックする、という高密度な1日となった。 そして夕方に届いたX社からの「対応改訂版」に対して、やっぱりバグ有りで駄目ですよ(;_;)・・・とメイルしたところで1日が終わった。
X社システムのバグが解決しないと僕のMax8パッチでの実験や検討に入れないので、原因不明のトラブルで悶々としていた先々週とは様変わりして、この週末は某X社プロジェクトに関しては何も出来ないので、ぽっかりと時間が空いた。 ここは2件、今月末の締切りに向けた学会発表論文の執筆のチャンスかもしれないが、まずはとりあえず朝イチでいつものJoyJoyの予約を電話した。 そして「基礎演習E」に関しては、僕が支援することになった4人の学生のアポが今月下旬までびっしりと入ってきて、さらにここにゼミ3人の4作品、仮ゼミ清水さんのプロジェクト3作品、さらに「音楽情報科学」で学生5人の「インタラクティブ錯覚体験Max8パッチ」の制作支援・・・と目標がだいぶ明確になってきた。 なんという幸せな日々か、今月は「Max8プログラミング三昧」がずっと続くことは確実なのだ。(^_^)
昨夜に自宅にFedex(→ゆうパック)で届いた「EmotiBit」を、休日出勤していた事務局の宮野さんに検収してもらえたので、 このように 記録しつつ、さっそく開梱してみた。 これは来年2月に一般に提供されるKickStarterのオプションとして、「7月に先行して受け取る」という出資で獲得したadvantageなので、ほぼベータテスタなのだが、遊ぶには最高のおもちゃ(しかし実戦的な優れもの)なのだ。 まずは EmotiBitのサイト に行き、GitHubに置かれている 最新のツール をダウンロードして、こちらもGitHubに置かれている EmotiBit Documentation のページから、お約束の Getting Started with EmotiBit に進んだ。
リチウムイオン電池を繋いでみると一瞬LEDが点灯したが、USB電源に繋ぐと「Charging LED」(橙色)が点灯しっ放しになったので、これが消えるかどうか充電してみることにしよう。 そしてマイクロSDカードに「SSID」と「暗号化キー」を書き込め・・・というので、これは研究室に飛んでいるDHCPでは無理(情報室に書類を出してSUACネットのシステムにMACアドレスの登録が必要)だと判断して、ちょうどMUSE2の実験のために購入していたBuffaloのWiFiルータ(スタンドアロン・ルータの設定)を持ち出してきて立ち上げてみると、基板上の「WiFi Connected」というLEDが点灯した。 そこで、LANにも繋がっているお仕事Mac miniで同時にこのWiFiルータとも接続してみると、起動した「EmotiBitOscilloscope」というアプリがあっさりとEmotiBitと接続できて、上のようなたくさんのセンサデータが簡単に表示されてしまった。 YouTube動画は これ である。 このアプリには「OSC」というチェックボックスもあるので、EmotiBitOscilloscopeを経由してMax8と繋ぐのもかなり簡単そうだが、それは明日以降の楽しみとすることにして、今日は充実の成果とともに午後〜晩のJoyJoyヒトカラに向かうことになった。
2021年7月4日(日)
昨日のJoyJoyヒトカラ(飲み続け)6時間では妥協(曲数稼ぎの甘い曲)無しの「攻めた」65曲 ★ を完走したが、1年4ヶ月毎週ヒトカラを続けてきてようやく、長時間ヒトカラの攻略法(途中でへばったり翌日に声枯れしたりしないテクニック)が身についてきたようである。
昨日のEmotiBitがベータモデルであるにもかかわらず予想以上に順調に動いたのを受けたハイテンションで、さてOSCのポートはどうなっているのかな(メイルで質問しないといけないかな?)・・・と研究室に出てきたが、 Getting Started with EmotiBit のページに「Streaming Data in Real-Time and Recording」という項目があり、そのリンクで Working with EmotiBit Data というページに行ってみると、さすがオープンソース、欲しい情報がちゃんと公開されていた。
OSCの設定(IPアドレスとポート番号)は、上のような「oscOutputSettings.xml」というファイルに記述すればいいのだが、とりあえずdefaultでのIPはlocalhost、ポート番号は12345だというのが分かった。 そこでスタンドアロンWiFiルータを立ち上げ、EmotiBitを立ち上げてWiFi接続し、お仕事Mac miniのWiFiをONにしてスタンドアロンWiFiルータを指定し、EmotiBitOscilloscopeを立ち上げ、駄目モトでMax8を立ち上げて「udpreceive 12345」の出力を見ると、ワラワラと何かが出ていることが分かった。 つまり、「EmotiBitとMax8とが繋がった」のである(^_^)。 そしてこのOSCメッセージを「route」で先頭文字列の指定によって取り出し、「route」の右端出力からは「それ以外のメッセージ」が出てくるので、さらに「route」を芋づる式に繋ぐことで、以下のように簡単に全てのOSCメッセージを取得して表示できてしまった。
要するにdefaultではEmotiBitOscilloscopeで表示している全てのセンサデータがOSCで送られてきていたのだった。 そこで「芋づる」をやめて、今後は必要なセンサデータだけを取り出せるように、以下のようにMaxパッチを改訂した。 これで今後、EmotiBitはMaxでなんとでも遊べる「便利な生体センサ」となったのだ。 Muse2の時には、ほぼ同じところに到達するまでにかなりの時間がかかったのだが、なんとこの作業はものの30分ほどで出来てしまったというのは、オープンソース文化とOpenBCIプロジェクトの挑戦の積み重ねによる成果とも言えそうだ。
こうなると、ちょうど9月に開催される音楽情報科学研究会・夏のシンポジウムが発表募集をしていて、そこに応募するネタをどうしようか・・・と考えていたところだったので、これは正に「渡りに船」である。 KickStarterでEmotiBitへの出資募集をしている、というのはOpenBCIのユーザMLから知って、本来であれば量産して提供されるのは2022年の2月あたりだというのに対して、余計に出資することで、手作業で試作しているベータ版を2021年6月に入手できるというoptionでEmotiBitをゲットした、という時間的な優位性を活かさない手はない。 そこで、まだだいぶ先であるものの、その予稿に記載できるように、ここで改めてEmotiBitの全体像を整理してみることにした。
まずスタートは Kickstarterの出資募集 である。 そしてプロジェクトの全貌は EmotiBitのサイト にある。 ただし「332 人のバッカーが$118,692プレッジしました」とあるように募集が終了してしまった現在では、このEmotiBitに興味を持って「購入」したい人は、 OpenBCIのショップサイト に行けば「$ 425.99」のところ「$ 399.99」で購入できるのだが、これはPre-Orderであり、実際に入手できるのは以下のように、来年2022年の2月か3月まで待たされるのだ。(^_^;)
さて、それでは改めて、 Getting Started with EmotiBit のページに従ってこのシステムを眺めていこう。 別売り(All in oneキットには1個入っている)の「LP801735」というリチウム電池のコネクタを上部のArduino(WiFi)に差し込んで、これを下部のセンサ基板とコネクタで繋ぐと完成するというのは非常に有効で面白い。 MyoやMuseはケース内にバッテリが入っていて基本的に交換ができないのが最大の欠点だが、このシステムでは このバッテリ がついていて、これが消耗してくれば自分で仕入れて交換すればいいのである。 僕もさっそくこのバッテリを業者に注文した。 そして、上に乗っているWIFi担当のArduinoは、どうやら Adafruit Feather M0 WiFi という、完成しているものであり、動作確認済みのファームウェアが書き込まれているので、パッと見には「WiFiモジュール」部品と見なせる位置付けになる。
上のように、リチウム電池の充電はこの基板のUSBから行い、Charging LEDが消えれば満タン充電ということになる。 基板にはリセットボタンしかなくて、上下の基板をコネクタで接続することが「電源ON」である。 そして、下のEmotiBit基板のマイクロSDカードスロットのすぐ横に小さな小さなプッシュボタンが横向きに付いていて、これを3秒間、長押しすると「スリープ」(hibernate mode)に入る(リセットボタンで再起動)というスマートな方式になっている。 この小さな小さなプッシュボタンがなかなか押せなくて困っていたが、調べてみるとスリープに入るためには、WiFiで接続しているEmotiBitOscilloscopeの「Power Mode」のメニューの中にある「hibernate」からでも指定できるのだった。 解説ページにもちゃんと「We recommend switching the EmotiBit into Hibernate mode instead of un-plugging the EmotiBit battery when not in use」と書かれていた。
上のアニメGIFで説明しているように、EmotiBitが扱っている(Max8で取得できる)生体情報(TypeTag)は以下のようなもので、サンプリングスピードは以下の表のようなものなのだった。
- EA EDA- Electrodermal Activity
- EL EDL- Electrodermal Level
- ER EDR- Electrodermal Response
- PI PPG Infrared
- PR PPG Red
- PG PPG Green
- T0 Temperature (Si7013)
- TH Thermopile(ML90632)
- H0 Humidity (Si7013)
- AX Accelerometer X
- AY Accelerometer Y
- AZ Accelerometer Z
- GX Gyroscope X
- GY Gyroscope Y
- GZ Gyroscope Z
- MX Magnetometer X
- MY Magnetometer Y
- MZ Magnetometer Z
ここまでで、過去にMyoとかMuseとかMuse2とかOpenBCIでやってきたように、まだ世の中には出てきていない新しい生体センシングシステムEmotiBitが、だいぶ身近で親しいものになった気がする。 脳波センサの場合には、開眼していると使えないというデメリットがあったが、こちらはMyoに近いものであり、お手軽な9軸WiFiセンサという見方も出来る。 まぁ、9軸WiFiセンサであればArduinoNano33BLEとArduinoNano33IoTがライバルなのだが、選択肢は多いほど嬉しいので、これはさっそく、何かやってみたくなってきた。 ちょうど某X社のプロジェクトは「バグ解決待ち」というフェーズで一旦停止しているので、ちょっと何かやってみようかなぁ。
2021年7月5日(月)
新しい週となった。 今日は午前に1人、午後に1人、それぞれ「基礎演習E」に関して支援のアポが入っているだけだが、おそらく某X社からもバグ対応の連絡が届くと思われる。 しかし昨日かなり進展したEmotiBitに関しては、さっそく夜中に実験してみたいアイデアが2つほど浮かんできたので、まずは朝イチから実験である。 OSCのパケットで届く生体情報のトラフィックを計測する、というのがその第二だが、まずそれよりも第一に確認したいのが「WiFi接続のテスト」なのだ。 1106研究室のお仕事Mac miniはLAN接続で使っているので、情報室へのMACアドレス登録はLANだけでWiFiは記入していなかったので、「WiFiをON」としても、DHCP接続のところで切られて「!」という表示のままとなってWiFiではSUACネットに出ていけないのだが、研究室内で学生のコンピュータとデータをshareする場合には、「!」のままのWiFiとBluetoothをONにすれば、AirDropで待ち受ける学生にデータをshareしたり、逆にAirDropを起動すればデータを受け取れるのである。 これはつまり、学内のSUACネットにはDHCP接続できなくても、部屋内に飛んでいるWiFiルータにだけは接続できるという事であり、それがEmotiBitに関して実験してみたい点として浮上したのだ。そこでまず、ホスト(EmotiBitOscilloscopeを起動する)のお仕事Mac miniに関しては、LANは接続したままで、さらにWiFiをOFFにするか、WiFiとして次の2種類のいずれかをONにするか、という計3つの条件を設定した。 WiFiルータのうち「AirMac」は研究室のLANに接続しているので、MACアドレスを登録していればDHCP接続してネットにも行ける。 WiFiルータのうち「Buffalo」は昨日の実験のようにスタンドアロンでDHCPサーバとして動作するものなので、EmotiBitのように指定していない場合にネットには行けないが、接続した機器同士は普通にclosed環境として情報交換(OSCのようなUDPも)が出来る。 EmotiBitのWiFi指定については、SDマイクロカード内に「config.txt」というテキストファイルを置き、その中に「{"WifiCredentials": [{"ssid": "Buffalo-G-####", "password" : "3t#######k5"}]}」などとIDと暗号化キーを指定すればいいのだが、これが複数候補を指定できるのだという。 昨日の実験で開通が確認できたのは、このEmotiBitの指定を「Buffaloのみ」として、「mini(ホスト)はLAN+Buffalo」かつ「EmotiBitの指定はBuffalo」というものだったが、これを「AirMacのみ」と「AirMac+Buffalo」としたらどうなるか・・・を実験してみたいのだ。
実験の結果は上のようになった。 SUACネットのDHCPに接続できない「AirMac」の指定は全滅で、要するに昨日の実験で行ったスタンドアロンDHCPサーバというWiFiだけが「使える」というものであり、まぁ当然と言えば当然なのだが、AirDropで起きている謎の現象はAppleがかなり裏で頑張っているのだ(Bluetoothとの連携というところがポイントか)、と判明した。 しかしこれでますます、EmotiBitが身近なものとなったので、この30分ほどの実験は有意義なものとなった。
- mini(ホスト)はLANのみ
- EmotiBitの指定はAirMacのみ → ×
- EmotiBitの指定はAirMac+Buffalo → ×
- mini(ホスト)はLAN+AirMac
- EmotiBitの指定はAirMacのみ → ×
- EmotiBitの指定はAirMac+Buffalo → ×
- mini(ホスト)はLAN+Buffalo
- EmotiBitの指定はAirMacのみ → ×
- EmotiBitの指定はAirMac+Buffalo → ◯
その後、「基礎演習E」の佐々木クンが来るアポ前の1限のうちに、上のように「OSCのパケットで届く生体情報のトラフィックを計測」の実験を行った。 計測は2箇所で、一つは「OSCパケット到着ごとにON/OFFするトグルの間隔」を2回に1回のペース(おそらく同等であろうと想定)で計測したもので、Maxパッチ内の右側のグラフ(縦軸はmaxが400msec)で表示してみると、およそ平均は200msec(毎秒5サンプル)であり、たまにフルスケールの範囲内(数msec〜390msec)で暴れていた。 もう一つはこのパッチがOSCメッセージをsequencialな「route」オブジェクトの連鎖でparsingしている処理の遅延の評価であり、1段目のrouteでclockerをONにして16段目のrouteでclockerをOFFにするまでの遅延を毎回、同じグラフによって表示した。 こちらはおよそ平均が100msecであり、たまにフルスケールの半分の範囲内(数msec〜200msec)で暴れていた。 生体情報などというのはMIDIと違って毎回正確に取得できるものではないので、これは全体として、まずまず「リアルタイム生体センサ」としては好成績であると言えるだろう。
「2限のアポ」だったが前の講義が早く終わったから・・・と「基礎演習E」の佐々木クンは10:30きっちりに1106研究室にやってきた。 この作品では既に、ArduinoNanoEveryに傾斜スイッチを取り付けたセンサ部分が完成していて、3Dプリンティングで「打出の小槌」を造形している途中となっている。 Max8パッチの方はゲームのシナリオについてほぼ作り終えていた(同時に履修している「サウンドデザイン」を遥かに超えるjitterプログラミングを駆使)ので、今回のアポはダミーで入れていた動画/静止画のデータをいくつかの試作版に改訂しての動作確認である。 そして上のように、いい感じに全体の進行を確認して、あとは個々のコンテンツの内容を充実させ、movieにはサウンドも入れればOKというレベルに早くも到達して、1106に来てから30分もせずに完了となった。(^_^)
あっさりと佐々木クンのアポが解決してしまったので、ここで余勢をかって音楽情報科学研究会・夏シンポの発表応募をすることにした。 そこで改めて EmotiBitのサイト に行ってみると、これを実現したチームは、上のような Connected Future Labs というプロジェクトである、と知った。 OpenBCIから知ったEmotiBitだったが、このチームは決して「生体センシングねた」オタクに限定しているのではなくて、Webの「Projects」というところで紹介しているように、どうやら「Algorithms」・「Bio-Sensing」・「Computer Vision」・「Health & Wellness」・「Installations」・「Mobile」・「Wearable-Tech」などのキーワードで色々な技術を組み合わせてシステムとして実現することに注力するという、テクノロジー主体のチームのようだった。 そして、昼休みには以下のように発表申し込みを完了してしまった。(^_^)
そして午後には「基礎演習E」の大庭さんが1106にやって来て、 このように ArduinoUNOにSHARPの赤外線距離センサを取り付け、mp3シールドを載せて、Arduinoスケッチまで完成させてしまった。 あとは造形で面白い作品が出来上がる・・・という行く末が見えてきて、明日と木曜日にも予備的に入れていたアポは「順調キャンセル」となった。 僕が配線を加工しているビニールテープを見て、お母さんがエイサー太鼓の修理に使っている・・・という話から、なんと大庭さんは沖縄から浜松にやってきたと判明して、出身の「うるま市」も知っていて20年ほど毎年かかさず沖縄に行っている僕の 沖縄行き ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ の話題で盛り上がってしまった。 この縁で、ますます大庭さんを応援していくことになりそうだ。(^_^)新・生体センサシステム"EmotiBit"は新楽器として使えるか Can the new biometric sensor system "EmotiBit" be used as a new instrument? ニューヨークのR&Dコンサルティング・グループである"Connected Future Labs"は2021年、「Wearable biometric sensing for any project」として オープンソースの新しい生体センサシステムを発表し、KickStarterでのクラウドファンディングによって、新・生体センサシステム"EmotiBit"を2022年2-3月に 提供する予定である。このシステムは定番の9軸センサ(加速度/ジャイロ/地磁気)に加えて、温湿度(3種)、心拍(3種)、皮膚電気特性(3種)の計18種類の 生体情報を、小型軽量ウェラブルWiFiモジュールから最大毎秒25サンプルでホストに伝送し、標準でOSCプロトコルも完備している。本稿では、過去に各種 オリジナル生体センサ(楽器)を開発するとともにMyo/Muse/OpenBCI/Muse2などの生体センサを解析報告してきた立場から、ベータテスタとしてこの新しい システムを紹介するとともに「新楽器」としての可能性について検討する。
土曜日に EmotiBitのバッテリ を業者に注文していたが見積もり連絡が来ないために発注を再送したところ、業者の輸入部門から「リチウムイオンバッテリーにつきまして,海外からの配送は安全上の理由で厳しく規制されております。このため,弊社ではお取り扱いをすることができません」とのメイルが届いた。 ちょっと目から鱗の盲点だったので、今度はドローン用に国内で(Amazon.co.jpから)購入できる同等品を見繕って、再度発注することになった。 某X社からのバグ解決のメイルは届かなかったものの、これで充実の月曜日はおしまいである。
2021年7月6日(火)
研究室に出てくると届いていたニュースとして、「フルトヴェングラー生誕135年記念! 商用リリース用として録音された音源すべてを、2021年新リマスター音源で収録した完全セット」というのがあった。 このような 素晴らしいものであり、タワーレコードの予約だと、55枚組みが このように 15000円ほどだという。 間違いなく「買い」である。 しかしググッと堪えて、予約のクリックを断念バーグした。 というのも、残念ながらこれからの人生で、この55枚のCDを聴くという時間は想像できないのだった(^_^;)。
1限には「基礎演習E」の東本クンのアポがあり、Arduinoのスケッチ暫定版を書き込んだところで、「まずは造形!!」と念押しして次に続けることにした。 その後ようやく某X社から改訂版のプログラムが送られてきて、久しぶりに電子楽器業界の恐怖プレイ「いじわるテスト」を行った。 その結果はOKだったが、僕が送ったメイルは「 今回、お送りいただいたバージョンのドングル・ファームウェアに対して、以前にお送りした「error_check.maxpat」にて「いじわるチェック」を実行しました。 これは楽器業界ではよくあるテストですが、例えシンセサイザーとか電子ピアノの鍵盤の白鍵と黒鍵それぞれの上にわたって、長さ1メートルとか50cmとかの定規を置いて、両手でそれを同時に押して離す、というのをビシバシと何度も高速に繰り返すことで、「ほぼ瞬間的に多数の鍵盤のON/OFF」という高密度なMIDIを送るというワザです(^_^;)。 これを受けきれず(受け落として)何かの音が残ったりすれば電子楽器の製品としては失格(バグ)となります。 「error_check.maxpat」では、8チャンネルのEMSチャンネルに対して同時にONを送って、さらに共通のduration(ON-OFFの時間)経過後に同時にOFFを送ります。 それをmetro(お送りしたパッチでは初期値1500msec)で繰り返すので、この数値をどんどん小さくしていけば「8チャンネル同時ON/OFF」の繰り返し間隔が小さく、つまり高速な繰り返しとなります。 実験ではまず、過去に即死していたレベルで、duration=50msec程度で同時ON間隔のmetroを500msec→300msec→200msecなどと速くしましたが、びくともしませんでした。 そこでさらに、150msec→100msec(毎秒10回)→70msecとしても平気だったので、duration=15msecとして、metroを50msec→40msec→30msec(毎秒33回、人間の演奏としてほぼ不可能レベル)→25msecまでテストしましたがOKでした。 そしてこれを1分以上、続けたところで、ようやくHUBが赤くなって死にました。(ここでようやくバッファ溢れのようですが、これは現実的ではないレベルなので問題ありません。どのような製品でも25msecのテストに対しては同様にストップします) これは楽器業界の厳しいテストを経験してきた(私のいじわるテストで、若手の開発した電子楽器の試作機にNGが出たことも多いです)私の印象として、ライヴの音楽演奏情報をMIDIで送ることに対して十分な機能であると判断します。 実際にはこのテストであれば50msecインターバル(毎秒20回)でも十分で、ここでmetroをストップして「emstyle stop」を送ると受け付けず(つまり、まだバッファに溜まっているデータをHUBに送り続けている)、再度送ったらきちんとストップしました。 その後のstartにもちゃんと対応したので、これもOKです。 」というような感じである。
そして4限に領域会議があるのでスグにあのスーツを着用せずに、Maxパッチを改訂する作業に着手した。 材料としては、ちょうどトヨタ中央研究所からの受託研究で開発した自動作曲パッチを流用できそうな感じである。 明日・明後日あたりには、あのスーツを再び着用してのテストが再開か・・・と思っていたそんなところに再びX社からのメイルがあり、なんとEMSパルスに230msecのランプ波形が乗算されていると判明した。 これでは音楽リズムのタイミングが鈍ってしまうので駄目、ということで、今日はその改訂を依頼するところまでとなった。
2021年7月7日(水)
この日は1限からゼミの永井さんのアポがあり、「早押しボタン」を改造してArduinoNanoEvery経由でMax8に接続するまでを一気に進めたが、残念ながらデジカメ不調で撮ったつもりの写真が残っていなかった(;_;)。 そして2限には杉山さんと清水さんが欠席して「ゼミZOOM」が以下のように進んだ。 ちなみに(リンク切れするが)全60分の記録動画は これ である。
その後、再び「訂正版→バグ報告→・・・」という無限ループ(^_^;)が某X社と続いたが、ようやく何度目かのループの後に、ほぼ希望するスペックでの動作に到達した。 あのスーツを着ての実験はその先にようやく始まるのだった。 そこで、途中でストップしていたMax8プログラミングをいよいよ本格的にスタートさせて、1日が終わった。 ネットからは以下のような見慣れない謎な「Myo」のページを見つけたが、どうやら最初のMyoが出る前?のサイトのようだった。
2021年7月8日(木)
今日は午前中からひたすらMax8プログラミング三昧でスタートして、2限と3限には このように 「基礎演習E」の2人の学生アポに対応してそれぞれ順調に進展した。 その後は再び、某X社プロジェクトのためのMax8プログラミングを進めていると自宅から連絡があり、COVID-19ワクチン接種の予約が取れた(^o^)とのことだった。 これで7/22の1回目、8/19の2回目まで順調に推移すれば、とりあえず9月になれば出張も可能となりそうで、現在は「慶應義塾のCOVID-19対応活動制限が解消されない場合オンライン方式に切り替え」とされている「可視化情報シンポジウム(VSJ2021)」には、ちょっとだけ光明が見えてきた。
そして元気が出てきたのでさらにMax8プログラミングを進めて、上のようにちょっとカッコイイ感じのものを試作してみた。 走らせてみるとスグにバグを発見して修正に追われたので(^_^;)まだまだなのだが、実際に例のスーツを着用しての実験は、また明日は終日ギッシリの金曜日なので、週末になりそうである。
2021年7月9日(金)
密度の高い金曜日がやってきた。 1限の「サウンドデザイン」では、「サウンド+グラフィック+インタラクション」の合体技という最終課題が出て、過去の先輩パッチからいくつか紹介したことで、学生たちもいよいよ気合いが入ってきた。 今年は来週マルマル、「支援」の回があり、さらにその翌週が休日(呪いのオリンピック開会式)のためにさらに1週間があるので、これを活用してどのように進展するか、楽しみである。 2限の「音楽情報科学」では、それぞれ新しい「キープ錯覚」をインタラクティブなMax8パッチ化する・・・という最終課題に向けて、こちらもそれぞれの制作を支援する最終フェーズに入った。 以下は中村さんと田中さんのプロジェクトを応援しつつ、まだ途中経過であるもののこれでも十分に面白い、という試作パッチの様子である。
そして4-5限の「基礎演習E」も、学生それぞれの制作フェーズとなり、僕は時間枠を区割りしたアポ表を掲示すると1106研究室に戻って待機する・・・という体制となった。 既に別途にアポを入れて支援している学生はこちらのアポ表も事前メイルで埋めているので、空白のコマは研究室で悠々と上記のようなMaxパッチの改訂版や実験を進められる。 以下の田中さんが挑戦している「クレイク・オブライエン・コーンスイート効果」は、WikiPediaを見ると直線的に輝度変化を付けた例があったが、ここは絶対にエッジに向かって指数関数的に変化させたいので、これをtableオブジェクトに手で描くという上の試作はまだまだ途上であり、是非とも数理造形らしく数式処理したいのである。
そしてこのMaxプログラミングを進めつつ、やってきた東本クンのMacのArduino IDEのライブラリ欠損を解決し、大庭さんのArduinoスケッチの追加仕様(距離センサだけでなく一定時間ごとに時報のように叫ぶ)を完成させ、堀田さんの造形内Arduino照明を速攻で仕上げ、吉田さんのMaxプログラミングをやや進展させ(本格的な制作アポは来週)、充実のうちに嵐のような時間が過ぎてオシマイとなった。 まずまずの手応えとともに週末に入る(当然、明日はいつものJoyJoyだ(^o^))というのは、(出張が)何も無い日々とはいえ、辛うじて生きている実感を支えてくれている。
2021年7月10日(土)
週末である。 朝イチでNIMEコミュニティに届いていたメイルは、「SMC 2021 Conference Videos and Proceedings available online」というもので、オンラインで開催されたSMC2021の 論文集 が公開されたというものだった。 発表の様子も YouTubeチャンネル として置かれているよ・・・というものだったが、行ってみたら数件しか無かった(^_^;)ので、やはりオンライン開催の2年目は低調だったのかもしれない。
そして、懸案は午前中に片付けようとひんやり濡らしたインナーを着てあのスーツを着用して、某X社プロジェクトの最初の試作を実験して動作を確認できた。 なかなか面白い体験だが、これがどのように発展していくかは、まだまだこれからである。 その後は、午後〜晩にいつもの6時間を予約したJoyJoyを楽しみに、引き続き「音楽情報科学」の学生プロジェクトの実験・改訂に精を出した。
2021年7月11日(日)
昨日のJoyJoyヒトカラ(飲み続け)6時間では、先週の65曲 ★ とのカブりは練習曲のたった2曲だけ、というまずまず「攻めた」64曲 ★ を完走した。 先週獲得した「長時間ヒトカラの攻略法」を続けてみたが、なんといつも必ず途中にある「ドラッグタイム」(声枯れを避けるためにAmazonで仕入れている漢方薬[超・効く]を飲む)を、なんと今回初めて「ナシ」で済ませてしまった。 これはかなり画期的なことで、僕にとって5-6時間のヒトカラマラソンにこの「響声破笛丸料 エキス細粒」は必携であり、ここ1年5ヶ月ずっと続けているヒトカラで、これを途中で飲まなかった日は一度も無かったのである。(^_^)
そんな充実感と疲労感とで研究室に出てくると、ウチの奥さんからメイルが届いており、息子から送られてきたという「孫の写真」のプリント作業というお仕事に1時間ほど忙殺されたが、まぁこれも悪くないだろう。
そしてこの週末は、先週までは金曜日の「サウンドデザイン」と「音楽情報科学」の講義ページを改訂したりする作業があったのだが、もう最終課題に向けて「制作」期間に突入して、最終回まで講義ページを完成させていたので、昨日に続いて「音楽情報科学」の学生プロジェクトの実験・改訂に取り組む(Max8プログラミング)、という楽しい休日となった。 そして午後じゅうかかって、以下のように「クレイク・オブライエン・コーンスイート効果」を色々に調整できる(そして手作業でその特性テーブルを自在に変更描画もできる)、まさに「数理造形の塊」のようなパッチが完成した。 YouTubeに上げたその動作の様子が これ である。 なかなかに充実感のある出来となった。(^_^)
2021年7月12日(月)
新しい週になった。 昨日の楽しい楽しいMax8プログラミングの余韻は頭の中のどこかに残っていて、目覚める時にフト、重大な改訂点を思い付いて研究室に出てきた。 そして朝イチの一時間ほど、かなり集中して、以下のように完璧な「クレイク・オブライエン・コーンスイート効果」体験パッチが完成した(^_^)。 昨日のバージョンでは、2つの区間の両端の輝度変化が同じパターンだったが、この錯視の面白さは「バンプ」感覚にあり、ある区画の左側と右側の輝度変化を昨日のように同じにしていたのでは、「それぞれの区間の中央付近の色が同じであるのに違ってみえる」という効果が出ない・・・と気付いたのだ。 改訂の原理は簡単で、区間の境界の左と右のブロックはそのままにして、真ん中のブロックだけ、Y軸方向を反転させればいいのである。 これは「uzi 3」で3つのブロックを指定しているので、その数値(0,1,2)を「% 2」することで簡単に判別できるのだった。 さらに「swatch」で、単純なグレースケールだけでなく、自由な色彩を選べるようにしてみた。 朝から一仕事、片付けたというのは気持ちの良い週明けとなった。
午前中には、まだあと2件残っている、この夏の学会発表の予稿執筆に取りかかった。 残っているのは電子情報通信学会ヒューマンコミュニケーション基礎(HCS)研究会(「ウェルネス・エンタテインメントのためのインタラクティブな錯覚体験システムに向けて」)とEC2021(「新楽器をデザインする」というエンタテインメント)であるが、いずれも提出の締め切りが延びて今月下旬となっている。 HCS研究会のネタは、まさに現在進行形の「音楽情報科学」の学生課題と関係しているので(今朝のMax8パッチもこれ)まだ着手は後回しとして、まずはEC2021の過去ネタの発掘ということになった。
ネットニュースからは上のような、ボストンダイナミクスでなく中国・テンセント(騰訊)のロボット「Ollie」のgif動画が届いた。 いやいや、バク宙とは大したものである。 そして午後には某X社とのZOOMミーティングがあったが、その後にフト思い付いて、「音楽情報科学」の中村さんテーマの「蛇のフリッカー回転」錯視のMax8パッチ化に取り組んで、なんと夕方までに完成してしまった(^_^)。 やはり、このところ「Maxプログラミング脳」になっているというのは大きいようだ。
2021年7月13日(火)
昨日は夕方に用事があったので、帰り間際に完成した「蛇のフリッカー回転」錯視のMax8パッチを記録する余裕がなかったので、今日は朝イチで以下のようにそれを並べてみた。 不思議なもので、(swatchで配色を変えられるので裏ではmetroで叩いているものの実質的には)カラーの静止画とグレーの静止画とを、交互に切り替えたりクロスフェードさせているだけなのだが、切り変わりのところでどうやっても「回転している」ように見えてしまう、という素晴らしい錯視(画像)なのである。 これは金曜日の「音楽情報科学」で皆んなに見せるのが今から楽しみだ。
午前中は大谷翔平の大リーグ・ホームランダービーの死闘をネットのライヴ中継で凝視しているうちに過ぎ去った。 同点延長、再同点延長、そしてサドンデスで1回戦敗退だったが、これを録画でなくライヴで見たというのは素晴らしい時間となった。 そしてかたや旭川からは王位戦の第2局もネットのライヴ中継をしている・・・という、なかなかお仕事しにくい日なのだ。
午後には、「音楽情報科学」で「停止・粘着錯視」に挑戦している松本さんからの巨大(超冗長)なパッチが届き、とりあえず「lcd」を「jit.lcd」にして、さらに「uzi」を活用した上のようなサンプルパッチを作って送ってみた。 まだまだここから「停止・粘着錯視」までの道のりは長いが、松本さんなら打開していく可能性もあるのでスグに完成させず、頑張る余地を残すのも重要なのだ。
2021年7月14日(水)
今日はゼミの日であるが、北京の王さんから欠席連絡があったのでZOOMはナシとなり、さらに杉山さんから遅れて参加の連絡があったので、 このように 3人が1106に集まって、それぞれの進捗報告をサクサクと進めた。
そして昼から午後イチで杉山さんと相談した後に杉山さんは作業のために総合組立アトリエに向かい、僕は このように 宿題となっていた「早押しピンポンボタン」の改造に取りかかった。 ゼミの永井さんも同じピンポンボタンを改造したが、そちらは単純な押しボタン部分とするためにスピーカや「立ち上がる丸い板」を除去してArduinoに繋いだが、こちらは単4電池2本で押したら「ピンポン」と鳴るという本来の機能を残しつつ、同時にそのボタン操作情報を取得してArduinoからMax8に送るので、アナログ部分に厄介な試行錯誤の実験が発生した。
結局、スピーカの信号をダイオードで直接に整流したラインの電圧をArduinoNanoEveryのアナログに入力に繋ぎ、その点とGNDとの間に105と100kΩを並列にした時定数回路を入れることで、ボタンを押すと十分な電圧になり、その後に自然に放電するという理想的な電圧をホストのMax8に9600bpsのシリアルで送る・・・という単純なシステムが無事に完成した。 ボタンの横っ腹に穴を開けてUSBケーブルを挿せるように、ArduinoNanoEveryはエポキシ接着剤でがちがちに固定した。 これであとは作品の実現に向けて全力投球ということになりそうだ。
2021年7月15日(木)
今日は2限と3限に「基礎演習E」の学生アポ、4限にデザイン学科会議、5限に学生委員会、と予定が詰まっている。 空いている1限には、Max8のライセンスが切れないように(SUACネットだとライセンスサーバとの接続が何故か失敗する)自宅に置いているレンタルWiFiルータを研究室に持ってきて、6台のMaxBookAirとお仕事mac miniと2台のMacBookと1台のWindowsの全てでMax8ライセンスの確認(更新)をして、さらにそれぞれのバッテリが減っていたのを充電した。 自宅に置いていた2台のiPad Touchのバッテリがゼロになっていて慌てて充電したのを契機に、合わせて研究室の2台の古いiPadと2台のiPadと2台のAmazon Fire8/10の充電も行った。 そこに届いたのは、一昨日に某X社に「改善要請」していたシステムの改訂版であり、以下のように久しぶりに謎な作業を行って、バトンはMax8プログラミングのこちらに渡った。
このところ某X社とのやりとりでは、制御情報を送る僕のMax8パッチに対して、X社の「ドングル基板」と「HUB装置」という2つのシステムのそれぞれのファームウェアが対応関係にあり、さらにそのプロトコルの仕様書が共通認識として共用される。 ここで備忘録としてメモしておくと、今回zipで届いた3つのファイルに対して、このところ以下のようなルーチンを繰り返して対応していて、これは基本的に今後も続くことになる。
そして、上の作業の前半が終わっていよいよMax8プログラミングだ・・・というところに、「基礎演習E」の早川さんがやってきて、およそ40分で このように ハンダ付けを無事に完了して、後は造形が勝負というところまで進んだ。
- お仕事Mac miniのにて某X社から届いたzipを解凍する。中身は「仕様書.pdf」と「ドングル.zip」と「HUB.zip」の3つ
- 「仕様書.pdf」は最新版として作業エリアにコピーして参照する
- 「ドングル.zip」を解凍すると「ドングルhex」になる
- ドングル基板のファームウェア書き込みUSBポートを接続するとディスクイメージのアイコンが出現する(mbed方式)ので、ここに「ドングルhex」をドラッグ&ドロップする。これにてファームウェアの書き込み完了。アイコンをゴミ箱に移動させてアンマウントして、このUSBポートは電源供給用としてUSB電源アダプタに繋ぐ
- お仕事Mac miniのWiFiとBluetoothをONにする
- iPadのWiFiとBluetoothをONにして、AirDropをONにする
- 「HUB.zip」を指定してshare先としてAirDropを指定するとiPadのアイコンが出現するので選択する
- iPadは「AirDropを受けていいか?」と聞いてくるのでOKして受け入れアプリとして「nRF Connect」を指定する
- AirDropにて「HUB.zip」がiPadに転送され、「nRF Connect」が起動する
- HUBの電源を入れて「nRF Connect」のscanでこれを選択して接続する
- 書き込みメニューによってファームウェアを書き込む
- これにて一連のファームウェア更新作業は無事に完了(^_^)
- ホスト側でMax8のプログラミング
- ドングル基板のシリアルポートを接続して電源ON
- HUBの電源を入れるとドングル基板と接続される
- ホスト側(Max8)からコマンドを送ればドングル基板を介してHUBに情報が伝送される
昼休みには某X社の改訂版のテストをして、一部の仕様設定のミスを指摘して、さらに動作状況の報告(まだ性能として問題アリ)とともに実験用Max8パッチを作って送った。 そして3限になり、今度は「基礎演習E」の吉田さんがやってきて、 このように あれこれ進めた。 吉田さん作品は軽音の気合いでちょっとだいぶ背伸びを応援しているのだが、マイク音声をライヴサンプリングしてドラムと一緒にシーケンス再生しつつ、3Dプリンタで作った3体のバンドメンバー(体内は高輝度3色LEDでライヴ照明)が乗ったライヴステージ(PAシステム有)、という感じに進展する予定である。 以下のように3Dプリンタの造形はLEDテープでいい感じに光ることを確認できた。
そして4限に会議、5限に委員会、と身体だけ嫌々出席してじっと我慢の時間を取られていると、気圧と同様に次第に体調が低下してきたのを自覚した。 気付いてみれば、今月下旬が締め切りの原稿提出が2件、何も手付かずで残っている。 明日もびっしりの金曜日だが、いよいよこの週末からは尻に火がついてきそうな雲行きである。
2021年7月16日(金)
そして週末の金曜日、それも来週は祝日でスキップしてその翌週は学期末の最終課題合評日となる、事実上は「大詰め」の日がやってきた。 午前中は このように 「サウンドデザイン」と「音楽情報科学」で、それぞれ学生は最終課題の制作に精を出す・・・という風景となった。 昼休みには、某X社からは昨日の課題に対応したというバージョンのデータが届いたが、実験してみると性能は低下していた(^_^;)。
そして4-5限の「基礎演習E」では、佐々木クンと吉田さんがそれぞれ1106研究室にやって来た。 打出の小槌を3Dプリンタで作ったり、木製のステージをレーザーカッターで作ったり、まったく造形の時代も様変わりしたもんだが、やはりインタラクションの「肝」はスケッチングにあるのだ・・・と再確認できた。 二人の作品の完成が楽しみである。
2021年7月19日(月)
一昨日の土曜日は朝イチの眼科検診(進展ナシ(;_;))の後、いつものJoyJoyヒトカラに出かけるまでの4時間、みっちりEC2021の予稿を執筆したが、まだまだ先は見えない(3ページ程度)ところまでだった。 そのJoyJoyヒトカラ(飲み続け)6時間では、先々週の65曲 ★ と2曲だけカブっていた先週の64曲 ★ の両方に対してカブりが"Jupiter"たった1曲、という新たな69曲 ★ (カブりを除いて計195曲)を完走した。 また先々週に会得したスロースタートの技とともに、先週に続いて「ドラッグタイム無し」(響声破笛丸料を服用せず)も継続している。 こうなると、さらに今週末も同じチェック記入済みのプリントアウトを持参して、さらに「カブり無し」の修行を続けたくなってきた。 そして昨日の日曜日は、朝から晩まで終日、ひたすらEC2021の予稿執筆を続けた。
昨夜は計9ページになった原稿をプリントして持ち帰り、自宅で赤ペンを入れて、今朝は朝7時に研究室に出てくるとまずは赤ペンの原稿修正を行って、遂に この予稿 が完成して、EC2021のサイトに提出を完了した。 その勢いのまま、予稿と共に提出する必要がある「抄録用画像 : 図やイラストを主に利用した一枚画像.画像のファイル形式はjpg/jpeg/gif/pngとし,横幅が1200px以上(1600px推奨)で,3MB以下になるように作成してください」というのも、「SUACインスタレーション」のページにある作品画像を集めて1枚にまとめて、4800*3600ピクセルという日頃は馴染みの無いサイズにして、上のように完成させたものの提出を完了してしまった。 上のリンク先の画像は7.2MBあるが、これはJPEGの圧縮を100%(非圧縮)にしたからであり、提出版は90%に圧縮した2.8MBの画像である。
そして午前10時から午前中ずっと、ゼミの永井さんが研究室にやって来て、 このように 「総合演習II」の作品の制作を追い込んだ。 まだまだ盛りだくさんなので、明日の1-3限にもアポを入れてあるが、さらに水曜のゼミ前の1限にもアポが入った。 コロナを意識したこの作品が完成するように、応援を続けていこう。
さらに午後には、「音楽情報科学」と「サウンドデザイン」をダブルで受講している中村さんのアポがあり、いい感じの「絵心」系ゲームをほぼ企画通りの感じに実現するような道筋をつけた。 あとは画像データの仕上げと、効果的なサウンドを加えるだけで十分な没入感のゲームになりそうである。(^_^)2021年7月20日(火)
今週の後半はオリンピックの関係で木金が臨時に祝日になっているので、あと今日と明日だけという週だが、午前も午後も学生のアポでびっしり埋まっている(^_^;)。 某X社からは「改訂版」が届いて、テストしてみると、ようやく無事に「届いたMIDI(的)音楽演奏情報を受け落として誤動作する」という論外の動作が無くなっていた。 ここまで1ヶ月以上もかかったのだが、まぁ一歩前進というところだ。 ちょうどカード会社の明細が届いて、この某X社との受託研究の関係でAppleから購入した、以下の「MainStage」というソフトの支払い手続きをしたところだが、結果としてこのソフトの出番はナシということになった。(^_^;)
そして1限から3限までゼミの永井さん作品の追い込みを、4限から5限まで「基礎演習E」の吉田さん作品の追い込みを このように 進めた。 これから造形(ステージ)の外観が大きく変貌するというので、制作途中バージョンの吉田さん作品を記録したYouTube動画が これ である。 とても2回生前期とは思えない力作に成長しつつあるのが楽しみである。(^_^)
2021年7月21日(水)
「サウンドデザイン」を受けている学生から「Maxの最終課題でオリジナル要素としてイラストではなく動画を使用したいです。動画サイズは640×480で製作しています。Maxに動画を貼り付けられることは調べ知りました。使用してもよろしいでしょうか」とのメイルがあったので、『サウンドデザインの最終課題は「ここまで学んだもののまとめ」とあります。動画(ムービーの再生)というのは、Maxアニメーションのような柔軟性がありません。AとBとCのキャラクタがそれぞれ動く「動画」があったとしても、あるキーを押したらその中のAだけストップするとか、別のキーを押したらBだけ逆回しに動くとか、Cだけランダム、というような自由度がムービー再生には一切、ありません。予告しているように、後期「メディア数理造形演習」ではMaxの拡張機能のjitterを扱いますが、そこでは動画を自由な速度や方向で制御するだけでなく、ライヴのカメラ画像や3次元CG(Open-GL)などに広がります。ツールで簡単に作った動画をを再生させるだけでなく、Maxのアニメーションは自由なインタラクティブ性が実現できるところが「肝」です。自分で調べてMaxで動画を扱う自主制作は自由ですが、サウンドデザインの最終課題としては失格です』と返信した。
そして1限アポの永井さん作品を追い込みつつバグが残った(^_^;)まま、2限には古谷さんが1106に来て、ZOOMで北京から王さんが来て、残り2人は欠席連絡があり、前期最終のゼミが このように 進んだ。 ちなみに(リンク切れするが)全48分の記録動画は これ である。 ちょっと永井さん作品のMaxパッチのバグは根深い予感がするので、某X社のシステムのテストという宿題を棚上げして、明日から4日間の連休の最大のテーマになりそうな悪寒がする(^_^;)。
その後、午後はゼミの杉山さんの卒制の追い込みを進めたが、自宅で撮ってきた「宇宙人YouTuber」という動画が秀逸であり、Arduinoを仕込んだボタンと共に、大きく作品成功への感触を得ることが出来た。 あとは来週に、発表会場である講堂でのリハーサルが勝負となった。 そしてそこから夕方にかけて研究室でただ一人、冷静に落ち着いて集中してみると、なんと難題のように思えた上の永井さん作品のMaxパッチのバグも、ツギハギ対策を排除してきちんと整理することで、なんとか解決した。 これで気持ち良く連休に突入であり、明日は遂に懸案だったCOVID-19ワクチン接種の1回目である。(^_^)
2021年7月22日(木)
明日がオリンピック開会式ということで臨時祝日となった今日であるが、何日か前に開会式の作曲家が辞退させられたと思ったら今日は開会式の演出家が即日一発解任ということで、流石の電通というのか、このコロナ下でのオリンピックとは一体何なのか、という暗雲が国内どころか世界に漂っている。 お仕事のメイルも全く届かないこの連休は「稼ぎ時」であり、朝イチから始めてお昼にザザ2階のワクチン接種会場に行ってきた1時間ちょっとを跨いで、夕方には懸案だった最後の原稿執筆、HCS研究会の この予稿 を書き上げて、学会サーバに送ってしまった(^o^)。 中身としては、「音楽情報科学」などで一緒に錯覚ネタを考えてきた学生たちに感謝感謝、というものである。これで、この2021年度前期は上のような感じで、ここまで発表2件完了、これから5件発表のうち、あと音楽情報科学研究会だけ原稿未提出(8/21締切)となった。 それより前に、来年の国際時間学会ISST2022へのアブストラクト提出の締め切りが8月15日にあるので、来週の学期末を乗り越えたらこちらに注力することになる。 AbemaTVでの生中継では藤井王位がやや優勢を続けており、ワクチン接種から4時間したところで痛みも出てきて、無事に生理食塩水では無かった・・・と実感できた。 これで今夜は大人しく禁酒であるが、明日もお仕事して、明後日のJoyJoyに元気に向かっていく・・・という充実の連休を過ごせそうである。
- 「ライヴ"Risset Rhythm"音楽への道」 2021年6月20日 日本時間学会第13回大会
- 「インタラクティブ錯聴実験に関する2つの考察」 2021年6月27日 日本音楽知覚認知学会2021年春季研究発表会
- 「ウェルネス・エンタテインメントのためのインタラクティブな錯覚体験システムに向けて」 2021年8月21日 電子情報通信学会ヒューマンコミュニケーション基礎(HCS)研究会
- 「Real Time Risset Rhythm Generator」から「Live Sampling Risset Rhythm」への道 2021年8月25日 FIT2021
- 「新楽器をデザインする」というエンタテインメント 2021年8月30日-9月1日 EC2021
- 「ライヴComputer Musicにおける情報可視化についての考察」 2021年9月9-11日 可視化情報シンポジウム(VSJ2021)
- 「新・生体センサシステム"EmotiBit"は新楽器として使えるか」 2021年9月16-17日 音楽情報科学研究会・夏のシンポジウム ★原稿提出まだ
2021年7月23日(金)
晩にオリンピック開会式があるという日である。 昨日の演出家解任劇はいたって当然のことであり、ホロコーストをネタに使うなどというのは言語道断なのだ。 僕は2018年の 欧州ツアー では、初めてのポーランドに行ってPoznanでの国際会議に発表参加するというので、調べて途中でKrakowに立ち寄る旅程を立てた。 僕が沖縄に学生と行く時にはまず必ず「ひめゆり」に連れて行くのと同じで、人類が直視しなければいけないアウシュビッツに行くためだった。 その模様は 欧州ツアー および Max7日記(2) の「2018年9月14日(金)」のところにあるが、とにかく想像を絶する悲惨さだった。 「ジェノサイドは現在の人類にもあるからこそアウシュビッツの存在意義がある」。 これをネタにするというのでは、もう、そんな人間は未来永劫、駄目だ。 こんなオリンピックなら、もう呪われて朽ち果てればいいのである。 チケットが当選した遥か昔には喜んでいたが、早々に見限ってキャンセルしていて良かった。
午前中には久しぶりの思い出しとして、 この日記のPart9 の「2021年6月21日(月)」にまとめていた、ISST2022の CFPのページ (オリジナルは これ )を、今度は「応募するぞ!」モードで真剣に読み解いてみることにした。 「推奨されるトピック」の中であれば、僕は「音楽、詩、演劇、ダンス、映画における「テンポ」の機能をどのように測定するか? 視覚芸術において、時間の尺度はどのように関わっているのか?」という問いに対して何かを発信するべきだろう。 また「その他の推奨されるトピック」の中であれば、「時間の測定または誤測定としての歴史」を音楽情報科学の分野で語るとすれば、まず僕の仕事だろう。 さらに最近の仕事と関連させるのであれば、「錯覚体験→ウェルネス・エンタテインメント」の中で、運動錯覚、マルチモーダル錯覚、時間錯覚、錯聴、などの「時間要素」にfocusしたものを紹介する、というのも新しい材料が豊富にある。 そして最後の段落で、「提案は、20分間のプレゼンテーションで、様々な形式で行われます。学術論文、ディベート、パフォーマンス、創作物の概要、インスタレーション、ワークショップなど、さまざまな形式で20分間の発表を行っていただきます」とあった。 これは、過去にいくつもの国際会議でチュートリアル、ワークショップ、レクチャー等を行ってきた身としては、普通にoral発表するのとは別の形態というのも、挑戦してみたい気がした。
そして、半日かかって「 芸術において、映像や音楽の表現テクニックには人間の時間感覚や時間錯覚に基づいているものが多い。基礎心理学の領域では、日々、新しい錯覚が報告され、人間の知覚認知活動の解明にも貢献している。我々はメディアデザインの立場から、錯覚体験における気付きの"AHA!感覚"や意外性の認識が脳活動を活性化することで軽度認知症予防やリハビリなどに有効な「ウェルネス・エンタテインメント」となる可能性を追求している。私はこの発表において、時間感覚や時間錯覚をテーマとして我々が新しくデザインしたいくつもの錯覚体験システムを紹介し、実際にインタラクティブに体験してその意義や有効性を議論するワークショップを提案したい。 有名な古典的錯覚の多くはパッと見るだけの静止画であり、またはループ動画(アニメGIF)の形式の運動錯視であることが多い。しかし人間の知覚認知活動には個人差があり、同じ錯視画像に対して誰もが同じ反応・印象を持つとは限らない。我々はインタラクティブなマルチメディア・デザインの手法を活用して、静止画やループ動画という固定的な錯覚素材に限定されず、体験者が自分なりに各種のパラメータを微調整できるようなシステムをいくつも構築してきた。ここで我々が見出したのは、視覚的な形状・色彩・運動の特徴量や、聴覚的な特性の時間変化具合などを調整することで、錯覚体験の度合いや関心が個人差として大きく異なってくるという事実であった。私はこのワークショップにおいて、参加者に実際にインタラクティブな錯覚を体験してもらって、これが新しいエンタテインメントに成長する可能性について議論したいと考えている 」という原稿を書いて、DeepL翻訳で英訳するとちょうど287wordsのいい英語に変換できたので、そのまま一気にポストしてしまった(^_^;)。 上の画像はその「受け取りました」ページの様子である。 2年前までであれば、Google翻訳に突っ込んでは稚拙な英語が返ってきてさらに訂正して・・・というのを繰り返したものだが、いやー流石のDeepL翻訳なのだ。 これ以上、いくら文章をいじくっても改善される余地もなく、これは現在の僕の限界なので、これにて来年の世界時間学会に発表参加できるかどうか・・・という件は「終了」である。 結果の連絡は完全に忘却した頃、12月15日だという。
この応募にあたっては、Max8でちょっとした実験をやってみた。 ワークショップ形式のために1台でなく複数台のMacBookAirを持参することは想定しているが(現在5台あり)、事前にMacアプリ化して配布する可能性の検証である。 Maxパッチには「アプリケーション書き出し」という機能があるが、defaultの「open this patcher」だけだと、同じディレクトリ内に置かれた画像/ムービー/サウンド等の素材が取り込まれないのでは・・・という点の確認である。 そこでメニューの「Include File...」というので、一つ一つ、外部に置かれた素材も指定したらどうなるか、というテストを上のようにやってみたのだが、案の定というのか、「Include File...」によってアプリ本体内にコンテンツも取り込まれて、単一のアプリというファイルでMaxパッチ作品を公開できると確認できた。 これは、地味ながら大きな進展である。
2021年7月24日(土)
昨夜はチケットをキャンセルした身としてオリンピック開会式を観ずにお笑いライヴを選んだが、今朝の朝イチで研究室に届いていたニュースは「New advanced material shows extraordinary stability over wide temperature range」というタイトルで、 -269℃から1126℃まで体積変化しない新物質 : Sc1.5Al0.5W3O12 という報告だった。 素晴らしい研究・発見である。 思わず化学式から構成元素の確認として「スカンジウム、アルミニウム、タングステン、酸素」と調べたり、 結晶系 とか 直方晶系 について調べてしまった。 しかし、まさかここに「クラインの四元群」が出てくるとは思わなかったなぁ(^_^;)。
そして午前いっぱいかけて、某X社プロジェクト(受託研究)に関して「経過レポート」を作成するために、まず研究室で全裸になり、導電繊維のインナー上下を濡らして着用し、その上にEMS電極スーツを着用して、現状の動作確認とパラメータの検討を行った。 来週の月曜日には某X社とのZOOMミーティングがあるので、その資料として最新のMaxパッチとアプリ化したものも送って、これにて準備万端OKとなった。 午後から晩には、予約してまたまた今週もJoyJoyヒトカラ6時間であり、オリンピックなどを観戦している暇はないのだ。
2021年7月25日(日)
昨日のJoyJoyヒトカラ(飲み続け)6時間では、今月3日の65曲 ★ と2曲だけカブっていた先々週の64曲 ★ と1曲(Jupiter)だけカブっていた先週の69曲 ★ に対して、意地のカブり無し選曲で驚異の82曲 ★ (カブりを除いてこれで今月は計277曲)を完走した。 だいぶ残りが減ってきて、昭和アニソンとか昭和フォークの短い曲が多かったためだが、続いてきた「ドラッグタイム無し」(響声破笛丸料を服用せず)も継続した。 ただし翌朝には喉の疲れを感じて「ペラック」と「響声破笛丸料」と「葛根湯」を服用した(^_^;)。 このシリーズはこれにて終わりで、次回からは このリスト を改訂した新しいプリントアウトを持参することにした。今日はそのリハビリとして、AbemaTVで「叡王戦」の豊島vs藤井をだらだらと観戦する1日となったが、午後になって、ゼミの永井さんとメイルをやりとりして、明日の午前のアポをキャンセルすることにした。 永井さん作品のMaxパッチはバグが解決して先が見えたのに対して、重要な造形がまだ残っている(火曜日にも1-3限アポが入っている)こともあるが、実は今朝から原因不明で左目が痛むので、明日の朝に眼科通院することにしたい・・・と連絡したのがきっかけなのだ。 今日は研究室でもずっと眼帯をしていたのだが、明日の朝に起床してどうなっているか、明日から学期末の重要な週を迎えるというのに、先はまったく読めない感じとなってきた。
2021年7月26日(月)
予約ナシで駆け込んで計3時間かかった眼科で判明したのは、角膜上皮が新たに薄く大きくごっそりと剥がれていた・・・という事で、昨日の痛みはその傷が常時、瞼の裏側と接触するからだった。 久しぶりに保護用のソフトコンタクトレンズを装着すると懸案は解決したが、また土曜日に通院ということで、週1ペースの眼科通院が復活してしまった。 ついでに続けて耳鼻科に行き、処方薬局を経て研究室に出てきたのはほとんどお昼となったが、懸案2つが片付いたのは朗報と言える。 そして午後イチでの某X社とのZOOMミーティングも終えて、午後には このように ゼミの杉山さんの「総合演習II」と「卒業制作」の最終追い込みを進めた。 明日はゼミの永井さんと古谷さんも1106に来る予定であり、午後には吉田さんも最終追い込みにやってくる。 いよいよ大詰め週間なのだ。(^_^)
そして、唯一「慶應義塾のCOVID-19対応活動制限が解消されない場合オンライン方式に切り替えの可能性あり」と一縷の望みがあったためにホテルも予約していた可視化情報シンポジウム(VSJ2021)のサイトに久しぶりに行ってみると、「COVID-19収束の見通しがつかないため、オンライン開催とさせていただきます」とあったので、泣く泣く予約していたホテル(横浜に通う日々なのに新宿歌舞伎町の東横イン(^_^;))をキャンセルした。 まだまだ出張というのは先になりそうである。
2021年7月27日(火)
普段だと、オリンピックの生中継は日本では深夜だの早朝だのということで全く見ることが出来ないので、稀に海外出張中にだけ、ホテルの部屋で見れたりした。 ところがいざ、日本で開催されてみても、いつも21時前に寝て朝5時に目覚める身としては、上の卓球の二人(左は15年前)の金メダルの瞬間も寝ていて見逃して、今朝のニュースで知ったところなのだった。 まぁ、目出度いことはいいことだ。
そして1-3限までブチ抜きのアポを入れていたゼミの永井さんと、途中で合流する予定としていたゼミの古谷さんの2人は、 このように それぞれの追い込みとリハーサルの動画記録を進めて、午前中で無事に明日の朝に1106集合するところまで確認した。 古谷さんは明日のプレゼンPDFも確認し、永井さんは夕方までにPDFを作って提出ということになり、この2人も明日の最終合評が「見えて」きた。(^_^)
4限になると、「基礎演習E」の吉田さんがやってきて、 このように かなり完成度が上がってきた造形とともに、全体のシステムを組み込んで記録動画を撮ってみた。 これはちょっと普通の2回生のレベルをかなり超えたところに到達しつつあり、金曜日の最終合評が楽しみになってきた。(^_^)
「音楽情報科学」の課題を制作している松本さんからはMaxパッチのSOSのメイルが届いたが、ちょっと無駄にuziを連結し過ぎてoverflowとなっていた(^_^;)。 このところMax8プログラミングをびしばしやっている僕は、秒殺で上のように「とりあえず解決」版を作って返信したが、ここから本当の「遊べる錯視」にするには、まだちょっと試行錯誤の苦労が必要かもしれない。 そんなこんなで、あれこれプロジェクトが進んで1日が過ぎ去っていく。(^_^)
2021年7月29日(木)
昨日は終日、4回生「総合演習II」(一部5回生の「卒業制作」も)の最終合評があり、僕はインタラクション領域とビジュアルサウンド領域をダッシュで移動する・・・という最終回が このように 行われた。 晩に終わってみればヘロヘロに疲れたものの、学生の頑張りに圧倒され充実した1日となった。 ゼミの永井さんと古谷さん、そして2科目ダブルの杉山さんも無事に全てをこなして完了した。
そして今日は、いよいよ明日が最終合評となった「基礎演習E」の2人がそれぞれアポを入れてやってきて、 このように 動作確認の録画まで済ませた。 いずれも力作であり、ウケるのは確実なのだ。 今から明日が楽しみである。(^_^)
2021年7月30日(金)
そして前期の実質的最終日、1限「サウンドデザイン」・2限「音楽情報科学」・4-5限「基礎演習E」の最終合評の日である。 「遠足の朝」現象でいつもより早く5時前に起床して、いつもは食べない朝食をとって、朝6時台には研究室に出てきたが、OpenBCIからの このような 定期便ページが届いていた。 涙ぐましい感じもするが、こうやって新しい情報を提供し続けないと、オープンソースのプロジェクトは続いていかないのである。
午前には1限・2限と順調に最終合評が進んで、きちんと最後まで提出した学生は無事に単位を確定させた。 それぞれの作品については、細かいデバッグとか整理をして後期までにWebに上げることにするので、この日記でもいずれスクリーンショットとかが並ぶことになるだろう。 そして午後の4-5限には、 このように 「基礎演習E」の最終合評があった。 僕はほぼ全ての写真を撮りつつ、さらに支援した学生6人については動画記録も撮った。 この6人の作品は、おいおい来週あたりに「SUACインスタレーション(5)」のページに追記することになる。 長い長い1日だったが、充実感とともに無事に終わって、これで前期は終了である。
2021年7月31日(土)
2021年8月1日(日)
もう8月である。 金曜日に 基礎演習Eの最終合評 があってヘロヘロに疲れたものの、昨日の土曜日の眼科通院ではソフトコンタクトレンズの保護が効いて角膜上皮はほぼ復活していてホッとした。 そして7月最後のJoyJoyヒトカラ6時間64曲を完走したが、久しぶりの曲でテンションが上がって突っ走り過ぎたために、久しぶりに「響声破笛丸料」のお世話になった(^_^;)。 8月と9月はこれまでの「7日に一度」でなく、「5日に一度」にペースアップする予定である。 以下が先月の記録であるが、COVID-19のために2020年から続いている過去のヒトカラ戦果の置き場所は、 この日記のPart9 のいちばん最後、「2021年6月27日(日)」のところに書いてある。この日記では金曜日の最後に追記したものの、実際には翌日の土曜日に 基礎演習Eの最終合評 のページをまとめてWebに上げたが、それだけでは完了しない。 そこで今日は、この前期に研究室ページに上げていた情報(メイキング記録)とをまとめて、何時間かかけて、ようやく SUACインスタレーション(5) のページに、僕が制作を支援したりした、この前期の10作品の記録を追記するという作業が完了した。 データを整理していて、この前期に5回生として「総合演習II」と「卒業制作」のダブルをやり遂げた、ゼミの杉山さんの膨大な仕事と頑張りにあらためて感服した。 明日からは、成績を付けたり、あとは「サウンドデザイン」と「音楽情報科学」の学生課題Max8パッチの改訂・整理などの作業が待っている。 講義は終わったものの、まだまだお仕事は続くのだ。
- 2021年7月3日(土) 6時間 65曲
- 2021年7月10日(土) 6時間 64曲
- 2021年7月17日(土) 6時間 69曲
- 2021年7月24日(土) 6時間 82曲
- 2021年7月31日(土) 6時間 64曲
2021年8月2日(月)
朝イチで届いていたメイルはICMAからのもので、「ICMC 2022 will be hosted by the University of Limerick in Limerick, Ireland, 3-9 July 2022」とのことだった。 アイルランドはなかなか行けないが、NIMEの第1回が開催されるなど、Computer Music関係の専門家が注目している場所なのである。 2022年になれば渡航も解禁になることを祈って、そろそろ新しい楽器でも作ろうか・・・という気に一瞬なったのだが、これが続くかどうかは不明だ。
ちょうど1年前、 この日記のPart6の8月4日 のところに、リモートで進めた「サウンドデザイン」と「音楽情報科学」の学生最終課題Max8作品をまとめていた。 せっかくなので、バグ修正やパッチの整理などを加えつつ、今年もまずは「サウンドデザイン」について、これをやっていこうというのが今日のお仕事である。 なお、zipに入っている2つのパッチのうち「*****_org.maxpat」というのが学生提出のオリジナル、「*****_rev.maxpat」というのが僕の改訂したものである。
上は 渡邊くん の作品であり、世界地図のマップを参照して、ランダムに選ばれた地点が陸地であればランダム色の点が打たれることで、次第に世界地図が生成されていくというものである。マップを参照するテクニックは過去に1例あっただけだが、久しぶりの登場となった。
上は 中村さん の作品であり、いい感じのBGMと共に、いい感じのモンスターから飛んでくる炎を打ち返すというゲームに仕上がった。 中村さんは3回生になって特訓補習を受けつつ「サウンドデザイン」と「音楽情報科学」の両方を一気に片付けてくれた。
上は 五十川くん の作品であるが、今年は先輩の伝説的名作「しいたけ」を改訂(グラフィックを差し替え)した作品が多いものの、元パッチにも若干のバグがある上に判定チェック座標などの不備も目立った。 このパッチについてはバグの修正を諦めてオリジナルだけである。(^_^;)
上は 大野さん の作品であり、「lcd」にお絵描きしたものを静止画として保存するというタイプのものである。 モードの切り替えにちゃんとサウンド(SE)を用意している。
上は 大庭さん の作品であるが、ファイルが読み込めないエラーが多数あり、参考にした去年の作品の画像差し替え版としても成功していない。 残念ながら未完成であり、このパッチについてもバグの修正を諦めてオリジナルだけである。(^_^;)
上は 河野さん の作品であり、これも名作「しいたけ」を改訂(グラフィックを差し替え)した作品であるが、サウンドファイル読み込みエラーや座標判定の不備も目立った。 このパッチについてもバグの修正を諦めてオリジナルだけである。(^_^;)
上は 佐々木くん の作品であり、笑いに徹した秀逸(臭逸)なゲームである。 佐々木くんは「基礎演習E」では、まだサウンドデザインでやっていないjitterを活用した作品でこちらも笑いを取っていて、「ネタ系の帝王」となる可能性を感じさせる。
上は 杉山さん の作品であるが、あちこち残念ながら未完成であり、このパッチについてもバグの修正を諦めてオリジナルだけとした。(^_^;)
上は チェくん の作品であるが、これもあちこち残念ながら未完成?であり、このパッチについてもバグの修正を諦めてオリジナルだけとした。(^_^;)
上は 中江さん の作品である。 去年の富田さん作品の素材差し替え版であるが、背景音楽もキャラも結果画面もきちんと作り上げていて、ここまで頑張って作ればオリジナルと言える。
上は 秦さん の作品であるが、メインパッチが初期化だけで閑散としている。 実はスクリーン画面の方にキーボードがあるので、そこで音階の検出その他を仕込んでいるのであり、これも立派に世界観が完成された作品となった。
上は 浜野さん の作品であるが、先輩(井さん)のパッチの素材だけを差し替えたとしても、パッチ名の学籍番号まで先輩のままで変えていない・・・というのはちょっと興醒めである。 これではさすがに後輩に紹介できない。(^_^;)
上は 肥田さん の作品であり、これも名作「しいたけ」のオマージュである。 ただしこの学生は動作の様子がおかしい・・・と質問のメイルをくれて、僕が原因究明とバグ修正をしたので、きちんとした作品として完成した。 さらにサウンドがかなり切なくてこれも良く、立派にリメイク作品として充実していると思う。
上は 藤崎さん の作品であり、丼の上の3種類の「具」を選んで、最終的に静止画として書き出すというタイプのものであるが、グラフィックが得意なところを十分に発揮して、いい感じに仕上がっている。 ここまで作り込めば、堂々とオリジナル作品と言える。
上は 松下さん の作品であり、定番の「流れてくるものをスペースキーでシューティング」というタイプである。 しかし「絵心」に優れていて、さらに伸ばした「腕」が切れているのが何ともシュールで気に入った。
上は 吉田さん の作品であり、軽音でドラムを担当しているために、ドラムのリズム感のゲームを目指した。 ただし実際のところ、リズムのループの「頭」がよくわからないことでちょっと混乱している感じがあった。 とりあえずオリジナルからはあまり変えず、ループの頭にCrash Symbalを置いたものの、ちょっと不完全燃焼という感じもある。 まぁ吉田さんは「基礎演習E」の方で超絶に頑張ったので、まぁこちらはこんなもので十分ということにしようか。
2021年8月3日(火)
叡王戦第2局を裏で眺めつつ、この日は「音楽情報科学」の学生課題作品の整理を進めた。 「サウンドデザイン」では、Maxパッチとスクリーンショットだけだったが、8-9月にある学会発表シリーズ(あと5回)の中で紹介することも考えて、さらにスクリーン動画を撮ってYouTubeに上げるのもセットで進めることにした。
上はこの日記の「2021年7月13日(火)」のところにも既に上がっていた、 中村さん の「蛇のフリッカー回転」の錯視である。 元々は、カラフルな絵とグレーの絵の2枚の静止画を交互に繰り返すだけのアニメGIF画像だったのだが、このパッチではjitterでリアルタイム生成しているので、カラフル部分の2色を自在に作れて、さらに2層の輪と中央の円の黒いエリアの大きさ/太さも変更できる。 そしてグレー版と交互に切り替える時間を変化可能にして、さらにピシッと切り替わるモードとディゾルブでじわっと変化するモードも完備した。 そのいずれであっても、カラー版からグレー版に切り替わる瞬間にこの円が「回転しているように見える」という錯覚はかなり強固であり、インタラクティブに試すことでその面白さは倍増どころか10倍増以上になっていると思う。
上は 松本さん の「停止・粘着錯視」である。 これは松本さんの制作過程からかなり難航していたパッチであり、メイルでもらった試作を改訂して返送して・・・というのも繰り返したが、今回の最終作品を見ると、だいぶまだ無駄が残っていたので、3時間ほどかけて大規模な改訂をしてみた。 その結果、ちょっと自分としても想定外の感覚を誘起されるパラメータもあったりして、これまたなかなか「濃い」インタラクティブな錯視体験パッチとなった。 同時にサウンドも鳴らしていて、マルチモーダル錯覚という要素もある、なかなかの収穫なのだ。
上は 橋本さん の「存在しない正方形のジャンプ」である。 これは正確に言えば、4つずつの円をjitterで描画した後で、バックグラウンドと同じカラーの正方形を描画しているので、実は「存在しているが見えない筈」というのが正しいのだが(^_^;)、基礎心理学的には、4つの円からちょうど正方形の4頂点に相当する部分が切り取られているのにその正方形を知覚する・・・という錯覚のインタラクティブ版となっているのだ。 これは「uzi」のサンプルとして僕が作ったものがほぼそのまま最終課題作品となったが、まぁ、それもアリである。
上は 橋本さん のPAW-doubleセンサを活用した作品である。 今年の「音楽情報科学」は、インタラクティブ錯覚パッチと、PAW-doubleを使ったパッチの2本を推奨したが、皆んななかなかPAWにまで手が回らなかった中、橋本さんはちゃんと制作したのは流石だ。 もっとも松本さんのように、PAWセンサを返却せずに、夏休み中の自主制作としてチャレンジしたい、という学生もいるのだから心強い。 ・・・ということで、残り2人については明日に引き継ぎつつ、幸せなMax8プログラミングとともに1日が過ぎ去っていった。
2021年8月4日(水)
昨日は「音楽情報科学」の最終課題作品を3人まで見たところだったが、その途中で業者が納品してきたのは、EmotiBitに使われている、上の Adafruit Feather M0 WiFi を、試しに海外から入手ということで発注していたものだった。 WiFiモジュールが搭載されているこの「高性能Arduino」? が、EmotiBitの機能の大きな部分を占めているので、音情研・夏シンポで発表するネタでもあり、ついでに調べてみることにしたのである。 関連(Overview)サイトとしては このページ から眺めていくことになりそうだ。
そして午前から午後にまたがって、昨日の続き、「音楽情報科学」の最終課題作品の残り2人(それぞれ錯覚とPAWがあるので計4作品)のチェック作業に入った。 上は 清水さん の「オクターブイリュージョン」であり、だいぶ全面的に改訂整理してみた。 本来、左右チャンネルにオクターブ違いの純音を交互に聞かせるという錯聴であるが、それと同時にスクリーンに交互に移動する音符の画像、あるいは無限ループする3次元リサジュー図形を表示することで、マルチモーダルな効果を狙ってみた作品である。
上は 清水さん のPAW-double活用作品「デブハムズ」である。 こちらもサウンドねたであり、PAWセンサの出力を加算して、ドミソの3和音が純正律に近づいたり遠ざかったりする・・・という微妙な世界を、ドミソの3匹のハムスターの変化で表現するというのは面白いアイデアだと思う。
上は 田中さん の「クレイク・オブライエン・コーンスイート」錯視である。 以前に僕が作ったものから無駄なモードをばっさりカットして、さらにマスクをかけて「明暗が違うように見えるが実は一致している」というのをクッキリと出すように改良されていて、素晴らしい作品に仕上がった。 これは8-9月のオンライン学会でもぜひデモって、居並ぶ先生がたをZOOM越しにザワつかせてみたい第一候補である。
上は 田中さん のPAW-double活用作品である。 他の学生はPAWセンサの4チャンネル出力をちょっと持て余し気味だったが、この作品ではいい感じにご飯の上の目玉焼きが移動して、中心付近のいい感じのところでOK画像とOKサウンドが鳴る・・・というゲームとしてきちんと完成させていた。
これでようやく今年の前期の「音楽情報科学」がほぼ終わった。 「ほぼ」というのは、PAWセンサを引き続き借用して、松本さんが夏休みの自主研究としてさらに挑戦しているからなのだ。 少数精鋭という言葉通りに、それぞれの作品は頑張った跡がしっかり残っていて、今後の後輩に伝えるいい作品群となってくれた。 午後には某会議が待っているが、なんとかその前に片付けることが出来た。
そして4限の某会議の後は、 Adafruit Feather M0 WiFi をちょっと触ってみようと気になり、 このページ から このページ に進んで、上のようにArduino IDEにボードライブラリを入れたりしてみた。 とりあえず、なんとか「Blink」を走らせたいものだが、何度もIDEがクラッシュして(^_^;)、ちょっとなかなか進まない。
それでも、 このページ に従って地道にライブラリなどを入れて試してみたところ、最新のMacOSXでない10.11.6の環境でも、無事にArduino1.8.13で、「Adafruit Feather M0」のLEDをBlinkさせることが出来た。 これは最初の一歩として、まずまずの進展である(^_^)。 ちなみに明日は5日インターバルとなった初日ということで、有休で出てきて午後にはJoyJoyヒトカラのために帰宅という予定が待っている。
2021年8月6日(金)
昨日のJoyJoyヒトカラでは6時間で71曲を完走したが、明後日からは静岡県も「まん防」(まん延防止等重点措置)となる。 去年の全国一斉緊急事態宣言では「休業(;_;)」だったが、果たして静岡県のJoyJoyは今度はどうなるか、ちょっと注目(心配)である。 朝イチで届いていたのは、アルスエレクトロニカからの こんな案内 だったが、あの美しい街 : リンツ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ に再び行けるのはいつになるのだろう。
そして昨日から溜まっていたニュースをチェックしていると、上のような「球体歯車」という凄いネタに到達した。 思わずゼミの古谷さんにメイルで知らせたが、これは3Dプリンタで作らないといけないし、駆動系がとんでもなく大変なので、ちょっとトライするのは無謀な世界のようだ。 その後、再び Adafruit Feather M0 WiFi のページに行ってみて、そこから知らなかったこの会社について、 これ とか これ とか これ とか これ とかのページで、創始者のLimor“Ladyada”Fried(MIT)の素晴らしさと、オープンソース文化のど真ん中にいる企業のスタイルに感銘を受けた。 これでは、旧態依然とした日本の電子関係の企業が潰れていくのも当然なのだった。 ただし、おそらく電波関係の法令が問題で、秋月電子でもスイッチサイエンスでも、 Adafruit Feather M0 WiFi についてはまったく取り扱いの情報が無かった。 こうなると、せっかくの音情研での発表については、EmotiBitについてだけでなく、その裏方として活躍している、この「Adafruit Feather M0 WiFi - ATSAMD21 + ATWINC1500」というボードについても調べて報告していこう。
2021年8月7日(土)
朝イチで眼科通院したが、ソフトコンタクトレンズの保護が効いてか、これまで1年半以上にわたって0.4未満が続いていた左目の視力が0.6と測定された。 遅々とした微々たる進歩であるものの、「良い方向に向かったベクトル」というのはテンションも押し上げる。 今日は以下のLimor“Ladyada”Friedの凛々しい写真をスタートとして、 Adafruit Feather M0 WiFi のページをスタートとして眺めて、さらに詳しい解説があるという このページ をじっくりと読み解いていこう。
まずは「概要」である。 ここで気に入ったのが「rock」という単語である。 第一段落と第二段落にそれぞれ登場するのだが、およそテクニカル(工学)のドキュメントに「rock」というのは異端であり、ここから既にLadyadaの気合いとノリを感じた。 なお、翻訳はいつものように「DeepL翻訳」丸投げコピペである。
Feather is the new development board from Adafruit, and like its namesake it is thin, light, and lets you fly! We designed Feather to be a new standard for portable microcontroller cores. This is the Adafruit Feather M0 WiFi w/ATWINC1500 - our take on an 'all-in-one' Arduino-compatible + high speed, reliable WiFi with built in USB and battery charging. Its an Adafruit Feather M0 with a WiFi module, ready to rock! We have other boards in the Feather family, check'em out here. Featherは、Adafruitの新しい開発ボードで、その名の通り、薄くて軽く、そしてあなたを飛ばせるものです。私たちは、ポータブルマイコン コアの新しい基準となるよう、Featherを設計しました。これはAdafruit Feather M0 WiFi w/ATWINC1500で、Arduinoと互換性があり、 高速で信頼性の高いWiFiを備え、USBとバッテリー充電を内蔵した「オールインワン」を実現しています。Adafruit Feather M0にWiFi モジュールを搭載したもので、即戦力となります。Featherファミリーの他のボードもありますので、こちらをご覧ください。 Connect your Feather to the Internet with this fine new FCC-certified WiFi module from Atmel. This 802.11bgn- capable WiFi module is the best new thing for networking your devices, with built-in low-power management capabilites, Soft-AP, SSL TSL 1.2 support and rock solid performance. We were running our adafruit.io MQTT demo for a full weekend straight with no hiccups (it would have run longer but we had to go to work, so we unplugged it). This module is very fast & easy to use in comparison to other WiFi modules we've used in the past. Atmelの新しいFCC認定WiFiモジュールを使って、Featherをインターネットに接続しましょう。この802.11bgn対応WiFiモジュールは、 内蔵の低電力管理機能、Soft-AP、SSL TSL 1.2のサポート、および堅実なパフォーマンスを備えた、デバイスのネットワーク化に最適な 新製品です。私たちはadafruit.ioのMQTTデモを週末連続で実行していましたが、何の問題もありませんでした(もっと長く実行できるはず でしたが、仕事に行かなければならなかったので、コンセントを抜きました)。このモジュールは、過去に使用した他のWiFiモジュールと比較して、 非常に高速で使いやすいです。
その「バッテリー充電を内蔵」というのが、上の写真である。 EmotiBitを発注した時に業者に一緒にリチウムポリマーバッテリを注文したところ「輸入できない」と断られたために、国内のアマゾンで入手できる、ほぼ同等のリチウムポリマーバッテリを2種類、購入していた。 これはなかなか凄いことで、コネクタをニッパーでカットして無理矢理に挿入しているものの(^_^;)、満タンでない場合には、USBから勝手に充電してくれて、黄色いLEDが点灯しているのがその証しであり、満タンになれば勝手に黄色LEDが消えてくれるのである。 これまで僕がArduinoその他でリチウムイオン電池を使ってこなかったのは、その充電回路がけっこう面倒だったからなのだが、このボードは「勝手に充電」・「勝手にUSBから給電」などとお任せで動作してくれるのが凄い。
そして注目すべきなのは、WiFi機能に関する以下の段落である。 これまで、ArduinoNano33IoTなどでWiFiをちらっと触ったものの、海外(デトロイトのSketching会場)では動いてくれたのに、日本に帰ってきたらうまく動かないまま棚上げになっていた・・・という苦い記憶を思い出した。 ところが、どうやら上の写真のように出荷段階でWiFi機能が書き込まれていて、買ってきた状態のボードを繋いでみると、Arduino IDEのシリアルモニタには、1106研究室の周辺で飛んでいるWiFiのリストが簡単に表示された。 これはデトロイトで苦労してArduinoNano33IoTに書き込んで実現した機能だったのだが、なんとこれが初期状態なのだった。 後で実際に確認してみるが、ちらっと先に眺めた範囲だと、このボードをスタンドアロンWebサーバとして走らせて、ホストのブラウザからのJavascriptか何かでボード上のポートの制御が出来てしまうようなのだ。 つまりはFirmataのWiFi版となってくれれば、これは色々に応用できそうである。(^_^)
この後には、「こんな凄いスペックですよ」という箇条書きが続くのだが、それを全てコピペしてDeepL翻訳(一部改編)・列記すると以下の感じとなる。This module works with 802.11b, g, or n networks & supports WEP, WPA and WPA2 encryption. You can connect to your own WiFi networks or create your own with "Soft AP" mode, where it becomes its own access point (we have an example of it creating a webserver that you can then control the Arduino's pins). You can clock it as fast as 12MHz for speedy, reliable packet streaming. And scanning/connecting to networks is very fast, just a second or two. このモジュールは、802.11b、g、またはnネットワークで動作し、WEP、WPA、WPA2の暗号化に対応しています。 お手持ちのWiFiネット ワークに接続したり、「ソフトAP」モードで独自のアクセスポイントを作成することができます(ウェブサーバーを作成してArduinoのピンを 制御する例もあります)。12MHzという高速クロックで、スピーディで信頼性の高いパケットストリーミングを実現できます。また、ネットワーク のスキャンや接続も1〜2秒と非常に高速です。CPUコア部分については省略するとして、重要なのはバッテリに関する以下の部分だろう。 すでに上の写真で紹介していたが(これを書いている途中で満タンになって黄色LEDが消えた)、この機能はこれまで多くのArduinoユーザが欲していたものなのだ。 そして、EmotiBitのシステムがこのマイコンを採用した理由の一つとして、この機能(電源周りのお手軽さ)が大きく役立っているのである。
- 高機能なCortex M0+プロセッサに、豊富なI/Oピン、多数の12ビットADC、10ビットDAC、SPI、I2C、UARTが可能な合計6個のSERCOM(3個は既存のインターフェースで使用されているため、残りは3個)、多数のタイマー、PWM、DMA、ネイティブUSBなどを搭載したCPUコア(→ データシート)
- ATWINCの電力使用量ははるかに少なく、WINCでは約12mA、ATSAMD21では約10mAとなっています。手動のパワーマネジメントでは、WiFiモジュールをスリープさせることで、約2mAに抑えることができます
- これは、ESPの平均消費電流が約70mAであることや、ディープスリープモードではWDTリセットが必要であることと比較しても、遜色ありません
- また、ATWINCの方がより確実に(バーストが少なく)ストリーミングできることがわかりましたが、全体的にはESPの方がスループットが高いです
- また、WiFiコアは別のチップなので、常に「ゆずる」必要もありません。プロセッサーとタイミングを自在に操ることができます
そして最後に、他の「Feather M0」と共通であるというスペックが列記されている。 これは重要なので、そのまま転記しておくことにしよう。 地味な凄さとしては、10ポートのA/D入力はArduinoのように10ビット精度ではなくて12ビット精度(0-4095)になっていること、そしてなんと1ポートだけであるが、PWMでなくて本当のD/Aのアナログ電圧(10ビット精度)まで完備しているところである。To make it easy to use for portable projects, we added a connector for any of our 3.7V Lithium polymer batteries and built in battery charging. You don't need to use a battery, it will run just fine straight from the micro USB connector. But, if you do have a battery, you can take it on the go, then plug in the USB to recharge. The Feather will automatically switch over to USB power when its available. We also tied the battery through a divider to an analog pin, so you can measure and monitor the battery voltage to detect when you need a recharge. ポータブルプロジェクトで使いやすいように、当社の3.7Vリチウムポリマー電池用のコネクターを追加し、バッテリー充電機能を内蔵しました。 バッテリーを使用する必要はなく、マイクロUSBコネクターから直接でも問題なく動作します。しかし、バッテリーをお持ちの場合は、外出先で USBに接続して充電することができます。フェザーは、USB電源が利用可能になると、自動的にUSB電源に切り替わります。また、バッテリーを 分圧器を介してアナログピンに接続しているので、バッテリーの電圧を測定・監視して、充電が必要なタイミングを検出することができます。そして「詳しい解説」という このページ の最初の「Overview」というのは、「rock」2連発を含む、ほとんど前のページの記述がそのまま改めて並んでいるだけだった。 あとはページ左端のメニューから、重要そうな部分を拾っていくことになる。 まずはもっとも重要な「Pinouts」である。
- Measures 2.1" x 0.9" x 0.3" (53.65mm x 23mm x 8mm) without headers soldered in. Note it is 0.1" longer than most Feathers
- Light as a (large?) feather - 6.1 grams
- ATSAMD21G18 @ 48MHz with 3.3V logic/power
- 256KB FLASH, 32KB SRAM, No EEPROM
- 3.3V regulator (AP2112K-3.3) with 600mA peak current output, WiFi can draw 300mA peak during xmit
- USB native support, comes with USB bootloader and serial port debugging
- You also get tons of pins - 20 GPIO pins
- Hardware Serial, hardware I2C, hardware SPI support
- 8 x PWM pins
- 10 x analog inputs
- 1 x analog output
- Built in 200mA lipoly charger with charging status indicator LED
- Pin #13 red LED for general purpose blinking
- Power/enable pin
- 4 mounting holes
- Reset button
最初のグループは「Power Pins」である。 あまり気にすることはないが、そのまま列記しておこう。
そしてもっとも重要な「Logic pins」である。 Raspberry Piなどと同様に、GPIOという名称になっているが、ここで太文字で3項目の注意点があるので列記しておくと、「All logic is 3.3V」・「Nearly all pins can do PWM output」・「All pins can be interrupt inputs」という、なかなか地味に凄いことがサラッと書いてある。
- GND - this is the common ground for all power and logic
- BAT - this is the positive voltage to/from the JST jack for the optional Lipoly battery
- USB - this is the positive voltage to/from the micro USB jack if connected
- EN - this is the 3.3V regulator's enable pin. It's pulled up, so connect to ground to disable the 3.3V regulator
- 3V - this is the output from the 3.3V regulator, it can supply 600mA peak
そして、ライブラリが別途に管理しているので「予約ピン」として指定されているのは、WiFiモジュールに関する「2,4,7,8」のピンであり、さらに関連してLEDとセットで「WiFi Module & LEDs」というカテゴリが続く。
- #0 / RX - GPIO #0, also receive (input) pin for Serial1 (hardware UART), also can be analog input
- #1 / TX - GPIO #1, also transmit (output) pin for Serial1, also can be analog input
- #20 / SDA - GPIO #20, also the I2C (Wire) data pin. There's no pull up on this pin by default so when using with I2C, you may need a 2.2K-10K pullup.
- #21 / SCL - GPIO #21, also the I2C (Wire) clock pin. There's no pull up on this pin by default so when using with I2C, you may need a 2.2K-10K pullup.
- #5 - GPIO #5
- #6 - GPIO #6
- #9 - GPIO #9, also analog input A7. This analog input is connected to a voltage divider for the lipoly battery so be aware that this pin naturally 'sits' at around 2VDC due to the resistor divider
- #10 - GPIO #10
- #11 - GPIO #11
- #12 - GPIO #12
- #13 - GPIO #13 and is connected to the red LED next to the USB jack
- A0 - This pin is analog input A0 but is also an analog output due to having a DAC (digital-to-analog converter). You can set the raw voltage to anything from 0 to 3.3V, unlike PWM outputs this is a true analog output
- A1 thru A5 - These are each analog input as well as digital I/O pins.
- SCK/MOSI/MISO (GPIO 24/23/22) - These are the hardware SPI pins, you can use them as everyday GPIO pins (but recommend keeping them free as they are best used for hardware SPI connections for high speed)
最後に残った3ピンが「Other Pins!」である。 わざわざ積極的に使うことはあまり無いものの、いずれも重要なピンである。
- #2 - used as the ENable pin for the WiFi module, by default pulled down low, set HIGH to enable WiFi
- #4 - used as the Reset pin for the WiFi module, controlled by the library
- #7 - used as the IRQ interrupt request pin for the WiFi module, controlled by the library
- #8 - used as the Chip Select pin for the WiFi module, used to select it for SPI data transfer
- MOSI / MISO /SCK - the SPI pins are also used for WiFi module communication
- Green LED - the top LED, in green, will light when the module has connected to an SSID
- Yellow LED - the bottom LED, in yellow, will blink during data transfer
これでPinoutsは終わり。 次の「Assembly」というのはピンヘッダの半田付けなどで何も目新しくないのでパスである。 その次の「Power Management」というのも通常のArduinoではあまり気にしないのだが、このマイコンではちょっと重要っぽいので追いかけてみることにした。 最初は「Battery + USB Power」である。 簡単に書いているが凄いことで、このマイコンにはUSBとリチウムバッテリの2つの端子があるが、その両方を適当に繋げばいいのだという。 まずUSBが繋がっていれば、オンボードレギュレータで+3.3Vの電源をとる。 さらにコネクタに3.7Vのリチウムポリマー電池が繋がっていると、もし満タンでなければ200mAで自動的に充電して、満タンになれば切断され、もしUSBコネクタが抜かれると自動でバッテリに切り替わる(HotSwap)のだという。 素晴らしいことである。 注意書きとして「充電LEDは、Lipolyの充電回路によって自動的に駆動されます。バッテリーを検出しようとするので、バッテリーが接続されていることを期待しています。バッテリーがない場合、電源を使用する際に時々点滅することがありますが、これは(存在しない)バッテリーを充電しようとしているためです。これは有害ではなく、全く正常なことです」と書かれているところを見ると、そういう誤動作っぽいこともあるようだ。(^_^;)
- RST - this is the Reset pin, tie to ground to manually reset the AVR, as well as launch the bootloader manually
- ARef - the analog reference pin. Normally the reference voltage is the same as the chip logic voltage (3.3V) but if you need an alternative analog reference, connect it to this pin and select the external AREF in your firmware. Can't go higher than 3.3V!
- Wake - connected to the Wake pin on the WiFi module, not used at this time but it's there if you want it
続く「Power supplies」のところを読むと、「BAT」端子には普通の+5Vの外部電源を繋ぐのもOK、とあるので、これまでのArduinoやPropellerやmbedやAKI-H8のように、単3電池を4本で低ドロップ3端子レギュレータとか、モバイルUSBバッテリとか、+5Vスイッチング電源を繋ぐのもアリのようだ。 「3V」ピンからは外部に最大600mAの3.3V電源を供給できるというが、+5Vから連続して出していると過熱して壊れるので、これはWiFiやXBeeなどの間歇利用を想定しているらしい。 そして最後の「Measuring Battery」も重要である。 リチウムポリマー電池は最大で4.2Vであり、大部分の帯域で3.7Vを出力する。 そして3.2Vあたりに低下すると保護回路によって切断されるので、以下のコードで済むように、「これを簡単にするために、BATピンに2重100Kの抵抗分圧器を取り付け、D9(別名アナログ#7 A7)に接続しました。このピンの電圧を読み、それを2倍することで、バッテリーの電圧を得ることができます」と、なんとも至れり尽くせりのシステムとなっていた(^_^)。We wanted to make the Feather easy to power both when connected to a computer as well as via battery. There's two ways to power a Feather. You can connect with a MicroUSB cable (just plug into the jack) and the Feather will regulate the 5V USB down to 3.3V. You can also connect a 4.2/3.7V Lithium Polymer (Lipo/Lipoly) or Lithium Ion (LiIon) battery to the JST jack. This will let the Feather run on a rechargable battery. When the USB power is powered, it will automatically switch over to USB for power, as well as start charging the battery (if attached) at 200mA. This happens 'hotswap' style so you can always keep the Lipoly connected as a 'backup' power that will only get used when USB power is lost.「ENable pin」については、「3.3Vレギュレータをオフにしたい場合は、EN(able)ピンを使用します。このピンをグランドに接続するだけで、3Vレギュレータが無効になります。BAT端子とUSB端子には電源が供給されます」とのことで、これもなかなかスマートである。 「Alternative Power Options」はほぼ常識的なことであり、「連続使用の場合には+5V1AのUSB電源アダプタを推奨」・「モバイルUSBバッテリも推奨」などがあった。 常識的な注意点としては、「アルカリ電池やニッケル水素電池を使用してバッテリーポートに接続しないでください - これはLiPoly充電器を破壊し、充電器を無効にする方法はありません」・「バッテリーポートに7.4Vのラジコン用電池を使用しないでください-基板が破損します」とあった。 また、3.3Vとか5Vの外部電源を繋ぐのは推奨しない・・・という記述があったが、たしかにパソコンのUSBポートに接続している状態でそのUSB(5V)端子に外部電源を繋ぐのはちょっと怖いが、ファームウェア書き込み済みとなってからの外部電源であれば問題ないだろう。#define VBATPIN A7 float measuredvbat = analogRead(VBATPIN); measuredvbat *= 2; // we divided by 2, so multiply back measuredvbat *= 3.3; // Multiply by 3.3V, our reference voltage measuredvbat /= 1024; // convert to voltage Serial.print("VBat: " ); Serial.println(measuredvbat);
その後には上のようなグラフとともに「Power Usage & Saving with WiFi」という記述があった。 「WiFi is a very power-hungry protocol. During transmit and SSID association, you'll see high power usages」とのことで、おそらくロギングで長時間計測の用途では重要になるが、当面ここはパスしておいてOKだろう。 さらにスリープモードの記述も続いたが、これも僕は使う予定がない(Myoでも苦労してスリープを停止させるコマンドを発掘することで楽器として成立させた)ので、パスである。 その次のページは「Arduino IDE Setup」であるが、これは水曜日に出来ていたのでパス。 その次が「Using with Arduino IDE」である。 これは単純なBlink以上の世界になるので、ようやくこのあたりから「Sketching」となるのだ。 ところが、すでに「Install SAMD Support」と「Install Adafruit SAMD」は既に済んでいて、「Install Drivers (Windows 7 & 8 Only)」は不要で、最後の「Blink」では「Successful Upload」に到達していたので、もし問題があれば・・・という「Compilation Issues」も無問題と判明した。 手元に購入したマイコンは新しいもののようなので「Manually bootloading」も不要、そして最後の「Ubuntu & Linux Issue Fix」も無関係ということで、このページもあっさり最後まで到達してしまった。
そして、続くページはいよいよ、 Using the WiFi Module である。 上の写真は、どうやらこのマイコンに小型のLCDモジュールのボードを搭載したもののようで、Arduino IDEのシリアルモニタの代わりにここに出力して表示するというものらしいが、ちょっと世間はお盆休みに入ってしまって、今からこれを業者に発注するのは無理っぽいので、単体+シリアルモニタで進めていくしかない。 だいぶ集中して進めてきたので、今日はここらにして、 このように バッテリに充電だけしておいて、続きは明日にでもやってみようか。
2021年8月8日(日)
オリンピックの最終日らしいが、既に1年以上も前にチケットをキャンセルした段階でどーでもよくなって過ぎ去っていく。 「東京オリンピック2020」は何故か2020でなく2021年に開催され、その最終日の男子マラソンは何故か東京でなく札幌で行われているようである。 選手が走っている大通公園や北大構内の風景を見て、過去に学会出張で札幌に行った FIT2003 や 日本音楽知覚認知学会 や 電子情報通信学会非線形問題研究会 や 電子情報通信学会ソサエティ大会 や 電子情報通信学会非線形問題研究会 や 日本音楽知覚認知学会 や EC2005 や リハ工学カンファレンス を思い出した。 札幌に行かずに函館に行ったのも 情報処理学会ヒューマンインターフェース研究会 や 日本音楽知覚認知学会 や 電子情報通信学会非線形問題研究会 と3度ほどあり、さらに新千歳空港は乗り継ぎだけの一人旅で 稚内・礼文・利尻 に行ったこともあった。 非線形と音知学会の北海道率が高いというべきか、北海道で開催されるからわざわざ参加する率が高いというべきか。(^_^;)
COVID-19のために前期が全てリモートとなったは去年はもちろんだったが、今年もオープンキャンパスが無い夏となった。 ただし今年は事務局が頑張って、昨日と今日は「静岡文化芸術大学 オープンキャンパスオンライン」というのをYouTubeでやっているらしい。 昨日は覗きに行ったら既に終わっていたが、今日は覗きに行ったらまだ始まっていなかった(^_^;)。 まぁ、これを眺めているほど暇ではないので、デュアルモニタのサブ画面の片隅に開いておくことにした。
そういえば、ずっと愛用しているジャパンネット銀行が、何故か「ペイペイ銀行」(^_^;)という薄っぺらい名前に変更されたのだが、そこでオンライン決済に使っていたトークン(1分ごとにワンタイムパスワード番号が変わる)が、これまでのキーホルダー型からカード型になる・・・というので交換に送ってきた。 別に形状がどう変わろうと関係ないのだが、カッコ良かった「Japan Net Bank」が、これで強制的に情けない「ペイペイ銀行」になったことで、ちょっと恥ずかしくて持ち歩けない(元々、持ち歩く必要はない)感じとなった。 キーホルダー型ではずっとLCDにワンタイムパスワード番号を表示していたが、カード型ではボタンを押した時に1分だけ数字を表示する(→消える)ことで、バッテリの持ちがさらに長くなったようである。
そして、静岡県の「まん防」の適用対象が政令市の浜松と静岡、さらに神奈川県と隣接して感染拡大している県東部の市町と決まったことを受けて、以下のように遂にJoyJoyのホームページに「浜松市」と名指しで「10時〜20時の時短営業、酒類の提供停止、酒類の持ち込み禁止」と告知が出てしまった。 まぁ、静岡県のJoyJoyは浜松市にしか無いのでこれは当然とも言えるが、名指し感はなかなかである。 去年の緊急事態宣言では営業休止だったので、それに比べればまだだいぶマシなものの、ちょっとだけ辛い日々が続くことが確定した。
サブ画面で開いていたYouTubeのライヴ中継「静岡文化芸術大学 オープンキャンパスオンライン」であるが、いざ実際に10時から「デザイン学部の紹介」というのが始まってみるとなかなか内容が充実していて(あまり見たこともない工房を初めて見たり)、和田先生とか知っている学生とかも出演していて、思わず1時間15分、全部、見入ってしまった(^_^)。 その後の「入試概要」などのパートもけっこう面白くて、今日はたまたまAbemaTVで面白い番組が無い(将棋チャンネルは藤井聡太の順位戦B級1組の録画、麻雀チャンネルは2017年の録画)こともあり、午前中はそのまま表示させておいた。 その午前中には昨日からのニュースをチェックしていたが、下の「オリンピック心霊写真」(^_^;)というのは、たまたまあまりに見事に身体が仰け反っているだけ・・・というのにウケたりした。
さて、ようやく午後になって Using the WiFi Module からの再開となった。 購入したばかりの新品でもシリアルモニタでWiFi接続できる状態になっているのは確認したが、既に「Blinkだけ」を書き込んだデバイスを使うことにした。 まずは「Install the Library」である。 とりあえずリンクに従ってGitHubの official Arduino WiFi101 library というところに行って、 WiFi101-master.zip というのをダウンロードした。 8月4日の最初の実験で作った「Adafruit」というディレクトリ内に「Blink」の「Adafruit_01」があったので、その隣に置いてみたが、この中身は以下のようなもので、なんだか豊富なexamplesで溢れている。(^_^)
そしてArduino IDEの「Library Manager」で、以下のように「wifi101」というタームの全てをinstallないしupdateした。 これが済んだらArduino IDEを再起動する・・・とあるが、ちゃんとクラッシュしてくれたので問答無用で再起動である(^_^;)。
そして「Check Connections & Version」に進む。 ここには真っ赤なアテンションとして、昨日チェックしていた「Note that to use the official Arduino WiFi101 Library, we must configure it to use the pins specific to the ATWINC1500 Feather. With each example sketch, you'll need to add WiFi.setPins(8,7,4,2); to the top of the setup function!」というのが明記されている。 相当に汎用性を拡張したArduinoであるものの、オンボードのWiFiモジュールについては「WiFi.setPins(8,7,4,2);」は厳然と固定なのだ。 そして、何度かArduino IDEがクラッシュしても負けずにリトライしてみると、以下のように「CheckWifi101FirmwareVersion」というスケッチの書き込み・実行に成功して、シリアルモニタから判明したのは「The firmware version on the shield do not match the version required by the library」という事だった。
こうなると、まずはWiFiモジュールに関する部分のファームウェアを最新のものに更新する必要がある。 どうせいずれ必要になるステップなので、ここでやっておかないといけない。 ということで、「簡単に出来るよ」という Updating Firmware のページに寄り道することになった。 そして以下のように、「No problem - you can update the firmware through your Arduino/compatible! Start by loading up the FirmwareUpdater sketch」ということで、まずこのスケッチをコンパイル・アップロードして、次に「WiFi101 Firmware Uploader」に行って、シリアルポートを選んで、「Test Connection」で確認して、ファームウェアの最新バージョンを選択して、「Update Firmware」を選ぶと転送に成功した。
そこで、再びメインでは何もしない「CheckWifi101FirmwareVersion」スケッチを書き込んでテストしてみると、無事に以下のように最新バージョンのテストに合格した(^_^)。 これで このページ の内容のおさらいが完了で、回り道から、途中だった本道の official Arduino WiFi101 library に戻ることができた。
次は「Scanning WiFi」である。 またまたexamplesの「WiFi101->ScanNetworks」を開き、またまた必ずのおまじないである「WiFi.setPins(8,7,4,2);」をsetup()の冒頭にコピペすることからスタートである。 そして「ScanNetworks」スケッチをコンパイルして実行させると、シリアルモニタには以下のようなWiFiスキャンの状態が10秒ごとに表示された。 買ってきた時のままの初期状態のボードには、これに似たスケッチが書き込まれていたようである。
ここまでは、ArduinoNano33IoTを使って、 Sketching2019 の会場(デトロイトのホテル)の内職でもやっていた事だったが、いよいよ「その先」である。 なんとタイトルは「Connect & Read Webpage」、このボードを1106研究室内のローカルWiFiルータ(MUSE2の時に購入していてヨカッタ)に接続して、Webクライアントとするというものである。 examplesから呼ぶのは「WiFi101->WiFiWebClient」であり、ここでも忘れずにまずは「WiFi.setPins(8,7,4,2);」をsetup()の冒頭にコピペである。 また、冒頭にWIFiルータの名称とWPAパスワードを登録することになった。 以下のように動作したものの、サーバが無かったので「空振り」(;_;)となった。
そしていよいよ「Creating an Access Point + Webserver」である。 「This demo will let you create a new WiFi AP with the Feather M0 which you can connect to from any WiFi capable device. It will also create a Server so you can connect and turn on/off the onboard LED」というように、このボードをWiFi接続できるデバイスとして走らせて、オンボードのLEDをWiFi経由でON/OFFさせるのだという。 examplesから呼ぶのは「WiFi101->AP_SimpleWebServer」であり、ここでも忘れずにまずは「WiFi.setPins(8,7,4,2);」をsetup()の冒頭にコピペである。 そして何度かArduino IDEがクラッシュしつつも以下のように走ったが、残念ながら、Safariで「192.168.1.1」をアクセスしても、以下のように上手くはいかなかった。
ここでシリアルモニタのメッセージとAdafruitのページを見比べてみると、createしている筈のアクセスポイントの名前が、既存のローカルWiFiルータになっている。 つまりここでは、おまじないの「WiFi.setPins(8,7,4,2);」をsetup()の冒頭にコピペするのは当然として、さきに設定していたアクセスポイントの情報ではなくて、自分で名前を定義する必要があったのだ。 そこで以下のように、適当な名前と適当なパスワードを設定してみると、無事にたくさん飛んでいるWiFiアクセスポイントの一覧に、「Adafruit_test」という名前が出現した。
そこで喜び勇んで再びSafariで「192.168.1.1」をアクセスしてみると、以下のように「駄目」と出た。 これは最近のブラウザはセキュリティの関係でhttps:だけを通してhttp:は駄目なのか・・・とFirefoxやVivaldiなどを次々に試してみたが、全て結果は同じようなものだった。
最後にMax8の「jweb」まで出してみたが、やはり以下のように駄目・・・と思えた。 しかしここで再度、ネットワーク一覧を眺めていて気付いたのは、新しいアクセスポイントとして「Adafruit_test」が登場したというのに、いま自分が接続しているのは、まだローカルのBuffaloだ・・・という事実だった。 そこで改めて、明示的に接続先を「Adafruit_test」にして、さらにローカルFirewallの「Radio Silence」でMax8をストップしていたのに気付いてこれを外してみると、以下のようにちゃんとMax8の「jweb」から画面が出てきて、クリックするたびにオンボードのLEDの点滅を確認できた。(^_^)
そして改めてブラウザで試してみると、FirefoxでもSafariでもVivaldiでも、ちゃんと「httpsじゃないから注意してね」と表示されつつも、全てWebブラウザ(クライアント)側からの指示でボード上のLEDを点滅できる、というところまで確認できた。 これは素晴らしい進展である。
パソコンどころかRaspberry Piでもないのに、なんとこのボード単体でこのように「アクセスポイント/簡易Webサーバ」まで実現できるとは、いい時代である。 これで official Arduino WiFi101 library のページはおしまいで、最後には「That's it! pretty easy, huh? There's other examples you can try such as server mode, UDP data transmission & SSL」とあった。 UDPということはOSCである。 こうなると、この部分をさらに調べていきたくなった。(^_^)
2021年8月9日(月)
昨日のオリンピック閉会式の途中で、ドローンにしては小さいので不自然な輝点の動きだなぁ・・・と思っていた演出は、やはり以下のように映像の合成であって、現場の会場は真っ暗のままだったというネタばれ情報が流れてきた。 もしあれが現実に出来たのであれば素晴らしいが、開会式のドローンだってインテル製品(のライブラリ)をそのまま使っていただけだったし、知恵も技術も乏しいまま厖大な中抜きで国民の税金を消滅させた連中の罪は限りなく大きい。
「年の功」というのは有難いもので、過去にやったもののあまり役立たなかったような経験が、後で別の局面で役立つ、つまりは何でも実験してみる事は大切なのだ、というのを朝イチから実感した。 昨日は予想以上に Adafruit Feather M0 WiFi の「WiFiアクセスポイント化」と「簡易Webサーバー化」が上手く進展したが、そうすると夜に寝ている間に頭の中が整理されてきて、半ば夢か現かという感じで実験のアイデアが浮かんできて起床した。 昨日はArduino IDEで「AP_SimpleWebServer」というスケッチを書き込んで、その後にIDEのシリアルモニタを開いて9600で接続してきたが、これは不要なのか? というのがまず第一の思いつきである。 そして、既にファームウェアが書き込まれていればIDEのシリアルモニタである必要はないので、普通のシリアルコンソール(ターミナル)でいいじゃん・・・というのが第二の思いつきである。 さらに、そうやって「簡易Webサーバー」が走っていたら、たくさんのクライアントから同時に接続しても反応してくれる筈で、これはもしかすると多人数ゲームのプラットフォームになるのでは? というのが第三の思いつきだった。
そこで思い出したのが、ちょうどたまたま、 この日記のPart9 の「2021年6月22日(火)」のところにチラッと書いていた、某X社と進めている受託研究で、色々と苦労したときの上のメモだった。 ArduinoやmbedやAKI-H8などのマイコンが外部シリアルに「Serial.println("Hello, World !");」などと吐き出すメッセージをモニタするには、何もいちいちArduino IDEのシリアルモニタを起動するまでもなく、OSに標準のターミナルから、上の例であれば「screen」とか「cu」とかで、「受信して表示」はもちろん、「直接テキスト入力を送信」までする事が出来る、というのを新しい技としてゲットしたところだった。 結局、某X社プロジェクトではこの手法でない方法で解決に至ったのだが、今回、まさにこれが使えると気付いたのだ。 そこでさっそくやってみて判明したのは、このスケッチを書き込んだ「Adafruit Feather M0 WiFi」を電源に繋いで立ち上げただけでは駄目(第一の思いつきは→NG)、という事実だった。 つまり、シリアルコンソールに接続してステータスを吐き出すと、やっと「WiFiアクセスポイント化」がスタートして、パソコンで「飛んでいるWiFi」を調べるリストに登場すると確認できた。ターミナルでの繋ぎ方 =================== $ ls -l /dev/tty.* crw-rw-rw- 1 root wheel 18, 0 6 16 07:33 /dev/tty.Bluetooth-Incoming-Port crw-rw-rw- 1 root wheel 18, 2 6 16 07:33 /dev/tty.Muse-30CB-RN-iAP crw-rw-rw- 1 root wheel 18, 6 6 16 16:57 /dev/tty.usbmodem146241 $ screen /dev/tty.usbmodem146241 115200 これで入れるが打った情報は表示されず結果が返ってくる 終了の方法 ctrl + A K killするか聞いてくる[y/n]のでy で終了 =================== $ ls -l /dev/tty.* crw-rw-rw- 1 root wheel 18, 0 6 16 07:33 /dev/tty.Bluetooth-Incoming-Port crw-rw-rw- 1 root wheel 18, 2 6 16 07:33 /dev/tty.Muse-30CB-RN-iAP crw-rw-rw- 1 root wheel 18, 22 6 17 08:39 /dev/tty.usbmodem146441 $ sudo cu -l /dev/tty.usbmodem146441 Connected. ok[stop] sudo ~. Disconnected. ===================
この第二の思いつきがOKと分かれば、あとは第三の実験である。 その結果、上のように、いったん起動したサーバはいくつものクライアントからの情報をイベントドリブンで、つまり接続されているどこから届く情報にも全て対応することを確認できた。 調子に乗ってMax8でも「jweb」のブラウザを2つ起動して、それとFirefoxの4つのブラウザ、計6クライアントからの接続にもサクサクと対応するというのは、朝からなんだか嬉しくなるようなスタートとなった。
さらに行った実験は、上のようなものである。 一見すると何でもないようだが、実はこれはかなりチャレンジングな実験なのだ。 9月の音楽情報科学研究会での発表をZOOMで行う際に、せっかくのEmotiBit(世界に提供されるのは来年2月以降なので、このベータ版が現在動いているところは是非とも今回、ライヴで見せたい!!)をZOOMでデモれるのか、たぶん無理では・・・と思っていた。 というのも、EmotiBitのWiFiが1106研究室に飛ばしている2つのフリーWiFiと繋がれるには、別途にMACアドレスをSUAC情報室に登録しないとDHCP接続されないからである。 それでローカルWiFiルータを走らせているのだが、これに繋いでいては今度はネットの彼方の学会ZOOMに出ていけないと思われた。 しかしちょうど「Adafruit Feather M0 WiFi」で遊んだことで、このあたりがスッキリ整理されて、上のように、実際に「お仕事Mac mini」でEmotiBitを走らせて、そのデータを横画面ではMax8がライヴで受けているのだが、そのスクリーン全体をネットワーク経由でZOOM接続した別のMacBookAirから出すことに成功してしまった。
およそ上記のような手順でいけば、ちゃんと音楽情報科学研究会でのZOOMデモが出来る・・・という準備もこれで完了してしまった。 次のステップとしてGitHubにあった19個のexamplesに行くことも考えたが、まずはこの「AP_SimpleWebServer」のスケッチをコピーした「AP_SimpleWebServer2」を作って、少しずつ改編しつつ全体を眺めてみた。 そして以下のように、まず確認事項として「シリアルモニタ(接続すると動作を開始する)との接続は115200bpsでもOK」というのをまず確認し、次に「local IP addressはdefaultでは192.168.1.1である」ものの、例えば「WiFi.config(IPAddress(10, 0, 0, 1));」と入れることで10.0.0.1というように自在に設定できることを確認できた。
- 1106のローカルWiFiルータ(Buffalo-G-59A9)を稼働させる
- お仕事Mac miniはdefaultでLAN。defaultでWiFiはOFF。この状態でまずZOOMに繋ぐ
- お仕事Mac miniのZOOMとの接続確立を確認する
- EmotiBitを装着してリセット起動する。SDカードの設定により自動でBuffalo-G-59A9と接続される
- お仕事Mac miniのWiFiをONにして、Buffalo-G-59A9を探して繋ぐ
- 「EmotiBitOscilloscope」を起動する。EmotiBitを探して自動で接続してグラフが動くはず
- この状態で、「ZOOMにネット(LAN)接続」しつつ同時に「EmotiBitと通信」している
- 「Radio Silence」のFirewallでMax8をブロックしている事を確認する(※ 念のため)
- Max8を起動して「EmotiBit_OSC_3」などのパッチを走らせる
- 「EmotiBitOscilloscope」のメニューで「OSC」をONにするとMax8のパッチのグラフも動くようになる
- これで「ZOOMでEmotiBit+EmotiBitOscilloscope+Max8」のデモが可能(^o^)
- 終了時は「EmotiBitOscilloscope」のメニューでEmotiBitをパワーダウンさせる
- Max8、EmotiBitOscilloscopeを終了。お仕事Mac miniのWiFiをOFFにする
- ローカルWiFiルータ(Buffalo-G-59A9)を落とす
さらに、25年以上も昔にやっていた遠い遠い知識として、Webサーバが表示する書式が以下のようなものだった・・・というのを、なんとここではArduinoスケッチのソースコード中に再発見した。 当時のWeb技術というのは「Blink」以外に動的な要素が無く(アニメGIF形式が生まれる数年前)、リンク以外のインタラクティブな要素としては、サーバ側の裏でプログラムを走らせてそこにバトンタッチする「CGI」という技術だけが存在していた。 そのCGIが生成する文字列というのが、ここでのHTTPメッセージであり、30年たった今でも、全てのブラウザはこの文字列を受け取ると同じようなWeb画面を表示するのである。 これはとっっても懐かしく、フトここで新しいアイデアを思いついた。
そこでまず、 ピン配置 のページに行って、とりあえず汎用のポートとして「#10」・「#11」・「#12」の3ピンを選んだ。 ついでに、このマイコンの全体ドキュメントとして ドキュメントPDF も発見し、その中にあった以下の回路図も確認した。 これがあると、ようやくオープンソースとして安心できる。(^_^)
そのアイデアというのは、このボードの汎用ポートにさらに3つのLEDを追加して、13ピンの赤LEDと合わせて4個のLEDを個別にON/OFFできるようなサーバを走らせてみよう・・・というものである。 そこでまず、 このように ハンダごてを出してピンソケットを取り付け、3個のLEDをハンダ付けした。 そして「AP_SimpleWebServer3」としたスケッチでこの改編を盛り込んで、以下のようにあっさりと希望する動作を実現できてしまった。(^_^)
邪魔の入らない休日とはいえ、なかなか今日は順調に進展してくれた。 裏ではずっと、AbemaTVの叡王戦第3局の「藤井vs豊島」を見ていたのだが、「天敵・豊島」というのは過去の話となったか、豊島竜王叡王が全くいいところ無く藤井二冠に投了したのを確認して帰宅することになった。 明日は有休をとってあるのでJoyJoyであるが、今月末までは「6時間の素面」という珍しい(残念な)形態となるのだが、行けるに越した事はない。
2021年8月10日(火)
前回のJoyJoyヒトカラから5日たったので今日も午後には出かけるという有休の朝である。 昨日、豊島二冠に圧勝して叡王戦2勝1敗となった藤井二冠の今月のスケジュールは、なんと以下のようにびっしりであるという。 ちなみに来週以降も「8月18〜19日 藤井vs豊島 王位戦第4局 佐賀県嬉野市」・「8月22日 藤井vs豊島 叡王戦第4局 愛知県名古屋市」・「8月24〜25日 藤井vs豊島 王位戦第5局 徳島県徳島市」と藤井vs豊島が続き、さらに藤井が竜王戦挑戦者決定戦に勝てば、今度は豊島が防衛戦としてさらに藤井と7番勝負をする予定が加わる。 緊急事態宣言「県境を越える移動の自粛依頼」なんて、そんなの関係ねえ。 僕も「乗り鉄」の旅好きなのだが、藤井二冠も乗り鉄だというので、この移動につぐ移動は、側で見ているほど苦痛ではないのかもしれない。
僕の出張の乗り鉄での思い出としては、国内であれば流氷船「おーろら」に乗るためにわざわざ網走(女満別)に飛んで自費で1泊してから学会の札幌まで特急「オホーツク」に約6時間乗った 冬の北海道2011 が一番である。 海外であれば、 欧州ツアー2012 ではウイーンからスロベニアのリュブリャナまでの6時間、 欧州ツアー2013 では、ウイーン→ブダペスト、ブダペスト→プラハ(7時間)、プラハ→リンツ(鉄道の無い区間を含めて数時間)、というのが懐かしく、さらに サバティカル2016 では、エカテリンブルクからモスクワまで、わざわざ「シベリア横断鉄道」の寝台車に乗って移動したのが思い出される。 しかしもう1年半の間(さらにまだまだ続きそう)、COVID-19のために、これら「乗り鉄」の「続き」は全て止まったままなのだ。(;_;)
そして今日は新しい実験とかは進めない、と決めてネットニュース関係を眺めていると、どこからのリンクで行き着いたのかは不明だが、上のような面白いYouTubeのシリーズを発見してしまった。 なかなかに玉石混交で個々にはかなりばらつきがあるが、出来るか出来ないかは別として、この中には学生の制作テーマに関係しそうなネタもありそうなので、おいおいゼミの皆んなに出す連絡メイルでは、この情報を知らせておくことにしよう。2021年8月11日(水)
昨日は無事に「JoyJoy素面ヒトカラ6時間67曲」を完走できた。 飲まずに歌うと声域も上がり声帯が持ち堪えるという当然の事実も、実感をもって確認できた。 その翌朝、以下のようなメイルがEmotiBitから届いていた。
電子機器製造業界は大変な状況にありますが、私たちは正気を保っています。 昨年の大規模なシリコンウェハー工場の火災と、それに伴うチップ不足のため、エレクトロニクス業界は完全に狂ってしまった。通常3ドル程度のセンサーが 1個70ドル以上の見積もりを取ったこともあります(笑)。通常はDigikeyで在庫している部品が、52〜104週のリードで見積もられています(つまり1〜2年 です!)。価格は日々大きく変動するため、製造見積もりは72時間で期限切れとなり、複数のメーカーと見積もりや価格交渉を行う通常のプロセスは、目隠し をしての曲芸のようなものになってしまいます。 しかし、私たちはそれを成し遂げています。創造的なエンジニアリングと部品調達、そして多くのエネルギーを必要としていますが、私たちは必要なすべての 部品の注文を確保し、メーカーと契約を結び、2022年2月にEmotiBitsを出荷する予定です。
昨今の半導体の逼迫を逃れて、KickStarterでEmotiBitに出資した人たちは、予定通りに2022年2-3月にこれをゲットできるし、これから小ロットのベータ版を注文できる可能性も今年の9-10月あたりだというが、僕の手元には既に稼働している現物があるのだ。 これは、初期ロット(手作業)のベータセットを購入した者だけの特権なのだと実感できた。私たちの次のステップは、製造工場で小ロット(DVT)のEmotiBitsを実行することです。これにより、製造とテストのプロセスが検証され、これまでにない 最高のEmotiBitsを確実に出荷することができます。 これらはベータ版として提供されます(2021年9月〜10月に出荷予定)。早急にEmotiBitを手に入れたい方は、Eメールアップデートにご期待ください。そして、朝フト思いついていたアイデアを実験してみると、想定通りに動作することを確認できた。 このZIP がそれであるが、何度も何度もArduino IDEがクラッシュして困った(^_^;)ものの、少しずつ保存して最後まで到達した。 この実験は、「シリアル出力のモニタ無しでも[AP+簡易Webサーバ]が走る」のではないか・・・という「読み」の確認である。 面倒なのでスクリーンショットとかYouTube記録は省略するが、結論から言えば、このZIPに入っているArduinoスケッチをadafruit-feather-m0-wifi-atwinc1500に書き込むと、あとはIDEもシリアルモニタもコンソール等の外部シリアルターミナルも不要で、電源さえ入れれば「Adafruit_test」というWiFiアクセスポイントが出現する。 ここにMacのWiFiを接続すれば、そのMac内で、どんなブラウザでもMax8の「jweb」でもいいので、「http://10.0.0.1」とアクセスすると例の画面が出てきて、クリックすればオンボードのLEDを自在に点滅できる。 さらにクリックでなくても、実はそれは「http://10.0.0.1/A」・「http://10.0.0.1/B」・「http://10.0.0.1/C」・「http://10.0.0.1/D」・「http://10.0.0.1/E」・「http://10.0.0.1/F」・「http://10.0.0.1/G」・「http://10.0.0.1/H」というURLへのアクセスなので、これをMax8の「jweb」に与えてやれば、「Max8からWiFi接続したAdafruitのLED4個を自在に点滅」させる事が出来る、という、けっこう重要な確認となった。
そして、「AP+簡易Webサーバ」が出来たので、いよいよGitHubにあったexamplesの中から「WiFiWebServer」というのを選んでみた。 あらかじめArduinoスケッチを眺めてみると、ディジタル(LED)の点滅でなくて、アナログ6チャンネルのA/DデータをWebとして表示するらしいので、これはハンダ付けで配線するまでもなく、アナログ端子を手で触れば電位が変動してデータの変化は分かるのだ。 サンプルに対する注意点としては、(1)お約束のWiFi設定4ポートをsetup()の冒頭で定義すること、(2)今度は研究室内ローカルWiFiルータを指定すること、(3)そのためにIPアドレスの自己定義はしない(WiFiルータのローカルDHCPから割り当てられるまで不明)、というあたりである。 だんだん慣れてきたのか、上のように、なんと一度のトライでアッサリと成功してしまった(^_^)。 これはDHCPサーバから割り当てられるIPアドレスを外部コンソールで確認する必要があるので省略は出来ないために、この実験はここで完了となった。
さらに余勢をかって「WiFiUdpSendReceiveString」に取り掛かってみた。 あいかわらず、Radio Silence(ローカルFirewall)でMax8をブロックしないとブラウザのWebアクセスとかArduino IDEのライブラリ更新が出来なくなったり、Arduino IDEがたびたびクラッシュする(^_^;)という嵐の中、たまたま書き込み完了してIDEが落ちたところでターミナルからローカルWiFiルータ(DHCPモード)に繋いでみると、その後にRadio Silenceでブロックを外してMax8を立ち上げれば、上のようにMax8からのUDPメッセージを受け取ってコンソールに表示してくれた。 ここを深掘りしていけば、事実上はOSCのようなMax8との双方向コミュニケーションが可能になる・・・というのが、今日の最大の収穫となった。(^_^)
2021年8月12日(木)
朝イチでSketchingコミュニティに届いていたのは、「AI/ML - Senior Full Stack Software Developer, AI Education」というAppleの中の人からの求人情報だった。 「Appleで世界クラスのAI教育体験を作る仕事に参加しませんか? 情熱的な教育者や機械学習の専門家と協力して、人々がAIやMLについて学べるようなアプリケーションやサービスを作ることができます」というのは、さすがである。 元「Appleの中の人」といえば、慶応SFCの増井俊之さんぐらいしか知らないが、こういうところで活躍する人材が音楽情報科学研究会から出てきて欲しいものである。
EmotiBitから発展して Adafruit Feather M0 WiFi でいろいろ遊んでいるが、ぼちぼち音楽情報科学研究会の予稿の提出締め切りが来週に近付いてきているので、このあたりでとりあえず原稿をやっつける作業に入るタイミングである。 世間はCOVID-19の全国的拡大と秋雨前線の豪雨とお盆とで、邪魔も入らない週末に向かう格好のタイミングなのだ。 今回は「原稿ページ数:2〜8ページ以内」とのことなので、まぁどのように作ってもこの範囲に入りそうだ。 他のオンライン学会は図や写真を載せずに全てURLとしたが、今回はせっかく撮ったスクリーンショットがこの日記にあるので、普通のスタイルで行ってみようかな。
2021年8月13日(金)
SUACは「一斉休業日」という邪魔の入らない日である。 NIMEコミュニティからは こういう人 が こういう研究所 とのコラボレーションで こういうプロジェクト をするらしく、「アーティスティックなプロジェクトとして、私が記録した一連の歩行の動きがあり、それを音にマッピングする機械学習モデルをモバイルアプリ用に開発したいと考えています。現在、アプリのプログラマーと一緒に仕事をしていますが、機械学習の専門家に協力してもらいたいと思っています。この仕事に興味のある方は、詳細について私に連絡してください。これは有料のコラボレーションになります」というような「募集」が届いた。 やはり時代はDLのAIなのだなぁ。
ネットニュースから何かのYouTubeに行き、そこからさらにリンクに導かれて、たまたま上のような2つの動画に行き着き、1時間17分/2時間37分のmp3ファイルに変換して「今日のBGM」としてみた。 それを流しながら(高校時代の自分が蘇る(^_^;))、ゆっくりと自分のサイトの記録を手繰って原稿の「参考文献」の部分に並べる・・・という作業から、今回の原稿執筆の準備を始めた。 たいていは何かの予定に追われつつ片付ける原稿執筆なのだが、「COVID-19お盆」という何も予定の入らないぼんやりとした時間にこういう作業をするというのも、たまにはいいものだ。
2021年8月15日(日)
このところずっと日本列島の全体に秋雨前線が停滞して線状降水帯などがひどいようだが、今日は5日ぶりのJoyJoyヒトカラ6時間(ただし素面)なので、雨雲が残っていても出かける覚悟で、ややテンションが上がりつつ研究室に出てきた。
一昨日から執筆を開始して、昨日は終日没頭して、昨夜にプリントアウトを見て赤を入れて、今朝に 予稿の改訂版 を情報処理学会のサーバに送って、これにて音情研・夏シンポの準備も完了である。 この2021年度前期には去年を上回り、既に6月に終えた2件に加えて以下の5件という、まさにヤケクソのような計7件の学会発表ということになった。 例年であれば9月あたりに欧州に出張する学会は無いかな・・・と調べて新年が始まり、この時期にとてもこんなに国内の学会/研究会などに参加できない(FITとECとVSJはいずれも学会員発表者の参加費が1万円以上)のだが、まさに呪わしいCOVID-19のお陰である。
ただし、2020年度後期に作った このページ に倣って、今期も このページ を作って6月にはプレゼンをここに置いて発表してきたのだが、オンライン疲れというか、このリンクの無い黒いままの5件を作ろうというモチベーションはなかなか上がってこない。 もしかすると手抜きして、このままZOOM越しに「予稿PDFを見せて」・「若干のデモをライヴで見せて」というスタイルに退化するかもしれない(^_^;)。
- 電子情報通信学会ヒューマンコミュニケーション基礎(HCS)研究会 2021年8月21-22日(土日)
ウェルネス・エンタテインメントのためのインタラクティブな錯覚体験システムに向けて ★- FIT2021 2021年8月25日(水)-27日(金)
「Real Time Risset Rhythm Generator」から「Live Sampling Risset Rhythm」への道 ★- EC2021 2021年8月30(月)-9月1日(水)
「新楽器をデザインする」というエンタテインメント ★- 可視化情報シンポジウム(VSJ2021) 2021年9月9日(木)-11日(土)
ライヴComputer Musicにおける情報可視化についての考察 ★- 音楽情報科学研究会・夏のシンポジウム 2021年9月16-17日(木金)
新・生体センサシステム"EmotiBit"は新楽器として使えるか ★2021年8月16日(月)
昨日はまたまたJoyJoy素面ヒトカラ6時間66曲を全力で完走したが、当然ながら飲まないと翌朝の様子が全く違って新鮮である。 そんな朝、研究室に届いていたのは、いつもご一緒しているRAKASU PROJECT.さん(京都精華大の落先生)からの「Shing-kwei Tzeng先生ご逝去」という驚くべき訃報だった。 Shing-kwei Tzeng先生とは今年の3月にもメイルを行き来させていて、5年前に作曲した合唱曲の歌詞の日本語版を、2種類のどちらにしたらいいか・・・という相談を受けていたところだった。 かつて合唱曲を100曲以上、作曲していたという話をしていたために僕に相談が来たようだが、そこでアドバイスをして、翌月の4月には「このように出来た」という以下のような楽譜(一部)と歌詞(杜甫!!)も届いていたのだ。
台湾での訃報のWebページは これ であり、念のためにローカルに保存したものが これ (→文字エンコードをUnicodeにすること)である。 「電子音樂先驅曾興魁病逝 李永得震驚不捨」というこのページにDeepL翻訳で初めての「中国語→日本語」をしてみると(一部手作業で修正)、「 Wu Sanlian 受賞歴のある作曲家で、台湾における現代音楽のパイオニアである曾興魁氏が、10日夜、長い闘病生活の末、75歳で亡くなりました。 このニュースを受けて、文化大臣のリー・ウィングタック氏は深い衝撃と悲しみを受け、音楽業界からも驚きと悲しみの声が上がりました。 1981年にドイツから台湾に帰国した後は、国立台湾師範大学で教鞭をとり、中華民国現代音楽協会や中華民国コンピュータ音楽協会の設立に携わり、台湾における現代音楽の発展に貢献しました。 文化部長官の李詠鐸氏は、「曾興魁先生の作品は、スタイルや内容が多様で、豊かな創造力と台湾の音楽の発展に貢献しました。1946年に屏東で生まれた曾興魁氏の音楽的想像力は、屏東師範学校でオルガンを学び、合唱団に参加したことから始まりました。1968年には台湾師範大学の音楽学部をスポンサーとして留学し、卒業後はドイツのフライブルク音楽院で作曲を学びました。ここでは多くの新しいコンセプト、テクニック、音色が開発され、現代音楽への関心を呼び起こしました。帰国後は、国立台湾師範大学で教鞭をとる傍ら、作曲活動にも力を入れており、作品は台湾内外で広く発表されました。 彼は、伝統を核とし、現代音楽の作曲技法をゆとりとして、自分の音楽の緊張感を表現することが多い。客家人である曾興魁氏は、客家人の歌や電子音楽も多く作曲しており、創造性に富んでいます。曾興魁氏は音楽に対して非常に情熱的で、台湾現代音楽協会の発展にも熱心に取り組み、協会の権利のために戦ってきました」と述べました。 Poon Ka Lam氏は、曾興魁氏が音楽業界の若い世代のロールモデルであるとし、彼は一人になっても冒険をあきらめず、現代音楽のエコロジーの発展に貢献したと述べました 」となった。 Shing-kwei先生は何度も1106研究室に来てくれたし、2007年3月の国際会議MOCMATに招待された 台湾ツアー の際には、(二人きりなので写真は撮らなかったものの)先生のご自宅にも行っていた。 こうなると、きちんと資料を発掘して、お悔やみのページを残すのが今日のお仕事ということになった。
まずは研究室ページを探索して、上のように記録が残っていることを確認できた。 あとは、Shing-kwei先生が写っている写真を抜き出すという作業であり、一緒に写っている学生たちの懐かしい顔も思い出しながら、午前中かかって このような ページを完成させた。
合掌。2021年8月17日(火)
無思慮な五輪の賜物として全国的にCOVID-19がさらに拡大し、今日の浜松市の感染者は一気に118人となり、静岡県も20日から緊急事態宣言の対象になったため、その20日に既に予約していたJoyJoyに電話してキャンセルしつつ代わりに明日に予約して、20日に出していた有休を明日に変更して1日が始まった。 そしてAdafruitボードの続きである。 先週の水曜日に「WiFiUdpSendReceiveString」というのを実験していて、まずは同じローカルWiFiサーバに接続したMax8からOSC(udpsend)でAdafruitボード(IP:192.168.11.3)に送ったOSCメッセージが外部シリアルモニタで見える・・・というところまでだった。
そしてMax8側のパッチを上のように少しだけ変更して、さらにshellコマンドの「ifconfig」からMax8のIPアドレスがIP:192.168.11.2であると判明した。 こうなれば、先週の月曜日に3つ取り付けていたLEDを1ピンだけずらして「9」・「10」・「11」とすれば、これは基板に「~」記号の付いたPWMポートになるので、今日の目標を「Max8からOSCでAdafruitボードにPWMデータを送って点灯制御」(ちょうどFirmata+maxuinoのWiFi版)とした。
そして、上のようにあれこれ試行錯誤を繰り返したのだが、AdafruitボードからのUDPパケットを受けようとするMax8パッチの「udpreceive」に謎のエラーが出て解決しないまま、今日のところはさしたる進展もなく終了となった(^_^;)。 昨日も今日も、夕方にはちょっと早めに大学を出て、常備薬の処方のためにお医者さんに行く・・・という節目が重なったために、ちょっと中途半端で終わる日が続いているが、まぁ学会発表の方は少しずつプログラムが公開されて発表日時なども判明しているので、ぼちぼち進展というところだ。
2021年8月18日(水)
政権延命のための無能な愚策が続いて、上のように明後日からまた静岡県はCOVID-19緊急事態宣言下に入るという。 AbemaTVでは王位戦第4局が中継されていたので豪雨災害の佐賀県(嬉野温泉の旅館「和多屋別荘」)は大丈夫だったのか? と検索してみると、案の定「大阪市の関西将棋会館へ変更」とのことだった。 確かに対局室の風景(藤井王位の後ろの4枚の掛け軸)には見覚えがある。 パラリンピックも全て無観客となり、雨天中止順延が相次ぐ甲子園でも感染で辞退する高校が続き、日本列島は夏の停滞前線に覆われた暗鬱な日々である。
さて、午前中だけであるが昨日の続きである。 状況としては上のように、まず室内にローカルWiFiルータ(ローカルDHCP)の電波を飛ばして、Adafruitボードの「WiFiUdpSendReceiveString2」というスケッチでこれに接続していて、IPアドレスは「192.168.11.3」(ポートは自前で「5500」と宣言)である。 Max8を走らせるホストのお仕事Mac miniでは、LANではSUACネットに接続しているのと同時にWiFiもONにして、同じローカルWiFiルータにも接続する。 このMax8パッチのudpsendでAdafruitボードのIPとポートを指定してメッセージを送ってみると、コンソールでは接続確認が表示され、「From 192.168.11.2, port 56519」などとなって、つまりホストのIPアドレスは「192.168.11.2」なのだが、ここで表示される「port 56519」がどこで設定されているのか、が昨日から謎なのだった。 Max8でこのポート番号のudpreceiveを指定するとエラーになって失敗し、1だけずらして設定できたとしても、上のように「udpreceive: OSC Bad message name string: DataAfterAlignedString: Unreasonably long string Dropping entire message.」と叱られるのだ。
そこで上のようなArduinoスケッチをじっくり眺めつつ考えていったが、(1)「packetBuffer」と同様に「ReplyBuffer」についても「len」を求めて最後にnullを入れる・・・という対策はまったく効果が無かった。#include <SPI.h> #include <WiFi101.h> #include <WiFiUdp.h> int status = WL_IDLE_STATUS; #include "arduino_secrets.h" char ssid[] = SECRET_SSID; char pass[] = SECRET_PASS; int keyIndex = 0; unsigned int localPort = 5500; char packetBuffer[255]; char ReplyBuffer[] = "acknowledged"; WiFiUDP Udp; int led1 = 9, led2 = 10, led3 = 11; void setup() { WiFi.setPins(8,7,4,2); Serial.begin(115200); while (!Serial) { } if (WiFi.status() == WL_NO_SHIELD) { Serial.println("WiFi 101 Shield not present"); while (true); // don't continue: } while ( status != WL_CONNECTED) { Serial.print("Attempting to connect to SSID: "); Serial.println(ssid); status = WiFi.begin(ssid, pass); delay(10000); } Serial.println("Connected to WiFi"); printWiFiStatus(); Serial.println("\nStarting connection to server..."); Udp.begin(localPort); pinMode(led1, OUTPUT); pinMode(led2, OUTPUT); pinMode(led3, OUTPUT); } void loop() { int packetSize = Udp.parsePacket(); if (packetSize){ Serial.print("Received packet of size "); Serial.println(packetSize); Serial.print("From "); IPAddress remoteIp = Udp.remoteIP(); Serial.print(remoteIp); Serial.print(", port "); Serial.println(Udp.remotePort()); int len = Udp.read(packetBuffer, 255); if (len > 0) packetBuffer[len] = 0; Serial.print("Contents: "); Serial.println(packetBuffer); Udp.beginPacket(Udp.remoteIP(), Udp.remotePort()+1); Udp.write(ReplyBuffer); Udp.endPacket(); } } void printWiFiStatus() { Serial.print("SSID: "); Serial.println(WiFi.SSID()); IPAddress ip = WiFi.localIP(); Serial.print("IP Address: "); Serial.println(ip); long rssi = WiFi.RSSI(); Serial.print("signal strength (RSSI):"); Serial.print(rssi); Serial.println(" dBm"); }
(2) 次に「Udp.write(ReplyBuffer);」をコメントアウトして「Udp.write(48);」とすると、Max8のエラーメッセージが変わって「udpreceive: OSC packet size (1) not a multiple of 4 bytes: dropping」となった。 これは、少なくともAdafruitボードからは謎の「+1したポート」に対してOSCメッセージが帰ってきているという事なので、掘り下げる価値はある。 コンソールでMax8からのOSCを受けたところには「Received packet of size 12」とあり、これは4の倍数である。
そこで、(3)「Udp.write(48);」「Udp.write(49);」「Udp.write(50);」「Udp.write(51);」と4バイトになるようにしてみると、また元のように「udpreceive: OSC Bad message name string: DataAfterAlignedString: Unreasonably long string Dropping entire message.」と叱られた。
そして、最後がnullになれば・・・と (4)「Udp.write(48);」「Udp.write(49);」「Udp.write(50);」「Udp.write(0);」としてみると、今度はArduino IDEが「error: call of overloaded 'write(int)' is ambiguous」と返してきて(;_;)、その上流の「virtual size_t write(uint8_t);」・「size_t write(const char *str)」などと書かれていて、どうもゼロ指定は「size_t」を困らせるような感じだった。
現象は完全に法則性があり、(5)最初の「char ReplyBuffer[] = "acknowledged"」というのは12文字なので4の倍数だが、これを送ると元のように叱られ、1文字追加して「char ReplyBuffer[] = "acknowledged-";」としてみると「udpreceive: OSC packet size (13) not a multiple of 4 bytes: dropping」と叱られた。 OSCで送られるメッセージのバイト数は確実にMax8に伝わっているが、4の倍数でなければ駄目と叱られ、そして何故か4の倍数であっても叱られる・・・というのがこの実験での結論である。
ここで遂に気付いてクリアになったのは、「AdafruitボードはOSCでなくudpプロトコルで動いているだけ」という当然の事実だった。 Max8からはOSCメッセージをudpで送っている。 そしてAdafruitボードからはudpメッセージが返ってきているが、そのフォーマットはOSCでない単なるデータだったのである。 YAHOO.COMに行って「osc packet format message」などと検索してみると、 ここ とか ここ とか ここ とかのサイトや こんな資料 が出てきて、「12バイト単位」というだけでなく、メッセージの冒頭は「/」であるとか、データタイプを送るとか、色々と出てきた。 Arduinoの方は「OSC」でなく「udp」だったということであり、ここを深掘りしていくことは今後にも重要だろうから、これは明日以降にちょっと挑戦していくことにしよう。
2021年8月19日(木)
8月中は5日インターバルの予定だったのを緊急事態宣言での休業を見越して、昨日は急遽3日インターバルにしてJoyJoy素面ヒトカラ6時間68曲を全力で完走したが、当面の(予告通りに来月12日に宣言解除される可能性は相当に低い(;_;))歌い納めということで色々なクスリと共に極限まで歌い込んで、飲んでもいないのになかなかヘロヘロになった。 以下が今月の断絶前のヒトカラ記録であり、それ以前の記録はこの日記の「2021年8月1日(日)」から全て辿れる。映像系の学生からは「スモークマシンを借用したい」という希望のメイルが届いていたので、 このページ を発掘して知らせつつ、「貸し出しOK」を返信した。 そして午前にザザに出かけて、ようやくモデルナワクチン接種2回目が完了したが、もう世界では3回目のブースター接種が常識になりつつあるのだった。
- 2021年8月5日(木) 6時間 71曲
- 2021年8月10日(火) 6時間 67曲
- 2021年8月15日(日) 6時間 66曲
- 2021年8月18日(水) 6時間 68曲
2画面モニタのAbemaTVの王位戦第4局2日目は午後になっても形勢不明のまま85手を越えてきたが、それを横目に昨日の続きで、 ここ から中身を読み進めて、 ここ とか ここ とかを経て、GitHubの このページ で これ をゲットした。 udpメッセージだけでなくOSCのライブラリはあるだろう・・・と思っていたが、やはり「oscuino」なんてのがあったのだ。
しかし、ふとワクチン接種した左腕に触れてみると、さすがに1回目と違って接種の日から痛みが出てきて、もしかするとこれから発熱か・・・という嫌な予感もちょっとあり、横で白熱している王位戦もちらちら眺めつつ、じっくり腰を据えてプログラミングの実験に没入するという雰囲気ではない(^_^;)。 明日は元々はJoyJoy有休だった日でマルマル空いているので、Arduino-OSCのプログラミングは明日に挑戦することにした。 合間には将棋を追いかけつつ、Amazonで「ワクチン接種済みバッジ」などというのを物色したが、ポチッてしまうほどのブツには出会わなかった。 誰か良いデザインのバッジを作ってくれたら、買うぞ。(^_^)
2021年8月20日(金)
COVID-19モデルナワクチン2回目接種のその晩は、発熱ではなくて強烈な悪寒でガクガクブルブルというのを久しぶりに体験した。 その全身硬直痙攣(約30分?)の疲れでか、今朝は目覚めると全身の倦怠感に苛まれてなかなか起床できなかった。 ようやく研究室に出てきたものの、いつもの朝イチ「脚回し計1400回」は今日だけ止めて、静かに「棋譜データベース」のサイトで昨日の王位戦第4局(藤井圧勝で防衛王手)の棋譜を追ったりした。 明後日には今度は叡王戦第4局でまた「藤井vs豊島」があり、たしか藤井二冠は勝てば叡王を奪取して三冠になるので、その日に発表の予定がある電子情報通信学会ヒューマンコミュニケーション基礎(HCS)研究会のオンラインに身が入らないのは、今から確実である。(^_^;)
そしてフト思い立ち、浜松市のオンラインサイトに行って、上の写真データなどを送りつつ、「ワクチンパスポート」の申請を完了させてしまった。 行き先はいつものリンツ/ウイーンのオーストリア、時期はアルスエレクトロニカの9月は直前過ぎるので国際会議がよくある11月頃として、これから探すことにした。 実際、過去にロシアの国際会議でご一緒したのはオーストリア(拠点ウイーン)の研究グループだったし、リンツのArs Electronicaの研究スタッフと交流したり、ウイーンでの国際会議ISPSに参加したり、と細々と糸は繋がってきたのだ。 そしてオーストリアではオフライン(対面 in-person)の学会/イベント等が再開しているようなので、可能性はゼロではない。 せめていつでも国際会議に行けるという「体」は確保したい、という切なる願望だけは形にしたかったのだ。 そういえば、昨日はAmazonで「ワクチン接種済みバッジ」を探したが良いのが見つからず断念バーグしたのだが、帰宅前にYAHOOショップで以下のような「ワクチン接種済みキーホルダー」と遭遇してしまい、思わずポチッてしまったのだった。
そして、午前中はダラダラとネットニュースを追いかけたりしていたのだが、ワクチンの副反応というのは時間と共に消えていくので、次第に身体の重さが消えてスッキリしてくる・・・という実感が如実に体験できた。 この「快方に向かう嬉しさ」というウェルネスこそ、僕が この論文 の冒頭で書いていたものであり、小児喘息の発作がネブライザー吸入によって刻々と霧散していくあの感じとまったく同じだった。(^_^)
体調(メンタルを含む)がようやくプログラミングに堪えられるか? と自覚したので、上のように昨日から思っていた実験を行ってみた。 Max8からはOSCフォーマットでudpメッセージを送っているのだが、AdafruitボードからのudpメッセージはOSC準拠していなかった・・・ということで、返送用バッファでなく、WiFiで受信したメッセージをそのままudp返送してみたらどうなるか、という実験である。 その結果、やはりデータ列が4の倍数でなければそこで弾かれ、さらにスラッシュで始まったメッセージで4の倍数になっていても、「形式違反」というような文句を言われると確認できた。 こうなれば、いよいよ昨日ゲットしていたOSC関係の情報やライブラリを詳細に読み解いていく、という作業にこれから全力投球となる事が確定した。
ネットで確認すると、やはり上のようにJoyJoyの静岡県(店舗は浜松3店と磐田1店の4軒だけ)は「休業」だった(;_;)。 そして午後になると、何故か異常に眠くなって居眠りしたり、日頃はまったく無縁な「頭痛」まで出現してきて、快方に向かっているとはいえ、副反応はまだまだ続いている。 やはり今日はプログラミングに向いていない・・・と判断して、AbemaTVの過去の藤井将棋や麻雀などを眺めつつ、ぼちぼち行き来している音楽情報科学研究会・夏のシンポジウム関係の運営委員のメイルなどをチェックして過ごした。 明日と明後日はオンライン学会5連発シリーズの初回だが、発表は2日目なので準備は1日目に内職で進める作戦である。 ちょうどSUACネットの工事の関係で研究室のネットワーク(LAN/WiFi)が停止するのだが、そのために1ヶ月限定WiFiルータ(いつも使っているものより大容量)を研究費でレンタルして昨日届いたところなので、明日はその最初のテストとなるのだ。
2021年8月21日(土)
朝イチの眼科通院では治療中の左目の視力が0.7まで改善した。 ずっと1年半ほど0.3だったのが、この1-2ヶ月で0.4、0.5、そして前回(3週間前)は0.6と改善されてきたので、まずまず順調である。 ワクチン接種の副反応もようやく2晩寝たところでほぼ霧散して、いい感じで研究室に出てきた。 ネットのニュースでは、「 世界でワクチン接種が進むにつれ、実際の効果についての調査も進み、その結果がつぎつぎに発表されている。そのひとつ、8月9日にプレプリント・サーバーmedRxivに発表された研究によれば、同じmRNAワクチンでもモデルナ製は、デルタ株に対してファイザー製の倍近く効果が高い可能性があるという。 この調査は、1月から7月の間に主にミネソタ州でワクチンを接種した人々を対象としている。性別や居住地、接種日などの一致するモデルナワクチン接種者とファイザーワクチン接種者、ワクチン未接種者を比較し、その後の新型コロナ感染と病状について調査した。 それによれば、1月〜7月全体では、2回目のワクチン接種から14日以上経っていると、感染予防の効果は、モデルナ製では86%、ファイザー製では76%と計算された。入院予防の確率はさらに高く、モデルナ製で91.6%、ファイザー製で85%。集中治療室入りを防ぐ確率になると、モデルナで93.3%、ファイザー製で87%だった。また死亡はどちらのワクチン接種者においても皆無であった。
だが、7月だけに関してみれば、感染予防の効果は、モデルナ製が76%であるのに対し、ファイザーは42%とかなり低い。これは、両ワクチンのデルタ株への効果の違いを示していると考えられる。7月はミネソタ州でデルタ株が大きく増えた時期にあたるからだ。ただし、幸いなことに、デルタ株であっても重症化予防の効果は、どちらのワクチンも同様に高いままであった。 同研究は、ミネソタ州以外でのブレイクスルー感染も比較調査しているが、その結果も上の数値とほぼ同じであった。感染リスクの差は、どこもデルタ株率が50%を超えた7月がもっとも顕著で、たとえば、フロリダ州では、モデルナワクチン接種者のブレイクスルー感染は、ファイザーワクチン接種者より約60%も低かった。
メッセンジャーRNAという同じ技術を用いながら、両ワクチンの効果の差はどこから来るのか? 同研究はこれに触れていないが、スイス、ジュネーブにあるグローバルヘルス研究所のフラハウト所長は、両ワクチンの投与量の違いが最も大きいと考える。というのも、「ファイザーでは一度の接種で30μgのメッセンジャーRNAが投与されるが、モデルナだと100μg」と、3倍以上のRNAメッセンジャーが投与されるのだ。また、フュチューラ・サンテ誌(8/16)は、モデルナワクチンは薄めずそのまま接種されるのに対し、ファイザーワクチンは0.9%の生理食塩水で希釈されるという違いと、RNAメッセンジャーを運ぶ脂質ナノ粒子の組成が異なることにも言及している。日本では現在圧倒的にファイザーワクチンの接種数のほうが多いが、モデルナワクチン接種を進める意義も大きいといえるだろう 」 ★ という嬉しいものも流れてきたが、一方で「モデルナ製ワクチンの心筋炎リスク報告、米当局が調査」というのも流れてきていて、既に世界的にステマ合戦の様相なのだった。今日と明日は電子情報通信学会ヒューマンコミュニケーション基礎(HCS)研究会、上がそのプログラムである。 そして今日と明日がSUACネットは工事で止まる・・・ということでレンタルしたWiFiルータで、まずは学会参照用のMacBookAirで問題なくZOOM接続したが、なんとお仕事Mac mini(いつもはLANでネット接続)のLANをOFFにして、WiFiをONにしてルータと接続したところ、ブラウザでネットに繋がらない(^_^;)というトラブルに苛まれた。 ブラウザをSafariやChromeやVivaldiに替えても駄目、PRAMリセットしても駄目、と繰り返すうちに、試しにFTP用のRBrouserでサーバに接続してみるとちゃんと出来た・・・という事実にピンと来た。 FTPではドメイン名でなく、サーバのIPアドレスを直接指定して接続しているので、このトラブルはDNSなのだろう・・・と、今度はZOOM接続できているMacBookAirで「汎用DNS」を検索して、Googleが公開している汎用DNSの「8.8.8.8」を入れてみると、無事に何事もなかったように接続できるようになった。 これで一安心で、今日1日かけた内職で明日の発表の準備を進められる環境が整った。8月21日(土) 午前 非言語 (1) アバタを使用したWeb会議におけるプロテウス効果の継続的検証 (2) 共感覚的比喩を用いた触感と表情の対応性に関する一検討 (3) 対話中の非言語行動の機能スペクトラム解析に向けて 〜 頭部運動を対象とした機能コーパスと深層学習モデルの構築事例 〜 (4) 頭部運動機能を用いた複数人対話における対話参加者の主観的印象の予測 8月21日(土) 午後 招待講演 「体験メディア:時空間を超えた体験共有によるコミュニケーション拡張」 8月21日(土) 午後 CSCW (5) オンライン学習環境における学習者支援の方略 〜 日本語教師のネットワーク構築と活動の事例から 〜 (6) マルチモーダル特徴量を用いたターン管理の意欲と実際のターン交替の同時予測 (7) エージェントとの共食におけるユーザによる食事行動同期の効果 (8) ケータリングサービスを用いた3者間オンライン共食実験の実施 8月22日(日) 午前 ネットワーク・ソーシャルメディア (9) クラウドソーシングにおける成果物評価の提示と追加報酬に関する研究 (10) テレワーク環境におけるショート動画による活動報告に向けて (11) Instagramにおける投稿の特徴といいね!獲得数に関する基礎的調査 (12) ソーシャルメディアを用いた危機管理 〜 公衆衛生緊急事態における情勢感知を例として 〜 8月22日(日) 午後 感覚・認知(I) (13) 平面認識を用いた聴覚情報と触覚情報による空間認知 (14) ウェルネス・エンタテインメントのためのインタラクティブな錯覚体験システムに向けて 長嶋洋一(静岡文芸大) (15) 恋愛者間で行われる非対面コミュニケーションの内容分析 8月22日(日) 午後 感覚・認知(II) (16) VRは人々の心をオープンにするか? 〜 オンラインコミュニケーションメディアと自己開示への影響 〜 (17) 多様な自動リーダビリティ判定手法の性能比較と教育的説明性 (18) ユーザの個人特性に応じた自己/他者の作業結果比較システムの検討 HCS2021-33
そしてお昼にふとレンタルWiFiルータの画面をスワイプしてみると、上のようにグラフがあり、全部で7GBというグラフに対して500MBほどまで使用量が伸びていた。 今日は眼科に行ったので朝イチから研究室にいなかったのにこれだけ増えると、今日1日、さらに明日に終日、同じようにZOOM接続しているとこのグラフが伸びて7GBに行ったらどうなるのか・・・というのをよく知らずに契約していた事に気付いて、慌ててレンタル会社にそのあたりの質問メイルを出した(回答には2-3日とのこと)。 そしてネットで「ZOOMのネット使用量を削減する方法」というのを調べて、自分の動画はもちろんOFFっていたので、ZOOM画面を最小化してみることにした。 これだとプレゼンも見えないので(^_^;)、学会ZOOM参加といっても「ただ接続しているだけ」という形になってしまうが、明日の肝心の発表の時に接続が切れたら困るので、まぁ仕方ない。
2021年8月24日(火)
一昨日の日曜日にはHCS研究会で無事に発表して(プレゼンWebページは無し)、藤井二冠は叡王戦第4局に豊島竜王にボロ負けして奪取失敗(→共に2勝2敗で最終第5局へ)。 昨日の月曜日には息子一家の引っ越しの手伝い(裏方)で8キロを超えた初孫を抱え続けて本日やや腰痛(^_^;)。 明日の水曜日から3日間はFIT2021で初日の午後には僕の発表。 そして今日は朝9時から王位戦第5局が徳島県徳島市「渭水苑」で始まっていて、明日の晩には藤井二冠の防衛か、豊島竜王が3勝2敗に盛り返すかが決まる。 そんな「合間」の火曜日だが、朝イチで届いていたメイルはちょっと気になるものだった。
メイルのタイトルは「Wearable bio-signal devices & brain-computer interfaces | EEG & EMG-based」というもので、僕にとってはジャストフィットで食い付くネタである。 また新しいシステムが出たという情報であれば、スグにも購入(今期は予想外の受託研究があったり出張ゼロで研究費は比較的潤沢なのだ)に動くところである。 ただしこのメイル、ちょっと怪しいのだった。 これまで購入してきた生体情報センサのシステムは、たいてい研究者グループの研究成果で、ただしお金が無いのでKickstarterなどのクラウドファンディングで・・・という流れなので、自分たち研究グループの紹介などが定番なのだが、このメイルにはそのような「研究」の自己紹介もなくスマートで、「 Dear Nagashima Y., Let me introduce our tech portfolio aimed for biomedical and robotics developers and researchers. Experiment with bio-signals through our easy-to-use and accessible brain and muscle measuring solutions. With our wireless devices, you can record research-grade EEG and EMG signals, and you'll get full access to our easy-to-integrate SDK and visualizer: "arc: standalone EEG headset | 6 ch" , "armband: EMG armband for gesture control | 8 ch" , "strip: transform any headphone into an EEG headset | 4 ch". Explore: mindrove.com 」というかなり淡白なもので、経験上はかなりの違和感があった。 そして上の「mindrove.com」というサイトに行き、「explore」というボタンを押すと、なんと以下のように3つの品揃えが登場して、さらに「order」ボタンが完備していた。 これはちょっと出来過ぎで、やや怪しい。(^_^;)
この3つの品揃えと製品(として完成しているらしい)価格は、 Mindroveのページ によれば、 Museのように「額」を使わずに頭頂部と耳付近の電極のヘッドセットで脳波センシングする「standalone eeg headset」であるという「arc」(specは ここ )は499ドル、 見た目は出来損ない(試作中?)のMyoのような筋電センサらしい「emg-based gesture control armband」であるという「armband」(specは ここ )は479ドル、 自分の愛用するヘッドホンの頭頂部に取り付けることで脳波センシングする「transform any headphone into a brain sensing device」であるという「strip」(specは ここ )は479ドルというものである。
ここまで、お約束のホスト(PCなりスマホ)画面が出てこないのでやや不安になったが、以下のように「Visualizer on Desktop & SDK : free」という淡白なページからはGitHubに行って、とりあえず こんなZIP をゲット出来たが、その中身は以下のように「ばりばりWindowsだけ」であり、他のツールが「Win/Mac/Linux」と謳うのとはかなり対照的だった。
VisualizerがWindows専用ということで、とりあえず最近の某X社プロジェクトで新しくWindowsも買ったので見てみることは出来るにしても、ここまで「ばりばりWindowsだけ」となると、GitHubに上げているとはいっても、世界標準のオープンソース文化との距離をなんとなく感じて、どうもこのグループ/企業?は、これまでの北米(カナダ/USA)とか欧州(ポルトガル/オーストリア/英国/フランスなど)とは異なる・・・という印象を持った。 最近ではAmazonでも、いい感じだと思った商品が実は中国製の粗悪なものというトラブルも多いとのことで、ここはスグに中身に食い付くのでなく、まず調べてみることにした。
とりあえず、まずは「国」である。 そこでINTERNICのWHOISでドメインから調べてみた。 上のようにWHOISサーチに「mindrove.com」を入れてみると、「MindRove Kft.」という会社名と、国としては「Hungary」が出てきた。 ハンガリーでこんな先端の生体センシングシステムの研究や開発が進められていた、というのは聞いたことはなかった。
そこでさらにYAHOO.COMで、この会社「MindRove Kft.」を検索してみると、上のように一応はちゃんとした会社のようだったが、「Managers」が「1 persons」となっていて、「Numbers of staff」も「persons」となっていた。 これでは僕のArt & Science Laboratoryと同じ、個人営業ではないか(^_^;)。
さらにYAHOO.COMで「MindRove Kft.」を検索してみると、謎にあふれた こんな論文? が出てきて、さらに上のようなBohn Andras氏の情報に辿り着いた。 その経歴から、ブダペストの工科大学を出て、機械学習とデータサイエンスの修士を取り、2017年から2019年までこの「MindRove Kft.」で開発者としてこのEEGヘッドセットのためのデスクトップアプリケーションを開発(センシング部分でなくアプリプログラミング)をして、2019年からはフリーのSoftware Engineerであるようだ。 そして、 この論文? はなんと「Technical white paper」とのことで、どうもドキュメントとしてはこれしかないようである。(^_^;)
そして結論として、「これはパス」と決断した。 理由は上記のようなものである。 Sketchingコミュニティのメンバーとしては、ややショボくてもオープンソースで頑張ったプロジェクトにはクラウドファンディングで支援したいのだが、これはあまりにも情報が少なく、「詐欺サイト」ではないと思うのだが、なんともあちこち不安で溢れているのである。 とりあえずこの情報をMACS-MLに丸投げしてみることにして、僕は手を出さない・・・と決断した。 それにしても、 EmotiBit や MindRove の情報が乱舞するというのは、いい時代だぁ。(^_^)
- 価格はそこそこの範囲内なので興味あり
- 3種類のセンサ/インターフェースは面白いが詳しい情報は公開されていない
- アプリケーション/SDKはWindows専用しかない
- プロジェクトの正体/全貌はまったく不明
そして、明日から上のように大規模に3日間開催されるFIT2021であるが、調べてみると過去のFITとしては、2002年(東工大)、2003年(札幌学院大) ★ 、2006年(福岡大学)(※聴講参加) ★ 、2008年(慶應大学SFC)、2015年(愛媛大学) ★ 、2019年(岡山大) ★ 、そして今年の2021年(オンライン)ということのようだった。 僕の参加は「E分野 自然言語・音声・音楽」であるが、それでもあまりに多いので、自分の参加する「音楽情報処理」のセッションだけタイトルを残すと、以下のようになる。 要するに自然言語と音声というバカでかい領域にひっついているのが音楽情報処理なのだ。A分野 モデル・アルゴリズム・プログラミング B分野 ソフトウェア C分野 ハードウェア・アーキテクチャ D分野 データベース E分野 自然言語・音声・音楽 F分野 人工知能・ゲーム G分野 生体情報科学 H分野 画像認識・メディア理解 I分野 グラフィクス・画像 J分野 ヒューマンコミュニケーション&インタラクション K分野 教育工学・福祉工学・マルチメディア応用 L分野 ネットワーク・セキュリティ M分野 ユビキタス・モバイルコンピューティング N分野 教育・人文科学 O分野 情報システムそして、AbemaTVのお〜い王位戦を眺めつつ、明日の発表のために久しぶりの 「Risset Rhythm」 温故知新 と 「Risset Rhythm」 からの発展に向けて とを眺めて過ごした。 すっかり忘れていたが、今回のRissetRhythmねたの2件発表(6月の時間学会と今回のFIT2021)の前者の当日2021年6月20日に、「第16章 "Shepard Note" vs "Risset Rhythm" というアイデア」なんてのを思いついて追記していたのだった。 開催は8月下旬でもFITの原稿提出期限は「2021年6月18日」と早かった(実際には5月22日に送付済)ので、FITの予稿にはこれについて一言も書いていなかったのである。 まぁ、中身としてはそれほどでもないので最後に時間が余ったら軽く紹介するか、「15+5分」の時間枠なのでパスするか、明日になって考えることにした。自然言語・音声・音楽 8月25日(水) 9:30-12:00 1d会場 自然言語処理(情報抽出) 8月25日(水) 13:10-15:10 2c会場 自然言語処理(言語生成・評価) 8月25日(水) 13:10-15:10 2d会場 音楽情報処理 8月25日(水) 15:30-17:30 3d会場 「Real Time Risset Rhythm Generator」から「Live Sampling Risset Rhythm」への道 フレーズパターンの複雑性推定による難易度選択可能なベースフレーズ自動生成方式の実現 音楽検索のための楽曲特徴量についての調査 楽曲聴取における個人差を考慮したリラクゼーション効果の分析 複数音の協和性を表現可能な特徴量を用いたCNN-LSTMコード進行推定法 各楽器音の時間-周波数特徴の変化に追従可能なDeform-Conv Dense U-Netによる音源分離法 音声言語処理 8月25日(水) 15:30-17:30 3e会場 自然言語処理(文書分類・応用) 8月26日(木) 9:30-12:00 4e会場 自然言語処理(言語モデル・語彙) 8月26日(木) 15:30-17:30 5e会場 自然言語処理(対話,画像と言語) 8月26日(木) 15:30-17:30 5f会場 自然言語処理(情報検索・推論) 8月27日(金) 9:30-12:00 6d会場 自然言語処理(校正・感情推定) 8月27日(金) 13:10-15:40 7e会場
夕方には、だいぶ前に業者に発注していたブツが、無事に取り寄せ出来たということで このように 納品されてきた。 これは新しいプロジェクトを始めるための「シーズ」なのだが、具体的に何をどうするというプランは皆無なので、毎日少しずつ触ったり眺めたりするうちにアイデアを練っていく作戦である。 いずれもちらっと触っただけでも何かに化けそうないい感じなので、あまり慌てずにぼちぼち遊んでいこう。
王位戦第5局は互いに慎重に読みあって遅々として進み(AIはほとんど振れずに50%前後を行き来するだけ)、45手目を豊島竜王が封じたが、この時点もAIは「50%」となっていて、全く先が読めないまま明日に引き継ぐことになった。 明日はFIT2021での発表もあるが、同時にAbema王位戦もずっと横で眺める・・・という忙しい日になりそうである。2021年8月25日(水)
緊急搬送されたCOVID-19患者が各地で入院を断られ見捨てられて、沖縄・東京・埼玉・千葉・神奈川・大阪・茨城・栃木・群馬・静岡・京都・兵庫県・福岡・北海道・宮城・岐阜・愛知・三重・滋賀・岡山・広島の21都道府県に緊急事態宣言が出て、石川・福島・熊本・宮城・富山・山梨・香川・愛媛・鹿児島・高知・佐賀・長崎・宮崎の13件に蔓延防止等重点措置が出て、・・・というタイミングでパラリンピックが始まったというのは、アベノマスクにも増して天下の愚策としか言いようがない。
王位戦第5局(AIは前日50%)の豊島竜王の封じ手は△3三桂として始まったが、気付いてみると何故か(ほとんど見ていないので詳細不明)、午前中からAIは藤井優勢(79%)に振れていた。 そんな中、何事も無かったようにFIT2021は15分野のパラレルセッションに加えて5つのイベント会場で以下のように一斉に始まったが、これだけのZOOMがどわーーーーーっと同時並行に走っているというのは、考えてみればなかなか圧巻である。
朝イチで1106内でZOOMを走らせて、今日の発表では「Max8で実際にデモ」を前面に押し出すことを決めて環境を確認した。 Max8のAudio Preferenceとしては、入力はWebカメラのマイク、出力はZOOM Audioと設定することで、スレーブ機のZOOMから自分のプレゼン音声とMax8のサウンド、さらにWebブラウザでのmp3再生サウンドなどが全て出ることを確認した。 3日前のHCS研究会のZOOMで、「画面共有」に切り替えるメニューに「サウンドを共有」だけでなく「動画の画質を最適化」という新しいチェック項目が増えていたのを発見したので、今日はこの両方をONにすることになる。
FIT2021はCOVID-19がなければ東北学院大(仙台)で開催される筈だった。 そして、全国から多数の研究者がFIT2021のために仙台に集うところに向けて、上のような「現地限定お土産」が準備されていたのに幻となった。 出張で仙台にも行けない日々が続くので、せめてFIT2021のサイトで紹介されたこのお土産でも購入して地域経済の振興に協力しようかな・・・とオンライン購入ページに進んだのだが、何故かカード決済の最後のあたりでエラーとなって購入成功できなかった(;_;)。 天下の情報処理学会のサイトから行ったところでのオンラインショップのこのようなバグは、ちょっと恥ずかしい感じである。
そして上のようにFIT2021のセッションで発表したのだが、何故か事前テストで鳴っていたサウンドが原因不明でZOOMを伝わって鳴ってくれず(;_;)、せっかくデモをきめようと思っていた構想は完全に崩壊してしまった。 ブラウザのmp3再生のサウンドまで鳴らないというのは想定外もいいところで、今後もサウンドねたのオンラインは鬼門となりそうだ。 とりあえずYouTubeやサーバに上げたURLをchat画面に貼り込んで「後で聞いてね」と進めたが、ライヴでMax8でデモるというスタイルは消えてしまったので、なかなかショボい発表になってしまった。 それにしても「ZOOMとサウンド(Max8)」との相性の悪さはなかなかだなぁ。
発表の時には閉じていたVivaldi(AbemaTV)を再び立ち上げて王位戦を見ると、残り時間が藤井120分豊島26分で、AIの判定は藤井優勢90%となっていた。 しかしいつものように、帰宅までには決着しないで、結果は明日に見ることになるだろう。
・・・と書いていたら、なんと17時にもならない16:49に、77手であっさりと豊島竜王が投了して、藤井王位の防衛が成立してしまった。 まぁ、これだけ圧倒的の敗勢では仕方ないのだろう。 何日か前の叡王戦では逆に藤井二冠が圧倒的に負けたし、この二人の将棋はなかなか凄い世界なのだ。
気付いてみれば既にこのページのHTMLも207kBになったので、夏休みの途中でちょっと中途半端ではあるものの、ここでpart10を終えて、 Sketching日記(11) に続けていくことにしよう。 まだまだ「Sketching」が続くことになりそうである。
「日記」シリーズ の記録