どのカテゴリにも属していない投稿[869件](25ページ目)
改造したDI-1の主要なコンデンサも変えてみました。音響用として評判が良いニチコンのコンデンサ達です。
MUSES02Dにしても改善されなかった特定の響きがスッキリと抜ける様になりました。特にガットギターの音源では使い古した弦と新品の弦くらい響きが違います。
ダイレクトボックスは楽器の音声信号をミキサーに入れるためのレベル変換ですから、演奏者が奏でるニュアンスを出来るだけ正確にミキサーに渡すのが仕事です。この改造の発端はDI-1を通すと正確さに掛けるのではないか?という疑問からです。何を以って正確かというと難しいですが、「DI-1なら弦を新しくしなくてもよかったなぁ~」などと演奏者に言われてしまうならば正確ではないのだろうと思っています。イメージとしては、高域を膨らますというより、響きや余韻を出来るだけ多くミキサーに渡したいといったところです。
今のところ、圧倒的な変化が起こっている訳ではありませんので売りは弱いですが、繊細な響きや余韻といったDI-1が苦手なところは改善されています。演奏者からすればこの辺りが大事だと思うので良い変化だと考えていますけどね。
最終判断は、手持ちに無かった物を替えてエージングした後になります。
新規開発や改造などの話は、モノの良し悪しより「誰が評価したか」が重要です。または、成り行きで使い続け、しばらくして以前の物に戻ってみたら物足りなさや不便を感じて意味を発見する、といった物語が必要です。残念ながら、自分の価値基準でゼロベースの評価をできる人は極めて少数です。ですので、社内でプレゼンすることは労力の無駄かもしれませんw
誰に試作品を送ろうかな・・・
#音の世界
MUSES02Dにしても改善されなかった特定の響きがスッキリと抜ける様になりました。特にガットギターの音源では使い古した弦と新品の弦くらい響きが違います。
ダイレクトボックスは楽器の音声信号をミキサーに入れるためのレベル変換ですから、演奏者が奏でるニュアンスを出来るだけ正確にミキサーに渡すのが仕事です。この改造の発端はDI-1を通すと正確さに掛けるのではないか?という疑問からです。何を以って正確かというと難しいですが、「DI-1なら弦を新しくしなくてもよかったなぁ~」などと演奏者に言われてしまうならば正確ではないのだろうと思っています。イメージとしては、高域を膨らますというより、響きや余韻を出来るだけ多くミキサーに渡したいといったところです。
今のところ、圧倒的な変化が起こっている訳ではありませんので売りは弱いですが、繊細な響きや余韻といったDI-1が苦手なところは改善されています。演奏者からすればこの辺りが大事だと思うので良い変化だと考えていますけどね。
最終判断は、手持ちに無かった物を替えてエージングした後になります。
新規開発や改造などの話は、モノの良し悪しより「誰が評価したか」が重要です。または、成り行きで使い続け、しばらくして以前の物に戻ってみたら物足りなさや不便を感じて意味を発見する、といった物語が必要です。残念ながら、自分の価値基準でゼロベースの評価をできる人は極めて少数です。ですので、社内でプレゼンすることは労力の無駄かもしれませんw
誰に試作品を送ろうかな・・・
#音の世界
以前から考えていたことですが、MTCのデータを差動バイフェーズで送るのはどうかなと。
データ構成はLTCよりMTCの方が簡単です。通信インフラはMTC(MIDI)より差動バイフェーズの方が選択肢が多く遠距離でも使えます。双方のいいとこ取りをしたらどうかって発想です。
LTCに比べMIDIの方がビットレートは速いのですが、MIDIを占拠しないためにMTCのデータレートはLTCより遅いのです。通信媒体を占有するならLTCベースでもMTCを送ることは可能です。
なぜこうするかいうと、専用の通信インフラを使わず、音響さんに迷惑をかけずに音響回線を借りられたら汎用性が高いと思うからです。LTCは電気的には音声信号相当ですからダンテなどのEtherも通せます。
差動バイフェーズとUARTの変換は作らねばなりませんが、この変換はタイムコードに限らず他の制御にも使えると思うのです。データレートの制限はありますが、MSCをマイクケーブルで送れたらいいなぁ~なんて妄想してます。
#電子工作
データ構成はLTCよりMTCの方が簡単です。通信インフラはMTC(MIDI)より差動バイフェーズの方が選択肢が多く遠距離でも使えます。双方のいいとこ取りをしたらどうかって発想です。
LTCに比べMIDIの方がビットレートは速いのですが、MIDIを占拠しないためにMTCのデータレートはLTCより遅いのです。通信媒体を占有するならLTCベースでもMTCを送ることは可能です。
なぜこうするかいうと、専用の通信インフラを使わず、音響さんに迷惑をかけずに音響回線を借りられたら汎用性が高いと思うからです。LTCは電気的には音声信号相当ですからダンテなどのEtherも通せます。
差動バイフェーズとUARTの変換は作らねばなりませんが、この変換はタイムコードに限らず他の制御にも使えると思うのです。データレートの制限はありますが、MSCをマイクケーブルで送れたらいいなぁ~なんて妄想してます。
#電子工作
LTC Generator のPICはFIFOにデータを突っ込んで波形が出力するまでまとまりました。
内部のテストルーチンによるものですが、データのリレーはシュミレーターで、波形はオシロスコープで確認出来たので、最も面倒な部分が成立した模様です。
昨日一見動いたものの波形が安定せず悩みましたが、バグを手直しして今は期待した波形が出ています。0x00や0xFFはもちろん他の数値もOK。オシロスコープのトリガが引っかからず波形が読み取れない数値もありますが、この値が確認出来ればいいでしょうって値はいけたので、デバイスドライバ的なところが終わったと言えます。
今後の課題はパソコンとの通信です。PIC側は過去実績、パソコン側はライブラリに頼れば左程難しくないハズ・・です。パソコンから受信した値をFIFOに突っ込んで期待した波形が出れば重要な機能は完了です。
完成に至るには、PICからパソコン側にデータ送信の要求を送ったり、コマンドでfpsのモードを切り替えたりと課題は残っていますが、ハードウェアとデバイスドライバ的な部分がまとまればハードルは低くなります。
ちなみに、今作っているのはシリアルで受信したバイトデータを差動バイフェーズで出力するだけの物ですから、TASCAMのプレーヤーのリモコンと組み合わせることも可能(正しくは不可能ではない)です。曲ごとのタイムコードをユニークする方法を考えなければなりませんが、これはこれで欲しい一品です。
当然リモコンはフルスクラッチとなりますが、出来るだけ音響さんの環境を変えないためにこういった発想もありかなと。
#PIC #タイムコード
内部のテストルーチンによるものですが、データのリレーはシュミレーターで、波形はオシロスコープで確認出来たので、最も面倒な部分が成立した模様です。
昨日一見動いたものの波形が安定せず悩みましたが、バグを手直しして今は期待した波形が出ています。0x00や0xFFはもちろん他の数値もOK。オシロスコープのトリガが引っかからず波形が読み取れない数値もありますが、この値が確認出来ればいいでしょうって値はいけたので、デバイスドライバ的なところが終わったと言えます。
今後の課題はパソコンとの通信です。PIC側は過去実績、パソコン側はライブラリに頼れば左程難しくないハズ・・です。パソコンから受信した値をFIFOに突っ込んで期待した波形が出れば重要な機能は完了です。
完成に至るには、PICからパソコン側にデータ送信の要求を送ったり、コマンドでfpsのモードを切り替えたりと課題は残っていますが、ハードウェアとデバイスドライバ的な部分がまとまればハードルは低くなります。
ちなみに、今作っているのはシリアルで受信したバイトデータを差動バイフェーズで出力するだけの物ですから、TASCAMのプレーヤーのリモコンと組み合わせることも可能(正しくは不可能ではない)です。曲ごとのタイムコードをユニークする方法を考えなければなりませんが、これはこれで欲しい一品です。
当然リモコンはフルスクラッチとなりますが、出来るだけ音響さんの環境を変えないためにこういった発想もありかなと。
#PIC #タイムコード
FIFOなど、諸々書き加えたファームウェアも正常に動きました。
自分で書いた送出停止処理の扱いを間違えて信号が出ないことに悩んでしまいましたが、テストプログラムが間違っていただけでした。肝心のモジュール本体は一発OKです。
今回のPICはパソコンから送られてきたデータを淡々と差動バイフェーズで送り出すだけです。難しいことはパソコンでやれと、PICの名前の由来を考えろと。そんな作りです。
データを差動バイフェーズで送出することは出来た。データのタイミング緩衝となるFIFOもどうやら正常に動く。残るはパソコンとの通信です。FT232RLを経由したシリアル通信ですが、PIC側はDMXで散々やったことですし、パソコン側はPythonなのでほんの数行で書けます。10分の空き時間で進められるものでもありませんけどね。
あとはラインセレクタも必要です。
音響さんからもらう本線LTCと自分のパソコンから送るチェック用LTCの2系統を切り替える必要があるからです。
セレクタにはJRCさんのNJM2750が良さそうです。単電源で動く電子ロータリースイッチってイメージですね。
NJM2750はアンバランスのLRを4系統から1つ選ぶって構成ですが、バランスのモノ4系統として使っても良さそう。
今回はそこまで使わないけど、4系統のラインセレクタ基板を作っておけばいいかな?
#PIC #タイムコード #電子工作
自分で書いた送出停止処理の扱いを間違えて信号が出ないことに悩んでしまいましたが、テストプログラムが間違っていただけでした。肝心のモジュール本体は一発OKです。
今回のPICはパソコンから送られてきたデータを淡々と差動バイフェーズで送り出すだけです。難しいことはパソコンでやれと、PICの名前の由来を考えろと。そんな作りです。
データを差動バイフェーズで送出することは出来た。データのタイミング緩衝となるFIFOもどうやら正常に動く。残るはパソコンとの通信です。FT232RLを経由したシリアル通信ですが、PIC側はDMXで散々やったことですし、パソコン側はPythonなのでほんの数行で書けます。10分の空き時間で進められるものでもありませんけどね。
あとはラインセレクタも必要です。
音響さんからもらう本線LTCと自分のパソコンから送るチェック用LTCの2系統を切り替える必要があるからです。
セレクタにはJRCさんのNJM2750が良さそうです。単電源で動く電子ロータリースイッチってイメージですね。
NJM2750はアンバランスのLRを4系統から1つ選ぶって構成ですが、バランスのモノ4系統として使っても良さそう。
今回はそこまで使わないけど、4系統のラインセレクタ基板を作っておけばいいかな?
#PIC #タイムコード #電子工作
FIFOの動作チェックをしました。
バク無し・・・嬉しいような怖いような。
FIFOはループメモリです。例えば10個のメモリを使うなら10個目を書いた後は1個目から書きます。これを続けます。読出しも同じ。
ただ、読出しと書き込みはタイミングがシンクしませんので、読出しが書き込みを追い越さないこと、書き込みは一周以上先行しないことが重要です。これらの確認も出来ました。
処理のタイミングとしては、読出しはLTCの送出に合わせてになりますが、書き込み(パソコンへのデータ要求とも言う)はメモリが空いたら行います。
パソコンとの通信速度がLTCの送信速度より十分に速く、パソコン側のレスポンスも十分に早ければタイミングがズレることはありません。たぶん。
読出しが書き込みに追いついてしまえばデータが無いことになりますので、新しいデータが入るまでLTCを送出しないだけです。
#PIC #タイムコード
バク無し・・・嬉しいような怖いような。
FIFOはループメモリです。例えば10個のメモリを使うなら10個目を書いた後は1個目から書きます。これを続けます。読出しも同じ。
ただ、読出しと書き込みはタイミングがシンクしませんので、読出しが書き込みを追い越さないこと、書き込みは一周以上先行しないことが重要です。これらの確認も出来ました。
処理のタイミングとしては、読出しはLTCの送出に合わせてになりますが、書き込み(パソコンへのデータ要求とも言う)はメモリが空いたら行います。
パソコンとの通信速度がLTCの送信速度より十分に速く、パソコン側のレスポンスも十分に早ければタイミングがズレることはありません。たぶん。
読出しが書き込みに追いついてしまえばデータが無いことになりますので、新しいデータが入るまでLTCを送出しないだけです。
#PIC #タイムコード
気分転換にFIFOを書いてみました。初期設定を含めても50行くらいです。
ループメモリを非同期で読み書きする構造ですから、それぞれのアドレスカウンタの扱いが肝です。当初悩んだものの、条件を整理すれば案外簡単でした。アルゴリズムの設計大事です。
こういったモジュールは例外も想定して慎重に動作確認をしなければなりませんが、実機だと確認が難しいのでMPLABXのシュミレータの出番です。ステップ毎のレジスタの変化を観察したいのです。
MPLABXのシュミレーターは使い方がイマイチわからんのですが、操作メニューが違うだけでやることはv8.92と同じでしょうから、先達の書き込みを参考に探ってみます。
追記
シュミレーターの使い方は次のサイトがわかりやすい。というか、この通りにやったらシュミレート出来ました。
MPLAB X の使い方(Simulator編)
MPLABv8.92とはデザインが違いますが、やっていることは同じなので慣れればいいかなと。PICの中身を知らないと何が何やらですけど・・・
テスト用に少し書き換えればFIFOの挙動をチェック出来ます。
#PIC
ループメモリを非同期で読み書きする構造ですから、それぞれのアドレスカウンタの扱いが肝です。当初悩んだものの、条件を整理すれば案外簡単でした。アルゴリズムの設計大事です。
こういったモジュールは例外も想定して慎重に動作確認をしなければなりませんが、実機だと確認が難しいのでMPLABXのシュミレータの出番です。ステップ毎のレジスタの変化を観察したいのです。
MPLABXのシュミレーターは使い方がイマイチわからんのですが、操作メニューが違うだけでやることはv8.92と同じでしょうから、先達の書き込みを参考に探ってみます。
追記
シュミレーターの使い方は次のサイトがわかりやすい。というか、この通りにやったらシュミレート出来ました。
MPLAB X の使い方(Simulator編)
MPLABv8.92とはデザインが違いますが、やっていることは同じなので慣れればいいかなと。PICの中身を知らないと何が何やらですけど・・・
テスト用に少し書き換えればFIFOの挙動をチェック出来ます。
#PIC
MUSES02D化したDI-1はとても良い音ですが、どこか物足りない。オペアンプが鳴りきっていないというか躓いているような気がするのです。勘ですが、入口か出口のコンデンサがMUSES02Dに対して性能不足の様に感じます。
当初はオペアンプの交換に留めようと思ったのですが、コンデンサは安価で元に戻すのも簡単なので試してみようかと。
別な部品と共にコンデンサも手配しました。
#音の世界
当初はオペアンプの交換に留めようと思ったのですが、コンデンサは安価で元に戻すのも簡単なので試してみようかと。
別な部品と共にコンデンサも手配しました。
#音の世界
LTC Generator のPICのファームウェアを書いています。
今日の課題は「バイトデータ送出モジュール(補正機能付)」です。信号を出す要の部分でしょうか。
30fps、29.97fps、25fps、24fpsに対応する予定ですが、それぞれに適したパルス波長を作る部位です。
1時間単位の計測方法が無いので精度の確認は出来ませんが、オシロスコープで確認する限りは適切なパルス長です。
データ送信も確認しました。0x00と0xFFを繰り返し送出するテストですが、ちゃんと差動バイフェーズの波形が出ています。そこそこ面倒なアルゴリズムですが一発で動いてしまい嬉しいやら寂しいやら。
データに応じた波形が出せる状態になったのでファームウェアは一旦お休み。
この後は、プリアンプの手直し、パソコンからFT232RL経由でデータを送るテストプログラムの作成と続きます。
追記
そういやFIFOモジュールを書いてない。
これは先にやっておきましょう。
#PIC #タイムコード
今日の課題は「バイトデータ送出モジュール(補正機能付)」です。信号を出す要の部分でしょうか。
30fps、29.97fps、25fps、24fpsに対応する予定ですが、それぞれに適したパルス波長を作る部位です。
1時間単位の計測方法が無いので精度の確認は出来ませんが、オシロスコープで確認する限りは適切なパルス長です。
データ送信も確認しました。0x00と0xFFを繰り返し送出するテストですが、ちゃんと差動バイフェーズの波形が出ています。そこそこ面倒なアルゴリズムですが一発で動いてしまい嬉しいやら寂しいやら。
データに応じた波形が出せる状態になったのでファームウェアは一旦お休み。
この後は、プリアンプの手直し、パソコンからFT232RL経由でデータを送るテストプログラムの作成と続きます。
追記
そういやFIFOモジュールを書いてない。
これは先にやっておきましょう。
#PIC #タイムコード