電装工芸日記
- 舞台照明機器の製作とか -
2023年8月 この範囲を時系列順で読む この範囲をファイルに出力する
PySimpleGUI ですが、ウェジットの更新がかなり重い様子。
大したことやってないハズなのに重いなぁ～と以前から思っていたのですが、内容が更新されていないウェジットまで毎フレーム書き直しをしていたことが原因でした。進捗の時間表示もありますので毎フレーム書き換えるウェジットはありますが、かといって全部やるこたありません。
ウェジットをグループに分けて内容が更新された時だけ書き換えを行う様にしたところ劇的に軽くなりました。当然っちゃ当然なんでしょうけど、ナルホドなぁ～ってことでした。フラグを立てまくりですから書き直しは面倒でしたが、これだけ軽くなるなら手間の分の価値はアリです。
気になってどうしても確認したかったのですが、オカゲで本業が遅れております。これはこれでヤバイ。
#Python
大したことやってないハズなのに重いなぁ～と以前から思っていたのですが、内容が更新されていないウェジットまで毎フレーム書き直しをしていたことが原因でした。進捗の時間表示もありますので毎フレーム書き換えるウェジットはありますが、かといって全部やるこたありません。
ウェジットをグループに分けて内容が更新された時だけ書き換えを行う様にしたところ劇的に軽くなりました。当然っちゃ当然なんでしょうけど、ナルホドなぁ～ってことでした。フラグを立てまくりですから書き直しは面倒でしたが、これだけ軽くなるなら手間の分の価値はアリです。
気になってどうしても確認したかったのですが、オカゲで本業が遅れております。これはこれでヤバイ。
#Python
自作のポップアップウィンドウを作っています。
汎用もあるのですが、ちょっと違うなぁ～って思いまして。
ウィンドウを表示するだけなら簡単ですが問題は表示位置です。通常はモニタのセンターに表示されますが、ポップアップウィンドウは親ウィンドウの中央に表示したい。
モニタのサイズ、親ウィンドウの位置やサイズは取得出来ますのでポップアップウィンドウのサイズがわかれば左上の位置は計算で出せますが、
・表示するとプログラムから表示位置の変更が出来ない。
・表示しないとウィンドウのサイズを得られない。
といった制約のためナカナカ難しい。
ならばと閃いたのが、テキトウな位置に表示してサイズを取得してすぐに消し、位置を計算して再表示するというもの。サイズ取得のための表示はタイムアウトを10msecくらいにすれば全く気になりません。
進捗表示などはメインルーチンで進捗の更新しないといけませんが、関数側で表示まで行い、ウィンドウのステータスをメインルーチンに戻して進捗表示を進めます。処理が終わればメインルーチン側で close() を実行です。ウィンドウのステータスをポインタで返しているんですね。
ついでに、親ウィンドウがモニタからハミ出した場合にはフルサイズになるようにもしてみました。
#Python
汎用もあるのですが、ちょっと違うなぁ～って思いまして。
ウィンドウを表示するだけなら簡単ですが問題は表示位置です。通常はモニタのセンターに表示されますが、ポップアップウィンドウは親ウィンドウの中央に表示したい。
モニタのサイズ、親ウィンドウの位置やサイズは取得出来ますのでポップアップウィンドウのサイズがわかれば左上の位置は計算で出せますが、
・表示するとプログラムから表示位置の変更が出来ない。
・表示しないとウィンドウのサイズを得られない。
といった制約のためナカナカ難しい。
ならばと閃いたのが、テキトウな位置に表示してサイズを取得してすぐに消し、位置を計算して再表示するというもの。サイズ取得のための表示はタイムアウトを10msecくらいにすれば全く気になりません。
進捗表示などはメインルーチンで進捗の更新しないといけませんが、関数側で表示まで行い、ウィンドウのステータスをメインルーチンに戻して進捗表示を進めます。処理が終わればメインルーチン側で close() を実行です。ウィンドウのステータスをポインタで返しているんですね。
ついでに、親ウィンドウがモニタからハミ出した場合にはフルサイズになるようにもしてみました。
#Python
2023年7月 この範囲を時系列順で読む この範囲をファイルに出力する
オフの今日は LTC Player のソースコードを整理しております。
出来るだけ class 化しているのですが、慣れれば平文で書くのと大差ありません。書き上がったコードはむしろ読みやすい。VSCodeは折り畳みが出来たり、自分なりにわかりやすいと思えるコメント文を入れているのものありますけどね。
メインのウィンドウの描画の再現まで完了しましたのでデザインの手直しにかかります。変更というよりは書いていなかったパラメータの追加が主な作業です。
明日からは山積みの本業に手を付けないといけませんので進むかな？
#Python
出来るだけ class 化しているのですが、慣れれば平文で書くのと大差ありません。書き上がったコードはむしろ読みやすい。VSCodeは折り畳みが出来たり、自分なりにわかりやすいと思えるコメント文を入れているのものありますけどね。
メインのウィンドウの描画の再現まで完了しましたのでデザインの手直しにかかります。変更というよりは書いていなかったパラメータの追加が主な作業です。
明日からは山積みの本業に手を付けないといけませんので進むかな？
#Python
バレエ発表会で道具だけ。転換は休憩の時だけなので緩い現場です。
Python の記述エディタを VSCode に変更しました。
インストールするべき拡張機能は次の通り。
１）Japanese Language Pack for Visual Studio Code（VSCodeを入れたらまず入れるべき拡張機能）
２）Python Extension Pack（拡張機能が３つ６つ入る。この中のPythonだけでもいいらしいけど、全部入れた方が便利だと思う)
こんだけでいいならもっと早く使えばよかったなと。
VSCodeはいいっすね。「オイラ便利だろ！」という主張がほぼ無くサラッと便利。
軽いし、無駄な装飾は無いし、わかりやすいし、こんなバランスが良くてスマートなツールが microsoft 発祥とは意外だったりして。
VSCode はお勧めです。
LTC Player のソースコードを整理しようとしていますが、import した自作ファイルの変数の有効範囲などを改めて確認しています。スマートな記述のためには大事なことです。
試してシミジミ実感したのですが、出来るだけ class で記述した方が可読性が高いですわ。
#Python
Python の記述エディタを VSCode に変更しました。
インストールするべき拡張機能は次の通り。
１）Japanese Language Pack for Visual Studio Code（VSCodeを入れたらまず入れるべき拡張機能）
２）Python Extension Pack（拡張機能が
こんだけでいいならもっと早く使えばよかったなと。
VSCodeはいいっすね。「オイラ便利だろ！」という主張がほぼ無くサラッと便利。
軽いし、無駄な装飾は無いし、わかりやすいし、こんなバランスが良くてスマートなツールが microsoft 発祥とは意外だったりして。
VSCode はお勧めです。
LTC Player のソースコードを整理しようとしていますが、import した自作ファイルの変数の有効範囲などを改めて確認しています。スマートな記述のためには大事なことです。
試してシミジミ実感したのですが、出来るだけ class で記述した方が可読性が高いですわ。
#Python
まだまだ途中ではあるものの使えるっちゃ使える LTC_Player で本業の音源チェックをしています。
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
Table のカラム幅の自動調整で少し悩む。
初期サイズからウィンドウ枠をドラックするサイズ変更を１回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が１回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。
あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
フォントの指定も列ごとに出来るといいのですけどね。
#Python
初期サイズからウィンドウ枠をドラックするサイズ変更を１回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が１回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。
あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
フォントの指定も列ごとに出来るといいのですけどね。
#Python
PySimpleGUI にてウィンドウのサイズを取得出来ました。
これは基本情報です。
課題は Windows サイズに合わせて Table のカラム幅を自動調整する方法です。
純正のドキュメントには解決策が無くネットをしばらく徘徊。
結論から言うと解決したのですが、Tkinter のパラメータを PySimpleGUI から直接操作すると思われるコマンドでカラム幅を直接指定しました。
Tkinter を知らないので全く理解出来ていませんが、先達の例文にあった定型文を試したところビンゴでした。
細かい調整は沢山ありますが、根本的なところは解決したので一安心です。
#Python
これは基本情報です。
課題は Windows サイズに合わせて Table のカラム幅を自動調整する方法です。
純正のドキュメントには解決策が無くネットをしばらく徘徊。
結論から言うと解決したのですが、Tkinter のパラメータを PySimpleGUI から直接操作すると思われるコマンドでカラム幅を直接指定しました。
Tkinter を知らないので全く理解出来ていませんが、先達の例文にあった定型文を試したところビンゴでした。
細かい調整は沢山ありますが、根本的なところは解決したので一安心です。
#Python
本業が詰まってしまい工作が進みません。
困ったような仕方ないような。
さて、合間に調べモノと妄想はしています。
課題は 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