2020年03月08日

出力波形の確認を行う過程でAudioExciter機能関連のBugを発見する

BIAS切り替え回路の接続を変更した最新回路による出力波形の記録。



スレッショルドポイントの設定を失敗していたので、もう一本撮り直し。



オシロスコープのトリガースレッショルドを最適化した修正版の映像。 今回は、Distortion と Transition のオン/オフによる波形の変化を記録している。

ディストーションをオンにした状態のフルゲイン出力の波形がトーンホイール状なのが興味深い。音もそんな雰囲気がする。

スピーカーからの音をマイクで拾って居るために録音のクオリティーはイマイチだが、実際の出音のイメージはこちらの方が近いかもしれない。



LFO使用時に発生するGitterの記録を同時に行っている。 LFOの動作に出力の制御系が追いつかず、鋸刃状のノイズが発生している。



Mサイズ筐体のAudioBoardは別設計なので若干音のニュアンスが異なる。 これはTransitionによる波形の推移。 今回の音源ソースは、マイクではなくライン録音。



個別の波形出力はこんな感じ。 波形の歪が大きいが、聴感上は然程問題を感じない。

テルミンの単独出力波形の確認を行う過程で、Exciter(波形変換モード)の動作不良を発見し、コードの修正を行った。



バグは書き込み時のスイッチ長押しのルーティンに潜んでいて、複数設定していたmode判定のプライオリティの設定ミスが原因だった。

具体的にはmode7とmode2のうち、後者の条件分岐判定が優先される状態でbreakが発動して、データの書き込み&波形の再構成がスキップされていた。

修正後に動作を確認しているが、フィジカルコントローラーの多機能化に伴うコンフリクトがまだまだ潜んでいる可能性がある。

追記:

案の定、TransitionWaveformとDistortionSWの記録が行えないバグが見つかったので、原因となっていた箇所を修正した。

WS002080.JPG

WS002081.JPG

WS002082.JPG

WS002083.JPG

これらのバグは、整備中の試作モデルの波形観測を行っている過程で発見することが出来た。 

波形観測の後半は、adat系の信号を取り回すオーディオシステムの確認のため実験だったのだが、副産物として、AudioBoardのレベル設定等、整備のメソッドを確立しつつある。

こちらは、調整後のLサイズ筐体(一番旧い160mm幅のモデル)の挙動を記録したもの。



非直線回路の過渡的特性が、破綻なく綺麗に移行しているのが判る。

posted by Yasuski at 07:18| LaVoixski

2020年02月28日

Msize筐体専用基板の新調とアナログ・スイッチの配線について

ケースに孔を開けて基板を仮組みしているのだが、孔開けの精度が絶望的にアカン感じ。 

IMG_9782.JPG

基板のクリアランスがギリギリなのは想定内だが、補機類の配置をしくじらないようにしなければならない。

IMG_9813.JPG

孔開けのズレを解消するために、次回の工作でホールソウを試すことにした。

IMG_9814.JPG

新設計の基板には、MCU接続用のPogoPinを使用する。設置するPinの長さは12mm位が妥当か。

IMG_9778.JPG

IMG_9805.JPG

基板同士のクリアランスはなんとか維持出来そう。 仕様が固まったら、Hammondに加工済のケースを発注するのが正解かもしれない。

IMG_9783.JPG

MultiTurnVRを設置するスペースがギリギリで辛い。 

IMG_9786.JPG

ホンでもって相変わらず孔の位置が微妙にズレてしまう。

IMG_9795.JPG

材が微妙に粘るのもズレが生じる原因か。 より厚みのあるID-292のアルミ材はサクサクと削れてズレが少ない。

IMG_9817.JPG

ホールソーが到着したので、停止していた孔開け作業を再開した。

今回は8mmと10mmを試したが、8mmはタッパが足りず板に傷が付いてしまった。裏面からアクセス出来ない場合はプラワッシャー等を使った防護策を講じる必要がある。

ホールソーは下孔を中心にして一発で大穴が開くのが良い。 これで工作精度の向上が達成できそう。

残るケースの加工は裏板のヴェンチレーション孔と本体?に空けるUSB端子で、それらを除いて作業はほぼ終了している。

IMG_9853.JPG

その後、組み上がったオシレーター基板が発振しない原因を探っていたのだが、プリント基板の配線ミスという極単純な失敗を発見、これを修正した。

IMG_9857.JPG

配線の修正後に発振を確認できたが、

Screen Shot 2020-02-22 at 1.45.33.png

ヴォリューム側の時定数の設定を間違えていたようで、こちらは不足側に66pFを追加という現物合わせで対応した。

Screen Shot 2020-02-21 at 23.19.28.png

Screen Shot 2020-02-22 at 7.27.54.png

