続・Propeller日記(2)

長嶋 洋一

Propeller日記(1)

Propeller日記(2)

Propeller日記(3)

Propeller日記(4)

Propeller日記(5)

続・Propeller日記(1)

続・Propeller日記(3)

続・Propeller日記(4)

続・Propeller日記(5)

続々・Propeller日記(1)

続々・Propeller日記(2)

続々・Propeller日記(3)

続々・Propeller日記(4)

2012年8月31日(金)

ヤンクなでしこが韓国に快勝した翌日、いよいよ日本から出発の日である。 いつものように朝7時に前泊したセントレアの東横インを出発して、8時過ぎのフライトで成田空港に着いたところである。 フランクフルトへのフライトへの搭乗まであと50分。 今回の55番ゲート付近は成田空港のFree WiFiがうまく繋がり、コンセント近くの椅子もゲットしたので、 iPod touchでYESの「こわれもの」を聴きつつ(^_^;)、MacBookAirを満タン充電しつつ、少しだけ書き進めてみよう。

続・Propeller日記(1) に書いたように、 今回の日記では、PropellerとXBeeを組み合わせているが、Propellerシステムの部分は 「電子十二影坊」 や 「Peller-Min」 などのオリジナル回路と違って、 「万変鏡」 では加速度センサや照度センサを加えているものの、基本的には uOLED-96-PROP を活用している。 OLEDとは「有機エレクトロルミネッセンス」の事で、その別名が「有機発光ダイオード（Organic light-emitting diode）」である。 これまで公開していなかったこの「万変鏡」関係のドキュメントを残す、という意味もあるので、 ここでuOLED-96-PROPについて整理しておくことにしよう。 この作業は、電子的資料があれば、WiFiを飛ばすXBeeモジュールが無くても(機内でも)進めることができる。 以下、まずは全13ページの マニュアルPDF の中で、あまり関係ない(option製品とか)部分を除いた9ページを眺めつつ、実際に使用した立場でコメントしてみよう。

これがuOLED-96-PROPのPDFマニュアルの表紙である。Propellerファンにはたまらない(^_^)。 このuOLED-96-PROPが製造中止になってしまい、 その後の同社のOLED製品ではPropellerが使われていない?模様なのが残念である。

ここにイントロダクションとして、この製品の概要が紹介されている。 コンパクトであり、コスト/性能比が良好なことが謳われているが、なによりPropeller応用製品であることが重要である。 これまで僕は使った事がないが、なんと基板上にマイクロSDカードスロットが付いていて、 静止画データなどをここに格納して表示できるのである。 2009年のアルスエレクトロニカの展示で見たが(今回もまたアルスエレクトロニカに向かっているが)、 MITメディアラボの作品で、多数のブロックをテーブル上で並べるものがあった。 このブロックのディスプレイにはそれぞれ異なった人物の顔が表示されていて、 例えば2個のブロックを上下に隣接させると、上のブロックの人物は下を見下ろし、下のブロックの人物は上を見上げる。 その動作は静止画の切り替えでなく、スローながら動画である。 左右に隣接させても同様である。 これは磁気センサとともにPROP-OLEDのようなデバイスを内蔵しているのだろう。

これがuOLED-96-PROPの「仕様」である。 画素が「96*64」、すなわち「4:3」でなく「3:2」であるのがちょっと残念だが、それ以外は「凄い」の一語に尽きる。 この写真のように、OLEDデバイスの裏側に、Propellerチップが載っている。

これがビン配置(電気的仕様)である。 たった10ピンのコネクタで、USBシリアル(FTDI)ライタとの通信に「Propellerクリップ」と同様の

  • Gnd(Vss)
  • Tx
  • Rx
  • Reset
の4本と、さらに以下の6本が定義されている。
  • Vcc(モジュールに供給する電源 : 3.6V - 6.0V)
  • 「+3.3V」電源ライン出力
  • Propellerの汎用ポート(P18)
  • Propellerの汎用ポート(P19)
  • Propellerの汎用ポート(P20)
  • Propellerの汎用ポート(P21)
Propellerには32本のポートがあり、ホストと通信する「Tx」「Rx」の2本とこの汎用4本を除いた26本のうち、 かなりのポートがOLEDの表示制御のために使われているのだろう。 ・・・ここで搭乗時刻となった。続きは機内からスタートである。

さて、一つ上の画像について書いてから、およそ6時間が経過した。 いつものようにワイン(quarter)を4本飲んで爆睡して、フライトの半分あたりで目覚めて、 入念なストレッチと冷たいトマトジュースとオレンジジュースと濃いホットコーヒーとで目覚めたところである。 もうじき(といってもあと2時間ほどで)モスクワ上空である。 このページは「Circuit Diagram」とあるが実際には次のページに回路図があり、ここは写真である。 これだけ小さく作るというのは大したものだ。

これが回路図である。 Arduinoあたりから驚かなくなったが、シンプルそのものである。 要するに、

  • CPU
  • 水晶振動子
  • 外付けフラッシュEEPROM(シリアル)
  • 電源レギュレータ(→3.3V)
  • USBインターフェースIC
  • OLEDモジュール
  • マイクロSDカードスロット(コネクタ)
だけが並んでいる。 水晶は5MHz(→16倍モードで最大の80MHzクロック)でなく8MHzであり、8倍モードの64MHzクロックで動作させている。 ArduinoであればEEPROMが内蔵されているが、Propellerは外付けである。 これはデメリットという事ではなく、ソフトウェア開発時にはPropeller内部のRAMに転送するので、 ArduinoやAKI-H8のようにフラッシュEEPROMの書き込み回数制限を気にすることなく、無限にリトライ出来る。(^_^;)

OLEDモジュールとの接続には、データバス8本、制御線6本が使われていて、 マイクロSDカードとは計4本の信号線でシリアル通信している。 未使用のポートはたった5本であり、まずまず効率が良いが、 希望としてはこの5本も外部コネクタに出して15ビンとして欲しかった(^_^;)。 外部回路に対して、4ビットで出来ることと、9ビットで出来ることには雲泥の違いがある。

これはOLED-PROPのディスプレイドライバ・グラフィックドライバについての淡白なページである。 このURLにアクセスしても、現在では製造中止なので何も出てこない。 自分の手元にあるものが頼りなので、ちょっと調べてみると、既に 続・Propeller日記(1) で紹介した2つのグラフィック関係ドライバは、いずれも4D社オリジナルをわずかに自分なりに簡潔にしたものであるが、 発掘しても本当のオリジナルは出てこなかった(^_^;)。 アセンブラでごりごりと、しかし確実にビット操作して表示させているのが判る。

「電子十二影坊」 の時に、ソフト開発した小畑さんと任田さんとともに確認したように、 Propellerでは内蔵メモリに転送できるプログラムサイズの制限があり、また個々のCogが80MHzで並列動作しているといっても、 リアルタイムグラフィック生成処理では、さすがにGHzオーダのパソコンほどの描画速度は無いのであった。

このページは外形寸法図である。 外部接続するコネクタのピンが0.1インチ(2.54mm)間隔なので、電気屋には、だいたい見当はつく。

このページは「注意事項」であり、以下のようにOLED特有の面白い注意点が書かれている。 背景色を「白」にすると消費電流が最大となるので背景は黒とせよ。 画素が明るいほど消費電流が増える。 周囲が白だと色が目立たなくなるので画素はmixカラーして黒背景で。 他のディスプレイと同様に焼き付きがあるので特定の同じ画像を表示し続けるな。 スクリーンを定期的に暗くしたりコントラストを落としたりスクリーンセーバを採用せよ。

  • Avoid having a White Background. The more pixels that are lit up, the more the OLED module will consume current. A full white screen will have the highest power consumption.

  • Avoid displaying objects or text on White Backgrounds. This will cause a smearing effect which is inherent to all OLED displays. Instead, try a shaded mixed colour as the background or better still a black background. Ideally have mixed coloured objects/text/icons on a black background.

  • Avoid having to display the same image/object on the screen for lengthy periods of time. This will cause a burn-in which is a common problem with all types of display technologies. Blank the screen after a while or dim it very low by adjusting the contrast. Better still; implement a screen saver feature.
これでOLED-PROPマニュアルについては終わりである。 機内では「出発から7時間40分、目的地まであと2900Km(3時間40分)と表示されている。 まだバッテリが「残り83%」とあるので、楽しいMax/MSP/jitterプログラミングに入る前に、 もう少し進めてみよう。 卒業生の清水清一郎クンが角川から出したDVDの2作目「中学星part2」も、 Amazonで買ったのにまだ一度も見ていないのでMPEG4に変換して持参しているが、 これはいつでも見れる(^_^;)。

ここで自分のプログラミングの思い出しのためにも確認しておきたいのは、 OLED-PROPのディスプレイドライバの勘所(呼び出し方法)である。 あわせてPropellerアセンブラの復習にもなるだろう、 続・Propeller日記(1) に、サンプルとなる「Demo_OLED.spin」と「OLED-Driver1.spin」と「OLED-Driver2.spin」を載せているので、 ここでは該当部分だけを抜き出して検討しよう。 まず、ドライバを利用する呼び出し側の「Demo_OLED.spin」では、 以下のように外部オブジェクトと広域変数を定義する(クロックの設定と基本色の定義も残しておく)。 

CON
  _clkmode = xtal1 + pll8x      'Use the PLL to multiple the external clock by 8
  _xinfreq = 8_000_000          'An external clock of 8MHz. is used (64MHz. operation)
  _screensize   = (_xtiles * _ytiles * _pixelperlong)   'Size needed for arrays
  _red          = %11100000
  _green        = %00011100
  _blue         = %00000011
  _yellow       = %11111100
  _purple       = %11100011
  _turq         = %00011111
  _white        = %11111111
  _black        = %00000000

VAR
  long MemDisp[_screensize]     'OLED display driver variables 
  long MemWork[_screensize]     'graphics driver variables  

OBJ
  OLED          : "OLED-Driver1"
  Graphics      : "OLED-Driver2"
「OLED-Driver1.spin」は、主としてOLEDの描画処理動作そのものに関するディスプレイドライバである。 メイン側から「start」が呼ばれると、以下のようにOLEDに関するビンの定義を行い、 実際にOLED描画処理を行うCogを起動する。 
PUB start(_MemDisp) : okay
'' Start the ASM display driver after doing a Spin initialize
'' Setup I/O pins, initiate variables, starts a cog
'' returns cog ID (1-8) if good or 0 if no good
  stop                                                  'Keeps two cogs from running at the same time
  MemDispPtr := _MemDisp                                'Copy pointer passed from main program
  CSpin := _OLED_CS                                     'Store I/Os in variables for ASM to access
  DorCpin := _OLED_DorC
  WRpin := _OLED_WR
  RESpin := _OLED_RESET
  VCCEpin := _OLED_VCCE
  RDpin := _OLED_RD
  okay:= OLED_cog:= cognew(@ENTRY, @MemDispPtr) + 1     'Returns 0-8 depending on success/failure
これ以外の処理は「stop」「powerDown」「writeCMD」などであり、 実際のコマンドは「OLED-Driver2.spin」の方で生成する。 残りのアセンブラ領域が、実際にPropellerがOLEDとやりとりしている部分であるが、 これはOLEDそのものの技術資料が無いので、アンタッチャブルなブラックボックスとするしかない。 そして「OLED-Driver2.spin」は、後半のアセンブラ領域では「8*8」と「5*7」ドットのフォントを定義しているだけで、 以下のような描画ルーチンをspinで定義してメインから呼ばれるだけであり、 これは他の処理系でもよくあるものである。(モジュール名前のみ列記) 
PUB setup(_xtiles, _ytiles, _baseptr)
'' Setup the bitmap parameters for the graphics driver, must be run
''  _xtiles    - number of x tiles (tiles are 4 x 4 pixels each because 8-bits x 4 pixes = long)
''  _ytiles    - number of y tilesl
''  _baseptr   - base address of bitmap

PUB clear
'' Clear bitmap (write zeros to all pixels)

PUB copy(_destptr)
'' Copy bitmap to new location for use as double-buffered display (flicker-free)
''  _destptr   - base address of destination bitmap

