電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-Net」を含む投稿［125件］（11ページ目）
実機を離れて考えを進めると抜けが見えてきます。
一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。
受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。
ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。
#Python #[Art-Net]
一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。
受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。
ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。
#Python #[Art-Net]
本日は久しぶりの現地照明。現場って感じでホッとします。
実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。
#[Art-Net]
実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。
#[Art-Net]
Art-Netは受信したデータのスタックの仕方を変えてうまくいきました。
約1/100秒毎でスタックし、1/40秒毎で出力しています。
試験的な処理ですが、Delayもユニバース単位で綺麗に動きます。
Art-Netの送受信の試験製作はこれにて終了。
ただ、テストで使っていた中華電器のArt-Netデコーダが不良品でした。
8アウトの製品ですが、普通に使うとDMXポートが１つしか信号を出さない。
組み合わせを吟味すると半分の４ポートは出力されますが、マニュアル通りに使って正しく動かないのでは現場じゃ使えません。
届いた時にMAdot2でテストしてちゃんと動いたような気がするのですが・・・
Art-Netのデコーダは市販品もありますが、RaspberryPiでここまで出来てしまうと自作した方が圧倒的に安い。市販品の国内価格は7-8万円ですが、材料費だけなら2万もしません。
レガシーDMXのインターフェースは基板から自作になりますが、PICマイコンでSPIからDMXにプロトコル変換するだけなのでそれほど難しくないハズ。パッチマシンとしてまとめる際には必要ですから作ってしまいましょう。
#RaspberryPi #[Art-Net]
約1/100秒毎でスタックし、1/40秒毎で出力しています。
試験的な処理ですが、Delayもユニバース単位で綺麗に動きます。
Art-Netの送受信の試験製作はこれにて終了。
ただ、テストで使っていた中華電器のArt-Netデコーダが不良品でした。
8アウトの製品ですが、普通に使うとDMXポートが１つしか信号を出さない。
組み合わせを吟味すると半分の４ポートは出力されますが、マニュアル通りに使って正しく動かないのでは現場じゃ使えません。
届いた時にMAdot2でテストしてちゃんと動いたような気がするのですが・・・
Art-Netのデコーダは市販品もありますが、RaspberryPiでここまで出来てしまうと自作した方が圧倒的に安い。市販品の国内価格は7-8万円ですが、材料費だけなら2万もしません。
レガシーDMXのインターフェースは基板から自作になりますが、PICマイコンでSPIからDMXにプロトコル変換するだけなのでそれほど難しくないハズ。パッチマシンとしてまとめる際には必要ですから作ってしまいましょう。
#RaspberryPi #[Art-Net]
Art-Netの入力の扱いについて考えを進めています。
受信の更新頻度に合わせた処理ではフリッカーが発生することが確定。送られてくる頻度が変化するために起こることですが、根本的に何か変えないと解決しません。
対策は、十分に早い頻度で入力をサンプリングし、内部処理を整えて値の変化を滑らかにすることです。
例えば、1/30秒の頻度から1/10秒の頻度を見たとき、更新が1/3回と見るのではなく、3回同じデータが送られているとみるべきなのです。
DMX512の規格を読み解くと更新頻度は1秒～1/44秒の範囲になりますが、更新頻度の違いによるフリッカーを防止するには1/44秒よりも短い頻度でサンプリングすることが肝のようです。
短ければ短いほど安定すると思われますが、実際に作って落としどころを見つけましょう。
#[Art-Net]
受信の更新頻度に合わせた処理ではフリッカーが発生することが確定。送られてくる頻度が変化するために起こることですが、根本的に何か変えないと解決しません。
対策は、十分に早い頻度で入力をサンプリングし、内部処理を整えて値の変化を滑らかにすることです。
例えば、1/30秒の頻度から1/10秒の頻度を見たとき、更新が1/3回と見るのではなく、3回同じデータが送られているとみるべきなのです。
DMX512の規格を読み解くと更新頻度は1秒～1/44秒の範囲になりますが、更新頻度の違いによるフリッカーを防止するには1/44秒よりも短い頻度でサンプリングすることが肝のようです。
短ければ短いほど安定すると思われますが、実際に作って落としどころを見つけましょう。
#[Art-Net]
ユニバース単位の試験的な物ですがDelayが出来ました。精度はともかく遅れます。
ただ、卓の更新頻度による問題発生。
MAdot2は値が変化しているときの更新頻度が1/30秒くらいですが、値の変化が無いときの更新頻度は1/10秒くらいです。卓としては間違っていない動作ですが、この違いのためにカットチェンジとフェードチェンジではDelayタイムが見た目で違ってしまいます。1/30なら0.033秒、1/10なら0.1秒の潜在的な遅れが処理のキータイムになってしまうからです。
こうなると入力を遅らせるのではなく出力を遅らせないといけないのかな？スロット単位にDelayをかけたいけど出力側のユニバース単位が現実的かなぁ～。
・・・考えを進めてみました。
今は受信のタイミングでデータをスタックしていますが、一定時間でスタックをしたらどうか。
DMX512は最大1/44秒毎くらいですが、1/100秒毎くらいで最後に受信したデータをスタックしていくのです。タイミングとピッチが違う情報をサンプリングの頻度を上げることで整えて滑らかにします。また、スタックの時間間隔が一定なら日時情報をスタックせずに済みますし、ソート並みに重い近似値抽出も不要です。
スタックが多くなっても処理全体が軽くなるならアリかも。
#Python #[Art-Net]
ただ、卓の更新頻度による問題発生。
MAdot2は値が変化しているときの更新頻度が1/30秒くらいですが、値の変化が無いときの更新頻度は1/10秒くらいです。卓としては間違っていない動作ですが、この違いのためにカットチェンジとフェードチェンジではDelayタイムが見た目で違ってしまいます。1/30なら0.033秒、1/10なら0.1秒の潜在的な遅れが処理のキータイムになってしまうからです。
こうなると入力を遅らせるのではなく出力を遅らせないといけないのかな？スロット単位にDelayをかけたいけど出力側のユニバース単位が現実的かなぁ～。
・・・考えを進めてみました。
今は受信のタイミングでデータをスタックしていますが、一定時間でスタックをしたらどうか。
DMX512は最大1/44秒毎くらいですが、1/100秒毎くらいで最後に受信したデータをスタックしていくのです。タイミングとピッチが違う情報をサンプリングの頻度を上げることで整えて滑らかにします。また、スタックの時間間隔が一定なら日時情報をスタックせずに済みますし、ソート並みに重い近似値抽出も不要です。
スタックが多くなっても処理全体が軽くなるならアリかも。
#Python #[Art-Net]
Art-Netパッチにはミキサー機能も入れたいような。
将来的にレガシーDMX512も取り付けるならあると便利ですし、Art-Netはローレベルでミキサーを構成しやすいのがわかったからです。
見える機能にしないまでも、内部的には可能な様に作っておけばいいのかなと。
機能の大枠はミキサー、パッチ、ディレイ、カーブプロファイル、リミッタまたはコンプレッション、ライン(固定値・いわゆる直)で検討を進めています。
設定項目を多くし過ぎると凡ミスの原因になりますので現実的な線で考えたいですが・・・
用語ですが、DMXの内部系統をラインと呼ぶと混乱するのでルート(route)と呼ぶことにします。
#[Art-Net]
将来的にレガシーDMX512も取り付けるならあると便利ですし、Art-Netはローレベルでミキサーを構成しやすいのがわかったからです。
見える機能にしないまでも、内部的には可能な様に作っておけばいいのかなと。
機能の大枠はミキサー、パッチ、ディレイ、カーブプロファイル、リミッタまたはコンプレッション、ライン(固定値・いわゆる直)で検討を進めています。
設定項目を多くし過ぎると凡ミスの原因になりますので現実的な線で考えたいですが・・・
用語ですが、DMXの内部系統をラインと呼ぶと混乱するのでルート(route)と呼ぶことにします。
#[Art-Net]
先日書いた謎のオレメモ
np.abs( np_array_dt - ( datetime.datetime.now() - datetime.timedelta(seconds=0.1) ) ).argmin()
これはDelay機能で重要な処理です。
日時の配列(np_array_dt)の中から、現在日時から一定の時間を差し引いた日時に最も近い日時を項に持つIndexを得ます。
Delayを構成するにあたり、受信値に日時を付けて数世代のデータを保存し、少し前の入力値を使います。出力を遅らすのではなく入力を遅らすのです。
パッチはパッチマップに従って入力スロットの値を出力スロットにコピーしますが、コピー元の入力スロットを探すアドレスに受信世代のインデックスも持たせれば１フェーズでパッチとDelayの処理が完了します。コピー元のアドレスの表現を「何秒前の何番LINEの何番スロット」とするワケです。Titan系からのパクリですが、LINEとはDMXの内部系統のことです。８ユニバースを扱う構想ですから８LINEあります。内部系統に入出力先をパッチするのは言うまでもありません。
意味合いとして正しいのはパッチが済んだデータの出力を指定時間遅らすことだと思いますが、入力を遅らせてもその様に振る舞うならいいかなと。
そもそも反応が鈍い劇場の調光装置と反応が鋭い機器をワンボードで操作しても明かりの変化を一斉にさせたいという要望からのDelayです。カットインをカットインにしたいだけで、照明効果を作るエフェクトではありません。
ですから、厳密に設定時間分遅らせることが目的ではなく、全体が同じタイミングで動いているように「見えれば」いいので、入力の世代を管理する方法で十分だと思うのです。
「少し前の日時のインデックス」を見つけるのが謎式の正体です。
ちなみに、時刻を使わず日時を使う理由は、深夜24時、日付が変わる瞬間に必ずエラーが起こるからです。0時0分0秒付近でほんの一瞬ですが、設定可能な最大Delay時間前のデータが出ます。Delay最大値が１秒なら１秒前のデータが出てしまうのです。一瞬のこととはいえ、こんな潜在エラーがあったらカウントダウンの現場では使えません。
#Python #[Art-Net]
np.abs( np_array_dt - ( datetime.datetime.now() - datetime.timedelta(seconds=0.1) ) ).argmin()
これはDelay機能で重要な処理です。
日時の配列(np_array_dt)の中から、現在日時から一定の時間を差し引いた日時に最も近い日時を項に持つIndexを得ます。
Delayを構成するにあたり、受信値に日時を付けて数世代のデータを保存し、少し前の入力値を使います。出力を遅らすのではなく入力を遅らすのです。
パッチはパッチマップに従って入力スロットの値を出力スロットにコピーしますが、コピー元の入力スロットを探すアドレスに受信世代のインデックスも持たせれば１フェーズでパッチとDelayの処理が完了します。コピー元のアドレスの表現を「何秒前の何番LINEの何番スロット」とするワケです。Titan系からのパクリですが、LINEとはDMXの内部系統のことです。８ユニバースを扱う構想ですから８LINEあります。内部系統に入出力先をパッチするのは言うまでもありません。
意味合いとして正しいのはパッチが済んだデータの出力を指定時間遅らすことだと思いますが、入力を遅らせてもその様に振る舞うならいいかなと。
そもそも反応が鈍い劇場の調光装置と反応が鋭い機器をワンボードで操作しても明かりの変化を一斉にさせたいという要望からのDelayです。カットインをカットインにしたいだけで、照明効果を作るエフェクトではありません。
ですから、厳密に設定時間分遅らせることが目的ではなく、全体が同じタイミングで動いているように「見えれば」いいので、入力の世代を管理する方法で十分だと思うのです。
「少し前の日時のインデックス」を見つけるのが謎式の正体です。
ちなみに、時刻を使わず日時を使う理由は、深夜24時、日付が変わる瞬間に必ずエラーが起こるからです。0時0分0秒付近でほんの一瞬ですが、設定可能な最大Delay時間前のデータが出ます。Delay最大値が１秒なら１秒前のデータが出てしまうのです。一瞬のこととはいえ、こんな潜在エラーがあったらカウントダウンの現場では使えません。
#Python #[Art-Net]
キーボード、モニタ、ネットワークなど、ハードウェアとのやり取りを先に進めていますが、ボチボチ本丸であるパッチ機能の具体的な作りもまとめ始めています。
パッチ機能はマッピングファイルに従って入力を出力に置き換える作業なのでアルゴリズムに難しいことはありませんが、十分な速度を得られるかが難しい課題です。
DMX512は１スロットあたり44usecです。100万分の44秒ってことですが、８ユニバース扱うなら100万分の5.5秒以内に１スロットを確実に処理しなければなりません。RaspberryPi4BのCPUクロックは1GHz以上であり、それが４スレッドありますから間に合うような気もするのですが、確認しながら工夫していく必要があると思われます。
なんの工夫もなくPythonを動かすとCPUは１スレッドしか使われません。RaspberryPiでは能力の1/4しか使えないってことです。CPUの能力を最大限使おうとするなら、実行ファイルを複数に分けてOSレベルでプロセスを分けるか、Python内でmultiprocessingを定義して複数のCPUスレッドがPythonの処理を請け負うように仕向けないといけません。
multiprocessingの使い方はThreadingと似ているので難しいことは無さそうですが、こういったちょっと深いところをちゃんと書かないとRaspberryPiでパッチマシンは厳しい感じです。
#Python #[Art-Net]
パッチ機能はマッピングファイルに従って入力を出力に置き換える作業なのでアルゴリズムに難しいことはありませんが、十分な速度を得られるかが難しい課題です。
DMX512は１スロットあたり44usecです。100万分の44秒ってことですが、８ユニバース扱うなら100万分の5.5秒以内に１スロットを確実に処理しなければなりません。RaspberryPi4BのCPUクロックは1GHz以上であり、それが４スレッドありますから間に合うような気もするのですが、確認しながら工夫していく必要があると思われます。
なんの工夫もなくPythonを動かすとCPUは１スレッドしか使われません。RaspberryPiでは能力の1/4しか使えないってことです。CPUの能力を最大限使おうとするなら、実行ファイルを複数に分けてOSレベルでプロセスを分けるか、Python内でmultiprocessingを定義して複数のCPUスレッドがPythonの処理を請け負うように仕向けないといけません。
multiprocessingの使い方はThreadingと似ているので難しいことは無さそうですが、こういったちょっと深いところをちゃんと書かないとRaspberryPiでパッチマシンは厳しい感じです。
#Python #[Art-Net]
Art-Netの受信モニタはイメージ通りに動きました。選択したユニバースをキレイに表示しています。
当面の習作課題はクリアしましたが、喜ぶというより目の前に新たな壁が見えてきました。
この後はartnet-coreと名付けている受信と加工を司るサーバー的な部分を作ります。
ここまでの経験をもとに全体の構造をよく考えてから作る必要があります。
#Python #[Art-Net]
当面の習作課題はクリアしましたが、喜ぶというより目の前に新たな壁が見えてきました。
この後はartnet-coreと名付けている受信と加工を司るサーバー的な部分を作ります。
ここまでの経験をもとに全体の構造をよく考えてから作る必要があります。
#Python #[Art-Net]
画面とArt-Netの送受信を結合させられる段階になりました。Art-Netをスルー出力し特定のユニバースをモニタします。
簡易ながら実験段階で出来ていることですから、画面を整えたからってなんだよって構成ですが、パッチマシンの一部を先行して作っているので重要な過程です。表示することが目的ではなく、最低限持たなければならない機能を出来るだけ見やすく使いやすく軽く、そして今後の伸びしろを持たせた構成でまとめ上げることが目的です。
#[Art-Net]
簡易ながら実験段階で出来ていることですから、画面を整えたからってなんだよって構成ですが、パッチマシンの一部を先行して作っているので重要な過程です。表示することが目的ではなく、最低限持たなければならない機能を出来るだけ見やすく使いやすく軽く、そして今後の伸びしろを持たせた構成でまとめ上げることが目的です。
#[Art-Net]