一方、DA基板のディストーション/出力レベル切替えスイッチの設計がイマイチなので、これをソフト側の制御でなんとか出来ないか思案を始めた。

LV2p3AudioSch75mm.png

配線の変更は、DistortionとLevelShifter関連のアナログスイッチを全て並列化しつつ、従来接続していたD2端子(現在はTransitionWaveformSelector連動)をLED表示のみに切り替えている。 

WS002079.JPG

また、D13のみでコントロールしていたDistortion系の出力に、正論理でLED表示を行うための反転出力"D50"を加えているが、このD50によって本来はオルタネイトに動作していた逆極性のスイッチグループを平行に駆動している。

WS002078.JPG

変更の結果は良好で、ステレオ出力に現れていた不要な歪を軽減することが出来ている。

WS002077.JPG

旧式基板の配線にも変更を行ったが、端子のラインアップが少々異なるため、配線の取り回しには若干の変更が必要となった。

IMG_9864.JPG

こちらは、Lサイズ筐体の配線。何れにしてもトグルスイッチICの極性が逆転していることに注意が必要だ。

IMG_9863.JPG
posted by Yasuski at 06:42| LaVoixski

2020年02月09日

PitchAntenna用エクステンションのコネクターをリプレイスする

接続が不安定だったPitchアンテナの接点をPogoPinに改良するついでに、アルミアンテナのコネクターを全てSMAにリプレイスした。

IMG_9769.JPG

SMAはTNCの大凡1/4の体積で、物々しさがなくシンプルなところが良い。

IMG_9768.JPG

接続が確実になった所為か、以前よりもピッチの予期せぬ変動が抑えられた感触がある。

SMAはTNCに比較すると強度に若干の問題がありそうに見えるのだが、圧入構造のアングルパーツに必要なハンダによる補強が容易なので、構造体の「分解」を含むトータルの強度はSMAの方が上になる。

IMG_9740.JPG

アングルの付いたSMA端子は四角い基台にコネクタが圧入されている構造で、直角にアンテナを取付けるにはコネクタの接合部をハンダで固定して強度を稼ぐ必要がある。

IMG_9741.JPG

SMAコネクタは表面積が小さく、アンテナ全体のシェイプがスッキリする。

IMG_9742.JPG

TNCとSMAのサイズを比較すると、SMAのコンパクトさが実感できる。

IMG_9759.JPG

ついでに残りのアルミ製アンテナの端子もSMAにリプレイスしておいた。

試験的にAmazonで購入した3Turnのプラスティック導電体のVRを導入した。このポットは単純にCV生成する為に分圧を行っているだけなのだが、リプレイス後の挙動が予想外で、Pitch側のチューニングのセンターがズレたうえに挙動がやたらとセンシティヴになってしまった。

IMG_9269.JPG

これはどう考えても異常な反応なので回路を精査したところ、交換したポットの特性が記載された"B"ではなく"A"カーヴのようだ。 このままでは非常に扱い難いので、ポットの配線を逆接続に組み替えた後、ノイズ除去用のコンデンサーを仕込んだところ、動作の不具合は解消された。

購入した小型ポットの値は貼ってあるシールの値を信用するしかないのだが、抵抗値が正しい一方でカーヴが間違って表記されていたようだ。 半額セールで購入した製品故に、訳あり品だったのかもしれない。

ちなみに、VRの特性がAカーヴであっても変化の方向が適正であれば何の問題もない。 そもそも、CVの変化特性がリニアではないチューニング機構では、そちらの方が却って使い易い場合がある。

posted by Yasuski at 00:00| LaVoixski

2020年01月28日

フィルター選択機構の条件分岐をifからswitchに変更する

ifを使って複数の条件に分岐を掛ける場合、参照先のソースを全てチェックする分だけ不要な時間が消費される。 例えるなら、1番最初に設けた条件に合致した後も、2番目以降に設定した条件のチェックを行うことになり、その分だけ計算機のリソースが空費されてしまう。

switchは、入力された整数を参照してcase毎に分岐させて処理を行う機能で、breakを行うことでプログラムの下流に配置された無駄な参照と評価をスキップすることができる。

ただし、これを使う場合には事前に対象となるソースを加工してパラメーターをハンドリングが可能な規模の整数に刻んでおく必要がある。 

改修を行う前に、まずはcase判定用のレジスタをリザーブする。

Screen Shot 2020-01-26 at 19.24.32.png

入力するソースを除算してその結果からレベルを判定し、分岐先でディテクターアウトの変化に掛けるウエイトを選択する。

Screen Shot 2020-01-26 at 20.53.34.png

ifに比べてプログラムがより判り易い構造になった。

Screen Shot 2020-01-26 at 20.52.44.png

