2024/8/24 musikē@KNOCK KOENJI A/Vライブ＆VJ振り返り

2024年8月28日 11:06

来週8/24(土) 16:00〜高円寺KNOCKにてライブとVJやります！
今回のライブは、drone ambientの即興演奏とそれに合わせたvisualを独りでやります。
遊びに来てね〜。 pic.twitter.com/nXJexDWNa7
— hacha (@hacha) August 17, 2024

てなわけで、今回はAudioVisualライブと、いつも通りのLiveCodingでのVJをやった。

ライブの準備

今回は独りでAudioVisualライブをやると決めていた。
15分の尺なのでまぁ何とかなるだろうぐらいの算段で、とりあえず音についてはDroneAmbientの即興演奏みたいなものをやりたいな、とiPad版KORG Gadgetでざっくりと音色構成を作り上げた。
ノートは打たずにInstaChordのPressモードで演奏して、それをBluetoothMIDIを受けて鳴らす構え。
ここまではわりとすんなりだったので、まぁAbletonLive向けにプロジェクトexportしてそこ起点でMIDIなのかAudioReactiveなのかで映像を作るような感じにしようかな、と考えていたんだ。当初は。

それならあまりちゃんと触ったことのないJitterとかVizzieとかでビジュアルやってみようかな、と一通り勉強してみた。
ただどうにもなぁ、映像素材とかwebカメラ入力ベースで何か加工したりするのは良いような気もするけど、ゼロベースでジェネをやるにはそんなに取り回しが良いわけでもなさげ。
BEAPとかも使ってビデオシンセ的な画作りをするのもナシではないんだけど、だったらhydraの方が圧倒的に手っ取り早くて込み入ったものを作れるんだよな。
一応こんな感じのことぐらいはできる程度には理解した。

Vizzie勉強中 pic.twitter.com/Zptjus2y24
— hacha (@hacha) August 17, 2024

本当にVizzieで作り込むかどうかはやや保留としつつ、AbletonLiveを中心に添えるつもりではあるので、ひとまずKORG GadgetからAbletonLive用のプロジェクトをexportした。
この機能がどれぐらい知られているのか分からないが、iOS版KORG Gadgetは単純に音声データの書き出しができるだけでなく、AbletonLiveのプロジェクトをexportすることができるのだ。
音色まで再現するには別途KORG Gadget Plug-ins for Mac/PCが必要になるし、Memphisのようなアプリ連携しているようなガジェットの音色は再現できない。
とは言え、かなりの数のガジェットがパラメータ設定なども込みでexportできるので素晴らしい機能だと思う。

誤算

ところが、である。
いざAbletonLiveのプロジェクトでInstaChordからのMIDI入力を受けて鳴らしてみると、どういうわけかHelsinkiやChiangmaiのReleaseが効いてなくてブツッと切れる。
しかしWarszawaやLisbonは効いているので、ガジェット別の不具合のような気がする。
※注釈：KORG Gadgetの各種シンセには世界中の都市の名前が付けられているのだ。
う〜ん、iPad版では問題なかったのになぁ。
こうなるとAbletonLiveのプロジェクトを中心に、という前提も崩れてくる。
Audio I/FでiPadから引き込んで、というのも考えはしたがそこまでしてVizzieを使いたいわけでもない。

ビジュどうするか問題

よし、じゃぁ音についてはiPadから直接アウトプットすることにして、ビジュをどうするか。
既にVizzie調査に時間を使ったりしていて、スケジュールに余裕はない。
こうなると使い慣れたhydraになるが、今回はInstaChordの鍵盤を押さえるのに片手が塞がっている。
そのためLiveCodingというわけにはいかない。
まぁマシンライブにしても、音の操作は忙しいのでちょっと同時にコーディングってのは難しい。ってのを昨年5月に味わっている。

