PureData 日記

長嶋 洋一


2013年8月24日(土)

2013年の夏休みも中盤となった。 今年の前期は5月から7月まで、みっちりと Raspberry Pi に没頭する期間となったが、発表する目標として頑張った Sketching2013 まで Raspberry Pi日記 を進めたところで失速、学期末のあれこれでほとんど進展しないまま、お盆になった。 お盆休みはハンダ付けなど具体的な作業なく「沈思黙考」で過ごし、これから約1-2年の作戦を朧げながら立てた。

そして来週火曜日8/27には、 Sketching に続いて、今年2度目の海外出張に出発する。 メインはウイーンでの国際会議 ISPS2013 での発表参加と、今年もまたリンツでの Ars Electronica2013 の視察参加である。 ここ で数えたところでは、リンツが8回目、ウイーンが4回目となる。 日程がカチ合ってしまったので、残念ながら東大で開催の 音楽情報科学研究会 (SIGMUS20周年・第100回研究会)には参加できないが、これは半年前から判っていた事である。

そして、今年はArs Electronica2013の開催時期が例年よりちょっとだけ遅いために、ISPS2013から数日あるということで、ウイーンからリンツには直行しない。 去年、3人の院生と行った 欧州ツアー2012 の行き先はウイーンとリンツとICMC2012のリュブリャナ(スロベニア)だったが、現地で突発的にスロベキアとクロアチアにも遠征した事に味をしめて(^_^;)、今年はウイーンからハンガリーのブダペストへ、ブダペストからチェコのプラハへ、プラハからリンツへ、と計3本の「国境越え」鉄道の旅を計画した。 既に指定券はチェコからの国際宅急便で手元に届いている。 これまで国内での鉄オタ(乗り鉄) だったのが、なにげに海外まで拡張されてきたのである。

ここ最近では、 海外出張 の際に、あれこれけっこう時間があること、出張中というテンションの高さによって集中できること、等の理由からか、「○○○日記」ということで、新しい何かに取り組みつつ日記としてドキュメントを残す、というのがマイブームになっている。 去年の 欧州ツアー2012 では、数年前に書いたところでストップしていた Propeller日記 を、それまでのWindows上でなくMac上のツールbstと出会ったのを契機に 続・Propeller日記 として再開し、リンツ・ウイーン・リュブリャナと旅行する中で、Propeller-OLEDモジュールとXBeeを持参して空港やホテルでプログラミング三昧、相当に進展させるとともに、去年から今年に繋がる 続々・Propeller日記 へと発展した。

一昨年の6月には、ノルウェー・オスロでの NIME2011 に参加しつつ、みちみち SuperCollider の勉強を進めた。そして8月には英国Huddersfieldでの ICMC2011 に参加しつつ、 SuperColliderProcessing を進展させ、OSCを経由してMaxとSuperColliderとProcessingとを統合させた。 この経験によって、今年の Raspberry Pi でも、OSCの活用はかなりアッサリと進んだのである。

そして、今年の Raspberry Pi日記 のかなり早い段階で、既にPd(PureData)のモジュールはインストールしてあり、また実験用のMac(研究室も出張用も)にも、簡易版と豪華版の2種類のPureDataがインストール完了していて、アイコンもちゃんと並んでいるが、これまでノータッチで来た。 なんせRaspberry Piも初めて、PureDataも初めて、という組み合わせでは、実験しつつ理解していこう、という道具として甚だ問題があるからであり、PureDataの兄弟であるMax6 を、 公開前 から知って使い倒してきている身としては、Max6で十分なので、必要性も無かったからである。

お盆休みを「沈思黙考」で過ごした結果として、来週から約2週間の海外出張中に、テキスト書き(文書整理/作成)でお仕事する分量は十分なだけある、と確認できた。 しかし、やはりここは、道中あれこれ、新しいこともやって行きたい、とフト思いついたターゲットがPureDataなのである。 Raspberry Piは持参して実験するには、電源など「重過ぎる」のが欠点である。 PureDataはMaxよりも軽いのがウリなので、空港でも飛行機内でも実験ができるのでは、という期待がある。 そこでまずは、 PureDataサイト に行き、サイトの全体像を眺めるとともに、必要な資料を機内などオフラインでも参照できるように、ドキュメント類を手元に集めることにした。

まず、 PureDataサイトのトップページ にある概説(多数のリンクあり)は以下である。 まるでComputer Musicの歴史のようなお話であり、リンク先を参照することなく説明できるので、これは旅立ってから、機内とかで暇があれば概要を解説してみたいと思う。

Pure Data

Pure Data (aka Pd) is an open source visual programming language. Pd enables musicians, 
visual artists, performers, researchers, and developers to create software graphically, without 
writing lines of code. Pd is used to process and generate sound, video, 2D/3D graphics, and 
interface sensors, input devices, and MIDI. Pd can easily work over local and remote networks 
to integrate wearable technology, motor systems, lighting rigs, and other equipment. Pd is 
suitable for learning basic multimedia processing and visual programming methods as well 
as for realizing complex systems for large-scale projects.

Pd is free software and can be downloaded in different versions. The two principal 
distributions of Pd are:

    Pd vanilla (or simply Pd): the core of Pure Data, mainly written by Miller Puckette, 
	focusing on audio signal and MIDI processing.
    Pd extended: a version of Pd vanilla that comes with many libraries written by the 
	community. Pd extended can be used for graphics rendering (GEM library), OSC 
	communications, binary file processing, audio-visual streaming, physical modeling, 
	sensor-based performances, and much more.

Both distributions are available for GNU/Linux, Windows, or Mac OSX as well as for other 
operating systems. Pd is multi-platform and portable; it runs on anything from an old laptop 
to a Raspberry Pi to a brand new desktop, and even on tablets and smartphones thanks to 
projects like libpd, pddroidparty and RjDj.

Pd is a so-called data flow programming language, where software called patches are 
developed graphically. Algorithmic functions are represented by objects, placed on a screen 
called canvas. Objects are connected together with cords, and data flows from one object 
to another through this cords. Each object performs a specific task, from very low level 
mathematic operations to complex audio or video functions such as reverberation, fft 
transform, or video decoding. Objects can be:

    built-in Pd objects;
    abstractions, that is, reusable patches created in Pd itself;
    externals, i.e. objects developed in another programming language.

The work of many developers is included in Pd-extended or can be downloaded separately, 
and complete patches from the community can be found on this site and elsewhere on the web.

Pd is a major branch of the family of patcher programming languages known as Max (Max/FTS, 
ISPW Max, Max/MSP, jMax, DesireData, etc.), originally developed by Miller Puckette at IRCAM. 
Pd was created to further the Max paradigm by extending data processing to applications 
other than audio and MIDI, such as real-time video and web interaction.

This site is a contribution of the IEM to the Pd community. Everybody using Pd is welcome 
to join and write/contribute some documentation, reports, news, announcing events and 
add comments. The site is run on a Linux server with Zope / CMF / Plone and administrated 
and driven by the Pd community.
PureDataサイト の左側には「downloads」・「documentation」・「development」・「community」・「members」・「exhibition」という6つのリンクカテゴリがある。 その downloads のところを見ると、まず冒頭には、既にダウンロード・インストール済みの以下の2つがある。 この下に、さらに「Distributions」・「Applications」・「Libraries and externals」・「GUI Plugins」・「Other Downloads」と多数のリンクが並んでいるが、当面はこれは必要ないだろう。

PureDataサイト の次の documentation が、当面のターゲットである。 ここで気付いたが、どうやら日本語のページも完備しているようである。 ただしチラッと見た感じでは、自動翻訳サイトに突っ込んだだけのようで味気ないので、やはり本家の英語サイトを追いかけることにしよう。 いちばん最初の Start Here によれば、「Getting Started with Pd」として、まずはPureDataをダウンロードして、実行せよ、とある。 とりあえずせっかくなので、以下のように、「Pd-extended」と「Pure Data」の両方を起動して比較していくことにした。

次に「Exploring a Patch」として、「Pd-extended」のHelpメニューから「Pd Help Browser」を開け、とある。 これに従って「Manuals」→「+ Start Here」→「+start-here.pd」と行くと、以下のように最初のサンプルパッチが出て来た。 なお、Macのシステム環境設定で「ウインドウの上部をダブルクリックしてウインドウを畳む」という機能をいつもONにしているが、PureDataのウインドウはこれを頑固として無視する(^_^;)事も判明した。

そして、まぁMax6と兄弟だから当然であるが、このサンプルパッチ内の記述にあるように、以下のような使い方が判ってパッチを変更するまで要した時間は3分ほどである。

そしてついでに、「Getting Started with Pd」には無い方の「Pure Data」のHelpメニューから「Pd Help Browser」を開き、同様に「Pure Data」→「1.manual」→「index.htm」と行くと、なんとテキトエディタでhtmが開き(そのように設定しているので)、オリジナルのhtmlファイルが何故か見つからなかった。 これでは「Pd-extended」のようにはサクサクと行かない。 そこで、簡略版の「Pure Data」はとりあえず諦めて棚上げし、「Pd-extended」だけで進めていくことにした。

そして「Pd-extended」に戻って、「Pd Help Browser」を見ると、「0.intro」で以下のようにhello_worldが出てきて、あとはもう60個か70個ほどのPdパッチが、この「0.intro」の中に詰まっている。 もはやHTML版やPDF版のドキュメントなど不要で、ヘルプ/マニュアル/リファレンス自体がパッチである、というMaxと同じ文化である。 つまり、このまま機内に持っていけばPureDataはお勉強できるのである。(^_^)

documentation のページには、いちばん下あたりに Raspberry Pi という気になるリンクがあるが、とりあえず他をザッと見てみた。 すると、 Development Wiki のページはMaxと同様にPureDataのオブジェクトを開発する者に必要なページということで当面パス、 community のページは以下のようなものでこちらもパス、 members のページもメンバー検索で不要、と判明した。

そしてリンク最後の Pure Data exhibition のページは、PureDataユーザのいろいろな応用のショーケースという事になるのだが、なんと12個しかリンクが無かった。 いちばん最後のものを試しにダウンロードしてみると こんなもの だったが、これはICMCかNIMEで見たような気もする。 しかし、PropellerのサイトでもArduinoのサイトでもProcessingのサイトでも、そしてもちろんMaxのサイトでも、このような「exhibition」のサンプルはこれでもかこれでもか・・・と数十個とか100以上はズラリと圧巻に並ぶのが常なので、ちょっとこれはあまりに寂しい(^_^;)。 やはり、フリーのPureDataより、実際の作品とかパフォーマンスの作家/専門家はMax6に流れているのかもしれない。 この Pure Data exhibition のページの他の11個のサンプルは、どこかで時間があればチェックしてみる事にした。

あと残ったのは、PureDataサイトでの Raspberry Pi というページである。 ここは、 Raspberry Pi日記 に書いた、「ふーみん本」と関係する部分ということになる。 既にふーみん情報として、Raspberry PiでPureDataを走らせるというのは、簡単なサウンド生成処理でもちょっと重くて苦しい、という見立てがあるので、基本的にはあまりサウンド生成/エフェクト処理には期待していない。 ただし、センサインターフェースをOSCと組み合わせてシステムの一要素として構成するのは面白いので、ここも、PureDataについておよそ掴めた段階で、改めてRaspberry Piで実験することにしよう。

ここまで整理したところで、持参する出張用MacBookAirで「Pd-extended」の動作確認をしたところ、サウンドが出ない(^_^;)、という現象となった。 まぁ、これは過去にもあれこれ経験しているので、たぶんアレだろう・・・と色々preferenceなどを開いて、外部Webカメラも接続できる環境をインストールしていた事を思い出した。 最後にそちらを選択していたので、ビデオ入力とともに、オーディオ機器もWebカメラになっていたのを発見して無事にdefaultのオーディオが動作する事を確認した。 これでOK、とりあえずPureData初日はこんなところである。

2013年8月25日(日)

まずは、 Pure Data exhibition の残り11個、というのが気になったので、PureDataの応用例を、ということでとりあえず並べてみた。 この作業の後半は、実は翌日の8月26日(月)だったが、区切りが中途半端だったので今日にまとめてある。

bang-tris, by Marius Schebella

「Tetris created completely in Pd」ということで、PureDataで作ったテトリスである(^_^;)。 リンク先 には、ちゃんと PureDataソース が置かれていたが、まだその中身の解析方法は不明である。

en Echo, by Philippe Manoury and Miller Puckette

「a music piece for soprano and live electronics」ということで、Philippe ManouryとMiller Pucketteによる作品である。このMiller PucketteがPureDataの生みの親であり、かつてIRCAMでDavid Ziccarelli(Maxの生みの親)とともにNeXT上のMaxとしてISPWを開発した本人である。 リンク先 には、 YouTubeムービー が置かれている。

Automatenklavier, by Winfried Ritsch and IEM

「custom-built electronics + Pd makes a piano speak English」ということで、ヤマハのDisklavierを使わずに、力ワザで自動演奏ピアノを作っている。 リンク先 には、 YouTubeムービー が置かれている。

solenoid concert, by Roman Hafeli

「a software-sequencer controls 8 solenoids, that knock on different things and therefore produce some rhythmic noise」ということで、ソレノイドを制御してそこら中のモノを叩いて音楽にする楽器である。 リンク先 には、 YouTubeムービー が置かれている。

TVestroy, by Thomas Ouellet Fredericks and Danny Perreault

「expanded cinema syncing image and sound」ということで、jitterで出来るような事である。 リンク先 には、 YouTubeムービー が置かれている。

Onyx Ashanti's Beatjazz

「Onyx Ashanti demonstrates "beatjazz" -- his music created with a custom instrument」ということで、まぁNIMEネタである。 リンク先 には、 YouTubeムービー (メイキング中心)だけでなく、 TEDのムービー (パフォーマンス)も置かれている。

Spore and Darkspore, by Maxis/EA Games

「a multi-genre metaverse god game that uses Pd for its procedural sound」ということで、jitterで作れるようなゲームである。 リンク先 には、 YouTubeムービー が置かれている。

tr-909 emulation, by Raul Diaz Poblete

「a Roland TR-909 emulator built using Pd and Processing」ということだったが、残念ながら リンク先 のダウンロード先は切れていてPureDataソースを入手できなかった(^_^;)。

HASA-Laboratories, by Olsen Wolf

「an installation featuring robotic showerhead camera creatures」ということで、先端(頭部)にCCDカメラを付けた蛇のようなロボットのデモ風景であった。これもMaxでも簡単だろう。 リンク先 には、YouTubeでなく Vimeoムービー が置かれている。

Engranaje (Sprocket), by Maira Sala

「a realtime movie editor with a multitouch interface」ということで、画像認識のインスタレーションのようである。MaxでもFlashでもよくある作品である。 リンク先 には、 には、YouTubeでなく Vimeoムービー が置かれている。

We own the sky, by Pierre et le Loup

「Pd-processed guitar in songs from rock trio Pierre et le Loup」ということで、アルバム中のギター音をPureDataでエフェクトさせているらしい。 リンク先 には、「CDを買ってね」ということか、何もムービー等が置かれていない。(^_^;)

Silent Drum by Jaime Oliver

「A modified drum that uses computer vision for gestural control of music」ということで、透明な胴体にゴム膜を張ったドラムをぐいぐいと押して変形する形状を画像認識でサウンドを生成させるものである。 リンク先 には、 YouTubeムービー が置かれている。

やはり、歴史もある天下のPureDataとしては、ちょっとデモのショーケースとして、12件(うち1件は実質的に判らない(^_^;))というのはあまりに寂しい気がする。 パソコンの性能が上がり、Max/MSP/jitterが席巻する中で、意地になってフリーのPureDataを支持してきた研究者はまだ多いとしても、実際に作品やパフォーマンスをする人々は、あまりPureDataに拘泥しないのかもしれない。

2013年8月26日(月)

いよいよ海外出張の前日である。 午前中から、耳鼻科(外耳道に異常が発生し治療)に行ったり床屋に行ったりしたが(^_^;)、なんとか上記の記録も整理できた。 そして、PureData初日にちょっと謎だった点、「PureDataのサンプルデータがどこにあるのか」が解決して、出張中にお勉強するためのサンプルを取り出すことが出来た。

上のように、「Pure Data」と「Pd-extended」のそれぞれについて、ブラウザからPureDataサンプルパッチを開き、これを別名保存するフリをしてサンプルのディレクトリを探ったのである。 そして無事に、以下のように解決した。

ここで、Webに上げる「PureData」ディレクトリと、実験用の「PureData_test」ディレクトリとを分離して、後者にはPureDataサイトからダウンロードしたYouTube/Vimeoムービーと、このPureDataサンプルを解凍して置いた。 「Pure Data」のサンプルパッチ(zip再圧縮版)は これ、 「Pd-extended」のサンプルパッチ(zip再圧縮版)は これ、 である。 あとは「Pure Data」と「Pd-extended」の両方を並行してサンプルを調べていき、例えばMax6で同等パッチを作ったりしていけば、違いや差分の検討とともにPureDataについての理解が進むだろう、という作戦である。

ちなみに以下が、最新の「PureData」ディレクトリを先頭(タイムスタンプ順)に、僕のサイト「nagasm.org」のASL(Art & Science Laboratory)の部分(1106研究室ページはこれとは別)の全体像である。およそ20年間で、よくぞここまで作ってきたものである。(^_^)

さて、いよいよ出発の24時間前となったので、ここでようやく、電源プラグやトランスなど、研究室から持参する機材などの準備に取りかかった。 今回はトランジットのフランクフルトを除けば、滞在都市は「ウイーン」「ブダペスト」「プラハ」「リンツ」の4都市なので、まず、YAHOO.COMの画像検索でそれぞれの都市名を入れてザッと眺めてみると、どうもいずれの都市もブルーが多いような印象である(^_^)。 ウイーンでもいくつか、そしてリンツでは写真の建物がどこか良く知っているものがたくさんあった。

この4都市の位置関係は、およそ以下のようになっている。 このGoogleマップには鉄道が書かれていないが、だいたい道路に沿っているのではないか・・・と勝手に推測している。 ウイーン→ブダペストは3時間弱であるが、ブダペスト→チェコは6時間、チェコ→リンツは5時間以上という鉄道マニアには楽しい旅である。

まず最初の訪問地のウイーンでは、既にポスターセッションで貼り出して発表するポスターも完成しているし、オンラインで プログラム も配布されている。 ホテルは去年の 欧州ツアー2012 と同じにしたので土地勘もあり、順調ならウイーン空港からリムジンバス→ウイーン西駅からタクシー、という去年のパターンでなく、スーツケースを押しながら電車だけで安くホテルにたどりつく作戦である。 地図も以下の3つを用意して、完璧である。 ただし今年のウイーンはずっとISPS2013会場なので、ほとんど観光の余地は無い。

次の訪問地のブダペストは、まだ「地球の歩き方」も読んでいない、全くの白紙状態である。 現地のデザイン関連大学等を訪問する、という予定は、一応、以下のデザイン/アート系の大学についてチェックしているが、土日に行っても開いていない可能性が高い。 とても残念なことは、「 コダーイ博物館 は休館日が週に4日もあり(^_^;)、今回の滞在期間に全てひっかかっていて、行けない事である。

その次の訪問地のプラハも、まだ「地球の歩き方」も読んでいない、全くの白紙状態である。 こちらは平日ということで、以下の3つの大学に「見学させて。可能なら意見交換でもどう?」との打診メイルを1ヶ月前に出していたが、シカトされていた(^_^;)。 まぁ、チェコ語の国であり、3つの大学の中でどうやら英語のコースがたった一つしかないので、日本人からのヘンな英語は無視されたのかもしれない。 地図によればいずれも市内なので、可能であれば覗いてみるかもしれないが、まったく未定である。

そして最後がいつものリンツである。 既にフルパスチケット(135ユーロ)もオンラインで予約していて、今回はじっくりに見て回る予定である。 今年は開催前からかなりWebの資料が充実していて、これから旅行中にそのプリントアウトと プログラム とを照合して優先度を検討し、なるべく有効に行き倒すつもりで、パフォーマンスも網羅したいと思っている。 宿はいつものLocomotive、そして以下のように展示会場もお馴染みばかりで、土地勘もありまずは安心である。 11番の「元タバコ工場」だけちょっと離れているが、ここは アルスエレクトロニカ2010 のメイン会場だったところで、リンツカードがあればバスで簡単に行ける。

明日は、自宅から着替えなどを入れたスーツケースを持って大学にクルマで出て、午後にe-wingに乗るために浜松西インター駐車場に出発する。 実は先月、7月の Sketching から帰ってきて気付いたが、ずっと何年も(10年以上)酷使してきた白いスーツケースに遂に割れが入ったので、新しいのを買ったのである。 以下は、その最後の雄姿である。

しかし、この白いのも軽さ抜群だったが、さらに軽ーーくなってるのであった。 篠田麻里子がCMしてるやつよりもっと軽い、 サムソナイト を大人買いでゲットした。 既に汚くシールを貼りまくっている。 新品なので「汚く」というのがポイントである。 このスーツケースへのパッキングは、明日の午前、まさに出発直前、研究室でやっつけよう。 (この日の 事件 は、とりあえず 無事 ということで何よりであった(^_^;))

2013年8月27日(火)

さて出発の当日である。 実際のフライトは明日の早朝であり、今日は午後にe-wingでセントレアに行って、東横インで前泊である。 学生と海外に行く時には、前泊のセントレアで、 飛行機を見に行ったり した。 夜のセントレアは奇麗だが、一人旅の時にはどこにも行かない(^_^;)。

音楽情報科学研究会の第100回研究会に関する運営委員会の直前準備のメイルが多数(朝の2時間だけで10数本)行き来して、さらにSUACデザイン学部の進展に関する重要なメイルが何本も行き来し、ここにインターカレッジ参加校の連絡メイルが多数行き来する、という、かなり厳しいタイミングでの出張となったが、まぁここは折々にネットに接続して、こなしていくしかない。 とりあえず、研究室のお仕事パソコンの作業領域を全て、64GBのUSBメモリ2本に詰め込んで持参することにした。 あまり旅先で事務仕事はしたくないが、これは覚悟の上である。

