■

ここ数年は何か思いついたらとりあえずrubyで書いてアイデアの感覚をつかむのがパターンで仕事だと主にlinuxを中心とした何入ってるかわからない色んなマシンで動かさないといけないという暗黙的な制約があり、そういうとき自分の場合は今までだったらPerlで書いてたんだけどPerlにそれほど馴染のない人に勧めるの酷なかんじするので色んなとこで動かすことになりそうだけど簡単なツールはlinux標準で入っててコードの見た目が綺麗なpythonで書こうとしていて、実際にいくつか書いてる。

python絡みで、前から気になってたSphinx + blockdiag/seqdiag使って仕事のドキュメント書いてみてるけど、普通にblockdiagの書き方でOmniGraffleで描いた図のような見た目になるのがいい感じ。
reStructuredTextの存在自体は知ってたけど書いたことがあまりなくてその理由を考えたんだけどpythonに絡まないところで目にする機会が少なかったからだろうか。markdownはgithub以前から目にする機会が多かったように思う。個人的な各種メモ、まとめはemacsのorg-modeで書いてる。さっきメモファイル置き場で ls | grep .org$ | wc -l したら151個ファイルがあった。orgにはとりあえず気になるトピック単位(vlad, q4m, beat_detection, kinect_openNI, chuckとか)でファイルにメモしていて、メモファイル置き場にある一番古いorgのタイムスタンプによるとorgで書き始めたのが2009年秋頃だった。この日記の更新頻度の低下に影響してるように見える。

そういうこと考えながらそういえば日記更新してないなーと思ってはてなダイアリーみたら最終更新が一年前の先月で今更新するとよさそうだったので更新してみました。更新って言葉がなつかしい感じする。

ruck

ruckはChucKの軽量スレッド周りの処理をrubyに移植したもので、RubyKaigi2010でもプレゼンがあった。タイトルだけ見るとゲームの話かと思うけどゲームに関しては少しだけ触れられていてほとんどはruckとChucKの話だった。ChucKは今までにも何度かおもしろそうだなーと思ったことがあったのでruckのコードを読んでみた。ChucKの論文眺めてたのもその為です。

ruckはclock, event_clock, shred, shredulerから構成されている。shredulerに対してshredを登録するとそのshredはshredulerが持つclockに登録される。shreduler実行ループでは以下のような処理が行われている。

  • clockから現時刻のshred取り出し
  • clock時刻進める
  • 取り出したshred実行

clockがshred管理、スケジューリング、時間制御を担当し、shredulerはそのラッパーという感じ。実際に使うときはshredulerインスタンスのmake_convinientというメソッドを実行するとmodule_evalやincludeで便利なメソッドがいくつか追加され、clockを直接触らなくて済むようになってる。以下はreadmeからmake_convinient使ってるコードの抜粋

@shreduler = Ruck::Shreduler.new
@shreduler.make_convenient

spork do
  %w{ A B C D E }.each do |letter|
    puts "#{letter}"
    Ruck::Shred.yield(1)
  end
end

spork do
  %w{ 1 2 3 4 5 }.each do |number|
    puts "#{number}"
    Ruck::Shred.yield(1)
  end
end

@shreduler.run

shredの実装はruby 1.8系はcallcc, 1.9系はFiberを使ったものになっていてshreduler/clockから制御するときに実際の実装を意識しない。

Ruck::Shred.yieldメソッドはshredからshredulerに制御を戻すためのメソッドで、yieldに渡した時間とshred自身をshredulerのclockに対して再スケジュールするよう指示してshredを停止する。shred停止はfiber実装だと単にFiber.yieldするようになっていてこのあたりは面白かった。

event_clockはclockと似たようなインタフェースを持つが時間でなくイベントに対するshredスケジューリングを行う。clockが時間でソートされた配列なのに対してevent_clockはイベントをキーとした辞書といった感じ。

RubyKaigi2010でのプレゼンではstrong timing, virtual timeまわりの説明に重点が置かれている。通常のthreadとの比較、fast_forwardによるvirtual timeの制御等。threadとの比較で出てくる、初期化を先にやって各スレッドの時間経過は同時だからタイミングがずれないというような説明図の意味もコードを読んでからは理解できた。

関連:

  • ruck-ugen: ChucKでいうところのUGenを担当していて、これをあわせて使うことでChucKのような音生成を実現できる。
  • ruck-realtime: clockのfast_forwardメソッドを上書きしたモジュールで、VMのステップを進める時間を調整している。デフォルトのfast_forward実装だとVM上での時間となり実時間とズレが生じるのでfast_forward上書きでその差分を埋めよう、ということだと思う。

ChucKの軽量スレッド

Chuckの論文を斜め読みした。ホームページトップにもあるようにChucKはリアルタイム音声合成/作曲/パフォーマンスを目的としたシステムで、強力に正確な時間(strongly-timed)なこともウリにしている。論文ではその時間管理の部分と軽量スレッドの関係についても触れられていた。

ChucKで音を出すには、D/A Converter(dac)へ何らかのオシレーターを接続し、必要ならオシレーターの設定をした後、音をならしたい時間を指定する。最後の音をならす時間指定の前までがChucKでの軽量スレッドの実行単位(Shredと呼ばれている)となり、鳴らす音の時間指定した時点で音声エンジンによって音声処理され、Shred切り替え処理(Shredulerと呼ばれる)でキューにいるShredが処理される。以下は単一Shred時のフロー(論文だとp.77, fig.3.34)

