emacs auto-complete-clang 導入メモ

久しぶりに投稿...

最近は忙しさのせいか趣味よりのプログラミング的なことはあんまりできてないけど、仕事/趣味のプログラミング環境をできるだけノマド化するためにemacsの設定なんかを頑張ってみている。
その中で掲題の件、emacs のauto-complete-clangの導入を試みたけれどなかなか手間がかかったのでメモ

ちなみにauto-complete-clangについては↑のようなことができるやつです。
なかなかgeekっぽくていい感じ。

基本的には こちら とか こちら とか先人が公開してくれてる通りにやれば出来るんだけれど、 以下の点で躓いた。

1. yasnippetは0.6系じゃないと動かない 
2. clang -cc1のインクルードパスが…ない！

1はまあその通りなのであえて書くことも無いけれど、yasnippetの最新版はgoogle codeからgithubに移動しており、こちらのバージョンは0.7でこれまでと少し使い方が変わっているみたい。
auto-completeと協調して動かすためにはgoogle codeに残っている方の最新(0.6系)を使う必要があった。

2の方が結構厄介だった。
llvm/clangに関してmacを使っていればアップル謹製のclangがあるので特に問題はなくauto-complete-clangが動いた。
しかし、業務用のlinuxサーバ環境で独自にビルドしたclangだと-cc1オプションをつけた場合デフォルトのインクルードパスをちゃんと見てくれないという症状が出た。(-cc1をつけないとOK。不思議。。。)
この問題も同じ症状の先人が既にいてしかしまだ未解決の模様。
http://b0r0nji.blogspot.jp/2012/05/clangcc1.html
clang -cc1でインクルードパスを見てくれないとプリコンパイルヘッダの生成もできないしそもそも動かない…

どうしても諦めきれなかったので色々試行錯誤してみた。
まず環境変数でインクルードパスを与えられないかと思ってトライ。clangがインクルードパスとしてみている環境変数はINCLUDEではなくCPATHらしい、こちらに必要なパスを埋め込んでみた。結果としてはclang のみだとCPATH見てくれるけど、やはりcc1をつけると見てくれない。。

ここで心はもう折れかけたけどなんか-Iのオプションは有効みたい。
オプションで与えられるならなんか設定のところで