昨日(正確には日曜日の深夜)からの 事件 で2ちゃんねるが完全に沈黙していて、新スレが並ぶ ニュースヘッドライン が怒濤の荒らしの後、昨日からまったく進まないという、これまで無かった状況である。 95%以上のゴミスレの中に、たまに1%程度の有益な情報(これはどのニュースサイトよりも早い)があるのを、暇があればチェックしてきたが、遂にこれで伝説の2ちゃんねるも終焉を迎えるのかもしれない。 国内のニュースより先に発売情報を知って申し込み、同僚の申し込みよりも2週間も早く ゲット できたのもここのお陰だった。 関連ログ(HTML)を落としたところ既に50本を越えたので、これは旅の合間に眺めるには最良の暇つぶしとなりそうである。

さて、出発までに少しだけでもPureDataお勉強をスタートしておこう、と、再度、中身に入らずにPureDataの枠組みを眺めてみた。 まず、Webの方でなく実験用のディレクトリに「Pd-extended_doc」と「Puredata_doc」として保存した、チュートリアル(サンプル)のPureDataバッチの全体を眺めてみると、以下のようになっている。 そして実際に実験してみると、「Pd-extended」にあるパッチ(拡張子 *.pd)を「Puredata」(vanilla)アプリに投げ込んでも、逆に「Puredata」にあるパッチ(拡張子 *.pd)を「Pd-extended」アプリに投げ込んでも、まったく同様に起動した。 つまり両者のパッチは基本的に同等/互換であるらしい。

そして、「Pd-extended_doc」と「Puredata_doc」の容量が大きく違うのは、拡張版の「Pd-extended」では、「media」というサンブルサウンドファイルと、あと上の「manuals」というディレクトリがあるからである。 この「manuals」というディレクトリには上のように、既に見た「+ Start Here」から始まり、「0.Intro」(66ファイル)、「1.Sound」(15ファイル)、「2.Image」(23ファイル)、「3.Networking」(13ファイル)、などとまさにチュートリアルとなっていて、さらに「Cognition」(8ファイル)、「pd-msg」(上にあるようにさらに深い階層まで充実)、そして上にある「PdDrums」や「PlayNow」など、すぐに叩いてみたいソソラレルものが充実している。 つまりは、教条主義的にPureDataの全体を学ぶ教科書は、「Pd-extended_doc」と「Puredata_doc」に共通にあり、「Pd-extended」の下の「manuals」以下は、とりあえず使えるサンプルを並べた速習チュートリアルなのでは、と見切った。 どちらからスタートするか、ここは逆に、悩ましいかもしれない。

そして上のように、PureDataの2つのバージョン「Pd-extended」・「Puredata」には、アプリケーションのサイズに約10倍の違いがある。 参考に他にMax5、Max6、Processing1.5、Processing2.0、SuperColliderのサイズも並べてみたが、やはり「Puredata」(vanilla)の小ささは突出している。 これはおそらく、実行時のメモリ占有スペースに直接に関係して、例えば長距離フライトの機内で実行させた場合に、バッテリの持ちに影響する可能性が高い。 電源のあるところではどれでもいいが、機内ではバッテリ長持ちのために「Puredata」(vanilla)を使うようにしてみよう。

2013年8月28日(水)

昨日は無事にe-wingでセントレアに到着して前泊であるが、まだ日本なのに目覚めたのは午前3時過ぎである。 実はこの夏は、 この子 のおかげで、深夜というか早朝というか、午前3時とか午前4時に目覚めて相手する・・・という事が多かったのだ。 しかしここで超早起きしておけば、朝イチのフライトで成田に飛び、フランクフルト行きのフライトが午前11時台で、直後の昼食を「いま現地は午前2-3時だ」と念じつつワインとともにいただいて強制的に爆睡するには、むしろ好都合である。 無理に寝ないで、ここは起きているに限る。

ネットの方では、 事件 がまだまだ収まらず、ニュースヘッドラインはいまだ心肺停止状態であり、落とした関連ログも72本に達している。 多量の危ないtxtファイルも何故か貯まってしまった(^_^;)。 東横インの部屋LANはまずまず快適だが、FTPでのアップロードは通らないので、昨日、大学で撮った新しいスーツケースの写真はウイーンまでお預けとなりそうである。

さてPureDataのお勉強であるが、行きのフライト(軽い方が長持ち)があるので、まずは「PureData」ディレクトリにある「Puredata_doc」から進めることにした。 「1.manual」というディレクトリの最初にある「1.introduction.txt」は以下のように親切かつ明快である。

PD_VERSION

A real-time graphical programming environment for live interactive
computer music, Pd works on Linux, Macintosh OSX, and Microsoft Windows.

Pd is copyrighted, but is free for you to use for any reasonable purpose.
See the file:
     PD_BASEDIR/LICENSE.txt

Reference documentation for Pd lives in:
    file:PD_BASEDIR/doc/1.manual/index.htm
or:
    http://www.crca.ucsd.edu/~msp/Pd_documentation/index.htm

More extensive FLOSS documentation is available on:
    http://en.flossmanuals.net/PureData/ (English)
    http://fr.flossmanuals.net/PureData/ (Francais)

Information of all sorts (guides, development, meetings, etc):
    http://puredata.org

The Pd mailing list archive lives in:
    http://iem.at/mailinglists/pd-list/
ここに書かれているように、この「1.introduction.txt」と同じ「1.manual」にあるindex.htmlが以下のようなフルセットの「Reference documentation for Pd」であり、これを読みつつ、続く「2.control.examples」・・・というディレクトリ内のPdパッチで実際に勉強していける、という素晴らしいドキュメント一式である。 当然ながら全てがオープンでありフリーである。素晴らしい。
    introduction
        guide to the documentation
        other resources 
    theory of operation
        overview
            main window, canvases, and printout
            object boxes
            message and GUI boxes
            patches and files 
        how to edit patches
            edit and run mode
            creating boxes
            the selection
            deleting, cutting, and pasting
            changing the text
            connecting and disconnecting boxes
            properties and help 
        messages
            anatomy of a message
            depth first message passing
            hot and cold inlets and right to left outlet order
            message boxes 
        audio signals
            sample rate and format
            tilde objects and audio connections
            converting to and from messages
            switching and blocking
            nonlocal signal connections 
        scheduling
            audio and messages
            computation load
            determinism 
        semantics
            creation of objects
            persistence of data
            message passing
            inlets and lists
            dollar signs 
        subpatches
            abstractions
            graph-on-parent subpatches 
        numeric arrays
        data structures
            traversal
            accessing and changing data
            editing
            limitations 
    getting Pd to run
        audio and MIDI
        installing Pd in Microsoft Windows
        installing Pd in Linux
        installing Pd in MacOS X
        installing Pd in IRIX (SGI)
        preferences and startup options
        how Pd searches for files 
    writing Pd objects in C
    current status
        release notes
        known bugs
        differences from Max/MSP 
最初の「introduction」の「guide to the documentation」は、上記の「1.introduction.txt」をより詳しく解説したもの、そして「other resources」のリンクと解説も充実している。 そして、いよいよ本編の「theory of operation」の冒頭、「2.1 overview」では以下のようにあった。 そういえば PureDataサイトのトップページ にある概説の解説、という宿題が残っていたが(^_^;)、これは機内ででもやってみよう。
Pd is a real-time graphical programming environment for audio and graphical processing. 
It resembles the Max/MSP system but is much simpler and more portable; also Pd has 
two features not (yet) showing up in Max/MSP: first, via Mark Dank's GEM package, Pd 
can be used for simultaneous computer animation and computer audio. Second, an 
experimental facility is provided for defining and accessing data structures.
要するにPureDataはMaxと同じことが出来るがずっと軽いよ、さらにMaxには無いがGEMとdata structuresにも対応しているよ、という事である。 ただし残念ながら、国立音大もだいぶ協力したGEMは既に業界では半過去のものであり、data structuresとともにjitterあたりで完全に追いつかれていて、「PureDataでないと出来ないこと」はたぶん、ほとんど無いのである。 Maxよりも軽くてオープン/フリーだ、というのが、今後もPureDataがMaxと棲み分けるポイントとなるのだろう。

「2.1.1. the main window, canvases, and printout」は、PureDataの基本的な枠組みである。 PureDataを起動すると、上のような「"Pd" window」がまず現れて、ここからいくつでも「"canvases" or "patches"」を作っていける。 ここまで書いて朝の5時半、そこからシャワーを浴びてパッキングと朝食で、いつもよりもちょっとだけ早めにホテルを出て、ANAのチェックインカウンターに着いたのは07:00だった。 成田へのフライトは08:20なので余裕たっぷりである。

・・・そして今は08:50、セントレアから成田のフライト中であるが、実はこの1時間半に、なんとも激動のハプニングがあった。 一言で言えば「阿呆・馬鹿・間抜け」、という顛末である(^_^;)。 知らんぶりして誤摩化してもいいのだが、ここは正直に、しかしさりげにフォントを落として薄字にして記録しておく。
いつも欧米行きには、朝イチのフライトで成田に飛んで、成田を昼前に出発するフライトが定番なので、たいていセントレアに前泊する。 ここに落とし穴があるのは、過去にフライト同日の日付けで前泊の筈のホテルを1日違いで予約していて慌てた(^_^;)、というミスで身にしみていた筈なのだが、「慣れ」こそ恐ろしい、遂にやっっちまっったのである。
チェックインカウンターでバゲッジを預けたところで、係員から指摘されて判明したのは、なんと僕が予約していたフライトは今日8/28でなく、昨日8/27だった(^_^;)(^_^;)。 既にこのフライトは昨日、飛んでしまっていて、僕の持っているチケット(行き)はただの紙くずなのだ。 ウイーンのホテルの予約は8/28からであり、まったく順調に進んでいると思い込んでいたが、フライト指定が旅行の初日、セントレア前泊の日付けだったのだ。
ここでカウンターの係員がANA本部に電話して、「予約変更の可能性を調べるので30分後にまた来て下さい」という事になった。 デッキでじっと不安に待つ30分というのは、実に、長かった。 そしてカウンターに戻るとその係員が別のお客さんにつかまってさらに20分、待たされた。
フライト30分前の07:50になって判明した対応は、帰りも含めて僕の持っているチケットを全てキャンセルして、新たに同じフライトの今日の行きと予定通りの帰りのチケットを改めて買う、ということであった。 夏休みも終わりのシーズンオフの平日で、席の予約だけは取れた、というだけでも助かった。 本来なら数万円を覚悟するキャンセル料は不要とされたが、後日にキャンセル扱いで戻る元々のチケットは19万円、そして今日買ったチケットは43万円である。SUAC旅費の出張が、プラス差額(私費24万円)の高い旅行となった(;_;)。
そして帰りのリンツ→フランクフルトのフライトだけは同料金では同じ便が取れず、当初予定はリンツ15時発あたりでフランクフルトの乗り継ぎもそこそこだったのが、なんとリンツ発が朝の6時だという。 朝6時のフライトだとチェックインが1時間前の朝5時、タクシーで30分とすればホテル出発は朝4時半であるが、これは過去に何度か経験しているので仕方ないし、まぁ何でもない。 これは考えてみると、乗り継ぎのフランクフルト(約13時間もある(^_^))で、ようやく初めて、「フランクフルトの街」に出れる、という事である。 そう開き直らなければやってられない。
結局、キャンセルの手続きは成田空港で行うように連絡してもらって、搭乗検査も普通の行列と別のショートカットを通って、成田へのフライトにぎりぎり間に合って乗れた、というところなのである。 要するに、僕の完全な勘違い(思い込み)ミス、という事であった。 まぁ、ここは切り替えて、あとは何事もなかったように旅を続けていこう。(^_^;)

・・・ということで(^_^;)、成田空港、搭乗15分前の10:40である。 ゲート内の両替所はユーロだけでなくハンガリー・フォリントも、チェコ・コルナもあって、無事に全てを両替できた。 いったん全部をユーロにして現地で両替所を捜すよりは、再交換レートの損もなく、まぁ楽になった。 両替しただけ、現地でちょうど使い切ることが重要である。 ここでメモしておくと、手数料を含めた変換レートは、「1ユーロ = 135円」、「1フォリント = 0.5円」、「1コルナ = 6円」、ということである(端数切り上げ)。 およそ1ドル(100円)を基準とすると、感覚として100円は、1ユーロ以下(0.7ユーロ)、ハンガリーに行ったら200フォリント、チェコに行ったら15コルナ、ということになる。 これはもう、移動するたびに価格の感覚がクラクラしそうである(^_^;)。

・・・ということで、いつものようにクウォーター(1/4ボトル)のワイン(ANAはカベルネソーヴィニョンなので最高)を計4本飲んで爆睡して、ロシア上空で目覚めてストレッチとオレンジジュースとコーヒーでリフレッシュしたところから再開である。 今回の目覚めはちょっと早くて、成田から4時間、フランクフルトまで7時間というところである。 まずは宿題だった、 PureDataサイトのトップページ にある概説の解説からスタートである。

Pure Data (aka Pd) is an open source visual programming language. Pd enables musicians, 
visual artists, performers, researchers, and developers to create software graphically, without 
writing lines of code. Pd is used to process and generate sound, video, 2D/3D graphics, and 
interface sensors, input devices, and MIDI. Pd can easily work over local and remote networks 
to integrate wearable technology, motor systems, lighting rigs, and other equipment. Pd is 
suitable for learning basic multimedia processing and visual programming methods as well 
as for realizing complex systems for large-scale projects.
「aka Pd」というのは詳細不明だが、MaxにしてもPureDataにしても、これらは「visual programming language」である。 従来のプログラミング言語というのは、C言語でもJava言語でもJavaScriptでもFlashのActionScriptでも、ProcessingでもPythonでもPropellerのspinでもArduinoのCでもAKI-H8のアセンブラでもXcode(MacやiPhoneやiPadアプリの開発言語のC++)でも今は昔のBASICでも、全て「記述言語」であり、なにやら異国語のような(まぁ英語ベースだけれど(^_^;))、テキストエディタでソースコードを記述して、これをコンパイルすることで、コンピュータが実行できるものだった。

これに対して、MaxやPureData、さらにMatLabやレゴのMIndStormなどのvisual programming languageというのは、開発環境のスクリーン上にモジュール化された「箱」を配置して、それらを「線」で繋ぐことでアルゴリズムを実現する。 これにより、理数系でない音楽家・研究者・ビジュアルアーティストなどが、言語記述を使わずに直感的に自分の希望する「世界」をブログラミング出来るようになったのである。 これは情報技術的には、イベントドリブン(オブジェクト指向)のC言語の発展(→C++言語やJava言語に綱がる)から、ソースコードの擬似的な並列処理を実現することで発展してきた流れである。 MaxやPureDataは音楽の世界から始まったが、このプログラミング哲学の革命は、あらゆる情報処理システムに波及している。

PureDataはMaxと同じように、サウンドの生成、映像、2D/3Dグラフィクス、センサなどのインターフェース、そしてMIDIを扱える。 そしてPureDataはMaxと同じように、ローカルや広域のネットワーク、ウェアラブルな機器、モータ等の制御、照明機器の制御なども行える。 PureDataはMaxと同じように、基本的な学習に役立ち、さらに組み合わせることで本格的な複雑なシステムまで実現できる。

Pd is free software and can be downloaded in different versions. The two principal 
distributions of Pd are:
    Pd vanilla (or simply Pd): the core of Pure Data, mainly written by Miller Puckette, 
	focusing on audio signal and MIDI processing.
    Pd extended: a version of Pd vanilla that comes with many libraries written by the 
	community. Pd extended can be used for graphics rendering (GEM library), OSC 
	communications, binary file processing, audio-visual streaming, physical modeling, 
	sensor-based performances, and much more.
PureDataはフリーソフトウェアであり、大きく2種類のバージョンがダウンロードできる。 一つは作曲家でありプログラマでもあるMiller Pucketteの作った「Pd vanilla」(あるいは単に「Pd」)であり、ここでは音響信号処理とMIDIプロセシングに特化して、とにかく、軽い(^_^)。 もう一つは「Pd extended」であり、PureDataコミュニティによって開発された多数のライブラリによって機能拡張されている。 ここにはグラフィック・レンダリング(リアルタイムCG生成)のGEM、OSC通信、バイナリファイル処理(vanillaはテキストファイルのみ)、ストリーミング処理、物理モデル音源、センサ活用パフォーマンス、等々がある。
Both distributions are available for GNU/Linux, Windows, or Mac OSX as well as for other 
operating systems. Pd is multi-platform and portable; it runs on anything from an old laptop 
to a Raspberry Pi to a brand new desktop, and even on tablets and smartphones thanks to 
projects like libpd, pddroidparty and RjDj.
(Mac版とWindows版しかない)Maxと違って、PureDataのどちらのバージョンも、GNU/Linux, Windows, or Mac OSXに対応していて、Raspberry Piのバージョンもある。 軽くマルチプラットフォームであるPureDataは、さらにタブレット版とかスマートフォン版にもどんどん移植されている。 (ちなみにSketcjing2013では、Maxがアンドロイドに移植されつつあったが・・・・(^_^;))
Pd is a so-called data flow programming language, where software called patches are 
developed graphically. Algorithmic functions are represented by objects, placed on a screen 
called canvas. Objects are connected together with cords, and data flows from one object 
to another through this cords. Each object performs a specific task, from very low level 
mathematic operations to complex audio or video functions such as reverberation, fft 
transform, or video decoding. Objects can be:
    built-in Pd objects;
    abstractions, that is, reusable patches created in Pd itself;
    externals, i.e. objects developed in another programming language.
PureDataは「data flow programming language」とも言える。 Maxと同じように、PureDataソースコードは「パッチ」というグラフィカルに開発できるプログラムである。 canvasと呼ばれるスクリーン上に、論理的な処理を「オブジェクト」というソフトウェア部品を並べて、互いにcordsで結ぶことで関係付けることがそのままプログラミングとなる。 個々のオブジェクトにはシンプルな機能から画像処理やリバーヴやFFTやビデオ処理など高度な機能まであり、(1)PureData自体に用意されているオブジェクト群、(2)PureDataで他に定義されたパッチをオブジェクトとして再利用、(3)CやJavaやJavaScriptなど他のブログラミング言語で定義された外部オブジェクト、などの種類がある。
The work of many developers is included in Pd-extended or can be downloaded separately, 
and complete patches from the community can be found on this site and elsewhere on the web.
PureDataコミャニティの専門家/アーティストが開発した色々な成果は、オープンソース文化のもとで、Webで多くの成果をダウンロードして、互いに勉強したり再利用できる。
Pd is a major branch of the family of patcher programming languages known as Max (Max/FTS, 
ISPW Max, Max/MSP, jMax, DesireData, etc.), originally developed by Miller Puckette at IRCAM. 
Pd was created to further the Max paradigm by extending data processing to applications 
other than audio and MIDI, such as real-time video and web interaction.
PureDataは、Miller PucketteがIRCAMで開発した「Max」の色々な発展系(Max/FTS, ISPW Max, Max/MSP, jMax, DesireData, etc.)の兄弟たちの一つであり、本家である。 ここからは僕の補足であるが、David ZiccarelliはIRCAMでMiller Pucketteとともに、故・Max Mathews先生の弟子として、NeXTコンピュータ上に最初のMaxを開発した。 Miller Pucketteはプログラマでもありまた作曲家てもあるので、まだ当時は非力だったワークステーション上で軽く動くPureDataに固執して、また作品への応用に重点を置いていった (Miller Pucketteは日本にも慶応大とか国立音大とかに滞在在籍していて、たぶんどこかのコンサートでご一緒している)。 一方、David Ziccarelliは生粋のプログラマであり、まだ当時は非力だったパソコン(Mac)でも動くものを市販するためにCycling'74社を興して、もう20年以上になる (David ZiccarelliはSUACにも2002年のDSPSSに来たし、これまでICMCやNIMEやSketchingで何度もご一緒している)。 パソコンの処理能力は当時から100-1000倍ほどになり、ここにきてMaxが盛り返してきたが、かたや背後からスマホやタブレットに脅かされている、という状況なのだろう。
This site is a contribution of the IEM to the Pd community. Everybody using Pd is welcome 
to join and write/contribute some documentation, reports, news, announcing events and 
add comments. The site is run on a Linux server with Zope / CMF / Plone and administrated 
and driven by the Pd community.
この部分はちょっと詳細不明であるが(^_^;)、PureDataはオーブンソースのコミュニティなので、興味をもったらどんどん参加してね、という事である。 ・・・これで宿題も完了である。 フライトはちょうど、全体の半分まで飛んできた。

さて、朝から半日、あれこれとずいぶんあったが(^_^;)、ようやく「2.1.1. the main window, canvases, and printout」から再開である。 上のウインドウにある「peak level and clip indicators」はオーディオの入出力のインジケータである。 PureDataでは最初からMIDIだけでなくMSPと同等なのであるが、これはMiller Pucketteにとっては当然のこだわりだろう。 彼が楽器メーカの制約下のMIDI音源で満足するわけは無いのである(^_^;)。 これ以降の細かい説明は、読んでみたがあまり重要ではないのでスキップする。

ここまで、まだPureDataパッチは呼び出せるものの、新しく作る方法は不明である。 これは、続く「2.1.2. object boxes」でようやく解明した。 とりあえずPureDataを起動して、「File」メニューから「New」で新しいcanvasを開き、以下のように「Put」メニューからObjectを選んでボックスを出して、そこにタイプすればいいのだ。 ちなみに日本語モードだと暖かく無視されるので直接入力にする事。

PureDataのパッチを構成するのは、以下の4種類の「ボックス」である。