何れの場合もデータを16段階に分類している。

Screen Shot 2020-01-26 at 20.53.10.png

レベルの判定を等間隔で行う場合は以上の手法で問題はないのだが、不等間隔でポイントを設定したい場合は、ifによる条件分岐が必須となる。 今回は多項式の表現を用いて視認性をより向上させている。

Screen Shot 2020-01-27 at 10.26.43.png

最近のコンパイラは賢いのでifからswitchに記述を変えても余り差はないという話があって、場合によっては速度が低下することもあるらしい。 

体感上は若干の向上が見られているのだが、これも気分の問題である可能性は否定出来ない。 判り易い判定法としては、廃止したディテクターのstepを比較してアウトプットの同期を切替える機構を復活させ、それにswitchを組み込めばハッキリするので、後ほどこれを試してみる予定。

追記1:

switch投入後のベンチマークとして、一部のモードで動作不良が発覚して廃止に至った「参照step切り替え機構」を復活させてみたが、以前に見られた5和音以上の発音で一部のEnvelopeに遅延が出る不具合が完全に解消されていた。 今回の改訂版では条件分岐を行うルーティンを2箇所追加した分だけタスクが増大している筈だったので、これは予想外の健闘と言えるだろう。

Screen Shot 2020-01-28 at 8.03.00.png

RAMの消費が以前より抑えられているようだが、これは合理的なリソース配分が行われたことを意味している。

よって、改変の御利益はアリと判定する。

追記2:

試験運用の結果、ピッチの中間域という微妙なエリアでバウンシングが発生しだしたため、プログラムのヴァージョンを元に戻すことになった。 出来ればLEDマーカーを仕込んで境界域の挙動を徹底的に調査すべきなのだろうが、とりあえずは現状で不満の少ないヴァージョンを選択することにした。
posted by Yasuski at 02:08| LaVoixski

2020年01月25日

TransitionMode下で発生するエンヴェロープの遅延に対処する

5Voice/PresetTuneModeでTransitionModeの特定の波形プリセットを選択した場合に、オシレーター2のエンヴェロープが遅延する謎現象が再発している。 いまのところ解決策は発見できておらず、問題が発生する発音パターンのプリセットを回避する対症療法を行うしかなさそうだ。

Screen Shot 2020-01-25 at 7.36.04.png

トラブルの発生はMCUの処理能力をオーヴァーした結果なので、これからシステムのダイエットを行っていくことになるのだが、まずは正攻法としてトラブルが発生する発音パターンを把握して原因を解析した後に、発音数を減らす方向で調整を行ってみたが、効果は全く無かった。

システムダイエットの過程で、コンパイラ頼りで適当なデータ型に記述していた箇所、例えば16bitでデータをハンドリングしているところにFloatを突っ込んでいたりするのがマズそうなので、データをキャストして辻褄を合わせることにした。

まず、取り扱うデータ幅を拡張するために、受け側のデータ幅を32bitに設定し直す。 

Screen Shot 2020-01-25 at 7.34.51.png

Pitchデータは16bitでハンドリングしているので、Floatを乗算した後に

Screen Shot 2020-01-25 at 7.35.19.png

データ型のキャストを掛けている。

あと、ステップ数でディテクタの結果を補完するタイミングを切り替える機構を廃止して、

Screen Shot 2020-01-25 at 7.36.21.png

Screen Shot 2020-01-25 at 7.36.36.png

Screen Shot 2020-01-25 at 7.37.29.png

Screen Shot 2020-01-25 at 7.37.49.png

代わりに元データを16bit幅で丸めていた各Transitionの制御信号を32bit精度に変更し、結果をbitshiftする方式にVolumeコントローラーの構造を変更している。

Screen Shot 2020-01-25 at 7.37.01.png

改変のリザルトはマアマアで、グリッチは相変わらず発生するもののエンベロープの遅延を無くすことができた。

削除したステップ数による切り替え機構は有効なので、Teensy4ではこれを復活させることになるだろう。


posted by Yasuski at 22:28| LaVoixski

2020年01月20日

ディテクタの改良

Pitch/Volumeデータが確定するタイミングを、FTMキャプチャ出力が更新されるサイクルの比較とadd_value(wavetableのポインタ)に設定した閾値で切替える機能を追加した。 

Screen Shot 2020-01-20 at 1.47.43.png

更新サイクルが長くなった方のタイミングで処理が行われ、補完のステップにはそれに準拠した値が設定される。

Screen Shot 2020-01-20 at 1.48.02.png

以前行った実験で、Pitch側のタイミングでデータを更確定させると高域でノイズが発生する現象を確認していたが、add_valueに閾値を設定しなかった場合に同じ症状が発現した。 