完全に仕込んでおいてLaunchControl XLあたりで操作するか。
う〜ん、しかしそれだとあまりにも面白みがないというか、チャレンジングな要素が少ない。
これはあくまで個人的な心構えだが、基本的にライブは常にexperimentalな実戦の場であり大小何かしらのチャレンジがそこには必要なのだ。
もちろん物凄く大きな舞台で相応のギャラでブッキングされて、という場合は安定させる方向に舵を切るつもりではあるが、幸か不幸か今のところそういう大舞台でライブをやる機会は訪れていない。
だから自分としては、多少なりとも「今回はこういうことを試みた」と言えるようなことをやらないなら無理にライブ出演する必要性はないとすら思っている。

で、どうしたものかなとぼんやり考えていたら視界に飛び込んできたのがコイツだ。

ちょうど6月に別の目的のために買ったコイツを実戦投入してみる良い機会だな、と。
ざっくりハードを説明すると、２つのノブがCC、ボタンはNoteで飛ぶ他に、ジャイロがX/YそれぞれCCで飛ぶ。
有線はもちろんBluetoothMIDI対応というところが個人的に購入の決め手だったな。
ただ実際に繋いでみると、どうもジャイロのうまい使い途が思い当たらなかったので自分は使わないかな、と設定を切っている。
ノブもちょっと曲者で、どちらの方向にも無限に回るタイプのやつだ。
困るのは時計回りに回していくと0から上がっていって127の次はいきなり0になる。
反時計回りも0まで下がって次はいきなり127になる。
これなら無限じゃなくて止まってくれた方が使いやすいんじゃないのか？とは思うのだが、そのままMIDIマッピングするんじゃなくてプログラムで吸収するつもりならどうとでも料理のしようはある。

てなわけで、ライブ前日の深夜までプログラミングすることになった。
これについてはいずれちゃんとした解説をAudioVisual勉強会なりQiitaなりで発表しようと思う。
まぁでもわりと泥臭い実装をして、直前の値を取っといて比較すれば行けるよね、みたいなことをしている。
むしろMIDIをそのまま使わずにプログラム側が間に入ったことで、分解能を自分が好きなように設定できるためただのMIDIコン以上のポテンシャルを引き出せて大いに満足している。
ボタンに関してもNoteとしては使うつもりはなく、任意のボタンを押すと対象が切り替わってそれぞれごとにノブの値を保持する、みたいな実装にしてみたがこれは言葉だと分かりづらいので、いずれ解説する。

かくしてライブ当日の数時間前にシステムが完成したのであった。
一応ライブに使ったhydraのコードは置いておこう。
まるでコメントがないが、まぁ大した処理じゃないから分かる奴が読めば分かるだろうぐらいのものだが。

// register WebMIDI
navigator.requestMIDIAccess()
    .then(onMIDISuccess, onMIDIFailure);

function onMIDISuccess(midiAccess) {
    console.log(midiAccess);
    var inputs = midiAccess.inputs;
    var outputs = midiAccess.outputs;
    for (var input of midiAccess.inputs.values()){
        input.onmidimessage = getMIDIMessage;
    }
}

function onMIDIFailure() {
    console.log('Could not access your MIDI devices.');
}

var prev = Array.from({length: 128}, ()=> Array(3).fill(0));
var vals = Array.from({length: 128}, ()=> Array(3).fill(0));
var index = 0;
const knobReso = .01;

 // master knob
var mk = 0;
// knob 1-9
var k1=0,k2=0,k3=0,k4=0,k5=0,k6=0,k7=0,k8=0,k9=0;
// toggle switch 1-9
var t1=0,t2=0,t3=0,t4=0,t5=0,t6=0,t7=0,t8=0,t9=0;