このボックスには、(半角)スペースで区切って「atoms」を並べる。 第一atomはオブジェクトの機能名、第二atom以降はそのパラメータ、というのはMaxと同じである。 PureDataはこのatomsを入れると、そのオブジェクトの機能を内部的に生成し、さらに初期化する。 「+ 13」というオブジェクトは、第一atom「+」が加算演算を、そして第二atom「13」が、加算される値として13を設定し、入力に対して13を加算する、という機能がここに生成される。 数値は整数や浮動小数点数だけでなく「4.5e6」[4.5 multiplied by 10 six times, i.e., 4500000](4.5 * 10の6乗)という指数表現もアリらしい。 指数は負もアリで、「1.23e-5」は「0.0000123」である。

数学的に無意味な「+5」とか「0..6」は「Zack」「cat」などと同様のシンボルと解釈される。 またPureDataはもともとUinxベースなので、シンボルは大文字小文字も区別され、「gore」「Gore」「GORE」は全て別のものとして扱われる。

オブジェクトの第一atomはそのボックスのインレットとアウトレットを指定する。 以下の例はシンブルなMIDIシンセサイザーである。 MIDI入力から「stripnote」でノートナンバ(ピッチに対応した数値)を抽出し、「mtof」でMIDIノートナンバを対応する周波数に変換し、「odc~ 0」で位相ゼロでサイン波を生成し、「*~ 0.1」で音量を絞って、「dac~」でオーディオ出力している。 ここらは完全にMax/MSPと同じである。(^_^)

MaxのラインはMax5からMax6になってグレーのうにょうにょ曲線になったが、基本的にこれはPureDataではcontrolと呼ばれる細い線である。 またMaxではオーディオ信号は黄色と黒の雄々しいタイガースカラーであるが、PureDataでは判りにくいがsignalと呼ばれる太い線である。 controlはデータやイベントが発生した時にだけ情報が流れるが、signalの方はオーディオレートで常に信号が流れている。 cintrolを受けるオブジェクトにsignalを入れては駄目(繋がらない)のもMaxと同じらしい。

次は「2.1.3. message and GUI boxes」である。 色々な「ボックス」の描かれる「淵」の部分が、そのオブジェクトの属性を表している。 ボックスの中にあったテキストを書き換えると、PureDataは古いオブジェクトを消滅させて、新しいテキスト指定に対応したオブジェクトを生成する。 「Message boxes」(ボックスの矩形の右端の淵がヘコんでいる)はテキスト記述されたメッセージを、メッセージ入力があるかマウスでクリックされると出力する。 普通のオブジェクトは普通の矩形である。 第三のオブジェクトは「GUI ("graphical user interface") box」であり、ボックスの矩形の右上端の角がナナメに切れている。 GUIオブジェクトには、「number boxes」「toggles」「sliders」など、たくさんあるらしい。 Maxと同じように、PureDataでもGUIオブジェクトは、データを動的に表示するだけでなく、マウスのクリックやドラッグによって入力インターフェースになるようである。

次は「2.1.4. patches and files」である。 Maxと同様に、PureDataのパッチはオブジェクトの組み合わせを記述するだけで、ある瞬間のそれぞれの数値は保存できないので、データストレージのオブジェクトに対してread/writeする事が必要である。 まだここまでのところでは「loadbang」は無いが、たぶんあるのかな(ただし「bang」という概念はまだ登場していない)。 「2.1 overview」はここまでである。

続いて「2.2. editing Pd patches」の最初は、「2.2.1. edit and run mode」である。 Maxに慣れていると判りにくいしちょっとショートカットに対するレスポンスが遅い(^_^;)が、「command*E」で行き来するのは同じである。 実行モードと編集モードは、カーソルが変わることで判別するらしい。

・・・このあたりまで機内で約3時間、進めたところでバッテリが50%を切ったので、そこまでとした。 やはり、Processing(中身はJava)とかMax6などよりも、PureDataはCPU負荷も軽い気がする。 そこから残り3時間ほどの機内は、いつもの数独と、「お試しかっ」「ほこvsたて」「探偵ナイトスクープ」「米国版サスケ」などのバラエティビデオ、そして今回のヒットは米国内をずっと落語ツアーしている落語家(名前は失念(^_^;))の英語の落語ビデオであった。

フランクフルトの乗り継ぎはけっこうギリギリであまり充電もできなかったので、今日のPureDataはここまでである。 いまは現地時間でまだ8/28の22時過ぎ、ただし日本はもう朝の5時である。 ここまでを 帰国後に公開予定のWeb に上げて、長かった1日もおしまい、いよいよ明日はISPS2013である。

2013年8月29日(木)

PureData日記といいながら、とりあえず今回の渡欧中は旅行記と比重は半々である(^_^;)。 上の8/28の最後の部分を書いて寝たのは23時近かったが、やはり身体はまだまだ日本を引きずっていて、深夜というか早朝の3時には目覚めてしまった。 ここからいくらベッドに横になって目をつぶっても寝れないのは判っているので、朝のお仕事からスタートしてしまおう。

2ちゃんの流出騒動はまだまだ続いていて、いつも旅先でチェックするニュースヘッドラインが実質的に止まっているので、時間的にはむしろのんびりした日々となっている。 まぁ、日頃から誹謗中傷悪口雑言罵詈讒謗してきた連中にはいいお灸だろう。 また、音楽情報科学研究会100回研究会も、どうやら開催直前となって、怒濤のように舞い込んでいた運営委員の準備メイルも閑散としてきた。始まってしまえばたぶんゼロになる。これも助かる(^_^;)。 大学からの事務式な連絡もほぼ一段落した。

届いたメイルを転送しているYAHOOに接続して消していると、以下のようなメイルがYAHOOから届いた。 これは Sketching に行っていた7月のシリコンバレーにも届いたが、まぁ、きちんとしているというのか、移動先が刻々とYAHOOにダダ漏れしているというのか、微妙である。 まぁ、iPhoneを持っている人やLINEをしている人は日々の移動を全てGPS情報として盗聴・蓄積されているのだから、それに比べればマシかもしれない。

帰途のフライトが早朝に変更となったために、まったく準備していなかったが、フランクフルトでの観光の調査が必要になった。 ただしこれは、過去にも似たような状況で調べたことがあって、 このような 検索をすると、いくらでも有益な情報がゲットてきる、と判っているので安心である。 これはリンツに行ってから調べても十分だろう。

昨夜は分厚い雲を突き抜けて、わずかに小雨のウイーンに到着したが、夜だったのでまったく状況が見えない。 そういう時に便利なのがWeather.comである。 とりあえず今日のウイーンの気温を調べると以下のようであり、だいたい晴れで気温は23度から13度だという。 猛暑・残暑の続く日本には申し訳ないが、かなり快適らしい(^_^)。 念のため上着をバッグに入れて、いつものベスト(脱ぎ着で温度調節)を着ていくことにした。 折り畳み傘は、「降水確率0%」ということなので、パスである。

まだ朝食の7時までは2時間以上あるので、ここでシャワーを浴びて気分転換して、PureDataの続きを進めることにした。 次のトピックは「2.2. editing Pd patches」の「2.2.2. creating boxes」である。 バッチのcanvas内に「boxes (objects, messages, GUIs, and comments)」を作るには、「"put" menu」を使う。 オブジェクトは最初は空白なので、テキストで機能を入れて呼び出す。 ちょっと実験してみたら、putメニューの中のVsliderを呼び出してcanvasに置いて、続いてその下付近にputメニューからnumbersを読んだら、勝手にVsliderの出力とnumbersの入力との結線をしてくれた。 これはまぁ、賢いというか余計なお世話というか、微妙である(^_^;)。 Maxと同じように、編集モードではオブジェクトを選択して(複数まとめてもOK)、コピー・ペースト・デュプリケート(複製)が自在である。

次は「2.2.3. the selection」である。 編集モードでのオブジェクトの指定は、Maxと同様に以下の3種類がある

たしかMaxでは、複数のオブジェクトを結線したものを選択しても、その相互の結線が選択されなかったのが不満なのだが、PureDataはちゃんと結線情報も選択してコピペ/複製できるようである。

次は「2.2.4. deleting, cutting, and pasting」であるが、これは既に上のところで書いてしまっていた。(^_^;)

次は「2.2.5. changing the text」である。 ブロック内のテキストの入力はMaxと同じで、1回クリックで全選択、2回クリックでカーソル出現である。

次は「2.2.6. connecting and disconnecting boxes」である。 Maxではオブジェクトの下側のアウトレット付近にカーソルを持っていくとアウトレットの厚みが増して「ここから繋いでー!」と懇願し、クリックしてドラッグしたラインを接続先のオブジェクトのインレット付近まで持っていくとインレットの厚みが増して「ここに繋いでー!」と懇願するのでリリースすると接続される(^_^;)。 PureDataでは基本的に同様であるが、繋がる可能性のある時だけ太いマルが出る。 シンプルであり、慣れればこれも楽しいかもしれない。

次は「2.2.7. popup menu for properties, open, and help」である。 オブジェクトのアウトレット付近にカーソルがある状態でマウスの右クリックで「property」が出る、ということだったが、Maxのインスペクタのような強力なものではなくて、単に座標情報などだった(^_^;)。 メニューの「Halp」も使ってね、ということらしい。

最後の「2.2.8. miscellaneous」はquitである。Maxと同じである。 これで「2.2. editing Pd patches」は終了となった。 次は「2.3. messages」であるが、ここで6時(日の出)、日本は午後1時となったので、メイルチェック、ニュースチェック、ログ読みなどをすることにした。7時から朝食、8時過ぎにはISPSに出かけるので、続きがいつになるかは、ISPS2013の会場に行って空気を読まないと不明である。

・・・そして9時、ISPS2013会場のUniversity of Music and Performing Arts Viennaの3つのセッション会場「Joseph Haydn Saal」・「Clara Schumann Saal」・「Fanny Mendelssohn Saal」のうち最大の「Joseph Haydn Saal」である。 ハイドンにメンデルスゾーンにシューマンという名前をホールに付けるというのはウイーンだけだろう。 ホテルから徒歩3分でU4の地下鉄に乗れて、そこから数駅のStadtpark駅で降りて、そこから徒歩数分でUniversity of Music and Performing Arts Viennaに到着する、というのは、予想以上に快適な場所であった。 事前に届いた情報から会場のWiFiも快調で、ホテルと同じ環境で作業が進められる。(^_^)

さて、今回初めて発表参加したISPSはInternational Symposium on Perfor- mance Science(ドイツ語で書くとmdwとなるらしい)という隔年で開催されるシンポジウムである。 もともと、音楽知覚認知学会の三浦先生からの情報で知ったのだが、音楽情報科学研究会などよりは、かなり音知学会に近く、心理学とか音楽学の専門家、ばりばり演奏する音楽家などが中心で、ICMCやNIMEに比べて女性参加者がほぼ半分というのは異例である。 僕は明日のポスターセッションで発表するのだが、高等発表のセッションは常に3つの会場でパラレルである。 1日目の昨日と4日目の最終日はパスとなるので実質的には半分の参加であるが、この日の午前のセッションは、もろ音知学会ぽいものが並んだ。

とりあえず、プリントしてきた プログラム から、以下の今日の朝イチのセッション3択を考えて、シンポジウム会場を選んだところである。 まぁ、どこを選んでもあまり違いは無い、ちょっと遠いところだし、睡眠不足、そしてイキナリ怒濤の英語トークで、なかなか初日から入り込めないのは仕方ない。

朝イチと午前後半の両方のコマをぶち抜いているこのシンポジウムは「Insights into sound practice: A national study of Australian orchestral musicians」というものである。 地元オーストリアかと思ったらオーストラリアだった。 行き来する単語でいちばん多いのは「サイコなんとか」という単語で、心理物理学、心理学、心理社会学、などの用語が並ぶのも、ISMPCなど音楽心理学の常である。 850ページ近い、分厚いProceedingsが渡されたが、この中には僕のpaperも載っている。 予告では このように 昨日からオンライン化されるとあったが、調べた範囲ではまだ上がっていないようである。

もう冒頭の3件に触れただけでお腹いっぱいなのだが、1件目の「Physical characteristics of professional orchestral musicians: Results from a national survey and physical evaluation research project」では、オーケストラの色々な楽器演奏者に生体センサを取り付けての心理物理学的な調査の報告である。 2件目の「Psychological wellbeing in professional orchestral musicians in Australia」は、女性と男性の違い、若者とベテランとの比較、アルコール摂取や喫煙の影響、PTSDの有無など、心理社会学的にオーケストラ演奏者を調査した研究である。 3件目の「Surveillance of musculoskeletal disorders and risk factors in orchestral musicians」は、タイトルからしてなんだか判らない用語で困ったが、エリートレベルの音楽家を対象としたリスク回避に関する研究だった。 ICMCやNIMEでは基本的なタームを共有しているので、聞き流しつつお勉強の内職も可能なのだが、どうもISPSは困難である、と次第に判ってきた。

午前の2つのセッションの間には30分のコーヒーブレークがあるが、ここで会場を移動すると決心した。 あのオーストラリア軍を続けて聞いても仕方ないので(^_^;)、第一印象では一番パスしようと思っていた、「Career perspectives」のセッションをいっそのこと聞いてみようと、シューマン・ホールに移動した。 遠くの建物からは、練習する立派なソブラノの声とかピアノの音が届くという、まさに芸術的な環境である。 会場に入ってみると圧倒的に女性が多く(^_^;)、数えてみたら女性(学生でなくほぼ全員が先生/教授)が15人、男性は僕を入れて3人だった。

1件目の「Constructing an artistic identity two careers at a time: Dance and the career lifecycle」はタイトルの通り、ダンスのスキルを上達させながら同時にライフスタイル(仕事)をどう確立するか、という話である(こちらもオーストラリア)。 やはり、このような切実なテーマは女性の専門家が飛びつくのだろう。 ダンサーとか音楽家は才能がある者がラッキーに世に出てくる、という印象があるが、このような研究が求めているのは、才能がそこそこの学生でも、本人が望む場合にそれなりの仕事としてダンサーとして生きていくためにはどうするか、という、職能育成機関としての大学というものなのだろうか。 日本でも、最近は大学での「キャリア教育」の必要性が語られているが、芸術系/デザイン系の大学には欠けている視点だと気付いた。

2件目の「Life after performance: The subjective experience of musicians who undergo career transition」は、不親切なシートをずっと置いたまま語る、やや小型化したマツコデラックスみたいなおばさんだったので、よく判らなかった(^_^;)。 ただし「お話」のような発表だったためか、質疑応答ではフロアの人達との議論が盛り上がった。

3件目の「Occupational health and wellbeing in the UK conservatoire sector: Staff perspectives」は、UKから柳原加奈子のような元気な先生の報告だった。 ダンス関係はやはり、ガタイが勝負なのだろうか。 UKのコンセルバトアール(音楽院)ではどのような健康サービスが提供されているか、というのは研究なのかどうか不明である。 インタビューから構成したような研究だった。

セッションスキップしたお陰で(^_^;)、上の発表を聞き流しながら、同時にPureDataのお勉強も並行して少しだけ進めることが出来た。 「2.3.1. anatomy of a message」では、メッセージにはシンボルと数値があり、Maxの数値は整数intと小数floatがあるのに対して、PureDataでは数値は「32-bit floating point」の浮動小数点小数だけである、と明示した。 そして例として「float」というオブジェクトが出て来たことで、PureDataでもMaxと同じでbangがある、と判った。 いつも「int」を活用しているが、「float」は右インレットから入った数値をメモレしていて、左インレットからbangが入ると浮動小数点小数に変換して出力するのである。

次の「2.3.2. depth first message passing」はMaxとPureDataが大きく違うところのようで要注意である。 Maxでは、パッチ内に並んだオブジェクトの処理の順番は、「trigger」オブジェクトで制御しない限り、基本的に「右が先」「右から左」である。 しかしPureDataでは違うらしい。以下のパッチは、Maxであれば「A→C→D→B」の順にメッセージが流れる。

しかしPureDataでは、「A→C→D→B」だったり「A→B→C→D」だったりする(^_^;)、というのだ。 Cの出力はあるタイムスロットにおいて、その行き先であるDが処理完了していなければ出ない、Aの出力はあるタイムスロットにおいて、その行き先であるBとかCが処理完了していなければ出ない、というのがPureDataのルールらしい。 このため、Maxでは禁止とされている以下のような無限ループも、PureDataではアリだという。

PureDataではこれはエラーでなくて、システムのタイムスロットという時間のdelayをインターバルとして繰り返すだけだというのである。 stack overflowというエラーメッセージは出すものの、アリなのだという。 これは発想の転換が必要で、どっぷりMaxに慣れた僕には理解しにくい。

これに対して、次の「2.3.3. hot and cold inlets and right to left outlet order」はMaxと同じなので安心できる。 以下の例は「float」の右インレットが冷たいインレットで、左インレットがbangを受ける熱いインレットということで、無限ループのエラーなく、bangが来るたびにインクリメント(ただしfloat出力)するのである。

Maxでは「二乗」の計算をするのに、「*」(整数)あるいは「* 1.0」(小数)というオブジェクトの左右のインレットに数値を入れる。 これは、Maxでは「右から先」というルールがあるからOKなのである。 しかしPureDataでは前述のようにこれが無いので、以下のようなパッチングは禁止であるという。 これはPureDataとMaxとの、概念的な大きな違いだ。

そしてPureDataでは、このような問題を解決するために、Maxでもお馴染みの「trigger」(「t」)を使いなさい、と言う。 以下のようにすれば、PureDataでも、triggerで順序を強制的に指定して、加算(2倍)とか二乗が出来る。

次は「2.3.4. message boxes」である。 前半はMaxと同じなので簡単に言えば、まず(半角)スペースで区切って、複数の要素をリストとして出せる。 その後はあまりMaxでやった事がないので対応は不明だが、「1, 2, 3」とコンマで切ると、3つのメッセージをまとめて記述できるらしい。 これはMaxでも、lineオブジェクトの入力に「0, 100 1000」(まず0を出力し、1000msecかけて100まで増加)などと使っているのと同じかもしれない。

そしてセミコロンはdestibationを指定するたるに使えるという。 これはMaxにあったかどうか不明だが、jitterスクリーンの処理にあったような気もする。 以下の例だと、セミコロンで切って、いくつものreceiveに対して選択的にsend出来るらしい。

メッセージの最後の例は「$1」で、これはMaxと同じで、複数の入力から何番目というのを指定するものである。 これで「2.3. messages」までオシマイである(^_^)。

・・・そして爽やかな中庭でのランチを経て14時、再びハイドン・ホールでKeynoteである。 Peter E. Keller氏(University of Western Sydney)の「Musical ensemble performance: A theoretical framework and empirical findings on interpersonal coordination」である。 音楽アンサンブル演奏を科学的に眺めるための色々な話題を総括的に紹介する、というもので、だいぶ音知学会から音情研に近くなってきたカンジで安心できる(^_^)。 脳機能とか身体動作検出による本格的な実験が続々と続いているのは流石である。 セッションにおける協調・同期の解釈については、Short TermとLong Termと、階層性を持った時間構造が必要だ、というのは重要な指摘だ。 「引き込み」Entrainmentの紹介のところはよく知っている事例かりだったが、ここは自分でもやったのでピクッと来た。

Keynoteの最後のあたりで、これから研究したいこと、という話題が面白かった。 ステージ上の少年合唱団のメンバー1人にセンサを付けて演奏の上手さ(集中度)を計測するのだが、3回の同じ実験で、1回目と3回目の時は客席の聴衆は全員が男性(大人)なのに、2回目の時だけ、客席の聴衆の中に若い女の子がチラホラいる、という状況を作るのだという。 おそらく男の子は2回目の時だけ、いつもより頑張ると容易に想像できるが、そういう実験デザインを思いつくところが凄いのだ。 日本の音楽心理学は総じて真面目すぎるというか、狭い。 ここに来てまだ半日なのに、基本は音楽心理学とかパフォーマンスであっても、より広範な人間の気持ちをベースに自由な研究テーマを設定している柔軟さに感銘を受けた。

15分のbreakの後に、午後のパラレルセッション(15:15-16:45)となった。 「Thematic sessions」のテーマは「Brass and woodwind research」と「Performance anxiety」と「Performing together III」であるが、ここは迷わず再びシューマン・ホールに行き、「Performance anxiety」(パフォーマンスにおける「不安」)に臨んだ。 これも日本音楽知覚認知学会などでは聞いたこともなかったテーマだが、実際に音楽/ダンス等のパフォーマンスに関係する人々であれば、プロアマ問わず直面する、重要なテーマである。 本番を前にして緊張するとか、練習していて失敗するところに不安を持つとか、コンテストでライバルがいるとか、キーワードとして提示されてみればあまりに題材は多いのだ。

1件目の「Maximizing performance potential: The efficacy of a performance psychology program to reduce music performance anxiety and build resilience in adolescents」は、音楽的な不安の分析から始まって、これを最小化することで音楽心理学的に演奏効率を最大化させるプログラムを提案する、というものであった。 Adultsへのセラピーの例として、Drugまであるのには驚いた。 クスリでハイになる、というのは、確かに不安を忘れるためには有効なのだが(^_^;)。 そして重要なポイントはやはり、モチベーションなのだ、という指摘で安心した。 ヤル気があれば不安は克服できる、というのではあまりに当たり前だが、まぁ心理学なんてのはたいてい、感覚的に当たり前の事を科学的に検証しているものが多いのだ。

