びぃえるくぅと。

ガラケーは打楽器。

Case-sensitive な macOS 上で Cinder のビルドにコケた話

ご無沙汰しております。

最近 macOS 10.12 をクリーンインストールする機会があり、もちろん SSD も綺麗にフォーマットしたわけですが、 今まで見落としていたのか「Case-sensitive」(日本語: 大文字/小文字を区別) というものに興味を惹かれて有効にしてみました。

そしたらまさかの Adobe ソフトがインストールできないとまぁ大笑いだったわけですが。

「大文字と小文字が区別されるドライブへのインストールはサポートされていません」エラー

MacIllustrator が使えないのは辛いですね・・・。

Cinder のビルドができない

openFrameworks のライバル(?) である Cinder というものがあり、 公式サイトから既にビルド済みのパッケージをダウンロードすることができますが、 Github 上のリポジトリからソースコードをクローンしてきて CMake でビルドすることもできます。

GitHub - cinder/Cinder: Cinder is a community-developed, free and open source library for professional-quality creative coding in C++.

ところがいざビルドしようとすると、CMake が以下のようなエラーを吐いて止まってしまいます。

CMake Error at proj/cmake/libcinder_target.cmake:14 (add_library):
  Cannot find source file:

    path-to-libcinder/src/AntTweakBar/TwOpenGl.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

src/AntTweakBar/TwOpenGl.app が見つからないって言っていますね。 では src/AntTweakBar ディレクトリを見てみましょう。

f:id:yadex205:20171020131849p:plain

なんと TwOpenG"""L""".cpp という名前で存在しています。

おそらく開発陣が CMake ファイルを作られた時に TwOpenG"""l""".cpp と誤植 (と言えるのか) してしまったのかと思われますが、 普通の macOS なら Case-Insensitive (大文字/小文字を区別しない) 環境で動かしていると思いますし、 ビルドに失敗することもなかったのでしょう。実際僕も以前ビルドした時にはこんな問題は起こらなかったです。

Issue を書き込みました。

ぶっちゃけこれが言いたかっただけなのですが、この件は一応 Issue を投げました。

CMake says "Cannot find source file" on macOS with Case-sensitive filesystem · Issue #1920 · cinder/Cinder · GitHub

まぁファイル中の 1文字を直すだけなので、手元にクローンしたやつを書き換えるだけでとりあえず対応はできていますけどね。

まとめ

Case-sensitive なディスク上で macOS を動かすとたまに不便になります。

話が逸れますが、Docker for Mac で 大文字小文字の区別関連で苦労されてる方もいらっしゃるようですね。

qiita.com

こちらは Case-sensitive な方が良いというパターンですので、一概に Case-sensitive はダメ、とも言い切れないですね。

告知など

いつも通りの唐突な告知です。以下のイベントで VJ で出演いたします。

#アジア二 第4期

twipla.jp

GOTTA VISION

GOTTA VISION VOL.5

また、この度 VJチーム SabaLeoN に所属することになりましたので、 SabaLeoN メンバーとしても各所に VJ しに行きます。

何卒よろしくお願いいたします。

Capistrano3 でリモート側の環境変数設定されてないなって思ったら

どうでも良いことで 2時間くらい食って悔しかったのと日本語記事がなかったように思えたので書きなぐりました。

症状

Capistrano でデプロイ先で、.bashrc に書いた環境変数が設定されないまま処理が行われてしまう。

対処

以下の Stackoverflow に答えがありました。

stackoverflow.com

デプロイ先の .bashrc なりシェルの設定ファイルの先頭に

# If not running interactively, don't do anything

みたいなコメントと、その直後に return してそうな箇所はありませんか?

Ubuntu など一部のディストリビューションのシェル設定ファイルの先頭には「インタラクティブシェルじゃないならこの後の設定は読み込まない」ような記述がされていることがあるため、その記述をコメントアウトするなりその記述の前に設定を書くなりの対策をとれば良い感じになると思います。

AmazonLinux だとそのような記述がなかったから完全に見逃してた・・・。

flycheck で走らせるプログラムを探すのに direnv に手伝わせる時の注意点

挨拶

またしても前回の投稿から間が空いてしまいましたが、なんと就活が終わっていたり 大学院を中退していたりと色んなことが起こりました。ひと段落したので VJや動画制作やWebデザインなど、もっと取り組んでいきたいと思います。

flycheck が使う文法チェック系プログラム

Emacs でリアルタイムに文法チェックを行うのに便利なのが flycheck ですが、 flycheck 自体がコードを調査しているのではなく、rubocop やら eslint やらを 実行しているのはご存知かと思います。

