2023年5月 この範囲を時系列順で読む この範囲をファイルに出力する
オレメモです。
LTCの差動バイフェーズのクロックをPICで起こす計算です。
Fosc32MHz(8MHzPLLx4)にすると、Timer1でコンペアモードとするクロックは最速で8MHz。
1時間は3,600秒。
8MHzで1時間カウントすると28,800,000.000.カウント。
1時間あたりの総カウント数をこれに近づける。
CCPRxH/Lに与える値は次の通り。
● 30fps(2,400bps相当)
ベース値は1,666.
3回に2回、1,667.にする。
(1,666count×2,400bps×2倍周期×3,600秒)
+(((2,400bps×2倍周期×3,600秒)÷3)×2)
=28,800,000,000.
誤差無し
● 29.97fps(30÷1.001fps、約2,397.602bps相当)
ベース値は1,668.
3回に1回、1,669.にする。
(1,668count×2,397.602bps×2倍周期×3,600秒)
+((2,397.602bps×2倍周期×3,600秒)÷3)+0.25
=28,800,000,000.004238...
誤差 004238...
水晶発振子の精度からして十分だと思う。
※ 最後の+0.25は4時間1回+1するって意味。タイムコードは24時間時計なので因数だからいいかな。
● 25fps(2,000bps相当)
ベース値は2,000.
(2,000count×2,000bps×2倍周期×3,600秒)
=28,800,000,000.
誤差無し
● 24fps(1,920bps相当)
ベース値は2,083.
3回に1回、2,084.にする。
(2,083count×1,920bps×2倍周期×3,600秒)
+((1,920bps×2倍周期×3,600秒)÷3)
=28,800,000,000.
誤差無し
以前の計算と何か違うのだけど、まぁいいか。
#器具の製作 #タイムコード
LTCの差動バイフェーズのクロックをPICで起こす計算です。
Fosc32MHz(8MHzPLLx4)にすると、Timer1でコンペアモードとするクロックは最速で8MHz。
1時間は3,600秒。
8MHzで1時間カウントすると28,800,000.000.カウント。
1時間あたりの総カウント数をこれに近づける。
CCPRxH/Lに与える値は次の通り。
● 30fps(2,400bps相当)
ベース値は1,666.
3回に2回、1,667.にする。
(1,666count×2,400bps×2倍周期×3,600秒)
+(((2,400bps×2倍周期×3,600秒)÷3)×2)
=28,800,000,000.
誤差無し
● 29.97fps(30÷1.001fps、約2,397.602bps相当)
ベース値は1,668.
3回に1回、1,669.にする。
(1,668count×2,397.602bps×2倍周期×3,600秒)
+((2,397.602bps×2倍周期×3,600秒)÷3)+0.25
=28,800,000,000.004238...
誤差 004238...
水晶発振子の精度からして十分だと思う。
※ 最後の+0.25は4時間1回+1するって意味。タイムコードは24時間時計なので因数だからいいかな。
● 25fps(2,000bps相当)
ベース値は2,000.
(2,000count×2,000bps×2倍周期×3,600秒)
=28,800,000,000.
誤差無し
● 24fps(1,920bps相当)
ベース値は2,083.
3回に1回、2,084.にする。
(2,083count×1,920bps×2倍周期×3,600秒)
+((1,920bps×2倍周期×3,600秒)÷3)
=28,800,000,000.
誤差無し
以前の計算と何か違うのだけど、まぁいいか。
#器具の製作 #タイムコード
PythonでVLCライブラリを使った音源ファイルの再生は驚くほど簡単。
インストールするべき諸々や音源モジュールの設定などもありますが、貴兄のサイトにいくらでもあるのでここでは割愛。
VLCで再生が出来、Python本体とPython-VLCがインストールされていればいいと思います。
以下、sound.mp3を再生するPythonのコード。
import vlc
if __name__ == '__main__':
p = vlc.MediaPlayer() #vlc.MediaPlayerのインスタンスを作成
p.set_mrl('sound.mp3') #インスタンスに音源ファイルを関連付け
p.play() #再生開始
こんだけです!
vlcのインスタンスを宣言し、音源ファイルを設定し、再生を指示するだけ。
再生はバックグラウンドで行われるので、マルチスレッドを使うことなく再生中に他のことが出来るのも良点。
ちなみに「p」はインスタンス名なので自由に定義して良いようです。
Python-VLCはC言語などが使うlibVLCをPythonから呼び出せるようにしているので、libVLCで出来ることの大半が出来るようです。
以下基本的なAPI。
p.set_mrl('sound.mp3') #インスタンスに音源ファイルを関連付け
p.play() #再生開始
p.pause() #再生中なら一時停止、一時停止中なら再生再開
p.get_time() #開始からの経過時間を取得(msec.)
p.set_time(1000) #指定した秒数(msec.)にセット
p.audio_set_volume(100) #0=mute,100=0dB(パーセント指示だと思っていいみたい)
p.stop() #停止
やりたいことはこれだけで済んでしまいそうな気もする。
python-vlcのドキュメント
沢山の事が出来るようですが、
vlc.MediaPlayer
の項を読むと上記のことがわかります。
#Python
インストールするべき諸々や音源モジュールの設定などもありますが、貴兄のサイトにいくらでもあるのでここでは割愛。
VLCで再生が出来、Python本体とPython-VLCがインストールされていればいいと思います。
以下、sound.mp3を再生するPythonのコード。
import vlc
if __name__ == '__main__':
p = vlc.MediaPlayer() #vlc.MediaPlayerのインスタンスを作成
p.set_mrl('sound.mp3') #インスタンスに音源ファイルを関連付け
p.play() #再生開始
こんだけです!
vlcのインスタンスを宣言し、音源ファイルを設定し、再生を指示するだけ。
再生はバックグラウンドで行われるので、マルチスレッドを使うことなく再生中に他のことが出来るのも良点。
ちなみに「p」はインスタンス名なので自由に定義して良いようです。
Python-VLCはC言語などが使うlibVLCをPythonから呼び出せるようにしているので、libVLCで出来ることの大半が出来るようです。
以下基本的なAPI。
p.set_mrl('sound.mp3') #インスタンスに音源ファイルを関連付け
p.play() #再生開始
p.pause() #再生中なら一時停止、一時停止中なら再生再開
p.get_time() #開始からの経過時間を取得(msec.)
p.set_time(1000) #指定した秒数(msec.)にセット
p.audio_set_volume(100) #0=mute,100=0dB(パーセント指示だと思っていいみたい)
p.stop() #停止
やりたいことはこれだけで済んでしまいそうな気もする。
python-vlcのドキュメント
沢山の事が出来るようですが、
vlc.MediaPlayer
の項を読むと上記のことがわかります。
#Python
頭の区切りが付かないので、LTC-Generatorの回路図を描いてみました。

