2019年05月21日

ID-292の試作機2機を破壊してしまう

在りし日の映像記録。



ID-292の試作機2機をぶっ壊した挙句、MCUを一個昇天させてしまった、、、。

ID-292系の弱点は電源で、何かのキッカケで電源が昇天し、入力と出力が直結した結果、周りのチップに抱きつき心中するという最悪な状況が発生する。 今日はこれを2回もなぞることになった。

原因はアンプから印加される15Vがアウトっぽいのだが、シングル・ボードの場合消費電力に見合った放熱が難しいのかもしれない。

1機は完全にスクラップ、FPGAを引剥して交換した残る1機も何故かアルペジエーターと連携してピッチが揺らぐ案件が再発している。 最初の試作機では全てが上手くコントロールできていたのだが、何故このような症状が発生したのか?原因は謎だが、LEDの消費電流が絡んでいる可能性がある。

例の如く、ジャンクパーツをサルベージして次の試作に備えたいところだが、MCUがぶっ飛んだ場合はリカヴァーのしようがない。 

電圧降下の問題に対処するため、次回製作する基板ではオシレーターとロジック系の電源ラインをレギュレーターICを含めて完全に独立させるべきか。

前述したように、電源が故障する原因は電源投入時に発生するサージ電流と過電圧が原因っぽい。

WS001827.JPG

通算5回以上もMCUを道連れにシステムを破壊していて、その都度対策を講じていたのだが、どれもが微妙にピントを外していたということになる。

ドロップ電圧の問題は認識していたが、15Vが絶対最大定格なので、コラ用に制作された4chアンプへの直結には少々無理があるのは承知していた。 特に放熱が辛いシングルボードには前段に電圧をステップダウンする機能を追加する必要があった。

マニュアルによると、出力に大きなCを配置した状態のレギュレーター回路には保護ダイオードを挿入したほうが良いとのことだが、これはジャンパー配線ですぐに実践できる。

WS001828.JPG

実のところ、製品版で回路を別基盤に分けた理由は、シングルボードで集中していた電源のレギュレーションを分散したいという思惑があった。

IMG_8954.JPG

華奢なシングルボード系はやはり限定生産になるが、ペアで販売する電源に工夫をすれば無用な過電圧を印加する危険性はなくなり、問題は押さえ込めるだろう。

IMG_9030.JPG

ちなみに、TNCコネクターの導入は失敗。 どうやってもクリアランスが取れない。 コネクタに加工を施しつつ、多少でも余裕の取れそうな筐体を選び直してトップパネルをフローティングしてやり過ごしているが、これは放熱が楽になるという利点もあるので、今件に関してはなんとも評価が難しい。 VRTのタッパを抑えるとある程度はクリアランスに貢献できることは判った。

ピッチ側には問題が生じていないので、こちらの採用はアリ。問題はVolume側なのだが、MCUに下駄を履かせてオフセットを取る方法は可能。この場合、端子にはラッピングポストを使用することになる。

ADATチップを使用しない場合、レベル変換ICが不要なことに今更ながら気づいた。 導入した元々の理由は、5V仕様のシールドとTeensyの通信が目的だった。 このチップは結構怖い潰れ方をするので、出来れば導入しないのが吉。

WS001838.JPG

別の失敗基板からサルベージしたFPGAの健在を確認した。

WS001822.JPG

これから、オーディオクロックユニットの健全性を確認する。

いまのところ、アプリやツールをバラバラに使って動作確認を行っている状態だが、そろそろオシレーター/オーディオ/デジタル信号の測定を統合したプラットフォームを製作すべきだろう。

例えば、オシレーターの調整に必要なツールとして、オシレーター間の差分信号を測定する専用のアンテナクリップを準備する一方で、別端子にはD-FFから生成される差分信号のデューティーサイクルを計測できるように専用の端子を製作する。

現状では測定器として使用しているAnalogDiscovery2は剥き身の状態なので、これを使い易いケースに収納した方が作業効率が上がる筈だ。

オーディオボードの試験には、専用のプログラムを書き込んだTeensy装着のボードを準備する。 これにには単純に基準信号をアウトプットするソフトウエアを4ch用意すれば良い。

あとは、LEDの輝度テストを行う装置が欲しい。LEDは個体差が凄まじく、抵抗値の調整が必要になる。

消費電力を抑えるために、LEDの電流制限抵抗の値を精査すべきだが、これは視認性の問題でもあるので、一度細かな検証を行いたい。

基板を再設計する過程で、放熱の問題に気付いた。 表面実装型レギュレーターの放熱は、部品の実装が過密状態でベタな放熱面を展開しにくい2層基板ではどうしても限界が発生してしまう。 ただし、4層化にはそれなりのコストアップが伴うので、これは微妙なところ。 現実的には電源電圧の設定でなんとか対応するのが筋だろう。

安全対策として、アンプと併用するタイプの試作機には9V程度まで電圧を下げるシリーズレギュレーターを外部に設置することにした。 シングルボードの意味合いが薄れてしまうが、スペース的には可能なので、これが即実行が可能な対策としては正解だろうか。

製品版の場合は専用電源の使用で電圧が管理できるために、過度な保護回路を設置する必要はなくなる。 アンプの電源電圧を統一していない現在の開発環境では、よりトラブルが発生しやすくなる。

ジャンク化したボードから取り外したRGBロータリーエンコーダーのウチ、幾つか赤色LEDが焼損寸前になったケースを確認した。 赤色に390Ωは3.3V環境であっても電流値が過剰なので、電源が破壊された時に印加された7V弱の電圧により引導を渡されたものと推測する。 1k程度の抵抗値を設定すべきところを3倍電流を流しているのだから、赤味が勝つのは当たり前だった。

電源回路の再設計を行う過程で、放熱を強化するために大口径のスルーホールを放熱端子裏に追加した。 

WS001829.JPG

WS001830.JPG

WS001831.JPG

WS001832.JPG

WS001833.JPG

WS001834.JPG

WS001835.JPG

WS001836.JPG

WS001837.JPG

制約のある環境で、ひたすらに表面積を上げる事に腐心しているが、多少の効果はあるものと思いたい。
posted by Yasuski at 12:54| LaVoixski

2019年05月14日

ID-292にLaVoixskiを内装する

動かなかった小型筐体用基板のパーツを差し替えて試験を行うことにした。

IMG_9020.JPG

まずは、1ch分のパーツを交換して様子を見る。 怪しいのはオシレーターの回路上でカップリングを行っていたコンデンサーで、これの値を間違えていた可能性がある。

WS001695.JPG

実際、不調の原因はコンデンサーの実装ミスで、470pFのところに間違えて47pFの部品を取り付けていた。
部品を交換した後、小型筐体用シングルボード仕様の4オシレーター分の発振と

Screen Shot 2019-04-20 at 4.42.27.png

D-FFによる復調を確認できた。

Screen Shot 2019-04-20 at 23.53.44.png

次に、ケースにボードを実装してチューニングを行う。 今回は、ID-292に基板を取り付けて周波数を測定した。

IMG_9025.JPG