それらのプログラムはどのように探されているかというと、シェルが $PATH から プログラムを探すように、Flycheck は Emacs 上の変数 exec-path から探しています。 公式ドキュメントにその記述があります。

また、exec-path の中身は

M-x describe-variable RET exec-path

で見ることができます。

direnv を使ってプロジェクト毎の文法チェックプログラムを探させる

少し話が逸れますが、eslint だったり rubocop と言った文法チェック系のプログラムは、 なるべくグローバルにではなくプロジェクトのディレクトリ内に置いときたい派です。 なんとなくなのでちゃんとした理由があるわけではないです。

なので、例えばNode.js 系のプロジェクトなら npmeslint を導入すると、 node_modules/.bin ディレクトリに実行ファイルが置かれるような状態です。

普通はそのようなディレクトリには $PATH が通ってませんが、direnv を使えば プロジェクトのディレクトリ下に入った時だけ $PATH にそれらを含めることができます。

.envrc というテキストファイルをプロジェクトのルートディレクトリに置き

export PATH="node_modules/.bin:$PATH"

と記載してやると良い感じになります。細かい話などは割愛しますので調べてみてください。

そして、普通シェルから立ち上げた Emacs$PATH から exec-path に値が丸写しされますし (GUI の場合は exec-path-from-shell というパッケージが要るそうです)、 direnv 管理下のファイルを Emacs で開けば .envrc に書かれた内容も もちろん exec-path に反映されています。

.envrc での $PATH の追加の仕方に注意

ただし、上記の export PATH="bin:$PATH" のように相対パスで指定すると、実はうまく動かない時が出てきます。

例えばファイル構成が以下の場合を想定します。

  • /your/great/project/.envrc
  • /your/great/project/node_modules/.bin/eslint
  • /your/great/project/code1.js
  • /your/great/project/nested/code2.js

.envrc には

export PATH="node_modules/.bin:$PATH"

が記載されています。

このとき、Emacs/code1.js を編集しているときは $PATH に従って /node_modules/.bin/eslint を見つけにいきますが、/nested/code2.js を編集しようとすると /nested/node_modules/.bin/eslint を探しに行こうとして見つからずに失敗します(多分そうだと思います)。

なのでEmacs の flycheck を利用する場合は $PATH は必ず絶対パスである必要があります。

PATH_add で楽して絶対パスを指定する

では .envrc には必ず絶対パスを書く面倒なことをしなくちゃいけないのかというとそうではなく、 PATH_add という便利機能が備わって要るので、それを使いましょう。

PATH_add node_modules/.bin

これによって $PATH には /your/great/project/node_modules/.bin のように 絶対パスで追加されます。

結論

プロジェクトディレクトリ以下に文法チェック系のプログラムがあり、 かつ flycheck にそれを見つけさせるために direnv を使う場合は、 PATH_add を使った方が良いと思います。

告知

5月中に 2件VJやります。

初めて学外でVJやった 武蔵小杉アルファクロス 様でまたVJできるのとても楽しみです。 エイジアも2回目になります。前よりゴリゴリ視力削っていきたいです。

お時間あれば何卒よろしくお願いいたします。

MacBook Pro Late-2016の画面出力について

そろそろ収まってきた頃だと思いますが、MacBook Pro Late-2016、すごいTwitterとかで話題になりましたよね。 そんな TouchBar 付き MBP ですが、直前の記事に書いた通り先月購入し、VJ用に整えている最中です。

ですが、最近 USB-C → HDMI アダプタを使っての画面出力がどうにもうまくいかないので、 原因の特定には至ってませんが気になる英語の記事を見かけたので、軽くまとめます。

画面出力の不具合

僕が使っているのはこの ELECOM の製品なんですが、初めの頃は問題なかったのですが、 現在以下のような現象が起きています。

  • プロジェクターに直接 HDMI を接続しても、Mac 側はプロジェクターを認識しているものの、プロジェクター側は「映像が来ていない」と思っている。
  • HDMIを Blackmagic design Intensity Shuttle (HDMIキャプチャ) に接続させると、キャプチャ側で映像のサイズやフレームレートは認識できるのに青い画面しか見れない。
    • 分かる人には分かる魔法 (Kanaan の HDMI スプリッター) を経由するとなぜかキャプチャ側で映像が映るようになる。

まさか常時 HDMI 出力に HDCP かかるようになりましたとか、そんなことはないですよね・・・。ていうかプロジェクター HDCP 対応してるでしょ(してた)。 そもそも、初めの頃普通に表示できていた理由もわかりません。

