🗐 電装工芸日記 - 舞台照明機器の製作とか -

今年は開発案件を進めたい

or 管理画面へ

2023年5月 この範囲を時系列順で読む この範囲をファイルに出力する

Icon of admin
 MIDIのビットレートは31,250kbps、8MHzの256分の1です。
 ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
 これならPICのUARTで誤差無しで扱えます。

 送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
 信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。

 凄くシンプルなMTCジェネレーターならすぐ作れそうです。

#タイムコード
Icon of admin
 パソコンの音声再生アプリにはタイムコードを出す物があるらしい。
 様々なアプリがあるので一概に言えませんが、タイムコードはLTCではなくMIDI-TimeCode(以下、MTC)ではないかと思われます。というか、それらのアプリの用途を考えたらMTCが自然かと。
 LTCのメリットは音声信号であるため配線の選択肢が多いことです。仕込みの効率が良いのでLTCを望んでいるのです。
 ですが、既存のアプリが使えるならその流儀を優先させた方が良いかもしれません。LTCを扱える調光卓はMTCも扱えますし、音声再生の視点ではMTCの方が汎用性が高いからです。
 LTCのメリットでありMIDIの弱点となるのは音声信号として扱えるかと配線長です。この辺りを対策すれば音声再生側も調光卓側もMTCでいいんじゃないかと。

 さて、どうしましょう。
 LTCのメリットとMTCのメリットを足して、MTCを音声信号として送れるようにすればよくね?
 MIDI全般に対応する気はありませんから、MTCに特化して音声信号(差動バイフェーズ)として送るのです。

 参考
 MIDIタイムコード規格
 MIDIタイムコード(MTC)について調べてみた
 有志の方のサイトです。
 ここで言うMTCは記事にある「クォーター・フレーム・メッセージ F1 dd」のことです。

 MTC(コマンド0xF1)はMIDIの回線をタイムコードで占有しないために2フレーム分の時間を使って送信するようです。
 バイト送信のタイミングはMTCを出す側に依存するとしても、1フレームの時間で8バイト送れればいい。MTCに完全特化してコマンド0xF1を省けば4バイトです。
 4バイトなら1フレームの時間内で40bit送れればよく、最もビットレートが速い30fpsでも1,200bpsあれば事足ります。差動バイフェーズで音声信号化しても問題無しです。
 受信側はバイト受信の度に0xF1を付けた2バイトをMIDIとして送出するだけです。
 この方法は僅かな遅れを生じますが、MTCは2フレーム遅れるのが前提の規格ですし、遅れが一定ならば実用上の問題は無いと考えます。
 分解能が1/12~1/15秒であることもMTCの前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。

 自画自賛ですが悪くないアイデアです。

#器具の製作 #タイムコード
Icon of admin
 LTC音源で卓が動きました。「MA dot2 core」です。
 トリガータイムは手打ちも出来ますが「TC Record」機能を使えばLTCを受けながら「GO」を押すことでタイムが取れます。タイムの修正も現在値に対するプラスマイナスで行えます。
 ただし、LTCが走り出してから認識するのに0.3sec.程度かかります。また、エグゼキューターをOffにしておいてもその時刻が来るとCUEが走ってしまいます。
 装置を構成するには卓の挙動をよく観察しないといけませんが、一度覚えさせればその通りに再現してくれる感覚は良いですね。

追記
 LTCの認識は同じ値を送り続けたら解決出来るかもしれません。スタートするまで1フレーム前のデータを繰り返し送り続けるのです。1:00:00.00からスタートするなら0:59:59.29(29.97fps)のデータを送り続けるのです。試すしかありませんが、アクティブな一時停止が実現出来れば手段が広がるように思います。

#器具の製作 #タイムコード
Icon of admin
 「LTC Sound Player」を本格的に製作する前にLTCによって生産性が上がるのか検証しなければなりません。本番操作が楽でも結果的に作業量が増えたら本末転倒だからです。
 音源を加工せずにLTCを出すことが目標ですが、まずはテスト音源を作成。花火屋さんに倣い、L-chに音楽、R-chにLTCです。今回は29.97fps(NDF)と25fpsの2種類を作ってみました。
 LTCはここで作ってもらいました。便利なサイトがあるものです。
 1時間目から本編開始とし、マイナス2フレーム(29.97fpsなら00:59:59.28)からのLTCです。2フレームは01:00:00.00を確実に掴んでもらうためのノリシロですが、普段の音源編集でも0.05秒程度のノリシロ(余白)を付けているので問題無いと思います。

 吉と出るか凶と出るか。

 そうそう、VLCをベースにするなら映像を元にしてもLTCが出せそうです。