複数Shredを並列実行する場合はsporkにShredとして実行する関数を渡す。OSCやMIDI等の外部信号イベントへの反応のためのハンドラ登録もsporkで行う。この辺りはjavascriptなんかでイベントハンドラ登録するのと同じ。sporkは先割れスプーン(spoon + fork)のことなのでfork意識してるはず。

以下は時間指定の部分だけ抜き出したコード例。

100::ms => now

'=>'は代入演算子みたいなもので、上記はコード実行時から100ms経過するまで待機、という意味になる。ソースは見てないけど上記のようなnowへの代入が実行された時点でshredulerに制御を返して他のshred処理をしてる、というような記述が論文中にあった。nowへのduration代入でなくme.yield();すると時間をまたずにその場でshredulerに処理を返せる。この書き方だと軽量スレッドをサポートする一般的なプログラミング言語の実行単位切り替えに似ている。

ChucKで軽量スレッドを採用する主なメリットは、OSのスレッド機構でなくユーザ空間の協調スレッドを使うことでコードを書く人の意図したタイミングでShredを制御できること、と書いてあってこれについては時間軸を持つメディアを扱うものらしいと感じた。あとは普通のthreadだとdead lock気にするの嫌とかスケジューラがユーザ空間で動いてるからカーネルに手を入れずに最適化できるとか書いてあってこれらは普通のプログラミングと変わらない。

論文中では他にもコンピュータを使った作曲システムの歴史とかリアルタイムにコード変更反映するためのVM周りの話とかパフォーマンスと関係するon the fly programmingの話とかあって面白そうな感じでした。

■

Thomas Ruffのインタビューを読んだ。内容については前もどこかで似たようなものを読んだことがあったので特に思うことはなかったのだけど、人からnudesいいよと聞いていながら印刷物は見たことなかったなと思ってネットでjpegs買ったら思ってたより大きいものが届いた。一般的な写真集より大きめ紙に印刷された写真でDCTの8x8ブロックの影響が見える。ネットで検索して見れるものとの違いは媒体の性質を除けば大きさだけなんだけど、いい。

それと1年くらい前から見たいなーと思ってたvalerie phillipsのi can't believe a girl is playing me metallicaも見た。こちらは思ってたよりも小さい本で。viktoriaかわいい。

年報2008-2009

確か2007年9月いっぱいで前の仕事を辞め就職活動らしきものを始めたのは一年後の2008年10月頃、決まって働き出したのは2009年2月なので17ヶ月好きな亊してた。
今の会社にはperl技術者として入ったのだけど色々考慮した結果自分の担当箇所はruby化することにした。移植作業こなしつつ現行バージョンのメンテ/バグフィックス/今まで対応してなかった入力形式に対応するための修正といった感じ。あのサーバ重いから次はこの構成にしようとかは今までなかったので楽しい。

echonestがおもしろくてrubyのechonestモジュールの元ネタ書いたり、ruby-echonest使うこと前提でscissorに乗ってビデオ切り刻むモジュール書いたりした。http://www.youtube.com/user/rtk2106#g/uにある検索避けっぽいタイトルが作例でコードはgistのどこかにあるはず。その流れでopenframeworkも触ったんだけどlinux版のビデオまわりがいまいちで途中で放置した。ISMIRにechonestの人とBBCの人が来てて興味はあるけど平日だし学術的知識なさすぎなので行くのはやめといた。

wonder-wall.comが出たとき昔似たようなことやったことを思い出したのと社内flash勉強会でなんかやれと言われたタイミングとあったので一部再現したのがこれ。社内flasherの方にもネットでバーンと発表すればいいじゃないですかみたいな亊言われたんだけど、これは自分が今やることじゃないんです、とさらっとリンク貼る程度にした。

仕事絡みだとperlからの移植ついでにでTheSchwartz使ってるとこをQ4Mにしてhttp://github.com/koyachi/ruby-q4mとかワーカープロセス管理にhttp://github.com/koyachi/ruby-log0xとか作ってる。log0xは元々社内にあったプログラムをruby化&社内情報隔離&WorkerManagerの影響受けて作ってるもの。プロセスまわりとかやってる影響で今までなんとなくしか知らなかったlinuxの低レイヤも詳しくなりつつある。

kathy graythonさんのブログがおもしろくてとりあえず3年分くらい見た。New York Minute Bookも買った。本の内容はブログのどこかにかなり載ってるけど探すの面倒なので興味ある方は探してみてください。

ucnvさんがおもしろかった。gif-glitch, aviglitch, datamoshing, とかとか。役に立たないけど技巧的なものばかり。誰かも言ってたけどプレゼンテーションをほとんどやってないってだけでやってることは有名な人も含めてそこらの人よりすごい。

unicode posterのあたりからユニコードグリフおもしろいなーと思い始めてtwitterでの携帯絵文字を使わない文字コミュニケーションでboxer(o'-')-oとかdecodeunicode,unifaces,newmoticons,twitclipart,TW1TT3Rartとか他にもあると思うけど比較的普通の人もこういうの見て真似して意識せずにnetartっぽいことできてるのがおもしろい。僕もランダムで表示しておもしろグリフ探すやつ作った。

今年は割とまじめに仕事してた気がするので程々にして仕事に使えないこともなんかやります。ホームページとか。