FT232RLを使ってPICにUARTを送る
→ PICで所定のbpsの差動バイフェーズ化する
→ PICの出力を分圧して約1vp-p(要は2v)にする
→ オペアンプの1:1ボルテージフォロア回路で音声信号化
→ 出力
といった簡単な構成です。
1vなので音声信号としては約+3dBです。
グランドループさせない様にした方がいのかな?
追記
気分が乗って描いてしまった基板の3D図も揚げます。

折角なので発注しました。
本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ~。
#器具の製作 #タイムコード

FT232RLを使ってPICにUARTを送る
→ PICで所定のbpsの差動バイフェーズ化する
→ PICの出力を分圧して約1vp-p(要は2v)にする
→ オペアンプの1:1ボルテージフォロア回路で音声信号化
→ 出力
といった簡単な構成です。
1vなので音声信号としては約+3dBです。
グランドループさせない様にした方がいのかな?
追記
気分が乗って描いてしまった基板の3D図も揚げます。


折角なので発注しました。
本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ~。
#器具の製作 #タイムコード
タイムコードの使用にあたり卓(MAdot2)の挙動で重要となるのは次の点です。
・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。
取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
注意点が2点あります。
1)CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
2)卓に入力されるタイムコードの有効無効を操作出来なければならない。
(1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(1曲あたり10分割振りとか)。
(2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。
一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな?
その筋に詳しい音響担当に相談していますのでしばらく待ちです。
・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ~。
#タイムコード #器具の製作
・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。
取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
注意点が2点あります。
1)CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
2)卓に入力されるタイムコードの有効無効を操作出来なければならない。
(1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(1曲あたり10分割振りとか)。
(2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。
一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな?
その筋に詳しい音響担当に相談していますのでしばらく待ちです。
・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ~。
#タイムコード #器具の製作
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の前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード
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)のデータを送り続けるのです。試すしかありませんが、アクティブな一時停止が実現出来れば手段が広がるように思います。
#器具の製作 #タイムコード
トリガータイムは手打ちも出来ますが「TC Record」機能を使えばLTCを受けながら「GO」を押すことでタイムが取れます。タイムの修正も現在値に対するプラスマイナスで行えます。
ただし、LTCが走り出してから認識するのに0.3sec.程度かかります。また、エグゼキューターをOffにしておいてもその時刻が来るとCUEが走ってしまいます。
装置を構成するには卓の挙動をよく観察しないといけませんが、一度覚えさせればその通りに再現してくれる感覚は良いですね。
追記
LTCの認識は同じ値を送り続けたら解決出来るかもしれません。スタートするまで1フレーム前のデータを繰り返し送り続けるのです。1:00:00.00からスタートするなら0:59:59.29(29.97fps)のデータを送り続けるのです。試すしかありませんが、アクティブな一時停止が実現出来れば手段が広がるように思います。
#器具の製作 #タイムコード
「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が出せそうです。
#器具の製作 #タイムコード
音源を加工せずに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が出せそうです。
#器具の製作 #タイムコード
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105