電装工芸日記
- 舞台照明機器の製作とか -
ユーザ「電装工芸」の投稿［862件］（19ページ目）
2023年8月 この範囲を時系列順で読む(電装工芸の投稿に限定) この範囲をファイルに出力する
次の２つの関数を作成しました。
・時間値をフレーム数に変換
・フレーム数からタイムコード値に変換(30・29.97・25・24fpsNDF、29.97fpsDFをサポート)
29.97fpsでは±１フレームの誤差が出ますが、他のfpsの様にキリ良く計算出来ないからです。演出機器を動かすなら29.97fps以外を使った方がいいと思います。
ドロップフレーム(DF)の処理はパズルでした。規則は単純ですが、計算式だけで解を得られない数の置き換えは思った以上に難儀します。
この後は LTC Player から得られる時間値からタイムコード値を自動でカウントし続けるモジュールを作ります。すでに試作品があるのでそれを参考にします。ここでもDFが面倒な課題となります。
#タイムコード
・時間値をフレーム数に変換
・フレーム数からタイムコード値に変換(30・29.97・25・24fpsNDF、29.97fpsDFをサポート)
29.97fpsでは±１フレームの誤差が出ますが、他のfpsの様にキリ良く計算出来ないからです。演出機器を動かすなら29.97fps以外を使った方がいいと思います。
ドロップフレーム(DF)の処理はパズルでした。規則は単純ですが、計算式だけで解を得られない数の置き換えは思った以上に難儀します。
この後は LTC Player から得られる時間値からタイムコード値を自動でカウントし続けるモジュールを作ります。すでに試作品があるのでそれを参考にします。ここでもDFが面倒な課題となります。
#タイムコード
LTC のフレーム値の計算で悩む。
ノンドロップフレームなら簡単ですが、29.97fpsドロップフレームではそうもいきません。実時間とタイムコードの値が合うのは１時間ごと、つまり途中は実時間とズレるのです。タイムコードは映像のフレームに時間形式のナンバリングを与える手法であって実時間を表す物ではありませんので仕方ありません。ズレがあるとしてもフレームナンバーをゼロからカウントするのは何も問題ありませんが、不特定の時間値からカウントされる場合に漠然とした疑問があるワケです。
困っていても仕方がないので条件を整理しましょう。
10分単位で考えてみます。
30fpsなら10分で18,000フレームです。29.97fpsドロップフレームは10分の間に18カウントを落としますので17,982フレームです。フレーム長の伸縮比1.001を掛けますと17,999.92となり、時間差は0.08フレームです。秒に直すと0.0026秒くらいの誤差です。そんなに大きな値ではありませんねぇ。見た目にわかる人は皆無ですからあんまり気にしなくてよくね？
となると、基準点(時毎もしくは10分毎)からのフレーム数を出し、このフレーム数からタイムコード値を得ればいいんでないか？大げさな感じもしますが、時間値で計算すると奇妙な繰り下がりが発生して計算が面倒だからです。30fpsの24時間分のフレーム数は 2,592,000 ですから32bitの整数でも十分管理出来ます。時間からフレームの枚数目を得る関数とフレームの枚数目から時間を得る関数を作っておけばどうにでもなりそう。
ここまでやれば、都度の誤差は人が感知出来ないレベルに収まると思います。
#タイムコード
ノンドロップフレームなら簡単ですが、29.97fpsドロップフレームではそうもいきません。実時間とタイムコードの値が合うのは１時間ごと、つまり途中は実時間とズレるのです。タイムコードは映像のフレームに時間形式のナンバリングを与える手法であって実時間を表す物ではありませんので仕方ありません。ズレがあるとしてもフレームナンバーをゼロからカウントするのは何も問題ありませんが、不特定の時間値からカウントされる場合に漠然とした疑問があるワケです。
困っていても仕方がないので条件を整理しましょう。
10分単位で考えてみます。
30fpsなら10分で18,000フレームです。29.97fpsドロップフレームは10分の間に18カウントを落としますので17,982フレームです。フレーム長の伸縮比1.001を掛けますと17,999.92となり、時間差は0.08フレームです。秒に直すと0.0026秒くらいの誤差です。そんなに大きな値ではありませんねぇ。見た目にわかる人は皆無ですからあんまり気にしなくてよくね？
となると、基準点(時毎もしくは10分毎)からのフレーム数を出し、このフレーム数からタイムコード値を得ればいいんでないか？大げさな感じもしますが、時間値で計算すると奇妙な繰り下がりが発生して計算が面倒だからです。30fpsの24時間分のフレーム数は 2,592,000 ですから32bitの整数でも十分管理出来ます。時間からフレームの枚数目を得る関数とフレームの枚数目から時間を得る関数を作っておけばどうにでもなりそう。
ここまでやれば、都度の誤差は人が感知出来ないレベルに収まると思います。
#タイムコード
本業がイイ感じに忙しいのでプログラム作業は思った程進みません。仕方ありませんけど。
LTC Player は音楽プレーヤー機能が一応組めたので、LTC の送出部を本格的に進めます。
どういった構造にしましょうかね。
クラスライブラリの書き方も体に入ってきましたので、本格的なドライバっぽい書き方に挑戦してみようと思います。LTC Generator は LTC Player と別な時間軸で動かさないといけませんのでマルチスレッドを使うことはマストだと思われます。LTC Generator は import する別ファイルとし、LTC Player とやりとりする部分はクラスとして記述し、そのクラスからスレッドを立ち上げてシリアル通信を制御するのです。これならLTC Player からはシンプルな関数にしか見えませんので構造的に美しく如何にもドライバって風味になりますw シリアルポートのリストを得る関数も別枠で作り、LTC Generator のインスタンスを起こす際にシリアルポートを指定するようにすれば複数の LTC Generator を扱えます。実際には音声信号を分ければいいので複数扱う必要はないのですが、ドライバとしてならこうあるベキかもしれません。
#Python
LTC Player は音楽プレーヤー機能が一応組めたので、LTC の送出部を本格的に進めます。
どういった構造にしましょうかね。
クラスライブラリの書き方も体に入ってきましたので、本格的なドライバっぽい書き方に挑戦してみようと思います。LTC Generator は LTC Player と別な時間軸で動かさないといけませんのでマルチスレッドを使うことはマストだと思われます。LTC Generator は import する別ファイルとし、LTC Player とやりとりする部分はクラスとして記述し、そのクラスからスレッドを立ち上げてシリアル通信を制御するのです。これならLTC Player からはシンプルな関数にしか見えませんので構造的に美しく如何にもドライバって風味になりますw シリアルポートのリストを得る関数も別枠で作り、LTC Generator のインスタンスを起こす際にシリアルポートを指定するようにすれば複数の LTC Generator を扱えます。実際には音声信号を分ければいいので複数扱う必要はないのですが、ドライバとしてならこうあるベキかもしれません。
#Python
Python の VLC ライブラリで mp3 を再生するとタイムオーバーします。長さ30秒の音源が32秒くらいまでカウントされて終わるのです。mp3 はデータの前後関係から復号する圧縮データのためでしょうか。
再生ポイントがズレてのことかと思いましたがお尻に無音が付くだけの様子。VLCの再生が終了していなくても再生秒数が長さ分になったことで終了と同じ扱いにしました。
付け焼刃な対策ですが、wav などの非圧縮データでは起こらないことですから、厳密を求めたいなら mp3 などの圧縮データを使わなければいいだけ、、、とします。
条件を織り交ぜた Play List で一晩連続再生しましたがエラーはありません。今後は頻繁な操作を続ける試験が必要です。
#Python
再生ポイントがズレてのことかと思いましたがお尻に無音が付くだけの様子。VLCの再生が終了していなくても再生秒数が長さ分になったことで終了と同じ扱いにしました。
付け焼刃な対策ですが、wav などの非圧縮データでは起こらないことですから、厳密を求めたいなら mp3 などの圧縮データを使わなければいいだけ、、、とします。
条件を織り交ぜた Play List で一晩連続再生しましたがエラーはありません。今後は頻繁な操作を続ける試験が必要です。
#Python
現場が立ち合いだけだったので LTC Player を書き進めることが出来、音楽プレイヤーとして搭載予定の機能はほぼ入りました。この後は動作確認しつつバグ取りです。
LTC を送出する LTC Generator の組み込みも考えましょう。LTCが組み込めれば全機能成立です。
#Python
LTC を送出する LTC Generator の組み込みも考えましょう。LTCが組み込めれば全機能成立です。
#Python
LTC Player はかなり良い仕上がりです。機能をもう数種類搭載すれば音楽プレーヤーの部分は終わりかなと。
主な課題は構造の整理ですが、細かいバグを潰しているためか負荷が減っています。特定の操作をするとファイルのアサインがおかしいバグがあったのですが、これを潰したところタスクマネージャー上の負荷が８%前後から４%前後に半減。余計なコマンドを１行消しただけなんですけど、重要な変数に破綻はさせないけどおかしな値を与えるものでした。プログラムは量じゃないと感じた一瞬ですね。
#Python
主な課題は構造の整理ですが、細かいバグを潰しているためか負荷が減っています。特定の操作をするとファイルのアサインがおかしいバグがあったのですが、これを潰したところタスクマネージャー上の負荷が８%前後から４%前後に半減。余計なコマンドを１行消しただけなんですけど、重要な変数に破綻はさせないけどおかしな値を与えるものでした。プログラムは量じゃないと感じた一瞬ですね。
#Python
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