2023年6月1日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 MUSES02D化したDI-1はとても良い音ですが、どこか物足りない。オペアンプが鳴りきっていないというか躓いているような気がするのです。勘ですが、入口か出口のコンデンサがMUSES02Dに対して性能不足の様に感じます。
 当初はオペアンプの交換に留めようと思ったのですが、コンデンサは安価で元に戻すのも簡単なので試してみようかと。
 別な部品と共にコンデンサも手配しました。

#音の世界
Icon of admin
 気分転換にFIFOを書いてみました。初期設定を含めても50行くらいです。
 ループメモリを非同期で読み書きする構造ですから、それぞれのアドレスカウンタの扱いが肝です。当初悩んだものの、条件を整理すれば案外簡単でした。アルゴリズムの設計大事です。
 こういったモジュールは例外も想定して慎重に動作確認をしなければなりませんが、実機だと確認が難しいのでMPLABXのシュミレータの出番です。ステップ毎のレジスタの変化を観察したいのです。
 MPLABXのシュミレーターは使い方がイマイチわからんのですが、操作メニューが違うだけでやることはv8.92と同じでしょうから、先達の書き込みを参考に探ってみます。

追記
 シュミレーターの使い方は次のサイトがわかりやすい。というか、この通りにやったらシュミレート出来ました。
 MPLAB X の使い方(Simulator編)
 MPLABv8.92とはデザインが違いますが、やっていることは同じなので慣れればいいかなと。PICの中身を知らないと何が何やらですけど・・・
 テスト用に少し書き換えればFIFOの挙動をチェック出来ます。

#PIC
Icon of admin
 FIFOの動作チェックをしました。
 バク無し・・・嬉しいような怖いような。
 FIFOはループメモリです。例えば10個のメモリを使うなら10個目を書いた後は1個目から書きます。これを続けます。読出しも同じ。
 ただ、読出しと書き込みはタイミングがシンクしませんので、読出しが書き込みを追い越さないこと、書き込みは一周以上先行しないことが重要です。これらの確認も出来ました。
 処理のタイミングとしては、読出しはLTCの送出に合わせてになりますが、書き込み(パソコンへのデータ要求とも言う)はメモリが空いたら行います。
 パソコンとの通信速度がLTCの送信速度より十分に速く、パソコン側のレスポンスも十分に早ければタイミングがズレることはありません。たぶん。
 読出しが書き込みに追いついてしまえばデータが無いことになりますので、新しいデータが入るまでLTCを送出しないだけです。

#PIC #タイムコード

2023年6月2日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 FIFOなど、諸々書き加えたファームウェアも正常に動きました。
 自分で書いた送出停止処理の扱いを間違えて信号が出ないことに悩んでしまいましたが、テストプログラムが間違っていただけでした。肝心のモジュール本体は一発OKです。
 今回のPICはパソコンから送られてきたデータを淡々と差動バイフェーズで送り出すだけです。難しいことはパソコンでやれと、PICの名前の由来を考えろと。そんな作りです。
 データを差動バイフェーズで送出することは出来た。データのタイミング緩衝となるFIFOもどうやら正常に動く。残るはパソコンとの通信です。FT232RLを経由したシリアル通信ですが、PIC側はDMXで散々やったことですし、パソコン側はPythonなのでほんの数行で書けます。10分の空き時間で進められるものでもありませんけどね。

 あとはラインセレクタも必要です。
 音響さんからもらう本線LTCと自分のパソコンから送るチェック用LTCの2系統を切り替える必要があるからです。
 セレクタにはJRCさんのNJM2750が良さそうです。単電源で動く電子ロータリースイッチってイメージですね。
 NJM2750はアンバランスのLRを4系統から1つ選ぶって構成ですが、バランスのモノ4系統として使っても良さそう。
 今回はそこまで使わないけど、4系統のラインセレクタ基板を作っておけばいいかな?

#PIC #タイムコード #電子工作
Icon of admin
 LTC Generator のプリアンプは回路を手直ししてOKになりました。
 バイアス電圧を当て、反転増幅回路の出力端子とマイナス端子の間の抵抗と並列に20pFのコンデンサを入れて解決しました。
 波形を示さないとわかりにくいのですが、コンデンサを入れる前は妙なノイズが出ていたのです。音声ではなく矩形波ですから周波数特性はそれほど気にしませんが、ノイズというか別波形が足されている状態はいただけない。
 回路修正用の基板も発注したので、プリアンプはとりあえずOKかな。

#PIC #タイムコード

2023年6月4日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator のPICはFIFOにデータを突っ込んで波形が出力するまでまとまりました。
 内部のテストルーチンによるものですが、データのリレーはシュミレーターで、波形はオシロスコープで確認出来たので、最も面倒な部分が成立した模様です。
 昨日一見動いたものの波形が安定せず悩みましたが、バグを手直しして今は期待した波形が出ています。0x00や0xFFはもちろん他の数値もOK。オシロスコープのトリガが引っかからず波形が読み取れない数値もありますが、この値が確認出来ればいいでしょうって値はいけたので、デバイスドライバ的なところが終わったと言えます。

 今後の課題はパソコンとの通信です。PIC側は過去実績、パソコン側はライブラリに頼れば左程難しくないハズ・・です。パソコンから受信した値をFIFOに突っ込んで期待した波形が出れば重要な機能は完了です。
 完成に至るには、PICからパソコン側にデータ送信の要求を送ったり、コマンドでfpsのモードを切り替えたりと課題は残っていますが、ハードウェアとデバイスドライバ的な部分がまとまればハードルは低くなります。

 ちなみに、今作っているのはシリアルで受信したバイトデータを差動バイフェーズで出力するだけの物ですから、TASCAMのプレーヤーのリモコンと組み合わせることも可能(正しくは不可能ではない)です。曲ごとのタイムコードをユニークする方法を考えなければなりませんが、これはこれで欲しい一品です。
 当然リモコンはフルスクラッチとなりますが、出来るだけ音響さんの環境を変えないためにこういった発想もありかなと。

