2019年11月14日

4thOrderのCos波に何故かノイズが発生する案件


4周期目のピークに至る直前にリセット?が掛かっている。 原因は解らない。

オーディオデータはフルアドレスを読み出しているので、表面的にはデータの欠損が発生している兆しはない。

Screen Shot 2019-11-14 at 14.23.25.png

音声信号をライン録音した場合の波形。 4ピーク毎に歪みが発生しているが、波形がナマッているために小さな歪を感知できていない。

Screen Shot 2019-11-14 at 14.47.53.png

オシロスコープの波形では、より明瞭に歪を観察できる。

Screen Shot 2019-11-14 at 15.18.13.png

周期によっては殆ど目立たない周回もあるが、何らかの形で不具合が発生している様子。

Screen Shot 2019-11-14 at 15.18.49.png

他の波形の再生で同様なノイズが発生していないことから、Wavetableの読み出し処理がオーディオクロックの枠外に至ることによって生じる不連続面ではなさそうだが、どのような理由でこのような現象が生じているのか皆目見当がつかない。

Screen Shot 2019-11-14 at 15.11.32.png

SDカードを読み出すコードにミスは発見できず、これといった原因を見つけられない。

Screen Shot 2019-11-14 at 23.52.01.png
posted by Yasuski at 15:34| LaVoixski

SequencerModeに新たなバグを発見する

久々にSequencerのテストを行ったところ、#05から#08までのchで、条件分岐の記述忘れにより”#”を認識できない大きなバグを発見、

Screen Shot 2019-11-14 at 6.35.26.png

これを修正した。

Screen Shot 2019-11-14 at 9.15.08.png

同時に、休符の表現を行えるように、Arpeggiator#14のStep数を試験的に増強している。

Screen Shot 2019-11-14 at 8.02.01.png

posted by Yasuski at 09:22| LaVoixski

2019年11月13日

pitchBendMode専用のスレッショルド設定を追加する

偶に不便に思うことがあったpitchBendモードの起動ポイントを解決するため、新たにスレッショルドを設定する機能を追加した。

Screen Shot 2019-11-13 at 6.56.45.png

当初はLFOと同時に使用しないモードなので起動ポイントを共用できると考えていたのだが、Apeggiatorモードでは起動ポイントを共用することになってしまう。 で、この時の使用感をイマイチに感じる場面が多く、ピッチベンド専用の起動ポイントの追加を考えた。

Screen Shot 2019-11-13 at 6.53.41.png

スレッショルドの設定を行うのは、ArpeggiatorやLFO等モジュレーターの起動ポイントを設定するThreshold設定モードの裏側で、スイッチの長押しによってモードを切替える。

Screen Shot 2019-11-13 at 9.06.14.png

表示は暫定で点滅色をSKY/BLKからSKY/YRLに変更、ベース色が黄色くなるように設定している。

Screen Shot 2019-11-13 at 9.15.41.png
posted by Yasuski at 09:17| LaVoixski

2019年11月11日

新調したTransitionControlのデモ演奏。

より効果が判り易いArpeggiatorモードで音源が切換わる状態を記録した。



後半はLFOモードを併用した例。

LFOはTransitionよりも上位の関係にあるTotalVolumeを直接制御しているため、

Screen Shot 2019-11-11 at 12.10.26 PM.png

LFOのレベルが切り換わるタイミングがTransitionの状態に反映される。

よって、左手の動きに対しての反応それ自体は、よりマイルドになっている。
posted by Yasuski at 06:28| LaVoixski

2019年11月09日

1455K1601専用基板の設計

経験上、160mm幅のケースに補機類と共に100mm幅の基板を実装するのはなかなか厳しく、少しでも状況を改善するために90mmまでMCU基板のダウンサイズを試みたが、効果は微妙なところだ。

mcu_60x90mm.png

ケースに基板を配置する時に問題となるのはオーディオボードの扱いで、バックパネルを装着する場合に必要なクリアランスがどうやっても確保できそうにない。

audio_75mm.png

基盤をバカ正直にスタックせず「上屋」となるMCU基盤に対してオフセットを掛ける方法もあるが、

osc_60x100mm.png

既にMCU側の部品配置には余裕がない状態だ。 画像は試作機のRev.2版で、50x100mm規格のMCU基板 + 75mm規格のOsc & Audio基板2枚で構成されているが、新しい設計ではMCU基板をOSC基板にスタックスする分だけ黄色いAudio基板とMCU基板のクリアランスが悪化する。 いっそうのことスタックを高脚式にしてタッパを稼いで干渉から逃げる手を考えているのだが、補機類とのクリアランスを考慮しなければならず、結局最後は現物合わせで対処することになるだろう。

IMG_9470.JPG

基板のレイアウトを変更するついでに改めて回路を評価しているが、電源ライン上に高周波的な手当のつもりで適当な値のLを挿入していたことがトラブル発生の原因だった。 程度の低い話で情けないのだが、基板のデザインによって音質が変わることを今更ながら思い知らされている。 失敗への対処法は簡単で「Lを短絡すれば済む話」なので重症に至ってはいないのだが、オシレーターの電源ラインにも同様の瑕疵が存在しているのが相当にマズい状況で、

