電装工芸日記
- 舞台照明機器の製作とか -
全年全月6日の投稿［30件］（2ページ目）
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
DI-1MUSEはコンデンサを替えて24時間経過。
音が鈍ったというか、明瞭感が弱くなっています。コンデンサを替える前と大差ない印象。
先行して替えたコンデンサでも24時間経過で一度鈍くなり48時間経過で戻る現象がありました。コンデンサのエージングはそういうものなのかもしれませんが気分は萎えます。
追記
確実ではないのですが、ピンクノイズを当てた直後は音が鈍るものの、通常の音源を数時間当てると音が戻るようです。通常の音源を３時間くらい当てて再チェックしたところ、昨日のイイ感じに戻っていました。
この話だけですとピンクノイズは余計なことに感じますが、ピンクノイズを当てて通常音源を当てると明瞭なだけでなくまろやかさも加わりますので、エージングには良いように思います。
音源100時間、ピンクノイズ100時間、音源100時間の設定で続けています。現在ピンクノイズ30時間。
#音の世界
音が鈍ったというか、明瞭感が弱くなっています。コンデンサを替える前と大差ない印象。
先行して替えたコンデンサでも24時間経過で一度鈍くなり48時間経過で戻る現象がありました。コンデンサのエージングはそういうものなのかもしれませんが気分は萎えます。
追記
確実ではないのですが、ピンクノイズを当てた直後は音が鈍るものの、通常の音源を数時間当てると音が戻るようです。通常の音源を３時間くらい当てて再チェックしたところ、昨日のイイ感じに戻っていました。
この話だけですとピンクノイズは余計なことに感じますが、ピンクノイズを当てて通常音源を当てると明瞭なだけでなくまろやかさも加わりますので、エージングには良いように思います。
音源100時間、ピンクノイズ100時間、音源100時間の設定で続けています。現在ピンクノイズ30時間。
#音の世界
今後はLTCをMTCに変換する方法も考えましょう。
LTCをバイトデータとして受信し、MTCのパケットに書き直して31,250bpsのUARTで送出すればMTCになります。
オレメモです。
PICには「変化割込み」と呼ばれるI/Oピンの入力が変化すると割込みが発生する機能があります。これとタイマーを組み合わせれば波長の計測が可能です。
PICのクロックを32MHzにした場合、LTCの波長は命令ステップ(Fosc/4)換算でビットが１なら1,666から2,083、０なら倍の3,332から4,166です。誤差10%としても１の最大値(2,291)と０の最小値(3,029)は被りませんしグレーゾーンも広いので、波長の判別はfpsの種類に関係なく可能です。fpsやフォーマットの種類はLTCのデータに書かれているので計測した波長から判断する必要はありません。
差動バイフェーズのビットは短い波長が２つ続けば１、長い波長が１つで０です。ビットデータが取れたら80bitのシフトレジスタに入れていきます。短い波長は必ず２回続きますから、長い波長の直前の短い波長が奇数回ならエラーとして仕切り直しです。80bitのシフトレジスタの末尾16bitにシンクワードが認められれば正常なLTCパケットが取得できたことになります。
LTCパケットが取得出来ればMTCパケットを作り、入力されたLTCに基づいたタイミングで31,250bpsに設定したPICのUARTから送出します。後は電気的にMIDIにすればMTCです。
必ず３フレーム遅れますが、欲しいのは絶対値ではなく相対値ですからいいかなと。
プログラムが求めるメモリサイズ次第ですが、8pinの12F1822で作る予定です。
追記
LTCにはfpsフォーマットを記載する領域はありません。訂正します。NDF/DFは記載されます。
fpsフォーマットをデータに記載するのはMTCです。
ですので、LTCの場合は波長からfpsフォーマットを推測します。
#PIC #タイムコード
LTCをバイトデータとして受信し、MTCのパケットに書き直して31,250bpsのUARTで送出すればMTCになります。
オレメモです。
PICには「変化割込み」と呼ばれるI/Oピンの入力が変化すると割込みが発生する機能があります。これとタイマーを組み合わせれば波長の計測が可能です。
PICのクロックを32MHzにした場合、LTCの波長は命令ステップ(Fosc/4)換算でビットが１なら1,666から2,083、０なら倍の3,332から4,166です。誤差10%としても１の最大値(2,291)と０の最小値(3,029)は被りませんしグレーゾーンも広いので、波長の判別はfpsの種類に関係なく可能です。
差動バイフェーズのビットは短い波長が２つ続けば１、長い波長が１つで０です。ビットデータが取れたら80bitのシフトレジスタに入れていきます。短い波長は必ず２回続きますから、長い波長の直前の短い波長が奇数回ならエラーとして仕切り直しです。80bitのシフトレジスタの末尾16bitにシンクワードが認められれば正常なLTCパケットが取得できたことになります。
LTCパケットが取得出来ればMTCパケットを作り、入力されたLTCに基づいたタイミングで31,250bpsに設定したPICのUARTから送出します。後は電気的にMIDIにすればMTCです。
必ず３フレーム遅れますが、欲しいのは絶対値ではなく相対値ですからいいかなと。
プログラムが求めるメモリサイズ次第ですが、8pinの12F1822で作る予定です。
追記
LTCにはfpsフォーマットを記載する領域はありません。訂正します。NDF/DFは記載されます。
fpsフォーマットをデータに記載するのはMTCです。
ですので、LTCの場合は波長からfpsフォーマットを推測します。
#PIC #タイムコード
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の小さなヒーターがあったので、これを庫内に入れて温度リレーで動かすことにしました。温度リレーはある仕事のために数十個買った際の予備があります。温度の精度はそれほど必要ないのでこんな安物の組み合わせでもいいかなと。
ヒーターは２日後に入荷予定です。
#ガチ工作