Screen Shot 2020-01-20 at 1.48.30.png

切替機能の実装後、低域で発生するグリッチが減少した一方で一定の周波数におけるバウンシングの発生を確認している。

オシレーターを物理的にリチューンするとバウンスが消滅することが判明しているが、原因がデジタル側のチューニングシステム内に潜んでいる可能性は否定できない。

現在は暫定でadd_valueの閾値を1000に設定しているが、これは低い方に修正を行うことになりそうだ。

そろそろLocalVariableに割振るRAMの容量が怪しくなってきたので、Wavetableを削除してRAMの余裕を増やしたが、

Screen Shot 2020-01-20 at 0.01.11.png

Screen Shot 2020-01-19 at 17.06.32.png

重タスク環境下でフリーズが発生することが判明、オプティマイザをSmallestCodeからSmallestCodeWithLTOに変更する必要が生じている。

その後、オシレーターのリチューンを行う過程で、ディテクタが参照するオシレーターの素の発振周波数の下限値がバウンシングの発生要因となっている可能性が示唆された。 低い方に周波数を拡張した場合にバウンシングが発生することから、入力信号のアップエッジのタイミングで瞬間値のキャプチャを行うリングカウンタが「一巡する周期」との関連性が疑われるが、その前にハードウエアの個体差から生じる物理的な影響を確認しなければならない。
posted by Yasuski at 06:55| LaVoixski

2020年01月14日

The waveforms around the lower frequency area

出力波形をキャプチャして、低域で発生するグリッチの観測を行った。



Lchのバイアスポイントが変動しているが、これは回路構成によるもの。

Screen Shot 2020-01-13 at 9.48.40.png

ほぼDCな出力周波数で、左手を動かした場合に発生するグリッチの波形。

Screen Shot 2020-01-13 at 8.14.57.png

マイナス側に振れたグリッチの波形を観察する。

Screen Shot 2020-01-13 at 8.15.17.png

波形を拡大していくと、ノイズに対して補完が行われているように見える。

Screen Shot 2020-01-13 at 8.17.05.png

より高速で波形をキャプチャできるオシロスコープでグリッチを観測する。やはり信号に乗っているノイズ成分に対して補完が行われているように見える。

Screen Shot 2020-01-14 at 14.34.26.png

ディテクタとして使用しているD-FFの電源回路に挿入した"L"が回路に影響を及ぼしている可能性があるため、

WS002072.JPG

これらを取り除いた結果、ノイズの軽減を確認できた。 ただし、完全なノイズの排除には至っていない。

WS002073.JPG

今回も Transition Mode を記録しているが、オシレーターを乗り換えるレスポンスを速い方にチューンするとグリッチが増えて仕舞う仕様故、帯域分割したウエイトの設定は実用性との折衷を行うことになる。



ディテクタのオプティマイズを更に進めた出力波形。



低域での安定性を高めるためにStep数の多い方のディテクタを選択して、データ出力の同期を行っているが、これも完全ではない。
posted by Yasuski at 10:12| LaVoixski

2020年01月12日

Hammond/1455K1601専用サイズの基板が届いた

新しい基盤にFPGAを実装し、

IMG_9738.JPG

ファームウエアを書き込んだ。

WS002071.JPG

基板の配置に関してはある程度のマージンが確保されているのだが、ケース上に展開するインターフェイス系部品の配置を優先して基板のセンターを出した場合、ギリに設定しているオーディオ基板とMCU基板のクリアランスが心配になってくる。 厚み方向のクリアランスは現物合わせとなるので、ケースの加工は基板が完成した状態で行うのが安全だろう。

ここ連日、周波数ディテクタのチェックというか最適化を試行錯誤しているのだが、一定の周波数帯域に妙なバウンシングが発生する現象に悩まされている。 バウンシングはオシレーターが冷えた状態で発生する兆しがあるが、家電製品からの電源経由もしくは放射による高周波の影響も看過できない。 電波暗室の必要を感じるレベルというのは大袈裟でもなんでもなく、放射系のノイズに関してはどこもかしこもが劣悪な状態にあると聞く。 廃棄処分のホットカーペットでシールドを作ることも考えているのだが、日本家屋は肝心のアースが甘いのでその効果は限定的になりそうだ。
posted by Yasuski at 15:43| LaVoixski

Pitch側データ出力の更新と線形補間をVolume側がデータを更新するタイミングと同期させる

左手のレスポンスを改善するために、Pitchディテクタのサブルーチン内に展開していたVolume関連の処理をPitchディテクタ関連の処理と共にVolumeディテクタのサブルーチン内に移し替えた。

Screen Shot 2020-01-12 at 5.27.40.png