Pitch側とVolume側でズレの大きさが異なるが、取り敢えずドリフトの大きなVolume側のリファレンス・オシレーターに220pF、ドリフトの小さなPitch側に30pFを追加して様子を見る。 

WS001815.JPG

最終的にリファレンスオシレーターの修正に追加したCの最適値はPitch側が100pF、Volume側が180pFだった。

Screen Shot 2019-05-10 at 12.30.21.png

接点の劣化したVolume側のコネクターの調子が悪く、これは交換する必要がある。

ロジック回路は何故か調整できないVolume表示LEDの挙動を除いて概ね良好だったが、特定色の発色がおかしい。 原因は追加したRの実装場所の間違いで、「赤」に電流を流す電流を調整するRを適正な値に差し替えなければならない。 音声のチェックは、6pコネクタへの配線が外れた為に、この時点ではお預けとなった。 

新しいヴァージョンの基板に対応するようにファームを書換えたが、何処かにバグが潜んでいるかもしれない。

LowerLEDの発色問題に関しては、OrangeとLavenderのポートアサイン(物理)の間違いと判明した。 UpperLEDは赤が強すぎるので、抵抗値を多少大きめな値に変更すべきか。 

Volume側の設定がどうやっても上手く行かない問題は、MCUを交換した後も解決せず。 トップのActivationSWのLEDが点灯しないのは、部品側に問題がありそうだ。

その後に行った作業の過程で、2年以上前に組み上げたID-292のガワは度重なる試作の失敗の過程で配線の疲労が酷く、断線が頻発しだした。 

IMG_6890.JPG

アンテナの結線が怪しく、部品を交換するかコネクタの接続方法を変更してやり直すことを考える。 コネクターのヤレが酷く試運転どころの話ではなくなってきたので、これを機に補器周りの配線を一新することにした。

LEDの発色問題は完全には解決しておらず、抵抗値の検討という現物合わせをしているが、同様の問題が他の基板でも生じていることから、回路設計に根本的な瑕疵が存在する可能性が高くなってきた。 ケースへの実装例が増えて、合理的に配線を取り回す方法がわかってきたが、それにしてもかなりの高集積が要求されるために実装が難しい。

WS001817.JPG

WS001818.JPG

LEDの色味は個体差が大きいので、事前に発色をチェックすべきかもしれない。 色味の問題(緑が異様に強い)は、ダイオードの実装ミスが原因と思われる。 ダイオードの順方向電圧を抵抗の代りに使用しているために、選択をミスると輝度が大きく変わってしまう。 基本、値の低いダイオードは青LEDの専用としている。

IMG_9043.JPG

hfeのバラ付きが懸念されたチップを新しく購入したものと交換した後に周波数を確認したが、Pitch側のリファレンスの周波数が高いほうにドリフトして調整不能になった。 修正には22pFを追加しなければならなかった。 が、実際はこれでもギリギリで、ベスト値は33pF辺り。

発振器の調整後にとりあえず片チャンネルから音を出せたが、左右ともにセンシングがメタメタなのが謎で、やたらとポルタメントが掛かる調整不能な状態に陥った。

そういえば、新型機の開発当初は同じような状況にハマった覚えがあるが、取り敢えずは最新のファームからFTM関連とEMAの設定値を移植するのが手っ取り早い対策だろう。

残り2つのDACはデータラインのアサインをミスってる公算が高いので、ロジアナで信号を確認する。 

WS001813.JPG

アナログ・スイッチ/ディストーション系は問題なく動作していた模様。 これが動けば相当インパクトがあるので、なんとかモノにしたい。

出力波形を確認したところ、MAX5717の片方からの信号が途中で消えていることが判明。天麩羅ハンダの可能性を考えて、怪し気な箇所にハンダを盛り直した結果、全チャンネルからの出力波形を視認できた。

が、ディテクターの動作がおかしい。 稼動状態にあったスケッチからの移植もアウトだった。 なにか根本的な原因があるのかもしれないが、とりあえずセンシングの周波数を落とす方向で対応をすすめる。

音源関連のソフトウエアは問題なく動いているので、ディテクターさえちゃんと動けば超小型テルミンが完成する。 実験に使っている電源ユニット(LiFe)からのノイズが問題を起こしている可能性があるので、電源をAC駆動の安定したものに変えて実験を行うべきか。 製作時のハードルはDACからアナログ系にあると思っていたのだが、予想外のポイントでトラブルが現出している。

IMG_9030.JPG

なにかポカをやっている可能性があるので、怪しいオーディオクロックを調べたところ、10kHz以下と論外に低い周波数が出力されている。 まずは使い回した部品が怪しいということで、FPGAの焼き直しを行ったが、結果は変わらず。

消去法で可能性を潰した結果、水晶発振子とPLLの辺りが非常に怪しい。 PLL601はよく使い回している石だが、それほどヤワではない。 怪しいのは水晶で、原発信は確認できたものの、PLLの入力レベルが異様に低い。 

IMG_8834.JPG

水晶発振子をアクティヴェートするには1番pinに10kを介して電圧を印加しなければならないのだが、どうもこの部分の配線がおかしくなってしまっていたようだ。 SMDの水晶発振子は取り付けが難しいパーツだが、実装時に失敗をやらかしていたということになる。

今更水晶を引っぺがすのも辛いので、ジャンクと化したSMD水晶の上に耐熱両面テープを使って新しい水晶発振子を追加することにした。

マトモなオーディオクロックを供給したところ、今までの苦労がウソのようにディテクターが稼働した。

ということで、最小サイズのテルミンが誕生したが、これは足掛け2年の成果でもある。

IMG_9032.JPG

限定10台位の規模で量産してもよいが、ケースとVRの手配で総数が決まる。

IMG_9039.JPG

IMG_9045.JPG

IMG_9043.JPG

IMG_9052.JPG

運用上の経験から、VRは右側上下に配置するのが正解。 あと、シャフトには「ノブ」を付けない方が扱い易い。 これは不用意な扱いをした場合に設定が狂い難いのと、制御が楽という二重の体験から得た回答だ。  ただし、Copal系のVRはシャフトが金属なので接触時に受ける影響が問題になってくる。

断線が怖いので、内部のアンテナ線は直付が推奨となるだろう。
posted by Yasuski at 04:25| LaVoixski

2019年04月21日

新型モデルにオシレーター基板を実装する

Hammond製ケースに基板の実装を始めた。

IMG_8952.JPG

予想通り、オーディオボードとMCUボードを繋ぐリボンケーブルの取り回しが難しい。

IMG_8953.JPG

サンプリングレートを切替えるデジタルスイッチを実装するために筐体側面の内側をザグっているが、手間が掛かり過ぎて量産には向かない方法なので、他のシンプルな実装方法を考えるべきだろう。

IMG_8954.JPG

IMG_8955.JPG

今回は、TNC規格のコネクタを使ったアンテナを新調するが、コネクタの個体差によって固定が上手く行えないことが発覚している。

IMG_8958.JPG

IMG_8957.JPG

対症療法としてコネクタのスリーヴをヤスリで削ってクリアランスを出しているが、また手間の掛かる案件が増えた。

IMG_8960.JPG