「Late-2016で USB-C to HDMI はやめとけ」という英語の記事

情報を探していましたが、直接の解決策となる情報は見つからず。 ただ、

blog.fosketts.net

こちらの記事に興味深い情報が書いてありました。要点をまとめると、

  • サードパーティーの USB-C to HDMI はまともに動かない (ただし Mac はディスプレイを認識できている)
  • そもそも Apple 純正の USB-C to HDMI すら動かない
  • USB-C to DisplayPort はしっかり動くので、今は DisplayPort の方をつかうべき

ただ、この方は Radeon 入り 15インチ MacBook Pro なので、僕の13インチ内蔵フラフィックスとは状況が違うかもしれません。

結論

VJするには非常に面倒なマシン買っちゃったかも・・・。 原因がわからないのが辛いですが、前述の通りなぜか魔法を使うと映るので、しばらくはそれで対処しようと思います。

追記

この記事を書いた直後にこんな追記するものアレなのですが、以下の構成でふっつーに出力できました。まじなんなん・・・。

MacBook Pro → Elecom の USB-C to HDMIHDMI to DVI ケーブル → BenQのディスプレイ (GL2250)

今後のVJ機器の構成を妄想

賀正

2017年

またしても前回の記事から時間が経ってしまい、気づいたら年が変わりました。 明けましておめでとうございます。 今後とも何卒よろしくお願いいたします。

大学院の方は相変わらずの進捗の悪さに定評がありますが、そろそろ覆したい気持ちです。

そしてVJですが、環境とか手元にあるリソースが大きく変わったので、 自分のやり方を維持しつつ構成をアップグレードしたいなという妄想をしたかっただけです。

ちなみにこの記事を書こうと思った発端は以下の通りです。

構成の妄想

f:id:yadex205:20170105230815p:plain

実は1月2日にVJ新年会というとても楽しい会があって、その時にVDMXを買ってしまったのですが、 パッと見自分のやり方に実は合ってる気がしたので、極めようと思っています。

その上で、今まで VVVV + V-4 でやってきたのに近いプレイを MacBook Pro + VDMX でやろうと考えています。

ThinkPad の方では VirtualDJ をメインで動かそうと思います。 そしてVDMXとVirtualDJの出力をミキシングし、最終的なエフェクトをかけ、プロジェクションマッピングするソフトとして Resolume Arena は使っていきたいです。

ちなみに、MacBook Proの方でVDMXとArenaを両方起動したところVDMXがかなり怪しくなったので、 できることなら同時起動させたくないなと思いました。

自分のVJ環境の変化

一応参考程度に、覚えている範囲で。

大学サークルでVJ (2014年9月ごろ~)

軽音楽系のサークルで、先輩がDJしている隣でVJをはじめました。

PCは ThinkPad E430、完璧にエントリーモデルなノートパソコンです。 ソフトは Resolume Avenue をしばらく体験版状態で使い、 途中からちゃんと購入して使っていました。

コントローラーも途中からド定番 nanoKontroller2 と nanoPad2 を買って、今でも使っています。

学外でVJ活動開始当初 (2015年10月ごろ~)

ライセンスBANされた Resolume Avenue を1回だけ使い、 そのあとは VVVV を使ってでっち上げたVJソフトもどきで何とかしのいでいました。

結局ここから1年間くらい VVVV だけでVJしていました。(何回かElectronで作ったソフトも使いました)

なお、コントローラーも AKAI APC mini を新しく買いました。

V-4 入手 (2016年4月ごろ)

諸事情あって、夢の Roland V-4 を入手しました。

例のVJソフトもどきはエフェクトをかけられるように実装していなかったので、 V-4を使ってチカチカするようなVJができるようになってかなり楽しくなりました。

自分がプロフィールに書いてる「目に悪いVJをしています」感じのスタイルはこのあたりで出来てきたのだと思います。

Pioneer DDJ-RB, GoVJ 購入 (2016年8月ごろ)

ニコル君と話していたら気づいたら買っていました。

同時に、VirtualDJ と GrandVJ を組み合わせたようなソフトを作ってみたいと思うようになって、 Electron(Node.js)でVJソフトもどきを作り、DDJ-RB, nanoKontroller2に対応させました。

ちなみにソフトの完成度はファッキンと言ったレベルです。

また、GoVJという iOS 向けVJアプリを購入し、 ThinkPadで動いてるVJソフトが死んだときの応急処置として用意するようになりました。

Resolume Arena, VirtualDJ 購入 (2016年11月)

