2019年10月16日

LFO/Speedの倍率をVoiceModeに展開したDepthパラメータで切替える

Thresholdのスイッチ長押しで切替えていたLFOの周波数を、各VoiceModeのシーンメモリー毎に行った方が便利なことに気付いた。

Screen Shot 2019-10-16 at 7.01.08.png

具体的には、PitchBendModeと同様にbitReadを使って各VoiceModeに配置したLFO depthを設定するデータのMSBを監視して、

Screen Shot 2019-10-16 at 5.37.13.png

MSB == HIGH の場合にSpeedの倍率を下げる判定を行う。

ただし、このままでは数値がゼロを超えて負の領域に入った瞬間、0x0000 から 0xffff と最大値にデータが振り切れてしまう。 

流石にこれは使い勝手が悪いので、MSB以外のbitにExORを掛けてバイナリーデータを反転させ、数値のジャンプを防いでいる。 

この際、データを二の補数化してもよいのだが、今回は仕上げの+1は行わず、中心値でゼロが被る仕様とした。

Screen Shot 2019-10-16 at 6.22.12.png

データを格納した時に状態が保持・再現されない問題が発生したため、新たにメモリーをハンドリングする符号付き変数をリザーヴしている。

Screen Shot 2019-10-16 at 6.44.47.png

Screen Shot 2019-10-16 at 8.03.03.png

正負の判定は、メモリーを呼び出すタイミングとロータリーエンコーダーのデータを取得するタイミングで行う。

セレクターの改変に伴い、Theresholdのスイッチ長押しでの切り替え機構は廃止となった。

Screen Shot 2019-10-16 at 5.54.17.png

追記:

目玉LED(赤)の状態がDistortionMode(LowerKnob)以外のModeで反映されないバグが発覚したため、全てのModeでポートのオン・オフが表示出来るようにコードを追加した。

Screen Shot 2019-10-16 at 10.59.09.png
posted by Yasuski at 08:35| LaVoixski

2019年10月15日

DistortionControl端子の極性を修正する

Distortionコントロール端子の極性が逆になっていたRGBロータリーエンコーダーの表示を修正した。

Screen Shot 2019-10-15 at 13.14.38.png

ただし、このままではDistortionの表示を行う目玉LEDの極性が逆になってしまうので、新たにD26(M size MCU boad)

Screen Shot 2019-10-15 at 13.46.12.png

D50(L size MCU board) にLED(Red)の出力端子を追加している。 (試作型の1455N1601を使用したモデルはbuttonPin06にアサイン)

Screen Shot 2019-10-15 at 13.19.43.png

ID-292用の基盤では、混乱を避けるためにadat系の出力はオプションのミュート端子(現時点では不使用)を接続しているLATCH02ポートを除き、全て無効とした。 

Screen Shot 2019-10-15 at 16.38.37.png

端子に余裕があるMCU基盤では、buttonPin05(D05) にミュート端子をアサインしている。(こちらも現時点では使用していない)

Screen Shot 2019-10-15 at 16.36.11.png

Setup時の出力設定を忘れないこと。

Screen Shot 2019-10-15 at 16.39.40.png

Screen Shot 2019-10-15 at 16.39.56.png

追記:


DACの接続が怪しい問題が再発しているのだが、これはTeensyのピンとコネクタ間の接触不良、もしくは、ボード上でMCUのBGAピンが外れ掛けている可能性もあるが、後者の場合はより重篤な症状で対処が難しい。
posted by Yasuski at 16:54| LaVoixski

LFOのSpeedRateを切替える機能のデモ

posted by Yasuski at 10:59| LaVoixski

2019年10月13日

テルミンのグリッチ発生問題に関する備忘録

まず、試験的にFTMの分周率を1つ上げて実験を行ったところ、グリッチの周波数が下がった影響で却ってその認知度が上がってしまう結果となった。

Screen Shot 2019-10-13 at 18.56.48.png

次に、分周率を元の最高周波数に戻し、先に調整したオシレーターのチューニングはそのままでグリッチの発生状況を観測したところ、悪目立ちする状態は変わらなかった。