#PIC #タイムコード
Icon of admin
 以前から考えていたことですが、MTCのデータを差動バイフェーズで送るのはどうかなと。
 データ構成はLTCよりMTCの方が簡単です。通信インフラはMTC(MIDI)より差動バイフェーズの方が選択肢が多く遠距離でも使えます。双方のいいとこ取りをしたらどうかって発想です。
 LTCに比べMIDIの方がビットレートは速いのですが、MIDIを占拠しないためにMTCのデータレートはLTCより遅いのです。通信媒体を占有するならLTCベースでもMTCを送ることは可能です。
 なぜこうするかいうと、専用の通信インフラを使わず、音響さんに迷惑をかけずに音響回線を借りられたら汎用性が高いと思うからです。LTCは電気的には音声信号相当ですからダンテなどのEtherも通せます。
 差動バイフェーズとUARTの変換は作らねばなりませんが、この変換はタイムコードに限らず他の制御にも使えると思うのです。データレートの制限はありますが、MSCをマイクケーブルで送れたらいいなぁ~なんて妄想してます。

#電子工作

2023年6月5日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator の今の課題はPCのPythonからデータを送ってそれに則した差動バイフェーズの波形を出すことです。
 シリアル通信とコマンド処理を書き加えました。シュミレータでは思った通りの挙動をしたので次は実機テストです。
 ですが、この時間なので流石に寝ないといけません。デバグがすんなり終わればいいのですが、夜明けを迎えたら明日に差し障りそうです。
 いささか力尽きましたし、シュミレータでの確認が済んで気分的にも区切りが付いたので今夜は終わりにします。
 明晩、Pythonでシリアル通信して挙動を確認します。思った様に動けばPICのファームウェアは投了です。

#PIC #タイムコード
Icon of admin
 改造したDI-1の主要なコンデンサも変えてみました。音響用として評判が良いニチコンのコンデンサ達です。
 MUSES02Dにしても改善されなかった特定の響きがスッキリと抜ける様になりました。特にガットギターの音源では使い古した弦と新品の弦くらい響きが違います。
 ダイレクトボックスは楽器の音声信号をミキサーに入れるためのレベル変換ですから、演奏者が奏でるニュアンスを出来るだけ正確にミキサーに渡すのが仕事です。この改造の発端はDI-1を通すと正確さに掛けるのではないか?という疑問からです。何を以って正確かというと難しいですが、「DI-1なら弦を新しくしなくてもよかったなぁ~」などと演奏者に言われてしまうならば正確ではないのだろうと思っています。イメージとしては、高域を膨らますというより、響きや余韻を出来るだけ多くミキサーに渡したいといったところです。
 今のところ、圧倒的な変化が起こっている訳ではありませんので売りは弱いですが、繊細な響きや余韻といったDI-1が苦手なところは改善されています。演奏者からすればこの辺りが大事だと思うので良い変化だと考えていますけどね。
 最終判断は、手持ちに無かった物を替えてエージングした後になります。

 新規開発や改造などの話は、モノの良し悪しより「誰が評価したか」が重要です。または、成り行きで使い続け、しばらくして以前の物に戻ってみたら物足りなさや不便を感じて意味を発見する、といった物語が必要です。残念ながら、自分の価値基準でゼロベースの評価をできる人は極めて少数です。ですので、社内でプレゼンすることは労力の無駄かもしれませんw
 誰に試作品を送ろうかな・・・

#音の世界
Icon of admin
 秋月電子通商さんからコンデンサが届きました。お昼休みのお遊びで交換。
 エージングはこれからですが、DI-1の欠点だと思う響きや余韻の鈍さが驚くほど改善されました。ガットギターやアコースティックギターの音が気持ちいい。
 もちろん、ハイ上がりで尖った音ではありません。柔らかくて自然な明瞭さのある音です。

 オレメモですが、以下が交換した部品です。

● オペアンプ
 MUSES02D(変換基板使用)
● コンデンサ
 C1 フィルムコンデンサー 0.01μF50V ルビコンF2D
 C2 オーディオ用無極性電解コンデンサー10μF25V85℃ ニチコンMUSE・ES
 C3 オーディオ用無極性電解コンデンサー10μF25V85℃ ニチコンMUSE・ES
 C5 オーディオ用無極性電解コンデンサー47μF50V85℃ ニチコンMUSE・ES
 C6 オーディオ用無極性電解コンデンサー47μF50V85℃ ニチコンMUSE・ES
 ※ C1~C6は基板上の部品名です。

 送料は除きますが、部品総額3,800円くらいかな?
 変換基板は手前設計の中華製造ですけど。

 C1も無極性電解コンデンサーにするか悩みましたが、ハイインピーダンスのピックアップと直結しますから高レスポンスなフィルムコンデンサーにしました。元々もフィルムコンデンサーです。このフィルムコンデンサーは低ノイズ・高レスポンスなので調光回路に使っても良かった物です。なので手元にあったのですけどw
 今日交換したのはC2とC3です。オペアンプの入力部に使うバイアスフィルタコンデンサですが、コンデンサの中で最も変化が大きかったかもしれません。
 なお、C2とC3は耐圧25v以下の物でないと基板に入りません。C1、C5、C6はファンタム電源に曝される可能性があるので耐圧50vの物でないと壊れると思います。

 MUSES02Dに替えてもイマイチ改善しきれなかった音の響きや余韻が改善しましたので、オペアンプはそのままにコンデンサだけ替えてもいいかもしれません。上記のコンデンサを全部替えても130円ですし、付け替えも普通にハンダゴテが使えれば簡単に出来ます。純アナログの部位なので、良い部品にすれば必ず良い結果になるとは言えないのですけどね。

 憑き物が落ちて肩が軽くなった気分です。