あと、圧入によりパーツが固定されたアングル中継コネクタの強度には問題があり、ハンダ付けもしくは溶接に拠る補強が必要だが、これも手間の掛かる案件。

IMG_8962.JPG

接合部がしっかりとしているので、SMAよりも安心感があるが、エクステンションとの接合が実質SMAなので、この部分に負荷がかかる可能性を忘れないようにしたい。

ピッチ側のアンテナ長は実際の運用を行いつつこれから調整していくことになる。アンテナの太さを変える等の方法を考えているところ。

基台を固定してしまったのは、シールドを展開する可能性を考えると少々早まった感がある。

左側のアンテナは例のごとく無理矢理フリーで手曲げを行っているが、そろそろジグを作って作業の効率化を図った方が良いだろう。

ボディー側の端子は何れもクリアランスを確保するためにスリーヴを削る必要がある。

IMG_8966.JPG

アングルの中継端子は、強度を確保するために圧入されているパーツをハンダによって固定しなければならない。

IMG_8965.JPG

カーヴは手曲げなので少々歪んでいる。

IMG_8967.JPG

半円部の直径はもう少し大きな方が良いかもしれない

オシレーター基板の電源電圧を設定するRの組み合わせがなかなか難しいのだが、1kと3.3k並列の組み合わせが一番近くなる。

アンテナの製作で手間が掛かるのはVolumeアンテナの曲げ加工で、エクステンションの製作は精度が求められる上に工程数が多い。 エクステンションの製作に必要な部材は、アルミ丸棒2個・12φの真鍮パイプ・GFRPの円柱1個とアングルあり・なしのTNC端子で、これらを組み合わせてPitchアンテナ用の基台を構築する。 

製作工程で難易度が高いのは、アルミ棒の扱いで、真鍮パイプに圧入した後、下孔を開けてユニファイねじのタップを切る必要がある。 この下穴の工作精度が出せない問題を解決する方法として、M5の中空スペーサーを流用する案を検討している。 スペーサーの内径5.3φは1/4-36のインチネジの下穴にはギリギリで合格。

SMAは強度が脆弱だが、アンテナ側にはギリギリでセーフかもしれない。

新規に導入したTNC規格のコネクタは、SMA程ではないにしても圧入パーツで構成されるアングル部品の強度は脆弱なので、半田による固定が必須。

ボディー側の取り付けはTNCに統一する。 例外はID-292版で、引き続きSMAを使っていくが、こちらも実験的にTNCを装備したものを試作する予定。

GFRP製のパーツにも同様に中心に穴を開けてタップを切る作業を行う。 現在、手曲げでRを造っているが、真鍮棒は硬すぎて指に負荷がかかってしまうので、専用のジグを製作したほうが良いだろう。

オシレーター基板を実装したところ。

IMG_8968.JPG

サンプリングレートを変更するデジタルスイッチの配線は未了だが、発振周波数のテストを行うことが出来る状態となった。

このモデルでは、10TurnのマルチターンVRを使用する。

IMG_8969.JPG

ポットの径が大きいので、実装時には基板とのクリアランスチェックを行わなければならない。

こちらは中型筐体版のテストベッド。 この段階では、VRTの配線が未了。

IMG_8971.JPG

中型筐体ではスペースを確保するために5TurnのマルチターンVRを使用しているが、価格と性能のバランスを考えた場合、10Turnのモデルを使用したほうが良さそうだ。

Screen Shot 2019-04-20 at 4.49.47.png

オシレーターのチェックを行っているが、大基板の方に問題が発生。4基のうち、3基が動作せず、発振している1基もレベルが低く、インバータによる波形整形も行われてない。 

回路をチェックしても不審なポイントは見つからず、何をどう間違えたのか原因は不明。 何処かでテンプラハンダをやらかしている?

一方、小基板の方は全てのオシレーターの発振を確認出来ているのが不幸中の幸い。最悪の場合はコレを仮実装することになる。

唯一発振していたオシレーターの出力値が非常に低かったので、Transistorの不具合を疑ってチップを取り替えたところ、全てのオシレーターの発振を確認できた。

教科書に載るような綺麗なシェイプの発振。

Screen Shot 2019-04-20 at 4.42.27.png

上がVolumeAntで下がPitchAntのオシレーター。

スペアナで波形を観測した。

Screen Shot 2019-04-20 at 17.27.23.png

目論見通り、大凡370kHz/380kHzで発振している。

VRによって発生させられるドリフト値は8kHz程度。 オシレーター間の差分を調べたところ、低い方が約30kHz、高い方が約20kHz、アンテナ接続によって下方にドリフトしていることが判った。

これからアンテナの接続によって生じるドリフトを相殺するために、追加のCを取り付けていく。

Cの組み合わせは、高い方の周波数に150pF、低い方に220pFを追加することで、周波数のレンジを合わせ込めた。 過去の経験から、アンテナを接続することによって増加する容量は100pF程度と予想していたが、今回はそれよりも大きなドリフトが発生している。

大サイズ基板のチューンを行う。 Volume側はほぼ問題なく組み上がったが、Pitch側オシレーターの回路に重篤な配線間違いを発見、修正を行った。

回路設計時に配線のネーミングが重複してしまったことが原因のようだが、この基板には何かと失敗が多い。

修正後、動作を確認しているが、Demodulate時に変なヒゲが出る現象に悩まされる。 

Screen Shot 2019-04-20 at 23.53.44.png

付け焼き刃で行った改修が原因かもしれないので、本格的に部品の再配置を行ったほうが良いかもしれない。

オシレーターの配線を引き回さずに部品の配置を直結する形に変更した結果、問題はほぼ解決できた。

中型筐体のオシレーターを調整する前にMCU基板に部品を実装しているが、基盤の仮組みをするとリボンケーブルの装着はちと辛い感触なので、量産機は丸ピンを使ってスペースを稼ぐことにした。

75mm規格の中型筐体用オシレーター基板のチューニングを完了。

IMG_8988.JPG

この基板でもPitch側に不具合が発生したが、原因はInverterのハンダブリッジという有りがちなものだった。

IMG_8992.JPG

80mm規格のオシレーター基板ではディテクター出力にヒゲが発生していたが、75mmでは安定した動作を確認できた。

IMG_8981.JPG
posted by Yasuski at 15:31| LaVoixski

2019年03月25日

LFOの導入とインターフェイスの改良・その他

"Won'tGetFoolAgain"のイントロのような効果が欲しくなったので、音声出力のエンヴェロープにLFOを仕込んでみた。

  

Arpeggiator制御クロックのエッジをEMAでなまらせることで、Envelopeのシェイプを変化させている。

追加した新しい機能・PitchBendとEnvelopeChopperは何れも制御パラメーターへのアクセスがもどかしく、とりあえず機能を発現させるだけでも数ステップの作業が要求される始末で、これを改善する方法はないものかと考えていたのだが、MuteSwitchに元々追加分のアドレスをリザーブしていることを思い出した。 

Screen Shot 2019-03-23 at 3.52.21.png

