2019年10月31日

Teensy4.0が届いた

今日は昼過ぎに届いたTeensy4.0を試しているが、これがなかなかの難物で先が思いやられている。

まず3.6からコードの移植を試みているが、当然ながらコンパイルはすんなりとは通らない。

不具合の原因は、

1)TimerOneのconfigファイルの更新を失念

Screen Shot 2019-10-31 at 20.33.56.png

2)D40番台のアドレスにないPinの設定を行う
3)ハードウエア互換のないFTMの設定

の3点で、互換性のない機能を殺した結果、書き込みを行うことができた。

Screen Shot 2019-10-31 at 18.21.01.png

が、コンパイル自体は通ったものの、書き込み後にUSB_Serialが認識されないために、立ち上がりのレポートが読めず、MCUが正常に稼働しているのか状態が全く判らない。

怪しげなEEPROMの機能を殺しても状況に変化はない。

void setup() {

Serial.begin(BAUD);
delay(500);

Serial.println(" checkPointCharie0000.");

と、電源投入後のハードウエアの立ち上がりで確認のための通信を行うコードを追加してみたが、そもそもUSBシリアルが認識されないOfflineの状態なので、これは意味がなかった。

Screen Shot 2019-10-31 at 18.48.38.png

シリアル通信機能を単独でテストした場合は問題はなかったので、ハードウエア起因のトラブルではないことが確定している。

つまり、プログラムの何処かに問題があるのだが、何故にsetupの時点で通信不能となるのか?その理由が判らない。ちなみに、USBデバイスとしては認識されている模様。

Screen Shot 2019-10-31 at 18.25.03.png
posted by Yasuski at 20:35| LaVoixski

PogoPinの実装について

手持ちの部品(結構な数の貰い物)と新たに購入する機械部品を組み合わせる場合、どうしても現物合わせになって仕舞う。

PogoPinとは中空端子にスプリングが内装された接続用のpinで、ハンダ付けが難しい場所に設定された端子にスプリングの圧力で導通を保つための部品だ。

IMG_9483.JPG

購入したPogoPinの長さは6mmで、これを丸ピンで嵩上げして使用する。 とりあえず、在庫する100本はこのやり方で組むことになる。 

IMG_9484.JPG

ちなみに、PogoPin単独で必要となる長さの実測値は9.5mmから10mmだったが、10mmという規格は手に入れ難いようだ。 9.5mmに超小型のワッシャーを噛ませてタッパを稼ぐ方法を採るのが現実的だろう。

尺が足らないPogoPinにユニバーサル基板を使った嵩上げを行ってみた。

IMG_9488.JPG

部品の転用は意外と効くもので、当面の間は6mmのPogoPinで組んだ端子のクラスタを使ってTeensy4.0の背面にあるpinに対応することになった。 ただし、基台に端子をしっかりと固着させるには両面基板の使用が望ましい。 

IMG_9495.JPG

丸ピンソケットを実装した基板専用にPogoPinを設置するための治具をDIPソケットとユニバーサル基板を組合せて製作した。

IMG_9532.JPG

丸ピンソケットはシルエットが低いために、pin単体では調整が難しい。

IMG_9531.JPG

ボード裏面の端子は0.1吋規格の正中線からズレているので、コンタクトポイントに合わせてpinの先端に0.05吋程のオフセットを掛ける必要がある。

IMG_9534.JPG

ボックスタイプのソケットの場合、シムが2枚重ねで丁度良さそうな塩梅だった。

IMG_9533.JPG

このような手間のかかる手法で量産体制に入れるかどうか微妙なところだが、その場合に不要な工程を省けるように試作の段階から考えておく必要がある。
posted by Yasuski at 12:40| LaVoixski

2019年10月30日

Teensy4.0導入時にリプレイスが必要となるpin配置に関する覚書

Teensy4.0は端子数が少ないため、現行のTeensy3.6に特化したシステムに導入を行う場合にはpinのやりくりが必要となる。

まず、pin配置の現状を整理するとTeensy3.6にリザーブした端子のうち、D1,D5,D6,D17,D18,D20,D21,D25,D26,D27の10pinが使用可能。

Teensy4.0の不足分は、D34からD50までの17pinとなるが、実際に使用しているのはD34からD39までの6ラインと、D44,D45,D48,D49のLED拡張信号の4ラインで、不足分は10本。

Teensy4.0の拡張端子はD24からD33までの10pin。その中で3.6と被るのはD25,D26,D27で、拡張端子では遊軍となるこれら3pinを再配置することになる。 他の端子は、Teensy3.6に準拠したポートに固定配線を行うが、この配線パターンは現行のAudio基板を使用することが前提としたもので、FPGAを使用したadatの実験を行う場合は、端子のアサインを考え直す必要がある。

AudioBoardへの信号ラインで今回使用を想定したのは8本だが、FPGAの信号ラインには9本が必要。足りない分はadatの出力数を制限する方向で調整するしかない。
posted by Yasuski at 12:44| LaVoixski

2019年10月29日

RGBロータリーエンコーダー/目玉スイッチの"Lavender"色を調整する

発色が悪い"Lavender"の修正を行った。

IMG_9530.JPG

まず、抵抗値を390Ωから100Ωに交換したところ、ダイオードによる逆流防止機構の影響で青が全く発色しなくなった。

不具合の原因は順方向電圧が低い赤との兼ね合いがありそうなので、電流制限抵抗を100Ωから200Ωに変更したところ、正常な発色を確認できた。

IMG_9529.JPG

今回、現物合わせで発色を調整したリザルトは、、、

ロータリーエンコーダーの場合、RGBの抵抗は1k(390/560)/470/200といった比率が妥当だった。(現物は470の代わりに560だが、この場合は若干ではあるが赤みが勝つ)目玉の場合は、1k/470/100といった塩梅で、逆流防止機構が介在しない分だけ青の輝度を上げることが出来る。

Screen Shot 2019-10-29 at 13.24.37.png

LEDは個体差が大きいために、これらの数値が完全な適正値とは言えないが、折衷案として記録しておく。
posted by Yasuski at 10:53| LaVoixski

2019年10月28日

Mサイズ筺体型テルミンの組み立てを完了する

梁にカメラ用の基台を設置したついでに、Ritardandoが発動するポイントを調整する過程を撮影した。

VolumeAntの微調整は、温度変化に弱いオシレーターには必須の作業だ。

Lサイズ/Mサイズ/ID-292の各種基板2枚ずつにFPGA及びオーディオクロック系の実装が完了している。

IMG_9517.JPG

Lサイズ2枚は最新版の基板だが、Mサイズ/ID-292のヴァージョンは旧型基板(黄)と対応するVRTのシェイプと、電源の保護回路及び放熱ランドが新調された最新版(赤)が一枚ずつとなっている。

M型筐体のアルミ・アンテナの評価を行う機体が、ひとまず形になった。

IMG_9523.JPG

今回制作したモデルは、試験的にインターフェイス群を中央に寄せているが、操作性は微妙なところか。
赤い目玉が発光しない原因を調査する必要があるが、ひとまずはオシレーターのチューニングを優先したい。


追記:で、測定のリザルトがこれ。

Screen Shot 2019-10-28 at 20.11.28.png

Screen Shot 2019-10-28 at 20.11.37.png

まず、Volume側のオシレーターのマッチングがギリギリでアウトだったので、周波数が高かったAntenna側に10pFを追加して、補正可能なレンジに周波数を合わせた。

Screen Shot 2019-10-28 at 20.13.02.png

Screen Shot 2019-10-28 at 20.13.15.png

Pitch側はなんとか修正無しで対応できそう。

次に音声のアサインを失敗していたので、これを修正した。 原因はモロに物理由来で、負電源ラインをRチャンネルの音声出力端子と繋ぎ間違えるというとんでもないミスをしでかしていたのだが、幸いなことにコンデンサーの耐圧超過による事故に至らずに済んだ。

目玉の赤が光らなかったのは、プログラム上で端子の設定(26番ポートの直アサイン)を間違えていたことが原因だった。

IMG_9525.JPG

今回は、事前にハードウエアの仕様が固まっていたお陰で、不要な試行錯誤を行うことなく効率よく調整を行うことが出来た。
posted by Yasuski at 18:40| LaVoixski

2019年10月25日

チューニング・モードにアウトレンジ表示機能を追加する

オシレーターのチューニング機構に、LEDによるレンジ表示機能を追加した。



筐体右側上下側面に設置した”ヴォリュームポット”を使って、手を体に近づけたニュートラルの位置に赤い表示が緑に変化するポイントを設定する。

Screen Shot 2019-10-24 at 20.52.13.png

オシレーターのボトム・レンジは、変数 tunerP / tunerV で指定する。 オシレーターの発振周波数がこの値を下回ると、追加したフラグ inRange の状態が High に設定される。

Screen Shot 2019-10-24 at 20.48.52.png

一方、ロータリーエンコーダー(Upper) の点灯機構に inRange の状態を判定する条件分岐を追加し、ここにアウトレンジで「赤」が点灯する仕掛けを組み込んでチューニングを行う際の指標とした。 

チューニングモードは目玉スイッチの長押し1回目で Pitch、2回目で Volume の調整モードに切り替わる。 長押し3回目はシーケンサのルート音のチューニングを行うモードが選択される。 どのモードからも短いクリック1発で通常の演奏モードに復帰する。

いまのところ、設定した閾値は暫定だが、この値で問題は無さそうだ。

Screen Shot 2019-10-24 at 21.32.53.png

ついでに、Volume側のオフセット値を変更していて、こちらも暫定値を3600に設定している。

Screen Shot 2019-10-25 at 1.35.50.png

実験の結果、4096が過大だったことから、適正値は3800程度と思われる。
posted by Yasuski at 01:55| LaVoixski

2019年10月22日

1455Mサイズ筐体の製作を再開する。

赤い1455M1601ケースに、基板及び部品の実装を始めた。

IMG_9470.JPG

ケースがタイトなために、部品の配置が難しい。 最終的にこれ以下のサイズは受注生産になるかもしれない。

IMG_9472.JPG

一方、昨晩から行っていた1455L1601ヴァージョンの通電試験は、安定した動作を確認出来たため通電開始後12時間を経過した時点で終了した。

IMG_9468.JPG

RGBロータリーエンコーダーの発色にまだ不満が残るが、ひとまずここで作業を終了する。

IMG_9469.JPG
posted by Yasuski at 16:03| LaVoixski

2019年10月21日

Lサイズ/160mm筐体の調整を行う

まず、発色がイマイチだった目玉LEDスイッチをリプレイスした。

IMG_9458.JPG

新しく採用した構造は、タクトスイッチにSMDタイプのRGB-LEDを接着した後、LEDの発光面に半球にバラした目玉を取付けている。

Pitchオシレーターの調整は、リファレンス側に実装されていた220pF(多分)を183pFにリプレイスして中心周波数を上げているが、これが適正値かどうかは微妙なところだ。

Screen Shot 2019-10-20 at 13.07.13.png

その後、Cをリプレイスした基板を組み上げて測定を行ったが、残念ながら結果は散々たるものでリファレンス側の発振周波数が上方に40kHzもズレてしまった。  周波数を合わせ込む作業の経過からオリジナルの設定値は330pFだったと結論しているが、このパーツの持つ「誤差」が、若干低めにドリフトした発振周波数に反映されていたようだ。

試行錯誤の結果得られた数値は、220+100+22pF=342pF となった。

Screen Shot 2019-10-21 at 16.04.56.png

チューニングが決まったので実際に音を出してみると、変なノイズがオーディオ・ラインに乗っている。しかも、モノ出力の#3chから音が出てこない。 

原因の特定は難しそうだが、SDカードのデータが更新されていない可能性や、リボンケーブルの断線、ポートの結線ミス等、それらしい原因を一つ一つ潰していくしかない。 100mm幅のDAC基板はなにかとトラブルが多いものの、いまのところこれといった誤配線を確認できていない。 

ノイズを気にせずに一連の操作を行ってみたが、出音の選択やLEDの点滅等のソフトウエアによる制御データの処理は正常に行われている雰囲気だ。 一方、ポートのアサインを間違えた結果発生する種類の不具合は「物理側の問題」なので、原因を探る過程でこれを切り分けていかなければならない。

不思議なことに、Threshold設定モードを選択した時だけ何故かノイズが消えるのだが、この現象が問題を解決するためのヒントになるかもしれない。

演奏を行いながらノイズが発生する状況を観察したところ、VolumeAnt側の操作によってノイズが生じるポイントが変化する一方、Muteの機能はきっちりと動作しているようだ。 ソフトウエアによるミュートが効いているので、これはハードウエアに起因する問題では無さそうだ。 以上の状況から機種別に書き換えているプログラムの複写をミスっている可能性が大きくなったので、試しに稼働実績があるLサイズ/220mm用のプログラムを160mm仕様に出力ポートを書き換えて走らせてみたところ、一発でノイズを取り除くことが出来た。

プログラムを書換えたついでにポートの配線を確認すると、これが結構いい加減な仕事で不要な接続を2ポートも発見、オープンにした場合の事故を避けるためにフローティング処理を行っておいた。 他にもオーディオ基板に至る信号ラインにコンフリクトが発見されたため、接続をシンプルな形に修正しておいた。

この筐体のオーディオボードは緑色の旧式だが、最新のボードと比べて基本的な配線は変わっていない。

IMG_9461.JPG

造りが頼りないミニジャックの評判が悪かったので、DCインレットの代わりにHiroseの6pinコネクター配置して音声出力と電源ラインを確保している。 オリジナルのミニジャックはモニター用に温存しているが、音声ラインが並列状態で直結しているのが問題。 ミニジャックに至るラインには抵抗を追加した方が良いかもしれない。。

IMG_9464.JPG

新しい目玉の発色は良好で、以前と比べて視認性が格段に向上した。

IMG_9466.JPG

追記:


稼働試験中に再発した LED2lav_ON が固定されてしまう案件に対応するため、消灯を促す fEG = LOW; を以下のポイントに再配置した。 

Screen Shot 2019-10-22 at 6.40.16.png

シーンメモリーをコールする場合。

Screen Shot 2019-10-22 at 6.39.56.png

Voiceモードを移行する場合。

Screen Shot 2019-10-22 at 6.39.49.png

機能モードを移行する場合。

Screen Shot 2019-10-22 at 6.39.39.png
posted by Yasuski at 10:26| LaVoixski

2019年10月20日

Mサイズ筐体モデルの調整を完了する

Screen Shot 2019-10-20 at 13.07.13.png

まずは、ズレの大きなPitch側の調整から始める。 該当するリファレンス側のコンデンサーを調整して(この場合は値を減らす)発振周波数を上げる方向にズレの修正を行った。

IMG_9453.JPG

一方、Volume側にも問題が発生していて、現状ではヴォリューム・ポットの変化域がチューニングに必要な帯域をカヴァーしておらず、調整を行うためのマージンが殆ど得られない状態だった。

IMG_9454.JPG

更に、プログラムを変更した際に設定した「不感帯」の分だけ実行域がドリフトしており、これに合わせてオシレーターの発振周波数を調整しなければならない。

今回は22pFをAntenna側に追加して、リファレンスに対する不感帯のマージンを中心周波数の下方向に稼いだ形になるが、これでひとまずMサイズ筐体を稼働させることが出来た。

作業の過程で行った測定から、Pitch側オシレーターの周波数変動はエクステンションの電気的な特性の違いによって大きく左右される事が判っている。 アンテナにバラストを追加する物理チューン法に期待していたのだが、kHzレベルのドリフトを発生させるためには予想よりも大きな質量が必要とされる。 こちらの調整法は、実用面を考えると微調整のレベルをカヴァーするのが精一杯かもしれない。

追記:

続いて、Lサイズ・160mm筐体の方のチューニング作業を開始した。 旧タイプのオシレーター基板は調整箇所が基板表側にあるために全バラシが必要。

IMG_9455.JPG

Pitch側オシレーターの周波数自体は修正なしでもギリギリで合わせ込めそうだが、可動域のマージンが殆ど無いのが不安要因。 なので、リファレンス側の周波数を若干下げることを目指す。

IMG_9456.JPG

該当するCの値を220から150pに減らしたが、これは多分減らし過ぎ。 大凡180〜200pF辺りが適正値と思われるが、基板が旧タイプのために組み直しに手間が掛かってしまう。 最終的に33pFを追加してトータル値を183pFとした。 

明日は配線と音声出力&電源コネクタのリプレイスを行う。
posted by Yasuski at 20:36| LaVoixski

2019年10月19日

試作機の調整を行うもオシレーターの周波数レンジが逸脱し過ぎて調整不能となる

今日は昼から手持ちの試作テルミンの調整を行っているのだが、Pitchアンテナに行ったアングル付きコネクタの補強によってアンテナの電気的な特性が変わった結果、オシレーターの周波数レンジが激変して調整不能となっていることが発覚した。

IMG_9430.JPG

うちMサイズのテルミンは演奏が不可能な状態にある。

Lサイズ(赤)の220mmモデルについては、アングル付きのSMAコネクタを使用したPitchアンテナを接続して、なんとか周波数のレンジを合わせることが出来た。

Lサイズ(青)の160mm幅のモデルは、音声端子の交換を行っていないため、テストは未了。

オシレーターの周波数ドリフトが許容値を超えた機体は、トリム用のコンデンサーを追加した後にスペアナを使って調整を行うことになる。

他の案件としては旧型のDACボードの出力電圧が新型に比べて低いことが判明している。 原因は出力コンデンサーの値の差にありそうだが、この件はアンプ側のレベル調整で避けられるので問題はないだろう。

その他に、対応するハードウエアによって微妙に仕様が異なるソフトウエアの動作が心配だったが、こちらは正常に動作している模様。

毎度々調整に苦労しているのが滑稽だが、予め周波数レンジを高く設定したアンテナに、バラストをくっつけて物理的にチューンを行う方法が現実的な調整法かもしれない。
posted by Yasuski at 17:39| LaVoixski

2019年10月18日

LFOでTotalVolumeとTransitionを制御する

LFOのRateSpeedを2倍(実は等倍)に設定したArpeggiatorのTransitionコントロールが、より効果的になった。



LFOの周波数がフレーズと同期した結果、Arpeggiatorのアタック感が薄れてより伴奏っぽくなりつつ、Transitionの推移によるフィルター効果がキッチリと出ている。
posted by Yasuski at 22:54| LaVoixski

2019年10月17日

ArpeggiatorのChoppingMode仕様時に発生するLED表示のバグ

最新版のファームウエア上でArpeggiatorの動作を確認したところ、ChoppingModeを選択した後に通常のモードに移行するタイミングによってLavender色のLEDが消灯不能となるBugが発覚した。



Bugは、Arpeggiatorのアドレスを移行してモードが切り替わるときに fEG == HIGH が固定されて、LED2lav_ON; の状態がそのまま継続される場合に発生するようだ。

Screen Shot 2019-10-17 at 14.39.36.png

この問題を解消するには条件分岐に用いているフラグ fEG をクリアすることで対処できそうなので、ChoppingModeが実装されているアドレス#17から#20に隣接する#16と#21に fEG == LOW を追加することにした。

Screen Shot 2019-10-17 at 12.03.56.png

追試の結果、LEDの状態が固定してしまう現象を回避することが出来た。

posted by Yasuski at 12:40| LaVoixski

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