全年全月12日の投稿(時系列順)[36件](3ページ目)
2022年9月 この範囲を新しい順で読む この範囲をファイルに出力する
茨城県沖に世界でも屈指の規模の油ガス田がありそうだとのこと。
地元のこんな話は嬉しいですね。
程度はともかく、茨城県には日本国内のどこかにある自然、資源、産業、施設が一通りあります。食材も全国No.1の生産量を誇る物が多く、北海道に続いてNo.2も驚く程多い。意外なのは日本酒の生産量が圧倒的なNo.1であること。無いのは活火山とサンゴ礁くらいでしょうか。そこに「原油生産世界一」なんて追加されたら悪い気はしません。
こんな地の利の割に心意気や地域の歴史や文化に自慢出来るところがありませんので「何でもあるけど何にもない所」と勝手に呼んでいます。魅力度ランキングが物語っているのでこれ以上はいいか(笑
話を戻しますが、原油をほぼ100%輸入に頼ってきた日本にこんな資源があるとは驚きです。採掘には高度な技術と莫大な投資が必要でしょうが、採算がイマイチでも採れるという事実を構築すべきです。十分に喰って安心して寝られることがより良い生活の基本ですが、ロシアとウクライナの件に影響を受けているヨーロッパ各国の様子を見るなら、資源と農畜水産物を十分に確保することは重要だと思うのです。
戦争などあってはいけませんが、無いことと足元をみられることがそれを引き起こす原因であることは多いので、社会を維持するのに最低限必要なモノを自国内で確保することは平和を維持するためにも必要なことでしょう。身勝手な欲張りが欲しがらない程度ってのも大事かもしれませんケド。
#雑談
地元のこんな話は嬉しいですね。
程度はともかく、茨城県には日本国内のどこかにある自然、資源、産業、施設が一通りあります。食材も全国No.1の生産量を誇る物が多く、北海道に続いてNo.2も驚く程多い。意外なのは日本酒の生産量が圧倒的なNo.1であること。無いのは活火山とサンゴ礁くらいでしょうか。そこに「原油生産世界一」なんて追加されたら悪い気はしません。
こんな地の利の割に心意気や地域の歴史や文化に自慢出来るところがありませんので「何でもあるけど何にもない所」と勝手に呼んでいます。魅力度ランキングが物語っているのでこれ以上はいいか(笑
話を戻しますが、原油をほぼ100%輸入に頼ってきた日本にこんな資源があるとは驚きです。採掘には高度な技術と莫大な投資が必要でしょうが、採算がイマイチでも採れるという事実を構築すべきです。十分に喰って安心して寝られることがより良い生活の基本ですが、ロシアとウクライナの件に影響を受けているヨーロッパ各国の様子を見るなら、資源と農畜水産物を十分に確保することは重要だと思うのです。
戦争などあってはいけませんが、無いことと足元をみられることがそれを引き起こす原因であることは多いので、社会を維持するのに最低限必要なモノを自国内で確保することは平和を維持するためにも必要なことでしょう。身勝手な欲張りが欲しがらない程度ってのも大事かもしれませんケド。
#雑談
2022年10月 この範囲を新しい順で読む この範囲をファイルに出力する
忙しすぎもヒト段落。普段の忙しさに戻りました。
そんな渦中にiPadが壊れました。仕事では補助的にPDFの資料を見る程度ですが、無いと微妙に不便。仕方ないので新調。
ノートパソコンもそうですが、持ち歩き品にはあえて中古品を使います。初期不良と要所の強度の確認がバッチリ済んでいるからです。
それなりの費用はかかりましたが、Apple Pencil を導入出来たことは良い結果でした。猛烈に便利。
#雑談
そんな渦中にiPadが壊れました。仕事では補助的にPDFの資料を見る程度ですが、無いと微妙に不便。仕方ないので新調。
ノートパソコンもそうですが、持ち歩き品にはあえて中古品を使います。初期不良と要所の強度の確認がバッチリ済んでいるからです。
それなりの費用はかかりましたが、Apple Pencil を導入出来たことは良い結果でした。猛烈に便利。
#雑談
現時点では目新しさだけだけど、大気中に捨てていた熱エネルギーを電力化していることが興味深い。
保守や改修の費用も含めた長い目でプラスならアリですよね。
肝は低沸点の物質を利用した「バイナリー発電」です。ちょっと前までは低沸点の物質は腐食性や摩耗性が強く実用化が難しいとされていましたが、これを解決したのでしょうか。
440kwで900世帯って勘定にも少々疑問があります。平均値で見ればそうかもしれませんが、ピーク電力はどうでしょう。1世帯でドライヤー2個使ったら簡単にオーバーです。発電施設はピークに耐えてナンボですが、440kwと900世帯という数字が安易な皮算用でないことを祈りたいですね。現実をシビアに見ない夢物語は始まりから破綻することが決定していますので、バブルで弾けた温泉街の二の舞にならないといいのですが。
EVの開発で進歩した蓄電池の技術を応用し、今後普及するであろう家庭蓄電システムと併用することが前提なのかな?そうなら猛烈にアリですけどね。今の法律ですと家庭蓄電システムに対する電力源は商用電源に限定されるので、今後の法改正にも注目です(家庭のソーラーパネルは売電を前提にしているなら商用電源と見なされるのでグレーゾーン)。
#関心したネタ
保守や改修の費用も含めた長い目でプラスならアリですよね。
肝は低沸点の物質を利用した「バイナリー発電」です。ちょっと前までは低沸点の物質は腐食性や摩耗性が強く実用化が難しいとされていましたが、これを解決したのでしょうか。
440kwで900世帯って勘定にも少々疑問があります。平均値で見ればそうかもしれませんが、ピーク電力はどうでしょう。1世帯でドライヤー2個使ったら簡単にオーバーです。発電施設はピークに耐えてナンボですが、440kwと900世帯という数字が安易な皮算用でないことを祈りたいですね。現実をシビアに見ない夢物語は始まりから破綻することが決定していますので、バブルで弾けた温泉街の二の舞にならないといいのですが。
EVの開発で進歩した蓄電池の技術を応用し、今後普及するであろう家庭蓄電システムと併用することが前提なのかな?そうなら猛烈にアリですけどね。今の法律ですと家庭蓄電システムに対する電力源は商用電源に限定されるので、今後の法改正にも注目です(家庭のソーラーパネルは売電を前提にしているなら商用電源と見なされるのでグレーゾーン)。
#関心したネタ
2023年2月 この範囲を新しい順で読む この範囲をファイルに出力する
追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ?という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#C言語 #RaspberryPi
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ?という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#C言語 #RaspberryPi
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はC言語などが使う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はC言語などが使う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年6月 この範囲を新しい順で読む この範囲をファイルに出力する
LTC Generator のタイマーを修正してみました。
8時間経過で約1秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の1を表す単位なので比率だと0.00003)、1日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。
秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。
#PIC #タイムコード
8時間経過で約1秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の1を表す単位なので比率だと0.00003)、1日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。
秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。
#PIC #タイムコード
2023年9月 この範囲を新しい順で読む この範囲をファイルに出力する
ENTTEC 純正の Open DMX USB を入手しました。
しかし、先日調べたネタではデバイスの認識すらしません。README.md を読み返したところRaspberryPi用でした。動かなくても仕方ない。
調べ直したところGitHubに次の様なモノがありました。
「PyOpenDmxUsb」
README.md を読む限り、Windows 上の Python で Open DMX USB を扱う代物のようです。
使い方が少し難しいようですが、調べてみる価値はありそうです。
追記
「PyOpenDmxUsb」
は予想外に簡単でした。
1)pip で pywin32 をインストール
> pip install pywin32
2)GitHub からダウンロードしたファイルを メインの Python ソースがあるフォルダにまとめる。
・フォルダ「PyOpenDmxUsb-master」内の「C#」フォルダにある「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のC#ソースが付属しているので、これを参考に Python モジュールを作れたらいいのかな?
#器具の製作
しかし、先日調べたネタではデバイスの認識すらしません。README.md を読み返したところRaspberryPi用でした。動かなくても仕方ない。
調べ直したところGitHubに次の様なモノがありました。
「PyOpenDmxUsb」
README.md を読む限り、Windows 上の Python で Open DMX USB を扱う代物のようです。
使い方が少し難しいようですが、調べてみる価値はありそうです。
追記
「PyOpenDmxUsb」
は予想外に簡単でした。
1)pip で pywin32 をインストール
> pip install pywin32
2)GitHub からダウンロードしたファイルを メインの Python ソースがあるフォルダにまとめる。
・フォルダ「PyOpenDmxUsb-master」内の「C#」フォルダにある「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のC#ソースが付属しているので、これを参考に 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
以下を参考に少し試してみました。
「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 があれば、少なくともC/C++なら簡単にアクセスが可能で、それを単純なラッパーにしてしまえば 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 があれば、少なくともC/C++なら簡単にアクセスが可能で、それを単純なラッパーにしてしまえば Python からストレスなくアクセス出来てしまうのです。
この辺りの手段は手にしたいですねぇ~。
#Python #器具の製作