2件目の「Performance psychology information impact on stress and anxiety level of Brazilian music performers」はタイトルでほぼ語られているが、ブラジル音楽の演奏家のストレスと不安に対して、パフォーマンス心理学からの情報がインパクトを与える、という凄いものである。 よそ者の我々からすれば、ラテンアメリカの音楽家なんて楽天的に奔放に演奏していると思い込んでしまうが、やはり彼らも不安があるのだ、とある意味でホッとした。 実際にはアンケートを中心としたもので、まさに文系の研究であった。 そしてここでフト気付いたが、数時間、英語漬けの会場にいることで、こうして日本語を打ちつつも、ようやく英語が入って(聞こえて)きた、という確かな実感がキターーー(^o^)ーーー。 日本にいると、どうしても読み書きはそこそこでも、いきなり英語で話せないし何より聞き取れない。 しかしここで水路が流れてきたのは幸いで、これなら明日のポスターセッションでは質問されても答えられる、と密かに確信した。

3件目の「Mindfulness and the self- regulation of music performance anxiety」もタイトルの通りである。 ここで判明したのは、1人目オーストラリア、2人目ブラジル、そしてこの3人目ニュージーランド、と全て発表者は女性であった。 やはりこのようなテーマは女性研究者が得意なのだろうか。 この発表は、これまでになく判りやすかったので、フレゼンの写真をたくさん撮ったので、後日、また眺めてみたい。 この領域の研究のやり方の良質なサンプルとなっているように思う。

ここで再びハイドン・ホールに戻って、この日の最後のセッションは「GRADUATE AWARD PAPER」ということで、学生のベストペーパーの発表である。Friedrich Platz氏(Hanover University of Music, Drama, and Media)の「The influence of performers’ stage entrance behavior on the audience’s performance elaboration」ということで、Visual Component of Performanceについて考察した。 無音であるピアノコンテストの決勝2人の演奏を見せたが、大多数が「勝者」を当てたのは何故か、という事である。 耳で聞いてCoolである、という演奏がWao!になるには、見た印象が加わる必要がある、という主張は面白い。 ステージでの演奏に関して、ステージ裏、つまり演奏直前の世界と、ステージ上の演奏時を結ぶ「ステージに登場する瞬間」というものに注目した、というのがこの研究の「肝」であり、聴衆は演奏家がステージに登場する瞬間の第一印象に大きく影響されて評価する、という。 ただしこれは、お笑い芸人が舞台に出てくる時と同じ「掴みはOK」というやつで、考えてみればある意味で当然でもある。 そこを、過去のいろいろな心理学研究の成果をサーベイしつつ理論構成する、という成功例である、と感じた。 バイオリン独奏のコンペで、ソデからステージに登場して演奏開始直前までの多数の演奏家の振る舞いをビデオに編集して、多数の専門家にアンケート調査をして特徴を分析する、というのはとても面白かった。

・・・そして今、オブショナル(無料)の、ウイーン楽友協会(Wiener Musikverein)ホールのガイドツアーからホテルに戻ってきたところ、もうじき21時(日本はもう金曜日の午前4時)である。 このホール は、内部に4つあるうち最大の黄金のホールで行われる、ウイーンフィルの ニューイヤーコンサート が世界的に生中継されることで有名である。 毎日多数のコンサートが行われるシーズン直前の見学ツアーであり、全てのホールを見て回り、また展示室のベートーベンやモーツァルトの自筆の楽譜を見たりできた。 ホールの素晴らしさはとても簡単には書けないのでパス(^_^;)。 ホール入口の集合よりちょっと早めに行って、どこを撮っても「絵」になるウイーン市内を撮影した写真を含めて、これから編集して 帰国後に公開予定のWeb に上げるまでいけるかどうか、というところである。

いよいよ明日は午前にポスター発表、そして晩にはウイーン市長の招待というバンケットがウイーン市庁舎で開催される。 昨夜、ホテルに着いてからほぼ24時間であるがもなかなかに中身の濃いウイーン初日であった。

2013年8月30日(金)

睡眠不足なのでバッチリ眠れるだろう、と前夜は22時あたりに寝たのだが、やはり身体には日本時間が残っていて25時過ぎには目覚めてしまい(^_^;)、せっかくなので上の前日の最後の部分に、ネット検索して出て来た ウイーン楽友協会 などの情報を追加した。 せっかく 帰国後に公開予定のWeb にアップしたので、以下に写真をいくつかリンクさせて、午前2時過ぎ、再び眠ろうと努力することにした。


ウイーン楽友協会


ベートーベンの自筆楽譜


残響の良好な録音用ホール


金属的なホール


小ホール


黄金のホール(大ホール)

・・・そしてここから約3時間、朝5時前に目覚めるまでちゃんと寝ていたようで、だいぶ睡眠不足は解消してきた。 なんせ今晩のバンケットは、ウイーン市長の招待の晩餐会として ウィーン市庁舎 で行われる(国際会議のバンケットが現地の市長の招待、というのは、オスロでの NIME2011 でも、台湾・新竹市での WOCMAT2007 でも経験しているのでそれほど驚かないが)、この時間が「20:00-24:00」と遅いので、睡眠不足を解消しているのは重要なことなのだ。

さらに大学の学生室からは、依頼されて取材されていた「夢ナビ」というやつのWebに掲載された、という連絡が来た。 このページ である。 まだ細部に訂正は入るが、既に 夢ナビ検索ページ の「教授名検索」のところに「長嶋」と入れると このように 僕だけが出てきて、リンクで このページ に行けるので、既に稼働しているらしい。 このため、11月の音楽知覚認知学会秋期研究会(広島)に参加できず、静岡での「夢ナビライブ」という多数の受験生を集めるイベントに行って、高校生を相手に講義をする予定となっている。 もちろんノーギャラ、これは大学教員としての「お仕事」なのだ。

今日のウイーンの気温を調べると上のようであり、昨日と同じに晴れで気温は23度から13度だという。 昨日は「降水確率0%」ということだったが一瞬シャワーがあったので(^_^;)、折り畳み傘は持っていこう。 日本の 事件 の方はあいかわらずで2ちゃんは平常に戻っておらず、既に落としたスレのログは130本であり。これはもしかすると本当に「もうダメぽ」なのかもしれない(^_^;)。 他人に言えないような書き込みをしていた当事者とかクレカ情報/IP等が流出した企業/機関は大騒ぎだが、まぁ傍からみれば、また数年ぶりの「祭り」というだけだ。 ここで起き出してシャワーを浴び、まだ朝食まで時間があるので、今日もまたPureDataを少しでも進めることにした。

PureDataはいよいよ「2.4. audio signals」である。 作者のMuller Pucketteは音響信号処理の領域の作曲家であり、自分がやりたかった音楽を作り上げるためにPureDataを作って進化させてきた、という側面もあるので、ここはPureDataの中でも重要なところだ。

Using Pd you can build audio patches which can synthesize musical sounds, 
analyze incoming sounds, process incoming sounds to produce transformed 
audio outputs, or integrate audio processing with other media. This section 
describes how Pd treats audio signals. 
冒頭の概要は上のようであり、つまりPureDataのサウンド機能としては、およそ以下が出来るという。 まず「2.4.1. sample rate and format」であり、ディジタルオーディオでは必ず、ここの定義からスタートする。 ディジタル入出力機器の性能によって、オーディオ信号の量子化は16ビット(普通のCDの性能)とか24ビット(高性能なCDやDVD)で処理されるが、PureDataは内部的にはこれを32ビットの浮動小数点の「-1から+1までの実数値」として処理する。 単純にディジタル数値処理をすると、例えば「0.9」のレベルの信号を加算したら「1.8」トナリ、ディジタル表現ではMSBか反転してとんでもないノイズとなるが、PureDataでは内部的に「-1から+1までの実数値」にクリップするようにして出力するという。 時間軸方向のサンプリングは、特に指定しなければCDと同じ44.1KHzである。 電機業界がもっと高いサンプリング周波数を「高性能」と謳って、なんとかオーディオ機器を差別化して売ろうとしているが、さすが専門家はそんな無意味なところには影響されないのである(^_^;)。 PureDataは外部サウンドファイルの読み込みや書き出しでは、16ビットとか24ビットの固定小数点データに変換して処理することで、「WAV」・「AIFF」・「AU」のサウンドファイルフォーマットに対応している。 MP3は記述が無い。 関係するオブジェクトは「soundfiler, readsf, and writesf」だという。

次は「2.4.2. tilde objects and audio connections」である。 これはMaxと同じで、サウンドを扱うオブジェクトにはチルダ「~」が付く、というやつである。 Maxでは「cycle~」がもっとも基本的なサイン波形のユニットジェネレータだが、どうもPureDataでは「osc~」らしい(^_^;)。 オシレータというだけでは波形は不明なのだが仕方ない。 チルダ付きのオブジェクトは「オーディオON」にしないと動かないのもMaxと同様である。 オーディオ処理のブロックサイズはサンプリング44.1KHzで64ブロックなので、1.45ミリ秒ごとに内部的に演算処理されることになる。

オブジェクト同士を結線していてPureDataでエラーが出るのは、「オーディオ出力」のアウトレットを「非オーディオ入力」のインレットに繋いだ時だけだという。 一般的にオーディオ関係のオブジェクトの左端の第一インレットはオーディオと普通のメッセージ(bangを含む)の両方を入力できるが、それ以外のインレットはどちらか一方だけを入力できるようになっているという。 ここもまぁ、Maxとほぼ同じだろう。

Maxではエラーとなったメッセージの無限ループがPureDataでは一種のdelayとしてOKだったが、PureDataのオーディオについては、まぁ当然だが「無限ループ」は禁止である。 ここはユーザの責任で気をつけてね、との事である(^_^;)。 サブパッチをオーディオに対応させるためには、「nlet~」と「outlet~」を使えばいい。

次は「2.4.3. converting audio to and from messages」である。 オーディオとメッセージを相互に変換する、という話題である。 これはMaxではけっこうトリッキーで、サウンドレベルであれば、よくあるのはオーディオメータのレベル出力を使うというのだが、これは内部的には相当な遅延のある「積分」処理なので、本質的にはあまり使いたくない簡易的な方法なのだ。 PureDataでは「sig~」オブジェクトが数値をシグナル(オーディオ情報)に変換してくれるという。 同様に、「+~, -~, *~, /~, osc~, and phasor~」オブジェクトもコントロール情報とシグナル(オーディオ)情報の両方の入力に対応しているという。

この逆に、シグナル(オーディオ)をコントロール(数値メッセージ)に変換するには、PureDataではその変換のサンプリングレートを考慮する必要がある。 「snapshot~」と「tabwrite~」があるが、チルダの無い「tabread」と「tabread4」というのもあるらしい。 エンベロープフォロワとしては定番の「env~」があるという。 まぁ、ここらは後で実際にサンプルパッチを動かして確認していくことにしよう。

次は「2.4.4. switching and blocking」である。 「switch~」はオーディオシグナルをON/OFFする。 「block~」はディジタル信号処理のブロックサイズを変更/設定するらしいが、これは僕はMax/MSPでは使ったことがない。 「switch~」と「block~」についてはちょっと特殊で、パッチ全体のどこかでこれが使われていると、ネスティングとかサブパッチで他にもこのオブジェクトがあっても、稼働した1個に全てが影響されるらしい。

ブロックサイズを64より大きくすると、リアルタイム処理の効率をわずかに向上させる。 「fft~」などでは、ブロックサイズを「FFT channels」にするのが一般的である。 一部のユーザは実験的にブロックサイズを1として. 再帰的フィルタ(recursive filter)を構成しているらしいが、良い子は真似しないほうがいいかもしれない。

Max/MSPと同様に、「switch~」はオーディオのON/OFFだけでなく、二つ以上のオーディオ処理に分岐する制御(スイッチング)ができる。 レベルをゼロに制御していないオーディオシグナルがスイッチでONされれば、アナログの世界と同じように「ブチッ」というクリックノイズが出るので注意してね、というのもまぁ当然である。 学生のパッチはここに無頓着だが、さすがに実際にライブComputer Musicコンサートをする我々は、もちろんこの「ブチッ」「プチッ」ノイズは厳禁である。 サブパッチのシグナル入出力をいちいちスイッチングしても、どうせ信号としてゼロが出続けるので、内部に「throw~」を設けて、外部に「catch~」を使うのがお奨めである。

そしてサウンド処理の最後は「2.4.5. nonlocal signal connections」である。 階層的なパッチの相互でシグナルをやりとりするために、以下のようなオブジェクトのペアがある。

「throw~/catch~」は複数のエレメントのサウンドの総和をまとめる「バス」に使えて、あちこちから「throw~」に出したオーディオをまとめて(加算累算する)「catch~」で受けるミキサーが出来る。 「send~/receive~」はMax/MSPと同様に、基本的には相手とペアで指定するのが望ましい。 ただしMax/MSPの「send~/receive~」は単純ミキサーとして使える(^_^;)。 「throw~/catch~」や「send~/receive~」を使う時に、それぞれのパッチ内で異なるブロックサイズにしてはイケナイというのは、まぁ当然である。

オーディオ処理は前述のように44.1KHzサンプリングであれば1.45 msecごとに計算して、次のタイムスロットでまとめて出力が反映される。 「delwrite~/delread~」はこのdelayを考慮して、その整数倍のdelayを指定するらしい。 トリッキーに使えば、これで「櫛型フィルタ」などのレゾナンス/フランジングが簡単に出来てしまうが、なんか生成と消滅の段取りが面倒らしい。(^_^;)

ここで朝07:30になったので1階のレストランに移動して朝食である。 去年と同じホテルだが、このレストランは改築されておニューである(^_^)。 昨日はかなり食べたが、ISPS2013のランチの量が半端なく、今日はバンケットもあるので、朝は野菜(トマトとパプリカとキュウリ?ズッキーニ?)と茹で卵とフルーツヨーグルトだけにした。 今日のポスターのインストラクションのメイルを発掘してみると以下のようだった。

Posters
Posters will be displayed on Friday, 30 August. One hour has been set aside 
specifically for delegates to view posters, during which time no other sessions 
will take place. Presenters are required to be by their posters to answer 
questions. Posters will also be available for viewing during refreshment and 
lunch breaks on 30 August and should be removed by 17:00 that day.

Set-up
Posters should be set-up in the designated display area during the Registration 
period (08:30-09:00) on Friday, 30 August. 15-20 minutes should be allowed 
for this.
要するに、これから朝08:30-09:00に好きなところに場所取りしてポスターを掲示して、午前のポスターセッションの1時間はそこで待機して質疑に対応して、ランチの時間までは掲示しておいて、その後17時までに撤去せよ、という事か。 まぁいつものパターンである。 荷物になるので、貼ったポスターは潔く捨ててくる予定である。

・・・そしてここはmdwのハイドン・ホール、ISPS2013の3日目の朝イチのKeynoteである。 ホテルを08:10に出てちょうどピッタリ08:30に会場に到着し、ちょうど20分かけて予定通りに8枚のA3ポスターをパネルに貼って、時間までにKeynote会場に着席する、というのは、逃れることの出来ない、なかなかにA型人間である(^_^;)。

KeynoteはAlan M. Wing氏(University of Birmingham)の「Follow my leader? String quartet synchronization」ということで、弦楽四重奏の演奏家の同期とか相互作用についての研究の概要紹介である。 1人の音楽家(リーダー)はantispationで音楽を駆動する、2人目以降の音楽家はreactionでそこに反応しつつ同期する、という視点はおおいに賛同できる。 ただし会場がハイドンホールだからというのか、対象曲がハイドンというのはどうかなー、という気もする。 モーツァルトとかベートーベンだとちょっと違ってくると思うのは僕だけなのだろうか。

第一の実験では。曲のスタートを身振りで指示する第一バイオリン奏者の身体に多数のマーカを付けてモーションキャプチャで動作を抽出すると、今度はスケルトン(骸骨)のCGにその身振りを再現させて、そのCGスクリーンを見て他の3人がちゃんと曲をスタートさせるかを調べる、というところが面白いと思った。 これにより、音楽をスタートさせる、いわば指揮者の身体表現が抽象的なレベルで抽出できるのである

第二の実験では、千葉大の堀内さんが研究したように、ハイドンのようなほぼコンスタントな音楽において、リーダ以外の音楽家が協調しながらどのようにテンポを揺らしていくか、を調べた。 基礎となるタッピングの調査から、タッピングのテンポの揺らぎには、shart termとlong termの2種類の揺らぎがあると調べた上で、これを加味しつつ、変化のソースとして「タイマー(内部クロック)」と「モーターシステム」があるという図式を提唱した(のが40年前のことだという(^_^;))。

そして「ビートをキープ」するメカニズムをモデルとして構築した。 このあたりは、僕の過去の この研究 とかにも関係してくるかも・・・と注目した。 ただし、線形位相修正モデルというのは、ちょっと単純過ぎて、あまりいただけなかった。 もっとも単純なケースは「N=2」、つまり2人のSynchronisation(同期)のモデルである。 これは指揮者と演奏者、独奏者と伴奏者、デュエット、など色々な基本である。 ここで「Adaptive metronome」というシステムを提唱していたが、まぁ予想通りのものである。

ここで弦楽四重奏のモデルになるが、途端にややこしくなる。 それは当然で、演奏家をA・B・C・Dの4人だとすると、AはBCDの3人とそれぞれ双方向の影響ベクトルを持つので、4人では合計で12本の影響ベクトルを考慮しなけれはいけなくなるのだ(^_^;)。 ハイドンの曲でsimulationをしたという事だが、うーん、なんだかどこか遠くに行っているような気がしないでもない。

ここまでを受けて、実際に人間の演奏家がsimulationと同じように振る舞うかを記録したという。 実験結果を分析して相互作用の行列としてデータ化して、過去の研究と同じような揺らぎを確認したという。 そして分析した結果、第一バイオリン奏者は他の3人と社会的に異なった役割を演じる傾向があるという。 ・・・このあたりでだいぶ理解能力の限界に近づいてきた。 連続1時間、英語を聞く(だけでなく内容を追いかけて考える)というのは、まったく非日常の苦行なのだ。(^_^;)

午前のコーヒーブレークをまたいで、10:30-11:30が、いよいよポスターセッションである。 ここでは持参のパソコンをムービーデモのプレイヤーとして使うこともあり、何も書くことは出来ない。

・・・そして今は13:30、閑散としたセッション会場で、無事にポスター発表を終えてホッとしているところである(^_^)。 次第に判ってきたのは、ISPSはやはり分析系がメインで、ICMCやNIMEと違って生成系はマイナーなのだ。 ただし、ちゃんとstructured abstractの査読を通って採択されての発表なので、決して「場違い」という事はない。 事実、人数は少ないものの、ウイーンの大学でメディアデザインを教えているという若い先生とか、わざわざ論文集で僕のpaperを読み込んで、名指しで僕のポスターまで来てくれた研究者もいた。

ポスターセッションの終了と同時に午前の最後のパラレルセッションがあるので走ったのは、メンデルスゾーン・ホールの「Perception of pitch」というセッションである。 なんせ、 音律の話題ピッチの話題 とでWebに膨大に上げている身である。 ここはなんといってもチェックしなければ。 一緒にポスター発表していた、京都市立芸大の津崎先生もちゃんとこのセッションに来ていた。

しかしこのセッションについては、まったくパソコンを叩くどころか開く余裕もなく、ひたすら聞きつつプレゼンの写真を撮るという1時間になった。 発表は「Intervals as distances, not ratios: Evidence from tuning and intonation」というタイトルと、「Does practice affect timbre- induced pitch shift?」というタイトルである。 後日、その写真を見ながら論文を読みながら、じっくり再検討する必要がありそうである。 そして、他の2会場は3件の発表で90分のところ、このピッチの会場だけは2件だったので、30分早く終了して、カフェテリアで早めに昼食を済ませて、そしてここまでをまとめるために、まだあと1時間あるセッション会場に来た、というわけである。 日本時間は金曜日の夕方から夜になり、来週までお仕事関係のメイルはストップするし、音楽情報科学研究会の100回研究会もいよいよ明日からということで運営委員のメイルも静かになってきた。

・・・そして14:30、メンデルスゾーン・ホールでのセッションは「SYMPOSIUM : Timing and dynamics in Mande ensemble drumming: Metric well-formedness and perception-action coupling」ということで、一転してワールドミュージックである(^_^)。 西アフリカのマリ周辺のMande民族の音楽、特にリズムに注目したフィールドワーク研究である。 発表は共同研究者が交互に著者となって、「Mande ensemble drumming: An introduction to Ngon」と「Microtiming in Ngon: Categorical production and perception of a non-isochronous meter」であり、マイクロタイミングとか非等分の拍節とか、とにかくソソラレル。 やはりリズムとかビートはアフリカだ、というのを改めて感じさせられた。

どちらかといえば「見て聞くだけ」というセッション(午後の後半はしんどくなってきたので早退予定(^_^;))の合間に、またまたPureDataの内職も続けてみた。 サウンドに続くトピックは「2.5. scheduling」である。 PureDataでは「時間」を表現する数値は64ビットの浮動小数点データであり、サンプルレートをカバーして、決してオーバーフローしないようになっている。 ユーザに対して提供される「時間」はミリ秒を単位としている。

そして「2.5.1. audio and messages」である。 既に紹介したように、defaultのPureDataのオーディオ処理は64サンプルを44.1KHzのサンプルレートで、つまり1.45ミリ秒ごとに扱う。 この処理は「pd」というオブジェクトに「dsp 1」と「dsp 0」というメッセージを送ることでON/OFFされる。 MIDI入力とかマウスのクリックなどのイベントによって、それらの遅延をカウントすることでインターバル(時間的間隔)の処理が可能になる。 その指導原理は「depth-first message passing」だというが詳細不明である(^_^;)。

次は「2.5.2. computation load」である。 PureDataはリアルタイム処理を確保するために「audiobuffer」とか「frags」とかを用意しているというが、その説明は後であるらしい。 もしPureDataの処理が遅れてくると、入力と出力の間に「gap」が生まれる。 ディスクから連続的にサウンドファイルを読み出すような処理のためには「-nogui」とか「-send」とかがあるらしいが詳細不明である(^_^;)。

