2022年3月 この範囲を時系列順で読む この範囲をファイルに出力する
オレメモ
● Art-Netの受信の準備でするべきこと。
・受信のタイムアウトを定義し、タイムアウトを例外としてキチンと処理する。
● Art-Netを受信したらするべきこと。
・受信した「Art-Netのバイナリデータ」に「いつ」「どこからか(送信元)」を絡めて受信データとする。
・ユニバースと内部ルートの対照データを基に、データの参照キーを「ユニバース」から「ルート」に変換してキャッシュする。
・「いつ」をキーに送信元からの送信が無くなったと見なせるならキャッシュも含め送信元情報を消去する。
・「いつ」をキーにキャッシュの有効期限が切れたならキャッシュのレベル値をすべてゼロにする。
・送信元ごとのキャッシュをルートで丸めて一意のキャッシュにする。
#[Art-Net]
● Art-Netの受信の準備でするべきこと。
・受信のタイムアウトを定義し、タイムアウトを例外としてキチンと処理する。
● Art-Netを受信したらするべきこと。
・受信した「Art-Netのバイナリデータ」に「いつ」「どこからか(送信元)」を絡めて受信データとする。
・ユニバースと内部ルートの対照データを基に、データの参照キーを「ユニバース」から「ルート」に変換してキャッシュする。
・「いつ」をキーに送信元からの送信が無くなったと見なせるならキャッシュも含め送信元情報を消去する。
・「いつ」をキーにキャッシュの有効期限が切れたならキャッシュのレベル値をすべてゼロにする。
・送信元ごとのキャッシュをルートで丸めて一意のキャッシュにする。
#[Art-Net]
実機を離れて考えを進めると抜けが見えてきます。
一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。
受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。
ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。
#Python #[Art-Net]
一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。
受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。
ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。
#Python #[Art-Net]
オレメモ
Pythonのsocket.recvfromでタイムアウト処理をする。
socketのインスタンスをsockとした場合、sock.recvfromの前に
sock.settimeout(<タイムアウトの秒数>)
とする。
sock.recvfrom(<バッファ数>) を try: で実行し、except socket.timeout: でタイムアウトエラーを拾う。
#Python
Pythonのsocket.recvfromでタイムアウト処理をする。
socketのインスタンスをsockとした場合、sock.recvfromの前に
sock.settimeout(<タイムアウトの秒数>)
とする。
sock.recvfrom(<バッファ数>) を try: で実行し、except socket.timeout: でタイムアウトエラーを拾う。
#Python
本日は久しぶりの現地照明。現場って感じでホッとします。
実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。
#[Art-Net]
実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。
#[Art-Net]
レガシーDMX512の出力インターフェースを作るには少し工夫が必要です。
RaspberryPiでもPICでも使えるインターフェースで十分な速度を持つのはSPIです。I2Cは便利ですがPICが最大400kbpsなので1ユニバースしか扱えません。
かといって、高速のSPIで複数のPICで扱うのはかなり難しい。解決するにはロジックICを用いた分岐回路を用いるのが良さそうですが、ICが5個くらい必要なので実装面積に問題があります。
ならばGALを使うのはどうかと。FPGAやCPLDの祖先であり、今回の構成に丁度良いスペックです。何と言っても安い。
ただし、GALはすでに過去の物で開発は終わっています。決して多くないニーズに応えて生産されているだけですし、開発ソフトウェアも正規対応がWindowsXP止まり。
されど、10個未満のTTL-ICで組む様な事を1個で組めるのは便利ですし、数十MHzまで対応するので、RaspberryPiなどのLinux系小型マイコンの外付け回路を組むには丁度良いと思います。
便利そうですが微妙なので導入を控えていましたが、改めて調べたところ書き込み装置などの開発用品が安くなっていたので、この際環境を整えてみましょう。
RaspberryPiとPICとGALを組み合わせれば製品が作りやすくなるような気がします。
#電子工作
RaspberryPiでもPICでも使えるインターフェースで十分な速度を持つのはSPIです。I2Cは便利ですがPICが最大400kbpsなので1ユニバースしか扱えません。
かといって、高速のSPIで複数のPICで扱うのはかなり難しい。解決するにはロジックICを用いた分岐回路を用いるのが良さそうですが、ICが5個くらい必要なので実装面積に問題があります。
ならばGALを使うのはどうかと。FPGAやCPLDの祖先であり、今回の構成に丁度良いスペックです。何と言っても安い。
ただし、GALはすでに過去の物で開発は終わっています。決して多くないニーズに応えて生産されているだけですし、開発ソフトウェアも正規対応がWindowsXP止まり。
されど、10個未満のTTL-ICで組む様な事を1個で組めるのは便利ですし、数十MHzまで対応するので、RaspberryPiなどのLinux系小型マイコンの外付け回路を組むには丁度良いと思います。
便利そうですが微妙なので導入を控えていましたが、改めて調べたところ書き込み装置などの開発用品が安くなっていたので、この際環境を整えてみましょう。
RaspberryPiとPICとGALを組み合わせれば製品が作りやすくなるような気がします。
#電子工作
Art-Netは受信したデータのスタックの仕方を変えてうまくいきました。
約1/100秒毎でスタックし、1/40秒毎で出力しています。
試験的な処理ですが、Delayもユニバース単位で綺麗に動きます。
Art-Netの送受信の試験製作はこれにて終了。
ただ、テストで使っていた中華電器のArt-Netデコーダが不良品でした。
8アウトの製品ですが、普通に使うとDMXポートが1つしか信号を出さない。
組み合わせを吟味すると半分の4ポートは出力されますが、マニュアル通りに使って正しく動かないのでは現場じゃ使えません。
届いた時に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ポートが1つしか信号を出さない。
組み合わせを吟味すると半分の4ポートは出力されますが、マニュアル通りに使って正しく動かないのでは現場じゃ使えません。
届いた時に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]
客席テーブルに塗布したポリエステル樹脂はよさげです。
YAMAHAのPC2002を1台と7.5kgの砂袋を2個乗せて丸1日様子をみましたが、ラックケースのゴム足の汚れが移るくらいで変化はありません。汚れは雑巾で拭けば落ちます。
爪で掻くと薄い線が付きますので鉄板やデコラ板より柔らかいのですが、ラッカーなどの1液式塗料に比べたら圧倒的に丈夫です。ポリエステル樹脂は造形に使う物で、塗料は装飾性を上げたり風化を抑える物ですから機械強度が違って当然ですけど。
あとは、ボールロックピンの紛失防止ワイヤーの固定と脚を収納する受けの塗装です。
脚は塗装をし直したい感じもあります。溶接によって寸法が狂ったところがあるのですが、補正をすると塗料が剥げるので、どうせなら防錆(「必殺錆封じ」という防錆剤の塗布)からやり直したいかも。
ちょいと忙しくなってきた本業を片付けつつ最終仕上げまでやってしまいたい。
#ガチ工作
YAMAHAのPC2002を1台と7.5kgの砂袋を2個乗せて丸1日様子をみましたが、ラックケースのゴム足の汚れが移るくらいで変化はありません。汚れは雑巾で拭けば落ちます。
爪で掻くと薄い線が付きますので鉄板やデコラ板より柔らかいのですが、ラッカーなどの1液式塗料に比べたら圧倒的に丈夫です。ポリエステル樹脂は造形に使う物で、塗料は装飾性を上げたり風化を抑える物ですから機械強度が違って当然ですけど。
あとは、ボールロックピンの紛失防止ワイヤーの固定と脚を収納する受けの塗装です。
脚は塗装をし直したい感じもあります。溶接によって寸法が狂ったところがあるのですが、補正をすると塗料が剥げるので、どうせなら防錆(「必殺錆封じ」という防錆剤の塗布)からやり直したいかも。
ちょいと忙しくなってきた本業を片付けつつ最終仕上げまでやってしまいたい。
#ガチ工作
ユニバース単位の試験的な物ですが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]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131