電装工芸日記
- 舞台照明機器の製作とか -
タグ「Python」を含む投稿［119件］（9ページ目）
ちょっと忙しかった今月もヒト段落。
本業があるのは有難いことですが、訛りきった感覚と体では押っ付けるのが大変でした。
良くも悪くもしばらくヒマです。
４月は例年ヒマですから、コロナが収束傾向にあっても増える元がありません。
そんなワケでArt-Netパッチを進めます。
まずは入力部を手直しして複数の送信機への対応です。結果的にHTPミキサーになるのですが、間違って複数を接続しても破綻しない様にすることが目的です。入力部を出来るだけ無駄なく丁寧に作ることが機能を実現する上で重要です。
あとは、人が操作する部分を後付けで作っても無理が出ない様にしておくことです。主機能と操作部を完全に切り離し、指示経路を一本化しつつ出来るだけシンプルにします。経路にqueueを使うかsocketを使うか考えていますが、queueの方が速度が出ますしpythonの変数のまま送受信できるメリットがありますが、操作部との通信には速度を求めていないのでscoketにした方がいいかもしれません。socketにしておけば操作部を別なデバイスにすることも可能なのでいいかなと。書いたことも調べたこともありませんが、iPadなどを操作部にすることも可能だと思うのです。
#Python #[Art-Net]
本業があるのは有難いことですが、訛りきった感覚と体では押っ付けるのが大変でした。
良くも悪くもしばらくヒマです。
４月は例年ヒマですから、コロナが収束傾向にあっても増える元がありません。
そんなワケでArt-Netパッチを進めます。
まずは入力部を手直しして複数の送信機への対応です。結果的にHTPミキサーになるのですが、間違って複数を接続しても破綻しない様にすることが目的です。入力部を出来るだけ無駄なく丁寧に作ることが機能を実現する上で重要です。
あとは、人が操作する部分を後付けで作っても無理が出ない様にしておくことです。主機能と操作部を完全に切り離し、指示経路を一本化しつつ出来るだけシンプルにします。経路にqueueを使うかsocketを使うか考えていますが、queueの方が速度が出ますしpythonの変数のまま送受信できるメリットがありますが、操作部との通信には速度を求めていないのでscoketにした方がいいかもしれません。socketにしておけば操作部を別なデバイスにすることも可能なのでいいかなと。書いたことも調べたこともありませんが、iPadなどを操作部にすることも可能だと思うのです。
#Python #[Art-Net]
SPI-DMXを使うにはSPIに渡す配列に少し工夫が必要です。
レベル値の２次元配列[ユニバース,スロットアドレス]を１次元配列[スロットアドレス]に変換してSPIに渡すのですが、<ユニバースnのスロットx>を<n.x>と書くなら、
[<0.1>,<1.1>,<2.1>,・・・,<6.1>,<7.1>,<0.2>,<1.2>,<2.2>,・・・,<6.2>,<7.2>,
・・・,
<0.512>,<1.512>,<2.512>,・・・,<6.512>,<7.512>]
としなければなりません。[ユニバース,スロットアドレス]だったものを[スロットアドレス,ユニバース]の順番で１次元配列にするのです。
ちなみに元のスロットデータは
[[<0.1>,<0.2>,<0.3>,・・・,<0.512>],
[<1.1>,<1.2>,<1.3>,・・・,<1.512>],
・・・,
[<7.1>,<7.2>,<7.3>,・・・,<7.512>]]
こんな２次元配列です。
元のスロットデータをout_routeとし、SPIに渡すスロットデータをout_spi_arrayとするなら
out_spi_array = out_route.ravel( 'F' )
あれま、たった一行。
カッコ内の'F'はravelの動作モードを表すものらしい。
これまたPythonの繰り返しコマンドを用いずにnumpyだけで変換出来てしまった。
numpy素晴らしい。
#Python #[Art-Net]
レベル値の２次元配列[ユニバース,スロットアドレス]を１次元配列[スロットアドレス]に変換してSPIに渡すのですが、<ユニバースnのスロットx>を<n.x>と書くなら、
[<0.1>,<1.1>,<2.1>,・・・,<6.1>,<7.1>,<0.2>,<1.2>,<2.2>,・・・,<6.2>,<7.2>,
・・・,
<0.512>,<1.512>,<2.512>,・・・,<6.512>,<7.512>]
としなければなりません。[ユニバース,スロットアドレス]だったものを[スロットアドレス,ユニバース]の順番で１次元配列にするのです。
ちなみに元のスロットデータは
[[<0.1>,<0.2>,<0.3>,・・・,<0.512>],
[<1.1>,<1.2>,<1.3>,・・・,<1.512>],
・・・,
[<7.1>,<7.2>,<7.3>,・・・,<7.512>]]
こんな２次元配列です。
元のスロットデータをout_routeとし、SPIに渡すスロットデータをout_spi_arrayとするなら
out_spi_array = out_route.ravel( 'F' )
あれま、たった一行。
カッコ内の'F'はravelの動作モードを表すものらしい。
これまたPythonの繰り返しコマンドを用いずにnumpyだけで変換出来てしまった。
numpy素晴らしい。
#Python #[Art-Net]
Art-Netは入口の処理がまとまったので肝心のパッチ処理を考えています。
パッチとは入口と出口を１対多の関係で結びつける処理です。基本的な考え方は簡単ですがどう処理したものか。
と、言いますのも、処理の回数が多いので、１回１回の処理を限りなく軽くしないと間に合いません。
単純に考えればfor文を使ってスロット単位に移し替えをすればいいのですが、これではちょいと遅いようです。
何か無いかと調べたところnumpyに良い処理方法がありました。
「ファンシーインデックス」と呼ばれる方法です。
numpyの配列はインデックスで内容を参照できますが、インデックスに配列を使うことも出来、これを「ファンシーインデックス」と呼ぶようです。
パッチにおいては、出力側が参照する入口側のスロットのインデックスを配列にして使います(パッチマップ)。
一番単純な入力１ユニバース-出力１ユニバースを処理するとして、
入口側の配列が５スロットある場合
input = np.array( [ 11, 22, 30, 44, 50 ] )
とし、
これに対するパッチマップを
map = np.array( [ 0, 3, 4, 2, 2, 3, 1 ] )
とした場合、
patched_values = input[ map ] ※ 内部的には input[ [ 0, 3, 4, 2, 2, 3, 1 ] ] と同意
print( patched_values )
>>> [ 11 44 50 30 30 44 22 ]
インデックスの基底数がゼロなので注意が必要ですが、mapに記載されたインデックスでinputを参照し、配列としてoutputを得られます。
入力のスタック(input_stack)が[ delay, route, address ]の３次元配列の場合は、出力側スロット視点で次の３つの配列をインデックスにします。
delay_index_map：スロットごとのディレイレイヤーのインデックスを表すインデックスの配列 (取り扱いスロット数分・現在のカレントindexからオフセット済み)
※ delay_index_map = ( <ディレイレイヤーのスタック数> + <現在のカレントindex> - delay_map ) % <ディレイレイヤーのスタック数>
in_route_map：入力スロットのルートを表すインデックスの配列 (取り扱いスロット数分)
in_slot_map：入力スロットのアドレスを表すインデックスの配列 (取り扱いスロット数分)
※ in_route_mapとin_slot_mapを合わせてpatch_mapとなる。
とすると、
patched_values = input_stack[ [ delay_index_map, in_route_map, in_slot_map ] ]
patched_values は取り扱いスロット数分の１次元配列です。
ディレイの処理も含めて１行のコマンドで出力値を得られます。素晴らしい。
ここでスロットデータが１次元配列になるので、ここから先、出力ポートに渡すまではスロットを１本の通し番号で扱った方が良さそう。
同様の方法でカーブプロファイル変換も出来ます。
カーブプロファイル(curve_profile_values)を 変換後レベル値[ プロファイルナンバー, 元レベル値 ] 、カーブプロファイルマップ(curve_profile_map)をプロファイルナンバー[ スロットアドレス ]とし、変換した配列を curve_converted_values とすると。
curve_converted_values = curve_profile_values[ curve_profile_map, patched_values ]
※ len( curve_profile_map ) == len( patched_values ) がTrueなこと。
curve_converted_valuesを出力ルートとスロットアドレスの２次元配列にするなら、
output_values = curve_converted_values.reshape( <ルートの本数>, 512 )
※ <ルートの本数> × 512 = 取り扱いスロット総数 であること
コマンドが少ないから処理時間が短いとは限りませんが、少なくともfor文を用いた処理より軽いことは間違いありません。
numpy素晴らしい。
#Python #[Art-Net]
パッチとは入口と出口を１対多の関係で結びつける処理です。基本的な考え方は簡単ですがどう処理したものか。
と、言いますのも、処理の回数が多いので、１回１回の処理を限りなく軽くしないと間に合いません。
単純に考えればfor文を使ってスロット単位に移し替えをすればいいのですが、これではちょいと遅いようです。
何か無いかと調べたところnumpyに良い処理方法がありました。
「ファンシーインデックス」と呼ばれる方法です。
numpyの配列はインデックスで内容を参照できますが、インデックスに配列を使うことも出来、これを「ファンシーインデックス」と呼ぶようです。
パッチにおいては、出力側が参照する入口側のスロットのインデックスを配列にして使います(パッチマップ)。
一番単純な入力１ユニバース-出力１ユニバースを処理するとして、
入口側の配列が５スロットある場合
input = np.array( [ 11, 22, 30, 44, 50 ] )
とし、
これに対するパッチマップを
map = np.array( [ 0, 3, 4, 2, 2, 3, 1 ] )
とした場合、
patched_values = input[ map ] ※ 内部的には input[ [ 0, 3, 4, 2, 2, 3, 1 ] ] と同意
print( patched_values )
>>> [ 11 44 50 30 30 44 22 ]
インデックスの基底数がゼロなので注意が必要ですが、mapに記載されたインデックスでinputを参照し、配列としてoutputを得られます。
入力のスタック(input_stack)が[ delay, route, address ]の３次元配列の場合は、出力側スロット視点で次の３つの配列をインデックスにします。
delay_index_map：スロットごとのディレイレイヤーのインデックスを表すインデックスの配列 (取り扱いスロット数分・現在のカレントindexからオフセット済み)
※ delay_index_map = ( <ディレイレイヤーのスタック数> + <現在のカレントindex> - delay_map ) % <ディレイレイヤーのスタック数>
in_route_map：入力スロットのルートを表すインデックスの配列 (取り扱いスロット数分)
in_slot_map：入力スロットのアドレスを表すインデックスの配列 (取り扱いスロット数分)
※ in_route_mapとin_slot_mapを合わせてpatch_mapとなる。
とすると、
patched_values = input_stack[ [ delay_index_map, in_route_map, in_slot_map ] ]
patched_values は取り扱いスロット数分の１次元配列です。
ディレイの処理も含めて１行のコマンドで出力値を得られます。素晴らしい。
ここでスロットデータが１次元配列になるので、ここから先、出力ポートに渡すまではスロットを１本の通し番号で扱った方が良さそう。
同様の方法でカーブプロファイル変換も出来ます。
カーブプロファイル(curve_profile_values)を 変換後レベル値[ プロファイルナンバー, 元レベル値 ] 、カーブプロファイルマップ(curve_profile_map)をプロファイルナンバー[ スロットアドレス ]とし、変換した配列を curve_converted_values とすると。
curve_converted_values = curve_profile_values[ curve_profile_map, patched_values ]
※ len( curve_profile_map ) == len( patched_values ) がTrueなこと。
curve_converted_valuesを出力ルートとスロットアドレスの２次元配列にするなら、
output_values = curve_converted_values.reshape( <ルートの本数>, 512 )
※ <ルートの本数> × 512 = 取り扱いスロット総数 であること
コマンドが少ないから処理時間が短いとは限りませんが、少なくともfor文を用いた処理より軽いことは間違いありません。
numpy素晴らしい。
#Python #[Art-Net]
Art-Netを受信してから一時保存する流れ
● Art-Netの受信・・・タイムアウトしたらすべての受信情報を初期化する
● 受信日時の取得
● 受信したバイナリをデコード
● 対象ユニバースか確認
● ルートIDを取得
● 送信元のIDを取得・新規送信元なら保存し送信元IDを取得
● 送信元の最終受信日時を上書き保存
● 送信元,ルートの最終受信日時を上書き保存
● 送信元,ルートで受信値を上書き保存(必ず512スロットで保存)
タイムアウト処理・・・0.2～0.5秒毎
● 送信元のタイムアウトを確認・・・タイムアウトしていたら送信元からの受信情報を初期化する
● ユニバースのタイムアウトを確認・・・タイムアウトしていたらユニバースをゼロデータにする
次工程からの読み出し要求への返信
● 送信元,ルートで保存した受信値から最大値を取り出す
● 返信
といった感じで、細かいコマンド処理とアルゴリズムが見えてきましたが、本業が忙しくなってソースを書くことが出来ません。
#Python #[Art-Net]
● Art-Netの受信・・・タイムアウトしたらすべての受信情報を初期化する
● 受信日時の取得
● 受信したバイナリをデコード
● 対象ユニバースか確認
● ルートIDを取得
● 送信元のIDを取得・新規送信元なら保存し送信元IDを取得
● 送信元の最終受信日時を上書き保存
● 送信元,ルートの最終受信日時を上書き保存
● 送信元,ルートで受信値を上書き保存(必ず512スロットで保存)
タイムアウト処理・・・0.2～0.5秒毎
● 送信元のタイムアウトを確認・・・タイムアウトしていたら送信元からの受信情報を初期化する
● ユニバースのタイムアウトを確認・・・タイムアウトしていたらユニバースをゼロデータにする
次工程からの読み出し要求への返信
● 送信元,ルートで保存した受信値から最大値を取り出す
● 返信
といった感じで、細かいコマンド処理とアルゴリズムが見えてきましたが、本業が忙しくなってソースを書くことが出来ません。
#Python #[Art-Net]
Art-Netを受信した後、送信元別だった受信値をミックス(HTP)する方法。
numpy.maxを用いれば簡単
受信値を３次元のnumpy.arrayで保存します。
３次元のnumpy.arrayはエクセルでイメージするとわかりやすいかなと。
１スロットの受信値は0-255の数値で、これが横方向(行)に512個並んだ状態をユニバースとします。
これをルート別に縦方向(列)で並べます。ここまでは縦横の１枚のシートです。
この１枚を送信元別のシートとし、レイヤーとして重ねます。もちろん、スロットアドレスとルートは同様にします。
あとはレイヤーを串刺しで最大値を得ればHTPでミックスしたルートとスロットの２次元のnumpu.arrayを得られます。
numpyをnpの名前でimportし、３次元のnumpy.arrayをan_cache_senders_route、最大値の２次元のnumpy.arrayをan_cache_htpとすると次の様になります。
an_cache_htp = np.max( an_cache_senders_route, axis=0 )
こんな感じの１行で計算出来ます。axis=0は最大値を得る次元方向の指示です。３次元なら、axis=2は横で、axis=1は縦で、axis=0は奥行という指示です。
以下、ちょいとオレメモ
受信値、付随するデータ
an_bytes 受信したArt-Netパケットのデータ(type=bytes、別途デコード必要)
an_sender_ipaddress 受信したArt-Netパケットの送信元IPアドレス(type=string、４つのドット切り10進数 IPv4の一般的な表記)
an_received_datetime 受信された時点でdatetime.datetime.now()により取得した日時(type=datetime.datetime)
処理の処理を指示するデータ
an_universes2route 対象ユニバースの１次元配列 ( Net, Subnet, Universe )[ ルート ]
受信値を処理、管理するデータ
an_ipaddress_senders 送信元のIPアドレスの１次元配列 IPアドレス [ 送信元 ]
an_datetime_senders 送信元ごとの最終受信日時の１次元配列 最終受信日時 [ 送信元 ]
an_datetime_senders_route 送信元ごとにルートの最終受信日時の２次元配列 最終受信日時 [ 送信元, ルート ]
an_cache_senders_route 送信元とルートごとに受信値を保存する３次元配列 受信値 [ 送信元, ルート, スロットアドレス ]
an_cache_htp 次の処理へ渡す処理済み受信値の２次元配列 受信値 [ ルート, スロットアドレス ]
※ [ ]内はインデックスの要素([３次元目,２次元目,１次元目])
※ 同名のindexは同じ値になるように設定
＃an_ipaddress_senders から an_sender_ipaddress と同じIPアドレスを持つ[ 送信元 ]のindex配列を得る
list( zip( *np.where( an_ipaddress_senders == an_sender_ipaddress ) ) )
※ 受信した際に重複しない様に送信元情報を保存してインデックスを発行し、送信元別に日時と受信値を保存するために使う。
※ ただし、対象のユニバースを送って来ない送信元は無いものとする。早い段階でフィルタしないと後が面倒。
＃an_datetime_senders から現在日時より１秒以上前の日時を持つ[ 送信元 ]のindexの配列を得る
list( zip( *np.where( an_datetime_senders < ( datetime.datetime.now() - datetime.timedelta( seconds=1 ) ) ) ) )
※ 送信元の存在を確認するために使う。１秒間受信が無い送信元は無いものとする。
＃an_datetime_senders_route から現在日時より１秒以上前の日時を持つ[ 送信元, ルート ]のindexの配列を得る
list( zip( *np.where( an_datetime_senders_route < ( datetime.datetime.now() - datetime.timedelta( seconds=1 ) ) ) ) )
※ ユニバースの存在を確認するために使う。１秒間受信が無いユニバース(=送信元,ルート)はゼロデータにする。
#Python #[Art-Net]
numpy.maxを用いれば簡単
受信値を３次元のnumpy.arrayで保存します。
３次元のnumpy.arrayはエクセルでイメージするとわかりやすいかなと。
１スロットの受信値は0-255の数値で、これが横方向(行)に512個並んだ状態をユニバースとします。
これをルート別に縦方向(列)で並べます。ここまでは縦横の１枚のシートです。
この１枚を送信元別のシートとし、レイヤーとして重ねます。もちろん、スロットアドレスとルートは同様にします。
あとはレイヤーを串刺しで最大値を得ればHTPでミックスしたルートとスロットの２次元のnumpu.arrayを得られます。
numpyをnpの名前でimportし、３次元のnumpy.arrayをan_cache_senders_route、最大値の２次元のnumpy.arrayをan_cache_htpとすると次の様になります。
an_cache_htp = np.max( an_cache_senders_route, axis=0 )
こんな感じの１行で計算出来ます。axis=0は最大値を得る次元方向の指示です。３次元なら、axis=2は横で、axis=1は縦で、axis=0は奥行という指示です。
以下、ちょいとオレメモ
受信値、付随するデータ
an_bytes 受信したArt-Netパケットのデータ(type=bytes、別途デコード必要)
an_sender_ipaddress 受信したArt-Netパケットの送信元IPアドレス(type=string、４つのドット切り10進数 IPv4の一般的な表記)
an_received_datetime 受信された時点でdatetime.datetime.now()により取得した日時(type=datetime.datetime)
処理の処理を指示するデータ
an_universes2route 対象ユニバースの１次元配列 ( Net, Subnet, Universe )[ ルート ]
受信値を処理、管理するデータ
an_ipaddress_senders 送信元のIPアドレスの１次元配列 IPアドレス [ 送信元 ]
an_datetime_senders 送信元ごとの最終受信日時の１次元配列 最終受信日時 [ 送信元 ]
an_datetime_senders_route 送信元ごとにルートの最終受信日時の２次元配列 最終受信日時 [ 送信元, ルート ]
an_cache_senders_route 送信元とルートごとに受信値を保存する３次元配列 受信値 [ 送信元, ルート, スロットアドレス ]
an_cache_htp 次の処理へ渡す処理済み受信値の２次元配列 受信値 [ ルート, スロットアドレス ]
※ [ ]内はインデックスの要素([３次元目,２次元目,１次元目])
※ 同名のindexは同じ値になるように設定
＃an_ipaddress_senders から an_sender_ipaddress と同じIPアドレスを持つ[ 送信元 ]のindex配列を得る
list( zip( *np.where( an_ipaddress_senders == an_sender_ipaddress ) ) )
※ 受信した際に重複しない様に送信元情報を保存してインデックスを発行し、送信元別に日時と受信値を保存するために使う。
※ ただし、対象のユニバースを送って来ない送信元は無いものとする。早い段階でフィルタしないと後が面倒。
＃an_datetime_senders から現在日時より１秒以上前の日時を持つ[ 送信元 ]のindexの配列を得る
list( zip( *np.where( an_datetime_senders < ( datetime.datetime.now() - datetime.timedelta( seconds=1 ) ) ) ) )
※ 送信元の存在を確認するために使う。１秒間受信が無い送信元は無いものとする。
＃an_datetime_senders_route から現在日時より１秒以上前の日時を持つ[ 送信元, ルート ]のindexの配列を得る
list( zip( *np.where( an_datetime_senders_route < ( datetime.datetime.now() - datetime.timedelta( seconds=1 ) ) ) ) )
※ ユニバースの存在を確認するために使う。１秒間受信が無いユニバース(=送信元,ルート)はゼロデータにする。
#Python #[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
ユニバース単位の試験的な物ですが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]
先日書いた謎のオレメモ
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]