追記
 C2とC3を別なコンデンサにしました。原因は不明ですが、時間経過と共に音に張りが無くなったためです。
 次のコンデンサにしたところ、高域がまろやかで伸びのある音になりました。
 C2 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW
 C3 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW

#音の世界
Icon of admin
 DI-1はバイアスフィルタコンデンサを交換してエージングすること6時間。とりあえずのチェック。
 呆れるほどの明瞭感。ハイ上がりでキャンキャンしているワケではありません。バランス感に疑問はありません。ガットギターは胴の響きを感じ、生ベースはブンブンゴリブリとエグイ鳴りをし、ヴァイオリンは弓が擦れる音まで目の前に見えます。生々しい感じが強調されているので嫌いな人がいるかもしれませんが、ダイレクトボックスではなくエフェクターと考えれば納得!?
 良いとか悪いとかではなく、DI-1とは全くの別物になってしまいました。私は改造品の方が楽器が出している音をダイレクトにミキサーに渡せるような気がしますが、現場で使えんのかな?
 エージングが終わったら布教活動という名の人柱募集でもすっかな。

 そういや、オペアンプはMUSES、コンデンサはMUSEです。
 MUSEとは芸術全般を司るギリシャ神話の女神様だそうな。
 何か名前を付けないとなぁとは思っていましたが、命名にこだわりはありませんので、DI-1MUSEとします。

#音の世界
Icon of admin
 困ったことに LTC Generator が一発で動いてしまいました。デバグのために本業を途中で切り上げ、午前様を覚悟していたのに実作業15分で終わってしまいました。ここまでデバグせずに進んだのは初めてかもしれません。
 何をしたかと言うと、Pythonからシリアルでデータを送り、それに則した波形を出し、コマンドコードで波長を切り替えるというもの。実験用に一部書き換えましたが、どうやっても想定の結果が出ます。
 予想より早いですが、実際にタイムコードを出してみる段階になってしまいました。プリアンプの改修基板は明日入荷なのでいいか。
 仕方ないのでPythonのプログラムの構想を始めましょう。まずは固定値のリストで2-3秒出すところからです。

 そりゃ嬉しいけど、機械たちにスルーされているみたいでなんだか寂しい。
 こんなにすんなりいくと何かありそうで怖い。

#PIC #タイムコード

2023年6月6日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 あまりにすんなり動いたので忘れてましたが、FT232RL凄いです、便利です。こんな素晴らしいデバイスをナゼ今まで使わなかったのか自分にクレームです。
 Pythonのシリアルも無茶苦茶簡単、PICのシリアルも設定が少し分かりにくいけど数行のアセンブラで送受信できて簡単。
 先人が作ってくれた素晴らしいシステムたちに感謝です。

#PIC #Python #電子工作
Icon of admin
 今後はLTCをMTCに変換する方法も考えましょう。
 LTCをバイトデータとして受信し、MTCのパケットに書き直して31,250bpsのUARTで送出すればMTCになります。

 オレメモです。 

 PICには「変化割込み」と呼ばれるI/Oピンの入力が変化すると割込みが発生する機能があります。これとタイマーを組み合わせれば波長の計測が可能です。
 PICのクロックを32MHzにした場合、LTCの波長は命令ステップ(Fosc/4)換算でビットが1なら1,666から2,083、0なら倍の3,332から4,166です。誤差10%としても1の最大値(2,291)と0の最小値(3,029)は被りませんしグレーゾーンも広いので、波長の判別はfpsの種類に関係なく可能です。fpsやフォーマットの種類はLTCのデータに書かれているので計測した波長から判断する必要はありません。
 差動バイフェーズのビットは短い波長が2つ続けば1、長い波長が1つで0です。ビットデータが取れたら80bitのシフトレジスタに入れていきます。短い波長は必ず2回続きますから、長い波長の直前の短い波長が奇数回ならエラーとして仕切り直しです。80bitのシフトレジスタの末尾16bitにシンクワードが認められれば正常なLTCパケットが取得できたことになります。
 LTCパケットが取得出来ればMTCパケットを作り、入力されたLTCに基づいたタイミングで31,250bpsに設定したPICのUARTから送出します。後は電気的にMIDIにすればMTCです。
 必ず3フレーム遅れますが、欲しいのは絶対値ではなく相対値ですからいいかなと。

 プログラムが求めるメモリサイズ次第ですが、8pinの12F1822で作る予定です。

追記
 LTCにはfpsフォーマットを記載する領域はありません。訂正します。NDF/DFは記載されます。
 fpsフォーマットをデータに記載するのはMTCです。
 ですので、LTCの場合は波長からfpsフォーマットを推測します。

#PIC #タイムコード
Icon of admin
 DI-1MUSEはコンデンサを替えて24時間経過。
 音が鈍ったというか、明瞭感が弱くなっています。コンデンサを替える前と大差ない印象。
 先行して替えたコンデンサでも24時間経過で一度鈍くなり48時間経過で戻る現象がありました。コンデンサのエージングはそういうものなのかもしれませんが気分は萎えます。

追記
 確実ではないのですが、ピンクノイズを当てた直後は音が鈍るものの、通常の音源を数時間当てると音が戻るようです。通常の音源を3時間くらい当てて再チェックしたところ、昨日のイイ感じに戻っていました。
 この話だけですとピンクノイズは余計なことに感じますが、ピンクノイズを当てて通常音源を当てると明瞭なだけでなくまろやかさも加わりますので、エージングには良いように思います。
 音源100時間、ピンクノイズ100時間、音源100時間の設定で続けています。現在ピンクノイズ30時間。

#音の世界

