電装工芸日記
- 舞台照明機器の製作とか -
全年全月12日の投稿［43件］（2ページ目）
2023年12月 この範囲を時系列順で読む この範囲をファイルに出力する
どこまで本当の話なのか。
本当なら再生不可能エネルギーですね。
つか、意識高い系の白人って表面のキレイごとしか見えないアホなのかな？その昔はアジアやアフリカから奪うことで辻褄を合わせていたけど、今はそれが無理だからアホさ加減が表に出てきたのかな？
無生産な人たちが権力と財力を握ると良くないことになるのは何度も何度も繰り返されてきたことだと思う。白人と華人抜きで世界を再構成するのが最もエコかもしれない。
#雑談
本当なら再生不可能エネルギーですね。
つか、意識高い系の白人って表面のキレイごとしか見えないアホなのかな？その昔はアジアやアフリカから奪うことで辻褄を合わせていたけど、今はそれが無理だからアホさ加減が表に出てきたのかな？
無生産な人たちが権力と財力を握ると良くないことになるのは何度も何度も繰り返されてきたことだと思う。白人と華人抜きで世界を再構成するのが最もエコかもしれない。
#雑談
2023年11月 この範囲を時系列順で読む この範囲をファイルに出力する
2023年10月 この範囲を時系列順で読む この範囲をファイルに出力する
本業が絶賛過密中です。
ちょっくらヘトヘト。
穴あきボードの壁にLED-Barを吊り下げる現場があるのですが、昨年40個作っておいた金具が4個しかない！どうやら捨てられてしまったようです。
金具といってもΦ3.2の針金を曲げた物なので２時間くらいで再製作出来ましたが、当日の午前中に出庫積込みをして午後仕込みのつもりだったので、当日発覚したらエライことでした。
どうも納得いかないのは、Φ3.2の針金を簡易治具を使って曲げていますからそこそこ形も揃っており、特別な用途のための物に見えると思うのですが、それをその場限りの消耗品と思って捨ててしまうのが理解不能。。。
特定の案件や会場に合わせた特殊品がどうしも増えてしまうので、管理はシッカリやらんといかんです。
#本業 #ガチ工作
ちょっくらヘトヘト。
穴あきボードの壁にLED-Barを吊り下げる現場があるのですが、昨年40個作っておいた金具が4個しかない！どうやら捨てられてしまったようです。
金具といってもΦ3.2の針金を曲げた物なので２時間くらいで再製作出来ましたが、当日の午前中に出庫積込みをして午後仕込みのつもりだったので、当日発覚したらエライことでした。
どうも納得いかないのは、Φ3.2の針金を簡易治具を使って曲げていますからそこそこ形も揃っており、特別な用途のための物に見えると思うのですが、それをその場限りの消耗品と思って捨ててしまうのが理解不能。。。
特定の案件や会場に合わせた特殊品がどうしも増えてしまうので、管理はシッカリやらんといかんです。
#本業 #ガチ工作
2023年9月 この範囲を時系列順で読む この範囲をファイルに出力する
以下を参考に少し試してみました。
「Programming FTDI devices in Python: Part 1」
Open DMX USB や FT232RL が実装されたデバイスが手元にありませんので何ともですが、pip で ftd2xx をインストールするとVSCode ではそれらしい関数の候補が出ます。候補が出るということはアクセスできる可能性が高いという事です。
＞ pip install ftd2xx
pywin32 もインストールされます。
「ftd2xx」のサイト見ますと、「ftd2xx は、ctypes を使用した FTDI の D2XX DLL の単純な Python ラッパーです。」とあります。
システムコールを直球で使えるってことだと思われます。
「jlbrogdon/dmx_controller」
ここで使われている関数とは呼び出す文言が違いますが、VSCode で表示される関数の候補にはそれと思われる関数が存在しています。
明日以降になりますが FT232RL が実装されたデバイスを繋げた状態で色々テストしてみましょう。
今考えているアイデアでいけるなら Open DMX USB の制御が Python で完結します。
これはいいかも
「Ftd2xxドライバー説明」
本家の資料では理解出来なかったことが分かりやすく書いてあります。欲しかった資料そのものです。
「ftd2xx.py」
「xiangruili/RTBox_py」
これらの資料で行けそうな予感がムクムク。
ENTTEC 純正の Open DMX USB と DMXチェッカーを事務所に置いてきたことを後悔。
すでに帰宅して呑んでいるので取りに行けませんので明日以降ですね。
それにしても、敷居が高いと思っていた DLL をここまで簡単に使えるとは予想外です。
ドライバに対する DLL があれば、少なくともＣ/Ｃ＋＋なら簡単にアクセスが可能で、それを単純なラッパーにしてしまえば Python からストレスなくアクセス出来てしまうのです。
この辺りの手段は手にしたいですねぇ～。
#Python #器具の製作
「Programming FTDI devices in Python: Part 1」
Open DMX USB や FT232RL が実装されたデバイスが手元にありませんので何ともですが、pip で ftd2xx をインストールするとVSCode ではそれらしい関数の候補が出ます。候補が出るということはアクセスできる可能性が高いという事です。
＞ pip install ftd2xx
pywin32 もインストールされます。
「ftd2xx」のサイト見ますと、「ftd2xx は、ctypes を使用した FTDI の D2XX DLL の単純な Python ラッパーです。」とあります。
システムコールを直球で使えるってことだと思われます。
「jlbrogdon/dmx_controller」
ここで使われている関数とは呼び出す文言が違いますが、VSCode で表示される関数の候補にはそれと思われる関数が存在しています。
明日以降になりますが FT232RL が実装されたデバイスを繋げた状態で色々テストしてみましょう。
今考えているアイデアでいけるなら Open DMX USB の制御が Python で完結します。
これはいいかも
「Ftd2xxドライバー説明」
本家の資料では理解出来なかったことが分かりやすく書いてあります。欲しかった資料そのものです。
「ftd2xx.py」
「xiangruili/RTBox_py」
これらの資料で行けそうな予感がムクムク。
ENTTEC 純正の Open DMX USB と DMXチェッカーを事務所に置いてきたことを後悔。
すでに帰宅して呑んでいるので取りに行けませんので明日以降ですね。
それにしても、敷居が高いと思っていた DLL をここまで簡単に使えるとは予想外です。
ドライバに対する DLL があれば、少なくともＣ/Ｃ＋＋なら簡単にアクセスが可能で、それを単純なラッパーにしてしまえば Python からストレスなくアクセス出来てしまうのです。
この辺りの手段は手にしたいですねぇ～。
#Python #器具の製作
Open DMX USB を扱うには FTD2XX.dll をコールするのが肝らしい。
チンプンカンプンな領域なのでこれから勉強ですが、次のサイトがヒントになりそう。
「PythonからDLLを使う」
「Python から DLL を利用する」
「C++で書いたコードをPythonで動かすには【pybind11】」
以下も参考になりそう。
「USBを使って制御できるリレーモジュールをpythonで動かしてみる」
「Programming FTDI devices in Python: Part 1」
上記の記事と以下を合わせるといけるのかな？
「jlbrogdon/dmx_controller」
#Python
チンプンカンプンな領域なのでこれから勉強ですが、次のサイトがヒントになりそう。
「PythonからDLLを使う」
「Python から DLL を利用する」
「C++で書いたコードをPythonで動かすには【pybind11】」
以下も参考になりそう。
「USBを使って制御できるリレーモジュールをpythonで動かしてみる」
「Programming FTDI devices in Python: Part 1」
上記の記事と以下を合わせるといけるのかな？
「jlbrogdon/dmx_controller」
#Python
ENTTEC 純正の Open DMX USB を入手しました。
しかし、先日調べたネタではデバイスの認識すらしません。README.md を読み返したところRaspberryPi用でした。動かなくても仕方ない。
調べ直したところGitHubに次の様なモノがありました。
「PyOpenDmxUsb」
README.md を読む限り、Windows 上の Python で Open DMX USB を扱う代物のようです。
使い方が少し難しいようですが、調べてみる価値はありそうです。
追記
「PyOpenDmxUsb」
は予想外に簡単でした。
１）pip で pywin32 をインストール
＞ pip install pywin32
２）GitHub からダウンロードしたファイルを メインの Python ソースがあるフォルダにまとめる。
・フォルダ「PyOpenDmxUsb-master」内の「Ｃ＃」フォルダにある「DMXServer.exe」。
・フォルダ「PyOpenDmxUsb-master」内の「Python」フォルダにある「DMXClient.py」。
あとは、サンプルプログラムを参考にソースを書きます。
from DMXClient import DMXClient
import time
dmxClient = DMXClient("PODU")
dmxClient.connect()
while True :
for i in range( 256 ) :
try :
dmxClient.write([1, i, 2, i])
time.sleep( 0.1 )
except KeyboardInterrupt:
dmxClient.close()
break
break
DMX の アドレス001とアドレス002をカウントしていくだけの動作を確認出来ました。
コマンドコンソールか PowerShell から DMXServer.exe を起動してから上記の Python コードを実行します。
＞ .\DMXServer -n PODU
この後、別コマンドコンソールから Python コードを実行します。
DMXServer.exe を起動してから本プログラムを実行する手順が少し面倒だし Python らしくない。
出来ることなら Python モジュールとして import して使えるようにしたいと思います。
DMXServer.exeのＣ＃ソースが付属しているので、これを参考に Python モジュールを作れたらいいのかな？
#器具の製作
しかし、先日調べたネタではデバイスの認識すらしません。README.md を読み返したところRaspberryPi用でした。動かなくても仕方ない。
調べ直したところGitHubに次の様なモノがありました。
「PyOpenDmxUsb」
README.md を読む限り、Windows 上の Python で Open DMX USB を扱う代物のようです。
使い方が少し難しいようですが、調べてみる価値はありそうです。
追記
「PyOpenDmxUsb」
は予想外に簡単でした。
１）pip で pywin32 をインストール
＞ pip install pywin32
２）GitHub からダウンロードしたファイルを メインの Python ソースがあるフォルダにまとめる。
・フォルダ「PyOpenDmxUsb-master」内の「Ｃ＃」フォルダにある「DMXServer.exe」。
・フォルダ「PyOpenDmxUsb-master」内の「Python」フォルダにある「DMXClient.py」。
あとは、サンプルプログラムを参考にソースを書きます。
from DMXClient import DMXClient
import time
dmxClient = DMXClient("PODU")
dmxClient.connect()
while True :
for i in range( 256 ) :
try :
dmxClient.write([1, i, 2, i])
time.sleep( 0.1 )
except KeyboardInterrupt:
dmxClient.close()
break
break
DMX の アドレス001とアドレス002をカウントしていくだけの動作を確認出来ました。
コマンドコンソールか PowerShell から DMXServer.exe を起動してから上記の Python コードを実行します。
＞ .\DMXServer -n PODU
この後、別コマンドコンソールから Python コードを実行します。
DMXServer.exe を起動してから本プログラムを実行する手順が少し面倒だし Python らしくない。
出来ることなら Python モジュールとして import して使えるようにしたいと思います。
DMXServer.exeのＣ＃ソースが付属しているので、これを参考に Python モジュールを作れたらいいのかな？
#器具の製作
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
LTC Generator のタイマーを修正してみました。
８時間経過で約１秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の１を表す単位なので比率だと0.00003)、１日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。
秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。
#PIC #タイムコード
８時間経過で約１秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の１を表す単位なので比率だと0.00003)、１日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。
秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。
#PIC #タイムコード
2023年5月 この範囲を時系列順で読む この範囲をファイルに出力する
PythonでVLCライブラリを使った音源ファイルの再生は驚くほど簡単。
インストールするべき諸々や音源モジュールの設定などもありますが、貴兄のサイトにいくらでもあるのでここでは割愛。
VLCで再生が出来、Python本体とPython-VLCがインストールされていればいいと思います。
以下、sound.mp3を再生するPythonのコード。
import vlc
if __name__ == '__main__':
p = vlc.MediaPlayer() ＃vlc.MediaPlayerのインスタンスを作成
p.set_mrl('sound.mp3') ＃インスタンスに音源ファイルを関連付け
p.play() ＃再生開始
こんだけです！
vlcのインスタンスを宣言し、音源ファイルを設定し、再生を指示するだけ。
再生はバックグラウンドで行われるので、マルチスレッドを使うことなく再生中に他のことが出来るのも良点。
ちなみに「p」はインスタンス名なので自由に定義して良いようです。
Python-VLCはＣ言語などが使うlibVLCをPythonから呼び出せるようにしているので、libVLCで出来ることの大半が出来るようです。
以下基本的なAPI。
p.set_mrl('sound.mp3') ＃インスタンスに音源ファイルを関連付け
p.play() ＃再生開始
p.pause() ＃再生中なら一時停止、一時停止中なら再生再開
p.get_time() ＃開始からの経過時間を取得(msec.)
p.set_time(1000) ＃指定した秒数(msec.)にセット
p.audio_set_volume(100) ＃0=mute,100=0dB（パーセント指示だと思っていいみたい）
p.stop() ＃停止
やりたいことはこれだけで済んでしまいそうな気もする。
python-vlcのドキュメント
沢山の事が出来るようですが、
vlc.MediaPlayer
の項を読むと上記のことがわかります。
#Python
インストールするべき諸々や音源モジュールの設定などもありますが、貴兄のサイトにいくらでもあるのでここでは割愛。
VLCで再生が出来、Python本体とPython-VLCがインストールされていればいいと思います。
以下、sound.mp3を再生するPythonのコード。
import vlc
if __name__ == '__main__':
p = vlc.MediaPlayer() ＃vlc.MediaPlayerのインスタンスを作成
p.set_mrl('sound.mp3') ＃インスタンスに音源ファイルを関連付け
p.play() ＃再生開始
こんだけです！
vlcのインスタンスを宣言し、音源ファイルを設定し、再生を指示するだけ。
再生はバックグラウンドで行われるので、マルチスレッドを使うことなく再生中に他のことが出来るのも良点。
ちなみに「p」はインスタンス名なので自由に定義して良いようです。
Python-VLCはＣ言語などが使うlibVLCをPythonから呼び出せるようにしているので、libVLCで出来ることの大半が出来るようです。
以下基本的なAPI。
p.set_mrl('sound.mp3') ＃インスタンスに音源ファイルを関連付け
p.play() ＃再生開始
p.pause() ＃再生中なら一時停止、一時停止中なら再生再開
p.get_time() ＃開始からの経過時間を取得(msec.)
p.set_time(1000) ＃指定した秒数(msec.)にセット
p.audio_set_volume(100) ＃0=mute,100=0dB（パーセント指示だと思っていいみたい）
p.stop() ＃停止
やりたいことはこれだけで済んでしまいそうな気もする。
python-vlcのドキュメント
沢山の事が出来るようですが、
vlc.MediaPlayer
の項を読むと上記のことがわかります。
#Python
2023年2月 この範囲を時系列順で読む この範囲をファイルに出力する
追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi