2023/3/25 アレの日@club about VJ振り返り

アレの日というPsychedelicTransのパーティに呼ばれてVJをしてきた。
自分のための備忘録も兼ねてまとめておく。

かねてからPsychedelicTranceでVJやってみたいなぁと思っていたのだが、ひょんなきっかけから実現に至る。
引き寄せの法則じゃないけど、数年前からこういうのたまにあるんだよなぁ。
ぼんやりと欲しいものややってみたいことがあると、それが向こう側からやってくることがある。
不思議ではあるが常に縁には感謝を禁じ得ない。
あと、首都圏外のパーティに出演するのも初めてでテンション上がる。

持ち物

今回は現場にプロジェクターがないので、手持ちのBenQ MW560を持ち込む。
台形補正が無いものの安いし実験用にと一年ぐらい前に買ったものだ。
ただ初めて行く場所だと勝手が分からないので、一応16inchのモバイルディスプレイも持ち込み、HDMIスプリッターで両方に出力してみた。
今回のためにスプリッターを用意してみたが、これはなかなか良いかもしれないな。
ただMacBookProからの配線が多くなり、それぞれのケーブルの長さを考慮した配置に苦心することにはなる。
スプリッターへの給電用のアダプタを持っていくのを忘れて、慌てて近場のヨドバシカメラへ買いに行った。
やはり事前の設営シミュレーションは大事だな。
あと準備中は意外と暗かったので、明かりも持っていった方が良い。

今回のチャレンジポイント

基本的にいつもLiveCodingスタイルを貫いているが、このスタイルにも良し悪しがある。
ライブパフォーマンスとしての面白さや、似たようなことをやっている人が少ない希少性ってのはある。
また、その場で即興的に作り上げていくのでジャンルを問わずに対応可能な点も大きいかな。
もっとも、自分が対応できるだけのスキルがあるならば、という大きな但し書きは付くがね。
逆に苦手なところは、ブレイクなど急激な変化への対応か。
曲の展開に集中してればCodingだけでもある程度の対応はできなくはないのだが、ちょっと複雑な仕込みとかに集中してると対応が難しい。
まぁそこまで致命的ではないしこれは定めとして受け入れるかな、とか思ってはいたが、どうしても表現への制約は可能な限りクリアしたい。

ではこの課題を克服するにはどうするか、というのは常々考えていたがそれを今回は実戦投入してみた。

TouchOSCでこのようなコントローラーを作ってみた。
一応TouchOSC用ファイルを置いておく。リンク
ちなみに今回hydraはAtomエディタ向けpackage版を使った。
ただAtomエディタは開発終了してるし、今後どうするか考えないとなぁ。

// OSC初期化周りはこんな感じ
msg.setPort(12345)
tgl0 = 0
msg.on('tgl0', (args) => tgl0 = args[0])

tgl0〜tgl3は押すごとに0/1が切り替わるトグルスイッチ。
mom0〜mom3は押している間だけ1になるモメンタリスイッチ。
btn0〜btn3は何かしらの処理を発火させるためのボタン。
fad0〜fad3は0〜1の値を取るフェーダー。
OSC受けと、各変数への代入だけはあらかじめコードを書いておき、それを具体的にどのように使うかはその場で即興的に組み込んでいく。

このスタイルについては、自分の中でも少し葛藤があった。
真にLiveCodingと呼ぶならば1行のコードすらも持ち込まず、その場で全て書くべきなのでは？という原理主義的な考えがあったからだ。
もし持ち込みを許容するならば、いっそかなりの部分を持ち込んでパラメータ書き換えでやってしまってもいいのでは？
などと色々考えてしまうが、やはり自分なりのLiveCorderとしての矜持がそれを是とし難い。
無駄なこだわりではあるが、例え厳しい制約になってもそういうこだわりの上でライブする方が良いと考えていた。ただ同時に、常に同じ記述になるOSC周りのコードを持ち込むことに何の問題があるのか？とも考えた。
確かに頑張って暗記すればその場でも書ける程度の量ではあるが、その記述自体はクリエイティブなのか？と自問する。