これでVolume側のデータが更新されるタイミングにPitchデータの更新が同期されることになったが、右手側の追従性に問題は無さそうだ。

Screen Shot 2020-01-12 at 5.28.20.png

グリッチが若干増えているが、速いパッセージの演奏に耐えうるレベルまでレスポンスを改善することが出来た。

左手のレスポンスとグリッチの抑制はトレードオフの関係にあり、現時点で自分が持つスキルでは折衷を行うのが精一杯だが、この「折衷」のポイントには厳密な解がなく個人的な趣向が反映される。
posted by Yasuski at 04:25| LaVoixski

2020年01月10日

Pitch/Volumeの同期を行う

Volume側データ出力の更新と線形補間をPitch側がデータを更新するタイミングと同期させる案を試してみた。

Screen Shot 2020-01-10 at 18.31.41.png

結果は、左手のポジションションに合わせてグリッチの周波数が変化しなくなった一方で「均一にノイズが発生する」現象が発生、しかもこれがPitchの全帯域に影響することが判明した。

Pitchデータの更新が行われるタイミングでVolumeデータに発生する不連続性が固定された結果がノイズとして認識された訳だが、用法で逃げることが難しい上に全帯域に渡ってノイズが目立ってしまうのは本末転倒で、実験はアイデア倒れに終わった。 

ただし、ノイズが「均質化」したのは朗報でもあり、この手法を完全に放棄するのは拙速な判断かもしれない。

Screen Shot 2020-01-10 at 18.33.44.png

なんとかノイズの発生を抑え込む方法はないかとフィルターの数値をいろいろと試してみる過程で、出音に発生するリングモジュレーターのような変調が気になりだした。

ビートが発生する原因は、デモジュレートされたPitch/Volume信号のアップエッジ間を計測するカウンタが「バラバラなタイミング」でデータをキャプチャした際に発生するデータの周期的な不連続ポイントの影響と思われる。 この問題を解消するために考えたのがPitch側のサブルーチン内に確定したVolume側のデータをキャプチャする方法だったが、肝心のVolumeディテクタ側の設定が定まらず、実装は棚上げとなっていた。

今回はVolumeデータを生成するサブルーチンから「丸め処理が行われたデータ」を拾う代わりに、Volume側がキャプチャした素のデータを

Screen Shot 2020-01-10 at 18.34.48.png

Pitch側のデータが確定するタイミングで取り込み、Pitchデータの処理を行うサブルーチン内でVolume側の丸め処理を実行する構造に処理プロセスを変更した。

Screen Shot 2020-01-10 at 18.33.13.png

結果は満足が出来るもので、妙なビートの発生がなくなったうえにグリッチの発生を低減させることに成功した。
posted by Yasuski at 18:29| LaVoixski

2020年01月03日

FrequencyDetectorの再構成を行う

今日は半日周波数ディテクタの調整を行っていたのだが、最終的には以下に示す構成に落ち着いている。

Screen Shot 2020-01-03 at 21.09.57.png

LEDによる有効領域の表示は大凡ではあるが設定したダイナミックレンジに準じるものとなった。

Screen Shot 2020-01-03 at 21.10.14.png

分周率は 1/8 に設定した。 これ以下の分周率ではディテクターの挙動が不安定になることが実験で判明している。

Screen Shot 2020-01-03 at 21.10.47.png

オフセット値は試行錯誤の結果、8191 とした。 12bitのデータ幅を底上げして、見掛け上13bitのデータを扱うことで、アンテナの有感域(物理)を調整している。 

高い方のリミット値は現行 "15" に設定しているが、これは暫定値で再考の余地がある。 

試行錯誤の過程では、より高精度なコントロールを行うことを目指し、FTMの分周率を操作してディテクタのダイナミックレンジを広げる事に腐心していたのだが、、、

Screen Shot 2020-01-03 at 15.38.54.png

ディテクタのスイートスポットがピーキーになり過ぎて、調整が酷く難しい代物となってしまった。

Screen Shot 2020-01-03 at 15.39.10.png

可動域を調整するために対症療法でビットシフトを行って、帯域を制限したものの、、、

Screen Shot 2020-01-04 at 6.29.47.png

1) 速いパッセージに左手の動きが追い付けない 
2) Transitionの感覚が不自然になり乗換えのスムーズさが失われた 
3) スイートスポット化した稼動域の影響で、調整の難易度が上がる 
4) LFOの効きが極端に悪くなった

と結果は散々だった。

諸々の不具合が確認される一方で「グリッチが軽減する」という大きなメリットが存在したのものの、如何せん左手の動きに対するレスポンスが悪過ぎたうえ、Transitionのスムーズな運用が出来ない設定の採用は最終的に論外と判断することとなった。

