2018音源とオーディオの電子工作(予定)ソフト屋がハードにはまっていく軌跡2018年12月30日日曜日MIX0401のジャックをRCAジャックから3.5φミニジャックに変更MIX0401が不調で、ノイズの原因はこれかもしれません。入出力にRCAジャックを使っていましたが、ロックタイトを使ってもゆるゆるでプラグの抜き差しが不安です。音がでなくなることもあります。RCAは、据え置きオーディオなどずっとつないでいる場合はそれなりに信頼性が高いと思いますが、頻繁に抜き差しする音楽機材としての用途には不向きなのかもしれません。ギターやキーボードなどでは6.3φのプラグが標準ですが、MIX0401の筐体に収めるには少し大きすぎます。今やモジュラーシンセの標準と言ってもいい、DoepferのEurorackは基本的に3.5φのミニジャック/プラグを使っています。これを踏襲してMIX0401も3.5φのミニジャックを使うことにしました。基板を剥がして、既存のジャックを取り外し、ミニジャックを取り付け配線後、基板を両面テープでPOTの裏に貼り付けミニジャックに変更したバックパネルRCAジャックのゆるみ止めのロックタイト243をつかっていたので、取り外しに苦労しました。一応「中強度」となっていますがそうは簡単にはナットが回りません。ソケットレンチやらモンキーレンチやらラジオペンチやらいろいろ使って無理やり取り外したので、ケースが傷だらけになってしまいました。3.5φのケーブルを何本か作らないといけないのですが、年末年始で部品屋さんの通販がお休みなので、本格的なテストは年明け以降になります。前に作った「ミニ・ミキサー」にDASS01やKIK01をつないでみると、なんと気になるノイズなく動作しました。プラケースなのに不思議なものです。するとプラの方がケースへの接地がややこしくなくていいのかも?とりあえず、これでMIDI_CV_CONVの実験をしたいと思います。IC2A周りの非反転増幅回路で、JP2につないだPOT(レオスタット)で増幅率を可変するようにしていますが、このつなぎ方は良くないそうです。NG」の接続だとR2のワイパーの接触部分に電流が流れるため、経年変化による劣化に弱いようです。←確かにガリが目立つ気もします。OK」のように接続するとワイパーに電流が流れないため(オペアンプの入力はインピーダンスが高い)、接触抵抗が無視できます。0)、出力がクリップして出力振幅いっぱいの矩形波になってしまうので、入力抵抗を入れる必要がありますが。MIX0401を参考にされる場合はご注意ください。上記については「新・低周波/高周波回路設計マニュアル」で取り上げられています。その3下図のように接続してMIDI_CV_CONVをテストしました。ありあわせのケーブルで途中で変換コネクタを使ったりして接続すると、おそらくグランドループに起因すると思われるノイズが出て途方にくれていましたが、専用にケーブルを作り直したりしているうちにノイズが気にならなくなりました。やったことは、「ケーブルの途中で変換コネクタを使わなくする」ことと「オーディオ信号が通るケーブルは短くする」ことぐらいです。短くすると言っても2~3メーターのケーブルもあります。ケーブルのグランド線を切ったりしてグランド線のループを切ると改善することもあるらしいですが、そういうことはやっていません。このあたりのノイズは、苦手な電磁誘導が原因らしいので、後々経験を積んで理屈と照らし合わせて行きたいと思います。CV/GATE信号を同期させるラッチMIDIチャンネルごとのGATEのずれを、Dフリップフロップで吸収することを考えて実験しました。Arduinoからラッチ信号を出力して(接続図のArduinoのD9から出ている青色のケーブル)、74HC175とMCP4922を同期させて出力という手順を考えたのですが、うまくいきませんでした。説明できないのですが、MIDIの通信速度が遅すぎてチャンネルごとのGATE/CVを同期させようと思うと数ミリ~数10ミリ秒キザミの精度になってしまいます。メリットがはっきりしないので、Dフリップフロップによる同期は今回は保留します。CV信号にかけるLPF接続図のようにMCP4922の出力にパッシブのRLCローパスフィルタ(2次)をかけました。出力をドライブするために単電源OPAMPのNJM3404のボルテージフォロワを後段に入れています。コンデンサーの容量を大きくすると波形がなめらかになってポルタメントがかかっているようになるのですが、定数を決めるのが難しいのでLPFも保留します。トランジスタアレイによるLEDのドライブGATE信号を使ってLEDを発光させるためにトランジスタアレイのTD62003を使いました。これは入れておいた方が良さそうです。メモ:ノイズの改善と今回実験した回路の因果関係がはっきりしないので、もう少しテストする予定です。octave」が標準だそうです。(参考:https://en.wikipedia.org/wiki/CV/gate)CVの電圧が1V上がると1オクターブ周波数が上がるものです。Frequencyは、POTで分圧した電圧をADCで読み取り、単純に周波数に変換しています。Volt」にあたると思います。この方式だと周波数が高くなるほど1オクターブあたりの電位差が必要になり、基本的に3.3V系や5V系で動作させている自作の音源には厳しいものになります。octerve」のほうが使う電位差の節約ができるし、指数カーブをもった音階に沿った電圧値になります。CVを5V系にするか3.3V系にするかMIDI_TO_CVをArduino+MCP4922で実装するとすれば、5V系でも3.3V系でも出力できますが、受け側のNucleo_DCOが3.3V系です。一応5VトレラントなのでCVが5V系でも壊れはしませんが3.3V以上の値がADCで読み取れません。抵抗による分圧などで5V系→3.3V系にシフトする必要があります。CVを3.3V系にすると3.3オクターブで、5V系にすると5オクターブとれて有利ですが、多少作らなければならないものが増えるので、まずは3.3V系で作ってみようと思います。BaseNoteNumberはCV=0Vとするノートナンバーです。実際にスケッチを書いてテストすると、多少の誤差はありますがノートナンバーに対応する電圧が出力されました。IN」はフォトカプラでMIDI信号を受け、「MIDI-THRU」にスルーします。SW」は、「UART:RX」にMIDI信号(PullUpされている)を流したままだとArduinoに書き込めないので、それを切り替えるものです。Latch」については「マイコンの非同期出力をデジタル回路でラッチして同期させるシミュレーション(メモ)」にあります。GATE信号はArduinoのGPIOでドライブできると思いますが、同じ信号線でLEDをドライブするためにトランジスタ・アレイを使おうと思います。GATEのON/OFFでLEDがチカチカしたら目で見てわかるし楽しいと思いますし。CVのLPFは、127段階しかないMIDIの値をなめらかにしたほうがいいかなという意味です。音階は離散していてもいいんですが、時定数の大きいLPFをかければポルタメント的につかえないかな~という妄想です。メモ:CVは0V以上の単電源波形。アクティブ・フィルタを単電源OPAMPで構成して動作するのか?パッシブフィルタ+出力バッファ?はてさて?MIDIの音階はあまりにもトビトビなのでピッチベンドを拾って加算する?Nucleo_DCOのファームウェアの改修が必要。Off)特に低域の歪が改善されます。ADC読み取りを行うとPOTによる分圧の読み取り値がふらつくためだろうと思います。Offで測定しました。ADC読み取りを抑止した場合、可聴帯域ではTHD≒0.04%、THD+N≒0.17%程度です。DACのためでしょうか。POTで周波数を設定するため、きっちりした周波数は指定できませんが、まずまずきれいな波形が出力されていると思います。10kHzサイン波30kHz付近に2つのピークがあります。30kHz)でしょうか。(~1.25MHz)1.25MHzまで目立ったピークは出ていません。(~100kHz)サンプリングレートの62.5kHz付近に歪が残っていますが、-40dB程度です。<追記:2019.01.20>よく見るとピークは52kHz付近です。52.5kHzの折り返し歪でしょうか。D/A変換して使える帯域は、サンプリング周波数の1/2(ナイキスト周波数)以下なので、オーディオ的に考えると31.25kHz以下は十分に減衰させる必要がありそうです。DACなので可聴帯域外の歪は、「味」として深く考えないことにします。I/Fの入力のACカップリングの影響だと思います。100Hz矩形波(デューティ10%)100Hz矩形波(デューティ90%)矩形波のデューティ比を変えると、スペクトルがコム・フィルターをかけたみたいになるんですね~。ノイズそのうちに基本波形以外の波形も増やしてみようと思います。Nucleo_DCO2018年12月13日木曜日マイコンの非同期出力をデジタル回路でラッチして同期させるシミュレーション(メモ)MIDI_CV_CONVの実験でArduinoからCV、GATE信号を出力していますが、チャンネルごとに1ms以上のずれがあります。https://ja.wikipedia.org/wiki/MIDI」ということなので、1バイト(8bit)送受信するのに最低でも256usかかります。256us)→なんで「31.25Kbps」という中途半端な通信レートにしたのかも逆数をとると256という切りの良い数値になるのでわかる?Arduinoなどマイコンで逐次処理すると、MIDIメッセージを解釈してCVやGATEとして出力すると、1処理ごとに、どうしても256us以上のずれが発生することになります。1MHz駆動のマイコンなら1クロックで1usかかるので、大雑把に考えてMIDI->GATE変換に1ms以上のずれが発生するのはしかたないと思います。1msというと短い時間のようですが、逆数をとると1kHzでもろに可聴帯域なのでそれほど気軽には考えられません。実際にやるかどうかはわかりませんが、CV/GATEのチャンネルごとの時間的なずれをデジタル回路で同期させることを考え、LTSpiceでシミュレーションしました。デジタル回路なら素子の特性によるので、マイクロ秒~ナノ秒(1MHz~1GHz)オーダーに抑えられると思います。CV信号を発生させるDACのMCP4922は「LDAC」というラッチ端子があるので、GATE信号とまとめて同期できると思います。シミュレーション回路図Dフリップフロップを4つ並べて単一のクロック信号(CLK)で同期させる回路です。Registerというそうです。https://www.electronics-tutorials.ws/sequential/seq_5.html」この回路でマイコンの出力の時間的なズレを吸収し、CV/GATE信号を同期できます。メモ:CLK信号(黄色)がL->Hするとき入力(水色)が評価され、出力(緑色)される。CLKがLの間にCV/GATE信号をマイコンから出力し、CLKをHにすると同期して信号が出力される。レイテンシー(同期させるまでの待ち時間)が発生するので要注意。周波数として考えると、CLKは信号本体の周波数の2倍以上は必要。MIDI_CV_CONVの構想BSM02でシーケンサー+D/A混在シンセを作りましたが、打ち込んだデーターを外に取り出す仕組みは作っていないので、Nucleo_DCOに音階を与えるために流用するのは少しめんどうです。BSM02のハードウェア/ソフトウェアに手を入れる必要があるので、思いつきで崩してしまうのは抵抗があります。パソコン上のDAWを使ってMIDI信号を出力し、CV/GATE信号に変換する、MIDI-CVコンバーターを作ってみることにしました。F303K8を使ってmbedでやってみると、どうもMIDIメッセージを読みこぼすようです。DACが3系統内蔵されていて、性能もCortex-M4でそこそこ高スペックなので使ってみたかったのですが、まずはArduinoでやってみることにしました。Miniを使うつもりです。想定している使用例ArduinoにSPI/DACのMCP4922を接続し、アナログ値を出力してCVとします。DACなのでうまく行けば2ch分CVを出力できます。Nucleo_DCOは3.3V系(5Vトレラント)なのでCVの信号レベルは0V~3.3Vとします。「DASS01」(「ASS01」という名前にしようと思ってましたが、「DASS01」に変更します)はアナログ系でCV信号にもう少し振幅が欲しいので「DASS01」内の「Amp」で増幅します。Level」POTで可変します。GATE信号はGPIOから出力します。Miniなので入力するGATE信号レベルは5VでOKです。「KIK01」はNucleo-F446RE、「BSM02」はNucleo-F401REでSyncIn(GATEの立ち上がりで評価)は3.3V系ですが5Vトレラントなのでこれも5VでOKです。D1)を使うので、デバッグ用にArduinoのSerialクラスが使えません。簡単なメッセージの表示しかできませんが、I2C接続のキャラクタLCD(秋月のAE-AQM1602A)を使うことにしました。※Arduinoで書き込むときは、RXの配線を抜く。※MCP4922はまだ接続していません。https://n.mtng.org/ele/arduino/i2c.html」を使いました。LOW);#endif}メモ:LCD_TRACEを有効化(1)するとMIDIメッセージを読みこぼす。bootloder)を指定する必要がある場合がある。メインループの処理時間は92kHzぐらいで変わらない?DACからの出力にはLPFを入れる。Nucleo_DCOはADCにCV信号を入力するので注意。TRUEStudioでLチカSTM32のネイティブ環境でLチカを動作させられたので、メモです。試行錯誤しているのでこの手順通りで動作できるかどうかはわかりません。TRUEStudioを使いました。パソコンはWindows10で、ターゲットボードはNucleo-F446REです。http://happytech.jp/wordpress/2017/06/05/how-to-use-stm32cubemx/」TrueSTUDIOのインストールhttps://atollic.com/truestudio/よりAtollic_TrueSTUDIO_for_STM32_windows_x86_v9.0.1_20180420-1214.exeを入手してインストール。guideを一読EclipseベースのIDEを使うのは10年ぶり?ぐらいです。Guide」を一読してなんとなく操作法を確認しました。パースペクティブの切り替えなど少しクセがあります。Project]ダイアログでプロジェクト名を指定。Project]を指定。[ターゲット]で[Boards]-[NUCLEO_F446RE]を指定。[デバッグプローブ]で[ST-LINK]を指定。以上でカウンターをインクリメントするプロジェクトが作成され、コンパイル&デバッグできますが、これだけでは周辺機能のドライバが何もありません。STM32CubeのインストールSTM32CubeはSTM32の開発を行うためのHALその他もろもろのソフトウェアを集めたもので、F3とかF4などのSTM32のシリーズごとに別れています。STM32CubeMXはSTM32Cubeを使ったプログラムに必要な初期化コードを生成するグラフィカルなツールです。STM32CubeMXをインストールします。Enviroment」のインストールが促され、インストールしました。STMicroの日本語の記事https://www.stmcu.jp/design/sw_dev/pc_soft/52798/?gclid=EAIaIQobChMI-P6p9qfD3QIVQamWCh3FhQNcEAAYASAAEgIFxvD_BwEインストールファイルはSTMicroの本家サイト(https://www.st.com/ja/development-tools/stm32cubemx.html)から入手しました。manual」が参照でき、これに従って以降の設定を行いました。versionプラグインバージョンのインストールです。TRUEStudio上でCubeMXを利用できるようになります。packagesSTM32Cubeのインストールです。1.21.0」をインストールしました。(https://qiita.com/gkmaro634/items/7b2ce4f72615c96f41d3)」を参考にしてLチカさせました。CubeMXでBoardを指定してデフォルトの設定のまま初期化コードをを生成するものです。動かしてみるにはちょうどいいと思います。Selector]で[Nucleo-F446RE]を選択、デフォルト・モードで初期化。Location]を設定。IDE]で[TrueSTUDIO]を選択。Code]でコードを生成。以上でTRUEStudio用の雛形プロジェクトが生成されます。Project」を選択するとエラーメッセージが表示されましたが、TrueSTUDIOで生成されたプロジェクトを開けば大丈夫でした。プロジェクト内のmain.cppのmain()関数内のwhile()ループ内にLチカさせるコードを追加します。[デバッグ]で、PCに接続したNucleoにプログラムが書き込まれ、LEDがチカチカします。HAL_GPIO_WritePin()、HAL_Delay()などはSTM32CubeのAPIで、ドキュメントを参照しながら習得する必要があります。組み合わせてASS01(アナログ・シンセ・システムの略)と名付けて、仮組みしました。ASSはあんまりいい意味の言葉ではないですが、気にしません。System」という意味で「DASS01」とします。</追記>電源もいずれ作るつもりですが、とりあえず単3×6の9V電池ボックスを2つ使って±9V電源としました。WaveInはNucleo_DCOから、EnvelopeはArduino_EGから入力しています。左上のブレッドボードはArduino_EGに入力するGate信号を発生させるものです。NANOでとりあえず組んでいます。MIDI-CVコンバーターを作って置き換えるつもりです。MoogerFoogerをリスペクトして個別筐体でいろいろ作ってきましたが、機材の置き場所に苦慮しています。