このことから、オシレーターの実用域の設定がグリッチの発生に影響することが判明、オシレーターをセンスする実用域を1オクターヴ程度に再設定するとグリッチを軽減出来るようだ。

実験の結果、ピッチ側は分周率を上げたほうが安定する事が判明しているが、その場合Volume側で発生するグリッチの周波数が目立つ領域まで落ちてしまう。 つまり、FTMはPitch/Volue個別に設定したほうが良いのだが、FTMを並列で走らせた場合のタスクはMCUの処理限界を超えてしまう。

Screen Shot 2019-10-13 at 18.59.31.png

あと、チューニングを行う時の指標に閾値を知らせるLEDを光らせたいのだが、これがどうやっても実現できない。 しかも、作業の過程で片方のチャンネルから音が出なくなってしまう案件が発生しだしたが、直接的にDAC出力と関連する部分のコードを一切いじっていないのが面妖だ。 多分、コンパイル時に使用するオプティマイザーに問題があるのだろうが、これはブラックボックスなので修正のしようがない。

チューニングの最適値は、実測でPitch側 1.6kHz / Volume側 2kHz といったところ。

72065022_2681250125238762_6561067095923097600_o.jpg

今回はAndroid系のアプリを使って周波数を測定した。 

73375639_2681250511905390_4752849254005866496_o.jpg

ここで、発想を転換して、Volume Valueのグリッチ発生帯域に合わせて閾値を設けたノイズサプレッサーを追加してみた。

Screen Shot 2019-10-13 at 16.24.36.png

結果は、思ったよりも効果があったが、閾値のチューニングが難しい。 単純に音量だけに対応するのではなくピッチ側と連携する方法もあるが、マネージメントの方法を思いつけず、この件はペンディングとした。

一方、音が出なくなる現象はやはりオプティマイザーが原因で、片方のチャンネルの音が途切れてしまうバグを確認できた。 現在、コンパイル時のオプティマイザーにはFastestを選択している。

帯域の設定はシングルポイントでは難しく、選択域を細かく設定することにした。

Screen Shot 2019-10-13 at 17.49.49.png

結果は「軽減」のレベルではあるが、以前よりもグリッチが目立たなくなった。

追記:

クロックが停止する・オーディオ出力が死ぬ問題は、浮いた端子のラッチアップが原因かもしれないので、追試を行う必要あり。

追記2:

従来Arpeggiatorの駆動クロックの1/2倍にRateを設定していたLFOのテンポを×1倍に変更した。

Screen Shot 2019-10-13 at 21.56.50.png

これでフレーズが不自然に途切れることが無くなったが、若干忙しない雰囲気もある。 いっそのこと、テンポの倍率を設定する仕掛けを作った方が良いかもしれない。

追記3:

使い勝手を考えて、Rateの切り替え機能を実装した。

Screen Shot 2019-10-14 at 10.11.03.png

スイッチは、Threshold設定ページ(mode2 == 9)の長押しにアサインした。

Screen Shot 2019-10-14 at 10.24.31.png

追記4:

LFOがロックアップする問題は、稼働領域設定(オフセットなし)と動作判定(オフセット値あり)の狭間に、制御信号が落ち込んでしまうことが原因と判明。 可動領域設定にオフセットを追加することで、不具合を解消できたようだ。

Screen Shot 2019-10-15 at 2.01.42.png

一方、度々発生するDACが沈黙するトラブルの原因は、やはりソフトウエアのバグではなく、「断線」が原因だった模様。
posted by Yasuski at 19:09| LaVoixski

2019年10月11日

VolumeAnt側ディテクターの改良を行う

VolumeAnt操作時に発生するグリッチを軽減するために行った試行錯誤の記録。

まず、極端に高くなってしまったオシレーターの周波数域を下げる方向で調整を行った。

Screen Shot 2019-10-07 at 21.20.01.png

下限周波数はそのままで上限値を設定、データの幅は14bitに限定している。

Screen Shot 2019-10-07 at 21.20.31.png