そういえば、EtherwaveのVolume側の回路構成はBPFによってオシレータからの出力値を積分する設計だったが、左右のディテクタの構成がかなり違ったものになるのは当然の帰結なのだろう。
posted by Yasuski at 23:09| LaVoixski

2019年12月30日

LFO/PITCHBENDのThreshold 設定項目の改良

LFO/PITCHBEND が発動するスレッショルドポイントの設定を行うMode9の項目の切り替えを下側のポットで行えるように、インターフェイスを改良した。

Screen Shot 2019-12-29 at 17.37.07.png

Screen Shot 2019-12-29 at 17.46.12.png

同時に、上側ポットの長押しで行っていた項目の切り替えを廃止した。

Screen Shot 2019-12-29 at 17.47.58.png
posted by Yasuski at 07:25| LaVoixski

2019年12月29日

FrequencyDetectorの改装を行う

今日は、年内最後になるかもしれないプログラムの大改装を行っている。

ここ最近の試験運用で気になっていたのは、左手の分解能を「粗く」感じることで、実際のところはどうなのかをLEDのマーカーを使って調べてみると、本来12bit幅はある筈の変化量が高々10bit程度なことが判明、周波数ディテクタ関連の設定を根本的に考え直さなければならなくなった。

Screen Shot 2019-12-29 at 16.12.17.png

チューニングモードで左手側のダイナミックレンジ=聴感上の周波数変化を測ってみると、これが実質1Octに満たない状態で、なるほどこれは由々しきナローレンジだ。 周波数が低い方のレンジを稼げないのはFTMの設定の問題で、プリスケーラの分周率を上げることでディテクトが可能な最低周波数を拡張した。 

Screen Shot 2019-12-29 at 14.40.34.png

改装後は大凡12bitのダイナミックレンジを確保できたが、改変のついでにディテクター出力のオフセット値を現実的な領域まで狭めて、全体の変化量に合わせた。

Screen Shot 2019-12-29 at 14.34.15.png

Volumeカーヴの出力は専用のWavetableにアンテナからの復調信号のアップエッジをカウントしたレアデータを対応させて生成しているが、よりスムーズな変換を行うためにレアデータの方にも新たなLPFを噛ませることにした。

Screen Shot 2019-12-29 at 14.34.45.png

再起動後に謎な挙動を示すオフセットの設定不良は、ロータリーエンコーダでオフセットを調整してEEPROMに記録する際に、修正値にデフォルト値の加算を忘れていたことが原因だった。

Screen Shot 2019-12-29 at 14.37.54.png

暫定的に同じ値を割振っていたDetectorOutとWavetableのLPFを個別にチューンした。 特にDetectorOutの方は周波数が高くなる方向で音量が小さくなるように逆転した設定を行っているが故に、周波数の変動率はピアニッシモの方が大きくなる特徴があり、それに準じたLPFの帯域設定を行う必要があった。

その他、TransitionControlで行っていたモジュロ演算を簡略化して、構成をシンプルにしている。

Screen Shot 2019-12-29 at 14.35.19.png

改良の結果、グリッチは依然として発生しているが、発生域とレベルをそこそこ押さえ込むことが出来ている。
posted by Yasuski at 16:19| LaVoixski

2019年12月26日

RGBLEDをanalogWriteで制御する

pinが足りないTeensy4の不足分を補うために、LEDの発色をPWMでコントロールすることを思いついた。

Screen Shot 2019-12-26 at 5.36.13.png

予め発色を指定できるので、LEDの輝度がバラついた場合の対処が楽そうなところが良い。

Screen Shot 2019-12-26 at 5.06.40.png

setColorというサブルーチンを使って、RGBタイプのLEDを一括に制御する手法で、今まで個別に指定していたLEDの操作を簡単に行うことが出来る。

Screen Shot 2019-12-26 at 5.08.05.png

このように、LEDを制御する記述がシンプルに整理された。

Screen Shot 2019-12-26 at 5.08.55.png

予想される問題はPWMから発生するノイズだが、これは実験してみないと判らない。
posted by Yasuski at 05:38| LaVoixski

Teensy4.0にFLEXPWMを実装する

コンパイルが通るか通らないかという低いレベルの話ではあるが、トレーサーを仕掛けて情況を把握した結果、件のラインが悪さをしているようで、これらを排除すると形式的にはLoopに入ることが出来た。

Screen Shot 2019-12-25 at 14.03.33.png

この状態でコンパイルは通るのだが、何かがおかしい。

Screen Shot 2019-12-25 at 15.10.24.png

設定を記述する作法がイマイチ解らない。 とりあえず、マニュアルを愚直な形で解釈した結果がこうなった。多分これで間違いはない筈だ。

Screen Shot 2019-12-25 at 16.00.32.png