2023年6月7日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator は入荷した修正基板を用いてプリアンプが完成。+4dB(1.23Vp-p)の波形を出しています。
 まだPythonプロンプトのレベルですが、シリアルでデータを送ると波形が変化します。Pythonからデータを送る場合、バイト毎ではなく、配列にバイナリを格納してpyserialに渡すのが良さそうです。
 タイミングが正しいかは確認出来ませんが、PICからの送信要求も受信出来ています。これを受けてデータを送る段取りです。

 本業が詰まっていますのであまり長い時間は出来ませんが、1日0.5課題くらいの気持ちで少しずつ行きましょう。

 明晩は仮のLTCデータを送出するPythonプログラムを書いてみます。
 あらかじめ2-3秒分の配列データを作っておいて送信要求があれば1フレーム分送出する物ですが、卓に接続してLTCがカウントされれば最大の山場を越えます。

#PIC #タイムコード
Icon of admin
 今後のこともあり、移動時間にPICのI2Cを勉強し直してみました。
 これまではイマイチ理解出来なかったのですが、ボチボチ使い方がわかってきました。わからなかったのはハードウェアとソフトウェアの棲み分けとソフトウェアの手順です。
 I2Cの規格を頑張って説明するのはありがたいのですが、一番知りたいソフトウェアの手順がボンヤリした文書ばかり。ちょっと複雑な手順を踏むので突っ込んだ理解が望ましいのはわかるのですが、その説明で力尽きしまうのか、どとのつまりどうすればいいの?に応えてくれる資料が少ないように思います。特に、I2Cの特徴的な要素である「ACK」を扱うのがハードウェアなのかソフトウェアなのかが見えないのです。
 正直、Pythonなどではライブラリを使うだけで済んでしまいますので、いくらPICマイコンでもそこまでローレベルの機構まで理解しないといけないのか不思議です。

 わかったことは、設定さえしてしまえばソフトウェアの手順はUARTと大差ないことです。
 マスタが送信する場合はスレーブアドレスを先頭にしたバイトリストをハードウェアモジュールに渡す(PICではバイト単位で渡す)。
 マスタが受信する場合はスレーブアドレスを送り、返信されたバイトデータを取り込んだら取り込み済みのフラグを立てる。
 スレーブは、自分のアドレスを設定しておけば自分向けの通信かハードウェアが判断してくれるので、マスターの要望に従って受信値を取り込むか返信値を投げる。
 データの終りのストップコンディションは、マスター/スレーブ・送信/受信の立ち位置で違うけどフラグを立てるだけ。
 波形をコマンド操作で作るワケじゃありませんし、前後関係で調整することもありません。規格はザックリ概要がわかっていれば十分なのに、ソフトウェアの手順の説明がボンヤリしているのはイマイチ理解不能なワケです。

#PIC

2023年6月8日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 オレメモ

 windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew


 2回くらいやった方がいい。

#パソコン

2023年6月11日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator は24時間カウントの関数をPythonで書いてみました。限りなく本チャンに近いモノです。
 期待通りの動作をします。卓への接続テストはまだですが、オシロスコープには波形が出ます。
 ただ、24時間で約40秒の遅れが出ます。1時間あたり約1.7秒ですから無視出来ません。
 時間のクリックカウントはPICで行っていますが、TMR1のコンペア値が1個多いと仮定すると辻褄が合います。そういえば、TMR2でコンペアと同様の機構と思われるPWMを作る場合は折り返しで1カウント余計にかかるハズ。データシートには記載が見受けられなかったけど、TMR1のコンペアモードでも同様なのかもしれません。
 コンペアの定数値を変更して改めてテストしましょう。

#PIC #タイムコード
Icon of admin
 LTC Player には外付けスイッチが欲しい。
 RaspberryPipicoはUSBキーボードやマウスを簡単に作れるとのこと。
 てことは、picoでキーボードシステムを構築しといてもいい。USBのHIDはもちろん、UART、I2Cなども使える様にしとけば便利だと思われる。チャタリングを含めたセンシングのマトリクスと通信まで作っておくのです。
 picoについて調べてみましょう。

#RaspberryPi

2023年6月12日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator のタイマーを修正してみました。
 8時間経過で約1秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
 PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の1を表す単位なので比率だと0.00003)、1日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
 現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
 補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。

 秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
 求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。

#PIC #タイムコード

2023年6月13日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator は29.97fpsも25fpsと同等の誤差でした。30fpsと24fpsも同等に収まればPICのファームウェアは完成とします。
 比較に使っている時計はカタログスペックで月差±15秒。1日あたり0.5秒の誤差とみなせます。基準にするには十分でしょう。
 「卓がLTCとして認識するか」を早々に確認したいですね。これが一番重要です。

#タイムコード
Icon of admin
 LTC Generator は24fpsも他のfpsと同様の誤差に収まりました。現在稼働中の30fpsも確認出来れば LTC Generator はヒト段落です。
 本業もそこそこ忙しくなってきたので工作に使える時間は限られますが、LTC Player まで出来るだけ早く到達したいところです。

#PIC #タイムコード
Icon of admin
 RaspberryPi pico はとても面白いマイコンです。少なくとも私好みです。RaspberryPi のブランドですが、RaspberryPi の廉価版、簡易版ではなく、Arduino の親戚と思った方が自然な存在感です。想定される用途、ソースコードを書いてから実行に至るまでの流れが Arduino のそれととても似ています。
 純正の開発・実行環境は MicroPython と呼ばれるシステムですが、MicroPython からの派生品である CircuitPython を使うことで自由度が更に広がるようです。MicroPython がスタンドアロンでの実装を主眼としているなら、CircuitPython はPCなどの周辺機器を作ることを強く意識しているように思います。MicroPython、CircuitPython のどちらもとても良く整備された開発・実行環境だと思いますが、CircuitPythonの方が私の趣向に合っている気がします。実際、CircuitPython の存在を知って pico に興味を持ったのは事実です。
 pico のプロセッサはarm系32bit133MHzです。Arduinoは、高速化高機能化が進んではいますが、基本はAVR系8bitマイコンです。処理能力は pico に格段の優位性があります。その余裕を使って Python を動かしているとも言えますが、C/C++の開発環境を使えば攻めた造りも出来そうな気がします。また、pico は ArduinoIDE と呼ばれる Arduino の開発環境でもコーディング出来るので、Arduino に親しんだ方がシームレスに使えるメリットもあります。ArduinoIDE を用いてこれらのデバイスの開発環境を一本化するのもアリですね。

