2023年5月10日の投稿[4件]
TRUE1のY分岐とT分岐の試作は繋ぎ目にコーキングを入れて終わりました。
数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでOKなら防滴性能があるとしていいでしょう。
#器具の製作
数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでOKなら防滴性能があるとしていいでしょう。
#器具の製作
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ジェネレーターならすぐ作れそうです。
#タイムコード
ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
これならPICのUARTで誤差無しで扱えます。
送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。
凄くシンプルなMTCジェネレーターならすぐ作れそうです。
#タイムコード
パソコンの音声再生アプリにはタイムコードを出す物があるらしい。
様々なアプリがあるので一概に言えませんが、タイムコードは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の前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード
様々なアプリがあるので一概に言えませんが、タイムコードは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の前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード