電装工芸日記
- 舞台照明機器の製作とか -
2023年7月27日の投稿［2件］
まだまだ途中ではあるものの使えるっちゃ使える 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