#器具の製作 #タイムコード
Icon of admin
 オレメモです。

 LTCジェネレーターの制御は、パソコンやらRaspberryPi(以下、母艦と呼称)でLTCのバイナリを生成し、PICで所定のbpsの差動バイフェーズに変換することにします。
 PICにはFIFOバッファーを構成しようと思っていますが、母艦からPICへの送信がバッファオーバーフローか遅延にならない様にタイミングを考慮しないといけません。PICから母艦へデータ送信要求(許可)をする方法が必要でしょう。FT232RLはフロー制御も出来ますからそれを使ってもいいのですが、RaspberryPiのUARTにはフロー制御がありません。GPIOを直接制御してその様な信号を作ってもいいのですが、フロー制御を持ちなくても済むならそれに越したことはありません。UARTはデータを双方向でやり取りできますので、PICから母艦へデータ送信要求を送ることにしましょう。
 SMPTE12Mのフォーマットを8bit(1byte)区切りで見ますと、バイナリグループのビットを常に0にすることが条件ですが、上位4bitは0x0,0xB,0xF,(0x3)のどれかにしかなりません(0x3は逆再生した際にシンクワードで発生する値)。これ以外の値ならば制御コードとして使えます。ASCIIテキスト制御ではありませんから0x00と0xFF以外なら何でもいいので、双方で使える制御コードにしておけば後でわかりやすいかなと。
 この場合、上位4bitは0x5か0xAが一般的でしょうか。2進数ならb0101またはb1010です。0x7F以下のASCII文字になる値がデバックしやすいかもしれないので0x5かな。
 例えばですが、

0x50 初期化(LTC送信停止・バッファクリア)
0x51 これに続くデータは設定データ(設定はfpsとDF/NDF)
0x52 これに続くデータは送信データ
0x57 データエンド
0x58 データ受信要求
0x59 データ送信要求
0x5F データ(動作)エラー


 こんな感じ?

 後はbpsの精度をどこまで求めるかです。
 タイムコードの項に延々と書いていますが、波形周期を得るタイマー割込みのコンペア値を動的に変化させることで長周期の精度を水晶発振子の精度ギリギリまで出すことは可能です。ですが、どこまでの精度が必要なんでしょうね。

#器具の製作 #タイムコード
Icon of admin
 連休が終わってしばらく現場がありません。開発やらメンテナンスをする余裕が出ました。

 LTCジェネレーターの研究を進めてみます。
 これは「LTC Sound Player」で使うタイムコードジェネレーターで、UARTで受信したデータをPICで送出する物です。間にFT232RLを繋げばパソコン等からUSBでも制御出来るハズです。
 FT232RLはUSBシリアル変換ICです。比較的簡単な回路で動き、ドライバは最近のOSなら予め入っているか自動でインストール出来ます。
 FT232RLのいいところはMacでもWindowsでもLinuxでも使えることです。アプリケーションからは極々シンプルなシリアルデバイスに見えるので、大半の開発言語の標準ライブラリで扱うことが出来ます。
 当初C言語で開発しようと思ったのですが、音源再生やらLTCジェネレーターの構成を考えていくとPythonを用いるのが良さそうです。巧く書けばMacでもWindowsでもLinux(RaspberryPi)でも使えるモノになるからです。

#器具の製作 #タイムコード
Icon of admin
 昨日に引き続きバレエ発表会です。
 道具の転換だけですからリハ中の今はヒマなのでアイデアを整理しています。

 課題は「LTC Sound Player」です。
 wavやmp3の音源プレイヤーですが、再生している音源と並列のLTCも出力します。先日も書いたネタですが、折角の空き時間ですから改めて整理しています。
 音源再生にはVLCのライブラリであるlibvlcを使います。もっと直接的にOSとやりとりする方法もあるようですが、フォーマットやコーデックの違いをVLCが吸収してくれるので頼った方が間違いありません。記述はC言語系ならC++ですから勉強が増えますが、Pythonなら比較的簡単に書けそうです。
 LTCの出力にはPICを挟みます。LTCの変調は差動バイフェーズですが、RaspberryPiには専用モジュールはありませんし、ソフトウェアで波形を起こすよりPICを使った方が自分には簡単です。RaspberryPiとはUARTやSPIで通信します。
 レイテンシーを管理したガチの業務用ならC++記述しなければなりませんが、とりあえず作ってみようならPythonでイイと思います。