そんなことをぐるぐると考えた結果、ビジュアルに直接関わってこない部分のコードを持ち込むことを許容するに至った。
あくまで数値を扱うだけで、それをどのように反映させるかについては事前に何も規定しない。
このルールが守られる限りにおいては、完全即興を謳う私のスタイルは崩れないであろう。
ま、あくまで現時点での自分の考え方なので、また変化していくと思うけどね。

OSCコントローラーの使い方

tgl0～tgl3はパターンが単調になりすぎ時に、大きくパラメータを切り替えるのに使ったりしたかな。
一時的にちょっと変えたいだけの場合、コードを書き換えちゃうより使い勝手が良い。
１つの変数をあちこちにかませておけば、トグル１つで大きく変えられるしね。
mom0～mom3は主にフィードバック処理みたいな、ずっとかかりすぎると発散しちゃうような処理に挿しておく使い方が有効かな。
fad0～fad3は値を探るのには便利なのと、１つは常に全体をおとなしくさせるコントロールに使っていた。
４本目まで使い切ることはなかったかな。
btn0〜btn3は結局使わなかったな。
パラメータに絡ませる以外に、発火させたい処理というのがパッと思い付かなかったからというのもある。
何か考え方次第ではうまく使えるはずだが、その場でミス無く書ける程度の複雑さの処理というのがなかなか。
オミットしてその分フェーダーを長く配置する方が使い勝手は良いのかも。
いやいや、tglとmomを増やす方が便利か？

トラブル

謎のfps低下

イベント開始から数時間経過したところでhydraが極端に重くなって、見た目にfpsが一桁近くまで下がることがあった。
Atomエディタの再起動で治ったが、内部的に何かがリークして積もったりしているのか？謎

謎のhydraエラー停止

これまた原因不明だが、hydraがエラーを吐いて停止することが一度だけあった。
いや、原因不明だったかどうかうろ覚えだが、多分書き損じで内部エラーが起きるパターンかも。

shape([3,,4]).out()

Webブラウザ版でもarrayの要素を書き損じると内部エラーが起きて止まる。
こうなるとページ再読み込みしないと復旧できず、Atomエディタであれば再起動が必要になる。
急いでコーディングしてるとたまにやらかす。

途中でOSCが使えなくなる

前述の事情でエディタ再起動後に、OSCが受けられなくて慌てる。
ちょっと余談だがMBP側でProtokolを起動しとくと、TouchOSCからBrowseで接続できるので、いちいちIP調べなくて良くて楽チン。
また、MBPまでOSCが届いていることの確認をするためによく使う。
但し同一ポートを複数のプロセスから受けられないので、Protokolを起動したままだとhydraに値が流れて来ない状態になる。
あたふたしてるうっかり忘れがち。
今回は原因究明している余裕がなかったので、そのまま途中からはOSCコントローラーなしで乗り切った。

マウスカーソルが迷子

激しい明滅とかやってるとカーソルが迷子になりがち。
しかし大体は画面端まで移動させれば見つかるはずなのに何故か見つからず慌てる。
途中で気付いたが、給電のためMBPにiPadをケーブル接続していたのが原因で、iPadがサブディスプレイ扱いになってカーソルがそっちに移動してしまっていた。
サブディスプレイとして使えるのは知っていたが、まさかiOSアプリ起動したままでもそのアプリ内にカーソルを移動できるとは知らなかった。
調べてみるとこの機能はiPad側の設定->一般->AirPlayとHandoffからオフにできる。参考リンク

対策