#RaspberryPi

2023年6月14日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Generator は30fpsも他のfpsと同様の誤差でした。時間の勘定に期待値が出たので PIC のファームウェアは一応の完成とします。あとは、卓が認識するかです。
 今後はPC側のアプリケーションの製作です。Pythonベースでvlcライブラリを使い、LTCとVLCは同時スタートの疑似シンクです。VLCの現在時からLTCを生成することは難しいからです。途中スタートではLTCの現在時からVLCの開始時を補正して合わせる様にします。
 音声ファイルはプレイリストとしてまとめ、スタートタイム、エンドタイム、ボリューム、連続再生、曲間時間などを個別に設定出来る様にします。複数の音声ファイルを並列で再生する用途は想定しませんので、1トラックのわかりやすいモノを目指します。もちろん、LTCのタイムが被らない様にチェックする機能も大切です。

#タイムコード
Icon of admin
 LTC Generator のLTC信号を卓(MA dot2)が認識しました。
 ただ、同じ値を送り続けても認識しません。LTCを入力してから認識するまで1秒弱かかるので、カウントを進めずに信号を認識し続ける方法が欲しいのです。
 試しに数フレームの繰り返しを組んでみたところ認識し、数フレームの繰り返しを一定回数行ってから抜ける様にしたところ期待する結果を得ました。
 最初のCUEポイントのマイナス数フレームの位置で2-3フレームの繰り返し待機をし、トリガが立ったらそれを抜ける考え方で良さそうです。
 ともかく、卓が認識したので一安心です。

#タイムコード
Icon of admin
 オレメモ

 PythonでVLCを使った音楽再生方法を再整理。

 Windows11x64
 Python3.7
 VLC media player ver.3.0.18

 pipでpython-vlcをインストール。
コマンドプロンプト(管理者権限にて)
> pip3 install python-vlc

 pipとはPythonのライブラリを提供してくれるリポジトリのこと。先達に感謝。

 pythonでvlcによる再生。
import vlc

if __name__ == '__main__':
 p = vlc.MediaPlayer()   #vlc.MediaPlayerのインスタンスを作成
 p.set_mrl('sound.mp3')  #インスタンスに音源ファイルを関連付け 相対パスも可能らしいがフルパス指定を推奨
 p.play()         #再生開始

 これだけで音声ファイルが再生されます。

 以下基本的なAPI。
p = vlc.MediaPlayer()       #vlc.MediaPlayerのインスタンスを作成
p.set_mrl('<file_name>')     #インスタンスに音源ファイルを関連付け 相対パスも可能らしいがフルパス指定を推奨 ファイルはVLC media player で扱える物なら何でも。
p.play()             #再生開始 戻り値 0=正常再生/-1=再生出来ない ※ pauseされていれば再生再開
p.is_playing()          #再生中か 戻り値 0=再生していない/1=再生中
p.pause()             #再生中なら一時停止、一時停止中なら再生再開 戻り値無し
p.get_length()          #音源の長さを取得 戻り値 秒数(msec.)
p.get_time()           #音源の最初からの再生位置を取得 戻り値 秒数(msec.)
p.set_time(<msec.>)        #再生再開位置を秒数(msec.)で指定 戻り値無し ※ 再生中やpause()中でないと指定出来ない
p.audio_set_volume(<パーセント>) #0=mute,100=0dB(パーセント指示だと思っていいみたい。100以上も指定可能。)戻り値 0=再生中に設定成功/-1=設定はしたが再生はしていない
p.stop()             #停止 戻り値無し 次回のplay()では最初から始まる
※ 最後まで再生しきっても、stop()をしないと次回のplay()はスタートしない。再生終了で必ずstop()を実行する。
※ 停止中は次の再生開始秒数を指定出来ないので、特定の秒数(msec.)から再生する場合は、play()に続いてset_time(<msec.>)を実行する。ただし、pause()中は指定可能。
p.play()
p.set_time(<msec.>)


 複数の音源ファイルをプレイリストとして扱ってくれるクラスもあるのですが、LTCを作るには少し不便がありそうなため、1曲単位で扱うことにしています。

 vlc.MediaPlayer()のリストを作成する。
p = ( [vlc.MediaPlayer(), vlc.MediaPlayer(), vlc.MediaPlayer()] )
# p[0]、p[1]、p[2] などと使える。

 普通にオフジェクトのリストとして扱える。

 これだけはメモ。
 リストのオブジェクトを追加する。
p.append( vlc.MediaPlayer() )
# 上記に続いた場合は p[3] が追加される


 再生操作のレスポンスはとても良く、タイムラグはほとんど感じない。
 ただ、プレイリスト分のインスタンスを設定するにはメモリに注意かもしれない。

参考
 python-vlcのドキュメント
 ここの「vlc.MediaPlayer」を参照。

#Python
Icon of admin
 python-vlc で音源を流す試験をしました。
 単に再生するだけなら簡単。
 ちょっと難儀したのは再生終了を確定する処理。再生後自動的にリセットされませんので、再生が終了したことを確認して後処理をしないといけません。
 vlc.MediaPlayer.is_playing()は再生中かどうかを把握出来ますが、これだけでは再生が終了したフェーズかわかりません。オレフラグ(下記ではis_playing)を併用して再生前か再生後かを判別します。再生後ならstop()を実行します。きちんとstop()しないともう一度再生が出来ないpython-vlc。
 下記は再生終了を確定する試験として繰り返し再生するモノです。