現在、暫定でノーマル→ピッチベンド→ミュート→トレモロの演奏モードを円環させているが、おそらくはこの仕様で固定することになるだろう。 利便性を考慮した結果、ノーマルモードの前後にエフェクトを配置して全演奏モード上でベンドが行えるように変数を追加した他、各機能の発現を下段のLEDに表示させて状況の視認性を向上させている。

以上の改良によって、元々は2VoiceModeの#15に限定していたPitchBend機能を全チャンネルに拡大することになったが、この段階で処理機能の破綻は見られていない。

今回増設したPitchBendでは初めて積極的に負の値の設定を扱っているのだが、microSDにスナップショットの記録を試みた結果、単純にdtostrfでキャストを行っても負の値を記憶できないことが判明(世間的には自明なことなのかもしれないが)した。 

解決法をいろいろと思い悩んだが、フラグ代わりにMSBオンに相当する値をデータに足すことを思い付いた。 

WS001795.JPG

これはローカルで行った実験のスケッチ。 かなり怪し気なメソッドだが、12bit以下のデータ幅であれば問題なく動作している。

データの流れを解説すると、ロータリーエンコーダからの出力attackB1をmicroSDで受けられる形outstrに変換した後、レジスタread_var2に読み込ませ、そのデータを再変換してパラメーター制御用のシーンメモリーに戻す一連の動きをシミュレートしている。

WS001789.JPG

テストベンチでゼロ・ポイントを越境する際に問題なくデータをハンドリング出来たので、次は楽器に実装して動作を確かめることになった。

WS001793.JPG

実際にコードを埋め込むとこんな感じになる。 

WS001794.JPG

データをmicroSDに書き込む部分と、読みだす部分にそれぞれMSBの極性フラグに対する処理を行うコードを挿入している。 挙動に少々心配なところがあるが、極性判定の仕掛けは正常に動作している模様。

以上のように、インターフェイスに関しては折衷案を上手く見つけたと思っているが、連続した色味による機能の判別がややこしい。 対応策を試行錯誤した結果、 PitchBend/Toremolo各演奏モードの選択に伴ってUpperKnobのコード選択機能がパラメーターのValue設定に切り替わる方式を思い付いた。

負の値を扱うPitchBendモードでは、符号の変化を点灯するLEDの発色を切替えることで表現している。

WS001797.JPG

モード選択時にコードの選択が行えなくなるのが欠点だが、頁の移動量を考えると、こちらの方が現実的な運用を行えると思う。

実際にこれらのエフェクトを使用する頻度はそう多くないと思われるが、即興性の向上を狙う場合はこの手法が最適解だろう。

改装のついでに、LFOのDepthをVoicingMode毎に設定できるようにメモリーを増設した。

シーンメモリーの利便性を向上させるため、従来はArpeggiatorを選択した時のみ行えた記録を、全アドレスにおいて可能とした。 唯一、Pitchのプリセットを行った後に記録するアドレスを呼び出す必要がある ChordEditモード を選択した場合のみ、従来通り「アルペジエーターを選択した時だけ」シーンメモリーが行える仕様を継続した。

Mode毎にLFOのスピードを仕込めると更に便利だが、Arpeggiatorのスピードとの齟齬が発生する可能性がある。

結局、さらなる利便性の向上を目指してUpperKnobにチューニング系のパラメータを再配置することになったが、機能の被りを防ぐために大量のスキップルーティンを配置しなければならず、作業量は予想していたよりもかなり大きなものになってしまった。

WS001792.JPG

スキップの仕組みは、条件分岐が該当するモードと一致した場合にブレイクを掛けるだけの単純なものなのだが、switchを構成しているcase毎にこれを挿入しなければならない。

WS001791.JPG

より洗練された方法として関数化した発光ルーティンを呼び出す方式が考えられたが、コードの簡素化は遅延とトレードオフとなる可能性があり、今回は採用を見送ることになった。

WS001790.JPG

あんちょこの執筆時にインターフェイスの煩雑過ぎる構造が露見した為にやむなく作業を行っているのだが、つらい作文作業のおかげで客観的な視座を得ることが出来たのがラッキーだった。

要は、10を超える(概念的な)垂直移動が強要される環境ではパラメーターの認知に相当な負荷が掛かりそうなことが判ってしまったのだが、この問題を解決するには現状で20対9という不均衡なパラメーターの分布を、出来るだけ均等に分配する必要があった。

試行錯誤の結果、パラメーターのレイヤー化を進めて、下側のポットノブのアドレス#1・OP3の選択時に、倍音編集機能を、アドレス#10・MixSelectorにOscillatorの編集機能を割振ることになった。 

WS001796.JPG

要素をダイレクトに編集できるパラメーターの構造を採用できたのは大きな進歩ではあるが、



反面、ヴォイシングの選択レイヤーが減少する弊害が発生している。 

ネガティヴ面の評価については今後行っていく実験運用の過程で結論を出していくことになるが、レイヤーの移動を自動化出来た運用上のメリットはかなり大きい。
posted by Yasuski at 20:12| LaVoixski

2019年03月17日

PitchBendの運用ケースとパラメータの再配置について

運用には慣れが必要だが、左手の動作だけでトリガーを掛けるのは少々辛いことが判明。 より効果的にPitchBend機能を使用するには、外部からトリガーを入力出来る端子を追加すべきかもしれない。 

外部トリガーは、現在設定しているスレッショルドが設定可能な内部トリガーとExORを行って実装する。 入力端子のステイタスを変化させる方式は物理的なスイッチを接続するのがシンプルだが、よりフレキシブルに運用が可能なBluetooth等を使ったリモートデバイスの使用を検討している。



PitchBendの導入に伴い、パラメーターの配置を変更した。 インターフェイスの仕様がコロコロと変わるのは考えものだが、これが最新の操作法だ。



一方、プログラム上では循環するパラメーターの配置をこのように規定している。

<->op3(multiColors)<->PitchBend(pur/yel)<->distortion(sky/red)<->mute(yel)<->transition(pur)<->transitionEnvelopeSelecort(sky/pur)<->osc1_vol(grn)<->osc1_wfm(sky)<->osc2_vol(blu)<->osc2_wfm(sky)<->osc3_vol(red)<->osc3_wfm(sky)<->osc1_vo4(pur)<->osc4_wfm(sky)<->osc5_vol(yel)<->osc5_wfm(sky)<->arp_ptn(red)<->arp_spd(grn)<-> arp_seq(blu)<->

実際に設定しているニュートラルな位置のパラメーターは4番目の MuteSwitch(Yellow) で、今回の改装ではそこから前後する使い易い位置に使用頻度の高いパラメーターを再配置した。
posted by Yasuski at 14:35| LaVoixski

2019年03月15日

Gride機能にハーモナイズド・チョーキング風の機能を追加する / PitchBenderの製作

Gride機能にチョークアップする側のEnvelopeを追加した。



具体的な効果としてはハーモナイズド・チョーキングを模したものを目指している。

Screen Shot 2019-03-15 at 17.21.12.png

GrideのRate設定をゼロポイントを超えたマイナス側に回すと、int16_tのMSBからNegativeFlagを感知して、グライド・アップする方向に機能をスイッチする。 