基本的にいつも単純に画面のミラーリングで映像出力をしているので、一度始まってしまうと裏で何かを調べたりできないし、エディタ再起動中はデスクトップを晒すことになる。
まぁそれもライブ感と言ってしまえばそうだが、あんまりスマートでもない。
エディタが落ちる可能性は常にあるので、やはりリカバリープランを用意すべきなのかなぁ。
どこまでやるか次第だが、ベストは外部のビデオミキサーで別系統の映像出力に切り替えるとかか。
ただ余程大きなイベントでもなければ、わざわざビデオミキサー買うほどまでの対策は過剰な気もする。
次点としてhydraの画面をNDIでResolumeに流し込んで、そこで瞬時に切り替えとかできるように仕込むか。
PCリソースを食うのがちょっとなぁ、という思いもあるがちょっと実験しておくだけの価値はあるか。

とか言いつつ、ライブなんだからトラブったら画面真っ暗になるぐらいでも別にいいんじゃないかという思いはある。

テクニックメモ

今後の自分のために幾つかのエッセンスを書き残しておこう。

色味の細かい明滅

// パラメータは適当
.color(1, [.2,.6].fast(8), .3)

値の振れ幅は形状の大きさに応じて狭くしたり広くしたりして、やかましすぎない程よいバランスを狙う。

不規則な全体明滅

// 係数 1. は明滅の強さ調整で適当にいじる
.mult(noise(4,28).pixelate(1,1).thresh(.1), ()=> tgl0 * 1.)

最近気に入っている不規則な明滅演出としてnoise().pixelate(1,1).thresh()パターンがある。
ただこの部分は場合によってはnoiseではなくoscで定期的な周期の方がマッチすることもあるかな。
明るい絵がずっと出ているよりも、たまに画面オフになる方が眩しく感じる。
眩しさというのは単位時間あたりの光量の積分ではなく、変化量ということなんだろうな。

手動画面オフ

.mult(solid(), ()=> mom0)

地味ではあるが、ちょっと暗転したいことがあるので仕込んでおくと便利。
始めはトグルにしていたがモメンタリの方が使い勝手が良い。
ちょっと変化与えたい時に、手動でリズム打ったりするのにも使える。

画面を少しおとなしくさせる

src(o0)
.blend(src(o1), ()=> fad0)
.out(o1)
render(o1)

ブレイクとか展開的にちょっとおとなしくなるタイミングへの対策として仕込んでみた。
最終アウトプットの手前でフィードバックさせることでおとなしくなる。
音で例えるならdelayのdry/wetみたいな感じなので、0.5付近で劇的に効果が変わる。
あちこちで動きや明るさなど複数の要素がパターンを刻んでいる状況で、サッと全体をコントロールするのに便利。
src(o1)自体にhueやscaleをうっすら絡めたりしておいて、フェーダー操作で演出するという使い方もできる。

眩しさを少し抑える

.mask(osc(800).rotate(Math.PI/2).thresh(.2))

ちょっとカラフルになりすぎてうるさいというか眩しいかな、という時にスキャンラインみたいなマスクを重ねると、鮮やかさを落とさずに少し光量を減らして眩しさを軽減できる。
確かそんな話をいつぞのVJ概論で聴いたような気がする。
こういう解釈であってるかは分からんが、少なくとも意図した効果を得られているのでたまに入れたりする。

所感

後半は高速(BPM200ぐらい？)で駆け抜ける快感に身を委ねながら、ラストまでほぼぶっ続けでコードを書き続けられて非常に楽しかった。
トイレ行ったりとかを除けば8時間ぐらいぶっ続けだったのでは。
テンションの維持も含めて考えると新記録かもｗ
内容に関しても、ここ最近では会心の出来であると言っても良い。
やはり音楽ジャンルに対する自分の好き度はかなり関係してくるな。
ただ同時に、途中から細部の変化に凝ってしまってダイナミックな変化が少ないかなと思わなくもない。
決してそれが悪いわけではないが、自分の表現力をより解放させつつ馴染ませながら変化させる技をもっと磨いていきたいな。