WEBにアップされている製作例を参考にいろいろと試行錯誤を繰り返したが、FreescaleとNXPではTimerのアーキテクチャが大きく異なるために、過去の経験則は通用しそうにない。 ということで、基本に立ち返って概念図を眺めることにした。

Screen Shot 2019-12-26 at 2.29.46.png

FLEXPWMでは入力に対して複数のタイミングでキャプチャが行えるようだが、外部から信号を入力する端子毎に1ユニットを接続しなければならない。Timerの状態を個別のトリガー入力でキャプチャする仕組みは同じだが、FreescaleのFTMとは全体の構造が大きく異っているようだ。

Screen Shot 2019-12-26 at 2.32.13.png

この図はキャプチャのタイミングマップで、トリガーエッジでキャプチャが発動するタイミングが良く判る。

つまり、FLEXPWM4_SM0STSで複数のキャプチャエッジのセレクトを行っている現状は間違いで、新たにFLEXPWM4_SM1STSを追加する必要がある。

Screen Shot 2019-12-26 at 2.13.43.png

入力のノイズを取り除くフィルターの設定項目を発見したので、これを追加。同時にインターラプトの設定も行っている。

Screen Shot 2019-12-26 at 2.13.33.png

IOMUXの設定はややこしいので再確認を行ったところ、

Screen Shot 2019-12-25 at 20.59.49.png

Screen Shot 2019-12-25 at 21.01.00.png

pinの配列は提示された2種類のなかから選別しなければならないことが判明。 この部分にも誤解があったので、修正を行うことになった。

Screen Shot 2019-12-26 at 3.13.34.png

なお、SIONを設定すればモード設定の必要はなく強制配置が可能なのだが、これに限らず重複する機能設定項目がマニュアルをざっと眺めただけでも少なからず存在するようで、素人にとってはさながら迷宮に迷い込んでしまった感がある。

Screen Shot 2019-12-26 at 5.00.28.png

コアの部分が共通なCortexMシリーズだが、ハードウエアに依存する部分は知識の共有が行えず、チップを乗り換える毎に新たな学習を強いられてしまう。 自分のように系統だった教育を受けていない独学者には少々荷が重い状況だが、結局は3000頁あまりの物量を誇るマニュアルを読み込むのが一番の近道なのだろう。

追記:

FrequencyDetectorの構造は稼働実績が全く無く、ハードウエアによる実証試験を行うまで全ては想像の域を出ないのだが、フラグクリアをこの場所で行うとデータがアウトプットされないのでは?という疑問が生じた。

Screen Shot 2019-12-27 at 4.50.59.png

GPTを使った製作例では、attatchInterruptVectorを使ってサブルーチンに飛び、そこで獲得した値を抽出した時にインターラプトのリセットを行っていたので、FLEXPWMを使用する場合もリセットはデータを抽出した後に行うのが正解だろう。 

ということで、リセット関連の記述を削除したが、ここでORされているRFの扱いがいまいちよく解っていない。

インターラプトに関連する疑問もあって、実験ではNVICを設定してしまうとこのサブルーチンから抜けられなくなってしまうのだが、これもMCU単独では正確なところは判らず、AudioClockを印加した状態で動作を判断する必要がある。

追記2:

マニュアルを読みなおしたところ、、、

81527996_2848818428481930_2278560586675519488_o.jpg

カウンターのフルスケールはVAL1に設定するようだ。

Screen Shot 2019-12-27 at 13.39.37.png

参考にした原典ではVAL2を読んでいるので、

WS002069.JPG

こちらも参照先をVAL0からVAL2に変更しておいた。

Screen Shot 2019-12-27 at 13.39.59.png
posted by Yasuski at 02:56| LaVoixski

2019年12月25日

Teensy4.0にMicroSDカードを接続する

当初は極性を間違えて焦ったが、なんとかMicroSDカードの接続を行うことができた。

IMG_9730.JPG

実験では、MicroSDカードからデータを読み出すルーチンの途中で読み出し不能となる問題が発生したが、原因はセットアップ・ルーチンの中に仕込んでいた周波数ディテクターのサブルーチンにあると判明、、、

Screen Shot 2019-12-25 at 11.16.48.png

コードの配置を変更したところ、とりあえずデータの読み出しを完璧に行うことが出来るようになった。

Screen Shot 2019-12-25 at 11.17.00.png

以下にSDcardからデータを受取ったレジスタの状態を示す。

Screen Shot 2019-12-25 at 10.56.55.png

Teensy3.6と比較して物凄い速さでデータが転送されていく。

Screen Shot 2019-12-25 at 10.57.13.png

4kを越える容量のデータアレイ群は、DMAMEMを使ってgroup2のメモリーバンクにデータをストアしている。