Chronoは負の値を扱えないため、事前にMSBをマスクした数値をパラメーターとして使用するが、このままでは境界を超えた途端に最大値が入力されてしまう。 これを防止するために、マイナスのフラッグが立った場合には  を使って出力値を反転する機構への条件分岐を組み込んでいる。

実際に運用した場合にポットのゼロポイントの境目が判り難かったので、LEDの発色を変えて境界を示すようにインターフェイスを改良している。

追記:

EMAの処理時間を短縮する方法を見つけたので試してみたが、データが荒れて使い物にならなかった。
posted by Yasuski at 18:23| LaVoixski

EnvelopeGeneratorのようなものを実装した

Chronoを使ったトリガーを切欠にAttack=立ち上がりのエンヴェロープをオシレーターのピッチ制御に印加する機能、Envelope Generatorのようなものを実装した。

Lyle Maysな雰囲気を実現するまでの道程は遠いが、まずは第一歩から。

Oberheim名物なLyleMaysの"あの音"を思い出してから脳内再生が鳴り止まず夢にまで出てくる始末で、この日の午後はその実現に向けてひたすらに試行錯誤を繰り返していた。

基本的な構想は、データの極端な変化をサプレッションするEMAアルゴリズムの係数をChronoを使って段階的に変化させる方式で、Chronoによって発生させるトリガーの間隔が長くなると、EMA係数の変化量が抑制され、結果としてGrideTimeが伸びるという仕掛けだ。

最初のこれはおもいっきりコーディングを間違えているのだが、

WS001765.JPG

実装した結果「何となくそれっぽい動き」が観測されてしまい、これが迷路の入り口に入る切欠となる。

次に、実験を繰り返して到達したこの段階では、実用性は乏しいもののPitchをGrideさせる機能の実装がほぼ実現しつつあった。 ただし、変化量が大きすぎたり、Grideさせた結果が超低音になるなど、新たにピッチ制御のために用意した係数、add_vall2 に出力されるデータは正常なものとは程遠い状態だ。

Screen Shot 2019-03-13 at 15.47.24.png

そのうえ、Chronoの調整のためにノブを回していると、突然作動不能となるケースが頻発した。 

このケースには相当悩まされたが、SequencerにStart/Stop機能を実装したコードからそのままの仕組みを再利用して、「トリガーゲートがオフられた時にchrono.stopを使ってChronoの計数をストップさせていた」のが原因だった。 

chrono.stop を排除した結果、トリガーによってEGを発生させる機構の動作を安定させることが出来たが、この段階ではピッチが不思議な挙動を示す原因をまだ特定出来ていない。

その後の数時間に渡る試行錯誤の末に探し当てた、正常に動作するほぼ最終的な案以下に示す。 

機能をまとめてEGとしてサブルーチン化し、それをPitchディテクターのサブルーチン内からコールしている。

Screen Shot 2019-03-14 at 2.32.48.png

結局、発生させていた「Pitchの差分」そのものを add_val2 に代入するPitchデータ出力として取り扱っていたのが間違いで、元データ add_val に「差分を足す」のが正解だった。 これで、Pitchの扱いに関する問題はほぼ解決した。 制御波形の分解能は200だが、これは今後調整を行う必要があるかもしれない。

多分、これもまた「車輪の再発明」に過ぎないのだろう。 が、ひとまずはそれっぽい動作をする仕掛けが組み上がりつつある。

負荷が多いためか出音が微妙に荒れ出したのが危険な徴候だが、出来ればこの機能を外したくはないものだ。

ついでに、操作性を向上させるためにパラメーターの配置を一部変更している。
posted by Yasuski at 11:14| LaVoixski

2019年03月12日

LEDの表示モードを変更する(その2)

Sequencer使用時に「どの曲をセレクトしているのか判らなくなる問題」が発覚したので、メモリーCH毎に*Blink*するLEDの発色を変えることにした。

曲を選択する毎に色が変わって視認性が格段に向上したが、今度は点滅の間隔が気になりだした。

改装のついでに、TDMモード送信実験の前段階としてTDMに使用する通信端子の設定を行ってみた。 SCL0とSDA0をアサインする端子には、FPGAのラッチ信号を出力するためにリザーブしていた16・17番を使用する。

とりあえず、端子に通信機能を持たせるALT2にモードを切替える設定だけは行えているようだが、実際に使う段になると何をどうやればよいのかサッパリ理解していないので、ADMP1701の評価キットが到着次第TDMによる音声多重通信の実用化に向けて、これからフォーマットを学習していかなければならない。
posted by Yasuski at 21:30| LaVoixski

2019年03月11日

LEDの表示モードを変更する

空きチャンネルに搭載した新機能の判別が辛くなってきたので、LEDによる表示機能を追加した。

WS001762.JPG

Op3Modeは、選択したOscillator順に GRN/BLU/RED/PUR/YEL を、DistortionSWのオン・オフには SKY/RED TransitionControl/Sin/Exp.Sin の切替えには PUR/SKY をそれぞれ設定している。

改修の過程でDistortionSWの切り替えを検知するためにD13のStatusを読もうとしたところ、何故か読みだすことが出来ず。 対処法としてスイッチングを行う選択分岐の部分にスイッチングを行うための関数を代入している。 

PinのStatusが読めない案件は以前から偶に発生しているが、D13にはTeensyのボード上でLEDに接続されており、この回路によって発生する電圧降下がStatus"HIGH"の認定を阻んでいる可能性がある。 

何れにせよ、これは物理面の問題が疑わしく、MCUから外部に接続を行う際には必ずバッファーを挿入することを心掛けたい。
posted by Yasuski at 17:06| LaVoixski

2019年03月10日

Transition Control の制御波形に expSin を追加する。

何気に読んでいた大塚明氏のサイトからexpSinという概念を仕入れたので、

WS001755.JPG

これをあまりピーク値が重なって欲しくないオシレーターのtransitionコントロールに応用できないか、実験で試すことにした。



まずは下準備として、GNU/Octaveでヴォリュームを制御するための波形を生成する。 テンプレートには、以前記述したSin波を生成するコード使った。 Sinの手前にexpを書き足した後、カットアンドトライでオフセット値を探っていく。

WS001760.JPG

WS001756.JPG

WS001757.JPG

WS001758.JPG

WS001759.JPG

当初は12bit精度で縦軸を設定したファイルを単体で試してみたが、音像の分解能が上がって、和音が美しく聞こえるようになった反面、OverDrive系の出音にパンチが無くなってしまった。

これでは本末転倒なので、処理ステップ及びRAMの消費量が上がってしまうが、波形を使い分けられるようにスイッチ機構を組み込んで、旧来のファイルと設定が共用できるようにシステムの改変を行った。

Screen Shot 2019-03-10 at 16.23.42.png

問題は、現用していた11bitスケールの波形との整合性で、アッテネーターの値をどう工夫しても境界値のコントロールが行えなくなってしまった。 結局、expSine波のスケールを11bitに縮小して再度試してみたところ、スムーズな動作を確認できた。

WS001755.JPG

確かにこれは便利な機能で、和音演奏時のミックス具合を変更して、出力の飽和状態をコントロールすることが可能となった。

