https://www.densokogei.jp/tegalog/tegalog.cgi ja Copyright 2026 Fri, 01 May 2026 10:58:00 +0900 Powered by てがろぐ Ver 3.4.0 ]]> 前記事。
　３Ｄプリンタで１枚あたり４時間かかるので全数上がるのはまだまだ先ですがイイ感じです。
　安い割に本機能は優秀ですが、建具がシッカリしていないと使えるものではありません。地道にチマチマ進めていきます。
　この後も専用のオベタというか脚も作らねばならず、運用品としてコンプリートするのはまだまだ先ですけどね。

#照明器具 #器具の修理 -- Posted by 電装工芸 〔224文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=857 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=857 tegalog Fri, 12 Apr 2024 06:38:49 +0900 　今までにない設定が少しありましたが普通にDebianです。
　Pythonは3.9.2まで上がっています。ここ数年で追加された新機能がほとんど使えます。

　すべての方法を試したワケではありませんが、Pythonのプロセス間通信は全般的に遅いのかもしれません。マルチプロセス処理は、常に通信しながらの並行処理ではなく、重い処理を別なところでやって結果を取り込むという発想で作られている感じがします。
　となると、ユーザー操作や設定データ(パッチマップ、プロファイルカーブマップなど)の作成は別プロセスで行うとしても、受信から送信までのArt-Netの一連の処理はシングルプロセスで行うのがいいのかもしれません。プロセス間通信のオーバーヘッドを無くすためです。

追記

　少し調べを進めてみました。
　Queueは使い勝手がいいのですが、トラブルが起きにくい様にマネージされているので挙動が遅いようです。
　プロセス間通信にはPipeや共有メモリなどQueue以外にも幾つか方法がありますが、速度が出る方法は管理が難しく、管理が簡単な方法は速度が出ないという関係にあるようで、管理が簡単で速度が出る方法は無い様子。
　仮に速度が出るとされる方法を使ってもカレントプロセスの変数を扱うほどの速度は出ませんので、外部とのやりとりはQueueなどを使うとしても、常駐する繰り返し処理はシングルプロセスで単純化を狙った方が良い結果になりそうです。
　全体的にマルチプロセスで外に出すってことです。

#Python #[Art-Net] -- Posted by 電装工芸 〔699文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=228 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=228 tegalog Tue, 12 Apr 2022 09:01:03 +0900