# -*- coding: utf-8 -*-

import time
import vlc

def play() :
 # 音声ファイルを定義
 play_music = ( [ vlc.MediaPlayer() ] )
 try :
  play_music[0].set_mrl( 'C:/音源.mp3' )
 except :
  return -1
 # 再生ボリューム設定
 play_music[0].audio_set_volume( 60 )
 # フラグ定義
 is_playing = 0  # 再生実行済みフラグ

 # Main Loop
 while True :
  try :
   # 予備睡眠
   time.sleep( 0.0001 )  # Ctl-Cの反応を良くするのに少しsleepを入れるといい
   # 停止中
   if( play_music[0].is_playing() == 0 ) :
    # 未開始で停止中
    if( is_playing == 0 ) :
     play_music[0].play()
     while ( play_music[0].is_playing() == 0 ) : # 再生状態が確定するまで待つ
      time.sleep( 0.001 )
     play_music[0].set_time( 0 )
     is_playing = 1
    # 再生終了で停止中
    else :   # if( is_playing == 1 ) :
     play_music[0].stop()  # 再生終了を宣言してインスタンスをリセットする 主にこれをやりたいがための処理
     is_playing = 0
   # 再生中
   else :
    pass   # 再生中に行う処理は書いていないのでとりあえずpass

  # Ctl-Cで終了
  except KeyboardInterrupt :
   play_music[0].stop()
   break
 return 0

if __name__ == "__main__" :
 play()



 python-vlc便利過ぎ。

追記
 vlc.MediaPlayer.get_length()とvlc.MediaPlayer.get_time()を使って再生が最後まで行ったかチェックしました。
 何曲か試しましたが、概ねlengthの-0.1~-0.2秒で終了しています。vlc.MediaPlayer.get_time()は取得単位の1msecで厳密にカウントされているモノでも無さそうなので表示上の誤差かもしれません。トラック別で音繋がり場合は少し不安がありますが、音のお尻には1-2秒の余白があるのが一般的ですし、そこまで突き詰めるシステムではありませんのでいいかなと。
 画面作りをやって LTC Generator と合わせれば完成が見えてきそうです。
 ウィンドウマネージャーはPython標準のtkinterを使う勉強をしています。書式は違いますが、考え方はHTMLとCSSを使ったweb画面作りに酷似していますので、方言的に翻訳が出来れば何とかなりそうです。ただ、ボタン操作や画面の更新をオブジェクト指向のイベント処理(割り込み)で書くので少し面倒ですし、LTC Generator の制御やvlcの部分はバックグラウンドの常駐処理にしたいのでウィンドウ制御とは別スレッドとなり手間がかかるかも。

#Python #タイムコード

2023年6月15日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 DI-1MUSEはコンデンサを交換しました。時間経過と共に音に張りが無くなったためです。
 次のコンデンサにしたところ、いわゆるハイ上がりではなく、まろやかに高域が伸びる音に戻りました。数日エージングしていますが安定しています。
 C2 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW
 C3 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW
 ただ、無改造品がエージングの効果なのかとても良い音になっています。DI-1独特の高域がモヤっとする感じが弱くなり、MUSEの方がスッキリしているものの、とてもキレイに伸びています。
 MUSE化することで特に生楽器やキーボードのピアノ音源には効果があると予想はしているものの、コストを考えたら無改造品を丁寧に長時間エージングするのがいいのかもしれません。
 そもそもが改造ありきの話ではありません。DI-1の欠点を改善するのが目的で改造は一つの選択肢ですから、別な手段が見えればそれはそれでいいと思います。

#音の世界
Icon of admin
 LTC Generator は卓に繋いで20時間以上正常に連続動作しています。PCとのやりとりの都合で手直しはありますが、基本的な機能はこれで完成とします。
 python-vlcでの音出しも方向性が見えましたので、あと必要な要素はPC上のソフトウェアです。
 Pythonのウィンドウマネージャーはtkinterが一番ベタな選択肢です。Python標準ですから安定性が期待出来ますし、WindowsでもMacOSでもLinuxでも同じソースで動きます。もっと書きやすくデザイン性に優れたウィンドウマネージャーもあるそうですが、何が違うのかよくわからないですし、基本過ぎるモノに慣れれば便利な物も使えるでしょうから、当面はtkinterを勉強してみます。つか、目に見えないところで動作するソフトウェアばかり書いてきたので画面作りは苦手です。

#タイムコード #Python
Icon of admin
 昨日書いたpython-vlcが別なPCでも再生出来るか、mp3以外のフォーマットも再生出来るかチェックしました。
 もちろんVLCで再生する物は問題なく再生出来ますが、VLCのアプリで再生するよりも音の締まりと広がりが良いように聴こえる。。。
 何が違うんでしょう!?

 音源再生アプリ(LTC Player)には一般的な音源プレーヤーにはあまり無い機能を付けます。
1)音源毎に音量設定
2)再生開始点、終了点の設定
3)曲の終わりで止めるか曲続きか。曲続きなら曲間秒数も設定。
4)処理が許せば、指定秒数からの F.I/O も実装。可能ならクロスフェードも実装。
 ダンスイベントですと音源の音量がマチマチですし、前後の無音(白身)がやたら長い物があったりするからです。
 通常は事前に音量と白身を調整して現場に臨むのですが、あったら便利かなと思う機能です。
 あとは、先日も書きましたが、raspberryPi pico を使ってプログラムマブルキーボードを作って外部スイッチにします。

#タイムコード #Python

2023年6月16日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Player を作るのにPythonのGUIライブラリを検討しています。
 Python標準のtkinterも良いと思うのですが少し物足りない感じ。
 マルチプラットホーム対応で無料の条件ですと kivy が良さそうです。出来ることが多すぎて難しそうですが、これは贅沢な悩みです。
 kivyはkv言語と呼ばれるコマンド群を使うことでスタイルシートの様な使い方が出来る様です。Tkinterよりも細かい画面作りが可能ということです。
 何が出来るのか、どこまで出来るのか、どうやったら使えるのかはこれからの勉強です。