ちなみに、大人しい音色を使用した時には、効果の違いを殆ど感じられなかった。

Transition波形の切り替えスイッチには何故かアナログ部のスイッチ機能が「死んだ」状態で放置していたLevelControlを充て、出力端子のステイタスを波形の切り替えに反映させている。
posted by Yasuski at 17:40| LaVoixski

2019年03月09日

OutputCh#3に波形変換システムを導入する

元ネタは”Arduino Music and Audio Projects”の巻末近くに掲載されていたAudio Excitationという記事で、TransferFunctionを使って倍音構成を変化させる仕組みが紹介されていた。

この楽器は、5つのオシレーターによって波形合成を行う音源で構成されていて、現在第3出力にはオシレーター単体の出力をアサインしている。つまり、ここでピックアップされるのは単純なサイン波となる可能性が高く、その場合は少々パンチの乏しい音色となってしまうのが難点だ。 

今回の改装では、波形合成との兼ね合いで矩形波やノコギリ波等「エッジの効いた波形」をアサインすることが出来ない場合に音色を変化させる方法として、先の記事に記載されていたWavetableによる波形変換システムを導入している。

WS001748.JPG

WS001749.JPG

導入を試行した当初は参照するWavetableをリアルタイムで組み替えようとしていたのだが、結果は失敗だった。 Dueを使って(オリジナルの記事による)AudioClockのタイミングでそれを行うのはExciterを単機能のみで実装した状態であっても流石に無理な話。 実際の回路は任意のタイミングでプッシュスイッチを押して、ヴォリューム・ポットの状態をアップロードする仕組みだった。 

記事を読み飛ばしていた自分がそそっかしいのだが、ポットの状態が即出音に反映されないのはいささか残念な仕様ではある。 記事の内容に沿って、プッシュスイッチによりデータエントリーを行う構造に修正した結果、音声の出力を確認することができた。



ついでに、RGBロータリーエンコーダーにポットの状態を点滅速度で表示するギミックを追加しておいた。 

WS001753.JPG

点滅間隔が長くなるほど値が大きくなる表示方式で、最長0.5秒間隔でLEDが点滅する。

データトランスファーはオシレーターの音量調整ポットを流用する関係で、5倍音まで設定が可能な仕様とした。 記録は、トップ側のノブをch9に選択してエンコーダーのトップを長押しして行う。 

WS001751.JPG

現状はメモリー数を1chとしているが、今後必要に感じた場合はさらに記録バンクを増設する可能性もある。

WS001752.JPG
posted by Yasuski at 17:48| LaVoixski

2019年03月08日

SigmaDSPの導入について

ADAU系列のDSPは導入の敷居が高いが、スタンドアロンで動くこのチップを扱った記事はハードルを超えるためのヒントになる。

Webを漁ると製作例が上がっていて、ハードを販売している人も居るようだ

最終的にはこのコードが使えそうなので、DSPの試作ボードを購入してテストを行うことにした。

1401traningKit.jpg

ただ、このチップを含めた最近のオーディオ製品は通信をI2Cで行うために、DACとして使用する場合にボトルネックの問題が出てくるかもしれない。 所謂「バーストモード」がMCU側の設定で使えるかどうかが決め手になるだろう。

DSPを使用する利点は、それ自体にオシレーションを行わせられそうなところで、波形の生成を外部に丸投げして、I2C/S等のシリアル伝送によって生じるデータトランスファーのボトルネックをスキップできる可能性がある。

オーディオデータのハンドリングに話を戻すと、LRCLKでオーディオデータを受けていては出力が間に合わないので、3ch以上の出力を行う場合は否応無しにTDMモードを選択することになる。 TDMフォーマットに関しては良く判っていないので、参考のために具体的な製作例を探したほうが良いだろう。 

ADAU1701はデジタルオーディオ・フォーマットを直接出力できるので、MCUからDACに至る間に発生していた遅れ時間を気にせずに外部に設置したDACにデータを放り込める利点がある。 入出力で通信モードを切替えられそうなので、adatフォーマットに拠る通信を行えるかもしれない。
posted by Yasuski at 21:03| LaVoixski

2019年03月06日

chronoの導入

オマケ機能で実装している sequecer は、無音時にもステップを進める設定だが、これが意外と使い難いことが判明している。

要は曲を演奏中にブレイク出来ないということで、ならば改良のために条件分岐を使って無音時にカウントを休止する機能を実装しようとしたが、何故かmetro環境下ではどうやってもクロックをストップ出来ない。 

この問題に対処すべくchronoという新し目のライブラリを見つけてmetroと換装することにした。



chronoについての詳細はリンク先を参照してもらうとして、chronoは定常的にクロックを発生させるmetroとは異なり、インターバルが終了したあと常にrestartコマンドによってリトリガーを掛けなければ反復する信号を生成できない、所謂ワンショット系のデバイスを模したものとして考えればよいだろう。restartを行うまでは静的な状態を保持する一方、stopコマンドで一旦クロックの生成を停止できるところが今回の用途にぴったりだ。

Screen Shot 2019-03-06 at 7.58.52.png

クロックを駆動するトリガーは、目玉スイッチのLEDと連動させている。 実際に運用を行ってみると、テルミンは出音の立ち上がりが遅く、sequecerの発音が遅れてしまうように感じることがあった。 ただし、これは用法で解決すべき問題なので、今後は実際の演奏体験を通じて特性に合わせた運用を模索していくことになる。
posted by Yasuski at 09:55| LaVoixski

2019年03月04日

FVCの「丸め」を行う手順の修正など

今日は、テルミンの周波数ディテクター周りのコードをいじっていたのだが、間違った手順でデータを丸めていたことを発見、その部分の修正を行った。

Screen Shot 2019-03-04 at 15.20.20.png

要は、EMAで「データの丸め」を行った後に、暴れている元信号の差分を追加するというマヌケなことをやっていたのだが、改良の結果データのバラつきを格段に抑えることが出来た。 今後はEMAにプリセットする数値を調整していくことになる。

一方、動作が不安定で使用を諦めていた「ClickEncoderを排除した試作コード」に、無駄な処理ルーチンをスキップするbrakeポイントの追加やRAMの使用量を圧縮する改良点を思い付いたので、該当箇所の修正を行った後に再度運用をトライした。

Screen Shot 2019-03-04 at 13.54.13.png 

ロータリーエンコーダーの入力にノイズサプレッサ用のCを取り付けない機械的に不備な状態下でのテストではあったが、出音に関しては正常な動作を確認できた。 起動時にチューニングノブの規定値がClickEncoder使用時と大幅にズレることから、処理時間の圧縮に関してはほぼ成功していると思われる。

今後プラットフォームを変更する場合には、Arduinoのライブラリに頼らないこのコードを中心に開発をすすめることが可能となった。

追記:

後日、低域の安定度がどんどん低下する案件が発生、コードの不備を疑うも過去の経験から物理的な要因の気配があったので、繰り返しキャリブレーションとチューニングを繰り返した結果、キャリブレーションによって得られるイニシャル値には明らかな適正値が存在することを確認した。 ピッチ・アンテナ側とは逆ベクトルで操作を行うヴォリューム・アンテナ側ではこの値が明白で、データ取得時に設定しているリミッターのフルスケール16383がそれに相当する。