ブラックフライデーに合わせて、再び Resolume 製品を買ってしまいました、しかも Arena です。 買ってしまったというか、某VJさんにそそのかされて買いました。

また、それとは別に VirtualDJ を購入し、いわゆるアニソンVJのようなスタイルもできる準備はしました。

VVVVでやってた頃とは違ってスタイルがある程度制限されるようにはなりましたが、 やはり有償ソフトならではの安定さと、特に Resolume のエフェクトの豊富さは使っていて気持ちいいです。

MacBook Pro 購入 (2016年12月)

念願のMacBook Pro を購入しました。 ThinkPadを使っていた時よりは確実に性能が良くなりましたし、Syphonが使える強みもあります。

最後に

本年も、何卒よろしくお願いいたします。V-1HD欲しい。

Flycheck の In file included from 警告を消す

備忘録です。

謎警告

最近 emacs で Node.js のネイティブモジュールを書いてみたり、 Qtアプリケーションを作ろうと頑張っているのですが、 #include 文のところで Flycheck に こんな警告をよく吐かれていました。

In file included from

In file included from

In file included from

In include /usr/local/opt/qt5/include/QtWidgets/QApplication

・・・そもそもこれエラーなのか何なのか。

原因

どうやら flycheck のバグだとか何だとか言われていて(某所だとパースエラーだとか)、 flycheck の警告文からでは何が問題なのかがわかりませんでした。 なので、flycheckがどのようなコマンドを叩いて、どのような結果を得ているのかを どうにか見れないか調べてみました。

色々調べてみたところ、

github.com

に書いてある通り、C-c ! C-c を叩くことで、実際に実行されているコマンドと 実行結果(解析結果)の全文を見ることができます。

結果

で、やってみたところ

 1*- mode: compilation; default-directory: "(省略)" -*-
 2Compilation started at Tue Nov  8 15:04:30
 3
 4clang -fsyntax-only -fno-color-diagnostics -fno-caret-diagnostics -fno-diagnostics-show-option -iquote (省略) -Wall -Wextra -I (省略)
 5In file included from <stdin>:1:
 6In file included from /usr/local/opt/qt5/include/QtWidgets/QApplication:1:
 7In file included from /usr/local/opt/qt5/include/QtWidgets/qapplication.h:43:
 8In file included from /usr/local/opt/qt5/include/QtCore/qcoreapplication.h:43:
 9/usr/local/opt/qt5/include/QtCore/qglobal.h:1133:23: warning: rvalue references are a C++11 extension
10In file included from <stdin>:1:
11In file included from /usr/local/opt/qt5/include/QtWidgets/QApplication:1:
12In file included from /usr/local/opt/qt5/include/QtWidgets/qapplication.h:43:
13In file included from /usr/local/opt/qt5/include/QtCore/qcoreapplication.h:43:
14In file included from /usr/local/opt/qt5/include/QtCore/qglobal.h:1145:
15In file included from /usr/local/opt/qt5/include/QtCore/qatomic.h:46:
16/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:61:4: error: "Qt requires C++11 support"
17/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:90:13: error: unknown type name 'QAtomicOps'
18/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:90:23: error: expected member name or ';' after declaration specifiers
19/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:93:23: error: use of undeclared identifier 'QAtomicOpsSupport'
20/usr/local/opt/qt5/include/QtCore/qbasicatomic.h:93:53: error: no member named 'IsSupported' in the global namespace
21/usr/local/opt/qt5/include/QtCore/qglobal.h:761:63: note: expanded from macro 'Q_STATIC_ASSERT_X'
22/usr/local/opt/qt5/include/QtCore/qglobal.h:756:110: note: expanded from macro 'Q_STATIC_ASSERT'

(以下略)

なるほど、原因はC++11絡みのところにあったらしいです。

何が原因かというと、C++11に対応していない状態で flycheck を動かしていたということでした。

stackoverflow.com

上記によると、emacs の設定ファイルに