PureDataのリアルタイム性はCPU時間とGUI処理に影響される。 PureDataでトラブルを避けるためには、リアルタイムサウンド処理をしている時にはなるべくGUIを使わないでね、という事である。 サブウインドウを閉じておくと不要なGUI処理を減らすことが出来るが、お奨めは使わないなら閉じるのでなく消すことだという。

次は「2.5.3. determinism」である。 要するにどんなコンピュータシステムでも当たり前なのだが、PureDataでも時間的な処理は、それぞれのイベントをシステム(OS)のタイマー値を参照してその差としてインターバルを定義している、というような事らしい。 ここはちょっと眠たい頭ではテキトーである(^_^;)。

そして次のトピックは「2.6. semantics」である。 なんか面倒くさくなってきたが、ここではPureDataにおいてオブジェクトを記述する意味、オブジェクトがデータを蓄積する意味、オブジェクトなどがメッセージをやりとりする意味、を論じるという。 けっこう当たり前のことを当たり前に説明するような予感がある。

まず「2.6.1. creation of objects」である。 以下の記述を眺めると、あまりに当たり前で翻訳する気にもならないのだが。(^_^;)

The text in a box has a different function depending on whether it is a message, 
atom (number/symbol), or object box. In message boxes the text specifies the 
message or messages it will send as output. In atom boxes the text changes at 
run time to show the state of the box, which is either a number or a symbol.

In an object box, as in a message box, the text specifies a message; but here 
the message is to be passed to Pd itself, once, and the message's effect is to 
create the object in question. When you open a file, all the objects created are 
created using their text as "creation messages." If you type a new message into 
an object box (or change it), the old object is destroyed and the message is used 
to create the new one.

The selector of the message (the first word in the message) is a selector which 
Pd interprets to mean which type of object to create. Any message arguments 
(called "creation arguments") are used to parameterize the object being created. 
Thus in "makenote 64 250" the selector "makenote" determines the class of 
object to create and the creation arguments 64 and 250 become the initial 
velocity and duration.
次は「2.6.2. persistence of data」である。 これはMaxと同じことだが、パッチ内のオブジェクトの数値(パラメータ)は初期値(printable)でしかなくて、右インレットなどから新しい値が与えられると、もう外見の数値とは違う値になってしまう。 これはMax/PureData初心者が必ず当惑するところである。 例外はサブパッチだというが詳細不明である(^_^;)。

・・・ここで2人の発表が終わり、残り30分はduscussionだ、というところで退室して、ISPS2013会場のmdwを後にした。 明日はもう来ないので、これでmdwとはお別れである。 U4に乗っていったんホテルに帰ってきたのが16時、日本時間はもう23時で、金曜日もオシマイである。 ここで仮眠すると絶対に寝過ごすので(^_^;)、我慢してまずはここまでをWebに上げた。 デジカメはまだ今夜のバンケットまで撮りたいので、Webに上げるのは明日あたりである。

2013年8月31日(土)

ウイーン4日目、ハンガリーのブダペストに移動する日となった。 いま朝6時過ぎ、日本は13時過ぎなので、ちょうど音楽情報科学研究会100回研究会がスタートした頃である。 昨夜は、

というような招待状を持っていないと建物の入口でガードマンに制止される、


ウイーン市庁舎

でのISPS2013バンケット(レセプション)に参加して、24時までの予定を23時で切り上げてホテルに戻り、多数の写真を編集して 帰国後に公開予定のWeb に上げて、寝たのは結局、25時あたりであった。

そして午前3時頃にちょっと目覚めてまた寝て朝05:30頃に起床、シャワーを浴びて荷物をパッキングしてあれこれしたところである。 日本からは台風とか大雨とかまた猛暑、というニュースが届くが、ちょっと曇って肌寒い(ちょうど快適)ウイーンと、午後に到着するブダペストの天気は以下のようであり、まだまだ快適な旅の模様でラッキーだ。

2ちゃんの 事件 の方は、ぼちぼち芸能系の新スレとかが立ってきたが、まだニュースヘッドラインの下半分にゴミが残っていて駆逐されていない。 通常は1日あたりで全て書き替わるものが数日たっても残っているというのは異常事態であり、個人情報が流出して相当数のアクティブな「書き手」(オタク・ステマ企業・政治的な連中)が去ったという事を示している。 インターネットの常で別に無くなっても困らないのはmixiでも2ちゃんでも同じだが(やっていないのでツイッターやフェイスブックも同様)、保存している関連ログが、plain textだけなのに既に40MBというのも記録的である。(^_^;) 

・・・ここで朝食のためカフェテリアに移動、野菜とヨーグルトの朝食後、コーヒーでくつろぎつつ書いている。 ホテル全館に、パスワードをかけていない(^_^;)WiFiが飛んでいるので快適なのだが、これはISPS2013のmdwでも同様で、いい時代になったものである。 かつては各国仕様のモデム変換コネクタを持参して、ホテルの部屋の電話機に繋ぎ、日本で契約してきた海外ローミング接続サービスのアクセスポイントまで電話(ダイヤルアップ)して接続、ネットしていたが、スピードはおよそ現在の1000分の1ぐらいだった。 リンツのホテルから市外通話でウイーンのアクセスポイントに繋いでいたのも、まだ数年前のことなのだ。

去年の 欧州ツアー2012 で、ウイーンからスロベニアのリュブリャナに行った数時間の鉄道旅の経験から、同じホテルに泊まり、同じ「Vienna Meidling railway station」で出発するので、今年はとても楽である。 去年はMeidling駅に前日に下見に行ったりしたが、 こんなマップ もあり、1時間前あたりに行けば余裕である。

ここまでまだ、「地球の歩き方」のブダペストのページはまったく読んでいない(^_^;)。 せっかくの鉄道旅の車中で風景を見ずに読むのもナンなので、ちょっとだけ早めにMeidling駅に行って、列車を待つテンションで読むことにした。 ウイーンからブダペストは比較的あっさりと(3時間程度で)行けるので、いったんホテルに荷物を預けて、とりあえず市内に出てみる予定である。 そこから先はno idea、行き当たりばったりに散策することにしよう。 PureDataのお勉強がどうなるかも、まったくの未定である。(^_^;)

2013年9月1日(日)

ブダペスト2日目の朝、シャワーを浴びてスッキリして、ホテル1階のレストランで朝食後のコーヒーとともに、朝8時過ぎである。 日本は15時、ちょうど音楽情報科学研究会100回研究会の、後藤さんがプロデュースしたメイン企画が佳境の時間帯で、何も運営委員MLのメイルが飛んでこない(^_^)。

ちょうど昨日の日記の記述からマル24時間以上たったが、昨日はなかなかに、濃かった。 昨夜は23時過ぎにホテルに戻り、多数の写真を編集して 帰国後に公開予定のWeb に上げて、寝たのは結局、24時あたりであった。 夜中の2時頃にちょっと目覚めてまた寝たら、起床は朝6時頃であり、まだ昼間に眠いもののようやくぼちぼち現地時間に慣れてきたようだ。 ただし、昨日はたくさん歩いたこともあり、身体の節々に疲れが残っている。 昨日は素晴らしい好天のブダペストだったが、今日の天気と明日の天気は以下のようで、一応、折り畳み傘を持っていくものの、明日にプラハに向かって旅立つまで、雨とかの心配は不要のようでラッキーである。(^_^)

2ちゃんの 事件 の方は、どうやら終了したらしい。 「解決」でなく「終了」ということで過ぎ去り、何事もなかったようにニュースヘッドラインが多数のスレで埋まっていた。 ただし「糞スレ」が異常に少なく、ちょっと気持ち悪いような健全さである。 どれだけ、個人情報が漏れた連中が糞スレを量産していたかが判る。 こうなるともう、運営板のログを記録する意味もなく、ブックマークも消して記録作業も終了である。 ただし、後でログを読むほどの暇があるかは不明だ。

昨日はISPS2013のようにパソコンを持参していない「観光」なので、PureDataについてはまったく進展が無かった。 おそらく今日もそうなりそうである(^_^;)。 去年の 欧州ツアー2012 で、ウイーンからスロベニアのリュブリャナに行った鉄道旅に味をしめて、今年はウイーンからここブダペストへ、さらにチェコへ、そして最後にリンツへ、と3本の鉄道旅で繋ぐ「4都物語」である(^_^)。 ウイーン→ブダペストは3時間弱と短いので2nd classの指定席を取ったが、さすがバカンスの季節、車内はほぼ満員だった。

出発を待つMeidling駅と車内で「地球の歩き方」を初めて読んで予習してみると、ブダペストとは過去に「ブダ」地域と「ペスト」地域があったのが合体して大都市になったのだそうだ。 そして王宮とか、音楽史博物館、王宮地下迷路、くさり橋、コダーイ博物館(休館を確認済)、交通博物館、ドナウ川ナイトクルーズ、現代美術館、(マジャール)民族博物館、多数の「温泉」、国立歌劇場ガイドツアー、蚤の市(エチェリ)、などの「行きたい候補」をチェックして、マップにマーキングした。

ブダペスト東駅に13時に到着してみると、上のように芋を洗うような人混みだった。 ここでラッキーだと確認したのが、今回の鉄道のチケットをネット購入する際に、全てチケット現物を事前にチェコから国際宅急便で送ってもらっていた事である。 ネット予約だけだと、その記録プリントアウトを駅のチケット窓口に持参して交換に切符を購入するのだが、このブダペスト東駅の国際列車切符売り場は長蛇の列となっていた。 事前送付の手数料はかかったが、あそこに立って並んで時間と体力を消耗する事が無かった、というのはラッキーなのだ。

過去に行った、パリとかロンドンとかアムステルダムとかコペンハーゲンとかバルセロナとかベルリンとかウイーンとかリンツとか(いずれも ここ に記録がある)のヨーロッパの有名な観光都市は、そこを歩き倒す上で、僕の中では大きく2種類に分かれる。 そこそこ「こぢんまり」と小さくて、調子が良ければ散策/踏破できるぐらいのスケールの都市と、けっこうデカくて、公共交通機関での移動でピンポイントを繋ぐ必要がある(歩いては行けない)スケールの都市、とである。 もちろん今回も「ブダペストカード」をまずホテルで買ったように、市内の公共交通機関が48時間とか72時間とかフリーになるチケットは入手するのだが、それでも「歩き方」はだいぶ変わってくる。

そして、「地球の歩き方」でブダペストを予習した時には、けっこうコンパクトに小さいので、バルセロナとかコペンハーゲンとかリンツのように、マークした観光名所をあちこち行き倒せるんじゃないか・・・と予想していたが、これは大きな間違いだった(^_^;)。 ブダペストは想像以上に、でかかった。 上はブダペストのメトロに降りて行くエスカレータで、メトロは相当な大深度地下鉄だった。 そしてこのメトロで移動しないといけないほど、地図のイメージ以上に、それぞれのポイントは離れている、つまり大きな大きな都市だったのだ。

「ブダペストカード」とともに、ホテルでドナウ川のナイトクルーズのチケットを買ったので、まずはcity centerの界隈に行って、その船着き場の場所を確認して、そこから王宮とかあちこちに行こう・・・とスタートしたのだが、東駅に至近のホテルからのんびり歩いて行こうと思った構想は、マップの1ブロックを歩いただけで破綻した。 そして東駅に戻り、メトロの入口を捜してcity centerの駅まで行って地上に出てみると。、上のように多数の人がのんびりとカフェで一杯やっているのだが、マップ上でcity centerから目と鼻の先にあると思っていたドナウ川の船着き場までも10分ぐらいかかった。 つまりは、スケールが予想と違って大きいので、そんなにあちこち行けないのである。

ここでは詳細は書かないが、16時あたりになって空腹を覚えて(昼食をとっていなかった(^_^;))、散策していた公園の屋台で軽食とビールをいただいてると、その一角のステージでライブ演奏している2人組がいて、これがなかなかに上手くて、さらにワイン2杯とともに2時間ほど、ここで楽しんだ。 その後、ゼミの学生へのお土産など仕入れて、もう19時を過ぎたので、ナイトクルーズの船着き場に向かった。 帰国後に公開予定のWeb にいろいろと写真があるが、つまりブダペスト初日の昨日は、これだけで終わったのである。 頑張ってあちこちの観光名所の「数」を稼ぐ、というのと真逆に、素晴らしい陽射し(ただし湿度が低くて清々しい)とのんびりした時間を堪能したが、これぞまさにヨーロッパのバカンスなのだ。(^_^)

部屋に戻ってここまで書いてWebに上げて、ようやく9時半である。 観光地はぼちぼちスタートするが、いの一番に慌てて行くこともなく、今日はどうするかは、またぼちぼち歩きながら考えよう。 せっかくのPureData日記がまったくストップしているのも癪なので、ちょっとだけでも、残りを整理して進めておく事にした。 次の「Pd Documentation」のトピックは「2.6.3. message passing」である。 既に述べたように、PureDataのメッセージは「セレクタ」(シンボル)、つまりそのオブジェクトの機能をあらわす「名前」と、それに続く、ゼロ以上の「arguments (which may be symbols or numbers)」からなる。 オブジェクトにメッセージが与えられると、PureDataはまず「セレクタ」を解釈して、対応した処理を行って必要な情報を出力する。 「atom boxes (number or symbol)」では、この処理とともに自分の値を変化させる。 つまりナンバーboxであれば、入力された数値をそのまま出力するとともに、自分自身の現在地を入力された値へと更新して表示する。

オブジェクトはたくさんの種類があるので、PureDataが処理するclassもたくさんある。 例えば「float」というオブジェクトは、入力として数値あるいはbangを受け入れ、入力数値をfloatに変換して保持し、左インレット(ホット・インレット)からbangが来ると出力する。 このように、それぞれのオブジェクトの振る舞いをPureDataは記述して持っているので、オープンソースとして公開されているAPIを使えば、オリジナルのオブジェクトを開発して拡張することも出来るという事なのだろう。

たった1項目だが「PureData日記」も進めたので、ここで身支度して、10時前にホテルを出発することにした。 帰ってくるのはたぶん数時間後、この間にどれだけあちこち行くか、ではなくて、どれだけブダペストそのものを楽しむか、というのを目標にしよう。(^_^)

・・・そしてホテルに戻ってきたのは17時過ぎ、およそ7時間の市内観光で、おそらく少しは日焼けしたと思う(^_^;)。 昨夜の様子から、ブダペスト観光客の楽しみの半分以上は「夜の部」にあるようなのでやや勿体ないが今日はもうおしまい、明日以降に体力を温存することにした。 1時間以上かけて、これまで1日あたり最多の700枚弱の写真を編集(回転・ピンボケ除去・JPEG再圧縮)して全て 帰国後に公開予定のWeb に上げた。 詳細はここに書かないのでそちらを参照して想像して欲しい。

3枚だけ紹介すると、以下のいちばん上は、王宮の丘にあるハンガリー音楽史博物館である。音楽の可能性をさまざまな楽器の創造によって開拓しようとしてきた、マジャール民族の音楽への執念のようなものを感じて、なるほどこの国だからこそのバルトーク、コダーイ、リストなのだと納得した。 楽器のデザインに関してちょっと刺激を受けたので、後期のゼミではM1のリュ君、3回生の森川さん/土佐谷さんと一緒に考えていく事にしよう。 以下のまん中は、ドナウ川のボートクルーズ船内から撮ったもので、バスが沈没しているのではなくて(^_^;)、陸上からそのまま川にザブンと乗り入れるのが売りの観光バスらしい。 もう1枚はホテルに帰ってきたらベッドの枕の上にあったもので、ハンガリーではチップが珍しいのか、こんな御礼が書かれていて、ちょっと萌えたのだった。(^_^)

昨日は遅くて閉店直後だったのだが、ホテルから徒歩数分の、ブダペスト東駅のすぐ近くに、世界中どこにでもある、チャイニーズのデリ(ファストフード屋)があるのを見逃さなかった僕は、city centerからメトロで東駅に戻ってきたところでここを覗くと、さすがチャイニーズ、日曜でもやっていた。 そして、焼きそばとビールを今夜の夕食にと仕入れて帰ってきたのである、 ウイーンで残って持ってきたワインがボトル半分ほど、あと昨夜のビールのつまみのポテチが半袋ほどあるので、あとはホテルの部屋でこれをちびちびやりつつ、同時に数試合をあちこちのチャンネルで生放送しているサッカーでも楽しむ予定である(テレビのCNNとBBCのニュースで、珍しく日本の情報が届いているが、シリアのサリンと東電の放射能はともにテロという扱いなのかも)。 もし夜中に目覚めて時間が余ったら、PureDataの続きをするかもしれないが、一応、今日はここまで、明日はチェコ行きである。

2013年9月2日(月)

ブダペスト3日目の朝、朝食前の朝6時過ぎである。 昨夜はやや飲み過ぎたが(^_^;)、朝5時前までぐっすり眠れた。 昨日の晩に上げていた 帰国後に公開予定のWeb を軽くチェックして、いよいよ今日はチェコのプラハまでの大移動の日である。

日本は月曜日の13時過ぎ、たしか音楽情報科学研究会の100回研究会の最終日であり、京産大の平井さんがプロデュースした企画で、Maxの作者David Ziccarelliも来日して講演している筈である。 Davidには Sketching2013 の時に、せっかく来日してくれているのに、その時期はヨーロッバに行っているので会えなくてごめんね、と話してある。 上のように、日本の天気はほぼ全国的に雨模様なのに東京だけ晴れ(^_^;)、そして新しい台風も登場したようである。

ここまで折り畳み傘を開くこともなく、快晴に低湿度、という快適な気候を堪能してきたが、調べてみると上のように、プラハの天気は今日と明日は雨模様の予報である。 ウイーンに比べて南に位置するブダペストから、去年 欧州ツアー2012 でウイーンから1日観光で行ったスロバキアのブラチスラバを経て、今日の鉄道旅は相当に「北」に向かう。 以下のように、最終日のフランクフルトとともに、今回の訪問地でもっとも北になるので、上着が必要かもしれない。

プラハまでの「乗り鉄」はたしか7時間ぐらいあったので、ここまで一度も開いていない「地球の歩き方」の「プラハ」は車中で読めばいいだろう。 出発時刻を確認するのに、YAHOO.COMで「train budapest prague」と入れると、あっさりと 列車一覧 が見つかり、「EC 170 Hungaria 09:25 16:21」の7時間の旅と判った。 ホテルは東駅の目の前なので(わざわざ捜して予約した)、09:25の列車なら09:15に出ても間に合うが、まぁたぶん9時あたりには駅に向かうだろう。 上のページの「EC 170 Hungaria」をクリックすると 時刻表 があり、2時間ほどで既に行ったことのあるブラチスラバに行き、プラハからさらに5時間で、ドレスデンを経由してベルリンまで行く(12時間で1000Km)長旅列車なのだった。(^_^)

ここで1階レストランで朝食、食後のコーヒーとともにパソコンを開くと、週明けの月曜日の午後ということで、お仕事関係のメイルが動きだし、SUAC事務局からは、今年の科研費の公募が正式に来たので準備してね、というメイルが届いた。 あれこれ膨大で煩雑なので、これは帰国後に対応することにしよう。 さらに、音楽情報科学研究会は佳境らしく、以下のような情報をツイートして、というような運営委員メイルが届いた。 まぁ順調のようだし、Davidの講演も同時通訳が付くのはいいことだ。(^_^)

David Zicarelli氏の講演では左(英語), 右(通訳日本語)チャンネルにて
お送りします. 通訳だけ,英語だけをお聞きになりたい場合は, ご自身のPCの
LR設定を調整いただくようおねがいいたします.
*ニコ生では英語と日本語がMIXされた状態にて配信しています
そして部屋に戻って荷物をパッキング、出発まであと1時間ほどあるので、ここで恒例のPureDataお勉強を遅々として進めておくことにした。 「Pd Documentation」の「2. theory of operation」の「2.6 semantics」の「2.6.4. inlets and lists」からである。 PureDataのオブジェクトにはインレットがあり、特に重要なのは左端のホットinletである。PureDataには4種類のinletクラスがある(とあるがどういう4つなのか書かれていない(^_^;))。 このinletクラスは、入力されたメッセージがシンボルなのか、浮動小数点数値なのか、その他なのか、に応じて処理を行う。 「リスト」メッセージだけは、複数の要素を(半角スペースで区切って)まとめて扱うので、通常のメッセージと異なって解釈する。 まぁ、ここらはMaxと同じことなのでどんどんスルーしていこう。

次は「2.6.5. dollar signs」であるが、これはMaxで見かけるものと同じかどうか、チェックが必要かもしれない。 PureDataでは、メッセージやオブジェクトboxで、「$」記号と整数の組み合わせ、例えば「$1」とか「$3-bazoo」などは特別な扱いとなるので注意が必要である。 要するにMaxの「if」オブジェクトなどと同じように、入力されるメッセージに対応してその後の処理を関連づけられるのである。 Maxでこんなことが可能かやった事が無かったが、PureDataでは例えば、「$2 until $1」と設定されたメッセージボックスに「23 skidoo」というメッセージが入力されると、出力メッセージは「skidoo until 23」となるという。 これは便利だが、うーん、Maxでもあったような気がしてきた(^_^;)。

PureDataではパッチが呼ばれた時に、「$」があると、そこにメッセージが入ることを想定してメモリを割り当てて待機するらしい。 Maxでは記憶が無いが、PureDataの$1-x」というのはストリング処理のためのものらしい。 「$0-x」は内部的にローカル変数として使われる。 「$」はメッセージを構成するアトムの先頭にないといけないので、「rats-$1」は暖かく無視される。 ・・・と判ったように書いてきたが、以下のexampleは、判るようでよく判らないのだった。 まぁ、こういうのはMaxの「zl」ファミリが得意なので、PureDataではあまり深入りしないで行こう(^_^;)。

