電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-Net」を含む投稿［125件］（4ページ目）
資料映像のレンダリング中に Art-Net の IPアドレスを設定する Bashスクリプトを書いてみました。
実機は自宅ですが ssh で遠隔操作が出来ます。
dhcpcd.conf の書き換えを NetworkManager のコマンドに置き換えるだけですので難しくはありません。
とりあえず本体プログラムを書くための準備は終わりました。
#[Art-Net]
実機は自宅ですが ssh で遠隔操作が出来ます。
dhcpcd.conf の書き換えを NetworkManager のコマンドに置き換えるだけですので難しくはありません。
とりあえず本体プログラムを書くための準備は終わりました。
#[Art-Net]
RaspberryPiの開発セットが完成しました。
開発に使用する用品をマジックテープ付きの合板に貼り付けてスロットインします。
常に仮組みしておく意図です。作業の都度組まなくても済みますし作業場所も選びません。
現在の案件はArtNetPatchですからHubが２個です。一番奥のスロットにRaspberryPiが入っています。
仕上げは大雑把ですが便利です。
#RaspberryPi #[Art-Net]
開発に使用する用品をマジックテープ付きの合板に貼り付けてスロットインします。
常に仮組みしておく意図です。作業の都度組まなくても済みますし作業場所も選びません。
現在の案件はArtNetPatchですからHubが２個です。一番奥のスロットにRaspberryPiが入っています。
仕上げは大雑把ですが便利です。
#RaspberryPi #[Art-Net]
トランクにモニタとSFX電源を入れた物がまとまりました。RaspberryPi トランクとでも呼ぶことにします。
RaspberryPi と EtherNetHub を実装して ArtNetPatch の開発環境とします。
#電子工作 #[Art-Net]
RaspberryPi と EtherNetHub を実装して ArtNetPatch の開発環境とします。
#電子工作 #[Art-Net]
ホール管理の増員で置きダヌキ。
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#Ｃ言語 #[Art-Net]
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#Ｃ言語 #[Art-Net]
先週末は現場が被りまくりでオロオロしてましたが、今週は比較的ヒマなので少しはネタを進められそうです。
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#Ｃ言語 #[Art-Net]
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#Ｃ言語 #[Art-Net]
今週末はホール管理の増員です。これといってやる事のない置きダヌキです。
Art-Netパッチの処理構造を妄想。
C言語でドライバ部、Pythonでユーザーインターフェース部を作る棲み分けですが、今はドライバ部の構成を整理しています。
これまでの試行錯誤から処理フローを図式化。基本の流れは見えたと思います。
ただ、C言語の構造体を用いた配列処理をもっと突っ込んで覚える必要があります。Art-Netのデータは、レベル値だけでなくメタデータとも言えるインデックスが重要で、カード型データ構造と言ってもいいでしょう。これの追加、削除、抽出、修正を延々と繰り返すので構造体配列を自在に扱えることは必須技能です。
C言語での配列は少し不器用で、私の理解が間違っていなければ、配列をデータベースに見立てたとしてレコードの追加や削除は出来ません。出来ると言えば出来るのですが、特定のレコードを除いた配列全体を新たな配列としてコピーするような操作が必要です。追加も似た様な操作になります。
少しややこしいのですが、次のサイトでは面白い事を書いてます。
C言語 構造体を使ってリスト構造を作るプログラム
C言語の配列に頼らずリスト構造を構成してます。言うなれば手作業で配列操作をするのです。
また、変数名を使わずメモリ領域を確保してポインタで管理しています。一見不合理な使い方に見えますが合理的かも。アセンブラっぽいので私には違和感はありません。
オレメモ
C言語：構造体のメンバのアドレス
C言語 ポインタ同士の引き算
配列が格納されるアドレスとピッチがわかればポインタで配列にアクセス出来ます。処理の内容によってはこの方が速いかも。
この他にも、以前はどうも理解しきれなかったC言語のマルチプロセスや共有メモリ(mmap)のことが理解できた。
Linuxプロセスの生成と実行 fork／exec
C言語でmmap()を用いてプロセス間で変数を共有する
以前の試作でイマイチだったところが解決しそうな期待感。
#[Art-Net]
Art-Netパッチの処理構造を妄想。
C言語でドライバ部、Pythonでユーザーインターフェース部を作る棲み分けですが、今はドライバ部の構成を整理しています。
これまでの試行錯誤から処理フローを図式化。基本の流れは見えたと思います。
ただ、C言語の構造体を用いた配列処理をもっと突っ込んで覚える必要があります。Art-Netのデータは、レベル値だけでなくメタデータとも言えるインデックスが重要で、カード型データ構造と言ってもいいでしょう。これの追加、削除、抽出、修正を延々と繰り返すので構造体配列を自在に扱えることは必須技能です。
C言語での配列は少し不器用で、私の理解が間違っていなければ、配列をデータベースに見立てたとしてレコードの追加や削除は出来ません。出来ると言えば出来るのですが、特定のレコードを除いた配列全体を新たな配列としてコピーするような操作が必要です。追加も似た様な操作になります。
少しややこしいのですが、次のサイトでは面白い事を書いてます。
C言語 構造体を使ってリスト構造を作るプログラム
C言語の配列に頼らずリスト構造を構成してます。言うなれば手作業で配列操作をするのです。
また、変数名を使わずメモリ領域を確保してポインタで管理しています。一見不合理な使い方に見えますが合理的かも。アセンブラっぽいので私には違和感はありません。
オレメモ
C言語：構造体のメンバのアドレス
C言語 ポインタ同士の引き算
配列が格納されるアドレスとピッチがわかればポインタで配列にアクセス出来ます。処理の内容によってはこの方が速いかも。
この他にも、以前はどうも理解しきれなかったC言語のマルチプロセスや共有メモリ(mmap)のことが理解できた。
Linuxプロセスの生成と実行 fork／exec
C言語でmmap()を用いてプロセス間で変数を共有する
以前の試作でイマイチだったところが解決しそうな期待感。
#[Art-Net]
ここ数か月全く進んでいませんが、Art-Netパッチを作っています。
で、思い付く。
回路名のプロファイルを使えたらどうかと。パッチ画面に回路の名称も併記するのです。パッチ操作ではDMXアドレスだけより名称もあった方が扱いやすいと思うからです。仮設現場でも回路名が表示されていればメンテナンス性がいいでしょうし。
あと、パッチマシンはC言語で全部書くのではなく、受送信パッチ処理はC言語で書き、ユーザーフロントエンドの部分はPythonで書いた方が良さそうです。C言語でドライバを作りPythonで操作する感覚です。繋げる部分の記述は面倒っちゃ面倒ですが、C言語とPtyhonで得意分野を分けた方が生産性がいいかもしれません。
#[Art-Net] #器具の製作
で、思い付く。
回路名のプロファイルを使えたらどうかと。パッチ画面に回路の名称も併記するのです。パッチ操作ではDMXアドレスだけより名称もあった方が扱いやすいと思うからです。仮設現場でも回路名が表示されていればメンテナンス性がいいでしょうし。
あと、パッチマシンはC言語で全部書くのではなく、受送信パッチ処理はC言語で書き、ユーザーフロントエンドの部分はPythonで書いた方が良さそうです。C言語でドライバを作りPythonで操作する感覚です。繋げる部分の記述は面倒っちゃ面倒ですが、C言語とPtyhonで得意分野を分けた方が生産性がいいかもしれません。
#[Art-Net] #器具の製作
「Open DMX USB」について考えていたのは移動中アタマが空いていたからです。
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
DMX Delay を発見！（知人に教えてもらいました）
DMXdelayer （alpha version）
同じことに取り組んでいる方がいらっしゃることが何より嬉しいです。
#[Art-Net]
DMXdelayer （alpha version）
同じことに取り組んでいる方がいらっしゃることが何より嬉しいです。
#[Art-Net]
EoCの試験の続きでArt-Netを通してみました。全く問題なく動きます。繋いだだけで動いたので試行錯誤は無し。
接続は次の通りです。配線が汚いのはテストなのでご勘弁を。
[MAdot2]
↓ Cat5e
[Ethernetハブ]
↓ Cat5e
[PoEインジェクタ] ← <AC100v>
↓ Cat5e(PoEとして電源供給線も兼ねるので細いケーブルは非推奨)
[EoCレシーバ]
↓ A2V1B(3C相当) 50m
[EoCトランスミッタ]
↓ Cat5e
[Ethernetハブ]
↓ Cat5e
[Art-Net Node]
↓ XLR 5P
[DoctorMA]
↓ USB2.0
[パソコン]
エフェクトエンジンのデータで半日くらい様子を見てみます。
トランスミッタとレシーバは逆にしても動きます。
DMXのモニターにはDoctorMXを使っていますが、信号の遅れなのかDoccorMXの遅れなのか、ほんのわずかに遅れを感じるかもしれません。
しばらく先になりますが、現場で使えるパッケージも考えないといけません。これらを毎回組んでいたら面倒ですからね。
箱の中にそれぞれの用品を固定し、パネルに取り口を付けようと思います。これにUPSやインカムのパワーサプライも同居させたら便利かなと。
EoCのレシーバとトランスミッタはそこそこ熱を持つのでパッケージにおいては冷却を考慮した方がいいですね。こうったバラバラの物をパッケージする際はベース板を合板にした方が楽ですが、底板をアルミにした筐体放熱も検討の余地ありです。
#[Art-Net]
接続は次の通りです。配線が汚いのはテストなのでご勘弁を。
[MAdot2]
↓ Cat5e
[Ethernetハブ]
↓ Cat5e
[PoEインジェクタ] ← <AC100v>
↓ Cat5e(PoEとして電源供給線も兼ねるので細いケーブルは非推奨)
[EoCレシーバ]
↓ A2V1B(3C相当) 50m
[EoCトランスミッタ]
↓ Cat5e
[Ethernetハブ]
↓ Cat5e
[Art-Net Node]
↓ XLR 5P
[DoctorMA]
↓ USB2.0
[パソコン]
エフェクトエンジンのデータで半日くらい様子を見てみます。
トランスミッタとレシーバは逆にしても動きます。
DMXのモニターにはDoctorMXを使っていますが、信号の遅れなのかDoccorMXの遅れなのか、ほんのわずかに遅れを感じるかもしれません。
しばらく先になりますが、現場で使えるパッケージも考えないといけません。これらを毎回組んでいたら面倒ですからね。
箱の中にそれぞれの用品を固定し、パネルに取り口を付けようと思います。これにUPSやインカムのパワーサプライも同居させたら便利かなと。
EoCのレシーバとトランスミッタはそこそこ熱を持つのでパッケージにおいては冷却を考慮した方がいいですね。こうったバラバラの物をパッケージする際はベース板を合板にした方が楽ですが、底板をアルミにした筐体放熱も検討の余地ありです。
#[Art-Net]