前述したように、グリッチが発生するポイントはVolume値を参照するWavetableの変化が急峻な部分なので、波形の中間の変化幅がより緩やかになるExpCosにWavetableを変更している。

WS002038.JPG

音の立ち上がりがなだらかになった分、グリッチの発生域がMax側にズレて使い易くなった感がある。

WS002037.JPG

改変したGNU/Octaveのコードにはオフセット値の修正が必要。

WS002039.JPG

ついでにlog2カーヴの波形を生成してみた。

WS002041.JPG

実験の結果、残念ながら変化が急峻過ぎて使い物にならなかった。

WS002040.JPG

Pitch側に応用が効きそうだが、その場合は分解能が15/16bit必要になる。メモリーに余裕を持たすことが出来れば実験を行いたいところだが、メモリー消費が90%を超える現状でそれは難しい。

WS002042.JPG

試行錯誤の過程で、Volumeディテクターの入力周波数の下限値を変更して、グリッチの周波数を調整出来そうな事に気付いた。

Screen Shot 2019-10-10 at 19.11.03.png

アウトプット値が判らないので、とりあえずレベル調整のBitShiftは1bitに設定。

Screen Shot 2019-10-10 at 19.12.21.png

結果は、何故か出力のモノラルアウトが動作不能となってしまったので、BitShiftを行わないことにした。

Screen Shot 2019-10-10 at 21.30.42.png

今後繰り返すであろう調整を容易に行うために、下限値設定用の変数をリザーヴした。

Screen Shot 2019-10-10 at 21.31.44.png

実験の結果、FTMに内装されているフィルターが有効だったので、これを最大値に設定。

Screen Shot 2019-10-10 at 21.47.00.png

ディテクター周りの変数はこの場所にまとめてある。 Volumeのウエイトを0.5程度まで軽減した場合に、出力がノイズっぽくなる弊害が発生するようだ。

Screen Shot 2019-10-10 at 21.47.20.png

Volume側ディテクターの構造を変更した影響で、限界値付近で動作するRitardandoの操作感が変わってしまった。 しばらくは試験を行うことになるが、閾値の設定を変更することを考えている。

Screen Shot 2019-10-11 at 7.39.10.png

Screen Shot 2019-10-11 at 7.40.05.png
posted by Yasuski at 08:50| LaVoixski

2019年09月21日

ESP32にWirelessMidiを実装する

ArduinoにESP32を導入した時に行った試行錯誤の記録。

1)Arduinoに対応するファイルをツールを使って導入した場合、何故かライブラリ内のAzureIoTフォルダがカラッポになる現象が発生する。 この不具合に対応するには手動でコピペを行う必要がある。

2)通信速度を115200bps設定すると、ソフト側から書込が行われるタイミングでESP32のプッシュスイッチを左→右の順番で同時押し、左→右の順番で開放する物理的な儀式を行わなければならない。 通信速度を230400bpsに設定した場合は、自動的に書き込みモードに移行出来た。

3)Wifiは2GHz帯のみ対応。

4)OSXの環境では、チップを認識させるためにデバイスドライバーをインストールする必要がある。

導入時に必要なステップはこのサイトを参照した↓。

https://lastminuteengineers.com/esp32-arduino-ide-tutorial/?fbclid=IwAR0dIrGCIasaY93aAm__FXRWWE3p2vzByHvRklDjG2xchu3Cb2CdIbl9P2w

その後、ほとんど試行錯誤に嵌ることなく通信を行うことが出来ている。

WS002023.JPG

次に、WiFiMidiにトライしてみたが、元ネタのスケッチによってRTPmidiフォーマットの送受信を簡単に行うことが出来た。

https://github.com/gdsports/midi-wifi-demos/blob/master/midi1buttonrtp/midi1buttonrtp.ino?fbclid=IwAR28rVzsWBSgSPHCwIWB-k7Z5OAnBUT1V7T4LMewg4h4aowKt3wehiqeLrk