もう一方のピッチ・アンテナ側だが、こちらはデータを扱うベクトルがヴォリューム側とは逆になるため、単純に最適値を算出することが出来ない。 

イニシャル値の決定は、入力信号のアップエッジでフリーランするカウンタの値をキャプチャした結果から「差分値を引き出す」ディテクタ側のセンシングのメソッドと、カウンタをドライヴするクロックの分周率から影響を受ける。 MCUのシステムクロックや、クロック入力に設けられたフィルター等、関連するパラメーターが多過ぎて明確な回答を出すことが難しいが、カウンタのオーバーフローによって発生する字余り状態が誤動作の原因となることから、ピッチ側オシレーターのセンシングエリアの設定をオーバーフローが発生しない領域よりも上に持ち上げることが安定度をアップするための最適解といえるだろう。

ただし、この数値は楽器の発音域とのトレードオフで折衷することになるため、新たにアンテナ長等の楽器を構成する物理要因が絡んでくる。 よって機種依存しない普遍的な数値を出すことは難しいが、実測を繰り返した結果、イニシャル値20000前後が実用域なのではないか?と予想している。

現時点で実験に使用している楽器の発振器は設計に問題があり、より安定した性能の発振器を使った実験環境を構築しなければならないのだが、新たに設計した基板には配線ミスが発覚している。 修正版のオシレーター基板はすでに設計を終えているので、今月中にはこれを発注する予定。
posted by Yasuski at 18:06| LaVoixski

2019年03月03日

pgm_read_word_nearの削除を行う

前のシステムの名残だった pgm_read_word_near を

WS001741.JPG

コード上から削除して、シンプルな記述に書き換えた。

本来はROMエリアに格納したデータアレイを参照するためのコードだったものを、処理スピードをアップするためRAM上にデータを展開した後も使っていたのだが、記述を変えることによって何らかの変化が生じるかもしれない。

WS001742.JPG

処理上のステップが改変後に1.5%程増加した一方、RAMの使用量に変化はなかった。 

コードを改変する前のヴァージョンでコンパイルを行った時の画像を示す。

Screen Shot 2019-03-02 at 13.22.26.png

こちらのコードではVolumeControl関連のルーチンから pgm_read_word_near を既に排除している。

ステップの増加イコール処理スピードの低下とは単純に言えないので、実際に運用して確かめてみるしか無いが、その差1,5%という数字は尋常では無いために、どういった変化が生じるのか気になってくる。

追記:

実験の結果、正常に発音することが出来た。



改変前には44.1kHzにオーディオクロックを設定した時に特定のシチュエーション下でフリーズが発生していたが、今回の改変でこれが解消された模様。 つまり、処理能力のキャパシティーに余裕ができたということで、この件によって処理の合理化の達成を確認できた。
posted by Yasuski at 04:55| LaVoixski

2019年03月02日

Wavetableを使って出力信号にコンプっぽいものを掛ける実験

昨日作ったWavetableを使って出力信号にコンプっぽいものを掛ける実験を行った。

単音を出力する場合は「少々歪みっぽい」程度の変化だったが、総体的にはあまり良い印象を受けなかった。

入力レベルが増加する和音やOVERDrive系の音源となると、マイルドに設定していた過渡領域が全て無効になる始末で、システムの稼働実績は確認できたものの、その有効性には大きな疑問が生じることになった。

多分、チューニングを詰めれば再現性の高い効果が得られるのだろうが、出音に制御波形そのものの性格が反映される為に、実際にカット&トライを行う場合のハードルは高いものとなるだろう。

因みに、現行のシステムでは条件分岐によって入力の過渡的な変動値を圧縮しているが、この処理を24bitで行っているのがポイントで、それを16bitで行おうとした場合にどうしても粗が出てしまうようだ。 特にoverdrive系のような過渡特性が命な音源のコントロールは非常に難しいと結論することになった。

確かにデジタルドメインの非線形処理は対周波数特性等の解決すべき難問が待ち構えている案件で、大メーカーが開発に携わったものの撤退しているような難物故に、ウエーブテーブルによる波形の書き換え程度で容易に結果が得られる筈がないのではあるが。

自分の場合、最終的にはアナログ頼りなところがあって、勝手にいろいろな計算をしてくれるアナログ素子は便利なので、頼るべきところは頼ったほうが良いと判断するのが信条だったりする。

実験はひとまず失敗に終わった形だが、出力波形そのものをより動的に制御できる手段が実現できたのは心強い。 また、Wavetableに搭載する波形に関しては、メモリー管理の関係でそれらを削っていく過程で「無駄だと思っていた構成」がそこそこ必要とされるものと再確認することが出来た。予め複雑な「形を仕込んだ」波形を揃えるよりも、倍音関係にある単純な波形を準備して、それらに動的な制御を行ったほうがより効果的に音造りが出来そうだ。
posted by Yasuski at 21:10| LaVoixski

Wavetableを使用したコンプレッサーの実験

処理のタスクを少しでも減らせるように、このような非線形処理を行っているルーチンを省力化出来ないか検討を行った結果、GNU/Octaveを使って、出力波形圧縮用のWaveTableを作ることを思い付いた。 。

WS001268.JPG

問題はメモリーの残量だが、実際に24bitデータをリザーヴするのは非現実的で、そもそも処理が重すぎてOctaveからデータアレイを出力することができなかった。

いっそのこと理想としていた24bit/adatフォーマットを諦め、16bit長でデータをやりくりするという割切りもアリではある。  結局、16bit×16bitのデータは難なくアウトプット出来たが、、、

WS001735.JPG

これを適応させた場合、出力波形は相当なレベルで歪むことになる。

WS001734.JPG

解像度を上げると結構ガタガタになるが、まあこんなものであろう。

例えば、真空管アンプの実際の歪率は物凄いことになっているのだが、アレはアレでというかあっちのほうが音圧があって味を感じてしまうのが人情なので、出音が気に入るのであれば「波形のピュアさ」などという視点は無視したほうが良いのかもしれない。

で、予想はしていたがメモリーの総量が限界を超えてコンパイルが通らなくなったので、システム全体のダイエットを行うことにした。 まずは64bit長でエントリーしていた関数全てを32bit長に修正したところ、なんとメモリーの余裕が30%も増えた、、、。

WS001736.JPG

次に、エントリーしているWavetableのうち、cos波形を排除してRAMの使用量をさらに圧縮した。

全体に余裕ができたので、音量調整用の16bitFileをエントリーしてみたが、何故かRAMの使用量が二倍になって仕舞い、破綻が発生することが判った。

ローカルで関数を宣言しないのが正解かも?と考えて、Volume制御系のデータArrayに、出力直をアサインしてみたが、、、

WS001737.JPG

これもアウト。 サブルーチン上にWavetableを展開するとメモリーをリザーブしただけでは済まず、実質的にダブルエントリーとなってしまうようだ、、、。