Screen Shot 2019-11-09 at 16.58.11.png

Screen Shot 2019-11-09 at 17.02.12.png

特にベタグランド間のLによる結合がトラブルの原因となっている可能性が高く、近々試作機群にはLを短絡する改装を行う予定だ。

Screen Shot 2019-11-09 at 17.00.10.png

Screen Shot 2019-11-09 at 17.02.42.png

Screen Shot 2019-11-09 at 16.54.54.png

これはあくまで偶然の産物なのだが、設計に余裕がないはずの75mm規格の基板の方が、余裕たっぷりな80/100mm規格版よりも動作が安定している。 多分コンパクトな基盤に合わせて無駄なくラインを取り回したことが原因と思われるが、小サイズの基板は実装作業の難易度が上がってしまうのが難点か。

発注を行う前にポット類の位置を微調整しているが、仮設定でロータリーエンコーダー間の垂直距離が37mm、ロータリーエンコーダーからVRTまでの水平距離が75mmとなった。 デザイン面からすると若干間延びした印象のある配置となってしまったが、回路構成上の必然があるためにこれ以上の調整は難しい。 

デザインがタイト過ぎた従来のモデルは基本設計がID-292ベースなために、RGBロータリーエンコーダーの配置に無理があった。

IMG_9618.JPG

今回は1455k専用の設計なので、操作感の向上が期待できる。

プログラム面では、制御信号ラインに多数のフィルターを挿入した結果、既に96kHzの運用が辛くなってきている。 試作機を更にアップデートしないと初歩的な不具合さえ洗い出せそうにない不穏な雰囲気が漂ってきているが、Teensy4.0導入の成否如何で今後の展開が決まるだろう。
posted by Yasuski at 11:53| LaVoixski

2019年11月08日

2019年11月07日

グリッチ抑制フィルターをTransitionに導入する

今日はVCAのエンヴェロープに関連するコードのリファインを行っていた。

当初はMasterVolumeのパラメーターをいじっていたが、

WS002037.JPG

Screen Shot 2019-11-06 at 20.49.35.png

今回はTransitionをコントロールする個別のEnvelope出力にフィルターバンクを設置して、不連続なデータの発生を極力抑える方向でチューニングを行う。 注意すべきはMasterVolumeのデータが12bit規格な点で、用法や規格が異なるTransitionにフィルターを導入する場合、帯域の設定を変えなければならない。

Transitionのコントロール波形データはフルスケール11bitのサイン波なのと、

WS001767.JPG

Screen Shot 2019-11-07 at 10.45.06.png

ピークを超えてデータを読む用法なので、フィルターの減衰率は値の変移が大きくなるピークポイントを中心に大きく設定することになる。

各フィルターの係数には、管理が楽なようにグローバル変数を設定している。

Screen Shot 2019-11-07 at 11.18.04.png

フィルターの係数は、変化がなだらかになるように基本値から0.7を掛けて数値を決めた。 

大改装の機会にTransitionの間隔を従来の400から800に広めてみた。(アドレスのフルスケールは4096)

Screen Shot 2019-11-07 at 13.21.59.png

確かに、オシレーターを切替える時の変化がなだらかになって使い易い印象が得られた。 ただし、稼働範囲内でピークが2つ得られる従来型の方が表現の幅がある。 ピークの山を使った用法の重要性を判断した結果、結局は元の数値に戻すことになった。

Screen Shot 2019-11-07 at 14.09.05.png

Transitionの変更によって、MasterVolumeの方にも数値の調整が必要になった。 最初に大雑把な数値の配列を試しているが、問題が発生する帯域のフィルターを強化する方向で調整を行う必要が認められた。

Screen Shot 2019-11-07 at 22.27.14.png
posted by Yasuski at 23:48| LaVoixski

2019年11月06日

グリッチの抑制について

Volumeをコントロールするためのデータストリーム上に不連続面が発生し、それがノイズとして認識される現象をグリッチと仮称している。

WS001992.JPG

この波形から、クリップが発生していない中音量域で出力に妙な振動が印加されていることが判る。

当初は出力カーヴを規定するWavetableを読み出す際に発生した不連続なデータに対処するため、12bit幅の出力レベルにしきい値を設けた後、それぞれの帯域毎にフィルター切り替える方式を採用していたが、結果は殆ど出せなかった。

WS001993.JPG

次に思い付いたのはDCOをコントロールする周波数のデータを帯域分割してエリア毎にフィルターの値を設定する方法で、特にグリッチが目立つ低い周波数帯をメインに、データ読み出しアドレスと、Wavetableのアウトプットの双方にフィルターを掛けてみた。

Screen Shot 2019-08-18 at 6.24.55.png

ただし、グリッチの発生を抑制するフィルターの強化とエンヴェロープのレスポンスはトレード・オフの関係にあるため、闇雲にフィルタリングを徹底することはできない。

そこで折衷案を探ることになるのだが、極低域の周波数ではあまりアタック感を求められそうにないと仮定して、フィルターの影響で不自然な印象が与えられることのないギリギリのラインを探った。