getMIDIMessage = function(midiMessage) {
  var arr = midiMessage.data
  var num = arr[1];
  var val = arr[2];

  if (num == 1) {
    vals[0][num] += (val > prev[0][num] ? 1 : -1) * knobReso;
    vals[0][num]　= Math.max(0, Math.min(1, vals[0][num]));
    console.log(`$vals[${0}][${num}]: ${vals[0][num]}`);
    prev[0][num] = val;
    mk = vals[0][num];
  } else if(num == 2) {
    vals[index][num] += (val > prev[index][num] ? 1 : -1) * knobReso;
    vals[index][num]　= Math.max(0, Math.min(1, vals[index][num]));
    console.log(`$vals[${index}][${num}]: ${vals[index][num]}`);
    prev[index][num] = val;

    var v = vals[index][num];
    switch (index) {
      case 60 : k1 = v; break;
      case 61 : k2 = v; break;
      case 62 : k3 = v; break;
      case 66 : k4 = v; break;
      case 67 : k5 = v; break;
      case 68 : k6 = v; break;
      case 72 : k7 = v; break;
      case 73 : k8 = v; break;
      case 74 : k9 = v; break;
    }
  } else {
    index = num;
    console.log(`change index to ${index}`);
    if (val > 0) {
      switch (index) {
        case 63: t1 = Math.abs(t1 - 1); break;
        case 64: t2 = Math.abs(t2 - 1); break;
        case 65: t3 = Math.abs(t3 - 1); break;
        case 69: t4 = Math.abs(t4 - 1); break;
        case 70: t5 = Math.abs(t5 - 1); break;
        case 71: t6 = Math.abs(t6 - 1); break;
        case 75: t7 = Math.abs(t7 - 1); break;
        case 76: t8 = Math.abs(t8 - 1); break;
        case 77: t9 = Math.abs(t9 - 1); break;
      }
    }
  }
}

//a.show()
//a.hide()
a.setBins(8)
a.setScale(10)
a.setCutoff(1.)
a.setSmooth(.6)

const kp = 9999;

osc(13,()=>-.01 - k9 * .002, ()=>a.fft[1] * k2 * 6)
.posterize(()=>256 - k3 * 250)
.rotate(()=>k1)
.modulateScale(osc(18, ()=>k9 * 4).modulate(noise(6),0).kaleid(kp), ()=>.02 + k6 * (.03 + a.fft[3]))
.kaleid(kp)
.diff(osc(20,()=>.03 - k8 * .005, ()=> k9 * .2).kaleid(kp).mult(solid(), ()=> 1 - k7))
.modulateScale(osc(()=>38 - k7 * .1, -.05).modulate(noise(2, ()=> .1 + k5),0).kaleid(kp), ()=>.1 + k4 * .2)
.modulateScale(osc(6, ()=> .15 + k8 * .01).kaleid(kp), ()=> .05 + k5 * .3)
.blend(solid(), ()=>mk)
.out()

本番

システムに時間がかかったのと、VJパフォーマンスとは差別化したいのでシンプルに落とし込んだ。
音楽側がDroneAmbientで、基本的には周期の異なる持続音を重ねて構成する感じなので、それなら周期の異なるオシレータ同士をモジュレーションさせて画作りをしてみようかな、というコンセプトでこうなった。
osc(13,.1).kaleid(9999).modulateScale(osc(20,-.03).kaleid(9999)).out()、みたいな。
もっと凝れるんじゃないかとは思うが、個人的には満足している。

今回のミス

今回は２つのミスがあった。

まず１つめはAudioReactiveチェック漏れだ。
前述のhydraのコードを見ていただくと分かるように、今回はふんだんにAudioReactiveを色んなパラメータに散りばめている。
ただ音をMacBookProのマイクで直接拾っているので、環境によってどの程度の入り具合なのかが変わってくる。
なので本番前のリハでチェックして係数を調整したりするつもりだったが、バタバタしていて忘れたまま本番に挑んでしまった。
まぁそこまで致命的に低すぎたり高すぎたりはしなかったが、これは単純なケアレスミスなので何とも言い訳がし難い。

これを抑止するためには、環境に依存しないようAudio I/Fで引き込んでどうこうするようにした方がいいんだろうな。
なんかやればできるというのは分かるけど、パパッとできるほどどう設定すればいいのかは分かっていない。
次にAudioReactive使う時にはこの課題はクリアしておこう。
それはそれとして本番前チェックリストを毎回用意して確認しよう。

そして２つめは、機材の電池切れ。
前述の通り音はiPadのKORG Gadgetから出している。
Gadget側はこんな感じのトラック構成。

