電装工芸日記
- 舞台照明機器の製作とか -
No.1189
現場への移動が長かったので 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]