For example, if you want to get dog-food, dog-ears, and cat-food, 
for example, have an abstraction "a1" that invokes an abstraction 
"a2" twice, as "a2 $1-food" and "a2 $1-ears", and then in a third 
patch call a1 twice, as "a1 cat" and "a1 dog". Inside the four "a2" 
copioes, $1 will evaluate to "dog-food", "cat-food", "dog-ears", 
and "cat-ears". 
次は「2.7. subpatches」である。 これはMaxでもPureDataでも必須の階層化・構造化の基礎なので、重要なところだ。 PureDataではサブパッチのメカニズムとして、「one-off subpatches」と「abstractions」の2種類を提供しているという(後者は次のトピック)。 まず、Maxでは「patcher」あるいは「p」に名前を付けるサブバッチが「one-off subpatches」のようで、PureDataでは「pd」あるいは「pd my-name」という形式で、以下のようにサブパッチが展開されるという。

Maxと同様に、サブパッチは親パッチとともに保存される。 初心者にはちょっと悩ましいが、同じ名前のサブパッチを複数個コピーして、外見上は同じ名前でもそれらの中身を個別に変更することができる。 サブパッチの中で、親バッチなど外部のパッチとの接点となるオブジェクトは、入力/出力、コントロール/サウンド、という組み合わせに対応して、以下の4つである。

「outlet~」をサウンドのミキサーとして使うのは禁止で、あくまで一対一の接続に使う事。 Maxと同じであるが、サブパッチに上の4種類のオブジェクトを複数個、定義すると、オブジェクトの箱にはちゃんと並んでくれる。

そして次が「2.7.1. abstractions 」ということで、PureDataの第二のサブパッチのメカニズムの「abstractions」(抽象化)である。 これはMaxでは無かったような気がする。 どうやら、予約語として定義されていない(ぶつからないように自由に定義できる)名前だけのオブジェクトは、PureDataでは「その名前.pd」というパッチとして保存され、これが「abstractions」サプパッチなのだという。 例えば以下の上のようにPureDataパッチで表現されていると、「abstraction1」というのは予約語ではないのでサプパッチとしてabstraction1.pdという下のようなパッチを記述することができるらしい。

この例は、Maxのように「右から左」というルールが無いPureDataでわざわざ定義したものだが、まぁこれも便利である。 また、この「abstractions」サブパッチに定義するオブジェクトには、半角スペースで区切って定数を置けるという。 その定数は「$」で指定して取り出せるので、初期値ということである。 例えば「my-abstraction 5」というオブジェクトは名前が予約語に無いのでサブパッチであり、$1が5である。 これはつまり、任意のオブジェクトをサブパッチとして定義できるというか、サブパッチをオブジェクト的にカスタマイズするシステムということだ。 これはさすがである。

これに相当する「Max (both Opcode and Ircam)」は「#」だという。 ただし、たぶん使ったことが無いのか、記憶に無い。 とりあえず以下の記述をここに残しておこう。 ここで9時が近づき、チェックアウトしてプラハに旅立つことにした。

The corresponding feature in Max (both Opcode and Ircam) was the "#1" 
construct. In a Max abstraction, "#1", etc., are replaced by the creation 
argument. This has the disadvantage that you can't edit the abstraction 
as instantiated in the patch since the "#" variables are substituted. In Pd 
the "$" variables in object boxes are spelled literally as "$" variables so 
that it's meaningful to edit them from within their calling patch. On the 
Pd side, however, there is the disadvantage that it's confusing to have 
"$" expanded at a different time in an object box than in a message box. 
In an object box, the "$" argument is expanded at creation time, and in a 
message box, at message time. 
・・・そして12時間半後の21:30、プラハのホテルの部屋である。 これまでのホテルのインターネットが非常に快適だったのに対して、ここプラハはかなり心配な日々となりそうである。 全館にWiFiが飛んでいてパスワードも無い、とのことだったが、晩に旧市街に出かけて戻ってきて接続してみると、WiFiは繋がるもののDNSに繋がらず、これは典型的なホテル端末の発狂である(^_^;)。 フロントに行ってパソコンを見せて、ウイーンでもブダペストでもこのパソコンで快調だったのにこのホテルに来たら途端におかしいのでホテルの問題である、と主張して機器を再起動してもらうと、ようやく正常に繋がった。

ただし、とっっっても遅い。 まるでPHS(エッジ)でダイヤルアップ(これは国内でいまだ現役)しているような速度、体感で64Kbpsとか128Kbpsのスピードである(^_^;)。 今日の写真(360枚)を30分ほどかけて編集して、この裏で 帰国後に公開予定のWeb に上げているのだが、計16MBをアップするのに、1/10の1.6MBだけで15分以上かかっている。 このままFTPを走らせて寝れば、明朝にはアップ出来るのだろうか。(^_^;)

去年の 欧州ツアー2012 での、ウイーンからリュブリャナまでの鉄道旅は、同じ6-7時間とはいえ、考えてみればスピードがまるっきり違うのだった。 山間部や渓谷をゆっくり乗り越えていった去年に比べて、延々と直線の線路で120Km/h以上ですっとばすこちらの特急では、なかなか沿線の風景がうまく撮れなかった。 人間の動体視力だとちゃんと見えるのに、である。 しかし一方で、なんだかモゾモゾと遅れて、最終的には25分遅れとなった(^_^;)。

小雨がパラつく中、とりあえず旧市街に少しだけ行ってみたものの、まったく方向感覚がどこかに行ってしまう魔境、巨大迷路だった。 スロバキアのブラチスラバの旧市街もこんな感じだったが、より巨大である。 そしてブダペストと違って、プラハには町中に微妙なアップダウンがあり、歩き回ると疲れそうである。 その一方で、メトロの駅の間隔がかなり近いのと、トラムがあちこち走っている(まだマップをゲットしていないので詳細不明)ので、体感としてはあちこち行きまくりやすい都市、という印象である。

このあたりを含めて、プラハは明日と明後日と、あとマルマル2日あるので、ぼちぼちじっくりと巡ってみたい。 川を挟んで東側に旧市街、西側に王宮/王城、というおよその構造も、スケールがプラハの方がちょっと小さいものの、どことなく似ている。 ブダペストのドナウ川でなくプラハはモルダウ川であり、ブダペストがリストならプラハはドボルザークなのだ。(^_^)

2013年9月3日(火)

プラハ2日目、火曜日ということは確か出発日が火曜日だったので、今回の欧州ツアーのちょうど中間点を過ぎたところである(帰国日は来週の月曜日)。 部屋は広いがネットWiFiが貧弱なホテルなので(^_^;)、結局、朝4時に目覚めてみるとWebに上げていたFTPはfailしていて、いちいち手作業で転送エラーした数十枚の写真をFTPする手間となったが、1時間ほどでようやく昨日のところまでWebに上げて、この日記も昨日の分までアップ完了した。

せっかくなので昨日の写真からちょっとだけ振り返ると、上は朝9時の出発するブダペスト東駅、その下が17時に到着したプラハ中央駅、いちばん下が、夕方に彷徨った旧市街で、小雨なのにたくさんの人で混み合っていた。 天気予報だとプラハの降水確率はずっと90%あたりが続きそうだが、日本と違って湿度が低く、折り畳み傘を開いたり閉じたりしてそこそこ過ごせそうである。

今日の午前からは、昨夜、すでに予約した「市内観光ツアー6時間」というのが待っている。 その後は、このツアーで土地勘ができたところで、フリー交通券とHOP ON/HOP OFFチケットを活用して、ぼちぼち散策である。 1ヶ月前に見学訪問と意見交換の打診を申し込んでいた、以下の3つのプラハ市内の芸術/デザイン系の大学からは何の音沙汰も無かったので、天気が良ければ覗きに行く可能性を模索したかったが、この天気だと断念しそうである。

朝食を終えて「市内観光ツアー」の送迎バスがホテルに来るまでの2時間半ほど、PureDataお勉強タイムができた。 今日の天気予報は上のようなもので、昨日の予報より少しだけ降水確率が下がっているが、まぁチラッとシャワーがあるのは覚悟の日となりそうだ。 室内のビクター製ブラウン管テレビのCNNニュースでは、日本が竜巻とか台風とか大雨でえらいこっちゃ・・・というのを世界に向けて報道しているなか、本当に申し訳ないほど快適な湿度である。

昨日のブダペストでは「2.7.1. abstractions」まで調べて、PureDataの2種類のサブパッチを知ったところまでだったが、ドキュメントでは次に「2.7.2. Graph-on-parent subpatches」となっていた。 これは「abstractions」のオプションのようなもので、こちらもMaxには無い。

前述の「abstractions」サブパッチは、なんでも予約語でないオブジェクトをサブパッチとして定義できるというものだったが、たくさん作っていくと、それぞれの中身が何なのか、いちいち開けてみないと判らなくなってくる。 そこで上のように、サブパッチ(abstractionでも同じ)のプロパティを開いて、「graph on parent」をチェックすると、その親パッチの画面内に、隠れた数値ボックスなどを表示できるのだという。 プロパティは空いているところを右クリックすると出てくる。 サブパッチのopenは編集モードでダブルクリックだというが、これはMaxとは違っている。 Maxでは実行モードでダブルクリックであるが、PureDataではこれだと表示されているオブジェクトをトリガしてしまうという。 これはちょっと混乱しそうだ。(^_^;)

次のトピックは「2.8. numeric arrays」である。 数値配列というのは、周期的に読み出すことでサウンドの基本となる「波形テーブル」を代表として、Computer Musicの世界では基本中の基本である。 あとでサウンドに関して、「wavetable oscillator」方式の楽音合成と「table lookup」方式のオーディオ信号の非線形変換について述べるが、コントロールのレイヤーでもテーブル参照は基本的なテクニックである。 たとえばセンサとサウンドパラメータの対応を記述するマッピング、音楽的な要素を生成する確率統計的な変換、データを組み合わせてボイシングする、・・・などいくらでもある。

PureDataでは、配列データの定義(あるいはデータファイルからの読み込み)は、オーディオバッファの全体にわたって参照結果を格納する処理に時間がかかるので、サウンドを生成するより前に行うことを推奨する(まぁ当然である)。 PureDataでは、新しい配列を定義する方法には「graphs」と「tables」があり、いずれにおいても「名前とサイズ(データ数)」とともに定義する。 Maxでは整数配列がいろいろと便利だったが、PureDataでは全ての数値データは4バイトの浮動小数点数値として扱う。

「サウンドデザイン」の講義やCGクリエイター検定試験の対策講座で紹介しているように、この配列のサイズは簡単に計算できる。 PureDataでは1データが4バイトなので、44.1KHzサンプリングで「1秒間」のサウンドデータを格納する配列のサイズは、4 * 44.1 * 1000 = 176キロバイトである。「1分間」で10.6MBである。 これは、CDクオリティのサイズと同じであるが、CDはデータ量子化が16ビット、すなわち2バイトであり、一方でモノラルでなくステレオ(2チャンネル)なので、ちょうどPureDataのモノラルと同じサイズになる。 PureDataでステレオとかマルチチャンネルのサウンドであれば、このサイズの「チャンネル数」倍ということだ。

配列は上記のような波形テーブルとしてだけでなく、「変換関数」としても色々に活躍する。オーディオの非線形変換テーブル、センサ等のパラメータを楽音合成/信号処理のパラメータにマッピングする、FFTと逆FFTで周波数軸上の数値と時間軸上の数値を参照変換するなど・・・である。

配列はよく、上のように「graph on parent」の形で使われるが、もちろん普通のサブパッチであってもよい。 配列のアドレスは「0」から「N-1」であるのはMaxのテーブルと同じである。 以下のように、「tabread」や「tabwrite」でその配列の要素を読み込み/書き出しを行える。

上の例はコントロールのパラメータを参照していたが、以下のように、オーディオの読み出しテーブルの処理もまったく同様である。 440Hzということで毎秒440回のテーブル参照アドレスが出力されるが、これはPureDataなので0から1の間の実数値である。 そこでこれを10倍して1を加えて「1から11」という読み出しアドレスを生成する。 「phaser~」はMaxと同じように鋸歯状波のデータなので、要するにこれでMaxでいう「counter 0 1 11」が出来たことになる。 これを受けた「tabread4~」というのは、4ポイント補間したテーブル・ルックアップのオブジェクトである。 この部分は後に解説があるという。

新しい配列を生成定義するには、「put」メニューから「array」を選び、「properties」で以下のようなダイアログにプロパティを設定する。 ここらはMaxのtableのインスペクタとほぼ同じようである。 Maxの「save table with patcher」と同様に、「save contents」のチェックは重要で、これがOFFだとデータは全てゼロになってしまう。 配列をサウンドテーブルとする場合にはこれは不要で、サウンドファイルから読み込むことになる。

ここにある「delete me」はなんか自爆テロみたいで不気味だが(^_^;)、これをチェックして「OK」すると、PureDataではその配列が消されるという。 配列の見た目のインスペクタの設定は、以下の「graph dialog」で出来る。 X方向は整数で「0」から「N-1」、Y方向は好きな実数で定義する。 ただし周波数では「0 to 20,000」という範囲にするように、とあった。 サンプリング44.1KHzなので、エイリアス(サンプリング)定理により、その半分以下というのは基本中の基本である。

これで、「2. theory of operation」であと残ったのは、「2.8 data structures」だけである。 少しずつ進展しているので、ここで区切りとして、プラハの観光に出発しよう。(^_^)

そして上の写真は、6時間でプラハの名所を見倒すウォーキングツアーからホテルに帰ってきて、900枚近い写真を編集し、少しずつ分割して 帰国後に公開予定のWeb にアップロードしている合間に撮った、21時前のホテルの部屋の机上タコ足の模様である(^_^;)。 1週間が経過したので、電源をOFFったままにしているPHSと、成田空港までしか使っていなかった「数独」用ニンテンドーDS、そして3台あるiPod touchからまず2台、そして毎日撮っては使い切っているデジカメのバッテリ2個(他にさらにスペア2個あり)、そしてメインのMacBookAirの電源を取っている。

部屋の壁コンセントにアダプタを付けて持参したテーブルタップで机上に出しているので、この段階でACは100Vでなく230Vである。 MacとiPodとデジカメバッテリ充電器は「100V-240V」なのでそのまま差し込んでいる。 ところが、PHSの充電器とニンテンドーDSの充電器は100V専用なので、そのまま刺したら発火する(^_^;)ので、ヒゲ剃りの充電用に持参した小型トランス(差し込みブラグは海外用)に「海外→日本」という逆パターンのアダプタを付けてテーブルタップに差して再び100Vに戻し、これを三つ又プラグで分岐して両方を差している。 なかなかにパズルであるが、今回の出張はちょっと長いので、普段なら帰国直前にやる「充電の儀式」を、バッテリが完全に抜ける前にやってみた、という事である。

まだ 帰国後に公開予定のWeb の9月3日分のアップロードが終わらないので、今日の模様はまた、明日以降である。 とにかく疲れた。(^_^;)

2013年9月4日(水)

昨夜もちょっと飲み過ぎて目覚めに疲労感が残り、今日は休肝日にしよう、と決めたプラハ3日目である(^_^;)。 大学とのお仕事メイルは、いろいろと行き来して、順調である。 部屋のテレビのCNNニュースでは、シリアへの攻撃の話題、フクシマの放射能の話題、そして世界の天気では日本地図が連日、登場している。 日本がこんなに海外でのニュースに出てくるというのは、過去にはあまり記憶がない。 以下のように、日本の天気は大変なことになっているらしい。 今日のプラハはWether.comを見るまでもなく、快晴の予感で、とても申し訳ない。

昨日のプラハ巡りについては、無事にアップロード出来た 帰国後に公開予定のWeb を見てもらうとして、以下には「ジョン・レノンの壁」の写真とその 解説 を置いておこう。

The Lennon Wall or John Lennon Wall, is a wall in Prague, Czech Republic. Once a normal wall, 
since the 1980s it has been filled with John Lennon-inspired graffiti and pieces of lyrics from 
Beatles songs.
In 1988, the wall was a source of irritation for the communist regime of Gustav Husak. Young 
Czechs would write grievances on the wall and in a report of the time this led to a clash between 
hundreds of students and security police on the nearby Charles Bridge. The movement these 
students followed was described ironically as "Lennonism" and Czech authorities described 
these people variously as alcoholics, mentally deranged, sociopathic, and agents of Western 
capitalism.
The wall continuously undergoes change and the original portrait of Lennon is long lost under 
layers of new paint. Even when the wall was repainted by some authorities, on the second day 
it was again full of poems and flowers. Today, the wall represents a symbol of youth ideals 
such as love and peace.
The wall is owned by the Knights of Malta, who allowed the graffiti to continue on the wall, 
and is located at Velkoprevorske namesti (Grand Priory Square), Mala Strana.
明日は午前中にプラハを出て、リンツまで約5時間の最後の鉄道旅(^_^)であるが、ブダペストからプラハまでの列車は高速の特急だったので、ちょっと心配になった。 もしかして、プラハからまたあの特急でブラチスラバまで戻りウイーンを経由してリンツに行くとすると、あまり面白くない。 そこでネットで既に取っている切符の時刻表を調べると以下のようで、どうやらほぼまっすぐに南下するようで、距離の割に時間がかかる模様である。 これは去年の 欧州ツアー2012 のウイーン→リュブリャナと同じように、楽しいのろのろ山間列車なのでは・・・と期待した。(^_^)

PureDataについて、ここで整理しておくと、 Pd Documentation のうち、これまでに第1章「1. introduction」に続いて、第2章「2. theory of operation」の2.1から2.8まで終わっていて、あと残すのは最後の「2.9 data structures」だけであり、基本的にPureDataの解説はこれで終了なのである。 残っている「3. getting Pd to run」はインストール方法など周辺の話題、「4. writing Pd objects in C」は面白そうだがたぶんここまで深入りしないのでパス、そして最後に「5. current status」(最新の補遺)であり、リリースノートやバグ情報はパスして、最後の「5.3 differences from Max/MSP」をチェックしたら、もうPureDataのお勉強は完了なのである(^_^)。 実際には、残った「2.9 data structures」がそこそこのボリュームとなっている。

ここで朝10時前である。 昨日はツアーの迎えが来るまでの時間にPureDataを進めていたが、今日はぼちぼちプラハ(の観光地など)が動き出すので、まずは出かけることにした。 昨日、およそ全体像を掴んだので、今日はピンポイントに「展望タワー」「モルダウ川クルーズ」の2点に絞って、のんびりとしてみたいと思っている。

・・・そして19時である。 実はホテルの部屋には16時あたりに戻ってきたが、休肝日の予定が快晴で日焼けしたモルダウ川クルーズの船上で敢えなく取り消しとなり(^_^;)、帰途のメトロの駅で仕入れた本日2本目のビールをいただいて、軽く昼寝して目覚めたところなのだ。 まだ夕陽が明るいので、日が沈んだらプラハ最後の夜の夕食に出かけるつもりだが、weather.comで調べると今日のプラハの日没は19:40だということで、せっかくなので Pd Documentation の残された「2.9 data structures」の最初の概説部分でも眺めてみることにした。

この「2.9 data structures」の部分は、ICMC2002で発表した内容に基づいているそうで、確かにちょっとだけ、これまでの他のトピックよりもみっちりと書かれている。 もともとPureDataを開発したアイデアはMaxと同じように「real-time computer music performance environment」を作りたかったからだが、そこに「making computer music scores with user-specifiable graphical representations」ということでも、ユーザが自由に定義できるComputer Musicスコア(楽譜)、つまりはCGによる図形楽譜を作れるように発展したのだという。

これはMuller Pucketteらしいというか、IRCAMあるいはCCMIXのパリ/フランスらしいというか、僕がパリを中心に2ヶ月ほど渡欧した Sabbatical 2004 を思い出した。 作曲家クセナキスが指向した図形楽譜の系譜をコンピュータ上に実現したUPICシステムをスタジオCCMIXではかつてMSDOSマシン上に実装し、2004年当時は最新のMac OSX上で改良発展させようとしていた。 PureDataは「Eric Lindemann's Animal 」と「Bill Buxton's SSSP」に触発されてのことだというが、まぁ時代の流れとして、誰しもComputer Musicシステムをサウンドとパフォーマンスだけでなく、リアルタイム・グラフィクスと組み合わせようとしていたのである。

ちょうど2002年といえば、Max/MSPにリアルタイムグラフィクスの機能であるjitterが加わった年である。 Cycling'74でjitterの開発を担当した、プログラマでありアーティストのKit Claytonが2002年8月に来日して、DSPSSの場で世界に先駆けて発表した。 このDSPSS2002というのは、僕が2002年にプロデュースしてSUACで開催した MAF2002(Media Art Festival) (MAFは2001年から2010年まで毎年開催)の一部であったのだ。 上の写真のように、SUAC南棟の中講義室には日本中から多数、それぞれMaxの入ったマイMacを持参した専門家/音楽家が集結した(一部は海外からわざわざ参加)。 電源とLANは全て、毎年DSPSSを開催している(赤松さん三輪さん小林さんの)IAMASから持ち込んだ。 そして翌週に世界に公開されるjitterの(バグの取れた)最新版をサンフランシスコから持参した、開発者であるKit Claytonがこの場で参加者に配布して、自ら解説してくれたのである。 さらにKit Claytonがjitterを使った作品の公演を、MAF2002コンサートの中でSUAC講堂で世界初演したのである。 SUACスタッフ学生など、この場に居合わせたのは、実は凄いラッキーなことだったのだ。

・・・と回顧していたら、続きにはMuller Pucketteも、このアイデアはComputerより前から、あるいはComputer Musicの初期からの歴史あるものだ、と解説していた(^_^;)。 登場した事例は、「Stockhausen ( Kontakte and Studie II)」と湯浅譲二「Yuasa (Toward the Midnight Sun)」、そして「Xenakis's Mycenae-alpha」ということでクセナキスにも触れていた。