結果は、出力値による帯域分割よりは若干状況が改善された感があるものの完全な消滅には至っておらず、妥協点スレスレの微妙な仕上がりとなった。

WS001994.JPG

その後、音声出力に発現するグリッチ問題の対処法として、既に実装している「Volumeを制御するWavetable関連のデータを平滑化する機構」の処理ポイントを2段構えに拡張した。

最初に行う処理は、Volumeアンテナ側の復調信号から得られるWavetableを駆動するためのアドレスデータ (12bit) の平滑化で、ここに設置しているフィルターアレイはオシレーター出力の「周波数」に対応させている。 特にグリッチが悪目立ちする低域に対してはフイルターの効きが強化され、アドレスデータの変化量を圧縮する。

Screen Shot 2019-11-06 at 20.47.10.png

次にフィルターを配置しているのは音量が変移するカーヴを記録したWavetableからのアウトプットで、

WS002038.JPG

特にグリッチの発生が目立つ低〜中音量域にフィルターアレイを配置し、ヴォリュームカーヴに不連続な「段付き」が発生しそうなポイントに対して、データの変化量を制限している。

Screen Shot 2019-11-06 at 20.49.35.png

これらの手当を行った結果、完全ではないもののグリッチの発生をそれなりに抑え込むことが出来た。

最後はチューニングの問題なので、実際に運用を行いながら最適値を探していくことになる。
posted by Yasuski at 23:33| LaVoixski

楽器の個体差がEEPROMに記録した補正値から可視化される

EEPROMにストアした、楽器個体固有のドリフト値を記録した。

Screen Shot 2019-11-06 at 8.25.21.png

Screen Shot 2019-11-06 at 8.19.24.png

Screen Shot 2019-11-06 at 6.29.32.png

Screen Shot 2019-11-06 at 8.27.09.png

結果に結構バラつきがあるのが興味深いが、たとえそれがアバウトなものであっても個体差をカヴァーする機能が必要なことが判った。

Screen Shot 2019-11-06 at 8.50.36.png

手動チューニングの指標となるLEDが点灯するスレッショルドの推奨値は、実験の結果2100辺りにまとまりそうだ。

実験の過程で、コンパイル後のデータのアップロード時に発生したと思われる「データの読み間違い」でLEDが点灯しなくなるという謎の案件が発生、バックバネルを取り外して、ハードウエアの点検を行う羽目に陥った。

結果は後に「MCUがシャックリもしくは誤飲をしたらしい」と判明したのだが、まさかこれがプリミティブなLEDの点灯回路に作用するとは思いもよらず、最終的にはLED_Blink(Lチカ)で回路の健全さを確認してようやくハードウエアの故障が否定されることになった。

IMG_9616.JPG

回路が正常な場合は、コンパイル終了後に赤い目玉が点灯する。
posted by Yasuski at 09:03| LaVoixski

チューニングシステムを改良する。

EEPROMに機体固有のオフセットデータを登録するシステムの実装を完了した。

新たに加えられたオーヴァークロックの最高速度での実装は誤動作が頻発して失敗に終わった。 

Screen Shot 2019-11-06 at 0.12.31.png

コンパイル時のオプティマイザーの選択はSmallestでは動作が不安定なようで、今回はFastestを選ぶことになった。 サンプリング・レートを96kHzに設定していたことも不調の原因で、オーディオクロックによるattatchInterruptの介入が限界を超えてEEPROMに書き込みを行えなかった。 

その後、EEPROMの書き込み処理をcli(); sei(); で包んで、インターラプトの介入に対応した。

Screen Shot 2019-11-05 at 23.03.26.png

目玉スイッチの長押しで入るアナログ・オシレーターを物理的にチューニングするモードには、発振周波数の下限値をLEDの発光で知らせてオシレーターの素の周波数を観測する機能が装備されているが、Volume側のモニター時に誤って音量調節用のオフセットが掛けられた設定を読んでいたことに気付かず、EEPROMに記録された「ロータリーエンコーダーの」オフセット値を印加した結果、モニター周波数が大幅に上昇してしまうトラブルが発生した。 

ディテクターからの出力を直接を読めるようにコードを改変して、ようやく本来のモニタリングが行えるようになったが、Volume側はダイナミックレンジの扱いが難しく、この部分でいろいろと齟齬が出ていると思われる。 今回、発振周波数を音で客観視出来る設定にシステムを変更したことで、改良が進めばよいのだが、、、。

Screen Shot 2019-11-05 at 23.08.11.png

各オフセット値の書込みは、Pitch / Volumeのチューニングモード(緑&青)の選択時に、ロータリーエンコーダーのトップを長押しして行う。 

一度設定してしまえば、再起動時にロータリーエンコーダーの調整は最小限で済ますことが出来た。 

今回、ロータリーエンコーダーのオフセット値を測定した後に、改めてLEDチューナーの設定値を調整している。

Screen Shot 2019-11-05 at 23.01.54.png

起動時に毎度、大きな修正を行っていたVolume側の操作が必要なくなったことは大きな進歩と言えるだろう。

posted by Yasuski at 00:29| LaVoixski