Screen Shot 2019-12-25 at 10.57.35.png

データの読み出しと共に、処理ステップを確認するためのRGBLEDによる表示を行っている。

Screen Shot 2019-12-25 at 10.57.46.png

データの読み出し終了後は、単体LEDによってセットアップルーチンのステップを確認している。

Screen Shot 2019-12-25 at 10.57.58.png

単体のLED はコンパイルのテストを行う過程で適当に追加したマーカーなので、今後配置などを改善する必要あり。

Screen Shot 2019-12-25 at 10.58.16.png

問題となった周波数ディテクタはハードウエア依存なパートで稼働実績が全く無い。これから実効性のある仕掛けを構築していくことになるが、前途多難な雰囲気がする。
posted by Yasuski at 11:03| LaVoixski

2019年12月24日

Teensy4,0にプログラムを移行する(継続中)

動作の保証は全くないが、なんとかコンパイルだけは通すことが出来た。

Screen Shot 2019-12-24 at 6.22.13.png

今回は、DMAMEMを使ってメモリー消費が大きなデータアレイ群をMemoryBank2にアサインすることで、MemoryBank1のオーバーフローを防ぐ手法を試した。

Screen Shot 2019-12-24 at 6.22.23.png

なお、SmallestCode以外のオプティマイズは受け付けられないようで、通常のFastestで行うとUSBの接続が死亡する形で動作不能に陥ってしまう。
posted by Yasuski at 06:33| LaVoixski

2019年12月20日

Linear Interpolation の実装を行う

AudioClock と比較して時間軸の精度が粗いFTMからのデータを線形補完するシステムの実装を完了した。

Screen Shot 2019-12-20 at 12.21.41.png

当初レジスタのデータ型にintegerを設定していたが、実験の結果、割り算の解が1以下になると補完が全く行われないことが判明、最終的にはデータ型をfloat_32に拡張し、

Screen Shot 2019-12-20 at 11.52.00.png

Screen Shot 2019-12-20 at 11.51.29.png

結果をuint16_tにキャストする方法に落ち着いた。

Screen Shot 2019-12-20 at 11.53.35.png

聴感上の印象ではあるが、従来の状態から大幅にグリッチ・ノイズを減衰できたようだ。



同様の処置を行ったPitch側のセンシングは低域・高域共に荒れた感じが無くなって、こちらの方は期待していたよりも御利益が大きかった。

posted by Yasuski at 17:25| LaVoixski

Volumeにinterpolationを導入する

InterpolationをVolume/Pitchに導入するための備忘録。

AudioClockとFTMのインターラプトはデータを更新する周期が大きく異なるが、周期の長いFTMがデータを更新するタイミングで音量に段差が発生し、これがノイズとして認識されている。

段差を解消する方法としては、最も簡単なリニア補完を考えている。 メソッドは、固定されたAudioClockのタイミングでFTMが更新する時間をカウントし、バッファーにストアした新旧データの差分をカウントしたステップ数で割ってAudioClockが1クロックあたりに補完する値を算出する。

具体的な手続きは、、、

まずAudioClockと連動したPitch/Volume用のTimerを設定。

Screen Shot 2019-12-20 at 11.52.51.png

Timer はFTM のインターラプト毎にレジスタにストア&リセットを掛ける。

同じタイミングでPitch /Volume の新旧データを更新した後、サブルーチンにジャンプ。

Screen Shot 2019-12-20 at 11.58.39.png

サブルーチンでは新旧データの差分をレジスタにストアしたTimer の値で除算して、AudioClock 1step 分の補完値を算出する。

Screen Shot 2019-12-20 at 11.59.07.png

Volume側は、Transitionの分だけ計算が複雑になっている。


posted by Yasuski at 08:53| LaVoixski

2019年11月21日

Teensy4.0にmicroSDスロットを取付る

在庫しているジャンクパーツの中から発掘した1mm規格のフラットケーブル用コネクターをTeensy4.0に取り付けた。

IMG_9662.JPG

コネクターの左右の突起が邪魔だったのでこれを削ったが、まだピンとのクリアランスが確保できず、仕方なくピンを抱合しているプラスティック製のフレームを外して干渉を取り除いた。

IMG_9665.JPG

midroSDの結線がよく判っていないので、これを解明するまで作業はペンディングに。

15583-Teensy_4.0-03.jpg

ボードの裏面に印刷された端子のネームとカードの規格を確認すると、、、

Screen Shot 2019-11-20 at 20.28.56.png

ピッチ変換基盤に実装したmicroSDカードホルダーとケーブルコネクタの2階建てが正解だった。

MMC-SD-miniSD-microSD-Color-Numbers-Names.gif
posted by Yasuski at 06:35| LaVoixski