PureDataは本質的に、構造化されない環境として提供しているので、データ構造data structuresも、そのグラフィカルな表現も自在である。 ここでのトピックとしては、「graphical data structure,」をC言語の「data structure」と関連させて解説するが、グラフィックな色や形は自在にできる、という点が重要である。 データは適当に手描きしてもデータファイルから読み込んでも、数理造形としてアルゴリズムによって生成してもよい。 さらにデータは、入力されたサウンドをリアルタイムに解析したりスペクトル分析した結果でもよい。 以下の例は、そういうPureDataで表現できる「楽譜」の例である。

・・・ここで20時になったので、日没後といってもまだまだ明るい街に出て、もっとも賑わう国立博物館の新市街の方向ではない横道に進んで、庶民的なチャイニーズのお店を見つけて夕食となった。 1週間以上ぶりの「米」、チャーハンは、タイ米でも美味しかった(^_^)。 そしてホテルに戻り、今日は600枚ほどだった写真を編集して、また 帰国後に公開予定のWeb に手作業で分割アップロードしている合間に、PureDataについて進めてみた。

上の例にあるPureDataで描画した「楽譜」は、静止画ではなくて、音楽をライブ演奏している最中の、ほんの数秒間の模様であり、これは刻々と変化していく。 この例で表現しているのは、時間的に変化するノイズ群のポリフォニック(多声部)の融合体である。 この楽譜は表示しているだけでなく、6つのブロックからなり、その左端の青い縦棒をドラッグポイントとして、マウスによって、音量・変化周波数・フィルタのバンド幅などを「制御」「演奏」「操作」するためのインターフェースにもなっている。 よくあるシステムと同様に、この画面では、水平方向が時間軸を表現し、垂直方向が周波数軸を表現しているが、これはPureDataに固有のものではなく、定義は作曲家の自由である。 この例では、黒いシルエットは音量を、色の付いたシルエットは周波数成分を表し、いちばん最後に発生する音(右端)はパーカッションのような減衰音エンペロープで周波数特性が変化していないのが判る。 その一方で、真ん中あたりにある3番目のサウンドは、エンベロープは定常的なのに対して周波数特性は時間とともに激しく変動している。 それぞれのカラフルな色は、ボイスナンバーを表現するよう定義している。

この楽譜例で、それぞれのサウンド(オブジェクト)は、以下のような要素の組み合わせとして作曲されているが、実はこれはPureDataでテンプレートとして持っている枠組みなので、使うのはゼロから全て定義するより簡単である。

これらを定義するためのPureDataのテンプレートは以下である。

テンプレートは「struct」オブジェクトによってデータ構造体として定義され、ゼロあるいはいくつかの「drawing instructions」、具体的にはここでは「filledpolygon」と「plot」で記述される。 「struct」オブジェクトはテンプレートとして「template-toplevel」という名前で与えられ、「x」と「y」と「voiceno」という3つの浮動小数点値、さらに2つの配列によって定義される。 この2つの配列とは、テンプレートだと「template-pitch」という名前の「pitch」配列、そしてテンプレートだと「template-amp」という名前の「amp」配列である。 明らかに、これは音楽の要素「ビッチ」と「音量」を意識している。

一般的には(C言語などの場合)、データ構造体というのは、以下の4種類のデータタイプの複合体である。

PureDataウインドウに登場する要素は「リスト」を構成する。 ただしMaxのtableオブジェクトがTopレベルのみの単一階層でスカラー値を持っているのに対して、PureDataのデータ構造は、配列とリストのタイプをもっと深く階層化することを許容する。 例えばFFTの周波数と位相の複素数ペアを扱える。 ・・・とここまではPureDataが一方的に優れているようにそのまま翻訳しているが、実はこれはMaxの方でも、jitterでほとんど同様に実現できているのである。(^_^;)

「struct」オブジェクトで上に示したテンフレートの他に、「filledpolygon」という矩形のオブジェクトと、2つの配列オブジェクト、計3種類の「drawing instructions」オブジェクトがある。 グラフィックに関する膨大な属性は、描画コマンド・座標/色などの数値などから構成される。 例えば、「plot」だけでは駄目でプロットする色の指定も必要である。 上の例では、「plot + color」のペアの概念を使って、「amp + color」ではcolorにゼロを使い、「pitch + color」ではcolorにvoicenoを割り当てている。

ここまでで「2.9. Data structures」の最初の部分が終わり、次は「2.9.1. Traversal」であるが、この時間帯はホテルでWiFiを使う人が増えるために、非力なルータはすぐらにへこたれる(^_^;)。 小容量のJPEGを20本程度ずつに分解して1時間以上かかってもまだアップロードは半分なので、23時を過ぎたのであとは明日にして、寝ることにした(^_^;)。

2013年9月5日(木)

日付けが9月5日(アルスエレクトロニカの初日)となった真夜中の01:30あたりに目覚めて、残った300個ほどのJPEGをFTPしてみると、さすがにこの時間にホテルでWiFiを使う人はいないらしく、快適に全て、 帰国後に公開予定のWeb にアップロードできた。 このPureData日記も昨日のところまで改訂・アップロードして、これでプラハでの作業はほぼ終了、日本時間で朝10時までのお仕事メイルもチェックして、深夜3時に再びベッドに戻った。(^_^;)

そして起床してシャワーを浴びて朝食後に荷物をパッキングしての、出発前の時間(07:30)である。 日本は午後2時半、お仕事メイルも一段落して、明日の金曜日を乗り越えれば週末には来なくなるし、来週月曜日(帰国出発日)は早起きしてフランクフルトに終日出てそのまま成田へのフライトで途絶するので、お仕事メイル関係はほぼ峠を越した模様だ。 プラハの朝は霧が出ているが、もう出発なのであまり関係ない。 リンツの天気予報は以下のようで、どうも今年は好天に恵まれそうである(^_^)。 今年が8回目となるリンツだが、年によってはずっと雨模様で肌寒いこともあったが、これはラッキーだ。

毎年の登録参加者宛のメイルで「いよいよアルスエレクトロニカが始まりました!」というメイルが届いたのは、たしか2日前だった。 このフェスティバルは例年、5日間から7日間ぐらいの期間、開催されるが、多くの参加者はちょっと遅れてやって来たり、ちょっと早めに帰ったりするので、期間の初日とか最終日は観客が減っている、というのを過去7回のパターンから知っている。 今回は初日の今日にプラハからリンツに入るので、初日の午後の一部から参加できそうである。 5時間ちょっとの鉄道旅の合間に、プリントアウトしてきた分厚い プログラム をザッと眺めて、いつにどこに行くか、というのを決めておかないといけない。 現場で行き当たりばったりだと、それほどの距離でないにしても歩き回る非効率、そして日時指定のイベントを見逃す、という悲しい失敗も経験しているのだ(^_^;)。 予定変更によりおよそ丸1日のフランクフルト観光が可能になったが、この予定検討/調査はまだ、リンツに行ってからでいい。

PureDataの方は、「2.9.1. Traversal」からである。 「Traversal」というのは横断的ということで、ここでの文脈では、PureDataのオブジェクトはリストと配列を横断的に扱うように出来ているとか、データ構造体の個々の要素が横断的に割り当てできる、というような意味だろう。 上のPureDataパッチは、昨日まとめた部分、すぐ上にあるグラフィクス例とテンプレート・オブジェクトの例をプログラミングしたものである。 ここで08:30、出発の時間となったので、あとはリンツで続けていこう。

・・・そして11時間後の19:30、リンツのホテル・ロコモティブの部屋である。 去年の 欧州ツアー2012 でも、院生3人とこのホテルに泊まった、計8回のリンツのうちたぶん4回、利用しているホテルである。 ホテルにチェックインしたのは15時頃で、そこからブルックナーハウスに行ってArs Electronicaのフルパスを購入し、さらにブルックナーハウスで展示されているインスタレーション作品を全てチェックした。 ある日本人のサウンドインスタレーション作品に感銘を受けて、連続25分も動画記録していて、いまこの裏でパソコンは延々とmp4に変換処理中である。

その後、ブルックナーハウス近くの旧タバコ工場(過去にArs Electronicaの主会場になった)に行き、今夜、フェスティバルのオープニングイベントとして大音量ライヴがある、と確認した上で、ゲットしたパンフレット類が重いのでいったんバスでホテルに戻ったところで、既にホテル近くのスーパーで買ったビールを美味しくいただいている(^_^;)。 会場の旧タバコ工場には、あちこちにライブステージが設営中で、さらにたくさんの屋台が出て準備中だったので、たぶん今夜は、市民も集まって飲んで食べて騒いで踊って、工場の壁面を活用したプロジェクション・マッピング大会となりそうである。

プラハからリンツまでの特急列車は、6人用のコンパートメントに僕だけの指定席、つまり貸し切りという豪華なことになり、立ったり座ったりして窓側と通路側の両方からあれこれ写真を撮りまくる、という「乗り鉄・撮り鉄」には最高の鉄道旅となった。 ところが5時間の旅程の3時間ぐらい経過したところで、突然に車掌がやってきて「技術的な理由により、次の駅で下りてパスに乗って乗り継いで欲しい」とのことだった(^_^;)。 スーツケースを押して2台のバスに乗り、チェコの田園風景を楽しんでしばしのドライブで乗り継ぎ駅に行くと、違う電車が待っていて乗り込んだ。 ところがこれはどうも各駅停車の電車で(^_^;)、それなのになんと、リンツには時刻表通りに到着した。 つまりこれは、途中でバスで乗り継ぎ、普通列車に乗り換えるまでが予定通りで、工事とかの臨時措置ではなくて、いつでもこうらしい(^_^;)。 なかなか得難い経験であった。

2013年9月6日(金)

リンツ2日目の朝の9時である。 昨夜はオープニングイベント(プロジェクションマッピングでなく単なる壁面プロジェクションだった(^_^;))を楽しみ、途中で抜け出して23時頃にホテルに帰った。 その後、1200枚近い写真を編集してアップロードしてみると、プラハよりは高速だが、こちらも多量のFTPはfailするので手作業となり、途中で断念して寝た。

そして今朝、起床してから再び手作業アップロードを再開して、ついさきほど、 帰国後に公開予定のWeb の9月5日のところを上げ終えたところである。 昨日はプラハからリンツへの鉄道旅もいろいろ面白かったが、もうここで思い出して書いている余裕が無い。 今回の出張の主目的は、ISPS2013発表と並んで、アルスエレクトロニカ2013での世界最先端のメディアアートの調査である。 ここリンツではもしかすると、PureDataのお勉強の時間は取れないかもしれない。

旅程が変更となり、明後日9/8(日)の半日が消えたので、アルスエレクトロニカの視察は昨日午後と合わせて、あと今日と明日、マルマル2日しかない。 ブルックナーハウスで購入したプログラムを眺めて、もっとも効率良くなるべく全ての展示をチェックしつつ、さらに日時限定のパフォーマンスの予定を入れて、一部はその予約をする必要がある。 これは毎年恒例の、相当に大変なパズルで、どうも今年は山の上の教会への登山電車ピクニックは行けないかもしれない。 ハウプト広場の「蚤の市」と、ドナウ川畔の夜のイベントはいずれも明日9/7(土)なので、両方ともOKなのがラッキーである。

2013年9月7日(土)

リンツ3日目の朝の9時である。 昨日のこの日記がとても淡白なのは、アルスエレクトロニカの素晴らしい作品を見て回り、素晴らしいパフォーマンスを堪能し、多数の写真とビデオを記録して、それを整理して 帰国後に公開予定のWeb にアップするだけで精一杯だったからであり、快晴の好天とともに内容が充実していた証しである(^_^)。 写真をクリックしていろいろとコメントしたいのは山々であるが、その時間が無いので、これは後期の芸文講義「メディアアーツ論」の際に、あるいは帰国後に暇ができたら補足してみたい。

今日の予定は既にプログラムの裏表紙に分刻みで書き付けている。 これからぼちぼちハウプト広場に出かけて「蚤の市」を冷やかし、OKセンターに行って2つのフォーラム(映像部門・インタラクティブアート部門の受賞者が自作を解説)に出て、その後速攻でアルスエレクトロニカセンターに走って、科学未来館のパフォーマンスを見る。 そこからドナウ川を渡ってLentosミュージアムの展示を見て、さらにMarienDome(オーストリア最大のカテドラル)のサウンドインスタレーションを見て、その後アルスエレクトロニカセンター外の特設ドームシアターでのパフォーマンスを3件、見て、晩にはドナウ川を渡ってドナウパークでの数万人のあの音と光のライブイベントを楽しむと、もうホテルに戻るのは深夜になる。 明日の朝は4時には起きないといけないが、まぁ気合いで乗り切るしかない。

明日の朝のリンツ発のフライトは朝6時、タクシーはこれから予約しておくが、どうも上のように、プラハとほぼ同緯度のフランクフルトの明日の天気も良さそうである。 リンツから到着する朝8時前から、成田への帰国フライト20時過ぎまで、なんと13時間もあるので、ここはいつもの突発企画で、フランクフルト1日観光ということである。 ネットで検索すると、空港に こんな日本語ガイド があった。 ここではプリント出来ないが、到着してこれを入手すれば、あとは何とでもなりそうである。 ドイツの街は過去に何回も歩いているので、Sバーンもメトロもトラムもなんとかなるだろう。

・・・そしてここから、いったんホテルに戻った17時前から書き継いでいる。 内容はとても充実していたが、過去の海外出張としては58日間という Sabbatical 2004 を除けば、たぶん2週間というのは最長の出張で、それも5都市を移動周遊する、というハードな旅で、さすがに疲労が蓄積してきたので、いったんホテルに休憩に戻ったのだ。 当初予定からは、関連して併催されているLentosミュージアムの現代美術展をパスしたが、これはメディアアートではなくファインアートであり、またこの会場だけ写真NGなので、真っ先に切り捨てたのである(^_^;)。 ニュースでは、2020年のオリンピック開催地が決まるのはあと数時間後だそうだが、別に関心は無い。

ハウプト広場の「蚤の市」では、去年の 欧州ツアー2012 の時にも、また古びた小さな「鐘」を買ってしまったが、今年もまた、今度は3個さらに小さな「鐘」が並んでいるやつを、鳴らした上で買ってしまった。 海外でのお土産はたいていこれで、もうどれだけ貯まったか判らない(^_^)。

アルスエレクトロニカのフォーラム(各部門ごとに開催され、各部門の金賞・銀賞の受賞者3人が自作を解説)に参加するのは、たぶん 2004年 の、デジタルミュージック部門でIAMASの三輪さんが金賞を受賞したときに取材参加賞讃して以来のことである。 なんせ英語とドイツ語(同時通訳イアホンでつたない英語化)の入り交じる場なので、今回のようによほど海外出張の日々が続いて英語で思考できるようになっていないと、参加しても意味がないのである。 しかし、参加して、良かった(^_^)。 購入したDVDはまだ観ていないので作品全体を観るのは帰国後だが、映像部門の3作品それぞれの作者のこだわりとメイキングの苦労とその素晴らしい発想は、帰国後にメディア造形学科の3/2回生を対象にミニレクチャーを企画して伝授してみたい「刺激」に溢れていた。

また、インタラクティブアート部門では、昨日アルスエレクトロニカセンターのデモでも藤幡正樹さん(銀賞)のプレゼンに参加して質問もしたが、今日のプレゼンはだいぶ違っていて新たな収穫があった。 また、金賞作品は9人のアカペラ・シンガーがシリンダー制御でゆらゆらと回転しつつ演奏するという凄いものだが、会場からの質問で「これはインタラクティブですか?」と聞かれて作家本人が「現状は再生するだけなのでインタラクティブ・アートではありません(キッパリ)」と答えるなど、なかなか面白かった。 ハモンドオルガンのレスリースピーカ(スピーカを回転させることで自然なコーラス効果がかかる1960年代の技術)を意識したのか、と質問したが、彼らはハモンドを知らなかった。(^_^;)

・・・そして2時間たった19時、眠るでもなく横になり瞑目して休養していたが、窓の外では複数のヘリコプターが飛んできた。 いよいよ、数万人のリンツ市民も毎年楽しみに集う、ドナウ川畔での音と光のイベントが始まるまで1時間である。 体調は確かに低下してきているのを実感していたため、アルスエレクトロニカセンター外の特設ドームシアターでのパフォーマンスもパスしてホテルで静養してきたが、出かけるならぼちぼちである(思い立ってホテルを出てトラムでハウプト広場に行くまでの所用時間は10分か15分で十分)。 ベッドで毛布を被り、「行く」・「止める」をそれぞれ10回ほど逡巡してきたが、過去にリンツでこのイベントをパスしたのは確か2回、一度は 2009年 に現地のあまりの寒さに同行している学生の風邪を懸念して撤収、そしてもう一度はたぶん 2005年 に、未踏のプログラミングを毎日ホテルでやっていた年で、そちらに熱中していたためである。

・・・そして3時間後、イベントの途中で早めに切り上げてホテルに戻ってテレビをつけてみると、ちょうどライヴでCNNがオリンピック開催地の決戦投票をやっているではないか。 日本時間は日曜日の午前5時である。 皆んなこれを朝4時あたりから見てたのだろうか(^_^;)。 そして、「TOKYO !」というロゲ会長の発表と会場の大騒ぎをCNNで聞いたが、画面内の東京の会場の反応はそこから確かに0.5秒以上、遅かった。 中継の情報が地球を回るグローバルな時差を、まさにリアルタイムで体感した。

今回、出発した頃は完全に停止していた2ちゃんのニュースヘッドラインは何事も無かったように復活して、この瞬間に上のように1分間に4つものスレが立った。 しかしもう22時半である。 明日は4時起きなので、ここで寝ることにした。

2013年9月8日(日)

リンツの定宿・ロコモティブの部屋には時計も電話機も無い。 ということは、朝6時のフライトのため朝5時に空港に着くため朝04:30にホテルを出るように、目覚ましやモーニングコールをセットする術が無い。 昨日はフロントに早朝のタクシー予約を頼んだら、リンツのタクシーは24時間営業で、このホテルには電話すれば3分で来るから不要だ、というので予約しなかった。 そこで朝4時に確認のため部屋のドアを叩いて欲しい、と依頼すると「OK(^_^)」とのことだった。

しかしそこはA型人間、ちゃんと午前2時には目覚めてシャワーとパッキングを済ませて、昨日の写真の編集などしていたが、朝4時になっても何の音沙汰も無かった(^_^;)。 そして04:20にフロントにチェックアウトで下りて行き、タクシーを呼ぶよう依頼、すると電話して「混んでいるので45分後になるけど」と言ってきた。 それでは間に合わない、昨日はフロントのスタッフが太鼓判を押していたので何とかしろ、と言うと、しぶしぶ他のタクシー会社に電話したら、ちゃんとすぐ5分後に来た(^_^;)。

そして今、チェックインを済ませてスーツケースから解放され(これは帰国時の成田で受け取って税関を通してから再び預けてセントレアで受け取る)、ゲートインして搭乗ロビーで営業前のカフェのテーブルでパソコンを広げた朝05:10である。 リンツ空港はとても小さく、搭乗ゲートのガラス窓越しのすぐ前に、昨夜から駐機していた朝イチのルフトハンザ航空機が見えるが、ここに歩いて行って乗り込むのだ。 リンツ空港にフリーWiFiが飛んでいることはホテルで確認していたが、残念ながらFTPサーバの接続は、listingは出来てもuploadは出来ないと判明したので、昨日の写真のアップは後日となりそうだ。 真っ暗だった売店が点灯して開店、店員がワゴンで持って来たばかりのクロワッサンは作り立てで中がモチモチで、淹れたてのコーヒーとともに旨い(^_^)。

さて、こうなればもう搭乗までの時間はPureDataしかない(^_^;)。 「2.9.1. Traversal」の続きである。 Maxでは、僕は使ったことのない「タイムライン」というオブジェクトがどこからか追加され、お手軽に簡易シーケンサのモジュールを記述できるようになっていた筈だが、PureDataではビルトイン・シーケンサは無い。 9月5日のところにも置いていた以下のサンプルPureDataバッチ例では、変数「x」が時間軸に沿った推移を記述する時間パラメータであるが、あくまでPureDataはシーケンサでなくて、変数xに対しての振る舞いとして記述する。 ただし「sort」関数が提供されているので、ユーザは時間的変数xとともに記述したイベントリストをソートすることで、時間「x」に対するシーケンスデータの処理を実現できる。

これはMaxでも同様のことだが、Maxの「seq」オブジェクトはMIDIイベント・シーケンサとして、個々のイベントの先頭に、記録開始をゼロとするタイムスタンプを付けたリストとして管理する。 これは心理学実験では色々と活用したところで、かつて この研究 の心理学実験で、被験者のデータをMIDIシーケンスとして収集してから分析した。 また、 この研究 でも、被験者のデータをMIDIシーケンスとして収集してから分析した。

また最近では、シーケンスデータではないが、 この研究 の中でのメディア心理学実験として、講義の中で学生に被験者として協力してもらった。 実験ソフト(実際には上1/3の部分だけ見えている)は以下のようなもので、指示に従って、聞こえてくるサウンドに対しての評価をクリックしていくと、最後にはplain textデータが出来るので、それをコピペして僕にメイルしてもらってデータ収集した。 詳細はここでは省略するが、興味があれば この研究 の後半を参照されたい。 実験Max6バッチも結果データも解析パッチも全て公開している。

PureDataに戻ると、シーケンサのようにイベントをリストにレコーディングしたりプレイバックすることは、PureDataが提供している膨大な機能のごく一部でしなかい。 PureDataの機能を駆使すれば、普通のシーケンサでは実現できない可能性、たとえばイベントをランダムに再配置するとか、楽譜データに従ってリアルタイム入力(独奏)に反応して伴奏するとか、楽譜自身が音楽とともに変容していくとか、パフォーマンスのセンサ入力にリアルタイム反応するとか、も出来るのである。 まぁ、これはMaxでも同じであるが。(^_^;)

