電装工芸日記
- 舞台照明機器の製作とか -
2023年7月 この範囲を時系列順で読む この範囲をファイルに出力する
本業が詰まってしまい工作が進みません。
困ったような仕方ないような。
さて、合間に調べモノと妄想はしています。
課題は PysimpleGUI のウィンドウのサイズを変更しても画面レイアウトを成立させるにはどうするかです。
まずは基本情報の位置とサイズの取得です。
位置(左上の角)は sg.window.current_location() を用います。Tupleで(width, height)を取得出来ます。
ウィンドウサイズを取得するには sg.window.size を用います。Tupleで(width, height)を取得出来ます。ちなみに size の後にカッコは入れません。
ウェジットのサイズも同様の方法で取得出来ます。
ただ、PysimpleGUIはウェジットのサイズ指定が文字数/行数単位とピクセル単位が混在していますので、取得したサイズ情報からウェジットのサイズ指定をどのようにするか熟慮しないといけません。
#Python
困ったような仕方ないような。
さて、合間に調べモノと妄想はしています。
課題は PysimpleGUI のウィンドウのサイズを変更しても画面レイアウトを成立させるにはどうするかです。
まずは基本情報の位置とサイズの取得です。
位置(左上の角)は sg.window.current_location() を用います。Tupleで(width, height)を取得出来ます。
ウィンドウサイズを取得するには sg.window.size を用います。Tupleで(width, height)を取得出来ます。ちなみに size の後にカッコは入れません。
ウェジットのサイズも同様の方法で取得出来ます。
ただ、PysimpleGUIはウェジットのサイズ指定が文字数/行数単位とピクセル単位が混在していますので、取得したサイズ情報からウェジットのサイズ指定をどのようにするか熟慮しないといけません。
#Python
Python をスレッドに分ける基準についてオレメモです。
待ち時間が発生する処理単位をスレッドとして独立化することが基本的な考え方でしょう。デバイスの応答待ちや重い処理の終了待ちがある場合です。この間に何もしなくていいならスレッド化をする必要はありませんが、大概は待ち時間に他の処理を平行して行うことになるからです。
この様な想定がされる場合は最初からマルチスレッドで書き始めるのが良さそうです。主処理を親スレッドとしてサブルーチン的な子スレッドを定義する手もありますが、親スレッドはスレッド間通信の管理と子スレッドの起動・終了だけを扱うようにするとわかりやすいような気がします。
スレッド間通信の手段はデータ量や求める速度によりますが Queue を使うのが良さそうです。Tuple で包めばどんな型でもやりとり出来ますし、FIFO スタックなのでスレッド間のタイミング管理が楽です。
こういった検討する場合、一つのプロセスで処理しきれるかも同時に検討します。OS次第ではありますが、一つのプロセスは一つのCPUスレッドで処理されるのが普通ですから、処理が重い場合はプロセスを分けてCPUスレッドを分散させた方がいいこともあります。ただし、プロセスを分けると子プロセスを起動するのに時間がかかり、プロセス間通信も手続きが煩雑ですので、ハードウェアの能力を余すところなく使えそうなマルチプロセスが必ずしも最良の選択とは言えません。
#Python
待ち時間が発生する処理単位をスレッドとして独立化することが基本的な考え方でしょう。デバイスの応答待ちや重い処理の終了待ちがある場合です。この間に何もしなくていいならスレッド化をする必要はありませんが、大概は待ち時間に他の処理を平行して行うことになるからです。
この様な想定がされる場合は最初からマルチスレッドで書き始めるのが良さそうです。主処理を親スレッドとしてサブルーチン的な子スレッドを定義する手もありますが、親スレッドはスレッド間通信の管理と子スレッドの起動・終了だけを扱うようにするとわかりやすいような気がします。
スレッド間通信の手段はデータ量や求める速度によりますが Queue を使うのが良さそうです。Tuple で包めばどんな型でもやりとり出来ますし、FIFO スタックなのでスレッド間のタイミング管理が楽です。
こういった検討する場合、一つのプロセスで処理しきれるかも同時に検討します。OS次第ではありますが、一つのプロセスは一つのCPUスレッドで処理されるのが普通ですから、処理が重い場合はプロセスを分けてCPUスレッドを分散させた方がいいこともあります。ただし、プロセスを分けると子プロセスを起動するのに時間がかかり、プロセス間通信も手続きが煩雑ですので、ハードウェアの能力を余すところなく使えそうなマルチプロセスが必ずしも最良の選択とは言えません。
#Python
コロナも明けた感じで繁忙期に入っています。開発・製作をする時間が取りにくくなってきました。
LTC Player は早く欲しい気持ちはあるものの、近日中に使いたい案件があるワケではありません。１年くらいかけてノンビリ作るつもりです。
先日も書きましたが、Python らしい様式で書き直そうと思います。マルチスレッドの基本構造を最初から組み入れ、平文ではなく構造化・ライブラリ化(ヘッダーファイル化)を進め、可能な部分は出来るだけクラス化するのです。
PysimpleGUIも読みやすく手直しがしやすい書き方を検討したいですね。ウェジット一つにも設定項目が多いのでちょっとしたウィンドウ作るだけで膨大なコマンド数になりますが、これを出来るだけ簡素に書きたいのです。他人に読んでもらう気はありませんが、２年後の自分が理解できるようには書きたいかなと。PysimpleGUIは他の製作でも使いたいので、習作というか自分なりのひな形作りも兼ねるつもりです。
複数のファイルを使って構造的に書いていきますので VSCode を使った方が楽です。RaspberryPi の開発では便利に使っていますが、目的・用途に合わせたセッティングの仕方をオレマニュアルにまとめる必要があります。VSCode は素直で使いやすいエディタだと思うのですが、やれることが多すぎるので最初の段取りをキチンと踏まないと後で困るからです。
ファイル１枚の短いモノなら秀丸エディタでチョイチョイ書いた方が手っ取り早いのですけど、LTC PLayer はそういう規模ではなくなっています。
#Python
LTC Player は早く欲しい気持ちはあるものの、近日中に使いたい案件があるワケではありません。１年くらいかけてノンビリ作るつもりです。
先日も書きましたが、Python らしい様式で書き直そうと思います。マルチスレッドの基本構造を最初から組み入れ、平文ではなく構造化・ライブラリ化(ヘッダーファイル化)を進め、可能な部分は出来るだけクラス化するのです。
PysimpleGUIも読みやすく手直しがしやすい書き方を検討したいですね。ウェジット一つにも設定項目が多いのでちょっとしたウィンドウ作るだけで膨大なコマンド数になりますが、これを出来るだけ簡素に書きたいのです。他人に読んでもらう気はありませんが、２年後の自分が理解できるようには書きたいかなと。PysimpleGUIは他の製作でも使いたいので、習作というか自分なりのひな形作りも兼ねるつもりです。
複数のファイルを使って構造的に書いていきますので VSCode を使った方が楽です。RaspberryPi の開発では便利に使っていますが、目的・用途に合わせたセッティングの仕方をオレマニュアルにまとめる必要があります。VSCode は素直で使いやすいエディタだと思うのですが、やれることが多すぎるので最初の段取りをキチンと踏まないと後で困るからです。
ファイル１枚の短いモノなら秀丸エディタでチョイチョイ書いた方が手っ取り早いのですけど、LTC PLayer はそういう規模ではなくなっています。
#Python
弊社の音響担当に意見を聞きました。使ってもらうために彼らの慣れに合わせたいと思っているので、私の感覚だけで作りたくないのです。
こちらのイメージも具体的になってきたのでナルホドねぇ～が連発でしたが、そんな話の中で驚いたのはいわゆる叩きに使えるアプリが少ないという事実。
世の中には音楽再生アプリが数多ありますので私が作ったアプリを使ってくれるだろうかと思っていましたが、音響さんにとって便利な機能を積極的に取り込めば割り込む余地はありそうです。
大半の音楽再生アプリはあくまで音楽を聴くことを目的にしているためか操作に対するレスポンスが悪くキッカケ合わせに使うのは難しいのだそうです。私が音源再生のライブラリとして使っているVLCライブラリはレスポンスが良いので不思議です。
マルチスレッド化を考えていますが、その前にソースコードの整理が必要っぽいです。
フラグを用いた逐次処理をベタベタの平文で書いていますが、2000行に届こうともなるとインデックスが使えない平文ではエディタを上下スクロールするだけでも面倒ですし、今後の加筆、修正を考えるとこのままではいけないような気がします。
特に PysimpleGUI の設定が大量なので、せめてこの辺りをＣ言語で言うところのヘッダーファイル化したいものです。定数や関数をオレ様ライブラリ化するのですが、これが正しい書き方なのでしょう。
ここまでを試作とし、Python として美しい書式で新たに書いた方がいいのかな？
#Python
こちらのイメージも具体的になってきたのでナルホドねぇ～が連発でしたが、そんな話の中で驚いたのはいわゆる叩きに使えるアプリが少ないという事実。
世の中には音楽再生アプリが数多ありますので私が作ったアプリを使ってくれるだろうかと思っていましたが、音響さんにとって便利な機能を積極的に取り込めば割り込む余地はありそうです。
大半の音楽再生アプリはあくまで音楽を聴くことを目的にしているためか操作に対するレスポンスが悪くキッカケ合わせに使うのは難しいのだそうです。私が音源再生のライブラリとして使っているVLCライブラリはレスポンスが良いので不思議です。
マルチスレッド化を考えていますが、その前にソースコードの整理が必要っぽいです。
フラグを用いた逐次処理をベタベタの平文で書いていますが、2000行に届こうともなるとインデックスが使えない平文ではエディタを上下スクロールするだけでも面倒ですし、今後の加筆、修正を考えるとこのままではいけないような気がします。
特に PysimpleGUI の設定が大量なので、せめてこの辺りをＣ言語で言うところのヘッダーファイル化したいものです。定数や関数をオレ様ライブラリ化するのですが、これが正しい書き方なのでしょう。
ここまでを試作とし、Python として美しい書式で新たに書いた方がいいのかな？
#Python
Pythonでマルチスレッドをする方法を改めて調べていました。
以前は threading を使いましたが、concurrent.futures が便利っぽい。普通の関数を使うのと大差ない手間で使えます。
しかもマルチスレッドだけでなくマルチプロセスも扱えます。マルチプロセスでも fork して管理する作業が無く、マルチスレッドとほぼ同じ書き方で使えるので、どちらかで書いておけば後から変更するのも簡単。
マルチスレッドとマルチプロセスの違いは先達の書き込みが沢山があるので割愛しますが、今回の用途ではマルチスレッドが良さそうです。処理の総量はシングルプロセスでも十分に間に合っているのですが、ウィンドウマネージャーの待ちとシリアル通信の待ちがかみ合わないことへの措置なので軽快なマルチスレッドなワケです。
#Python
以前は threading を使いましたが、concurrent.futures が便利っぽい。普通の関数を使うのと大差ない手間で使えます。
しかもマルチスレッドだけでなくマルチプロセスも扱えます。マルチプロセスでも fork して管理する作業が無く、マルチスレッドとほぼ同じ書き方で使えるので、どちらかで書いておけば後から変更するのも簡単。
マルチスレッドとマルチプロセスの違いは先達の書き込みが沢山があるので割愛しますが、今回の用途ではマルチスレッドが良さそうです。処理の総量はシングルプロセスでも十分に間に合っているのですが、ウィンドウマネージャーの待ちとシリアル通信の待ちがかみ合わないことへの措置なので軽快なマルチスレッドなワケです。
#Python
ＥＶがエコである条件は、環境負荷が少ないエネルギー源で電力を起こし消費量も少ないことです。製造においても運用においてもです。
ところが現実は違うようです。電力の大半を火力発電で賄い、運用エネルギーの消費量も少ないとは言えず、製造ではガソリン車よりも多くのエネルギーを必要とするそうな。
ぶっちゃけ、目の前で排ガスを出さないだけでエコとは呼べないのが今のＥＶです。給電インフラの不足や電池の原料採掘と廃棄のことまで言い出したらキリがありません。
まぁ、目の前で排ガスを出さないのはアリっちゃありっちゃありなんですけど。
そんなこんなの裏で人造石油が注目されています。藻に下水を喰わせて搾り取ったり、炭酸水に原油(種油)を混ぜて培養するなど様々な方法が考案されていますが、人造石油のいいところは大気中の二酸化炭素が原料の一部になること、燃やしても有害物質の発生がとても少ないことなどです。特に硫黄の含有量がほぼゼロなので硫黄酸化物(SOx)の排出が理屈ではゼロです。しかもとても安価に作れるそうな。これは凄いことです。
欠点があるとするなら主要特許を持っているのが日本だということです。
日本車潰し(正確には日本のエンジンメーカー潰し)のためのＥＶ化なのに、このままではＥＶはダメでやっぱり内燃機関でしょとなり燃料まで日本が強くなって本末転倒です。
次世代燃料、高性能電池、レアメタルレス高性能モーターなどの主要特許を日本がほぼ独占しているのは皮肉でしかありません。
他者の足を引っ張ることで一番になろうとしても頂点には立てないという道徳の授業かな？
#雑談
ところが現実は違うようです。電力の大半を火力発電で賄い、運用エネルギーの消費量も少ないとは言えず、製造ではガソリン車よりも多くのエネルギーを必要とするそうな。
ぶっちゃけ、目の前で排ガスを出さないだけでエコとは呼べないのが今のＥＶです。給電インフラの不足や電池の原料採掘と廃棄のことまで言い出したらキリがありません。
まぁ、目の前で排ガスを出さないのはアリっちゃありっちゃありなんですけど。
そんなこんなの裏で人造石油が注目されています。藻に下水を喰わせて搾り取ったり、炭酸水に原油(種油)を混ぜて培養するなど様々な方法が考案されていますが、人造石油のいいところは大気中の二酸化炭素が原料の一部になること、燃やしても有害物質の発生がとても少ないことなどです。特に硫黄の含有量がほぼゼロなので硫黄酸化物(SOx)の排出が理屈ではゼロです。しかもとても安価に作れるそうな。これは凄いことです。
欠点があるとするなら主要特許を持っているのが日本だということです。
日本車潰し(正確には日本のエンジンメーカー潰し)のためのＥＶ化なのに、このままではＥＶはダメでやっぱり内燃機関でしょとなり燃料まで日本が強くなって本末転倒です。
次世代燃料、高性能電池、レアメタルレス高性能モーターなどの主要特許を日本がほぼ独占しているのは皮肉でしかありません。
他者の足を引っ張ることで一番になろうとしても頂点には立てないという道徳の授業かな？
#雑談
LTC Player は音源プレーヤー部がほぼ終わり。今後は LTC Generator の制御を組み込んでいきます。
LTC Generator の制御部はマルチスレッドを使って音楽プレーヤーと分ける必要があると思われます。LTC Generator との通信は最短で33msec(1/30秒)毎に行われますが、PysimpleGUI の sg.window.read() のタイムアウトを25msecにしているためにタイミングが間に合わない可能性があるからです。タイムアウトをもっと早くすれば良さそうなものですが、これ以上早くすると PysimpleGUI にとってよろしくないのです。あちらを立てればこちらが立たず状態ですが、トータルの処理量には無理は無く、あくまでタイミングの問題ですから、マルチスレッドにすればストレス無く動くと思います。
スレッド間通信には Queue を使えばいいでしょう。共有メモリや Pipe より通信は遅いのですが、List だろうが Tuple だろうがPythonで扱う変数をそのまま扱えるので便利です。通信するデータ量も僅かですから速度が気になることもないでしょう。ちなみに、Queue を送った後にほんの僅かな sleep() を入れると受け側のスレッドが動くまでの時間を短く出来る様です。
#Python
LTC Generator の制御部はマルチスレッドを使って音楽プレーヤーと分ける必要があると思われます。LTC Generator との通信は最短で33msec(1/30秒)毎に行われますが、PysimpleGUI の sg.window.read() のタイムアウトを25msecにしているためにタイミングが間に合わない可能性があるからです。タイムアウトをもっと早くすれば良さそうなものですが、これ以上早くすると PysimpleGUI にとってよろしくないのです。あちらを立てればこちらが立たず状態ですが、トータルの処理量には無理は無く、あくまでタイミングの問題ですから、マルチスレッドにすればストレス無く動くと思います。
スレッド間通信には Queue を使えばいいでしょう。共有メモリや Pipe より通信は遅いのですが、List だろうが Tuple だろうがPythonで扱う変数をそのまま扱えるので便利です。通信するデータ量も僅かですから速度が気になることもないでしょう。ちなみに、Queue を送った後にほんの僅かな sleep() を入れると受け側のスレッドが動くまでの時間を短く出来る様です。
#Python
LTC Player はいい感じに進んできました。
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
PysimpleGUI の使い方が更に見えてきたので LTC Player はそれっぽさが増しています。
右クリックメニューが便利ですね。ほとんどのウェジットに設定が出来ます。ボタンを配置することなく操作イベントを起こせるので、使用頻度が少ない操作やパソコンに間違って触れても発生させたくない操作には良いようです。問題は「ここには右クリックメニューがあるよ」をどうやって示すかです。隠しコマンドの様なショートカットキーは嫌いなのでその様にはしたくありませんし、「ここにあるよ」を強く主張したらボタンと同じです。強く主張することなく右クリックメニューがあることを示すデザイン手法が欲しいところです。もう少し研究が必要です。
まだまだα版ですが、「自分が仕事で使うなら欲しい機能」を実装していくのは楽しいですね。
VLC Media Player にもある機能ですが、スライダーで再生位置を設定したり、カーソルキーで少し戻す・送る機能は便利です。音源を聞きながらのデータ整理では能率が良いですし、リハでは「音の終わりから何秒戻したところから再生したい」とかがよくあるからです。されど本番では絶対に触りたくない機能ですから、右クリックメニューで有効/無効を設定出来る様にもしておくと更にイイ感じです。
#Python
右クリックメニューが便利ですね。ほとんどのウェジットに設定が出来ます。ボタンを配置することなく操作イベントを起こせるので、使用頻度が少ない操作やパソコンに間違って触れても発生させたくない操作には良いようです。問題は「ここには右クリックメニューがあるよ」をどうやって示すかです。隠しコマンドの様なショートカットキーは嫌いなのでその様にはしたくありませんし、「ここにあるよ」を強く主張したらボタンと同じです。強く主張することなく右クリックメニューがあることを示すデザイン手法が欲しいところです。もう少し研究が必要です。
まだまだα版ですが、「自分が仕事で使うなら欲しい機能」を実装していくのは楽しいですね。
VLC Media Player にもある機能ですが、スライダーで再生位置を設定したり、カーソルキーで少し戻す・送る機能は便利です。音源を聞きながらのデータ整理では能率が良いですし、リハでは「音の終わりから何秒戻したところから再生したい」とかがよくあるからです。されど本番では絶対に触りたくない機能ですから、右クリックメニューで有効/無効を設定出来る様にもしておくと更にイイ感じです。
#Python
某所に設置したサーバー機の OS は Debian です。
それ自体が素晴らしいのもありますが、細かい解説を残してくれる先達が多いので、自分がやりたいと思うことはネットを検索すればほとんど解決します。
samba を用いてのファイル共有はその昔の文字コード問題は全く無くアクセスも速いですね。Windows-Server で共有するのと遜色ありません。
Wi-fi のアクセスポイントにもしていますが、汎用の USB-Wifi トングで問題ありません。
VPN(openvpn)で本社のサーバーとも繋げています。ファイルを直接開くのはお勧め出来ないものの、特別なことをせずに本社の共有フォルダにアクセス出来ますから作業性は良いですね。VPNとは拠点間LANとも呼ばれる手法で、疑似的にLANケーブルが繋がっているのと同じ状態を作り上げる手法です。openvpn 以外にDNSサーバーに細工をしてルーティングを施さないといけませんが、要領がわかってしまえば簡単です。
#サーバー
それ自体が素晴らしいのもありますが、細かい解説を残してくれる先達が多いので、自分がやりたいと思うことはネットを検索すればほとんど解決します。
samba を用いてのファイル共有はその昔の文字コード問題は全く無くアクセスも速いですね。Windows-Server で共有するのと遜色ありません。
Wi-fi のアクセスポイントにもしていますが、汎用の USB-Wifi トングで問題ありません。
VPN(openvpn)で本社のサーバーとも繋げています。ファイルを直接開くのはお勧め出来ないものの、特別なことをせずに本社の共有フォルダにアクセス出来ますから作業性は良いですね。VPNとは拠点間LANとも呼ばれる手法で、疑似的にLANケーブルが繋がっているのと同じ状態を作り上げる手法です。openvpn 以外にDNSサーバーに細工をしてルーティングを施さないといけませんが、要領がわかってしまえば簡単です。
#サーバー