PUB plotPixel(_x0, _y0, _color) | videoOffset, pixelValue
''' Plot at pixel at x, y, with the appropriate 8-bit color
''  _x         - coordinate of the pixel
''  _y         - coordinate of the pixel
''  _color     - 8-bit color value (RRRGGGBB)

PUB plotLine(_x0, _y0, _x1, _y1, _color) | dx, dy, difx, dify, sx, sy, ds
'' Plot a line from _x0,_y0 to _x1,_y1 with the appropriate 8-bit color
''  _x0, _y0   - coordinate of the start pixel
''  _x1, _y1   - coordinate of the end pixel
''  _color     - 8-bit color value (RRRGGGBB)
''  Based on routine from Phil on Parallax Forum
      
PUB plotCircle(_x0, _y0, _radius, _color) | sum, x, y
'' Plot a circle with center _x0,_y0 and radius _radius with the appropriate 8-bit color
''  _x0, _y0   - coordinate of the center of the circle
''  _radius    - radius, in pixels, of the circle
''  _color     - 8-bit color value (RRRGGGBB)
''  Based on routines from Paul Sr. on Parallax Forum
    
PUB plotSprite(_x0, _y0, _spritePTR) | xpix, ypix, x, y
'' Plot a pixel sprite into the video memory.
''  _x0, _y0   - coordinate of the center of the sprite
''  _spritePTR - pointer to pixel sprite memory location
''  long
''  byte xpixels, ypixels, xorigin, yorigin
''  long %RRRGGGBB, %RRRGGGBB, %RRRGGGBB, %RRRGGGBB
''  long %RRRGGGBB, %RRRGGGBB, %RRRGGGBB, %RRRGGGBB
''  long %RRRGGGBB, %RRRGGGBB, %RRRGGGBB, %RRRGGGBB
''  long %RRRGGGBB, %RRRGGGBB, %RRRGGGBB, %RRRGGGBB
''  .... 

PUB plotChar(_char, _xC, _yC, _font, _color) | row, col
'' Plot a single character into the video memory.
''  _char      - The character
''  _xC        - Text column (0-11 for 8x8 font, 0-15 for 5x7 font)
''  _yC        - Text row (0-7 for 8x8 and 5x7 font)
''  _font      - The font, if 1 then 8x8, else 5x7
''  _color     - 8-bit color value (RRRGGGBB)
''  Based on routines from 4D System uOLED driver    
               
PUB plotText (_xC, _yC, _font, _color, _str) | t
'' Plot a string of characters into the video memory.
''  _xC        - Text column (0-11 for 8x8 font, 0-15 for 5x7 font)
''  _yC        - Text row (0-7 for 8x8 and 5x7 font)
''  _font      - The font, if 1 then 8x8, else 5x7
''  _color     - 8-bit color value (RRRGGGBB)
''  _str       - String of characters
''  Based on routines from 4D System uOLED driver

PRI circleHelper(_cx, _cy, _x, _y, _color)
'' helps to draw a circle on the screen, used with plotcircle
'' Based on routiness from Paul Sr. on Parallax Forum
これらを確認した上で、再び呼び出し側のメインの「Demo_OLED.spin」を眺めてみると、 以下のように、まずドライバ1の「start」を呼び出してOLEDを起動し、ドライバ2の「setup」で表示を初期化し、 MIDI入力モシュールも起動している。 あとはこのシステムでは3つのスイッチ入力をモニタして、3種類のモードを変更している。 
PUB main | mode, x, d, p, dummy, i, color, eraser_count
  OLED.start(@MemDisp)
  Graphics.setup(_xtiles, _ytiles, @MemWork)
  midiIn.start(21)
  dira[18..20]~
  repeat
実際に描画している部分では以下のように、「mode=0」では複数の同心円を描画している。 グラフィックメモリに描画処理を実行して、最後にOLEDに全画素をコピーして表示する手続きが重要である。 
Graphics.plotCircle(48,32,i-5, color)
Graphics.copy(@MemDisp)
「mode=1」では以下のように、移動する線分を表示している。 
Graphics.plotLine(plines[0], plines[1], plines[2], plines[3], color)
Graphics.copy(@MemDisp)
「mode=2」では以下のように、MIDI入力を16進表示させている。 画面が満杯になったらクリアして元の場所に戻す処理「place(p)」は自前である。 
        dummy := midiIn.event
        if dummy <> -1
          d := (dummy & $FF0000) >> 16
          Graphics.plotChar(HexConv(d/16), 3*(p//5)+1, p/5, 0, _green)
          Graphics.plotChar(HexConv(d//16), 3*(p//5)+2, p/5, 0, _green)
          Graphics.copy(@MemDisp)
          p := place(p)
          if (d > $DF) or (d < $C0)
            d := (dummy & $00FF00) >> 8
            Graphics.plotChar(HexConv(d/16), 3*(p//5)+1, p/5, 0, _white)
            Graphics.plotChar(HexConv(d//16), 3*(p//5)+2, p/5, 0, _white)
            Graphics.copy(@MemDisp)
            p := place(p)
          d := dummy & $0000FF
          Graphics.plotChar(HexConv(d/16), 3*(p//5)+1, p/5, 0, _white)
          Graphics.plotChar(HexConv(d//16), 3*(p//5)+2, p/5, 0, _white)
          Graphics.copy(@MemDisp)
          p := place(p)

PUB place(p)
  p := ++p//40
  if p == 0
    Graphics.clear
    Graphics.copy(@MemDisp)
  return(p)
・・・ここまで書いたところで、サンクトペテルブルクからヘルシンキあたり、「目的地まで2時間50分」となった。 暗い機内でお仕事していると、キーボードのバックライトを点灯させていても、 画面のバックライトが最小輝度で十分なので、MacBookAirのバッテリはまだ「残り68%」である。 残りの時間は、楽しいMax/MSP/jitterプログラミングとして、続きは乗り継ぎのフランクフルト空港かな。 日本時間ではもう夜の20時半だが、現地時間は午後3時半、リンツに着くのは夜の23時である。 この1日はまだまだ長い。

さて、1枚のスクリーンショットをここで入れてみたが、既に日本時間は9/1の午前2時を過ぎている。 2時間以上も前に、無事にフランクフルト空港に着いて、リンツへの乗り継ぎを待っているところ。 機内では、けっこうヨーロッパに入ってから揺れていたが、その中でMaxプログラミングをしていて、やや酔った(^_^;)。 同行の学生3人のうち、M2の伊熊さんは待ち合いロビーの長椅子に豪快に横になって爆睡、 M1の小畑さんと鈴木さんは本など読んでいる。 フランクフルト空港のWiFiは、見えているが繋がらないので諦めた(^_^;)。 そして僕は、待合室のカフェのテーブル(コンセントがあるのがポイント!)に一人陣取り、 ここまでMaxのプログラミングの続きをしてきて、なんと一気に、やろうとした事が完成してしまったところである(^_^)。

SDメモリカードのUSBリーダはスーツケースに入れていて手元に無いので、 リンツに着いてからそのうちデジカメ写真を補足するとして、とにかく成功した。 この写真はMacBookAirのスクリーンショットであるが、Maxパッチが完成して動作しているところである。 僕が持っているのはドイツに着いて最初のビールのジョッキをクリアした後のワインであるが。 パソコンのWebカメラでこれをキャプチャーして、jitterで「96*64」の解像度に変換して、 その各画素のRGB値を取得して、これをOLED-PROPのカラー解像度である「R3+G3+B2」ビット、 に変換して、既に1106で完成していたPropellerファームウェァに対して、 XBee経由で「画素の座標とその色」を送信したところである。 画面右下のように粗い画像であり、さらに1画面のスキャンに数秒かかる。 これはまさに、判る人はいないと思うが(^_^;)、ハムのSSTVの世界である。 しかし、これをOLED-PROPで実現しているところが凄いのである。

・・・そして小雨のリンツ空港に到着、今回はバゲッジが早く出て来て、待っているタクシーにサッと乗れたので、 あっさりといつものHotel Locomotiveに着いた。WiFiも快適である。 以下、フランクフルト空港でのPropeller/XBeeシステムの実験の写真だけ、並べたところで、 今日はおおいに進展したので、このあたりにしよう。 予報では初日9/1だけは雨である。土曜日のハウプト広場のフリーマーケット、 そして晩のドナウ川畔のレーザーと花火と音響のショーがどうなるか。やや心配である。

2012年9月1日(土)

リンツ1日目の朝となった。いつもの事だが、夜になかなか眠れず、また夜中の2時あたりに目が覚める。 身体の日本時間は午前中なので仕方ない。 無理矢理に3時間ほど寝て、それでも5時前には目覚めた。 朝5時起床というのはいつものペースなのでこのまま行けばいいが、ヨーロッパに来ても北米に行っても、 午後1-3時あたりに強烈に眠い時間がやってくる(^_^;)。 小雨模様のどんよりとした朝で、気温は11℃ぐらいである。 YAHOO.COMで天気予報を見ると、午前中と午後にたまにシャワーがあるが、 晩には「曇り」となるらしい。寒いけれど、花火+レーザー+音楽、のドナウ川畔のイベントには行けそうである。

朝8時に学生の部屋に電話したら、なんせトリプルルーム(凄く広くて超豪華。僕のシングルルームはシャワーだが、 この大部屋にはバスタプまであった)で3人が身支度するので、予定通りに朝9時に朝食、と確認した。 英語に切り替えるためにテレビでCNNを流しながら、昨日のバグに取りかかることにした。 昨日の夜中に、フランクフルト空港のカフェで実験した写真を上げたが、考えてみれば

この写真は、明らかにおかしい。画素の色についてもバグがありそうだが、なんといっても「画素」が縦長の長方形である。 数えてみると、横方向が96ドットだとすれば、縦方向は64ラインでなく半分の32ラインのように見える。 Propellerモジュールの側だけでなく、Maxの画像処理後のjit.pwindowからおかしい、と気付いたので、 バグはPropellerでなくMax側である。 ちょっと調べて、counterオブジェクトのオーバーフローが常に2発出ていることを発見し、 あっさりとバグは解決してしまった(^_^)。 以下はその様子である。これで気持ち良く、リンツの街に出かけられる。

2012年9月2日(日)

深夜の到着日をカウントしなければ実質リンツの2日目の朝である。 肌寒くて曇っているが、今日からはウイーンの期間まで、ちょっとしたシャワーを別にすれば、 雨は気にしなくて良さそうである。 折り畳み傘を開かずにオーストリア滞在を過ごせるのは有り難い。

昨日(9月1日)はシャワーの予報はあったが、ポツポツの雨はすぐに乾くので助かった。 9時に朝食、10時前にホテルを出て、公共交通1日乗車券MAXI(4ユーロ)を購入、 トラムでまずはハウプト広場に向かうと、小雨予報にいつもの半分ほどのまばらなフリーマーケットであった。 学生は見物だけだったが、僕はつい、「音の出るモノ」を買ってしまった。 ただし、10ユーロが1000円ということで体感は相当に物価が安い。過去には1500円だったのだから。 現地の物価は変わっていないのに、円高でとてもトクした気分になる。 ハウプト広場のアルスエレクトロニカ特設ドームで「本日の予定」を入手、作戦を立てつつ、 まずはアルスエレクトロニカセンターに向かった。この詳細は、後日のフォトレポートに譲る。


2010年にあった沢尻エリカのコスプレ百変化

アルスセンター(入口壁面の沢尻エリカのコスプレ百変化は遂に無くなっていた)では、 当日チケットで常設展示を徹底的に回り、 3階のカフェで一息ついてから、ドナウ川の橋を渡ってハウプト広場に戻り、SL型小型連結バスの観光ツアーに乗った。 これも7ユーロは変わらないが、過去に1000円以上だったのが今年は700円と、とてもリーズナブルである。 その後、去年のイベント会場でもあったMarienDome(オーストリアで2番目に巨大な教会)に行き、 10時から24時まで連続で演奏している"tear drop"という作品と教会の雰囲気を堪能した。 その後スーパーに寄っていったんホテルに戻り、僕は1時間ほど爆睡した。(^_^;)

そして晩になり、防寒具を完備した学生と落ち合って再びトラムでハウプト広場に行き、いつものチャイニーズのバイキングレストランで夕食。 そして大勢の人波とともに、ドナウパークに向かった。 結論から言えば、今年のドナウイベントは初めて、「花火が無い」ものであった。 全てはレーザーとプロジェクション(対岸に等間隔で並ぶ公営住宅マンションの壁面を全てスクリーンに使用)と、 何より全て無線で(つまりXBee !!)同期させた、もの凄い数の高輝度フルカラーLEDによって、全ての視覚的な演出を行った。 花火よりお金がかかっていたかもしれないが、これは来年以降も再利用できるので、 むしろ地球には優しいのだ。 今年のアルスのテーマに対応して、まったく判らないドイツ語の膨大なナレーションに閉口したが、 ショーとしては十分に楽しめた。 膨大な観客はあっさりと増便されたトラムがさばいて、終演が9時半なのに、ホテルに10時には帰れた。

夜中に2-3時あたりに目覚めた(眠れない)のは想定内として、無事に朝6時前まで、ようやく十分に睡眠が取れた。 昨日ゲットしたアルスエレクトロニカのプログラムを詳細にチェックして、今日の予定もキッチリと決まった。 今日はまずはOKセンターに行き、今年のアルスエレクトロニカの入賞作品(インタラクティブアート部門、ハイブリッドアート部門、映像部門の選抜集)と、 企画展示を徹底的にチェックして、その後、登山電車でピクニック、夕方にバスに乗ってこの日だけのパフォーマンスイベントに行き、 夕食後にはこれもこの日だけのサウンドインスタレーション(パフォーマンス?)を見る予定である。 大音量の音楽を鳴らしてウルサイ自動車というのはよく見かけるが、「楽器」としてトンデモナイ重低音を発するクルマ、という作品に期待したい。

・・・ここまでは備忘録としてのアルス日記であるが、ここは元々、Propeller日記であった(^_^;)。 昨日の朝に、画面のスキャンラインがとびとびに半分になるバグは取れたが、まだまだ未完成である。 これはぼちぼち、この欧州ツアーの合間にやっつけていくので、以下、改良すべき点をメモとして列記しておこう。

  • OLED-PROPはRGBミックスで計8ビットと、もの凄く「色」性能が低いが、それにしてもMax画面内でR/G/Bを3/3/2ビットに再量子化させたものに比べて、色がおかしい。この部分はまだチェックしていないので、まずはテストパターン画像を作って、色をちゃんとしたい

  • 写真の記録で判るように、XBeeで送信しているMax側の画像に対して、SSTVのようにスキャンして転送しXBeeで受けたOLED-PROPの画像では、各ラインごとに微妙にデータがふらついてノイズとなり、画面がキタナイ。これは次の転送速度とも関係するが、なんとかしなければならない

  • 上の画面のノイズについては、既に実験したMax/MSP/jitterパッチでは、大きく次の2つのパラメータがあり、それを変化させると状態が明らかに変わる。この部分をきちんと調べる必要がある
    • jitterのマスタークロック(「qmetro」に与えるバラメータ)
    • 画素スキャン→転送のインターバル

  • jitterのマスタークロックはベストエフォート主義なので、もちろん数値として「20」とか「5」とか設定しても、実際に本当に20msecや5msec間隔で処理しているとは限らないが、最適値は調べておきたい

  • Max側の転送元(96*64画素)に対して画素のスキャン→転送をループ処理するのmetro/delayのインターバルは、3msecあたりが最速の上限で、1msecでは完全にデタラメになる(追いついていない)

  • 31250のMIDIでは3バイトのメッセージをみっちり送ると1メッセージで約1msecであった。これは上記とほぼ対応する

  • 現在のところ、Maxの「serial」では最高速度が38400なので、XBeeのスピードをこれに合わせているが、XBeeは112Kbpsまで対応できるので、まだ3倍程度は高速化できる。Macではシリアルドライバの部分にパッチを当てると、正式サポート外で512Kbpsまで出る、という情報を見たことがあるので、この可能性も要チェックである

  • 今回はもともと、XBeeのトランスペアレントモードを使って、MIDIライクなメッセージパケットで画素ごとに転送している。これを、1画面分の画素の全部をバイナリのパケットとして可能な最高速度で伝送し、Propellerの側でOLEDのグラフィックメモリにそのパケットをごっそり転送した場合にどうなるか、というのはより本格的で実践的なアプローチである。これは旅行の片手間では難しいが、まだまだ実験テーマは残っている
・・・ここで8時半、朝食まであと30分となった。 ビデオカメラのムービーを整理して、メイルをチェックして、朝食後はまたまたリンツの街である。 ほぼ時差ぼけが抜けてきたので、今年のアルスの受賞作のチェックに集中していこう。

2012年9月3日(月)

9月3日になった。アルスエレクトロニカも最終日、我々のリンツも最終日である。 昨日、駅で時刻表をゲットしたので、今日の午前には切符を買って、明日の朝、ホテルをチェックアウトして特急でウイーンに向かう。 いつものように夜中の2-3時に目覚めたものの、2度寝して朝5時半に起床した。 こちらは朝6時でも日本は午後1時、月曜になったので、来年に20周年、100回研究会を迎える、 情報処理学会・音楽情報科学研究会の中核メンバーによる検討会議MLから、 「どんなイベントにしようか」という熱い企画案が多数、舞い込んできた(^_^)。

そのMLにコメントをポストしてシャワーを浴び、身支度をして朝食まであと50分である。 昨日について簡単にまとめると、昨日の日記に書いたメニューに従ったが、OKセンターで併設されていた作家の企画展がもの凄いボリュームで、 これを堪能していた煽りを受けて、16時からのパフォーマンスに向かうのはパス、となった。 また、Lentosミュージアムでのんびりしたが、大騒音パフォーマンスのセッティングで大体の様子が判ったので、 夕方早めにホテルに戻った。 日曜日でスーパーもレストランもお休みだったので、途中で営業中のチャイニーズ回転寿司(^_^;)で、 やきそばをテイクアウト、さらに隣のビザ屋で巨大なクウォーターをゲットした。 以下のように学生3人の大きなトリプルルームでの夕食パーティの後、なんと22時過ぎには就寝した。 昼過ぎから日差しが出てきたところを、山の上の教会までピクニック(電車で行くだけ)出来たのが、今回のヒットである。

最終日の今日は、ブルックナーハウスでの上映展示、あとアルスセンター外のu19をチェックする予定である。 YAHOOの1時間ごとの天気予報では、午前から午後の前半にシャワー予報なので、 インドアのブルックナーハウスを先行して、午後の後半は学生はショッピングの自由行動というあたりである。 僕だけone dayチケットでアルスの「Digital Music and Sound Art」のシンポジウムに行くかどうかは、現場で決める。 いつもはFestival Pass(130ユーロ)を購入するので、いつでも何度でも各施設をつまみ食いしたが、 今回は学生と一緒に、「この施設はこの日だけ」という当日券で入場したので、各会場の密度はハンパ無かった。 この手もある、と気付いたのが収穫である。 今回のアルスエレクトロニカは、漠然とした全体的な印象として、経済情勢からたぶんスポンサー関係がシブチンだったのか(^_^;)、 どことなく「音楽」にテーマをすり寄せて来た気がする。音楽をやっていると、あまり盛大に予算がかからないのかな。

なかなかPropellerに話題が向かないが(^_^;)、あと1つだけ。 昨日も一昨日も、何故か情報が舞い込んできて、PerfumeのビデオをYouTubeからゲットした。 例えば これ など、とても秀逸である。 初音ミクおたくのライブYouTube映像に比べて、同じ口パクなのに、このリアリティと躍動感はまったく段違いである。素晴らしい。 これはまさに、口パクであってもエフェクタ満載であってもハイテク駆使であっても、まさに「音楽ライブ」である。 初音ミクのすかすかな存在感に踊らされている人達が気の毒になってくる。 同じオタクなら、生身のPerfumeの方がよほど健康的だと再確認した。(^_^;)

・・・さて朝食まであと15分である。 現在、この欧州ツアーに携行しているPropeller/OLED/XBeeシステムの改良点については、昨日リストアップした通りである。 これをいつ進めるか、という事だが、とりあえずリンツでは、アルスエレクトロニカの視察に傾注しているので(観光もしたが(^_^;))、 ウイーン以降になる、とここで宣言しておこう。 ウイーンでは、僕はまったく行き先についてno ideaであり、「地球の歩き方 ウイーン」を学生たちに預けて、 ここに3人は膨大に付箋を付けているようである。 明日、リンツからウイーンまでの特急の車内で作戦会議なので、僕はそこに付き合うだけである。 学生がウイーンの土地勘に慣れてきたら、別行動で、僕は機材とともにカフェでプログラミング・・・というのが、 今のところの方針である。 ということで、おそらく、今日はここまでである。あしからず。(^_^;)

・・・「あしからず」と書いてから12時間ほど経過したが、まだ9月3日(日本ではもう9/4の朝6時)である。 リンツ最終日もほぼ予定通りに充実して、いろいろな作品展示に収穫が多かった。 ブルックナーハウスでは、NIME04でSUACにも来てくれた、英国Leeds大学のKia Ng教授と偶然にまた再会した(上の写真)。 彼は母国の中国から昨日ここリンツに飛んで来て、明日には英国に帰って、ICMC直前に企画した国際ワークショップを主催して、 その後すぐさまスロベニアのICMC2012に飛ぶ。僕もウイーンの後で電車(6時間ほど)でICMC2012に向かう。 いつも再会するのは海外の国際会議だが、今回は握手をして別れ際の言葉が「来週リュブリャナで会いましょう」というのは面白い。

明日のウイーン行きを前にして、ホテルの部屋でスーパーで仕入れたワイン(日本なら2000円以上するものが3.99ユーロ[400円])を飲みつつ、 とりあえずネットから、OLED-PROPのカラー異常のバグを取るための、カラー版のテストパターン的な画像をゲットした。 こんなのが数分で入手できるとは、本当にいい時代である。

これを使って実際にデバッグするのは、まぁウイーン以降ということで、これで今日は本当にオシマイである。 明日は10時12分発の、日本で言えば「のぞみ」タイプの特急でウイーンに向かう。 2009年のリンツ→ウイーン の時には、たしか「ひかり」タイプだったので、今回はより快適である事を期待しよう。 ただし、YAHOO JAPANで調べて、ヤングなでしこの対ドイツの準決勝が、ちょうどこの特急に乗っている間である、 というのを知ったので、やや残念である。 ウイーンに着いたらホテルに荷物を預けて(チェックインは晩)市内に出るので、試合結果を知るのは数時間後となるのだ。

2012年9月4日(火)

さて、リンツからウイーンへの移動日、9月4日の朝となった。起床はいつものように5時過ぎである。 いつも出張に持参するシェーバーは、満タン充電しておけば3-4日までは余裕で使えるが、遂にこの日、 持参したACアダプター(これだけ100V専用なので小型トランスを経由)で充電することになった。 シェーバーを充電すると、あぁ長期出張だ、と実感する(^_^;)。

大学事務局からのメイルも、9月のweekdayとなってぼちぼち届くようになり、今朝はメディア造形学科の学生で、 また一人、藤田さんの内定情報が就職室から届いた。 彼女は、去年インターンシップの顔合わせで静岡に一緒に行った3人のうちの一人で、残り2人も進路が決まっている。 今年はかなり、例年に比べて就職状況が順調である。皆んな、きちんと準備しているようで、何よりである(^_^)。

今日はこれまでより15分繰り上げて、8時45分から学生と朝食の予定であるが、まだ2時間ほどあるので、 ここで、「進める」というよりは「忘れない」ために、Propeller/OLED/XBeeも進めることにした。 シャワーを浴びていて気付いたが、先日のToDoリストのうち、「XBeeを透過モードからAT/APIモードにする」というのは、 せっかく

いうような技術情報を持参してきたが、この渡欧中には実験できないのであった。 これには、XBeeのフラッシュEEPROM上のモードパラメータを書き換える必要があったのだ。 従って、ここでは「透過モード」での最善を尽くす、というところまでが目標である。

まずは思い出しの思い出し、ということで(^_^;)、以下のように、 ここまで進めてきたものをセッティングして走らせてみた。 問題点はそのまま、しかしシステムはしっかりと稼働している。 Webカメラのモニタjit.pwindowsに映った裸の上半身に驚いたが、 シャワーを浴びて汗が引くまではいつも全裸なのであった(^_^;)。

まず最初に、Maxのパッチには、転送する動画のソースとして、外部ムービーファイルを指定して切り替えられるようにしてあったので、 これで昨日ゲットした8種類の静止画をそれぞれ指定して、現状でどうなっているかを比較した。 輝度を上げるとデジカメがコントラストの差にめげるので、パソコン画面の輝度を下げて、そこにOLEDを手で持っているが、 やはりなんか違うようである。(^_^;)

ここで、最後のテストパターンでのMaxウインドウ内を見ると、以下のように、ソースの画像のカラーと、右下の転送データのカラーとは、 ほぼ一致している。パッチを見れば判るが、これはソースの各画素を「R/G/B = 3/3/2ビット量子化」して、それを再び各カラーに8ビット化しているので、 ここまでの処理は正しそうである。

ということは、このパッチの左側にあるように、「R/G/B = 3/3/2 bits」というデータと、画素の座標の情報を3バイトのメッセージにパックして送る部分のバグか、 あるいはこれが正しかったとすれば、いよいよXBeeで受信した側、つまりOLEDのPropellerのソフトウェアのバグの可能性ということになる。

・・・そして考えること数分、やはりMax側の情報を3バイトのメッセージにパックして送る部分に、 triggerで各データをまとめていく順序のバグを発見した。 これを改良して、試しにいくつかのテストパターンやWebカメラを試したのが以下である。 少なくとも、「カラーが異常である」ということで問題視した、色情報の対応のエラーは解決した模様である。 実際のある色について正しいか、というのは別の問題で、OLED-PROPのマニュアルでも、 「R/G/B = 3/3/2ビット量子化」なので正しい色は出ないので許してねー(^_^;)、と開き直っているので、まぁ、このあたりが限界なのかもしれない。

ここで、朝食まであと30分となった。 荷物のパッキングとメイルのチェックもあるので、まずはリンツではここまで、としよう。 リンツでの3人は、アルスエレクトロニカからデザイン研究科の学生として多くの刺激を受けたと思うが、 ウイーンでは、より広範に、文化と芸術と国際交流を学ぶだろう。決して単なる観光ではない(^_^;)。 ウイーンに昼前に着いたら、ホテルに荷物を預けて、まずはリンクを一周してウイーンの土地勘に慣れて・・・と色々あるので、 今日のPropeller日記はここまでになるかもしれない。

2012年9月5日(水)

ウイーン2日目となる9月5日の朝5時である。今日は理由があって朝食は7時なので、あと2時間ある。 ちなみに今回のホテル : Hotel Cryston は、大正解であった。次回以降、ウイーンに来る機会には、またここに泊まりたい。 U4の駅から見える、という近さはおおいに助かった。 昨日については、特急(新幹線みたいなもの)でリンツからウイーンまで1時間半、お昼にはウイーンに着いたので、 学生は半日以上、みっちりあちこち美術館などを巡ったようである。 僕は 2009年のウイーン で十分、堪能しているので、王宮の庭のベンチでのんびり1時間佇んだり、カフェでビールをいただいたり、と休息日に徹した。 ただし、お約束の「Cafe Mozartのザッハトルテ」とか、「モーツァルト/シュトラウスの弦楽7重奏+ソプラノ+舞踏」というのは、 もちろんウイーン初日ということで、学生と堪能した。


Cafe Mozartのザッハトルテ


モーツァルトの弦楽7重奏+舞踏

さて、「続・Propeller日記」としたものの、旅立つ日にOLED-PROPモジュールのPropellerのファームウェアが出来てしまったので、 ここまでXBee日記、あるいはMax日記になりかけていた(^_^;)。 ただし、まだ色の部分に若干の疑わしさがあるので、ここを、今度はDraw系のコマンドを加えて、確認・整備することにした。 改良の余地はあるものの、Webカメラの画素情報をXBeeで転送してOLED-PROPで表示する、というのを作った際に、 続・Propeller日記(1) では、以下のコマンドプロトコルを定義していた。 また、既にパッチには加えていながら書き忘れていたが、「%11111111」で「OLED全画面クリア」(真っ黒になる)も作ってあった。

  • メッセージは全て3バイトを単位とする
  • 先頭データ(ステータスバイト)のMSBは1で、続く2バイトのデータバイトは7ビットデータ(0-127)
  • ステータスの最初の96バイト(%10000000-%110111111)では、画素単位の描画で、座標とカラーを以下のように定義する
    • カラーは「8-bit color value (RRRGGGBB)」と定義
    • ステータスバイトの下位7ビットがOLEDのX座標(0-95)
    • 2バイト目のデータバイト(7ピット)の下位6ビット(bit 5-0)がOLEDのY座標(0-63)
    • 2バイト目のデータバイト(7ピット)のbit 6がカラーのMSB
    • 3バイト目のデータバイト(7ビット)にこのカラーのMSBを加えた8ビットが、その画素のカラー(RRRGGGBB)
  • ステータス最後の「%11111111」が1バイト目に来た場合、2-3バイト目の内容を無視して、OLEDの全画面をクリア(→真っ黒)
  • 残り31バイトのステータス(%11100000-%11111110)は、今後の定義を待つreserved

そこで、「color_set」(後の描画コマンドでのカラー指定)、「move_to」(ラインを引く起点の座標の指定)、 「line_to」(終点座標を指定してラインを指定カラーで描画し、終点座標を起点座標に代入する)、 「line_draw」(終点座標を指定してラインを指定カラーで描画し、起点座標は変えない)、などのコマンドを整備すれば、 LINE系のDrawグラフィクスをXBee経由で飛ばせる筈である。 さらには、PropellerのOLEDモジュールのグラフィックドライバに「楕円」「矩形」の定義があったので、 これらもMaxの側で簡単に定義できる・・・という構想である。

上記のアイデアを、さきに再掲したプロトコルと会わせた形式で書けば以下となる。 このコマンド定義が、プログラミングのリファレンスである。 なんか MIDIのプロトコル定義 を思い出す。(^_^)

  • ステータスバイト「%11100000」 - color_set (後の描画コマンドでのカラー指定)
    • 2バイト目のデータバイト(7ピット)のLSB、つまりbit 0がカラーのMSB
    • 3バイト目のデータバイト(7ビット)にこのカラーのMSBを加えた8ビットをカラー(RRRGGGBB)とする
    • このコマンドでは描画しない。後の描画コマンドのためのカラー指定である
  • ステータスバイト「%11100001」 - move_to (ラインを引く起点の座標の指定)
    • 2バイト目のデータバイト(7ピット)がラインを引く起点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く起点のY座標
    • このコマンドでは描画しない。「line_to」と「line_draw」コマンドのための起点座標指定である
  • ステータスバイト「%11100010」 - line_to (ラインを引き終点を新しい起点とする)
    • 2バイト目のデータバイト(7ピット)がラインを引く終点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く終点のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 終点座標を指定してラインを指定カラーで描画し、終点座標を起点座標に代入する
  • ステータスバイト「%11100011」 - line_to (ラインを引き起点はそのまま)
    • 2バイト目のデータバイト(7ピット)がラインを引く終点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く終点のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 終点座標を指定してラインを指定カラーで描画し、起点座標はそのまま変化させない

ここまで定義すれば、いよいよ久しぶりにbstの出番である(^_^)。 当面、グラフィックドライバの「OLED-Driver1.spin」と「OLED-Driver2.spin」はそのまま参照して、 メインの「XBee_002.spin」を複製して「XBee_003.spin」にリネームし、 これまで作ったものに「追加」するだけ、という方針である。 まずはホテルのデスク上に以下のようにセッティングして、あとは楽しいプログラミングである。 合わせてMaxの側も、この新しいコマンド定義をXBee経由で送るように改訂する。

・・・と進めてきたが、ここで6時40分、7時に朝食で学生と顔合わせするので、ここまでである。 Maxのパッチを以下のように改訂して、画素スキャンの部分をサブパッチに移動して、コマンド送出部分をコピペ改訂して、 カラー設定コマンドを作りかけたところである。

実は、今日はこれから、なんとウイーンから日帰りのプチ海外旅行に行く予定なのである(^_^;)。 昨日、学生と「Cafe Mozartのザッハトルテ」を楽しんだ後、午後はそれぞれ自由行動ということで別れた。 その後の大部分は公園やカフェでのんびりしていたが、そこでフト思い出したのが、ボートクルーズである。 考えてみると、海外に出かけた際に、ちょっとした合間の時間を見つけては、「遊覧船」を楽しんできた。 2003年のシンガポール でも、 2004年のパリ でも、 2006年のパリ でも、 2007年のニューヨーク でも、 2007年のロンドン でも、 2009年のパリ でも、 2011年のオスロ でも、形はいろいろだが、ボートを楽しんできた。

そこで、たぶんドナウ川のボートクルーズがあるだろう、とマップを調べて、その船着き場に行ってみた。 すると、そこで発見した別のパンフレットが、なんと「ブラチスラバ往復ジェット船」というものであった。 ウイーンとスロベキアのブラチスラバは60kmしか離れていないので、所用1時間15分(帰途はドナウ川を遡るので1時間半)、 平日なら片道29ユーロで行けるのであった。 こんな面白いものは行くべきだ、と突然に思い立ち、 2003年のシンガポール でも半日だけマレーシアのクアラルンプールに渡ったのと同じノリで(^_^;)、行くことにしたのである。 なんとか夕方までは以下のように好天らしい。

2012年9月6日(木)

SUACを出発したのが先週の木曜日(8/30)だったが、それから1週間が経過した木曜日、ウイーン3日目の9月6日である。 僕はようやく後半戦に突入したが、今日は学生3人が帰国する日である。 いつものように朝5時過ぎに起床、日本は平日の午前中ということで、お仕事関係を含む多数のメイルをまず処理。 今日はfacebookから「5人のメンバーからあなたの招待を依頼されました」という、いつもの余計なお世話メイルが届いた。 mixiこそ招かれて(不本意で)入ったものの(^_^;)、僕はブログもツイッターもフェイスブックもパスなので、 申し訳ないが招待は無駄で不要である。

学生と別行動で行った、昨日のスロベキア(ブラチスラバ)は、好天もあり素晴らしいリフレッシュとなったが、 これはいずれのフォトレポートで紹介するとしてパス(ここまでデジカメ写真は約2500枚)。 昨夜は学生とウイーン最後の夕食に、とオペラで待ち合わせしたが、ベトナム人の「嘘SUSHIレストラン」でない、 たぶん日本人の経営している日本食レストランも、そろそろチャーハンの恋しい中華レストランも、 学生は断固パスして、「VIENNAレストラン」、つまり当地の夕食を選択した。偉い(^_^)。 僕は、ドイツのフランクフルトソーセージよりも巨大で柔らかいソーセージを堪能した。

さて今日であるが、あと15分で、8時に学生と朝食、その後、学生はチェックアウトをしてスーツケースはホテルに預けておき最後の観光に出かけて、 僕と14時ホテルで待ち合わせてウイーン空港に向かう。僕はフライトのチェックインまで見送る予定である。 そして今日は、僕はそれまでは部屋でお仕事することにした。 プログラミングというのは、中途半端で止めておくと良いことが無いのである。 昨日のブラチスラバは、コダーイやバルトークの音楽で親しんでいるマジャール語の正に「ふるさと」、 ここで元気を充電したので、気合いが高まってきた。 明日のリュブリャナ行きの列車のチケットをさきほどオンラインでゲットした(6時間の長旅なので、奮発して1st class)ので、 これをホテルのフロントでプリントしてもらえば、わざわざ駅に買いに行く必要もなくなった。

そして午前9時、上の写真のように、1週間、元気に過ごした学生たちは最後のウイーン観光に出かけていった。 M2の伊熊さんは市内中央のシュテファン教会の尖塔に登るらしい。 M1の小畑さんと鈴木さんは、日本で言えば東急ハンズのようなホームセンターを散策するという。 リュブリャナ行きチケット をフロントでブリントしてもらったが、出発/到着時刻も号車も座席も、情報が見当たらない(^_^;)。 ネットでは1日3本だったこの列車、どうやら現在は1日1本らしいので出発/到着時刻が無いのはOKだが、 果たしてこれだけでいいのか、若干の不安がある。駅に行って確認することにしよう。

さて、いよいよホテルに缶詰でのお仕事タイムであるが、まぁ、お仕事というよりは「お楽しみタイム」である。 システムをセットして、作りかけのパッチを走らせてみると、一部、「赤」があまり赤くない。 これはRGBの8ビットの中で、「赤」の3ビットのMSBだけ別に処理しているので、 最大重みの処理部分のどこかにバグがある可能性がある。 いま作りかけのライン描画が出来たら、「真っ赤なライン」を試してみることにしようか。 一応、以下のように、OLED-PROMの角度を変えて撮影してみた。 こうして見ると、やっぱり、何かおかしい。(^_^;)

そしてMaxパッチに取りかかること数分で、RGBのRの部分に、まさにバグを発見した(^_^;)。 Rの3ビットのうち下位2ビットについて、5ビットシフトの「* 32」が抜けていた。 これを以下のように解決して、みると、奇麗にテストパターンがカラーで再現できた。

そして、このバグは昨日のパッチにもあった筈なので、以下のように修正してみると、ちゃんとWebカメラのモニタも正確になった。 OLEDのカラー性能を低く見ていたが、なかなかどうして、立派にフルカラーであった(^_^)。

これでカラー問題は解決して、後顧の憂いが無くなった。あとは進めていくだけである。 まずは以下のように、コマンド定義に従って、ライン関係の3つのコマンドを送る部分を用意した。

Max的には、プログラミングとしてこれで出来上がりだが、Webカメラや静止画の時と同じように、 OLEDの画素の解像度とカラーの量子化に対応したウインドウを持って、「こうOLED表示される筈」というのを、 Max側でもあらかじめ表示するには、「jit.lcd」を作ればいい。 動いてしまえばこのモニタ画面は不要かというとそうでもなくて、グラフィック表示のコマンドをばんばん送った場合に、 XBeeの通信の部分のボトルネックでうまく行かないのかどうかを確認するためには、後々まで有効そうである。 そこで以下のように、きちんと作ってみた。

なお、ここでの定義の「color_set」(後の描画コマンドでのカラー指定)はMax/MSP/jitterの「jit.lcd」の「frgb」と互換であり、 「move_to」(ラインを引く起点の座標の指定)も「moveto」と互換、 「line_to」(終点座標を指定してラインを指定カラーで描画し、終点座標を起点座標に代入する)も「lineto」と互換であったが、 「line_draw」(終点座標を指定してラインを指定カラーで描画し、起点座標は変えない)は自分で作った。 これは、 「Processing日記」 の最初の方のサンプルで、放射状の直線群を描くのに、ぜひ欲しいと思っていた描画モードである。 Maxの「jit.lcd」の「line」というサブコマンドは、「moveto」や「lineto」で描画した現在値からの、相対座標での描画のようである。

・・・ここで時計を見ると、すでに12時45分である。合間にメイルやニュースをチェックしながのプログラミングで、 ちょっと残り時間が限られてきた(^_^;)。 久しぶりに(フランクフルト空港のカフェ以来?)bstを開いて、新しいコマンドの部分を追加していくと、 MaxのMaxウインドウに「print」オブジェクトで表示しつつデバッグして、30分ほどで、以下のように出来てしまった。 Macの中のMaxウインドウの中のjitterウインドウの中と同じものが、OLED-PROPで表示されている。 当たり前のことでも、これはいつになっても、嬉しい。(^_^)

改訂したPropellerのプログラムは以下である。 mainのところに、単純に4つのコマンドを追加しただけであり、OLEDのグラフィックドライバを呼び出すだけでOKだった。(^_^) 

CON
  _clkmode = xtal1 + pll8x      'Use the PLL to multiple the external clock by 8
  _xinfreq = 8_000_000          'An external clock of 8MHz. is used (64MHz. operation)
  _OUTPUT       = 1             'Sets pin to output in DIRA register
  _INPUT        = 0             'Sets pin to input in DIRA register  
  _HIGH         = 1             'High=ON=1=3.3v DC
  _ON           = 1
  _LOW          = 0             'Low=OFF=0=0v DC
  _OFF          = 0
  _ENABLE       = 1             'Enable (turn on) function/mode
  _DISABLE      = 0             'Disable (turn off) function/mode
  _xpixels      = 96                                    'Screen width
  _ypixels      = 64                                    'Screen height          
  _pixelperlong = 4                                     'Each tile requires 4 longs
  _xtiles       = _xpixels/_pixelperlong                'Each tile is 4 pixels x 4 pixels
  _ytiles       = _ypixels/_pixelperlong                                        
  _screensize   = (_xtiles * _ytiles * _pixelperlong)   'Size needed for arrays
  _red          = %11100000
  _green        = %00011100
  _blue         = %00000011
  _yellow       = %11111100
  _purple       = %11100011
  _turq         = %00011111
  _white        = %11111111
  _black        = %00000000

VAR
  long MemDisp[_screensize]     'OLED display driver variables 
  long MemWork[_screensize]     'graphics driver variables  

OBJ
  OLED          : "OLED-Driver1"
  Graphics      : "OLED-Driver2"
  midiIn        : "XBee_In2"
  midiOut       : "XBee_Out"

PUB main | dummy, i[3], p, num, d, x, y, color, x0, y0, x1, y1
  OLED.start(@MemDisp)
  Graphics.setup(_xtiles, _ytiles, @MemWork)
  midiIn.start(21)
  midiOut.start(20)
  num := 0
  repeat
    i[0] := cnt & $8000000
    if i[0] <> i[1]
      i[1] := i[0]
      num := ++num & 127
      dummy := $C00000 + num
      midiOut.fifoset(dummy)
    dummy := midiIn.event
    if dummy <> -1
'      p := Hex_Display(dummy, p)
      d := (dummy & $FF0000) >> 16
      if d == $FF
        Graphics.clear
        Graphics.copy(@MemDisp)
      elseif d < $E0
        x := d & $7F
        d := (dummy & $007F00) >> 8
        y := d & $3F
        color := d & $40
        d := dummy & $00007F
        color := color + d
        Graphics.plotPixel(x, y, color)
        Graphics.copy(@MemDisp)
      elseif d == $E0
        color := dummy & $00007F
        d := (dummy & $000100) >> 1
        color := color + d
      elseif d == $E1
        x0 := (dummy & $007F00) >> 8
        y0 := dummy & $00003F
      elseif d == $E2
        x1 := (dummy & $007F00) >> 8
        y1 := dummy & $00003F
        Graphics.plotLine(x0, y0, x1, y1, color)
        Graphics.copy(@MemDisp)
        x0 := x1
        y0 := y1
      elseif d == $E3
        x1 := (dummy & $007F00) >> 8
        y1 := dummy & $00003F
        Graphics.plotLine(x0, y0, x1, y1, color)
        Graphics.copy(@MemDisp)

PUB Hex_Display(dummy, p) | d
  if dummy <> -1
    d := (dummy & $FF0000) >> 16
    Graphics.plotChar(HexConv(d/16), 3*(p//5)+1, p/5, 0, _green)
    Graphics.plotChar(HexConv(d//16), 3*(p//5)+2, p/5, 0, _green)
    Graphics.copy(@MemDisp)
    p := place(p)
      if (d > $DF) or (d < $C0)
        d := (dummy & $00FF00) >> 8
        Graphics.plotChar(HexConv(d/16), 3*(p//5)+1, p/5, 0, _white)
        Graphics.plotChar(HexConv(d//16), 3*(p//5)+2, p/5, 0, _white)
        Graphics.copy(@MemDisp)
        p := place(p)
      d := dummy & $0000FF
      Graphics.plotChar(HexConv(d/16), 3*(p//5)+1, p/5, 0, _white)
      Graphics.plotChar(HexConv(d//16), 3*(p//5)+2, p/5, 0, _white)
      Graphics.copy(@MemDisp)
      p := place(p)
  return(p)

PUB place(p)
  p := ++p//40
  if p == 0
    Graphics.clear
    Graphics.copy(@MemDisp)
  return(p)         
            
PUB HexConv(d)
  if d<10
    return("0"+d)
  else
    return("A"+d-10)

PRI pauseMSec(Duration)
  waitcnt(((clkfreq / 1_000 * Duration - 3932) #> 381) + cnt)
学生がホテルに戻ってくるまであと20分である。 部屋の掃除も、出かけてからとお願いしている。 これで、気持ち良くウイーンを後にして、リュブリャナに向かうことが出来そうだ。

そしてホテルに戻って、今19:30過ぎである。日本は既に9月7日(金)の午前2時半過ぎである。 上の写真のように、学生とウイーン西駅からリムジンバスでウイーン空港に行き、チェックインまで見届けて見送った。 この時点をスタートとすれば、学生のフライトはミュンヘンに18時前に着き、いまは乗り継ぎ待ちで、 あと1時間ほどで出発、11時間半のフライトで成田に着くのは午後3時半。 そこからセントレア行きのフライトに乗り継いで、浜松に帰着するのは21時から22時あたりで、ちょうどスタートから24時間後の帰国である。

僕はウイーン空港から市内直行のCity Airport Lineで戻り、若干の不安のある明日の出発駅「Wien Meildling」駅に行ってみた。 「i」(インフォメーション)で確認したところ、

  • on-lineで購入したチケットは「オープン」なので、その日のどの列車にも乗れるので出発/到着の時刻記載が無い(ただしウイーン→リュブリャナは1日1本しか走っていないので選択の余地なし(^_^;))
  • ホームは当日にならないと確定しないので、駅に来て表示を見るべし
  • 乗る号車と座席は指定が無いので、駅に来て好きなところに乗れ(^_^;)
  • この列車は始発なので1時間前からホームにいる
という確認が出来た。ホテルの朝食は朝7時からなので、出発に余裕を持つなら朝食パスでチェックアウトかな・・・というあたりで、 明日のスロベニア行きについては不安要素が無くなった。 過去には、帰国の乗り継ぎフライトの関係で空港に朝5時/6時に行くため、午前4時とか午前5時にタクシーを予約してホテルを出発、 というような荒技を何度も経験してきているので、朝7時出発というのはまったく問題ない。

その後、馴染みのSchwedenpl駅のチャイニーズのファストフードで夕食をとり、ホテルに戻った。 あとはぼちぼち、ワインをいただきながら、もしかしたらMaxのパッチを整理するかもしれないが、まぁ焦らずにいこう。 テレビのCNNは米国大統領選挙の話題ばかりで何も面白くない。 もちろん、CNNから(つまり世界的には)日本に関するニュースはまったく来ない。 ニュースで届く世界中の惨状に比べて、日本は平和ボケなのかなぁ。(^_^;)

2012年9月7日(金)

ウイーンを発つ日となった。 テレビのCNNでは米国の大統領選挙が盛り上がっているようだが、YAHOO JAPANで読む日本のニュースは、 あいかわらずパッとしない(^_^;)。 こちらの天気は以下のように、ウイーンもリュブリャナも良好のようである。 学生は傘を一度も開かずに帰っていったが、さてどうなるか。 日本の天気を見てみると、台風も無いようで、これも何よりである。 昨日の下見で、ホテル至近のメトロの駅のホームに下りる階段だけ頑張れば、 あとはスーツケースを押しながらでも「Wien Meildling」駅に容易に行けると判明したので、 タクシーを呼ばずに歩くつもりである。

ウイーンからリュブリャナまでの列車の旅では、もちろん沿線の風景が楽しみだが、 なんせ時間がタップリあるので、「iPod touch」「数独」「Maxプログラミング」「Propeller実機でテスト」などで過ごす予定である。 1日1本の国際列車の車内がどんな雰囲気なのか、未経験でまったく不明なので、これは乗り込んでから考えることにする。 そういえば、リンツとウイーンがあるので、まったく読んでいなかった「地球の歩き方 スロベニア」があった(^_^;)。 いつものように、僕が行くところに関係したページだけ残して他を捨ててみると、ものすごく薄ーくなってしまった。 まずはこれを読んでいくことにしよう。

・・・そして13時間が経過した。詳細はとても書ききれない(^_^;)。 ところで、これまでリンツとウイーンではホテルのWiiFiが快適だったが、ここにきて久しぶりに通信環境に苦労しそうである(^_^;)。 列車で6時間の旅を終えてリュブリャナに着き、14時半あたりにホテルにチェックインした時にはWiFiが繋がったが、 21時半にホテルに戻ってみると、WiFiの電波はあるものの、繋がってくれない。 たまたま綱がっても切れてしまう。 これは過去の経験から、ホテルのWiFi環境が貧弱な場合に起きるので、もう夜のネットは諦めるしかない。 まぁ、週末になったので、お仕事関係のメイルは来ないだろうし、来週になればICMC2012の会場で繋がるだろう。 仕方ないので明日の朝4時に目覚ましをセットして、寝ることにした。

2012年9月8日(土)

まず最初にお断りすると、この日の日記はPropellerと関係なく(^_^;)完全に旅行メモであるが、いまリュブリェナ2日目の朝4時半である。 昨日のウイーン→リュブリャナの列車は、「iPod touch」「数独」「プログラミング」とも完全に皆無であった。 1等車両のさらにビジネスコンパートメントを一人で優雅に独占して、 「おぉぉすげー」とか独り言しながら沿線の風景にウケつつ写真を撮りまくっているだけで、気付いたら半分の3時間を過ぎていた。 これから行くリュブリャナとICMCについて完全に無知だったのに気付き、2時間ほどかけて「地球の歩き方 スロベニア」を読み、 またICMC2012のプログラムと施設位置を地図で確認して、市内にあるお城とか、「旧市街」あたりで十分に見所が満載なのを確認した。

そしてホテルにチェックインすると、無事に帰国した学生の一人(鈴木さん)のバゲッジがロストした、という情報が届いたが、 ちゃんと書類を出したということで、とりあえずは一安心。 ホテルの近くの民俗学博物館に行き、さらにケーブルカーでお城に上って、素晴らしい市街の眺めを堪能した。 夕食は「地球の歩き方」にあったレストラン「寿司ママ」に迷わず直行、1週間ぶりの日本食テイストを堪能した。 このレストランで食後のワインとともに悩んだのが、翌日、つまり今日の予定であった。 ICMCは日曜日に始まるので、土曜日マルマル、そしてプログラムで判明したのがICMCスタートは日曜日の夕方なので、 日曜日もほぼ昼間、空いているのであった。

こういう場合にはいつも、エクスカーションを活用している。 駅付近に朝に集合して晩に帰ってきて解散するまで、1日コースの観光バスツアーであり、 ホテルにあったパンフレットでも、110ユーロを越える豪華コースから、55ユーロの半日コースまで、 たくさん載っていた。世界遺産の「世界最大の鍾乳洞」とか、それぞれソソラレルものが満載。 週に1日、ある曜日だけのツアーもあるが、土日だったので選択肢はとても多かった。 いつものパターンであれば、このうちどれかに行っていたと思う。 2004年のパリ でも、世界遺産モンサンミッシェルへの1日エクスカーションに行ったが、たしか150ユーロだった。 今でも15000円であるが、当時は22000円以上だったので、大奮発だった(^_^;)。

・・・しかし、今回は違った。 ウイーン→リュブリャナの6時間以上の列車の旅で、鉄道の旅オタである自分に火がついてしまった。 かつて高1の時には このように、 4泊5日列車乗り詰め(4泊とも寝台/夜行列車)の一人旅で、「水戸発水戸行き」の切符で、 本州一周(ちゃんと紀伊半島もぐるっと回る)をした身であった。 そして、たまたまウイーンで、ジェット船によるブラチスラバ1日ツアーに行き、訪問国を1つ追加したのも、 大きな伏線である。 そしてその大好きな列車の中で「地球の歩き方」を見ると、なんと以下のように、 リュブリャナからそこそこ100kmほどの距離で国境を越えて、隣国クロアチアのザグレブ、あるいはリエカに行けそうな鉄道があったのである。

エクスカーションでも、スロバニアのほぼ中央にあるリュブリャナからは、国境付近の観光名所に100キロ以上のバスツアーとなり、 移動距離は同じだが、そこそこ高額である上に、バスである。 そこでリュブリャナの駅に到着した際に「i」に行き、「リュブリャナ→ザグレブ」「リュブリャナ→リエカ」の時刻表を、 以下のようにプリントしてもらっていた。なんと片道15ユーロと安い(^_^)。 これらの資料とワインとともに「寿司ママ」で悩んだ結果、大都市ザグレブでなく、 「アドリア海」という未知の海に面しているというリエカに行くことに決めたのである。 実質的には1日1往復のリエカ行きの列車は朝06:20に出発し、3時間ほどの旅である。 リュブリャナに帰ってくるのは23:30と深夜である。 リエカがどういう場所か、何があるのか、まったく白紙である。ネットで調べようにもWiFiが不調で駄目(^_^;)。 行ったところで何とかしよう、という作戦である。これでクロアチアという、もう1国、訪問国が増える。

22時に寝たが午前2時前に目覚めて、さすがに深夜ならWiFiも混んでいない筈・・・と試してみると、やっぱり駄目である。 昼間はアッサリとデスクの上で繋がったのに、深夜でこれなら原因はパソコンの場所だ、と室内をうろうろすると、 ドアから入ってすぐの、シャワートイレのドア前ではWiFi絶好調を確認した。 これなら、メイルとかFTPはここで出来る、とやや安心した。 そして朝4時に起床してここまで書いてきた。 これをWebに上げたら、もうあと18時間は途絶する。 鉄オタ(乗り鉄)には、たまらない一日となりそうである(^_^)。 というわけで、ホテルに帰ればもう今日が終わっている筈なので、今日はここまで。

・・・と書いたが、ちょうど7時間後、この部分を書き始めたのが上の2枚の写真の場所である。 暑い日差しと心地よい風が通り抜ける浜辺のカフェでワインを楽しんでいるここは、アドリア海、リエカから車で30分ほどのビーチリゾート、 OPATIJAというところである。 もちろん、リエカだって昨日まで知らないところだったのでまったく未知の場所だが、どうやらここは、 8-9月にパリ市民とかが無人になる(ショップは中国系か中東系の店員に任せる)、という、その欧州市民がバカンスに訪れている場所らしい。 いたるところにカジノがあり、リンツどころの比ではない。内陸のリュブリャナとはまったく違う、まさに地中海の畔である。 14-17時のグラスボートクルーズを予約したので、出航までの1時間ちょっと、ここで美味しいビールと美味しいワインとともに、 忘れないようにここまでを記しておこう。

朝6時20分発のリエカ行きの列車に乗るためにリュブリャナ駅に行ってみると、前夜から飲んで帰れない若者が多数、夜明かししていた(^_^;)。 15ユーロと聞いていたチケットが往復で24ユーロだったので、ここは2等でなく1等車両だ、とまたコンパートメント独占で乗ったが、 何故か車掌は「チケットは2等だけど、それでいいよ」と追加料金を取らなかった(^_^;)。 沿線の風景に驚嘆しつつ写真を撮っていると、2時間半の後半、スロベニアからクロアチアに入るあたりで、 駅でもない場所で列車が止まった。 そこで何故か、若者がたくさん、列車から下りてどこかに行ってしまった(^_^;)。

その後、コンパートメントにやってきたのは、いかめしい制服の出入国審査官?である。 ここでパスポートを出せ、と言う。 なるほど、スロベニアはEUに入っているので、フランクフルトでEU域に入国して、そこからオーストリアへの移動も、 スロバキアへの日帰り観光も、さらにスロベニアへの移動も、国内感覚でOKだったのだが、 どうやらクロアチアはEUに加盟していないらしい(^_^;)。 こりゃ大変だ。

ここで何やら文句を言われたが、"English, please."と言っても、ドイツ語しか出来ないらしい。 そんな審査官がいるのかなぁ。 そこへ、ちょうど同じ列車に乗っていた若者がやって来て、彼はドイツ人かオーストリア人らしく、 ドイツ語と英語を通訳してくれた。 どうやら、審査官が引っかかったのが、僕のパスポートの以下のページで、 8/31にフランクフルトからEUに入国しているが、もう9/5には出国しているじゃないか、という事だった。(^_^;)

同じような日付けであるが、実はこれは去年なのだった(^_^;)。何度も行っているアルスエレクトロニカに合わせて、 僕のパスポートには、ほぼ同じ日付けのスタンプがたくさん押されていたのである。 通訳が入ってくれたおかげで、無事に今年のEU入国のページを提示して。審査官は以下のように、「EU(スロベニア)からの出国」というスタンプを押してくれた。 軽いノリでクロアチアに来たけど、これは大変だ。 2003年のシンガポール で日帰り観光でクアラルンプール(マレーシア)に行った時にも、列車が途中のヘンな駅で止まって乗客全員が下ろされて出国審査し、 帰りにも入国審査に並んだのを思い出した。

そしてまたしばらく走ると、国境を抜けたらしい駅でまた列車は止まった。 通訳してくれた彼が僕のコンパートメントに来て、「日本からクロアチアにはビザ無しで入れるのかい?」と聞いてきた。 僕が買った「地球の歩き方」には、スロベニア・クロアチア・ボスニアヘルツェゴビナの3国が入っていたが、 関係ないと捨ててしまっていたので(^_^;)、この情報は不明だ。 知らないので審査官に聞いてみるよ、と開き直っていたが、 上の写真のパスポートのページを見ると、クールなおばさん審査官(さすがに写真は撮れない(^_^;))は、 以下のように、同じページに「クロアチアに入国」というスタンプを押してくれた。 通路の向こうで見守っていてくれた彼と目が合い、ニヤリと親指を立て合ってGood Luck ! である(^o^)。 これで、リュブリヤナに帰る列車では、さらに「クロアチア出国」と「EU(スロベニア)入国」というスタンプが加わるのだろう。 軽いノリで来たが、これは大変な海外旅行なのだった。 もしビザが必要であったら、あそこで下ろされて、その後もタイヘンだったろう。

そして車窓にいきなり紺碧の海が見えてきた。 しばらく走ってリエカ駅に到着、とりあえず周遊ボートは船があるあたりだろう・・・と港のある中心部に行った。 そして苦労して「i」を探して入ってみると、ボートとかは別の「交通i」だ、と言われて別のオフィスへ。 そして判明したのが、リエカは地中海航路などの長距離航路の港であり、ここには無い、ということ。 アドリア海の周遊ボートは、OPATIJAというところにあり、バスで30分ぐらいなので、そこに行って聞け、という。 もらったマップにバス乗り場をマークしてもらって、バスの乗り方を聞くと、タバコ屋でバスチケットを買え、という。 そこで近くのキオスクに行って「バスチケット」と頼むと、なんだか判らない数字と単位を言う(^_^;)。 ここで判明したのが、クロアチアはEUに加盟していないぐらいなので、貨幣はユーロでは無かったのだ。 そこでキオスクのおばちゃんに「エクスチェンジは?」と聞くと、広場の向かい側にあるのでそこに行け、という。 単位の呼び方も知らないまま、とりあえず50ユーロだけ両替してみたが、 単位は不明だが、以下のようなレート(1ユーロが7KN[クローネ??])であった。こりゃ大変だ。 たくさん両替して、余ったら、リュブリャナに戻っても使えない。(^_^;)

そして現地通貨でキオスクでバスチケットを買い、バス乗り場に行って待ち、来たバスに乗ってOPATIJAにたどりついてみれば、 なんとも以下のようなビーチリゾートだった、というわけである。 ずっと2時間半、山や渓谷を走ってきた列車が「いきなり紺碧の海」に出たという、あの場所が、 ここOPATIJAだった(列車の時刻表でここだけ載っていた)のだ。 まぁ、海外出張の前半であれば、こんな馬鹿な思いつき日帰り旅行など無いのであるが、 今回はリンツ・ウイーンですっかり慣れてきたこと、ウイーンからブラチスラバ日帰りを堪能したこと、 ウイーンからリュブリャナの6時間の鉄道を堪能したこと、などが伏線となっての偶然(ノリ)である。 旅好きとしては、こういうのも、まぁ、アリである。(^_^)

・・・そしてさらに9時間後、この部分を書き始めたのはリュブリャナに帰る列車の中、すでに無事に国境を越えた後である。 リエカ行きの列車で一緒だったドイツ人?の彼(彼も乗り鉄/撮り鉄であった)も同じように日帰りらしく、乗っていた。 国境審査官がどういう仕事をしているのか不明だが、クロアチアからの出国審査のストッブで軽く20分は待たされ、 パスポートのスタンプを押さないので聞くと、「出国では何もしない」とのことだった(^_^;)。 そしてスロベニアに入国した駅での入国審査のストップは30分ほど。僕はいったんパスポートを持っていかれて、 戻ってくるまで15分ほどはちょっとハラハラだった。 いろいろ盛りだくさんだった内容はフォトレポートに譲るとして、とりあえず以下は行ったところと無事に加わったスタンプである。

出入国審査にかかる時間は列車のタイムテーブルに織り込まれているようだが、 今回は両方でだいぶかかったので、明らかに「飛ばして」いる。 飛ばして挽回できるようにしているらしい。 それでも時刻表よりは遅れると思うが、まぁ終着なので関係ない。 とりあえずホテルに戻ったらFTPしてから爆睡しよう。 明日はいよいよ晩からICMC2012がスタートだが、日曜ということで、フリーマーケットと教会を覗いて、 さらにいくつか博物館/美術館を巡る予定である。 残りの車中は、バッテリがあれば、ちょっとだけMaxプログラミングでもしてみよう。

2012年9月9日(日)

ICMC2012初日(といっても晩から)の9月9日である。前日については上のようなことなので、詳細省略(→後日のフォトレポート)。 この日は晩からスタートするICMCに向けて「Ljubljanaを歩き倒す」という日である。 朝7時再起床、ヤングなでしこの無回転シュートのYouTube動画を保存して、朝食後の9時過ぎにホテルを出た。 そして「地球の歩き方」に「毎週日曜日の朝に開催」とあったフリーマーケットに行ってみたら、何故か、やっていなかった(^_^;)。 まぁ、初日の午後-夕方とは太陽の位置が違うので、改めてリュブリャナの街の美しい風景をたくさん撮れた。

そして、次に予定していた国立美術館に行ったが、朝イチということでたった一人で独占(^_^)。 ここは「カメラNG」ということで、1枚だけ気に入った絵をこっそり撮ったら、 すかさず監視のお姉ちゃんが飛んできた。 どうやら、監視カメラを手元の携帯でモニタしつつ、さりげに(といっても足音がデカい)僕を監視しているるらしい(^_^;)。 その、気に入った絵の入ったカタログを購入して、次にティヴォリ公園とティヴォリ城の展示に行き(散歩)、 さらに「地球の歩き方」にあった「ビール博物館」に行ったら、なんだか閉まっていて、 入口でウロウロしていたら入れてくれた守衛さんによると開館は「毎月第一火曜日だけ」に変わったそうで、入れなかった(;_;)。 でも、外からの写真を撮らせてもらって満足。

そして、他の博物館をパスしても狙っていた「鉄道博物館」に行き、ここもたった一人で独占。 SLの写真を、死ぬほど撮りまくった。一巡してベンチに座ってSLを眺めていたら、なんだか幸せで泣けてきてしまって(;_;)、 やはり真性SL鉄オタであることを自覚。 さらに細部を撮りまくり、Ljubljana駅に戻って、カフェで休憩でビールを頼んだら、これが美味しくて0.5lジョッキを2杯いただいた。 なんだかんだと、相当な距離を散歩していたのである。湿度の低い気候なので、汗もサッと引いて、とても快適(^_^)。

そして駅からホテルへの帰途、たしかここらあたりにICMC2012のメイン会場が・・・という場所(昔の火力発電所跡が博物館になっていて、 色々な展示/パフォーマンス/ワークショップ等に利用される施設)をチェックすると、 なんとICMC2012の大会委員長とばったり出会って話が出来た。 去年のようにProceedingsがDVDだと、僕が持参したMacBookAirではDVD/CDドライブが無いので読めないのだが、 今年はちゃんとUSBメモリに戻ったそうで、これで安心である。 この会場の近くに、とでネットで探したホテルだが、まさに徒歩数分の至近距離と判明して安心した。

その後15時過ぎにホテルに帰って、やや不調でも午後なのでかろうじて繋がるネットでメイル等を整理しているうちに、 朝から頑張ったためかフト寝入ってしまい、目覚めると18時を過ぎていた(^_^;)。 慌ててインスタレーション・オープニング会場に出かけると、いよいよICMC、という雰囲気が充満していた。 レジストレーションデスクで以下のような「ICMCキット」を受け取り、 いくつものインスタレーション作品を見て、ホテルへの帰途にはスロベニアンレストランで、地元料理という「カツレツ」をいただいた。 日本のカツレツとはたまたま発音が似ているらしいが、中にチーズを挟んだ美味しいカツレツであった。

今年のICMCは前半1/3あたりで早退、という不本意な部分参加なので、晩のコンサートはパスした。明日も夜と深夜のコンサートはパスの予定である。 ICMCフル参加の年には気合いとペース配分も違ってくるが、今年はインスタとpaper重視と決めていた。 そしてホテルに帰って、懸案だったMaxパッチの改良(ライン描画による図形表示のためのサブパッチ化)をした。 あまり大したことはしていないが、今後、構造化して複雑な図形を表示するには必須の予備作業である。 23時過ぎとなり、以下のようなところまででオシマイとなった。 この後は、明日の朝に早起きできれば、あるいはICMC2012の会場での内職(^_^;)、ということになる。

2012年9月10日(月)

ホテル界隈でICMC2012関係者と出会うようになり、paper会場にもっとも近いこのHotel Parkは、たぶん満室である。 当然、部屋ではまったくWiFiが繋がらなくなったが、フロントや朝食レストランの1階はバリバリOKである。 こういう時には、「部屋でネット」というのを潔く諦めて、オフライン作業を部屋でやって、メイルとかFTPは1階で、 と切り分ければよい。 以下のように、朝イチで朝食会場に行き、mixiのclosed日記にProceedingsをアップロードしたり、 昨日のこの日記をFTPアッブしたり、さらに音楽情報科学研究会の運営委員会関係のメイルに3件、 返信したりしながらのbreakfastは効率が良い。 この部分は、ホテルを出る時にまた1階からアップする予定である。

今日のICMC予定についていろいろと悩んだが、まず午前の最初のセッションはsignsl processing?なので参加、 午前の次のセッションは同じ会場は「美学」なのでパス(^_^;)して、ちょっと不明なDDTという会場での「live coding」セッションに行く予定である。 その後、3会場のインスタレーションを全て巡って・・・というところまでは確定である。 午後には、KeynoteとAfternoon Concertがあるが、この会場がちょっと遠い。 バスを利用すれば行けるが、リュブリャナのバスは、SUICAみたいなカードをまず買って、 そこにチャージする必要がある。しかし今回のICMCでは、晩のコンサート(こちらの会場も遠いのでバスが必須)はパスの予定なので、 今日の午後のセッション行きをもしパスすれば、バスのカード(今後、使うことはほぼ無い)は不要なのである。 気が変わって行くかもしれないが、朝の段階では、インスタの3会場を巡ったところで、 今年のICMCはほぼ終了(あとは明日の朝イチのセッションと午前のポスター発表だけ)、という予定である。 午後から晩には、最後にまた、あのお城に行っておきたい。

そして朝食後に部屋に戻り、作りかけていたMaxパッチをやや追加した。 画面内のjit.pwindowに表示されないのはまだバグだが、 ループを回してラインを引くことで、OLED-PROPに矩形を表示するところまで出来た。 これであとは、ICMCに全力投球である(^_^)。

さて、この部分はICMCの最初のセッション中に書いている。 今回のICMCのテーマは「蝸牛に頼らないサウンド」という、ちょっと怪しいものだったが(^_^;)、 なるほど、このセッションはそのものずばりからスタートした。 会場の反応もクール(冷淡)で、次の美学セッションと似た空気が漂っている。 どうやら、初日は最終日と同じように、参加者がまだ揃っていないという想定から、窓際テーマから始まったようである。 会場のWiFiは繋がるまでに待たされる(多数がアクセス)が、繋がってしまえば快適で、 合間に学会の運営委員会とか大学とメイルをやりとりする余裕があった。(^_^;)

そして会場を移動して、午前の後半のセッション「Live Coding」である。 期待したように、これは面白い。 リアルタイムに音を生成するアルゴリズムを記述するプログラム自体を、

  • 人間が音楽生成の最中に書き加えたり書き換えたりする
  • プログラム自身が音楽生成の最中に書き換えたり自動生成したりする
などという、間違えれば自爆テロとなるようなコンセプト(^_^;)である。 たいていは、裏でMaxMSPとかSuperColliderによってサウンド生成サーバを走らせておき、 そこにOSCで渡すパラメータを、それぞれのスタイルのコーディング様式で実装しているようである。 ただし、MIDI演奏情報レベルのアプローチはぼちぼち飽和してきたのか、 今回はサウンドに対するエフェクトとかWebブラウザ上とか、ちょっと周辺に染み出してきた。 まだ可能性はあるように思うのだが、これはちょっとトライしていこうかな。 
SESSION 2B: LIVE CODING

STRANGE LOOPS IN CFML: A LIVECODER’S RIDDLE
	 - Adam M. Smith

CHUGENS, CHUBGRAPHS, CHUGINS: 3 TIERS FOR EXTENDING CHUCK
	 - Spencer Salazar and Ge Wang

GIBBER: LIVE CODING AUDIO IN THE BROWSER
	 - Charlie Roberts and Joann Kuchera-Morin

LIVE NOTATION: ACOUSTIC RESONANCE?
	 - Alex Mclean and Hester Reeve
このセッションでは上の4件が発表されたが、最後の「Live Notation」というのが、 一番、個人的には気に入った。 Computer Musicライブパフォーマンスにおいて、聴衆がステージ上のパフォーマンスにおける「関係性」を理解しつつ聴取する、 という公演の実現(分かってもらった上で鑑賞してもらいたい)にいつも苦労するが、 パフォーマーが参照する広義の「楽譜」、これはライブに刻々と変化するが、 それを見せてしまう、というのは目から鱗であった(^_^;)。 似たことは過去にもやっていたが、これは今後、ぜひ自分でもやっていこう。

ホテルに帰ってきて、今は日本時間で9月10日が終わりかけ、リュブリャナは午後5時前である。 上の写真は、最後の晩に備えてキオスクで仕入れたスロベニアビール2本と、クロアチアで残ったクローネを使い切るために、 わざわざスーパーで買った輸入品のフランス・メルローワインである(美味しいので許す)。 さすがにこの時間はなんとか部屋でもWiFiが生きていて、嬉しい知らせとして、 バゲッジがロストしていたM1の鈴木さんから「戻ってきた」とのメイルが来た(^_^)。 初めての海外旅行でいきなりロストバゲッジでは印象が悪いが、これで本当に一安心である。

今日は結局、昼過ぎまでの午前のセッションの後で、地図を頼りに3つのインスタ会場を全て巡った。 慶応SFC(卒?)の小林さんのインスタは、外見上は結構よくある(アルスでもあったしここ数年の流行)作品だったが、 提示するグラフィックと、インタラクティブに生成されるサウンドに、慶応・岩竹研の伝統のテイストとこだわりを感じた。 そして予定通りに、今度はフニクラ(ケーブルカー)でなく「SL型自動車」でお城に行き、展望台であらためてリュプリャナ市街を見下ろし、 カフェでビールとワインでまったりして、街に下りた。 目をつけていたチョコレート屋さんに行くと、なんとスロベニアではなくて、全てクロアチア・チョコレートのお店だったが、 一昨日、まさにクロアチアに行った身としてはむしろ歓迎で、ここでようやくお土産を仕入れた。

明日の朝にはホテルをチェックアウトして荷物を預けて、午前のposterセッションの発表が終わったら午後にホテルに戻って、 バスで空港に行く・・・ということなので、ぼちぼち、部屋でパッキングなども始めた。 あとは晩に、これもチェックしていた中華レストランで「スロベニア最後の晩餐」に行くだけなので、 それまで部屋で「最後のPropellerプログラミング」を、スロベニアビールをいただきながら進めることにした。 ちなみに写真にはどこにもないが、ホテルの部屋に戻れば、いつものおっさん出張の癖で、ずっと全裸である。(^_^;)

・・・そして約1時間、まだ繋がっているネットなどでよそ見しつつも(^_^;)、無事に以下のように、複数の矩形で塗り潰し、 さらに放射状の白線を描画する、というパッチで動作を確認した。 これが出来た最初のテストランで、PROP-OLEDが突然、真っ暗になった。 再度XBeeから送ってみると、途中まで描画して、また最後に真っ暗になる。 これは、PROP-OLEDのマニュアルにあったように、全画面に明るい画素が出るほど消費電流が増えるために、 日本を出てからずっと交換していなかったバッテリが、ここに来て遂にギリギリになり、全画面を明るく表示すると、 そこでPropellerが低電圧の限界を下回ってリセットする現象である。 こちらのバッテリはXBeeとOLEDの両方なので、よりキツいのである。 Maxと繋がっている方はXBeeだけなので、まったく平然としている。 Propellerの、電池寿命の際の振る舞いもこれで分かった。 この様子を以下に並べて、これで今回のPropeller実験は打ち止め、としよう。 帰途はミュンヘンも成田も乗り継ぎ時間は長くないので、機内に持ち込まず、スーツケースに入れてしまおう。

2012年9月11日(火)

セプテンバー・イレブンである。 2001年の欧州ツアー ★ ★ ★ ではまさに、このテロの数日後に日本を出発し、次第に事態が判明してくるにつれて、 移動するたびに空港のセキュリティレベルが上がって、最後のフランクフルト空港では遂に、 それまで機内持ち込みしていたKymaのCapybaraと別室に連れていかれて15分ほど専用機でスキャンされた挙句、 搭乗口で強制的にバゲッジ扱いにされて、Capybaraの金属筐体の角の部分が曲がった(^_^;)、という苦い記憶が蘇った。

その9月11日、いよいよリュブリャナ最終日である。 午前のposterセッションで発表して、午後にホテルから空港までのプライベートバスの予約も昨夜に完了している。 まだまだICMC2012は始まったばかりの前半戦だが、大学のお仕事で9/12には帰国しないといけない、 という事で、Propeller再開とともに今回の欧州ツアー全体としては内容充実していたものの、物足りなさもある。 自分の学科の学生が関係した議題の学生委員会が9/13にあるので、これはどうしようもないのである。 自費で申し込みしていたBanquet(古城に行っての晩餐会)もキャンセルが効かず、 捨てるのも勿体ないので東大の嵯峨山先生にチケットをプレゼントした。 ・・・しかし、なんと僕が去った明日と明後日は、リュプリャナは雨、さらに寒いという予報である。 実に申し訳ない。(^_^;)

去年の9/11は2001年の同時多発テロから10周年ということで世界的にセキュリティレベルが上がったが、 今年はそれほどでなくても、やはり空港とかはピリピリしているかもしれない。 ホテルのテレビ(スロベニアではCNNは無くてBBC)では、あまり話題になっていないようである。 というか、テレビのBBCから珍しく「Japan」という言葉が出て来たが(ヘッドラインでなくて世界各地の話題のコーナー)、 どうも尖閣諸島の話題だ、ということでYAHOO JAPANのニュースを見てみると、

  • 尖閣購入を閣議決定＝地権者と売買契約を締結 (9月11日)
  • 中国・海洋監視船2隻、尖閣海域到着＝主権維持へ行動計画策定 (9月11日)
と、アジアのセプテンバー・イレブン・ニュースであった(^_^;)。 今年の2月には、毎年行っている沖縄から足を延ばして、素晴らしい 与那国島 に行ってきた身としての感想としては、「なんだかなー」である。

これまでずっと毎日、ホテルでの朝食をちゃんと食べて(日本では普段は朝食は食べない)、 空腹にならないので昼食をパスする、という生活をしてきたが、帰国日なのでホテルの朝食をパスして、 ICMC会場で提供されているバナナでもつまむ事にした。 ホテルを出るまでの時間に、いろいろ帰国後にするべきことをアトランダムに備忘録としてメモしておくことにした。 この部分はICMC会場や空港・機内などでも、帰国まで追加していくことになる。

  • PropellerのWebカメラ→XBee経由→OLED-PROP表示の、画面内でのチラつきについて。元画像の画素ごとにjitter windowスキャンからXBee送信をしているために、Webカメラのスキャンレート(より高速)では、例えば蛍光灯や光源LED(高速で点滅)の輝度変化がノイズとなっている可能性がある。1画面の画素(96*64))をいったんまとめてスキャンして配列に格納してから、その後に画素ごとにXBee転送して改善されないか、実験するべし
  • 復命書/出張報告書
  • 9/13学生委員会
  • 伊熊作品のための準備 - 超小型UVセンサの加工、UVセンサ回路の確認と量産、Max用MIDIインターフェースの製作
  • M1「メディアデザイン特論」の内容 - 小畑さんと鈴木さんと相談、ArduinoかPropellerかProcessingかiPhoneアブリか、M1の後期にインスタ作品等に挑戦するか
  • ゼミ3回生・SUSUの作品のための準備 - Max-DMX-LaserProjectorのパラメータ整理
  • 音楽情報科学研究会12月研究会の発表募集 - 研究会運営委員会と開催地(小坂さん)との発表募集コンセンサスの確認 → 発表募集
  • 写真を整理してフォトレポートを上げる。現在のところ6500枚ほど(^_^;)
  • 「続・Propeller日記」part2を切って、次はpart3
  • 某財団の研究助成応募の検討
  • 科研費の応募検討
  • 来週の日本音楽即興学会の発表準備
  • 後期「メディアアーツ論」準備
  • 後期「サウンドデザイン演習」準備
  • マルチメディア室のMacのOSアップデート
  • 12月インターカレッジ行きについて参加学生募集
  • CGクリエイター検定の申し込み様式を設定して受験受付の告知と掲示
  • 2013年2-3月のSUACイベント(→Sketchingワークショップ)について的場先生/和田先生と相談
  • 生産造形・空間造形の学生向けのエレクトロニクス講習会
  • 来年のICMCに向けてのネタは?
  • 来年のNIMEに向けてのネタは?
  • 「トンデモ系のComputer Music大ネタ」についてはどうするか(^_^;)
  • Propeller/Gainer/AKI-H8/Arduino/XBee対応・汎用実験基板の試作発注

ホテルを朝8時半に出て、まだ閑散としている会場で、ポスターを貼った。 まだ誰もいなかったので、どの場所でもいいよ、というので、一番良さそうな場所をゲットした(^_^)。 そして、2日目の午前のセッションである。最前列の中央の椅子で、写真がいちばん奇麗に撮れる。 このセッションのテーマはICMCの王道、「Analysis/Synthesis」(以下)である。 最初はパワフルなGeorge Esselからで、参加者の眠気を吹き飛ばす迫力である。 生成系というよりも、iPhone/iPadなどの処理系をComputer Musicのプラットフォームに活用する際の、 「時間/タイミング」について検討したようである。 ただ、SuperColliderでは、オーディオレートの処理とコントロール(演奏/センサ/インタラクション)レートの処理とを ちゃんと区別していたし、Max/MSP/jitterでも、MIDIレートのタイミング処理とMSPのサンプリング処理とjitterのベストエフォート処理とは区別されていた。 iOSやpdはこのあたりが適当なのだろうか。(^_^;) 

SESSION 3: ANALYSIS/SYNTHESIS

PLAYING WITH TIME: MANIPULATION OF TIME AND RATE IN A 
MULTI-RATE SIGNAL PROCESSING PIPELINE
	- Georg Essl

“WARM CHORUS”: RE-THINKING THE CHORUS EFFECT USING 
AN ORCHESTRAL SECTION MODEL
	- Richard Dudas

A SPECTROGRAPHIC ANALYSIS OF VOCAL TECHNIQUES IN 
EXTREME METAL FOR MUSICOLOGICAL ANALYSIS
	- Eric Smialek, Philippe Depalle and David Brackett

SOUND SYNTHESIS WITH AUDITORY DISTORTION PRODUCTS
	- Gary Kendall, Christopher Haworth and Rodrigo Cadiz

2件目の「Warm Chorus」とは、また渋いテーマである。 以下の上2つのような伝統的コーラスをMSPで実装して検討した上で、以下の下2つのように、 まさに腕力でより美味しいコーラスにこだわっているようである。 詳しくpaperをチェックする必要があるが、本物のオーケストラの芳醇なコーラス効果について、 「純正律」という言葉があった(ホンマかいな)のは面白い視点だと思う。

上の図はProceedingsからキャプチャしたが、本人から「paperに書いたものはまだイマイチだ」(^_^;)というような言葉があったので、この図はpaper machineかもしれない。。 デモを聞く限り、モノラルのデッドなバイオリンの演奏音響が、パートごとに豊かなコーラス効果で分厚くなっていた。 これはPerfumeでも使って欲しいものだが、しかしディレイ系と違ってコーラスの多用はすぐに食傷しそうだ。

3件目は分析系で、たぶん研究者本人が好きなのだろう、ヘビメタのボーカルに特徴的な歌声の分析である。 ただし冒頭、サウンド系のトラブルで「ちょっとボリュームを下げるけどこんな音楽です」と客席を圧倒させたかったサンプルが鳴らなかったのは、ちょっと可哀想だった。 しかし発表の途中では、マイクで簡単に色々なヘビメタ音声(Vocal Tract)をデモっていたので、もしかして、 彼は現役のヘビメタバンドのボーカルなのかもしれない(^_^;)。 ちょうど昨夜、デスメタルで宮崎アニメの曲をやっているのを人間やコンピュータはどう認識するのか・・・というネタを思いついていたところだったので、機会があればこのあたりを調べてみたい。 日本では猫も杓子も初音ミクであるが、こちらの研究の方が、よほどヒューマンでリアリスティックであると思った。

4件目は「Auditory Distortion」という、これも古典的なテーマでのSynthesisらしい。 どうも、音響心理学的なサーベイなどから始まって、いわゆる「アレ系」かと心配な「お話し」が続いた(^_^;)。 通常の楽音であれば、2倍音・3倍音・・・と高次倍音になるほどレベルが下がるが、 なんとここでは指数的周波数軸上に等間隔でN個、つまりFからNFまでを全て同じレベルでミックスするらしい。 当然ながら、タイトル通りに歪んだ音がする。 そこにAMとかFMとかをかけているが、とにかくデモ音は耳障りである。 こういう音を日々、ずっと聞きながら研究するというのは、かなりタフというか音響オタクでないと無理だろう。 これで朝イチのセッションが終わり、次はいよいよposter発表である。 もっと、たくさんのセッションに参加したかったが、うーーーむ、残念である。

・・・そして2時間後、ホテルのロビーに戻ってきた。 posterセッションは無事に、というか、今回のICMCではstudio reportセッション系が無いのか、 なんか周囲の発表から浮いていて、日本人とか、日本語を話す外人とかがたくさん来てくれてラクだった。 そういえば今日で帰国するので発表を11日の午前にしてくれ、と事前に依頼していたので、 研究系のposterセッションに無理に割り込んだ形なのかもしれない。 いずれにしてもお仕事は無事に完了で、一緒のセッションだった電機大の小坂さんと、 12月のインカレについてちょっと話して(小坂さんは開催ホスト代表、僕は研究会プログラム[発表募集]担当)、 会場を後にしたところである。 あと25分で、空港行きのプライベートバスが迎えに来て、リュブリャナ空港で夕方のフライトまでまったりして、 ミュンヘン、成田を経て、セントレアに着くのはちょうど今から22時間後である。 ここまでをホテルのWiFiでアップして、続きの日付けは明日(日本ではあと4時間で12日)としよう。

・・・「あとは明日に」と書いたが、上の写真はリュブリャナ空港のカフェである。 なんと太っ腹に、ここはカウンター越しにコンセント使用OK、 そして空港は24時間以内フリーの超快適WiFi(アップロード/ダウンロードは500KBまで)、 という嬉しい環境である。24時間もここに居座るつもりはないが、ここで搭乗までの2時間弱、ワインとともにお仕事である。 ただし、日本時間で今日9/11はあと1時間もないので、書いた内容は「9月12日」のところに書き、 明日以降にFTPアップとなりそうだ。 とりあえずYAHOOニュースで、サッカーでジーコのイラクに勝ったという情報だけはゲットした(^_^)。

2012年9月12日(水)

Propellerプロジェクトには、これまで書いてきたようにいくつかの課題が残っているが、 とりあえずもう少しだけ完備したいのは、OLED-PROPのグラフィックドライバに対応して、 MaxからXBeeで送るグラフィック表示コマンドを、「line系」だけでなく、「矩形」「楕円」にまでは拡張しておきたい。 これは、jitterのjit.lcdでも「drawrect」「drawcircle」「paintrect」「paintcircle」をサポートしているのと対応しているからである。 このpart2の日記の上の方で転載しているように、Propellerのグラフィックドライバにあるのは以下である。
  • PUB plotPixel(_x0, _y0, _color) | videoOffset, pixelValue
    Plot at pixel at x, y, with the appropriate 8-bit color
  • PUB plotLine(_x0, _y0, _x1, _y1, _color) | dx, dy, difx, dify, sx, sy, ds
    Plot a line from _x0,_y0 to _x1,_y1 with the appropriate 8-bit color
  • PUB plotCircle(_x0, _y0, _radius, _color) | sum, x, y
    Plot a circle with center _x0,_y0 and radius _radius with the appropriate 8-bit color
  • PUB plotSprite(_x0, _y0, _spritePTR) | xpix, ypix, x, y
    Plot a pixel sprite into the video memory.
  • PUB plotChar(_char, _xC, _yC, _font, _color) | row, col
    Plot a single character into the video memory.
  • PUB plotText (_xC, _yC, _font, _color, _str) | t
    Plot a string of characters into the video memory.
ここから分かるのは、「plotCircle」で、塗り潰しでない、かつ楕円でない「円」だけは簡単にいけそうだ、という事である。 「plotPixel」は画素単位なのでも、既にWebカメラ画像の表示に使っている。 「plotSprite」は、初代のファミコンにあった歴史的な機能で、あるサイズの画像をスプライトという単位でまとめて動かすものであり、 ここではちょっと関係ない。 「plotChar」は、文字を表示するのにドライバ側にフォントデータを持っているものだが、これもここでは関係ない。 「plotLine」については既に作っていて、Propellerの方には矩形は無いようなので、以下のいずれかの方法で作ることになる。
  • 既に実験したように、Maxの側で矩形の座標を解釈して「line」系としてXBeeで送る
  • XBeeでコマンドを受けたPropellerの方のspinプログラムとして矩形の座標を解釈してドライバを呼ぶ
これは、OLEDの反応速度と、XBeeの伝送速度と、たぶんトレードオフの関係で、スグにはどちらが有効か判断が難しい。 実験してみる価値がありそうである。 ただし、「ine系」に続いて、MaxからXBee経由で「circle系」「rect系」のコマンドを送る、という立場では、後者に挑戦したいところだ。 とりあえずここではまず、その後者のアプローチを前提として、「line系」でやったように、コマンドプロトコルを整理して定義してみよう。 ちょっと教条主義っぽいが、空港のカフェで一杯やりながら・・・というのには、こういう[手間がかかるがあまり考えない]作業が、 一番フィットしているのである。(^_^;)

さて、こうなると、新しいコマンドプロトコルの定義である。 MIDI的な3バイトメッセージのプロトコルは、Propellerの方の都合で厳守することになる。 ぼちぼちセキュリティゲートに向かうので、以下にまずは転載して、 いったんリュブリャナ空港のカフェから最後のアップロードをしておいて、中身を検討しつつ追加・改訂していくことにしよう。

  • メッセージは全て3バイトを単位とする
  • 先頭データ(ステータスバイト)のMSBは1で、続く2バイトのデータバイトは7ビットデータ(0-127)
  • ステータスバイト「%10000000」-「%110111111」 - 画素単位のカラー描画
    • カラーは「8-bit color value (RRRGGGBB)」と定義
    • ステータスバイトの下位7ビットがOLEDのX座標(0-95)
    • 2バイト目のデータバイト(7ピット)の下位6ビット(bit 5-0)がOLEDのY座標(0-63)
    • 2バイト目のデータバイト(7ピット)のbit 6がカラーのMSB
    • 3バイト目のデータバイト(7ビット)にこのカラーのMSBを加えた8ビットが、その画素のカラー(RRRGGGBB)
  • ステータスバイト「%11100000」 - color_set (後の描画コマンドでのカラー指定)
    • 2バイト目のデータバイト(7ピット)のLSB、つまりbit 0がカラーのMSB
    • 3バイト目のデータバイト(7ビット)にこのカラーのMSBを加えた8ビットをカラー(RRRGGGBB)とする
    • このコマンドでは描画しない。後の各種描画コマンドのためのカラー指定
  • ステータスバイト「%11100001」 - move_to (ラインを引く起点の座標の指定)
    • 2バイト目のデータバイト(7ピット)がラインを引く起点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く起点のY座標
    • このコマンドでは描画しない。「line_to」と「line_draw」コマンドのための起点座標指定
  • ステータスバイト「%11100010」 - line_to (ラインを引き終点を新しい起点とする)
    • 2バイト目のデータバイト(7ピット)がラインを引く終点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く終点のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 終点座標を指定してラインを指定カラーで描画し、終点座標を起点座標に代入する
  • ステータスバイト「%11100011」 - line_to (ラインを引き起点はそのまま)
    • 2バイト目のデータバイト(7ピット)がラインを引く終点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く終点のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 終点座標を指定してラインを指定カラーで描画し、起点座標はそのまま変化させない
  • ステータスバイト「%11100100」
  • ステータスバイト「%11100101」
  • ステータスバイト「%11100110」
  • ステータスバイト「%11100111」
  • ステータスバイト「%11101000」
  • ステータスバイト「%11101001」
  • ステータスバイト「%11101010」
  • ステータスバイト「%11101011」
  • ステータスバイト「%11101100」
  • ステータスバイト「%11101101」
  • ステータスバイト「%11101110」
  • ステータスバイト「%11101111」
  • ステータスバイト「%11110000」
  • ステータスバイト「%11110001」
  • ステータスバイト「%11110010」
  • ステータスバイト「%11110011」
  • ステータスバイト「%11110100」
  • ステータスバイト「%11110101」
  • ステータスバイト「%11110110」
  • ステータスバイト「%11110111」
  • ステータスバイト「%11111000」
  • ステータスバイト「%11111001」
  • ステータスバイト「%11111010」
  • ステータスバイト「%11111011」
  • ステータスバイト「%11111100」
  • ステータスバイト「%11111101」
  • ステータスバイト「%11111110」
  • ステータスバイト「%11111111」 - OLED全画面をクリア(→真っ黒) - 2/3バイト目は何でもよい

・・・さて、ここからは機内である。 いつもの4本と違ってquarterのワイン3本で爆睡できたのは、既にリュブリャナ空港でビールとワイン(0.2リットル)をいただいていたからである(^_^;)。 いつも思うが、時差ぼけ対策で無理に飲んで爆睡し、だいたい4-5時間、 フライトのちょうど半分ぐらいで目覚めた時の、どよーーーんとした倦怠感と全身カチカチ感は、他では体験できない。 そして、ここで席を立ち、ストレッチを入念に行いつつ、冷たいオレンジジュースを飲み、やがてブラックコーヒーを飲んで、 全身に血流が蘇っていく、その過程というのは、実に快感である(^_^)。 ある意味では、海外出張の醍醐味というかモチベーションの一つは、これを求めて、という気がする。 そしていつものように、目覚めたのはちょうどフライトのど真ん中、リフレッシュして席に戻ってMacを開けた今は、 「残り3800Km」「残り4時間半」というあたりであった。 バッテリは81%、こうやってテキストエディタ "JeditX" で書いている分には、十分に続けられる時間がある。(^_^)

上記のコマンドプロトコル案は、リュブリャナ空港のカフェでこれまでのものをコピペ整理して、 その後ミュンヘンに飛んで(フライト自体は40分そこそこ)、ミュンヘン乗り継ぎはドイツビールをいただくほどの時間も無かったので、 搭乗ゲート付近で全てのステータスバイトを網羅するように追加した。 既にある「96+4+1=101」通りのステータスバイトに、残り27通りのステータスバイトを定義する余地が残っている。

さて、日付けとしては今日「9月12日」の最初に書いた部分について、読み返して気付いた事がある。 矩形のOLED描画について2つの方法がある、と列記したが、実はもう一つ、全部で以下の3つの方法があるのだった。

  • 既に実験したように、Maxの側で矩形の座標を解釈して「line」系としてXBeeで送る
  • XBeeでコマンドを受けたPropellerの方のspinプログラムとして矩形の座標を解釈してドライバを呼ぶ
  • Maxからはシンプルに定義したコマンドをXBeeで送り、Propellerのspinプログラムはシンプルにドライバを呼び出し、新たなグラフィックドライバを追加してアセンブラで矩形の座標を解釈して描画する
この3番目の方法は、たぶんもっとも大変だが、たぶんもっとも高速である。 そして、「plotCircle(_x0, _y0, _radius, _color)」は、楕円が不可で円だけ、 それもProcessingやMaxでの「外接する矩形の左上と右下の座標」という形式でなく「中心座標と半径」(Processingはこれも対応)なので、こちらはほぼ、実装には3番目の対応しか無い、と見えてきた。 となれば、矩形についてもグラフィックドライバをアセンブラで記述して追加する方が、同じ形式でスッキリする。 1番目のMaxの側では作れず、2番目のspinうにゃうにゃも、あまり美しくないのだった(^_^;)。 そして、この方針だと腹をくくれば、コマンドプロトコルの定義は、まさに「絵に描いた餅」として、 あとの尻拭いはProcessingのアセンブラ・プログラミングに回すとして、どんどんスッキリと定義していいのである。

以上を受けて、前述のコマンドプロトコル案の定義の「残り」部分に、以下のように追加してみた。 まだ残っている部分は「reserved」ということで、これを常に残しておくのは、過去の経験上(イザという時の尻拭いが出来る)重要である。

  • メッセージは全て3バイトを単位とする
  • 先頭データ(ステータスバイト)のMSBは1で、続く2バイトのデータバイトは7ビットデータ(0-127)
  • ステータスバイト「%10000000」-「%110111111」 - 画素単位のカラー描画
    • カラーは「8-bit color value (RRRGGGBB)」と定義
    • ステータスバイトの下位7ビットがOLEDのX座標(0-95)
    • 2バイト目のデータバイト(7ピット)の下位6ビット(bit 5-0)がOLEDのY座標(0-63)
    • 2バイト目のデータバイト(7ピット)のbit 6がカラーのMSB
    • 3バイト目のデータバイト(7ビット)にこのカラーのMSBを加えた8ビットが、その画素のカラー(RRRGGGBB)
  • ステータスバイト「%11100000」 - color_set (後の描画コマンドでのカラー指定)
    • このコマンドでは描画しない。後の各種描画コマンドのための共通のカラー指定
    • 2バイト目のデータバイト(7ピット)のLSB、つまりbit 0がカラーのMSB
    • 3バイト目のデータバイト(7ビット)にこのカラーのMSBを加えた8ビットをカラー(RRRGGGBB)とする
    • このコマンドが指定される前の初期値はゼロ(真っ黒)
  • ステータスバイト「%11100001」 - move_to (ラインを引く起点の座標の指定)
    • このコマンドでは描画しない。「line_to」と「line_draw」コマンドのための起点座標指定
    • 2バイト目のデータバイト(7ピット)がラインを引く起点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く起点のY座標
    • このコマンドが指定される前の初期値は(0,0)
  • ステータスバイト「%11100010」 - line_to (ラインを引き終点を新しい起点とする)
    • 2バイト目のデータバイト(7ピット)がラインを引く終点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く終点のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 終点座標を指定してラインを指定カラーで描画し、終点座標を起点座標に代入する
  • ステータスバイト「%11100011」 - line_to (ラインを引き起点はそのまま)
    • 2バイト目のデータバイト(7ピット)がラインを引く終点のX座標
    • 3バイト目のデータバイト(7ビット)がラインを引く終点のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 終点座標を指定してラインを指定カラーで描画し、起点座標はそのまま変化させない
  • ステータスバイト「%11100100」 - rect_start (矩形の左上の座標)
    • 矩形または楕円を描画するための左上の座標を共通に指定する
    • このコマンドでは描画しない。「frame_rect」と「paint_rect」と「frame_oval」と「paint_oval」コマンド用の左上の座標指定
    • 2バイト目のデータバイト(7ピット)が矩形指定の左上のX座標
    • 3バイト目のデータバイト(7ビット)が矩形指定の左上のY座標
    • このコマンドが指定される前の初期値は(0,0)
  • ステータスバイト「%11100101」 - frame_rect (矩形の輪郭の右下の座標と描画)
    • 2バイト目のデータバイト(7ピット)がラインで矩形を描画する右下のX座標
    • 3バイト目のデータバイト(7ビット)がラインで矩形を描画する右下のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 「rect_start」で指定された左上の座標に対してラインで矩形を描画する
    • 左上の座標より必ず右下にあること(チェックしない)　※spinでチェックする???
  • ステータスバイト「%11100110」 - paint_rect (塗りつぶしの矩形の右下の座標と描画)
    • 2バイト目のデータバイト(7ピット)が塗りつぶしの矩形を描画する右下のX座標
    • 3バイト目のデータバイト(7ビット)が塗りつぶしの矩形を描画する右下のY座標
    • 塗りつぶしのカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 「rect_start」で指定された左上の座標に対して塗りつぶしで矩形を描画する
    • 左上の座標より必ず右下にあること(チェックしない)　※spinでチェックする???
  • ステータスバイト「%11100111」 - frame_oval (楕円の輪郭に外接する矩形の右下の座標と描画)
    • 2バイト目のデータバイト(7ピット)がラインで楕円を描画する外接矩形の右下のX座標
    • 3バイト目のデータバイト(7ビット)がラインで矩形を描画する外接矩形の右下のY座標
    • ラインを引くカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 「rect_start」で指定された左上とこの右下の座標の矩形に内接する楕円の輪郭を描画する
    • 左上の座標より必ず右下にあること(チェックしない)　※spinでチェックする???
  • ステータスバイト「%11101000」 - paint_oval (塗りつぶしの楕円に外接する矩形の右下の座標と描画)
    • 2バイト目のデータバイト(7ピット)が塗りつぶしで楕円を描画する外接矩形の右下のX座標
    • 3バイト目のデータバイト(7ビット)が塗りつぶしで矩形を描画する外接矩形の右下のY座標
    • 塗りつぶしのカラーは最後に「color_set」で指定されたカラー(RRRGGGBB)
    • 「rect_start」で指定された左上とこの右下の座標の矩形に内接する楕円を塗りつぶしで描画する
    • 左上の座標より必ず右下にあること(チェックしない)　※spinでチェックする???
  • ステータスバイト「%11111111」 - OLED全画面をクリア(→真っ黒) - 2/3バイト目は何でもよい

この日記のあちこちを読み返して修正などしつつ、ここまで5つの新しいコマンドを定義したところで、 機内が明るくなった。 既にハバロフスクに向かい、残りは2時間半、1200kmである。 成田に着いたらメイルをチェックするバッテリを残すため(現在47%)、今日はたぶん、ここまでである。 次は明日以降となるので、「続・Propeller日記(3)」にバトンタッチしよう。

続・Propeller日記(3) へ

「日記」シリーズ の記録