ここからリンツ→フランクフルトの機内である(たぶん20分以下)。 PureDataでは、データに対して「Traversal」を提供するために「pointer」というオブジェクトのアトムを用意している。 pointerといえばC言語ではバグの元と悪名高いが(^_^;)、既に述べたナンバーとリストという2種類を組み合わせてメッセージを作るためのもので、明示的な形式を持たないのでメッセージboxで表示されないものだという。 上のバッチ例で登場している「pointer」と「get」というのがpointerの定義とその使い方の例となっている。 「pointer」データタイプは、データの順序を制御する「pack」と「unpack」ペア、あるいは「route」オブジェクトを統合したものである。

・・・そして朝8時、ここはフランクフルト空港内の「LuxxLounge」というラウンジである。 リンツからのフライトは天候上の理由とかで15分ほど遅れて、分厚い雲をかきわけて着いてみるとフランクフルト空港の滑走路は濡れていた。 天気予報では「晴れ」とのことだが、雨模様ならあまり出歩きたくもない。 このラウンジは1日30ユーロ(僕のNICOS VISAゴールドカードは、国内の空港ラウンジはほとんどで無料となるが、海外にはまったく効かない)で、レストラン/カフェに行こうが市内観光に行こうが自由であるという。 昼寝も出来るゆったりのソファーに電源、そしてパスワードからフリーのWiFiはこれまでのホテルの貧弱なものと違って強力で、いまこれを書いている裏で、昨日の写真600枚を一気にアップロード中である(^_^)。 フリードリンク/軽食スペースもあり、これから10時間、このラウンジで引き蘢ってお仕事するのも悪くない。 もともとトランジットのフランクフルトなので、無理して市内観光に出かける必要もないのである。

ということで、美味しいコーヒーとともにPureDataの続きである。 ちょっとウトウトしていたが、成田空港を飛び立つとともに封印して、珍しく今回は海外で一度も聞いていなかったiPod(touch)をここで出してきて、多くが僕のカラオケのレパでもあるJ-POPを聞いてみると、じわわーっと奥底まで染み渡る幸せな気分になり、テンションが上がって目覚めた。 そうか、もう2週間も歌っていないのだった。 ここは水面下であちこちにお誘いを出して「歌う会」を企画しよう、と決意した。(^_^;)

上のバッチ例で、上から4つ目にある「pointer」オブジェクトは、その下のtriggerオブジェクトを経由して「play」するためのポインタを指定して、最終的に下の方にある「voice」オブジェクトのいずれかに送っている。 「pointer」オブジェクトは「traverse」メッセージを受けて、ここでは「pd-data」と名付けられたリストの先頭にセットする。 そして、後で「next」メッセージを受けるとリストとしてその次のデータを送る。 もう一つの「pointer」オブジェクトはもっと下の方で、「float」として数値を保存しているセルをトリガしている。

どのようなシーケンサでも、その中心には何がしかの「遅延」がある。 基本単位の遅延(の整数倍)がイベントと次のイベントの時間的間隔を示す、シーケンサの最大分解能(もっとも短い音符として表現)となる(「スタート」キーを叩く、という非イベントを含む)。 9月4日のところにも置いた上の楽譜の例(ここでのパッチと対応)には6つのオブジェクトが記載されているので、我々はあるオブジェクトをスタートさせると、次のオブジェクトまでの遅延時間分だけ待たなければならない。 そこで、それぞれの「voice」の抽象化されたポインタを使う。 しかし、オブジェクト自身はそれ以前にどのような遅延があって自分がトリガされたかは知らないので、PureDataでは最初にオブジェクトをトリガ(演奏)する際に、それ以前のイベントからの時間差を与えてやらなければならない。 これをしているのが、「pack」オブジェクトである。 たぶんPureDataの「pack」は、Maxの「pack」と同じようなものなのだろう。

上のパッチの上から6番目の「get template-toplevel x」というオブジェクトを用いて、「delay」オブジェクトにイベント間の時間差がセットされる。 マイナス演算によってインクリメンタル時間(次のイベントまでの時間差)を設定することでテンポに変換される。 PureDataはデータ構造体から値を読み込む「get」オブジェクトと、データ構造体に値を書き込む「set」オブジェクトを提供している。 上のパッチ例の2つの「get」オブジェクトは、現在のオブジェクトの「x」と「voiceno」のフィールドの数値を取得している。 「テンプレート」オブジェクト(template-toplevel)は「get」オブジェクトをサポートしているので、それぞれのオブジェクトは次のイベントまでの時間差(offset)を良好なリアルタイム処理として取得できる。

ディレイ時間が経過(完了)すると、オブジェクトのpointerは再びcall(recall)され、voicenoもリコールされることになる。 この時間xとボイスnoはpointer自身でパックされrouteされることで、pointerは該当するvoiceに行く。 ボイスnoは周波数を表す「色」にマッピングされていて、「999」という3桁のRGBフィールドで表現されている。 そして第一属性として指定された「色」を、第二属性は「黒」(→エンベロープのシルエット)としてルーティングされる。

「voice」abstractionにおいては、テンプレートに定義された中からビッチを取り出し、配列から動的なブレークポイントを処理する。 「voice」abstractionは当たられたオブジェクトに対するpointerを受け取ると、配列の要素に対するシーケンシングを行うので、ここでは内部的に同時進行する2つのシーケンサということになる。 全体としてのシーケンサーの構造が再帰的になっているのは、オブジェクトのデータ構造が再帰的になっていることの反映である。 最終的には「voice」abstractionは、それぞれのオブジェクトに対応したサウンドを生成し、加算バスに乗せて合成出力する。 これは単なる一例であり、PureDataには異なったテンプレートを持つたくさんのオブジェクトを多層的に構築することが容易である。 これにより、リッチで自分の個性的な「スコア言語」の枠組みを得て、自在に開発(作曲)し、シーケシング(演奏)することが可能となっている。

リンツでの日数をまたいだが、「2.9.1. Traversal」はこれで終わりである。 あと残りは「2.9.2. Accessing and changing data」「2.9.3. Editing」「2.9.4. Limitations」である。 本当は瞬間最大能力として英語力が上がっている旅先でさらにガンガン進めるべきだが、ここでお昼時となった。 そこで、ビールとおつまみ(これもフリー(^_^))を持ってきて、引き続きiPodで「Singers Unlimited」のアルバム2種を聞きながら、せっかくネット環境が快調で昨日の分までWebに上げた このページ もサクサクと追いかけられるので、ここでいくつかの写真リンクを並べつつ(オフラインだと全て写真が消えるが(^_^;))、今回の2週間の渡欧旅行を振り返っておく、という、のんびりした(至福の)時間にすることにした。 あちこち移動して色々してきたので、帰国後とか言っていると忘れるので、これは貴重なチャンスなのかもしれない。

まずはウイーン情報である。 以下のCATという空港市内直結電車で、ウイーンはすっかり空港が近くなった。 去年はまだ、市内ターミナルのMIT駅への接続通路が工事中でえらく迂回していたが、完成してみると最短経路でメトロのU4に直結(^_^)。 この軽快さは、 欧州ツアー2007 で経験した、コペンハーゲンの超軽快さと匹敵する(^_^)。 そして去年の 欧州ツアー2012 でも院生と宿泊した、以下のホテルもお薦めである。 なんといってもメトロU4の駅から地上に出たら、もう見える(^_^)。 数車線でクルマががんがん飛ばしてくる道路を渡った向かいなので一見怖いが、実はこの道路は一方通行なので、ちょっと待つと必ず上流の信号が赤になって渡れる。 さらにトラムの駅もある。 僕が嬉しいのは、駅前の、アラブ系のおっさんの売店(ワインとかビール)が遅くまでやっている事なのである(^_^;)。 あとはウイーンどこでも行けるトラムに加えて、以下の「リンク」トラムは、東京で言えば山手線だが、ウイーンの主だったところ、どこでも行ける。 ウイーンカードかフリー乗車券を買えば、ただ乗って降りるだけなので、1駅でも乗り降りも気楽である。 オーストリアはドイツと同じシステムで駅には改札機が無く、切符への刻印機の柱を素通ししてチケットを買わずに乗っている市民も多いが、たまーーーに隠密検札に無賃乗車がバレると罰金は60ユーロ(8000円ぐらい?)とかである。

ここで14時になり、フランクフルト市内観光に出ることなくあと数時間のラウンジ引き蘢りが確定的になった。 ビールから美味しいワイン(これもフリー(^_^))に進展、そして何より、茹でたてのフランクフルトソーセージが抜群に旨いのである(もう3本食べた)。 ブダペストについてはチラホラと写真リンクも紹介していた事を確認して(もう既に忘却していた(^_^;))、ここではチェコのプラハに注目してみよう。 ただし僕は、「地球の歩き方」の必要なページ以外(グルメ、ショッピング、ホテル等)は破り捨てて薄くして持ち歩き、さらに通り過ぎた街の「地球の歩き方」抜粋を現地に捨ててくるのがパターンなので、いま手元には何も無い(^_^;)。 過去の記憶に頼って書いてみよう。 以下の王宮はかなりの高台にあるので、下から登るのはお勧めしない。 3番目の「ジョン・レノンの壁」は絶対にお薦めの圧巻である。

ペトシーン・タワーは、トラムやバスに至近のケーブルカーで登った公園から絶景を堪能できるのでお奨め。 ただしタワーでは、僕は追加料金のエレベータを使ったが、階段で上まで登るのはたぶんかなりタイヘン(^_^;)。 注意点は、このケーブルカーのチケットは、フリー交通チケット(orプラハカード)があればそれで乗れること。 うっかり買ってしまった僕の失敗を繰り返さないように。

プラハからリンツへの列車は5時間。 1等だと6人用コンパートメントを独占、とリッチな気分で、これで指定券を含めて5000円なら、沿線風景を含めて大絶賛。 ・・・と思ったら、どうやら両国の鉄道規格の関係で直結は無理で、途中でバスに乗り換えて、後半はリンツ行きの普通列車になる、というのが不人気(空いている)理由らしい。 ただし、もう一度と言われたら、また乗ってみたい。

アルスエレクトロニカに絡めたリンツ情報は、過去の記録として 2004年2005年2007年2009年2010年2011年2012年 にも記載があるので、ここでは省略する。 ここではとりあえず「レトロゲームを展示し倒す」という、往年の名機と趣味のゲーセン大会からごく一部だけ。

・・・ビールに続くワインも2杯目となり、ぼちぼちラウンジに来てのんびり8時間が経過しようとしている。 iPodはSuperflyのアルバム[1]から[4]の中からランダム再生し続けていて、テンションは上がったままである(^_^)。 日本語の歌詞を聞き続けていると、どんどん英語力が薄れてきてすっかり感覚的には日本に戻ったようで、まぁリハビリかな。

・・・そして今は19:45(日本はもう月曜日の午前02:45)、フランクフルト空港のANAゲート、あと30分で搭乗である。 空港内をしばし散策して、リクライニングシートの並んだスペースでゆったりして、最後に30分間有効のフリーWiFiに繋いでメイルチェックであるが、日曜日の深夜なので何も来ない。 パソコンは満タン充電しているので、また機内の後半にPureDataの続きをする、というところだろう。 帰国するとあれこれあれこれお仕事が待っているので、PureData日記はここでオシマイになる可能性が高い。 Raspberry Piで走らせる実験とかは、まだ先になりそうである。 ISPSとアルスエレクトロニカで色々と刺激とアイデアがゲットできたので、これも進めていきたい。

2013年9月9日(月)

フランクフルトから成田へのフライトの半分にさしかかったところ(全体の4/9まで飛行)で目覚めて、いつものようにリフレッシュのストレッチ(しかしさすがに身体が軋んでいた)、そして冷たいオレンジジュースで起床した。 ここで「機内ニュース」を見ると、昨夜7時のNHKの録画でオリンピック2020東京の話題、たまたま僕は最後の発表の瞬間の直前にCNNテレビをつけたが、どうも国内では前夜から見守っていたらしい、と知った、 東京オリンピックのあった1964年というのは僕はまだ6歳で実際の記憶もなく、初めてのカラー中継だったというが我が家(大多数のサラリーマン家庭)のテレビはまだ白黒だった。 カラオケで学生がポ.ルノグラフィティの「アポロ」を歌うが、それと同じ「過去のもの」という気分である。 ただし僕はアポロ宇宙船が月面に着陸する世界生中継テレビを(たしか映像は白黒)11歳なので明確に記憶している。 その後の日本のオリンピックは札幌と長野といずれも冬季で、近くでもないのでとりたてての感慨もない。 万博(アポロ月面着陸の翌年の大阪万博1970には初めての新幹線に乗って実際に行った)と違って、オリンピックは見るだけだからなぁ。 7年後には関係ない総理大臣が「放射能は大丈夫」などと根拠なく大見栄を切ったのが心配だった(^_^;)。 このニュースを見終わってコーヒーをもらってここまで書いたところでフライトは残り5時間を切った。

さて、PureDataは次の「2.9.2. Accessing and changing data」からとなる。 ここではリストでなく数値データについて、PureDataに一般的な話として、データをアクセスし変更するのは、「pointer」オブジェクトを経由して「scalars」オブジェクトを呼び出すことで行うという。 スカラーの中にさらに数値とシンボルがあり、いずれも前述のように「set」と「get」でアクセスして設定・取得するという。 リストと配列も、個々の要素はスカラーなので、結局、PureDataでは個々の数値とシンボルは全て、何がしかのスカラーとして同じように処理される。

リストについても上記と同様で、「get」オブジェクトがpointerを与えて、スカラーのサブセットを得ることになる。 そして同じように、個々の要素のスカラーの「float」ないし「symbol」を与える。 配列については、与えられたスカラーから「element」オブジェクトが提供され、フィールドネームが番号付けされ、名付けられた配列フィールドの要素(element)となる。 どうもこのあたり、判っている本人の用語が判っていない他人に伝わらない典型のようだが、まぁ仕方ない。

スカラーの「float」や「symbol」要素を得るためには、直接的には「set」オブジェクトを使うが、リストや配列ではそうはいかない。 メッセージの中に、そのような(直接的にアクセス出来るような)データタイプを持たないからである。 リストは他のリストと関係付けて「set」出来るのはpointerを経由してのみ可能であるが、あらかじめ全ての要素の数とかを固定的に定義(C言語で言えば全てstaticに定義)していない、動的にわらわらとリスト自体が変化していいものなので、以下の2つの方法のいずれかが必要となる。 その第一は、処理するたびに自動で参照するリストのコピーを作る機構によってコピーの奥深くにアクセスして修正後はそれを元のリストにコピーして書き戻すこと。 その第二は、ガベージコレクションのメモリ管理機構(メモリ中に動的に配置され生成消滅することで生じる間隙を寄せ集めてメモリ空間を有効に保つ機能)を用意することである。 このいずれも、リアルタイムに刻々とリスト処理しなければならない処理は荷が重く(これはJavaとかFlashとかProcessingとかでもまったく同じ状況であり当然である)、「リアムタイム作曲」を実現したいPureDataにとっては大きな困難である。 スカラーと関係づけられたスカラーをメモリ内で生成消滅させる(アトムとアトムが対応しているならデータ改編は容易)のであれば簡単なのだが、不定長のリストでは実行時間内に予測が困難なので、本質的課題である。 まぁ、これは当然なので、僕はMax(やC)では、考え方としては冗長でもリストや蓮列は全てstaticにしているのだ。

配列において多数の要素をアクセスしたり変更するために用意されているのが、「getsize」オブジェクトと「setsize」オブジェクトである。 リスト(尻尾の先が見えない蛇)に対しては、「appemd」オブジェクトがあり、新しいスカラーをリストにひっつける事になる。 Maxであれば「append」と「prepend」があり前後にひっつけられるし、多数のあって色々自在にリスト処理できるが、PureDataではリストの一般性を確保するために自縛状態にあるような気もする(^_^;)。 追加(append)に対して削除(delete)はもっとシンプル(自由度ナシ)で、リストの特定の要素だけ消してその前後をひっつけるのは出来ないらしく、出来るのはそのリスト全体を消すだけである。 「There's no reason not to provide finer-grain deletion mechanisms except that it's not clear how to protect against stale pointers efficiently, except by voiding the entire collection of pointers into a list.」と書かれているが、まぁ言い訳とも見える。 Maxだと「zl」ファミリでもっとflexibleである。

フライトはイルクーツクを過ぎてぼちぼち全体の2/3、残り4時間ちょっとである。成田に着いてメイルチェックするためのバッテリを残しておきたいが、まだ残量表示は「82%」もある。 暗い機内で、LCDパネルのパックライトも、キーボードのバックライトもほぼ最小にしているのが効いているらしい。 さて、次は「2.9.3. Editing」である。 上述のグラフィカル楽譜は編集可能であり、その方法はブレークポイントをドラッグしたり、ブレークポイントをを追加/削除したりするためにマウスクリックする事だった。 そしてPureDataパッチはMaxパッチと同様に、これらオフジェクトの全体やいくつものオブジェクトをまとめて、コピー、ペースト、スクリーン内の移動、などが自在である。 さらにPureDataでは、ダイアログウインドウ内に表示され更新されている、テキストで表現された(コンピュータが生成したり処理している)データについても、編集したり変更したり外部textファイルに書き出したりできるという。 これはMaxでは出来ない(Maxウインドウの表示ステータスはコピペでつまめないので別にリスト出力する必要あり)のでPureDataは素晴らしい。

PureDataにおいて、データオブジェクトのグラフィカルな表示は内部的には描画命令によって処理されていて、マウス操作の結果として得られる数値を元にこの描画命令が発せられている。 グラティカルな次元が変数によってコントロールされるよう与えられている場合には、次元に沿ってドラッグすることで変数が与えられるので、次元が定数であればドラッグしても何も起きない。

PureDataに特有なトリッキーな状況として、ユーザがテンプレートの要素を変更した時に何かが起きる。 テンブレート内の描画命令の変更というのも、ユーザがデータオブジェクトを単にトラックダウンしたり巻き戻したりして起こり得る。 しかしユーザ軽い気持ちでフィールド定義を更新したり消したり新設したりリネームしたりと、「struct」オブジェクト自身を変更しようとすると、予想と違うことが起きる。 PureDataでは「struct」オブジェクトが変更されると、単にその部分が書き換えられるのではなくて、まず元の構造体をメモリにコピーして確認して新しい構造体を書き出す、という処理を裏で自動的に行う。 ここでもし同じ名前のフィールドやタイプがあったりすると、矛盾を避けようと登場する順にリネームとかリタイプという余計なお世話をしてくれる。 その結果、PureDataは良かれとやってくれているのだが、ユーザが希望したように構造体はエディット出来ないのだという。(^_^;)

これは「struct」オブジェクト」が同じ名前のデータ構造体を持っていなければ起きない。 あるいは既存のデータ構造体の過去の違ったバージョンなどをユーザがリクエストすると、PureDataは良かれとやってくれているのだが、既存のデータ構造体が消えたりすることがある。 このため以下のように、PureDataでは不慮のデータ消失を避けるために、データ構造体を記述するオブジェクトとして、直前の参照と新たな参照とを区別するのに、なんと「struct」と「structs」という両方があるのだという(^_^;)が、これはややこしい。 要は名前の重複に注意してね、という事なのだが、「よくある」事だと思う。

For this reason, Pd maintains a private representation of the last active version of a "struct" 
until all similarly named "structs," as well as all data using that "struct", have disappeared. 
If the user introduces a new version of the "struct" and only later deletes the "current" one, 
the data is only conformed to the new version once the old one is deleted. In this way we 
avoid getting into situations where data is left hanging without its structure definition, or 
where data ends up belonging to two or more structures of the same name. The worst that 
can happen is that data may lose their drawing instructions, in which case Pd supplies a 
simple default shape.
・・・ここでバッテリが「70%」となり、あとフライトは3時間半である。 次のトピックは「2.9.4. Limitations」である。 たいていこのタイトルは「言い訳」に使われるのだが、どうだろうか(^_^;)。

PureDataは、ここで紹介したようなシンプルな例よりももっと複雑で高密度なデータ構造体としていく事も出来るが、より(本人以外には)見にくく判りにくくなってくる。 ユーザはそれぞれの希望で、もっと高度な描画命令を構築したり、描画命令をON/OFFしたり、いろいろなテンプレートのバージョンの描画命令を切り替えたりしたくなる。 機能としては、ユーザのマウス操作で編集された色々なテンプレートのバージョンが、マウスクリックで自動的にバインドされるような機能が求められる。

より一般的には、PureDataはデータの集合体として、分析系、シーケンス系などについても上のような機能を提供すると期待されるかもしれない。 しかしPureDataではそのような機構を持たず。シンプルな「pointer」「set」「get」オブジェクトで構成されているので、そういう希望は、「出来ない」(キッパリ)。

The "data" facility, although part of the original plan for Pd, has only recently been 
implemented in its current form, and as (hopefully) the user base grows there will 
surely be occasions for many further extensions of the data handling primitives and 
the graphical presentation and editing functions. 
やはり「言い訳」だったようで、上がこのトピックの最後である。 いずれ誰かが改良してくれるかもね、というのは、どういうシステムでもよく書かれている事であるが、それが実現される事はなかなか少ない(^_^;)。 Maxの方は、PureDataの発想のようにグラフィック機能を拡充するのでなく、Maxの拡張のMSPでサウンド処理を実装したように、jitterによってグラフィック機能を拡張自走した。 このあたりで両者の戦略が違ってきたわけで、まぁ僕にはMaxの方が良さそうである。 ・・・ここでバッテリが「65%」となり、あとフライトは3時間である。 ちょうど区切りなので、ここまでとしよう。 帰国後には両方をWebにアップしなければ。

・・・と書いていたが、いま成田空港の国内線乗り継ぎ搭乗ゲートである。 今回はラッキーに、ここで接続できる時間があった。 ここまでをとりあえずアップして帰宅しよう。(^_^)