ローカルサーバーを立ることで、2.4G(ESP32)/5.1G(Macbook)帯の併用が可能。 当初は試験的にシングルスイッチを実装しているだけなので、ここから対応するポートを増やしていく。 フットコントローラーへの実装が必須だが、デバイスを複数用意して並列運用を行うことを計画している。

メカニカルなスイッチ系のハンドリングに関してはこのスケッチを参考にした。

https://github.com/thomasfredericks/Bounce2/blob/master/examples/bounce2buttons/bounce2buttons.ino?fbclid=IwAR0BL6dDg_OHfvqe_BUfqHXw4stOLsau3fBMmw_tAWvJQbjpC_oWVx-AP-0

当然ながら、このシステムはKYMAと併用することになるが、まずはMac側でWiFi通信リンクを設定し、、、

Screen Shot 2019-08-28 at 6.26.41.png

KYMAから出力されるmidiデータの受信状態をArduinoのモニターで確認した。 ESP32側で受信しているのはベースライン。

WS002025.JPG

一方、物理側の準備としてフットコントローラーの回路を組み直すことになったが、念の為ESP32を実装せずにテストを行ったところ、電源の状態が怪しく規定値よりもかなり高めの電圧を出力している。 度重なる電源の故障は異常事態で、バルクで購入したレギュレータが不良品な可能性を疑ってしまう。内装した電池もヤレていて満身創痍な状態なのが辛い。 

ESP32のADCはほぼ正常に動作しているが、ウエイトの値を調整した方が良い感触ではある。 

結局、目標とした期限内にフットコントローラーの右側バンクを完全にリファインできたが、以前製作したものと比較して格段に動作が安定していることに驚かされた。

ESP32の外部に追加した機能はRailToRailなOpAmpのバッファー回路のみ。基板のフットプリントはESP32より一回り大きなサイズ内にまとめることが出来た。

IMG_9367.JPG

信号の並列受信を試したところ、問題なく受信できているようだ。

KYMAのTimelineを検討する作業の過程で、コントロールチェンジナンバーをKYMA側からコントロールするアイデアを思いつく。 KYMA側からスイッチの機能を切り替えられるので、足元がスッキリする。

ライヴ運用といういきなりの実戦投入を行った結果、スイッチの動きが敏感過ぎてコントロールが難しいことが判明、バウンシングの値を調整することにした。

WS002027.JPG

ここで、インターバルを設定して感度の調整を行っている。 初期設定の5msは敏感過ぎた。

これは、データの更新を行っている部分。

WS002028.JPG

ADCからのデータは12bitから7bitにダウンサイズしている。

ダウンサイズ後の7bit幅でもデータがフラつくため、この部分でデータの変化にウエイトを掛けている。

WS002029.JPG

次の部分は、プログラム・チェンジを受けて、CCアドレスを変更するためのスイッチ機構。

今のところ10ch分を用意している。

フットヴォリュームの値をmidiデータとして送出するパート。

WS002030.JPG

バッファーの値を比較して、差異が検知された時のみデータを出力する。

こちらは、プログラム・チェンジにより選択されたパラメーターによって、スイッチの動作特性をオルタネイト/モメンタリーのどちらかに選択した後、出力するパート。 

WS002031.JPG

動作確認は未だ行っていないが、スイッチの出力アドレスを外部からコントロールするための、所謂「便利機能」である。 オルタネイト動作でOn/Offのデータを出力する。

この部分はモメンタリー出力を選択した場合に動作するパート。

WS002032.JPG

実験の結果、ESP32にKYMA側から出力したnnで、フットコントローラー側出力のcc#を切り替える機構をなんとか完成させることが出来た。

Screen Shot 2019-09-05 at 12.20.26.png

KYMA側で出力を行うオブジェクト。 非常に単純な手法だが、便利なツールとなりそう。

69819586_2607184495978659_527101055402508288_o.jpg

フットヴォリュームに関しては、切り替えるとマズイ場合が多いので、プリセットの内容は要検討。

69942474_2607316242632151_6385868791439425536_n.jpg

入力されたnnに対応させて、仕込んだcc#のグループをスイッチングする。

