電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-Net」を含む投稿［125件］（8ページ目）
急に入ったライトアップを仕込んできました。
例年年末に実施している仕込みで色を変えたものです。
今回は単色なので灯体のプレイバック機能で十分ですが、ライトアップ特化した卓が欲しいなと。何月何日何時からシーンの何番を実行するとプログラム出来るものです。
DMXレコーダー系は実尺での取り込みが必要なのでイヤ。
DAS-Lightの上位機種にはカレンダー機能がありますが、明かり作りの操作感が肌に合わないのでイヤ。
設備系は高価だし明かり作りが面倒なのでイヤ。
そういや、今作っているArt-Netパッチを拡張すればよくね！？
エフェクトエンジンを搭載するにはあと100年くらいかかりそうですが、単純なステップタイプの卓を作るのはそれほど難しく無いと思います。シーケンスの実行トリガに日時、シーンの実行トリガに経過時間を設定出来るものとする。チェイスはシーンのループ処理がしやすいことで対策。贅沢を言い始めたらキリがありませんが、単純なステップタイプのシーケンスにライトアップで便利なちょい機能を加える考え方です。
高度なことをするなら高度な卓を使えばいいのですし、今困っている簡単そうで簡単に出来ないことに特化したモノであればいい。私の要望は、LEDスポットに内蔵されたシーン機能がプログラムしやすくて実行の日時指定が出来ればいいレベルです。「LEDカラーミックススポットを使ったライトアップで、何年何月何日何時何分何秒から指定したパターンが実行できるシンプルな卓」とします。
決して、MAやAVOにカレンダー機能を搭載したモノな物は目指さない。「MAなら簡単にでき・・・」とか言う輩はMAを使えばいいのです。
#[Art-Net]
例年年末に実施している仕込みで色を変えたものです。
今回は単色なので灯体のプレイバック機能で十分ですが、ライトアップ特化した卓が欲しいなと。何月何日何時からシーンの何番を実行するとプログラム出来るものです。
DMXレコーダー系は実尺での取り込みが必要なのでイヤ。
DAS-Lightの上位機種にはカレンダー機能がありますが、明かり作りの操作感が肌に合わないのでイヤ。
設備系は高価だし明かり作りが面倒なのでイヤ。
そういや、今作っているArt-Netパッチを拡張すればよくね！？
エフェクトエンジンを搭載するにはあと100年くらいかかりそうですが、単純なステップタイプの卓を作るのはそれほど難しく無いと思います。シーケンスの実行トリガに日時、シーンの実行トリガに経過時間を設定出来るものとする。チェイスはシーンのループ処理がしやすいことで対策。贅沢を言い始めたらキリがありませんが、単純なステップタイプのシーケンスにライトアップで便利なちょい機能を加える考え方です。
高度なことをするなら高度な卓を使えばいいのですし、今困っている簡単そうで簡単に出来ないことに特化したモノであればいい。私の要望は、LEDスポットに内蔵されたシーン機能がプログラムしやすくて実行の日時指定が出来ればいいレベルです。「LEDカラーミックススポットを使ったライトアップで、何年何月何日何時何分何秒から指定したパターンが実行できるシンプルな卓」とします。
決して、MAやAVOにカレンダー機能を搭載したモノな物は目指さない。「MAなら簡単にでき・・・」とか言う輩はMAを使えばいいのです。
#[Art-Net]
久しぶりにArt-Netエンジンを書く時間が取れそうです。
丁度よい冷却期間になったのか、そもそもの修正点を思いつきました。
そもそもというのは処理の全体像のことです。Art-Netを受信して、パッチ処理などをして、送信するワケですが、これらの処理を無駄なく適切なタイミングで行うことはとても大切なので、それを目指して書き直しをするのです。偉そうな言葉を使うなら「最適化」です。
正直言いますと大きな無駄を見つけたのです。何しろ経験豊富の真逆ですから、設計書を書いてコーディングして・・・なんて上品な製作は出来ません。思い付いて書いては実験、思い付いて書き直しては実験を繰り返すので、付け焼刃の繰り返しで各所に歪みやら無駄が溜まるのです。一応機能するようになったら全体の見直しをするのはいつものことですけど、３歩進んで２歩下がるを繰り返す自分の様は残念です。つーても、誰かが書いてくれるワケでも添削してくれるワケでもないので仕方ありません。
全体の直しはあるとしても、作業の要はスタックフェーダーへの対応です。
ちょっと前まではスタックフェーダーのシーンデータをエンジン内に持たせ、別プロセスからマスター値を送り込んでエンジン内で出力値の計算をさせるイメージでしたが、エンジンの処理がやたら重くなるし拡張性も低いのでやめます。Art-Net受信値とMIXする一意のデータをエンジンに送り込むことにし、シーンデータを持つのもマスター値による出力値の計算もスタックフェーダ間のMIXも別プロセスにさせることにします。こうすれば、将来的に卓へ拡張してもArt-Netエンジン自体の変更は不要です。
#[Art-Net]
丁度よい冷却期間になったのか、そもそもの修正点を思いつきました。
そもそもというのは処理の全体像のことです。Art-Netを受信して、パッチ処理などをして、送信するワケですが、これらの処理を無駄なく適切なタイミングで行うことはとても大切なので、それを目指して書き直しをするのです。偉そうな言葉を使うなら「最適化」です。
正直言いますと大きな無駄を見つけたのです。何しろ経験豊富の真逆ですから、設計書を書いてコーディングして・・・なんて上品な製作は出来ません。思い付いて書いては実験、思い付いて書き直しては実験を繰り返すので、付け焼刃の繰り返しで各所に歪みやら無駄が溜まるのです。一応機能するようになったら全体の見直しをするのはいつものことですけど、３歩進んで２歩下がるを繰り返す自分の様は残念です。つーても、誰かが書いてくれるワケでも添削してくれるワケでもないので仕方ありません。
全体の直しはあるとしても、作業の要はスタックフェーダーへの対応です。
ちょっと前まではスタックフェーダーのシーンデータをエンジン内に持たせ、別プロセスからマスター値を送り込んでエンジン内で出力値の計算をさせるイメージでしたが、エンジンの処理がやたら重くなるし拡張性も低いのでやめます。Art-Net受信値とMIXする一意のデータをエンジンに送り込むことにし、シーンデータを持つのもマスター値による出力値の計算もスタックフェーダ間のMIXも別プロセスにさせることにします。こうすれば、将来的に卓へ拡張してもArt-Netエンジン自体の変更は不要です。
#[Art-Net]
Art-Netパッチに使おうと買ってみた８吋のオープンフレームモニタが入荷しました。
オープンフレームモニタは単体で使うモニタではなく機器に内蔵するためのモニタです。無骨ですが、取付金具やネジ穴があって筐体作りには向いています。
今後の確認次第ですが、いい感じだと思います。
当初使おうと思った公式の７吋ディスプレイは16:9の800x480ドットです。表示される文字の大きさは老眼にも優しく丁度いいのですが、情報量が不足な上に16:9は表が読みにくい感じがします。
８吋の800x600が希望だったのですが、取り扱い店が少なく将来的な入手に不安を感じるので、取り扱いが多い８吋の1024x768を選びました。
文字が小さい気もするのですが、512スロットを１画面に表示出来そうなのは悪くありません。かなり進んだ老眼には見えない文字サイズになりそうですが、ムービング卓の画面を読める人基準で考えます。明日は我が身ですけど(笑
先ほどまでこのモニタを仮に立てておく脚を3D-CADで描いてました。帰宅したらプリントです。
つか、現場の音源のフォーマット変換(m4a→wav)がなかなか終わらなくてそのヒマつぶしをしているところですが・・・
#[Art-Net]
オープンフレームモニタは単体で使うモニタではなく機器に内蔵するためのモニタです。無骨ですが、取付金具やネジ穴があって筐体作りには向いています。
今後の確認次第ですが、いい感じだと思います。
当初使おうと思った公式の７吋ディスプレイは16:9の800x480ドットです。表示される文字の大きさは老眼にも優しく丁度いいのですが、情報量が不足な上に16:9は表が読みにくい感じがします。
８吋の800x600が希望だったのですが、取り扱い店が少なく将来的な入手に不安を感じるので、取り扱いが多い８吋の1024x768を選びました。
文字が小さい気もするのですが、512スロットを１画面に表示出来そうなのは悪くありません。かなり進んだ老眼には見えない文字サイズになりそうですが、ムービング卓の画面を読める人基準で考えます。明日は我が身ですけど(笑
先ほどまでこのモニタを仮に立てておく脚を3D-CADで描いてました。帰宅したらプリントです。
つか、現場の音源のフォーマット変換(m4a→wav)がなかなか終わらなくてそのヒマつぶしをしているところですが・・・
#[Art-Net]
このところ本業が忙しい。
現場があるのは嬉しいことでありますが、発注側の段取りの悪さの尻拭いで時間を割かれることが多く気分は良くない。
Art-Netはアイデアだけまとまって書くところまで行けてません。ちょっと寂しい。
ちなみに、Art-Netの処理モジュールは「Art-Netエンジン」と呼ぶことにしました。
受信したデータにスタックフェーダー、ディレイ、パッチ、プロファイルの処理を施して送信するまでを１プロセスのモジュールにしてしまったので、やっていることがドライバって括りにするには広すぎるからです。
書き加えてない機能はスタックフェーダーですが、現時点の処理負荷は26%前後です。最終的に50%を割ればいいのではないかと思います。
処理負荷ですが、ANSIエスケープシーケンスによる表示処理が思った以上に重いことが判明。純Pythonでの繰り返し処理が多いからか、そもそもテキスト表示が遅いのか、いずれにしてもArt-Netエンジンと表示処理は完全にプロセスを分けないといけません。
まだ試していないのですが、ひょっとするとテキストベースよりもグラフィカルの方が処理が軽い可能性があります。扱う情報量は多くなりますが、ハードウェアでアクセラレーションされてるならひょっとするかもです。
表示モニタは中華電機で良さそうなのを見つけました。1024x768(4:3)で８インチです。組み込み用のオープンフレームモニタなので取り付けが楽です。価格も案外安い。
今どき4:3?って気もしますが、表示するのは表ですから、16:9よりも4:3の方が見やすい気がします。
また、あえての4:3だし、扱っているセラーが多く、組み込み用なので長期間の入手が期待出来ます。普通のモニターですと足が早くて半年後には同じ物が手に入らなくなることが多いのです。
#ガチ工作 #[Art-Net]
現場があるのは嬉しいことでありますが、発注側の段取りの悪さの尻拭いで時間を割かれることが多く気分は良くない。
Art-Netはアイデアだけまとまって書くところまで行けてません。ちょっと寂しい。
ちなみに、Art-Netの処理モジュールは「Art-Netエンジン」と呼ぶことにしました。
受信したデータにスタックフェーダー、ディレイ、パッチ、プロファイルの処理を施して送信するまでを１プロセスのモジュールにしてしまったので、やっていることがドライバって括りにするには広すぎるからです。
書き加えてない機能はスタックフェーダーですが、現時点の処理負荷は26%前後です。最終的に50%を割ればいいのではないかと思います。
処理負荷ですが、ANSIエスケープシーケンスによる表示処理が思った以上に重いことが判明。純Pythonでの繰り返し処理が多いからか、そもそもテキスト表示が遅いのか、いずれにしてもArt-Netエンジンと表示処理は完全にプロセスを分けないといけません。
まだ試していないのですが、ひょっとするとテキストベースよりもグラフィカルの方が処理が軽い可能性があります。扱う情報量は多くなりますが、ハードウェアでアクセラレーションされてるならひょっとするかもです。
表示モニタは中華電機で良さそうなのを見つけました。1024x768(4:3)で８インチです。組み込み用のオープンフレームモニタなので取り付けが楽です。価格も案外安い。
今どき4:3?って気もしますが、表示するのは表ですから、16:9よりも4:3の方が見やすい気がします。
また、あえての4:3だし、扱っているセラーが多く、組み込み用なので長期間の入手が期待出来ます。普通のモニターですと足が早くて半年後には同じ物が手に入らなくなることが多いのです。
#ガチ工作 #[Art-Net]
Art-Netドライバはボチボチです。
現場が無い日の定時後に2-3時間の作業ですから進みは遅いのですが、完成イメージは具体的になってきました。
されど、まだまだ追加しないといけない要素は多いのです。
今の課題はスタックフェーダーです。
数本のスタックフェーダーを構成するのは簡単そうに思えますが、スロット一つ一つに対して条件分岐をして数値をいじるような処理ではいけません。条件分岐を多用して書くと意図が読み取りやすいソースになりますが処理は遅いのです。同じことを短周期で何回も繰り返す処理は、PICのアセンブラを書いてきたクセですが、単純な計算結果にフラグの意図も持たせたりして条件分岐を減らしたいのです。例えば、一定の範囲で繰り返す加算カウンタを作るとして、一定数になったことで条件分岐して初期値に戻すのが基本的な考え方だと思いますが、カウンタを繰り返し数で割った余りも同じ数値になります(この方法は一つの配列で複数のカウンタを構成する場合にも便利な方法です)。割り算が苦手なシステムでは無謀な方法ですが、Pythonは条件分岐が遅いように感じるので、この様な方法で軽くなることもあるようです。
こんな感じで計算の中に条件分岐も含めるのは、将棋で数手先を考えるのとどこか似ています。
#[Art-Net]
現場が無い日の定時後に2-3時間の作業ですから進みは遅いのですが、完成イメージは具体的になってきました。
されど、まだまだ追加しないといけない要素は多いのです。
今の課題はスタックフェーダーです。
数本のスタックフェーダーを構成するのは簡単そうに思えますが、スロット一つ一つに対して条件分岐をして数値をいじるような処理ではいけません。条件分岐を多用して書くと意図が読み取りやすいソースになりますが処理は遅いのです。同じことを短周期で何回も繰り返す処理は、PICのアセンブラを書いてきたクセですが、単純な計算結果にフラグの意図も持たせたりして条件分岐を減らしたいのです。例えば、一定の範囲で繰り返す加算カウンタを作るとして、一定数になったことで条件分岐して初期値に戻すのが基本的な考え方だと思いますが、カウンタを繰り返し数で割った余りも同じ数値になります(この方法は一つの配列で複数のカウンタを構成する場合にも便利な方法です)。割り算が苦手なシステムでは無謀な方法ですが、Pythonは条件分岐が遅いように感じるので、この様な方法で軽くなることもあるようです。
こんな感じで計算の中に条件分岐も含めるのは、将棋で数手先を考えるのとどこか似ています。
#[Art-Net]
Art-Netドライバには追加しないといけないことがあります。
受信したデータにパッチなどを施して送信することには成功しているのですが、現時点ではフリーフェーダーやスタックフェーダーを考慮していません。
当初は[受信するプロセス]-[受信部からデータを取り出して加工するプロセス]-[加工したデータを受け取って送信するプロセス]と分けてイメージしていたので加工するプロセスで出来るだろうと思っていたのですが、プロセス間通信のオーバーヘッドを軽減するためにこれらを１つのプロセスにしましたので同じ考え方はできません。
今もパッチ等のマップデータはプロセス間通信で差し込んでいますが、マップデータが変更された時だけ実行すればいいので頻度が低く問題になりません。されど、即反応して欲しいフェーダー操作の情報は違ってきます。データをどう扱うか、どの位置で処理するか、ちょっと難しくなってきます。
フリーフェーダーだけなら特別なIPアドレス(例えば127.0.0.1)を用いた特別な経路でデータを取り込んでArt-Netと同列に処理する方法もありますが、スタックフェーダーにするにはちょっと無理があるように思ったりします。
ただ、これらのフェーダーはバックアップ的な意味合いが強いので反応がやや遅くてもいいかもしれません。これが許されるならプロセス間通信でデータを差し込んでもいいでしょう。
次のステップに入る前にここは片付けておかないといけません。
追記
スタックフェーダーの方法はアイデアが出ました。Art-Netの入力を記憶します。ただし、記憶するユニバースなりスロットを指定出来ないとディマー以外の動作を邪魔することがあるので一種のフィルターが必要です。フィルターがあればフリーフェーダー的にも機能します。排他的ではなくHTPミックスになりますが、この方がいいでしょう。
操作としては、記憶したい状態でスタックフェーダーとユニバースやスロットを指定してストアします。ユニバースやスロットが無指定ならすべてを記憶です。
#Python #[Art-Net]
受信したデータにパッチなどを施して送信することには成功しているのですが、現時点ではフリーフェーダーやスタックフェーダーを考慮していません。
当初は[受信するプロセス]-[受信部からデータを取り出して加工するプロセス]-[加工したデータを受け取って送信するプロセス]と分けてイメージしていたので加工するプロセスで出来るだろうと思っていたのですが、プロセス間通信のオーバーヘッドを軽減するためにこれらを１つのプロセスにしましたので同じ考え方はできません。
今もパッチ等のマップデータはプロセス間通信で差し込んでいますが、マップデータが変更された時だけ実行すればいいので頻度が低く問題になりません。されど、即反応して欲しいフェーダー操作の情報は違ってきます。データをどう扱うか、どの位置で処理するか、ちょっと難しくなってきます。
フリーフェーダーだけなら特別なIPアドレス(例えば127.0.0.1)を用いた特別な経路でデータを取り込んでArt-Netと同列に処理する方法もありますが、スタックフェーダーにするにはちょっと無理があるように思ったりします。
ただ、これらのフェーダーはバックアップ的な意味合いが強いので反応がやや遅くてもいいかもしれません。これが許されるならプロセス間通信でデータを差し込んでもいいでしょう。
次のステップに入る前にここは片付けておかないといけません。
追記
スタックフェーダーの方法はアイデアが出ました。Art-Netの入力を記憶します。ただし、記憶するユニバースなりスロットを指定出来ないとディマー以外の動作を邪魔することがあるので一種のフィルターが必要です。フィルターがあればフリーフェーダー的にも機能します。排他的ではなくHTPミックスになりますが、この方がいいでしょう。
操作としては、記憶したい状態でスタックフェーダーとユニバースやスロットを指定してストアします。ユニバースやスロットが無指定ならすべてを記憶です。
#Python #[Art-Net]
RaspberryPiのpythonでSPIで使うためのライブラリspidevの本家はこちら。
本家とは違いますが、こちらのサイトはRapberryPiのSPIについてよくまとめられています。ロシア語なんで原文のままではちっともわかりませんが、本家を読んでもわからなかったことがここで解決します。翻訳して転載したらすごく参考になるかも。
一見簡素な内容ですが、SPIの何たるかはこのサイトがわかりやすいかも。SPIには４つのモードがありますが、その違いを分かりやすく書いてくれている資料が少なくて困っていたところ、このサイトを読んで理解できました。シリアル通信に何の知識も無い人に向けた資料ではありませんが、UARTやI2CはわかるけどSPIがイマイチなぁ～って人にはお勧めです。SPIは少し独特な考え方を持っていますが、そのツボ処だけ簡潔に抽出しています。私は、マイコン全般の教科書と言ってもいいPICのマニュアルを読んでもSPIがどうしても理解できなかったのですが、このサイトを参考にPICのマニュアルを読み直したところ「なるほどー！」となりました。
#RaspberryPi #[Art-Net]
本家とは違いますが、こちらのサイトはRapberryPiのSPIについてよくまとめられています。ロシア語なんで原文のままではちっともわかりませんが、本家を読んでもわからなかったことがここで解決します。翻訳して転載したらすごく参考になるかも。
一見簡素な内容ですが、SPIの何たるかはこのサイトがわかりやすいかも。SPIには４つのモードがありますが、その違いを分かりやすく書いてくれている資料が少なくて困っていたところ、このサイトを読んで理解できました。シリアル通信に何の知識も無い人に向けた資料ではありませんが、UARTやI2CはわかるけどSPIがイマイチなぁ～って人にはお勧めです。SPIは少し独特な考え方を持っていますが、そのツボ処だけ簡潔に抽出しています。私は、マイコン全般の教科書と言ってもいいPICのマニュアルを読んでもSPIがどうしても理解できなかったのですが、このサイトを参考にPICのマニュアルを読み直したところ「なるほどー！」となりました。
#RaspberryPi #[Art-Net]
Art-Netの受送信がまとまったので、SPI通信の復習を始めました。人の操作部も大事ですが、ドライバレベルの繰り返し処理が成り立たなければ始まりません。
SPIは受信ハードウェアが無くても送信動作は可能ですから、ソフトウェア的に処理の負荷がかかる様にして試すのは重要です。
SPI通信を使うのはRaspberryPiから複数のDMXを出力する為です。RaspberryPiにはシリアルポートがありますが望む数はありません。何かしらの方法で拡張しなければなりませんが、私が扱える方法で組むならPICをフロントエンドにして数を増やしますので、PICと通信するのにSPIを使います。
SPIがどんな通信かは諸兄達に任せますが、RspberryPiでもPICでも扱えて複数のDMXを扱うのに十分な速度を持った通信です。
RaspberryPiにおいては、SPIを扱うハードウェアモジュールが搭載されているためにソフトウェアには負担がかかりませんので、周辺デバイスとの簡素な高速通信としてとても有効です。
#RaspberryPi #[Art-Net]
SPIは受信ハードウェアが無くても送信動作は可能ですから、ソフトウェア的に処理の負荷がかかる様にして試すのは重要です。
SPI通信を使うのはRaspberryPiから複数のDMXを出力する為です。RaspberryPiにはシリアルポートがありますが望む数はありません。何かしらの方法で拡張しなければなりませんが、私が扱える方法で組むならPICをフロントエンドにして数を増やしますので、PICと通信するのにSPIを使います。
SPIがどんな通信かは諸兄達に任せますが、RspberryPiでもPICでも扱えて複数のDMXを扱うのに十分な速度を持った通信です。
RaspberryPiにおいては、SPIを扱うハードウェアモジュールが搭載されているためにソフトウェアには負担がかかりませんので、周辺デバイスとの簡素な高速通信としてとても有効です。
#RaspberryPi #[Art-Net]
オフですが、用事が早く終わったのでArt-Netを書き書き。
ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
とりあえずこんなもんかな。
追記
送信元を切り替える動作も確認しました。
まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。
#Python #[Art-Net]
ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
とりあえずこんなもんかな。
追記
送信元を切り替える動作も確認しました。
まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。
#Python #[Art-Net]
Art-Netパッチは一番の課題をクリアしたワケです。
規格書を翻訳するところから始まって４ヶ月間、ヒマが無くても考え続けてきましたから、嬉しいと言えば嬉しいですが、肩の荷が下りてホッとした気持ちが強いです。
予想外の何かは残っていると思いますが、一番大きな山を越えたのかな。
今後はimport出来るライブラリとしてまとめ上げ、先日基板を作ったSPI-DMXの試作です。
ライブラリにするのはそれほど難しくありません。動作試験用に書いたmainを機能別に関数化して外から呼べるようにするだけです。
SPI-DMXは、Art-Netパッチに組み込むか、別の装置としてArt-Netデコーダにするか、試作しながら考えたいと思います。RaspberryPiのSPIで大きなデータを扱ったことがないので、Art-Netパッチに組み入れられるかわからんのです。
最終的な装置にまとめ上げるには筐体の製作もあります。簡単そうで難しい電源の入り切りや停電対策などもあります。
まだまだやらねばならないことが多く、主機能が一応動いたからと喜んでもいられんのです。
近々の目標は、最低限の設定操作が出来るところまで作ってDMX-Delayをリクエストしてくださったプランナーさんに主機能を確認して頂くことです。望まれているニュアンスで遅れるかが最も大事ですから。
ベニヤ板に基板やモジュールをネジ止めした姿での確認になりそうですが、中身が決まらないと筐体の設計は出来ませんのでよいのです。
願わくば、Ｐ社のＷ君にも確認してもらいたいなぁ～(笑
#Python #[Art-Net]
規格書を翻訳するところから始まって４ヶ月間、ヒマが無くても考え続けてきましたから、嬉しいと言えば嬉しいですが、肩の荷が下りてホッとした気持ちが強いです。
予想外の何かは残っていると思いますが、一番大きな山を越えたのかな。
今後はimport出来るライブラリとしてまとめ上げ、先日基板を作ったSPI-DMXの試作です。
ライブラリにするのはそれほど難しくありません。動作試験用に書いたmainを機能別に関数化して外から呼べるようにするだけです。
SPI-DMXは、Art-Netパッチに組み込むか、別の装置としてArt-Netデコーダにするか、試作しながら考えたいと思います。RaspberryPiのSPIで大きなデータを扱ったことがないので、Art-Netパッチに組み入れられるかわからんのです。
最終的な装置にまとめ上げるには筐体の製作もあります。簡単そうで難しい電源の入り切りや停電対策などもあります。
まだまだやらねばならないことが多く、主機能が一応動いたからと喜んでもいられんのです。
近々の目標は、最低限の設定操作が出来るところまで作ってDMX-Delayをリクエストしてくださったプランナーさんに主機能を確認して頂くことです。望まれているニュアンスで遅れるかが最も大事ですから。
ベニヤ板に基板やモジュールをネジ止めした姿での確認になりそうですが、中身が決まらないと筐体の設計は出来ませんのでよいのです。
願わくば、Ｐ社のＷ君にも確認してもらいたいなぁ～(笑
#Python #[Art-Net]