(add-hook 'c++-mode-hook (lambda () (setq flycheck-gcc-language-standard "c++11")))

を追加することで、flycheckが C++11 に対応してくれるようです。 私の環境でもこれで治りました。

結論

Flycheck の謎警告に困ったら、 C-c ! C-c を見てみましょう。

#アジアニ に出演しました! & JavaScriptでVJソフト自作しました

台風3つが同時に日本に攻めてきてますが、 昨日、渋谷clubasiaで3フロア同時にアニソンがかかる #アジアニ というパーティーがあり、 メインフロアのVJとして参加させていただきました!!

#アジアニ

シンガポールからのゲスト、ほとんどDJブースにいない方、お笑い芸人、そしてアニソン歌手まで、 多彩な方々がDJ、ライブをされて会場が死ぬほど盛り上がってる中VJさせていただけたのは本当に光栄と言いますか。。。

たくさんのお客さんを前に少し高いブースでVJできたことが本当にたのしかったです。

自分のVJですが、結局モーショングラフィックス系しか流さず、 OP等の映像は一緒にメインフロアでVJされたあっちんさんやちゃーさんに押し付ける形になってしまいました。 が、あくまでこれが自分の得意分野であるし、結果として得意分野を分担し合った連携VJができて良かったです。(個人的にはですが。。)

一点だけ、HOT LIMITが流れた時に

f:id:yadex205:20160821084512j:plain

これを出しました、ありがとうデリケア。なお、お客さんの反応は見ることができず。。

結果として、今までやってきたVJの中で一番楽しかったし満足することができました。 出演されたDJ、VJさん、asiaのスタッフさん、#アジアニ の主催者さん、お越しいただいたお客さん、本当にありがとうございました!

自作VJソフト

以前より金欠を理由にVJソフトは買わずに作ってきましたが、今回も例に漏れず自作VJソフトを実戦投入しました。 ただし、以前のようにvvvvでパッチングするのではなく、JavaScriptでゴリゴリコードを書きました。

JSと言っても、要するにNode.js + Electronなのですが、本当にJSしか書いてないです(強いて言えばWebGLのシェーダーが別言語なくらい)。 なおGitリポジトリ https://github.com/yadex205/berkut で公開しています。随時更新していきます。

ということで、まだまだ未完成なのですが、今回VJソフトを作るのに使った主な技術などを紹介してみます。

WebChimera

Node.jsにlibvlcをバインディングしたnpmパッケージ。 つまりNode.js上でVLCメディアプレーヤーが再生できるメディアを再生することができる魔法のようなライブラリです。 再生と言ってもピンとこないかもしれませんが、要するに1フレームのピクセルごとの色情報を配列として取得することができます。

[13,34,62,35,74,215 ...]

みたいな感じです(どんな感じだ)。

なお実際に使う場合は、すでにビルド済みの wcjs-prebuilt パッケージを使うのが無難です。 また、Electronで使う場合には(こちらがメインですが)、 wcjs-renderer パッケージを使うことで HTMLのCanvas に動画を描画することができます。

WebGL

最新のウェブブラウザでは、Canvasタグ上でその場で3Dモデルをレンダーすることができちゃうんですが、それを実現するのがWebGLという仕組みです。OpenGLをそのままブラウザに移植したイメージ、かもです。

前述のwcjs-rendererWebGLを使って動画のフレームを描画しています。 今回の自作VJソフトはwcjs-rendererを改造し、複数の動画のフレームを任意の合成方法(加算、乗算など)で重ねられるようにしました。

node-ffi

そもそもFFIとはなんぞやですが、Wikipedia曰く

あるプログラミング言語から他のプログラミング言語で定義された関数などを利用するための機構

だそうです。今回はこれのNode.js版である node-ffi を使って、Windows限定ですが kernel32の関数を呼び出しています。

VJソフトってコントローラーや動画リストとかが表示されているウィンドウと、ミキシングされた動画を出力するウィンドウが2つ普通ありますよね。 もちろん今回もそのようにしたのですが、Electronではウィンドウ同士は別プロセスになります。 つまり、コントローラーウィンドウの方でミキシングしたフレームを出力ウィンドウに渡そうとする場合、プロセス間通信が必要になり、フレーム情報がシリアライズされるのですが、これがとても無駄に重たい処理になります。

願わくば、コントローラーウィンドウが保持しているフレーム情報が格納されているメモリのアドレス(ポインタ)を出力ウィンドウに教えることが出来れば。でも原則、プロセスごとに割り当てられるメモリのアドレスは仮装的なもので、他のプロセスが保持するポインタを直接見ることはできません。

ところが、WindowsAPIReadProcessMemoryという関数があり、他のプロセスのポインタが示す内容を見ることができます。これを呼び出すためにnode-ffiが必要でした。

他にもNeDBというドキュメント型データベースを使ってサムネイルの管理をしたり、ビューとデータのバインディングVue.jsを使ったり、UIにはBootstrapを使ったり、さらにメディアファイルのインクリメンタルサーチを便利にするためにJS版migemoを使ったり、、色々使ってます。

眠たくなったのでこの辺にします、おやすみなさい。。。

Copyright © 2015 Yadex205