電装工芸日記
- 舞台照明機器の製作とか -
全年全月6日の投稿［27件］（2ページ目）
2023年5月 この範囲を時系列順で読む この範囲をファイルに出力する
今週末はバレエ教室の発表会です。
舞台監督でも照明でもなく道具屋です。ガチ公演ではありませんから、リノを敷いてジョーゼットを主にした飾りを休憩転換するだけで忙しくはありません。
以前も書いたような気がするのですが、リノの掃除方法をオレメモ。
基本は水拭きですが、重曹を少し入れると松ヤニやスモークオイルが落ちやすい様です。１リットル当たり大さじスリ切り１杯の割合です。いわゆる床掃除に使う濃度に比べたら薄いのですが、このくらいだと乾いても白く粉を噴きませんので中和拭きをしなくてもいいかなと。施工は農薬散布器で軽く噴霧して乾いたモップで拭きます。散布量の目安はリノを2-3本拭いてモップがやや湿る程度。乾くまでは少しヌルヌルしますが、乾けば本来のグリップに戻ります。松ヤニやオイルの付着が気にならなければ重曹の使用は３回に１回くらいにした方が良さそうでもあります。
スモークオイルが落ちない場合は重曹の濃度を３倍程度にしてオイルを落とし、クエン酸溶液で中和拭き、水で仕上げ拭きと進めます。
#本業
舞台監督でも照明でもなく道具屋です。ガチ公演ではありませんから、リノを敷いてジョーゼットを主にした飾りを休憩転換するだけで忙しくはありません。
以前も書いたような気がするのですが、リノの掃除方法をオレメモ。
基本は水拭きですが、重曹を少し入れると松ヤニやスモークオイルが落ちやすい様です。１リットル当たり大さじスリ切り１杯の割合です。いわゆる床掃除に使う濃度に比べたら薄いのですが、このくらいだと乾いても白く粉を噴きませんので中和拭きをしなくてもいいかなと。施工は農薬散布器で軽く噴霧して乾いたモップで拭きます。散布量の目安はリノを2-3本拭いてモップがやや湿る程度。乾くまでは少しヌルヌルしますが、乾けば本来のグリップに戻ります。松ヤニやオイルの付着が気にならなければ重曹の使用は３回に１回くらいにした方が良さそうでもあります。
スモークオイルが落ちない場合は重曹の濃度を３倍程度にしてオイルを落とし、クエン酸溶液で中和拭き、水で仕上げ拭きと進めます。
#本業
2023年4月 この範囲を時系列順で読む この範囲をファイルに出力する
PythonでVLCライブラリを使えば映像や音声に関して今やりたいことは全て出来そうです。
VLCは映像や音声の類は何でも再生出来る便利なアプリですが、コマンドラインでも使えるし、プログラムを書くためのライブラリとしても機能します。Windowsはもちろん、MacでもLinuxでも動きます。
懸案の再生時間の取得ですが、再生のためにはファイルをVLCモジュールに読み込んでインスタンスにするのですが、インスタンスからget_time()を取ると現在の再生ポジションをmsecの値で得られるようです。得た値の扱いはよく考えねばなければなりませんが、途中から再生しても適切なタイムコードを出せそうです。
ついでにTASCAM系のプレイバックも協調動作させますか。比較的単純なシリアル信号で動きますから、CDなどを同時スタート出来ればバックアップになります。
もちろん、PythonのライブラリがあるならC言語のライブラリもあると思われます。Pythonで書いとけばプラットホームを選ばないので、このツールはC言語で書くよりいいのかもしれないけど。
開発する時間がないので当面棚上げですが、ノンビリ研究していきましょう。
追記
C言語のライブラリーはlibvlc、includeは<vlc/vlc.h>だそうです。
映像を表示せず音声だけの出力も明示的に指示出来るようです。
#タイムコード
VLCは映像や音声の類は何でも再生出来る便利なアプリですが、コマンドラインでも使えるし、プログラムを書くためのライブラリとしても機能します。Windowsはもちろん、MacでもLinuxでも動きます。
懸案の再生時間の取得ですが、再生のためにはファイルをVLCモジュールに読み込んでインスタンスにするのですが、インスタンスからget_time()を取ると現在の再生ポジションをmsecの値で得られるようです。得た値の扱いはよく考えねばなければなりませんが、途中から再生しても適切なタイムコードを出せそうです。
ついでにTASCAM系のプレイバックも協調動作させますか。比較的単純なシリアル信号で動きますから、CDなどを同時スタート出来ればバックアップになります。
もちろん、PythonのライブラリがあるならC言語のライブラリもあると思われます。Pythonで書いとけばプラットホームを選ばないので、このツールはC言語で書くよりいいのかもしれないけど。
開発する時間がないので当面棚上げですが、ノンビリ研究していきましょう。
追記
C言語のライブラリーはlibvlc、includeは<vlc/vlc.h>だそうです。
映像を表示せず音声だけの出力も明示的に指示出来るようです。
#タイムコード
試してはいませんが、Linux系で音源を再生するのは簡単っぽいです。
モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな？。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
合間に調べを進めましょう。
目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。
#Ｃ言語 #RaspberryPi
モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな？。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
合間に調べを進めましょう。
目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。
#Ｃ言語 #RaspberryPi
2023年2月 この範囲を時系列順で読む この範囲をファイルに出力する
本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
本業もやらねばなりませんがArtNet-Engineも進めたい。
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
2023年1月 この範囲を時系列順で読む この範囲をファイルに出力する
現場が早く終わったので、開発用のRaspberryPiをノートパソコンのVSCodeと繋いでおきました。ここまでしておけば比較的身軽に開発が出来ます。
本格的に開発を進めましょう。
Ｃ言語でのsocketについて調べてみましたが、PythonのscoketライブラリはＣ言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。
#Ｃ言語 #[Art-Net]
本格的に開発を進めましょう。
Ｃ言語でのsocketについて調べてみましたが、PythonのscoketライブラリはＣ言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。
#Ｃ言語 #[Art-Net]
2022年11月 この範囲を時系列順で読む この範囲をファイルに出力する
久しぶりに３Ｄプリンタを使ったのですが、室温が低すぎてプリントが荒れまくり。
ワーク周辺の気温が摂氏25～30度だといいのですが、プリントするために部屋全体を暖めるのは勿体ない。
幸い３Ｄプリンタはオープンフレームではなくケース式です。amazonさんを覗いたら300wの小さなヒーターがあったので、これを庫内に入れて温度リレーで動かすことにしました。温度リレーはある仕事のために数十個買った際の予備があります。温度の精度はそれほど必要ないのでこんな安物の組み合わせでもいいかなと。
ヒーターは２日後に入荷予定です。
#ガチ工作
ワーク周辺の気温が摂氏25～30度だといいのですが、プリントするために部屋全体を暖めるのは勿体ない。
幸い３Ｄプリンタはオープンフレームではなくケース式です。amazonさんを覗いたら300wの小さなヒーターがあったので、これを庫内に入れて温度リレーで動かすことにしました。温度リレーはある仕事のために数十個買った際の予備があります。温度の精度はそれほど必要ないのでこんな安物の組み合わせでもいいかなと。
ヒーターは２日後に入荷予定です。
#ガチ工作
2022年10月 この範囲を時系列順で読む この範囲をファイルに出力する
こんなんす。ほぼ函の習作。
PSEの壁があるので販売出来ない製品。
全てではないのですが、商用電源を直接入力する機器はPSEに引っかかることが多いのです。
電源モジュールを名目別売りにし、購入者が最終組み立てをしたことにすれば逃れられるって話もありますけど。
#電子工作
PSEの壁があるので販売出来ない製品。
全てではないのですが、商用電源を直接入力する機器はPSEに引っかかることが多いのです。
電源モジュールを名目別売りにし、購入者が最終組み立てをしたことにすれば逃れられるって話もありますけど。
#電子工作
編集うまいなぁ～
#雑談
#雑談
2022年9月 この範囲を時系列順で読む この範囲をファイルに出力する
裸族のパイのUSB-LANアダプタですが、不調の原因が判明。
原因はUSB3.0のA-Aケーブルがクロス結線なことでした。電源は無関係でした。
USBは[RaspberryPi/USB3.0]-[USB3.0/A-A_Cable]-[USB3.0/A-A_KeyStone]-[USB-LAN]と繋いでいますが、ケーブルがクロス結線でキーストーンがストレート結線なのでRaspberryPiに対しUSB-LANアダプタは結線間違いになっていたのです。ケーブルを２本つなぐと正常に動くという摩訶不思議な現象だったので配線を当たったところ判明。
正直、「なんでクロス結線！？」と思いますが、USB3.0のA-Aケーブルはクロス結線が普通でストレートは例外みたいです。
対策は、キーストーンの中身を無理やりクロス結線に変え、クロスからクロスでストレートにしました。
ちなみに、USB3.0/A-Aのクロス結線は・・・
1-1 ※1番ピンから4番ピンはUSB2.0互換
2-2
3-3
4-4
5-8
6-9
7-7
8-5
9-6
です。
USB3.0のメモリを挿して動いたのであまり気にしていませんでしたが、USBメモリは3.0がダメなら2.0に切り替えてしまうみたいです。正確なところはわかりませんけどね。
紆余曲折ありましたが「裸族のパイ」が完成しました。作り方を忘れないウチにもう２台作ってしまいたいけどしばらく無理かなぁ～。
今後、裸族のパイの耐久試験を実施し、大丈夫なら自宅サーバーをコレに切り替えるつもりです。
#サーバー #RaspberryPi
原因はUSB3.0のA-Aケーブルがクロス結線なことでした。電源は無関係でした。
USBは[RaspberryPi/USB3.0]-[USB3.0/A-A_Cable]-[USB3.0/A-A_KeyStone]-[USB-LAN]と繋いでいますが、ケーブルがクロス結線でキーストーンがストレート結線なのでRaspberryPiに対しUSB-LANアダプタは結線間違いになっていたのです。ケーブルを２本つなぐと正常に動くという摩訶不思議な現象だったので配線を当たったところ判明。
正直、「なんでクロス結線！？」と思いますが、USB3.0のA-Aケーブルはクロス結線が普通でストレートは例外みたいです。
対策は、キーストーンの中身を無理やりクロス結線に変え、クロスからクロスでストレートにしました。
ちなみに、USB3.0/A-Aのクロス結線は・・・
1-1 ※1番ピンから4番ピンはUSB2.0互換
2-2
3-3
4-4
5-8
6-9
7-7
8-5
9-6
です。
USB3.0のメモリを挿して動いたのであまり気にしていませんでしたが、USBメモリは3.0がダメなら2.0に切り替えてしまうみたいです。正確なところはわかりませんけどね。
紆余曲折ありましたが「裸族のパイ」が完成しました。作り方を忘れないウチにもう２台作ってしまいたいけどしばらく無理かなぁ～。
今後、裸族のパイの耐久試験を実施し、大丈夫なら自宅サーバーをコレに切り替えるつもりです。
#サーバー #RaspberryPi