69687416_2607317675965341_8151814233789562880_n.jpg

nnの仕込みはここで行う。

69524162_2607319219298520_8233837294415511552_n.jpg

残念ながら、モメンタリ/オルタネイトの切り替えパターンは固定で、caseの中で予め動作を選択している。 条件分岐でなんとかしようとしたのだが、上手くいかなかった。

cc#を含めて仕込みが必要なので、スイッチの属性変更がフレキシブルである必然はあまり無い。 で、学習機能をもたせる場合はまた話が違ってくるのだが、現状はpgmCngをキッチリ読み込めないという学習機能の実現以前の状態なので焦ることはないだろう。

最終的にフットコントローラーのmidi受けチャンネルを#11に制限した。 出来れば、年内に怪談スイッチの軽量版を作りたいところだが、マイクロコントローラー単位で入力端子を16ポート確保しなければならない。

フットコントローラー左側の結線を完了。

IMG_9373.JPG

まずは、入力バッファーを組まない状態でADの挙動を試す。

IMG_9375.JPG

Windows使用時には出なかった、書き込み時のアラートが気になる。

Screen Shot 2019-09-22 at 1.04.28.png

Screen Shot 2019-09-22 at 1.05.41.png

Screen Shot 2019-09-22 at 1.06.00.png

Screen Shot 2019-09-22 at 1.06.06.png
posted by Yasuski at 15:12| LaVoixski

2019年08月18日

グリッチの抑制とFTM/Detector周りの改装等

先日、テルミン奏者に楽器を試してもらったところ、左手が素早い動きを行った時にグリッチが発生する問題を指摘された。

グリッチは、左手の動作に追従できずに発生したEnvelopeデータの不連続面が原因と思われるが、これが特にピッチが低音の時に悪目立ちしてしまう。

WS001991.JPG

波形を拡大していくとよく判るのだが、サイン波の上に細かなパルスが乗っかっている。

WS001992.JPG

入力した信号は極低周波を再生した時のもので、人間の耳に聞こえているのはグリッチのみ。

WS001993.JPG

グリッチが発生する直接的な原因は、疎になり過ぎたデータによるものだが、アナログオシレーター側にも原因がありそうだ。

WS001994.JPG

プログラム側では対症療法を行うしか無さそうだが、実験の結果、フィルターの値を小さくすることで発生を抑えることが出来た。

ただし、グリッチの抑制と左手の反応速度はトレードオフの関係にあり、実験で最適値を探っていくしか無いのだが、これがなかなかに難しい。

Screen Shot 2019-08-18 at 6.24.55.png

試行錯誤の結果、それっぽく動作するノイズサプレッション機構をなんとか完成させることが出来た。 前述したように、グリッチの抑制と左手の反応速度はトレードオフの関係にあるが、グリッチの発生は特に極低音で目立つことから、出力音程に閾値を設定して閾値以下の周波数を検知した場合によりハードなサプレッションを行う仕掛けを思いついた。

閾値の設定は好みなので出来ればユーザーによって調整できれば良いのだが、パラメーターの配置が難しいのとインターフェイスの構造が煩雑になることから、今のところ機能の実装は行っていない

Screen Shot 2019-08-18 at 6.27.15.png

フィルターの初期設定は暫定だが、折衷案としてこれらの値に収まっている。

Screen Shot 2019-08-18 at 6.26.05.png

作業の過程で、FTM周りの設計を大幅に変更して無駄な条件分岐やオーディオクロックのアップエッジで計数を行うローカルカウンター等を一掃することになった。 オーディオクロックのタイミングに関係なくFTMのデータ取得確定フラッグの立ち上がりで即レジスタにデータを取り込む形に構造を単純化している。

冷静に考えるとフリーラン状態で計数を行うFTMがデータを取得するサイクル(入力によってトリガー発生の間隔が変動する)とWavetableを読みだすオーディオクロックのタイミングは周波数の桁が違ううえに、そもそも同期を行う意味がなかった。