#器具の製作 #タイムコード
Icon of admin
 今週末はバレエ教室の発表会です。
 舞台監督でも照明でもなく道具屋です。ガチ公演ではありませんから、リノを敷いてジョーゼットを主にした飾りを休憩転換するだけで忙しくはありません。
 以前も書いたような気がするのですが、リノの掃除方法をオレメモ。
 基本は水拭きですが、重曹を少し入れると松ヤニやスモークオイルが落ちやすい様です。1リットル当たり大さじスリ切り1杯の割合です。いわゆる床掃除に使う濃度に比べたら薄いのですが、このくらいだと乾いても白く粉を噴きませんので中和拭きをしなくてもいいかなと。施工は農薬散布器で軽く噴霧して乾いたモップで拭きます。散布量の目安はリノを2-3本拭いてモップがやや湿る程度。乾くまでは少しヌルヌルしますが、乾けば本来のグリップに戻ります。松ヤニやオイルの付着が気にならなければ重曹の使用は3回に1回くらいにした方が良さそうでもあります。
 スモークオイルが落ちない場合は重曹の濃度を3倍程度にしてオイルを落とし、クエン酸溶液で中和拭き、水で仕上げ拭きと進めます。

#本業
Icon of admin
 TRUE1のT分岐は完成した感じです。
 ケーブルをハウジングに通してからレセプタクルに取り付けるのでケーブルの余長を押し込むことになりますが、この際の捩じりやコジる力がタブ端子にかかって半抜けになることがあるのです。組んだ後に中を確認することは出来ませんから対策が必要でした。前の書き込みでハンダ付けを試しますなんて書いたのですが、ハンダが馴染む温度ではTRUE1側が溶けてしまい使い物になりません。
 ちょっと発想を変え、ハウジングに収まる範囲でケーブルを出来るだけ長くしてみました。ハウジングの中で余裕を持ってトグロを巻ける様にしたらタブ端子に負荷がかからないのでは?というアイデアです。チーズを太くしたために可能になった方法です。
 結果から言うとビンゴです。組み上げてから数日おいて分解してみましたが半抜けの気配すらありません。
 TRUE1の取り付け部に水漏れ防止のコーキングを挿して本組みです。

 ちなみに、求める水対策性能は「防水」ではなく「防滴」です。水に浸すのはNGですが、水がかかるのはOKという意味です。
 防滴を考える上で気を付けなければならないのは狭い隙間です。毛細管現象で水が吸い込まれていくからです。明らかな水の進入路をコーキングで塞ぐのはもちろんですが、こういったところも気を付けるべきです。

 先に製作していたアルミ角パイプを使う方法も進めています。あとはコーキング処理だけだったのでお休みしてました。
 これも分岐ですが、ケーブルの方向性からY分岐と呼びます。

#器具の製作
Icon of admin
 今年の連休はちょいと忙しい。
 難しい物件はありませんが、事前準備が多い依頼が続いています。準備は一通り終わっているので気は楽ですけど。
 今日は午前中にリノ敷きだけなので午後は休もうかな。

 作りたい物(=欲しけど市販品に無い物)のネタが溜まっています。早く形にしたいのですが、製作経験のある物とは限りませんので何かと手間がかかります。
 限られた時間の中で何を優先するか悩ましい。
 Art-Netパッチやタイムコードプレーヤーも進めたいのですが、アタマを全振りしないと太刀打ち出来ないこれらの品物は空き時間にちょっと進めることは出来ません。
 今のところ片手間に進められるTRUE1分岐を試作っていますが、連休中にこれらの仕様が固まればいいかな
 次をどうするかは連休が明けてから考えましょう。

#雑談

■思ってみた

社屋を囲む田んぼの田植えが終わり季節を感じます。

編集

■複合検索:

  • 投稿者名:
  • 投稿年月:
  • #タグ:
  • カテゴリ:
  • 出力順序:

■日付検索:

■カレンダー:

2023年5月
123456
78910111213
14151617181920
21222324252627
28293031

■カテゴリ:

■最近の投稿:

最終更新日時:
2025年6月22日(日) 15時27分49秒