(setq ac-clang-flags '("-w" "-ferror-limit" "1"))

とかでclangのオプション与えてたような…
というわけで ここ の最後の方の記述も参考にして以下の記述をemacsの設定ファイルに書いてみたところ、なんとか動くようになった。

  (setq ac-clang-flags (append
      (mapcar (lambda (item)(concat "-I" item))
              (split-string
               "
 /path/to/include/c++/4.7.1
 /path/to/include/c++/4.7.1/x86_64-unknown-linux-gnu
 /path/to/include/c++/4.7.1/backward
 /usr/local/include
 /path/to/lib/clang/3.2/include
 /usr/include
"
               )) ac-clang-flags ))

上のインクルードパスは"clang -v -x c++ /dev/null -fsyntax-only"とかやって出てくる奴をコピペしたもの。それをsplitしてリストにして"-I"つけてオプションのリストの変数であるac-clang-flagsにくっつけてやる感じ（lisperではないので適当）。
ちなみにこの記述の前にac-clang-flagsが定義されている必要があるかも... ない場合は (append と ac-clang-flags)をのぞけば大丈夫のはず（未確認）。
ちなみにヘッダのプリコンパイルも同様に-I/path/to/include/c++/4.7.1 ...とかを片っ端からつけてやれば出来た。

これでめくるめくauto-complete-clangの世界を堪能できます。

参考
http://d.hatena.ne.jp/kenbell1988/20120428/1335609313
http://www.nomtats.com/2010/11/auto-completeelemacs.html
http://b0r0nji.blogspot.jp/2012/05/clangcc1.html

Links to this post

3D input/output としての Kinect/3Dテレビに思うこと

まずは3DなinputであるKinectに関して、
最近はこっそりopenframeworks + ofxKinect を触ったりしてるが、
プログラミングする上で気づいたこととして、kinectの適正距離はわりと不自由。
ネット上で適正距離1.8m〜って見た覚えがあるけど、実際近すぎると深度と色の関係が破綻する印象。
（そうでなくても色と深度の関係は個体差があるらしく、
　openframeworksのフォーラムでもキャリブレーションが話題。）
日本の住宅事情の中では適正距離のあたりがネックになったりするんだろうか。
しかしKinectいろいろやってるだけで結構楽しい。未来を感じる。

ofxKinect study #07 from Atsushi Tadokoro on Vimeo.

（映像はAtsushi Tadokoro氏によるデモ）


一方で3Dなアウトプットである3Dテレビに関して、
日本の電気メーカー各社から3Dテレビが出揃った感があるが
現状の3Dテレビには根本的な問題としての見たときの不自然さ、気持ち悪さみたいなものがある。
個人的な意見としては臨場感が増すメリットより不自然さを感じるデメリットの方が大きいと感じた。

不自然さの原因として3Dグラス自体はあまりネックにならない。
各社の3Dグラスともオンになった状態でも少し暗くなるかなっていう程度で全然気にならない。
これは素直にすごい。

ではなぜ現状の3Dテレビが気持ち悪いかというと映像そのものの不自然さがあると思う。
普段人間が見てるものは当然のごとく3Dな物体だけど特に不自然とは思わない。
映像の中の3Dがなぜ不自然になるかというと被写界深度の問題がある。

人間の目を含めた光学系にはピントが合う範囲があって、
ピントが合ってない、つまり注目していない領域の映像はぼける。
人間は普段意識はしなくても注目しているものだけ見られるハードウェアを持っているということ。

一方、3DTVでは注目してない領域の映像も強制的にピントがあった状態で見させられる。
このことが3D映像を見たときの不自然さ、ひいては長時間見たときの疲れに繋がっていると思う。

この課題は3D映画などの予め被写界深度を意識して作り込めるコンテンツでは回避可能かもしれない。
しかし、別の臨場感を求められるコンテンツ、例えばスポーツなどの生中継や、ライブ映像などのコンテンツでは難しい。
なぜならこういうコンテンツは映像を作る上で注目する対象に対してピントを外す失敗が許されないため、
できるだけ被写界深度を長くしたパンフォーカスでの映像をつくることが多いからだ。

しかしこの問題はソフトウェアでの解決が可能な問題でもあるよなあと思う。
深度情報を持ってるんだから注目以外の部分に深度に合わせたガウシアンフィルタでもかけてやればいい。
計算量度外視すればソフトウェアで解決できるんじゃないだろうか。
もちろん注目する深度をどこにするかなどの問題はあるだろうけど、
そこはトラッキングアルゴリズムとかでいけるでしょう。
Kinectは人間をトラッキングできちゃってるわけですし。

日本の電機メーカーが単なるハードウェア屋を抜け出せないのはそのあたりの詰めの甘さもある気がする。
要はもっとソフトウェアに力いれろよと。

そんなこと考えながらkinectを用いた擬似的なハイスピードレンズ（被写界深度の浅いレンズ）の
デモでもやってみようかなーとか思ってたら、以下のようなニュースが


WiiリモコンハッカーからKinect 開発者のJohnny Chung Lee氏、Googleに移籍
http://japanese.engadget.com/2011/01/18/wii-kinect-johnny-chung-lee-google/


（映像はJohnny Chung Lee氏の学生時代のデモ）

日本の電機メーカーがGoogleの破壊的イノベーションの対象にならないように祈ってます。

tweetloop

去年夏ごろgoogle app engine にアカウントを作り、
一通りいじってみたあと特にすることもなかったので放置してたが、
年始ごろに思いついたprocessing.jsとsoundmanager2を使って音がなるサイトを作成してみた。

具体的にどんなサイトかというと、以前動画を公開したmonome用のソフトに近いもの
（つまり乱数に頼ったシーケンサーのようなもの）をweb上で再現し、
作ったloopを保存してtwitter上で呟けるようにしたもの。

http://tweetloop.appspot.com/
（注：IEでは動きません）

canvas上でマウスをクリックする事によりループを作成し、
保存して共有されたモノは他人によって改変され、"ReTweet"できる。

これで僕が作ってみたいものは
楽器をある程度やってきた人だけに許される即興でアレンジする、Jamる、という感覚を、
（自分のような）楽器は出来ないという人間も含めた人みんなの中で共有できるようなもの。
しかもニコニコ動画のように非同期の同時性を含む形で。

それを実現するためにはもっと多くの人達に共有してもらう必要があるが、
そこに至るために足りないものがまだある気がする。
実際勢いだけで作ってみたものなので手が回ってない部分もある。
現状あくまで余暇を使ってやっていることなので、なかなか開発の加速は出来ないが、
最終的にはもうちょっといいもの、理想に近いものに近づけるつもり。

自作monome用ソフト動画

ChucKで前々から作ってたやつの演奏動画をアップしました。

http://www.youtube.com/watch?v=bSrLV8zcZm4

しかし機能の一部しか使ってないので紹介動画としては微妙。

そして画質も微妙。HDな録画環境が欲しいけど
最近GR3やらAbleton Liveやら立て続けに買った上に
年末アメリカまでライブ観に行ってかなり金遣い荒い感じなので当分我慢かな…

ChucKにおけるFileIO

いつかやろうと思っていた自作monome用のソフトへの
簡易的なFile入出力機能をようやく実装した。
着手してみると特に引っかかる所なく出来た。すごく簡単。
（簡単なんだけど簡単なものに限って
面倒くさくて後回しにしてしまうのは悪い癖）

ChucKの持っているFileIOやstringクラスは
当然の事ながらP言語なんかと比べると笑っちゃうくらい貧弱。
実装できる保存形式もStringTokenizerクラスで分割出来るのはspaceだけ（？）だから
space-separated valueしか無いよね？ってくらい
しかしながらChucKで少し使うくらいの機能としては
これで十分なんだと割りきってリリースしてるんだろうと思う。
（実際自分が実装したい機能も十分実装出来た。）
このあたりの割り切りはChucKのおもしろくてかわいい所だと思います。

ChucK 1.2.1.3

何時の間にやらファイル入出力がサポートされたらしい。
これでずっと前作ったシーケンサーに入出力機能が作れそう。

そしてChucKで全然別件だがはまったのでメモ
ChucKを使ってmidi note 36〜85までのエンベロープ付サイン波のwave file自動生成を行った
その際にWvOutを使って出力したwaveファイルが何回やっても
再生時間などの情報を持たないファイルになり再生出来ない。
もちろんShredは終了しているのにも関わらず。。。
相当何時間も試行錯誤したのだが、
結論だけ言うとVirtual Machineを止めないと
最終的な出力ファイルのヘッダ情報（？）は書き込まれない模様
miniAudicleの[Stop Virtual Machine]を押してからプレビューすると普通に再生された。
最終的にマニュアルを読んでてふと思いついたが、これはわからん！ちゃんと書いといて！！

SuperCollider メモ

SC3.3.1日本語版+Leopardでは便利だったヘルプ機能が使えない...
これは開発能率が激しく落ちる…
対策としてパッケージの中のJapanese.lprojを適当にリネームしてやったら
⌘+Dでヘルプにとべるようになった。
（もちろんメニューとかは英語になります。）

そしてmonome+BBCut2ですが
BBCut2気軽にオサレな感じのbeat作れるけど自由度低いなー
ていうか音量変えたいときとかどうすんの！？
ヘルプ見ても書いてないし！って思って少し萎えてました

そんななかふと⌘+Jでクラス定義みたらちゃんとありました。変える方法が。



(
~tempoClock = TempoClock(3);
~bbClock= ExternalClock(~tempoClock).play;
~bbClock.tempoclock.tempo_(90/60.0);
)

~sf= BBCutBuffer("sounds/break",8);
~cb= CutBuf1(~sf);
~cp= BBCutProc11.new;
~bb= BBCut2(~cb,~cp);
~bb.play(~bbClock);

~bb.amp_(0.2);

~cp= SQPusher1.new;
~bb.proc_(~cp);

~bb.end;


テンポ変えたいときは~bbClock.tempoclock.tempo_()
音量はbb.amp_()
ビートの刻み方（？）は~bb.proc_()

それぞれリアルタイムに変えられる模様

hoge_()ってのはSCでは一般的な書き方なんだろうか？

ヘルプはちゃんと見ましょう。見てわかんなかったとしても
クラス定義みたら幸せになれるかもよ？って話でした。

これでmonomeとのインタラクティブな連携の形が見えて来た（かも）


しかしSuperColliderはポートlangPort（デフォルトでは57120）以外では
monomeSerialの出すようなOSCは受け取れないのね…問題無いっちゃ無いけど…