照明制御のためのシェーダー言語。
関数をひとつ書く。すべてのフィクスチャがそれを実行する。それだけ。
フラグメントシェーダーは「各ピクセルに対して実行される関数」というたった一つの概念で、映像表現を不可逆に変えた。.lxs は同じ概念を照明に適用する ——「各フィクスチャに対して実行される関数」。
現在の照明コンソールのEffect機能は、実質的にパラメータ化されたLFO(sin波の振幅・周波数・位相を設定するだけ)。これは1990年代のGPU固定機能パイプラインと同じ段階。.lxs はプログラマブルシェーダーの導入に相当する。
// spiral-galaxy.lxs — これだけで32台のムービングライトが螺旋を描く @meta { name: "Spiral Galaxy"; fixtures: 32; } @params { speed: float = 1.0 [0.1, 3.0]; radius: float = 3.0 [0.5, 8.0]; } @fixture main(i, t) { pan = sin(t * speed * 2 + i * 0.196) * radius; tilt = cos(t * speed * 1.5 + i * 0.392) * radius * 0.67; dim = sin(t * 0.8) * cos(i * PI) * 0.3 + 0.7; red = sin(t + i * 0.1) * 0.5 + 0.5; green = sin(t * 0.7 + i * 0.2 + TAU/3) * 0.5 + 0.5; blue = sin(t * 1.3 + i * 0.3 + TAU*2/3) * 0.5 + 0.5; }
照明の世界で「エフェクト」と呼ばれてきたものは、実はsin波のパラメータ調整に過ぎなかった。振幅、周波数、位相 —— この3つの数値を変えるだけ。.lxs は「数式そのものを書く」ことを可能にし、表現空間を次元ごと拡張する。
sin, cos, noise, fract, clamp —— たった5つの基本関数の組み合わせから、これまでコンソールでは不可能だったパターンが次々と生まれる。
位相差のあるsin波。照明の最も基本的な動き。これだけでも十分美しい。
2つのsin/cosの掛け合わせ。XとYの周波数比で無限のカーブを描く。
ノイズ関数で予測不能だが滑らかな動き。自然界のゆらぎを再現。
異なる周波数の波を重ねてモアレ。複雑さが単純さから自己組織化する。
ハッシュ関数でフィクスチャごとの固有値。ランダムだが再現可能。
外部入力変数を数式に組み込むだけ。音とリアルタイムに対話する照明。
核心: 映像の世界では、テクスチャ→動画→シェーダーの進化が不可逆だった。同じ革命が照明で起きる。プリセット→キューシーケンス→.lxs。この進化は「より便利になる」のではなく、「表現の次元が変わる」。ShaderToyが映像表現を民主化したように、.lxs は照明表現を民主化する。
各ピクセルの座標 uv と時間 iTime を受け取り、RGBA を返す。GPUが全ピクセルを並列処理。ShaderToy で世界中の作者がシェーダーを共有。
各フィクスチャのインデックス i と時間 t を受け取り、Pan/Tilt/Dim/RGB を返す。コンソールが全フィクスチャを逐次処理。共有プラットフォームは未開拓。
| 概念 | Fragment Shader | .lxs |
|---|---|---|
| 処理単位 | pixel | fixture |
| 空間座標 | uv (0–1, 2D) | i (0–1, 1D) + n (int) |
| 時間 | iTime | t |
| 出力 | vec4 (RGBA) | pan, tilt, dim, r, g, b, ... |
| パラメータ | uniforms | @params |
| ファイル | .glsl / .frag | .lxs |
| 共有文化 | ShaderToy | 未開拓(=巨大な機会) |
.lxs ファイルは4つのブロックで構成される。@meta と @fixture が必須、他は任意。GLSLを書いたことがある人なら5分で書き始められる。
パターン名、作者、フィクスチャ数、FPS、タグ。ファイルの自己記述情報。
UIフェーダーやOSCで制御可能な変数。型、デフォルト値、範囲を宣言。
各フィクスチャで毎フレーム実行される関数。i(正規化インデックス)とt(時間)を受け取り、pan/tilt/dim/rgbを返す。
補助フィクスチャ制御、外部入力バインディング(OSC/MIDI/Audio)、物理配置、レイヤー合成。
// 三角関数 sin(x) cos(x) tan(x) asin(x) acos(x) atan2(y, x) // 算術 abs(x) sqrt(x) pow(x, y) exp(x) log(x) sign(x) // 補間 lerp(a, b, t) smoothstep(x) mix(a, b, t) step(edge, x) // 範囲 min(a, b) max(a, b) clamp(x, lo, hi) saturate(x) // ノイズ noise(x) noise2(x, y) fbm(x, octaves) // 丸め floor(x) ceil(x) round(x) fmod(x, y) fract(x)
ムービングライト(スポットライト)は本質的に「時間の関数で動く数学的オブジェクト」だ。Pan/Tilt は極座標の角度、Dimmer は振幅、Color は3次元ベクトル —— すべてが数値。.lxs の「数式ひとつで全チャンネルを制御する」アプローチは、この性質に完全に一致する。
ムービングヘッドの首振りは、sin/cos の出力そのもの。リサージュ曲線、螺旋、花弁パターン —— すべて三角関数の組み合わせで記述できる。
フェードイン、パルス、呼吸エフェクト、ストロボ。すべてが0–1の連続関数。clamp, smoothstep, fract で任意の波形を設計できる。
RGB は3次元空間の点。HSV→RGB 変換は6行の数式。色相の巡回、補色対比、温度グラデーション —— すべて幾何演算。
ムービングライトのすべての出力チャンネルは連続的な数値だ。これは偶然ではなく、照明器具の物理的性質から来ている。だからこそ、数式ベースの制御が自然にフィットする。
本質的な適合: ムービングライトは「数学的に動く物体」であり、.lxs はその数学を直接書くためのフォーマットだ。中間抽象化(Effect Generator, Phaser)を経由する必要がない。意図がそのまま数式になり、数式がそのままフィクスチャ値になる。これは「便利なツール」ではなく「本質的な一致」。
// 呼吸する螺旋 — Pan/Tilt/Dim/Color が有機的に連動 @fixture main(i, t) { breath = sin(t * 0.4) * 0.5 + 0.5; // 呼吸リズム pan = sin(t + i * TAU) * (2 + breath * 4); // 呼吸で螺旋が広がる tilt = cos(t * 0.7 + i * TAU) * (1.5 + breath * 3); dim = breath * 0.6 + 0.3; // 広がると明るく zoom = 1.0 - breath * 0.5; // 広がるとビーム絞る hue = fract(t * 0.08 + i * 0.15); // ゆっくり色相回転 red = saturate(abs(hue * 6 - 3) - 1); green = saturate(2 - abs(hue * 6 - 2)); blue = saturate(2 - abs(hue * 6 - 4)); }
32台のフィクスチャが .lxs の数式をリアルタイムに評価している。プリセットを切り替え、パラメータを調整して効果を確認。
10個のサンプル .lxs ファイルがリポジトリに含まれている。基本パターンから音声反応・レイヤー合成まで。
最小のシェーダー。sin波ひとつでディマーを上下。
リサージュ螺旋 + 120°位相差カラー。すべての基本。
インデックスからグリッド座標を導出。呼吸するように膨縮。
3つのsin波を重ねてモアレ干渉パターンを生成。
花火のような放射状バースト。極座標 + 重力減衰。
ノイズによる有機的ドリフト + HSV→RGB全スペクトル巡回。
FBMノイズで群れのような有機的運動。
@input でオーディオバインド。低音でフラッシュ、高音で色変化。
位置 + カラー + ストロボを独立レイヤーで合成。
奇数/偶数フィクスチャで二重螺旋。ストランド別カラー。
.lxs テキストはAST JSONにコンパイルされ、任意のランタイムで実行される。GLSLがSPIR-Vにコンパイルされるのと同じ二段構造。
| プラットフォーム | ランタイム | 状態 |
|---|---|---|
| grandMA3 | Lua Plugin (AST eval) | ✅ Working |
| Node.js | JavaScript evaluator | ✅ Working |
| Browser | WebGL preview + JS eval | ✅ Working |
| TouchDesigner | Python evaluator | 🔧 Planned |
| ETC Eos | External → sACN | 🔧 Planned |
| WASM | Universal high-perf | 📋 Future |
ポータビリティの原則: .lxs ファイルは純粋な数学のみで構成され、コンソール固有のAPIを一切含まない。Cmd() や SetFixtureValues() はランタイム層の責任。GLSLとGPUドライバの関係と同じ。
.lxs は純粋な数学式。コンソール固有のコマンド、DMXアドレス、プロトコル詳細は含まない。純粋関数のみ。
同じ .lxs がどんなコンソール、ソフトウェア、ハードウェアでも動く。ランタイムが適応し、ファイルは変わらない。
GLSL(2004年、人間用に設計)と違い、.lxs はAI時代に生まれた。LLMが生成できるほど短く、検証できるほど構造化され、人間が微調整できるほど可読。
照明の知識はプロプライエタリなショーファイルに閉じ込められてきた。.lxs はパターンを共有可能、フォーク可能、合成可能にする。
.lxs は SPOTLIGHT AI プロジェクトから生まれた —— 自然言語で照明の意図を伝え、AIが数式に変換し、grandMA3でリアルタイム実行するシステム。AST JSON フォーマットと Lua ランタイムは、テキスト構文を設計する前にライブパフォーマンスで検証された。
仕様策定、リファレンス実装、サンプルパターン、MA3互換ブリッジを含むリポジトリは GitHub で MIT ライセンスのもと公開されている。
実際のライブやインスタレーションでは、ステージ上に異なる種類のフィクスチャが混在する —— フロントウォッシュ、バックムービング、フロアライト、ピンスポット。すべてに同じパターンを適用するのは非現実的だ。グループごとに異なる .lxs パターンをアサインし、独立した速度・スケールで制御する必要がある。
speed: 0.5speed: 1.2, radius: 5speed: 0.8sensitivity: 2.0speed: 0.6各グループは独立した .lxs パターンを持ち、個別のパラメータ値で動作する。グループ間の i(正規化インデックス)はそれぞれ 0–1 にリマップされるため、パターンはグループサイズに自動適応する。8台でも16台でも、同じ数式が同じ空間分布を描く。
SPOTLIGHT AI(SPATAI)のコンパニオンアプリに、グループごとの .lxs パターンアサインメントと、パラメータのリアルタイム制御UIが必要になる。
マルチグループ対応では、SPATAI アプリがルーターとして機能する。各グループに対して独立した AST JSON を保持し、独立した環境変数(i のリマップ、個別パラメータ値)で評価する。MA3 側では既にグループ概念が存在するため、グループ → フィクスチャのマッピングはコンソールのデータを参照する。
自然言語との組み合わせ: 「バックの16台は螺旋で速めに、フロントの8台はオーロラでゆっくり、ピンスポットは音に反応」—— この一文をAIが解析し、3つのグループそれぞれに適切な .lxs パターンを自動生成・アサインできる。グループ × パターン × パラメータのルーティングが言語化されることで、照明オペレーションの意図がそのまま実行可能な構造になる。
grandMA3 は世界最高の照明コンソールであり、Lua プラグイン環境を提供する数少ないプラットフォームだ。だからこそ、SPOTLIGHT AI と .lxs フォーマットを最初に実現できた。しかし現在の実装はプラグインによるワークアラウンドであり、コンソールネイティブの統合には至っていない。以下は、MA Lighting に向けた具体的な拡張提案である。
現在、Lua から フィクスチャ値を直接設定する公式 API がない。Cmd("Attribute ...") 経由のコマンド発行は低速で、25Hz の数式評価ループには不十分。DMX512 レベルの SetFixtureValue(fixture_id, attribute, value) を Lua API として公開するだけで、プラグインのパフォーマンスが劇的に向上する。これは .lxs に限らず、あらゆる Lua プラグイン開発者に恩恵をもたらす。
現在の Phaser は波形選択 + パラメータ調整の固定機能モデル。ここに「Equation」タブを追加し、.lxs の @fixture ブロックと等価な数式を直接入力できるようにする。sin(t + i * 0.3) * 3 と書くだけで、全フィクスチャのPanが螺旋を描く。既存の Phaser ワークフローと共存し、ユーザーが段階的に移行できる。技術的には AST JSON 評価エンジンをネイティブ C++ で実装するだけで、Lua プラグインで既に動作実証済み。
Show File に .lxs パターンを直接インポートする機能。Effect Pool に .lxs パターンをドラッグ&ドロップするだけで利用可能に。逆にコンソールで作成した Phaser Effect を .lxs 形式でエクスポートし、他のコンソールやソフトウェアと共有できる。照明業界初のオープンな Effect 交換フォーマットとなる。
コマンドラインまたは専用UIに「32台で螺旋、暖色系、BPMに同期」と入力すると、AI が .lxs を生成し、即座に Phaser に適用される。SPOTLIGHT AI で実証済みのワークフローをコンソールにネイティブ統合する。照明デザイナーは数式を書く必要すらなく、意図を言葉で伝えるだけでよい。LLM の API コストは 1 クエリ 数円程度であり、ソフトウェアアップデートとして十分に実用的。
MA Lighting が .lxs パターンの共有プラットフォームを運営する。ShaderToy や Unreal Marketplace のように、世界中の照明デザイナーがパターンを投稿・フォーク・改良できる。コンソールから直接ブラウズしてワンクリックでロード。プロ用有料パターンの販売も可能。これは grandMA3 のプラットフォーム化であり、ハードウェア販売を超えた持続的なエコシステムの構築を意味する。
ETC Eos, ChamSys, Avolites のいずれもプログラマブルな数式エフェクトを持たない。grandMA3 が最初に実装すれば、技術リーダーシップを確立できる。
閉じたショーファイル形式ではなく、.lxs という共通語をサポートすることで「grandMA3 で作ったパターンがどこでも動く」という信頼を獲得。結果として grandMA3 がハブになる。
クリエイティブコーダー、メディアアーティスト、VJ はコンソールの操作体系に馴染みがない。しかし数式なら書ける。.lxs は照明の世界への新しい入口になり、grandMA3 のユーザーベースを拡大する。
AIは .showfile を生成できないが、.lxs なら生成できる。コンソールが .lxs をネイティブサポートすれば、AI → コンソールの直接パイプラインが開通する。これは数年以内に照明業界の標準ワークフローになる可能性が高い。
まとめ: Level 1(Lua API拡張)だけでも、プラグイン開発者コミュニティ全体に大きな価値を提供する。Level 2–3 で grandMA3 は照明業界初のプログラマブルコンソールとなり、Level 4–5 で AI 時代のプラットフォームとして確固たる地位を築く。.lxs フォーマットは MIT ライセンスで公開されており、MA Lighting は自由に採用・拡張できる。