BluetoothMIDIでnanoKontrolStudioを繋いでいて、各トラックのボリュームを上げ下げしながら展開を作っていくのを試みた。
ガジェット個別のパラメータやインサートエフェクトをちょっと触ったりしたいが、ボリュームだけは画面を全体に戻さなくても操作できるように物理のMIDIコンを使うのが良いと考えている。
しかしライブ終盤でnanoKontrolStudioが電池切れになったようで、フェーダーを下げてるはずなのにトラックボリュームが下がっていないことに気付く。
考えてみればそんなに毎日のように使う機材でもないので、前に電池を入れ替えたのが何年前だったかすら覚えてないぐらい古い。
まぁすぐ気付いたから、そこからはiPadを直接操作して何とかなったが、これも事前に潰せるようなミスだったかな。

でもどう対応するのかはなかなか悩ましくて、他にあまり使わないような単4電池2本をライブのたびに新品に入れ替えるというのもコスパが悪い。
充電式の単4電池を持っていたような気もするが、目に付くところには見当たらず、どれかしらのガジェットに使っているのかもしれん。
う〜ん、そういうリスクあるよねという認識は持った上で、ライブ後に入れ替えたばかりだからしばらくは大丈夫かな〜、ぐらいの運用でいっか。
ここぞというような大舞台ではケチらず新品に差し替えよう。
本体側にバッテリーを持ってるような後継機が出ると嬉しいんだけどなぁ。

VJ

いつも通りhydraでのLiveCoding。
今回はAudioVisualライブの準備に手一杯で、あまりテーマやコンセプトを事前に考えてなかった。
前述のNM2のマッピングを仕込みながらこれをそのままVJにも転用したらいいかなと考えたのだが、どうにも厄介な問題に直面したので時間の問題から使用を断念。
完全に仕込んでコードを走らせる分には問題ないのだが、全体コード反映する度に保持している値も初期化されてしまう上に、どうもログを見ているとMIDI受けの登録が多重化して溜まっていくような挙動になる。
う〜ん、それならOSC受けるコードの時にも同じようなことが起きそうな気がするが、そこは何も気にせず問題なかったな。
OSCの場合は初期化時に送出側が持ってる値を全部出す、みたいな挙動なのか？
ここは要検証だな。
まぁMIDIで受けて自分の都合良いように加工してOSCにしてhydraに流し込む、みたいなプログラムを作るか。そのうちに手が空いたら。

以下、所感

とりあえずなるべく手癖から離れるような感じでやり始める。

この辺りでちょっと方向性が固まってくる。

うんうん、いいねぇ。

やっぱこういう瞬間的に見える模様ってのが好きなんだなぁ。

以前の自分は画面全体を光らせすぎていたな、と思う。
それは単純に眩しいんだけど、そうじゃなくてパッと消しちゃうことで直前の模様が強く網膜に焼き付くような、そういう強調の仕方ってあるなと気付いた。

あー、こういうのかなり僕好みだな。
前回はkaleid()禁止縛りを己に課したけど、やっぱり.kaleid(6)はやめらんねぇぜ！
これはもはや性癖なんだと思う。

RGBの一部を激しく動かして作り出すこの色！
これもね、好きなのよ。

面積としては黒背景が多くなるようにして、そこへ派手な色をブチ込む方が映えるよな。
それでいて周期的にちょっと眩しく色が覆ってくる感じがさ、イイよね。

とは言え、ずっとそんな調子だと多少のマンネリを感じるので、そしたら全体をグチャッとかき混ぜてみたりなんかね。
こういうの序盤ではやらないけど、終盤にいつもやってる気がする。
逆に言えば自分の手癖になってしまってるんだな、良くも悪くも。

今回は値のサイクルを多少揃えるような感覚でやった。
それもあってか、ずっと激しくコーディングするというよりはhide codeしてじっくりと眺めて方向性を考える時間がいつもより多かったかな。
一応最終状態のコードを公開しておく。
でも自分が一番気に入っているのは最終状態じゃなくてそこに至る過程の中にあるし、その時にDJが流している音も込みでのものなんだよな。

終わりに

今回もとても楽しいパーティだった。
そして毎回やればやったなりの収穫があって、それが何よりも嬉しい。
さーて、次はどんなことをやってやりましょうかね〜。

この記事が気に入ったらサポートをしてみませんか？