電装工芸日記
- 舞台照明機器の製作とか -
2023年8月 この範囲を時系列順で読む この範囲をファイルに出力する
先週末、LTC Generator の関数を書いてました。モード値とタイムコード値から送信のバイナリを起こす関数です。
この作業で Python の変数の型である bytes と bytearray の違いようやくわかりました。
突き詰めたらどちらもバイトデータの羅列ってのが第一条件なんですが、コマンドで数値を処理するなら bytearray にしといた方が楽で、デバイスが送受信で扱うのは最終的に bytes ってだけでした。
とかく serial、socket を扱うなら bytes と bytearray がわかってないと不便。bytes にしなくても送信は出来るのですが文字コードの悪魔がちょっかいを出してくるので便利機能に頼るにしても自力で bytes まで持っていくつもりで書いた方がいいし、受信はどこまで行っても bytes なので避けて通れません。アセンブラに慣れきってしまった自分にとって「バイナリのデータが読めるとホッコリするよねぇ～」なんです。
#タイムコード #Python
この作業で Python の変数の型である bytes と bytearray の違いようやくわかりました。
突き詰めたらどちらもバイトデータの羅列ってのが第一条件なんですが、コマンドで数値を処理するなら bytearray にしといた方が楽で、デバイスが送受信で扱うのは最終的に bytes ってだけでした。
とかく serial、socket を扱うなら bytes と bytearray がわかってないと不便。bytes にしなくても送信は出来るのですが文字コードの悪魔がちょっかいを出してくるので便利機能に頼るにしても自力で bytes まで持っていくつもりで書いた方がいいし、受信はどこまで行っても bytes なので避けて通れません。アセンブラに慣れきってしまった自分にとって「バイナリのデータが読めるとホッコリするよねぇ～」なんです。
#タイムコード #Python
本業が忙しい。工作が出来ない。哀しい。
稼がんといけませんので仕方なし。
こんなとき、ちょっとしたアイデアが出るもの。
ジャンク品ですが、5Cクラスと思われるBNC同軸ケーブルと２回路の音声ケーブルが１本になっている複合ケーブル(ジープケーブル)が手元にあります。50mが２本と100mが１本です。
出処は書けませんが、とんでもなく品質の良いケーブルです。もちろん機械強度も高い。
丈夫で長さがあるので音声回線にDMXを通していましたが、考えてみたら同軸ケーブルにEtherでArt-Net通したらよくね？音声回線にはインカムとLTC通したらよくね？
今回は「同軸ケーブルが望ましいので積極採用！」ではなく、ジャンクなケーブルを活かすって意味ですから実用域のアダプタが安く手に入ればアリかな？って話です。
調べてみますと100Mbpsクラスの変換器なら入口出口のセットが１万円くらいで手に入ります。DMXマルチケーブルや屈強なLANケーブルで作ることを考えたら十分に安い。こんなんでもカタログスペックでは数百メートル引き回せるそうですから十分。
これは試すしかありませんのでポチリました。
幸い株で稼いだ分で賄えます。このところ株価の動きがアホみたいに大きいので、たまたま波に乗れたら３週間で原資の８％くらい取れました。巧い人は１年で何倍にもするのでしょうが、博才が皆無な私でも４月から月平均６％くらい取れています。どこに預けても増えるどころか実質目減りですから、損切り上等！で波を読むことを楽しんでます。現物なら目減りしても借金を背負うことはありませんから気楽なものです。運が良ければ持ち金が増える課金ゲームですね。昨年はちょっと負けましたが、自分に対する待ちどころがわかり始めた今年は負け分を取り返して小遣いくらいは稼げてます。自分を相手にポーカーをしているような気分ですけど。
#[Art-Net]
稼がんといけませんので仕方なし。
こんなとき、ちょっとしたアイデアが出るもの。
ジャンク品ですが、5Cクラスと思われるBNC同軸ケーブルと２回路の音声ケーブルが１本になっている複合ケーブル(ジープケーブル)が手元にあります。50mが２本と100mが１本です。
出処は書けませんが、とんでもなく品質の良いケーブルです。もちろん機械強度も高い。
丈夫で長さがあるので音声回線にDMXを通していましたが、考えてみたら同軸ケーブルにEtherでArt-Net通したらよくね？音声回線にはインカムとLTC通したらよくね？
今回は「同軸ケーブルが望ましいので積極採用！」ではなく、ジャンクなケーブルを活かすって意味ですから実用域のアダプタが安く手に入ればアリかな？って話です。
調べてみますと100Mbpsクラスの変換器なら入口出口のセットが１万円くらいで手に入ります。DMXマルチケーブルや屈強なLANケーブルで作ることを考えたら十分に安い。こんなんでもカタログスペックでは数百メートル引き回せるそうですから十分。
これは試すしかありませんのでポチリました。
幸い株で稼いだ分で賄えます。このところ株価の動きがアホみたいに大きいので、たまたま波に乗れたら３週間で原資の８％くらい取れました。巧い人は１年で何倍にもするのでしょうが、博才が皆無な私でも４月から月平均６％くらい取れています。どこに預けても増えるどころか実質目減りですから、損切り上等！で波を読むことを楽しんでます。現物なら目減りしても借金を背負うことはありませんから気楽なものです。運が良ければ持ち金が増える課金ゲームですね。昨年はちょっと負けましたが、自分に対する待ちどころがわかり始めた今年は負け分を取り返して小遣いくらいは稼げてます。自分を相手にポーカーをしているような気分ですけど。
#[Art-Net]
ディナーショーの現場です。
仕込めてしまえは空き時間多め。
LTC の時間値を扱う関数を書き上げました。
・msec からフレーム数得る物
・フレーム数から LTC の時間値を得る物
・時間値をインクリメント(+1)する物
・時間値を減算する物
以上４つです。
上３つは当たり前でも減算が必要か？って思われるかもしれませんが、卓がLTCを再認識するのに0.5秒くらいかかることへの対策に使います。試したのは MAdot2 ですが、LTCを停止すると認識が落ちますのでLTCを再開してもすぐには動作しません。ファーストCUEが遅れることになるので困ります。ところが2-3フレームを折り返し繰り返せば認識を維持しつつ進行を止めることが出来るのでコノ状態を Pause 処理にしようと思うのです。故に、現在値に対する減算が必要なのです。
具体的には再開の頭フレームのマイナス１フレームからマイナス３フレームを繰り返して待機状態とします。マイナス何フレームで繰り返すのが適切かは卓に寄って違う可能性がありますので今後検証したいと思います。
この後は LTC Generator 本体のファームウェアの手直しです。制御コマンドを少し増やしたいかなと。
#タイムコード #Python
仕込めてしまえは空き時間多め。
LTC の時間値を扱う関数を書き上げました。
・msec からフレーム数得る物
・フレーム数から LTC の時間値を得る物
・時間値をインクリメント(+1)する物
・時間値を減算する物
以上４つです。
上３つは当たり前でも減算が必要か？って思われるかもしれませんが、卓がLTCを再認識するのに0.5秒くらいかかることへの対策に使います。試したのは MAdot2 ですが、LTCを停止すると認識が落ちますのでLTCを再開してもすぐには動作しません。ファーストCUEが遅れることになるので困ります。ところが2-3フレームを折り返し繰り返せば認識を維持しつつ進行を止めることが出来るのでコノ状態を Pause 処理にしようと思うのです。故に、現在値に対する減算が必要なのです。
具体的には再開の頭フレームのマイナス１フレームからマイナス３フレームを繰り返して待機状態とします。マイナス何フレームで繰り返すのが適切かは卓に寄って違う可能性がありますので今後検証したいと思います。
この後は LTC Generator 本体のファームウェアの手直しです。制御コマンドを少し増やしたいかなと。
#タイムコード #Python
29.97fp-NDF の場合、単位時間あたりのフレーム数は 29.97fps で 勘定は 30fps の NDF と同じです。
・・・ってことが頭の中で混乱しました。
29.97fps-NDF はタイムコードの時間勘定が増えるため値の進みが遅くなります。
こういった「増えると減る」みたいな関係は挙動の理解がややこしい。
#タイムコード
・・・ってことが頭の中で混乱しました。
29.97fps-NDF はタイムコードの時間勘定が増えるため値の進みが遅くなります。
こういった「増えると減る」みたいな関係は挙動の理解がややこしい。
#タイムコード
次の２つの関数を作成しました。
・時間値をフレーム数に変換
・フレーム数からタイムコード値に変換(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