追記
 仕事の合間にkivyについて調べてみましたがとても難しい。これで出来ない表現は無いように思える程ですが、ここまで必要か疑問。正直、kivyの学習には時間がかかり過ぎます。
 別なGUIライブラリが無いかと調べたところ「PySimpleGUI」というのがありました。必要な表現が出来るかわかりませんが簡単です。コマンドで画面を描きますが、難易度はFileMakerProの画面描きと大差ない感じです。

#Python

2023年6月18日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Player を試作ってみました。
20230618062945-admin.jpg
 まだまだ途中ですが、ウィンドウの下半分はこんな感じかなと。音源ファイルを選択して再生出来ます。再生、停止などは当たり前ですが、スライダーで再生位置指示と音量を付けてあります。音量は音源に対するものでシステムの音量は変化しません。上半分にはプレイリストを表示する予定です。
 PySimpleGUIはレイアウトの制約が多いのですが、その範囲で並べればいいだけです。自由度を求めるならTkinterやKivyですが、これらはプログラミングが大変過ぎます。PySimpleGUIなら予習2日、製作数時間でここまで出来ました。
 ボタンがフォーカス(押してはいないけど選択された状態)されているとスペースキーで押されたことになるので、フォーカスをボタン類から外すか常にPLAYボタンがフォーカスされた状態にするにはどうするかが課題です。
 キー入力の取得も簡単でした。ウィンドウを表示コマンドにキーイベントを拾うスイッチを加えるだけです。キーボードで押された文字が戻り値に入ります。日本語入力状態には対策が必要です。

追記
 ボタンのフォーカス問題ですが、ダミーボタンを置き、常にこれがフォーカスされる様にしました。
 イベントが発生してPySimpleGUI.Window.read()を抜けたらイの一・無条件にダミーボタンをフォーカスするのです。
 今はボタンしかレイアウトしていませんのでいいですが、強制フォーカスがダメな時には強制フォーカスの実行に条件を付けましょう。

#Python

2023年6月19日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Player はPySimpleGUIの扱い方を探りながらです。Tkinterのラッパーらしいですが、簡単に使える反面制約が多いので、別な意味で難しいところがあります。
 主な制約はウェジット(オブジェクト)の並べ方によって挙動が違うことです。全てではないのですが「ナゼそうなる!?」に出会うことが少なくありません。昨日もExecl的な表示をするTable機能で出くわしてしまい数時間悩んでしまいました。下記の試作品では「Add Music」が今の位置では期待通りの挙動をしますが、表の左隣りでは期待通りに動きません。ウェジットを単独テストしてからレイアウトに入れ込めば期待に反する挙動が起きても並べ方が原因だろうと予想出来ます。
 問題点と言えば問題点ですが、クセといえばそれまでですし、TkinterやKivyに比べて簡単なことは余りある価値です。これで無理な製作は自分はやらないとすればいいでしょう。

 画像は製作途中の物です。パラメータやレイアウトは今後変更していきますが、基本的な機能は実装出来ました。挙動を確認しながら進めていきます。
 一般的な音楽プレーヤーには無い機能を考えています。
 画面でわかりやすいのは「▼ NEXT ▼」です。プレイリストの順番で再生していくのは当然ですが、これにアサインしてからPLAYに行く前提です。曲順が入れ替わっても前の曲が再生している最中に呼び出せます。照明の卓っぽいですねwww。
 あとは、曲間というか次の曲への手順を決めます。曲間が自動停止か続くかはもちろん、次の曲へ渡すまでの秒数を決める様にします。表のNextの列にPauseとあるのは自動停止、秒数らしき数字があるのは曲続きの意味と待ち秒数です。
20230619113316-admin.jpg
 VLCにも少し問題があります。
 スライダーで再生ポジションを表示し変更できる様にしてありますが、スライダーの動作によってはVLCがタイムスタンプのエラーを出します。圧縮が高いmp3の為かもしれませんが原因は不明です。
 止まりはしないのですが、エラー発生の後、テンポやピッチが狂うことがあります。ダンスイベントが主目的ですから本番でポジションスライダーを触ることは無いと思いますが、必要な時にテンポやピッチが狂うのは困ります。
 処理手順の変更でエラーを防止できないか調べることにします。

追記
 ふとアイデアが出て、本業中なのに手を止めて修正www
 VLCのエラーは対策が出来たっぽい。
 かなり面倒な手順ですが、
0)ポジションスライダーのイベント確認
1)再生停止 stop()
2)ポジションスライダーの情報からポジション値を計算
3)再生開始 play()(タイム00:00:00.00からになります)
4)再生確定まで待つ
5)ポジション値をセット
6)操作が一時停止中ならpause()
 といった感じ。
 VLCをリセットし、改めて再生して位置を宣言する手順です。
 コマンドプロンプトにはエラー表示が出ず、テンポやピッチの狂いも起こっていないようです。

追記の2
 mp3ファイルではポジションスライダーの行き来を繰り返すとタイムスタンプがズレることがあります。
 いやーな感じでしたが、wavファイル(非圧縮)だと起こりません。mp3の圧縮方法を知っていると納得出来ますし、wavファイルで問題が無いならいいかなと。

#Python

2023年6月21日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Player はPySimpleGUIとpython-vlcを勉強しながら書いてきたためにソースコードがゴチャゴチャ。
 この先もあるので、変数やインスタンスの名前も手直ししながら大整理をしました。時間がかかりましたが読みやすく手直しもし易くなりました。
 で、そんな整理をすると出てくる出てくる細かいバグ。
 先日、mp3再生中にポジションスライダーを動かすと警告が出て再生速度などがおかしくなることがありましたが、対策はplay()、stop()、pause()を実行した後にis_playing()が望みのフラグを返すまで待つというものです。コレが抜けてる所が数カ所。状況が整っていないのに次の指令が来ることが原因だったようで、再生速度が狂う現象は解消されました。mp3でスライダーを多用すると再生時間のズレが出るのは変わりませんが、wavなら期待通りの動きなのでいいかなと。

 現在の画面。PlayListとNEXTはモックアップです。