結局、今回はコンプ機能の導入を諦めることになったが、どうしても出音が気になってくる。 

明日は徹底的にWavetableのダイエットを行った実験用のプラットフォームを作って結果を試してみよう。

ちなみにこの方式を応用すると、リングモジュレーターやFM音源が作れそうだ。

posted by Yasuski at 03:40| LaVoixski

2019年02月27日

ロータリーエンコーダーの実装に関して

ここ数日間、新規に導入を検討しているロータリーエンコーダーシステムの実験を行っていたのだが、どうやっても増/減同一方向にしかカウントできない案件が発生。 当初はロータリーエンコーダーの故障を疑ったが、端子を変えても同じ動作をする。 また、プログラム側で極性を変えた場合でも、同一方向にのみカウントが亢進してしまう。

これは明らかに物理の問題なのだが、試しにPinA/Bに接続したノイズサプレッサ用のコンデンサを交換してみても状況は一向に改善しない。 回路的には変移する入力ステイタスのタイミングを見て、増減の方向を判断しているのだが、多分「特定パターンの変移」が読めないためにおかしな動作が発生しているようだ。

元記事を読んで、これが328向けに書かれたコードだったことを確認したが、328と比較して無闇矢鱈と処理速度が速いK-66では「pinの変移が読めないかもしれない」ことに気付いた。 

で、試しに数クロック分の無駄なタスクを追加した結果、

WS001708.JPG

ロータリーエンコーダーの正常な動作を確認できた。

WS001705.JPG

NOPは、無駄な動作を行っていないか確認を行うためのダミー。 pinに変移が発生した時のみ、タスクの処理を行っている。

WS001707.JPG

プラマイ両極性の変移も良好。 ノイズサプレッサの威力は絶大で、見事に誤動作を排除している。

動作が確認できたので、これもダミーで本来のシステムに近い状態を作って実験を行ってみたが、ひとつのカウンタを使い回す状態ではポットの個別データを保持することが出来ない。

WS001709.JPG

結局、ポット分のカウンタをロータリーエンコーダーの変移感知ルーチン側に仕込んで、スイッチで切り替えることになったが、これをパラメーターが多い側に仕込むのは結構な作業量になってしまう。

WS001717.JPG

結果的にはこうなってしまったわけだが、まともに動かせる自信がなくなってきた。 実際、RAMの使用量は94%に突入しているので、ここ数日の努力が無駄に終わってしまう可能性が疑われ始める。

WS001713.JPG

ポットの状態を管理するルーチンは、元のコードと比べて工程数が激減するわけでもなく、実際にMCU側の処理ステップ数で時間を計測してみたら存外遅延が増えている可能性もあるが、Timerで設定されたタイミンで定時に連絡を取りに行かないところがアドヴァンテージとなる筈だ。

WS001712.JPG

とはいえ、導入には巨大なカウンタのクラスタを生成する必要があり、そろそろメモリの余裕が無くなってき¥た。 従来はローカル関数で処理していたのだろうが、これらのアドレスが固定されてしまった状況で、はたしてシステムが正常に動作するのか? 実験を行って確かめたいところだが、その前にノイズサプレッサ=コンデンサの仕込みを行う必要がある。

WS001715.JPG

一方、クリックを検出する機構はループの巡回毎に端子の状態を読みに行くが、こちらの処理は軽く、遅延の発生は最小限に抑えられる。

クリック・ダブルクリックを行う毎にpotの読み出しアドレスを増減するインターフェイスの構造は従来のものと同じ。 ただし、アクセス時にpotの値を読み込まないので、無駄なデータの処理にタスクを割かれることはない。

このように、バックグラウンドの処理を極力抑えられたのは良いことなのだが、パラメーターの移植は大変な作業になった。

添付してたライブラリ類がなくなって、ソフトウエアのパッケージとしてはかなり身軽になったように錯覚したものの、本体はデータ別腹で4万行超えている。 物理面でもメモリをバカ食いしてるのが大問題で、ウエーブテーブル等はClass10とオーヴァースペックなmicroSDから直読みすればいけそうな気もするんだが、現行システムでは何故か通信のデータレートが激遅過ぎるので、それは無理っぽい。

追記:

実験の結果、残念ながらattatchInterruputを使用したロータリーエンコーダーの導入は失敗に終わった。

理由は憶測ではあるが、オーディオクロックの立ち上がり毎にハードなタスクをこなさなければならない状況の中で、他の外部端子からのスイッチングに拠るインターラプトが競合した場合に、ロータリーエンコーダー側の入力が競り負けてしまう現象で、入力に対する反応が安定せず、正常な動作を保証することができなかった。 

比較実験の過程で、奇しくもClickEncoderのセンシング・レートを低く設定した時に入力の精度が落ちる似たような状況に陥ってしまった。 センシングの頻度を下げた場合は、フリーランするループ内でエンコーダーの状態を反映するタイミングを外してしまい、結果としてエンコーダーの動作がおぼつかなくなることが判った。

ピッチの揺れに関する問題は、新規に導入した読み出しシステムの環境下で若干の改善が見られたが、インターラプト起動時に発生するタスクの変化が音声に反映される弊害も発覚している。 これにより、ロータリーエンコーダーの使用に伴って発生する処理演算のタスクが音声に影響していることを証明する形になったが、楽器としての実用性を考えた場合、出力音声が外乱からの影響を受ける現象を看過することが出来ない。

よって、計画は棚上げ・中止とすることが決定した。 
posted by Yasuski at 21:36| LaVoixski

2019年02月26日

ロータリーエンコーダーが消費するプロセッシングパワーについて

現在採用しているclickEncoderはTimer1に設定した1000usのタイミングに従って定期的にロータリーエンコーダーが接続された端子のセンシングを行っているが、毎時データを参照する分だけどうしてもタスクが増えてしまう。

WS001704.JPG

オーディオクロックを基準にすると1000usは1kHzとなるが、1ms毎に発生するタスクは結構大きなものがある。

フリーランさせているLoopルーチン内で発生する無駄なタスクの増加を解消するために、ロータリーエンコーダーからの入力をattatchInterruptで検知させて、その都度出力を行う方式への転換を検討している。

WS001702.JPG

clickEncoderを排除する手前、ダブルクリックの扱いにも変更を行うことになる。
posted by Yasuski at 03:35| LaVoixski

2019年02月25日

TFT液晶パネルの採用を考える

OLEDに対する拘りを捨てると、選択肢は一気に広がる。

s-l640.jpg

基板の端子配列パターンはおおまかに2種類存在しているようだが、一応両方のモデルを購入している。

3.5-inch-TFT-Touch-Screen-LCD-Module-3.jpg

が、青い方はどうもArduino互換ではなかった模様で(トップページから連想される製品仕様からするとこれはウソ)対処法としてはNucleoボードに搭載するか、もしくはリボンケーブルで配線を変更するしか無い。

基盤の設計は完了していて、赤い方の基板にはこれを使用することが出来る。

dueScope8.png

新しい設計の基板では、ロータリーエンコーダーの配線を変更してパラレル通信用の端子を確保している。

dueScope8sch.png
posted by Yasuski at 17:47| LaVoixski