グリッチ音の発生には良い面もあって弦にピックがあたるあの感じが図らずも再現されている。これは作ろうとして出来上がったものではないのだが「ギターっぽいテルミンが作りたかった人」にとっては行幸といえる産物だった。

ただしこれは低音でスローな演奏を行いたい人には邪魔になる音で実際に意識してみるとあまり気持ちの良いものではなかった。そこで折衷案として思いついたのが低い音を演奏した場合にエンヴェロープがスローギア化するこの機能なのだ。
posted by Yasuski at 21:55| LaVoixski

2019年07月12日

部品の実装を始める

チューニング・システム周りの操作性の向上を目指して、チューニング・ノブで操作出来る周波数の帯域を制限することを考えている。 

VRノブをサブチューナー扱いとしてノブの可動領域を1/9以下に制限しつつ、メインのチューニングをパネルマウントタイプの半固定抵抗で行う方式だ。

F2770228-01.jpg

このタイプのVRTでパネルマウントタイプのものが存在することを知らなかったのだが、

F7904221-01.jpg

VRTとVRポットと組み合わせても、マルチ・ターンタイプのVRポットを導入するより安上がりになるところが良い。

IMG_9247.JPG

組み上げたチューニングシステムは、ケースの側面に取付けることになるだろう。

IMG_9248.JPG

VRTの間には、ファームウエアを書き換えるためのUSB端子を挟んでいる。

IMG_9249.JPG

裸のVRTより操作性が向上するのも良いポイントだ。

IMG_9260.JPG

一方、新たに設計した赤いMCU基板の実装を開始している。

IMG_9261.JPG

基板は2種類で、80mm幅のOSC基板にスタックするタイプと、、、

IMG_9262.JPG

コンパクトな筐体に対応させた75mmサイズの基板を用意した。

IMG_9268.JPG

新たに購入したマルチターンVRポットのサイズが想像よりも大きかったので、これを機会に3種類のVRポットのサイズを比較することにした。

IMG_9269.JPG

SAKAE製は奥行きがあるために、ID-292への導入は不可能だった。 ID-292にはCopal製の13φと10φサイズのVRポットで対応することになる。

IMG_9270.JPG

SAKAE製のVRポットはHammond製ケースで使用することになる。
posted by Yasuski at 15:50| LaVoixski

2019年07月10日

アルミ製アンテナの製作

真鍮製で重いアンテナを改良するため、アルミ材を使った新しいアンテナを試作している。

IMG_9239.JPG

真鍮と比べて曲げ加工の難易度は下がったが、曲がり過ぎるのが問題。

IMG_9245.JPG

エクステンションの末端には、10mm径のアルミスペーサーにインチサイズのネジを切ったものを挿入しているが、エクステンション用のパイプの内径9mmに合わせて加工がを行う必要がある。

IMG_9242.JPG

スペーサーの外周を削った後にトンカチでガンガン圧入するのだが、作業は結構大変。

IMG_9244.JPG

試験運用で判明したのはTNCが意外と脆弱だったことで、特にストレートアンテナのアングル付きの基台にはSMA端子をハンダで強化したものを使ったほうが良いかもしれない。

IMG_9276.JPG

GFRP棒のアンテナ基台に孔を開ける際に使用するジグには、内径がGFRP棒とほぼ一致するアルミ・パイプを使用している。 当初はパイプ側に加工を行わず作業していたが、パイプの側面にスリットを入れることで、素材の取り外しを容易に行えるようになった。
posted by Yasuski at 19:33| LaVoixski

電源IC周りのリファインを行う

ID-292で連発した電源周りの事故に対応した基盤が届いた。

IMG_9229.JPG

今回、OSC系を緑、MCU系を赤、オーディオ系を黄に基板のカラーを設定している。

IMG_9203.JPG

電源部の改良は、放熱が厳しいID-292専用基板に帰還ダイオードの追加を行った他、

IMG_9210.JPG

レギュレーターICの放熱効率を改善する目的で大口径のスルーホールを設置し、基板裏側との熱結合を促進している。

IMG_9211.JPG
posted by Yasuski at 19:20| LaVoixski