電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-net」を含む投稿［141件］
よかれと思って公開しても何かあったら補償しろと言われるのはイヤなのでGPLライセンスで公開しようと思います。手の内は全部見せるし自由に使ってもらっていいけどサポートも補償もしないよってことです。運よく出来上がってからの話ですが、コードを書き始める前に発生しうる責任問題の対策は考えておきたいのです。
そこで色々考えたのですが、コンテナのDockerを使おうかなと。ご存じ無い方に説明する語彙力は持ち合わせておりませんが、インストーラーではありませんがコマンド一発でインストールが出来る環境構築の母体です。公開するソースコードはもちろんライセンスの宣言なども入れておけるので「知らんがな」にも対応出来そうです。これらをGitHubで公開して履歴を残します。Dockerはとにかく便利です。もしシステムがおかしくなってもDockerのパッケージを入れ直すだけですべてが元に戻るからです。インストール説明書を作る手間も省けます。細かいことを知りたい方はAIさんに聞いてください。
課題があまりに多くなりすぎてどこから手をつけたモノか困っていますが、一つ一つ片づけていきましょう。
#ガチ工作 #[Art-Net] #器具の製作
そこで色々考えたのですが、コンテナのDockerを使おうかなと。ご存じ無い方に説明する語彙力は持ち合わせておりませんが、インストーラーではありませんがコマンド一発でインストールが出来る環境構築の母体です。公開するソースコードはもちろんライセンスの宣言なども入れておけるので「知らんがな」にも対応出来そうです。これらをGitHubで公開して履歴を残します。Dockerはとにかく便利です。もしシステムがおかしくなってもDockerのパッケージを入れ直すだけですべてが元に戻るからです。インストール説明書を作る手間も省けます。細かいことを知りたい方はAIさんに聞いてください。
課題があまりに多くなりすぎてどこから手をつけたモノか困っていますが、一つ一つ片づけていきましょう。
#ガチ工作 #[Art-Net] #器具の製作
Art-Net切替＆パッチマシンは AI/Gemini さんのご協力を得て基本構成が決まりつつあります。
Gemini さんからの情報は鵜吞みにせず自ら検証をするものだと思っていますが、ドキュメントやネット検索から自分でまとめるよりも結論に近い位置から始められていると思います。
基本方針ですが、本機は Art-Net の ArtDMX パケットを受信、加工、送信する装置です。通信スタイルはブロードキャストのみ。ArtDMX 以外のパケットは扱いません (特にRDMは方言が多くて扱いが難しく、ArtDMXだけでも調光操作に支障がないためです)。
ハードウェアの基本構成は次の通り。
１）主装置
RsaspbrryPi-CM4 + CM4-Dual-Eth-Base
２）ネットワーク
1000Base-T × ２ (Art-Net用・スイッチングハブで分岐)
WLAN (製作・メンテナンス用)
３）拡張基板
RaspberryPiのGPIOに搭載する専用基板。
設定保存用 EEPROM (24LC64など,I2C接続)、レガシーDMX受信回路 (LT1785等) + 取り込みマイコン (PIC16(RAM2kB以上),SPI接続)、RS232インターフェース回路 (UARTコンソール用)。
ソフトウェアの基本構成は次の通り。
１）受信モジュール
Art-Net 上の ArtDMX を受信してバッファに保存する。保存する際、検索用のインデックス(クエリ)も作成する。
２）加工モジュール
受信した値を加工する。パッチ、プロファイルカーブ、ディレイ等の処理はここで行う。
３）送信モジュール
加工モジュールから出力された値を送信する。
４）タイムアウト監視モジュール
送信元や受信パケットがタイムアウトしたら(存在しなくなったら)適切に処理する。
５）ユーザーインターフェース(UI)モジュール
画面表示やキーボード操作を司る。
上記(1)-(4)で用いる設定はここで起こす。
これらを /dev/shm 上に作る共有ファイルで結び付けて動作させます。
#ガチ工作 #[Art-Net] #器具の製作
Gemini さんからの情報は鵜吞みにせず自ら検証をするものだと思っていますが、ドキュメントやネット検索から自分でまとめるよりも結論に近い位置から始められていると思います。
基本方針ですが、本機は Art-Net の ArtDMX パケットを受信、加工、送信する装置です。通信スタイルはブロードキャストのみ。ArtDMX 以外のパケットは扱いません (特にRDMは方言が多くて扱いが難しく、ArtDMXだけでも調光操作に支障がないためです)。
ハードウェアの基本構成は次の通り。
１）主装置
RsaspbrryPi-CM4 + CM4-Dual-Eth-Base
２）ネットワーク
1000Base-T × ２ (Art-Net用・スイッチングハブで分岐)
WLAN (製作・メンテナンス用)
３）拡張基板
RaspberryPiのGPIOに搭載する専用基板。
設定保存用 EEPROM (24LC64など,I2C接続)、レガシーDMX受信回路 (LT1785等) + 取り込みマイコン (PIC16(RAM2kB以上),SPI接続)、RS232インターフェース回路 (UARTコンソール用)。
ソフトウェアの基本構成は次の通り。
１）受信モジュール
Art-Net 上の ArtDMX を受信してバッファに保存する。保存する際、検索用のインデックス(クエリ)も作成する。
２）加工モジュール
受信した値を加工する。パッチ、プロファイルカーブ、ディレイ等の処理はここで行う。
３）送信モジュール
加工モジュールから出力された値を送信する。
４）タイムアウト監視モジュール
送信元や受信パケットがタイムアウトしたら(存在しなくなったら)適切に処理する。
５）ユーザーインターフェース(UI)モジュール
画面表示やキーボード操作を司る。
上記(1)-(4)で用いる設定はここで起こす。
これらを /dev/shm 上に作る共有ファイルで結び付けて動作させます。
#ガチ工作 #[Art-Net] #器具の製作
今後、出来上がった物を公開する際はＧＰＬライセンスとします。
ＧＰＬライセンスとはソースコードや回路図を無償で公開するし使用や書き換えは自由だけれどサポートはしませんしバグがあってもトラブっても一切関知しませんってライセンスです。他にも色々ありますので詳細はその筋の情報をご覧ください。ものすごく簡単に言うなら著作権は放棄しないけど自己責任で自由に使ってくださいってのがＧＰＬライセンスです。日本国内の法的にも有効です。
カスタマーサポートはしたくないし、本業の日程によってはサポートは不可能だからです。これまで製品を販売したことはありますが、カスハラ対応は非生産的で無駄。よかれと思って安く提供しても勉強も努力もしない輩に荒らされるのは私に何のメリットもありません。ここしばらく何も販売していなかったのはここにあります。
今作っている Art-Net 切替＆パッチマシンは価値を感じてくれる人が少なからずいると思いますので広く提供する前提で考えていますが、商売として成立する価格にしたら高価になりそうですし、かといって同業者のよしみで安価にしたらサポートで私のメンタルが潰れます。そんならＧＰＬライセンスにしようってことです。話をわかってくれる知人には完成試作品を試してもらいますし、専用基板は「部品」として安価に販売しますけど。RaspberryPiをコマンドラインで使え、gccでコンパイル出来、PICマイコンのIDEが使えて書き込みが出来、専用基板の回路図を読める人には難しくない工作です。
自分が欲しい物を自分のために作るのが前提ですから、購買者は神だと勘違いしたアホのことなど知ったことではありません。こんな悪意と嫌味と皮肉を垂れ流すほどカスハラで嫌な思いをしたのですが、知識と技能を持った人なら組める情報と専用部品を提供するので勘弁してください。
まだ「絵に描いた餅」ですけど(笑
#ガチ工作 #[Art-Net] #器具の製作
ＧＰＬライセンスとはソースコードや回路図を無償で公開するし使用や書き換えは自由だけれどサポートはしませんしバグがあってもトラブっても一切関知しませんってライセンスです。他にも色々ありますので詳細はその筋の情報をご覧ください。ものすごく簡単に言うなら著作権は放棄しないけど自己責任で自由に使ってくださいってのがＧＰＬライセンスです。日本国内の法的にも有効です。
カスタマーサポートはしたくないし、本業の日程によってはサポートは不可能だからです。これまで製品を販売したことはありますが、カスハラ対応は非生産的で無駄。よかれと思って安く提供しても勉強も努力もしない輩に荒らされるのは私に何のメリットもありません。ここしばらく何も販売していなかったのはここにあります。
今作っている Art-Net 切替＆パッチマシンは価値を感じてくれる人が少なからずいると思いますので広く提供する前提で考えていますが、商売として成立する価格にしたら高価になりそうですし、かといって同業者のよしみで安価にしたらサポートで私のメンタルが潰れます。そんならＧＰＬライセンスにしようってことです。話をわかってくれる知人には完成試作品を試してもらいますし、専用基板は「部品」として安価に販売しますけど。RaspberryPiをコマンドラインで使え、gccでコンパイル出来、PICマイコンのIDEが使えて書き込みが出来、専用基板の回路図を読める人には難しくない工作です。
自分が欲しい物を自分のために作るのが前提ですから、購買者は神だと勘違いしたアホのことなど知ったことではありません。こんな悪意と嫌味と皮肉を垂れ流すほどカスハラで嫌な思いをしたのですが、知識と技能を持った人なら組める情報と専用部品を提供するので勘弁してください。
まだ「絵に描いた餅」ですけど(笑
#ガチ工作 #[Art-Net] #器具の製作
DMX の受信処理をするにあたって必要且つ面倒なのがタイムアウト。規格では１秒間更新が無ければ送信がされていないと判断します。
ユニバースが１つのレガシーDMXの装置なら監視するタイムスタンプは一つですからそれほどの負荷ではありませんが、ArtDMX を大量にバッファする機構ではどうするか。
アイデアですが、受信してバッファされている全ての ArtDMX は監視しません。最新値だけ評価すればいいのですからインデックスを覗きます。送信元のインデックスのタイムスタンプでタイムアウトを確認し、登録されている送信元なら無送信のフラグを立てユニバースのインデックスを消去し、登録されていない送信元ならぶら下がるユニバースのインエックスと共に消去します。この後、送信元のチェックで消去されていないユニバースのタイムアウトをチェックします。最後に送信元とユニバースのインデックスをソートします。
タイムアウトは例外処理の一種ですから、どのようなメッセージを出すか、スロットの一覧表示をしていた際にどのような挙動にするか、カレントの送信元としてバスにリレーしていた場合にどうするか、この辺りはあらかじめ決めておいた方がよさそうです。
#[Art-Net]
ユニバースが１つのレガシーDMXの装置なら監視するタイムスタンプは一つですからそれほどの負荷ではありませんが、ArtDMX を大量にバッファする機構ではどうするか。
アイデアですが、受信してバッファされている全ての ArtDMX は監視しません。最新値だけ評価すればいいのですからインデックスを覗きます。送信元のインデックスのタイムスタンプでタイムアウトを確認し、登録されている送信元なら無送信のフラグを立てユニバースのインデックスを消去し、登録されていない送信元ならぶら下がるユニバースのインエックスと共に消去します。この後、送信元のチェックで消去されていないユニバースのタイムアウトをチェックします。最後に送信元とユニバースのインデックスをソートします。
タイムアウトは例外処理の一種ですから、どのようなメッセージを出すか、スロットの一覧表示をしていた際にどのような挙動にするか、カレントの送信元としてバスにリレーしていた場合にどうするか、この辺りはあらかじめ決めておいた方がよさそうです。
#[Art-Net]
現場への移動が長かったので Art-Net 切替＆パッチマシンのアイデアを AI の Gemini さんに投げてみました。
受信は socket で行いますが、受信したデータ(バイナリ)、受信日時、送信元のIPアドレスとMACアドレス、ユニバース番号を mmap を使ったループバッファでとにかく保存します。約２秒分の最大数を構造体配列に保存します。コンソール８台、それぞれユニバース１６(使うのは８ですが、使いたいユニバースを取り溢したくないで多めに監視して１６とします)、２秒分ですから88フレーム、１フレームあたり600バイトくらいとするなら６MBくらいです。PICマイコンなら厳しいですが、RaspberryPi なら楽勝です。ただし、mmap を OS がスワップ領域に移動すると困るので mlock などでメモリに常駐させる設定は必要です。受信順に保存するだけでは後処理で探しにくいのでインテックスも作ります。送信元とそこにぶら下がるユニバースやデータを階層で表し、ループバッファから目的のデータを最短手順で取り出せるようにします。データベース Access のクエリやリレーショナルデータベースの１対ｎ関係などの参照構造を作っておくイメージです。受信データから送信元を、送信元から受信データを参照しやすくするのです。
あとは、受信、送信、エフェクト、表示、操作をプロセスやスレッドで分割するワケですが、これらはそれぞれ勝手に動作するようにします。どこかがどこかへ指示を送って返り値を得る構造ですとタイミングの管理が難しい。設定書を書き換えるだけでコール・アンド・レスポンスは使わないのです。装置はデータを加工しながら一方向に流す機構ですから、それをそのままに素直に形にすればいいのです。ユーザーは流れているデータを覗き見たり流れ方を変更しますが、覗くのは加工の邪魔をしない隙間で読み出すだけですし、設定書は書き換えて適切な場所に置いておけば加工する側が勝手に読むのでいいのです。mmap の読み書きは衝突の可能性がありますが flock をかければ事足りると思われます。
といったことを Gemini さんに投げたのですが「よいんでない？」とのこと。ただ、AI はユーザーを認めて誉める言葉が多い。「だっせーこと言ってんじゃねーよ」的な言葉があってもいいと思う。
#[Art-Net]
受信は socket で行いますが、受信したデータ(バイナリ)、受信日時、送信元のIPアドレスとMACアドレス、ユニバース番号を mmap を使ったループバッファでとにかく保存します。約２秒分の最大数を構造体配列に保存します。コンソール８台、それぞれユニバース１６(使うのは８ですが、使いたいユニバースを取り溢したくないで多めに監視して１６とします)、２秒分ですから88フレーム、１フレームあたり600バイトくらいとするなら６MBくらいです。PICマイコンなら厳しいですが、RaspberryPi なら楽勝です。ただし、mmap を OS がスワップ領域に移動すると困るので mlock などでメモリに常駐させる設定は必要です。受信順に保存するだけでは後処理で探しにくいのでインテックスも作ります。送信元とそこにぶら下がるユニバースやデータを階層で表し、ループバッファから目的のデータを最短手順で取り出せるようにします。データベース Access のクエリやリレーショナルデータベースの１対ｎ関係などの参照構造を作っておくイメージです。受信データから送信元を、送信元から受信データを参照しやすくするのです。
あとは、受信、送信、エフェクト、表示、操作をプロセスやスレッドで分割するワケですが、これらはそれぞれ勝手に動作するようにします。どこかがどこかへ指示を送って返り値を得る構造ですとタイミングの管理が難しい。設定書を書き換えるだけでコール・アンド・レスポンスは使わないのです。装置はデータを加工しながら一方向に流す機構ですから、それをそのままに素直に形にすればいいのです。ユーザーは流れているデータを覗き見たり流れ方を変更しますが、覗くのは加工の邪魔をしない隙間で読み出すだけですし、設定書は書き換えて適切な場所に置いておけば加工する側が勝手に読むのでいいのです。mmap の読み書きは衝突の可能性がありますが flock をかければ事足りると思われます。
といったことを Gemini さんに投げたのですが「よいんでない？」とのこと。ただ、AI はユーザーを認めて誉める言葉が多い。「だっせーこと言ってんじゃねーよ」的な言葉があってもいいと思う。
#[Art-Net]
Art-Net 切替器もパッチも基本的に同じ物として考えています。
基本構成は受信部と送信部があり、間に値を加工するエフェクターを挟みます。
内部は８ユニバースとし、これらをバスと呼称します。
ミキサーというかマージは一番若いバスのみ一般照明向けとしてHTPで考えています。演出操作用ではなく小型サブ卓による作業灯や非常灯用と割り切り、レガシーDMXの入力を１本だけマージするかもしれません(エキストラマージ)。
受信部はIPアドレスやMACアドレスで送信元を選択し、Art-Net ユニバースをバスに渡します。切替器の実体はここです。
エフェクターとはバスの値を加工します。エキストラマージ、パッチ、プロファイルカーブ、ディレイなどはエフェクターとして扱います。ここで何もしなければ単なる切替器です。
送信部はバスの値を Art-Net で送信します。
RDM には対応しません。
複数のコンソールを設置する環境ならば切替器から見てフィクスチャー側に RDM コンソールを繋いだ方が良いと思うからです。
#[Art-Net]
基本構成は受信部と送信部があり、間に値を加工するエフェクターを挟みます。
内部は８ユニバースとし、これらをバスと呼称します。
ミキサーというかマージは一番若いバスのみ一般照明向けとしてHTPで考えています。演出操作用ではなく小型サブ卓による作業灯や非常灯用と割り切り、レガシーDMXの入力を１本だけマージするかもしれません(エキストラマージ)。
受信部はIPアドレスやMACアドレスで送信元を選択し、Art-Net ユニバースをバスに渡します。切替器の実体はここです。
エフェクターとはバスの値を加工します。エキストラマージ、パッチ、プロファイルカーブ、ディレイなどはエフェクターとして扱います。ここで何もしなければ単なる切替器です。
送信部はバスの値を Art-Net で送信します。
RDM には対応しません。
複数のコンソールを設置する環境ならば切替器から見てフィクスチャー側に RDM コンソールを繋いだ方が良いと思うからです。
#[Art-Net]
現場が早く終わって空き時間。とは言っても中途半端な時間なので Art-Net の算数を少々。
切替器やパッチマシンを作るとしてコンソールは何台まで接続可能なのか？です。
今時の EtherNet の通信スペックは 1Gbps が一般的ですが、ケーブルやハブなどに古い物を使ってしまうと 100Mbps になることもあるでしょうし wi-fi を使うと 20Mbpsくらいまで下がる可能性があります。仮に 20Mbps としてコンソールを何台使えるか考えてみます。
ArtDMXのパケットは530バイトです。EtherNetの諸々のデータが貼り付いても600バイトくらい見ておけばいいかな。
EhterNetは１バイト送るのに10ビット必要です。
DMX512の送信レートは最大で44fpsくらいです。
となると、１ユニバース送るのに１秒間に 264kbps くらいの通信速度が最低必要です。DMX512の 250kbps より少し多いですがこんなもんでしょう。
単純に 20Mbps を 264kpbs で割ると 75.757・・・です。Art-Net上に 75 ユニバース存在可能となります。各コンソールから８ユニバース送り出すならコンソールは９台まで不可能ではないとなります。
今のイメージはコンソール８台、合計 64ユニバースですから収まっています。
あとは RaspberryPi の処理能力が足りるかどうかです。
44fps/64ユニバースなら１パケットあたりに許される処理時間は 355usec(0.000355秒) です。以前試作した際は１パケットの処理に150から250usec程度かかっていましたので一応収まります。
先日 AI の Gemini さんとお話をしていたらCPUコアの割り当てや占有の方法がわかったのですが、上記の時間はOSの処理も含めて１つのCPUコアで処理しての値ですから、Art-Netで占有できるCPUコアを設定出来ればもう少し軽くなるかな？
主な処理を書いて１ユニバースあたりの処理時間を計測して最大コンソール数を決めることにしましょう。現実の現場ではバックアップを入れても仕込まれるコンソールは４台くらいでしょうから大丈夫な気はしています。
つか、８台並べてテストする環境を作るのが大変かな？〇ッシュシステムの〇山さんに相談ですね(笑
#[Art-Net]
切替器やパッチマシンを作るとしてコンソールは何台まで接続可能なのか？です。
今時の EtherNet の通信スペックは 1Gbps が一般的ですが、ケーブルやハブなどに古い物を使ってしまうと 100Mbps になることもあるでしょうし wi-fi を使うと 20Mbpsくらいまで下がる可能性があります。仮に 20Mbps としてコンソールを何台使えるか考えてみます。
ArtDMXのパケットは530バイトです。EtherNetの諸々のデータが貼り付いても600バイトくらい見ておけばいいかな。
EhterNetは１バイト送るのに10ビット必要です。
DMX512の送信レートは最大で44fpsくらいです。
となると、１ユニバース送るのに１秒間に 264kbps くらいの通信速度が最低必要です。DMX512の 250kbps より少し多いですがこんなもんでしょう。
単純に 20Mbps を 264kpbs で割ると 75.757・・・です。Art-Net上に 75 ユニバース存在可能となります。各コンソールから８ユニバース送り出すならコンソールは９台まで不可能ではないとなります。
今のイメージはコンソール８台、合計 64ユニバースですから収まっています。
あとは RaspberryPi の処理能力が足りるかどうかです。
44fps/64ユニバースなら１パケットあたりに許される処理時間は 355usec(0.000355秒) です。以前試作した際は１パケットの処理に150から250usec程度かかっていましたので一応収まります。
先日 AI の Gemini さんとお話をしていたらCPUコアの割り当てや占有の方法がわかったのですが、上記の時間はOSの処理も含めて１つのCPUコアで処理しての値ですから、Art-Netで占有できるCPUコアを設定出来ればもう少し軽くなるかな？
主な処理を書いて１ユニバースあたりの処理時間を計測して最大コンソール数を決めることにしましょう。現実の現場ではバックアップを入れても仕込まれるコンソールは４台くらいでしょうから大丈夫な気はしています。
つか、８台並べてテストする環境を作るのが大変かな？〇ッシュシステムの〇山さんに相談ですね(笑
#[Art-Net]
ホール増員でしたが操作盤の置物でしたので Art-Net の装置を作るための情報整理をやってました。情報量が多いので終わってませんが、これまでに実験したこと、AIさんたちに聞いたことなどです。
ソースコードも大切ですが、今日はOSのセッティングについてです。Art-Net を扱うのに不要なこと、つまりはOSから無駄を省きたいのです。
まずは Art-Net は IPv4 を用いますので IPv6 は不要です。
NIC は Art-Net の IN/OUT と作業用の３つを使いますが、Art-Net の IN/OUT 側は Art-Net 以外の通信をしないようにした方が良さそうです。
これらのセッティングをしてからプログラミングを進める方針です。
また、RaspberryPi の CPU にはコアが４つありますが、このウチの２つか３つを Art-Net にのみ割り振ろうと思います。こんなことが出来るんだと驚きましたが、出来るみたいですね。
土台をキチンと作って処理に「待ち」を持たせないようにしたいものです。
#[Art-Net] #器具の製作
ソースコードも大切ですが、今日はOSのセッティングについてです。Art-Net を扱うのに不要なこと、つまりはOSから無駄を省きたいのです。
まずは Art-Net は IPv4 を用いますので IPv6 は不要です。
NIC は Art-Net の IN/OUT と作業用の３つを使いますが、Art-Net の IN/OUT 側は Art-Net 以外の通信をしないようにした方が良さそうです。
これらのセッティングをしてからプログラミングを進める方針です。
また、RaspberryPi の CPU にはコアが４つありますが、このウチの２つか３つを Art-Net にのみ割り振ろうと思います。こんなことが出来るんだと驚きましたが、出来るみたいですね。
土台をキチンと作って処理に「待ち」を持たせないようにしたいものです。
#[Art-Net] #器具の製作
珍しく年末年始休みですが、いざとなると暇すぎ。
ならばとAIのGeminiさんと会話。Art-Net機器の開発に関してです。ぶっちゃけChatGPTより頼もしい回答。色々解決しました。
#[Art-Net] #Ｃ言語
ならばとAIのGeminiさんと会話。Art-Net機器の開発に関してです。ぶっちゃけChatGPTより頼もしい回答。色々解決しました。
#[Art-Net] #Ｃ言語
ホール管理の増員です。
あと一週間ほどすると閑散期に入りますのでネタの整理をしています。
常駐の者と話したのですが、会場設備のArt-Netを使ってもRDMを使う人はこれまで全く居なかったとのこと。不用とは言いませんが、私が作ろうとしているArt-Net機器にRDMを対応させる必要があるかは微妙です。対応するかしないかで処理量が格段に違いますし、自分にとって便利な機器を作ることが開発方針ですから背伸びはいけません。思い返せばRaspberryPi縛りのトライアルとして始めたことですから、RaspberryPiで役不足ならそもそもが違ってきます。
課題はArt-Netの切替機とディレイ機能を持ったバッチマシンです。中規模なフェスを対象とし、DMXを8ユニバースくらい扱えればと思っています。
追記
ChatGPTに聞いたりして考えてみましたが、RDMには対応せずで良いと思います。何よりもRDMに対応したフィクスチャーが手元にありませんから自分にとってはあっても無くても変わりません。
RDMは仕込みが一定のアミューズメント施設などでは効果があると思いますが、仮設においては微妙です。
てなわけで、ブロードキャストのArtDmxだけ扱う切替機、パッチマシンを作りましょう。
#[Art-Net]
あと一週間ほどすると閑散期に入りますのでネタの整理をしています。
常駐の者と話したのですが、会場設備のArt-Netを使ってもRDMを使う人はこれまで全く居なかったとのこと。不用とは言いませんが、私が作ろうとしているArt-Net機器にRDMを対応させる必要があるかは微妙です。対応するかしないかで処理量が格段に違いますし、自分にとって便利な機器を作ることが開発方針ですから背伸びはいけません。思い返せばRaspberryPi縛りのトライアルとして始めたことですから、RaspberryPiで役不足ならそもそもが違ってきます。
課題はArt-Netの切替機とディレイ機能を持ったバッチマシンです。中規模なフェスを対象とし、DMXを8ユニバースくらい扱えればと思っています。
追記
ChatGPTに聞いたりして考えてみましたが、RDMには対応せずで良いと思います。何よりもRDMに対応したフィクスチャーが手元にありませんから自分にとってはあっても無くても変わりません。
RDMは仕込みが一定のアミューズメント施設などでは効果があると思いますが、仮設においては微妙です。
てなわけで、ブロードキャストのArtDmxだけ扱う切替機、パッチマシンを作りましょう。
#[Art-Net]