20230621223221-admin.jpg

#Python

2023年6月26日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 LTC Player はファイルを読み込んでセットリストの編集をするところまで来ました。
 この辺り、かなり面倒です。編集の手順、再生中のLockなど、よく考えないといけません。
 それでも、かなりそれっぽくはなってきました。

#Python

2023年6月30日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 このところサーバーを作っていました。設置場所は某劇場の舞台事務所です。
 インターネットにも行けるごく普通の館内LANを使うのですが、館内のフリーwi-fiと元を同じくする回線です。先の設定がどうなっているのかわかりませんが、ネットマスクの桁数から想像するにフリーwi-fiの回線そのものと思われます。無料で使わせてもらえるので贅沢を言ってはいけませんが、接続しているパソコンと共有しているフォルダは絶対に隠さなければなりません。
 となると、必要な通信は通って不必要は通信は遮断するゲートウェイサーバーを構成する必要があります。その他の課題は、ローカルLANをwi-fiにすることです。机の配置の都合でLANケーブルを敷設出来ないからです。
 サーバー機の構成は、機体がジャンクのPC、OSはdebian、データストレージはRAID1にしたHDDを2台とバックアップ用のUSB-HDD、wi-fiのアクセスポイントとしてUSBのwi-fiトングです。マザーボードにはLANコネクタが2個あるので、外向きLANと内向きLANを構成してwi-fiトングは内向きのLANとブリッジします。
 これまでにも近い構成を何度も組んでいますからすんなり終わるだろと思ったら大間違い。このところのdebianはヴァージョンが上がるごとにセキュリティ対策が増え、設定が微増するのは仕方ないとして、旧来のコマンドが使えなくなったり設定の仕方がちょっとだけ変わるのです。私からすればよくわからん方言となりますので調べるのに時間がかかりました。持った通りに組めましたが、思惑より2日間余計にかかって他の仕事がヤバイ。
 おまけというか蛇足ですが、VPNで本社にも繋がる様にしておきました。本社の共有フォルダにアクセス出来れば業務も楽だろうと。

 突っ込んだ話ですが、DHCPサーバー、DNSサーバーとしてdnsmasqを使ってみました。簡易的なモノというイメージがありますが、私が組む小規模サーバーにはisc-dhcp-serverやbind9よりも等身大です。複雑な振り分けやルーティングはしませんので機能は十分ですし何よりも設定が分かりやすい。これらはサーバーを作り始めた当初に難儀したところですからこの使い勝手は感激レベルです。一つ問題を上げるなら、起動後、wi-fiトングと内向きLANとのブリッジが完了する前にdnsmasqが起動すると正常に動作しないので、dnsmasqの起動に待ちを入れる必要があったことです。これを見つけるのに少し時間がかかりました。
 /etc/resolv.conf を dhcpcd に書きかえらない対策が必要なことも気付くのに時間がかかりました。dnsmasq は自分でルートファイルを持たないために設定が簡単ですが、dhcpでアドレスを受け取る際に得たDNSサーバーの情報で /etc/resolv.conf を書き換えてしまうのです。これをされると自分でDNSサーバーを持っている場合に不都合が出るので、/etc/resolv.conf は書き換え不可にしなければならないのです。dnsmasq にも書き換えしない設定があるようですが、何度やっても書き換えられてしまう。ならば、/etc/resolvconf をOSレベルで書き換えられてない様にすればいい。同様の問題を抱えた先達がいましたので有難くパクらせて頂きました。パーミッションを400にするのかと思いきや、パーミッションより上位のフラグがあって、それを設定するのがいいらしい。# chattr +i /etc/resolv.conf とのこと。+i は書き換え不可のフラグを立てるスイッチです。外すなら -i だそうな。
 あと、DHCPクライアントをdhcpcdにしました。RaspberryPiで慣れているのもありますが、旧来の /etc/network/interfaces だけで設定するより何をしてもスムーズ。特にwi-fiトングをアクセスポイントにする hostapd を使うなら dhcpcd 一択と思えるほど快適でした。

 書き始めたらキリがありませんが、都度の感想も書き入れた設定記録を残したので、次の製作では参考にしつつ読んで楽しもうと思います。

 サーバーの設定は server world さんを参考にしています。
 server world
 ここの通りにすればちゃんと動きますので、私はここのレシピで基本設定をしてから好みに変更する様にしています。
 ただし、セキュリティについては別です。基本はフォルダやファイルのパーミッション、ルーティング、IPフィルタリングですが、ここはそうった解説を書かない方針と見受けらえます。それらについては別途勉強しなければなりません。

#サーバー
Icon of admin
 そんなこんなで LTC Player の製作は止まっています。進めたいのですが時間だけでなくアタマの容量も不足してます。
 PysimpleGUI を筆頭にプログラム環境でどこまで出来るかを探りながらなので、自分でもどう仕上がるかわからんという本音もあります。
 最近気づいたのは、sg.FileBrowse() などのボタンとしてレイアウトしなければならない機能は、不可視設定した column に入れ込んでしまえば表示しなくても使えること、ボタンオブジェクトを押したことにする .Click() を使えば他の event から(もちろんメニューからも)読み出せるというものです。PysimpleGUIを使ったことがないとピンとこないことですが、これは PysimpleGUI のレイアウトに自由度を与えてくれます。

追記
 .Bind() を使うと細かいキーボード操作を event として取り込むことが出来るらしい。
 キー操作をプレスにするかリリースにするかを選べるハズです。この辺りも研究課題です。

#Python