2019年02月19日

dueScopeの製作

IMG_8928.JPG

とりあえず、ClickEncoderの機能は実装できた模様。



Rateもキッチリと切り替わっている。 

今回のテストではRGBロータリーエンコーダーを使用していないので、LEDの点灯テストは未了。

IMG_8921.JPG

一時期対応できなかったスタートアップの画像もちゃんと読み込めるようになった。

IMG_8920.JPG

Teensyでは何故か欠けてしまっていたドットを復活させた。

IMG_8919.JPG

過大レベルを入力すると若干ドットの取りこぼしが発生してしまうが、Teensyと比較すると格段に良好。

IMG_8918.JPG

Dueの動作は速攻で描画が始まるTeensyとは違っていて、バッファーに一旦貯め込んだデータを逐次出しているように見える。 殆ど同じ内容のプログラムでどうして差が出てしまうのか?現時点でその原因は解らないのだが、TeensyのForumで見つけたトピックによると「Teensyが扱う32bit幅のデータがミスマッチしている」可能性が示唆されていた。 Teensy専用にライブラリを書き換える必要がありそうだ。

その後、運用法を考えた結果、Dueにピギーバックさせるのが良さそうということで、oledディスプレイを填め込んで実装できる基板を設計した。

dueScope2.png

入力には簡単なバッファーアンプを追加している。 回路は構造が単純単純なので、ユニバーサル基板に手組で製作を行う場合でも再現性は高いと思う。

dueScopeSch.png

Dueのタイマー系の構成について、詳細を記した資料を見つけた。

https://github.com/ivanseidel/DueTimer/blob/master/TimerCounter.md
posted by Yasuski at 15:45| AudioElectronics

OLED OscilloScope

Teensy3.6 に対応する OLED OscilloScope のコードを書いた。

WS001679.JPG>

インターフェイスにはLaVoixskiのロータリーエンコーダー周りのコードを転用した機能切り替え機構をなんとか組み込むことが出来たが、肝心のオシロスコープの性能は相変わらずイマイチで凹む。 あと、MCUのアナログ入力はポートを選ばないと性能にバラつきがありそう。

WS001680.JPG

波形表示のオフセット値の設定が滅茶苦茶になるのは何故なのか??? 24MHzまでMCUのクロックをダウンしないと動かないのも謎だ。 DUEで動かしていた時は、クロックのことなど気にしたことはなかったのに、これまた不思議な症状である。

Teemsyにフィッティングを行う一方で、遊んでいるArduinoDueが勿体無いのでOscilloscopeを仕込んでみようと昨晩から頑張っていたのだが、

WS001679.JPG

動作を確認できているOscilloscopeを制御するClickEncoderが規格違いで実装出来ず、試行錯誤をしていたら夜が明けた。

WS001681.JPG

ClickEncoderは便利な機能なので大変気に入っているのだが、これが使えない状況は結構ツライ。

WS001682.JPG

コンパイルを通してはいるものの、エラーを潰すためにAVR系のライブラリーを無理矢理に排除した状態なので、ちゃんと動くかどうかは不明。

WS001683.JPG

いろいろと怪し気なところがあるのでこれからバグを潰していくことになるが、Teensyみたいな他所の子の環境でなんとか動かせるものが本家のDueではアウトというのが情けない

WS001686.JPG

Teensyから単純に載せ替えが出来ないのが歯痒いが、元はDueで開発していたのをTeensyに移植した経過を思い出して、複雑な心境になっている。

DueではClickEncoderを駆動するTimerOneライブラリが使えなかったので、Timer3というのを代わりに使っている。

オリジナルのコードは

  Timer1.initialize(1000);
   Timer1.attachInterrupt(timerIsr);

と記述していたのだが、Timer3には initialize というコマンドは存在せず、代わりにそれらしいコマンドをデッチ上げることにしたのだが、、、。

コンパイルにはやたらと時間が掛かった。 

WS001685.JPG

Teensyの場合も同様で、メモリのキャパを高々10%消費する程度の短いコードの割に、時間を食わせられるのが謎だ。 LCDのデータの取り溢しに関してはDueの方がマシなのは何故なのか? 動作クロックの問題など、解らないことが多い。

書き込み完了時の表示。 なんだかよく解らない文字が羅列されている。 

WS001684.JPG

書き込みのプロセスがバーグラフで表示された以前とは仕様が激変している。

Oscilloscope自体はAD周りがイマイチなTeensyよりも安定して動いている感じなので出来れば完成させたいところなのだが、DueはAVR系のライブラリを一切受け付け無い不親切極まりない仕様で、その余波でTimer系のライブラリの互換性が確保できない等、潤沢なリソース(だけ)が売りのArduinoとは思えない所業である。

この手の使い物にならんハードウエアを、よりにもよって本家筋が作って仕舞ったのは理解不能だが、確かにWebを検索しても製作例を殆ど見かけないのであった。
posted by Yasuski at 08:58| oled

2019年02月16日

音声編集のメソッドについて

プリセット・チャンネルの出力波形の編集を行う際に採り得る選択肢として、

1)目的とするヴォリューム群を一旦ゼロにリセットすることから始める。
2)もしくは12bit幅の最大値に上書きを行う。

という、2通りの方法が考えられる。

ポットの設定は簡単で、ポットを選択後に右側に2クリック動かすとほぼ最小値に、左側に動かすと最大値に出力を振り切らせることができる。

WS001678.JPG

より簡単に修正を行うには、最大値から適正値まで出力を減算していく手法が最適解と思われるが、この時に誤って波形データの変更を行うとオリジナルの状態が掴めなくなってしまうので、ポットを切替える時には誤動作に注意しなければならない。

問題は、今現在どのオシレーターを選択しているのかが判り難い点で、その場合は波形を切替えて該当するオシレーターを確認することになる。

何れにしても、離散したパラメーター群をまとめて俯瞰することは難しく、オシロスコープを併用した方がより確実に編集を行える。 出来れば専用のツールを開発したいところだ。
posted by Yasuski at 21:06| LaVoixski

記録ガイドの変更など

周波数検出機構周りを合理化した影響で、何故か音声ガイドが一斉に死亡する案件が発生した。

しかも、関連するLEDの点滅機構が同時に無効化されてしまっているのが謎だ。試しに対象となるLEDを変更したところ、こちらのアクセスは受け付けられるようで、全く訳がわからない。 音声ガイドはギミックなので諦めるとしても、LEDの点滅表示は必要な機能なので不具合を無視することが出来ない。

対策を熟慮した結果、動作不能となった全ての音声ガイド機能の代わりに目視に拠るLEDの発光パターンを組み込むことにした。

WS001664.JPG

WS001665.JPG

WS001660.JPG

波形パターンを登録するチャンネルに記録を行うメソッドをアドレス毎に直接編集するスタイルに変更したため、目視による確認がより効果的との判断もあったが、楽器の構造としてはこちらの方式の方がスマートだろう。

一方、波形編集機能の強化に伴って、オシレーター群のレベル管理に関する問題が表面化してきた。 

Screen Shot 2019-02-16 at 16.18.23.png

VRポットの該当する箇所に記述している volumeInc は、12bitフルスケールで増幅倍率を等倍にするための係数だが、×1倍以上にレベルをオーヴァーさせないために、ロータリーエンコーダーからの出力値を12bit以内に制限するリミッターを設けている。

WS001658.JPG

プリセットを呼び出して、各音源のレベルをゼロにリセットした後、再度レベルの調整を行う。 レベルのリセットはパラメーターをいちいちコールするのが面倒だが、該当するアドレスのノブを2クリック増加方向(右)に回すだけで、ヴォリュームレベルを最小値+1(実質的には最小値)に設定できる。 逆にノブを減少方向(左)に回すと、12bitフルスケールの最大値をコールできる。 

実際的な運用方法としては、ポットの最大値を呼び出してから最適値まで増幅度を下げていく方式が推奨される。

Screen Shot 2019-02-16 at 16.26.27.png

最新のデータがシーンメモリーに反映されない問題を解決するために、データ書き込みのタイミングでレジスタを上書きする仕掛けを追加した。

WS001659.JPG

その後、コード・エディットモード下で波形選択機能を使用した場合に、フリーズが発生するバグを確認した。 これは去年の夏場に体験した症状と酷似している。

既にコンパイラ、もしくはオプティマイザのバグが疑われる状況だったため、これを機にオプティマイザをLTOに変更したところ、問題は解決した。
posted by Yasuski at 07:58| LaVoixski

2019年02月15日

FVCに関連するルーチンの合理化について

少しでもピッチの安定度を向上させるため、周波数ディテクターを構成するFTMとPitch/VolumeValueの処理を行うルーチンのリレーションを強化した。

WS001661.JPG

LaVoixskiのプログラムはフリーラン状態のMainLoopと外部から入力されるオーディオクロックの波形が立ち上がるタイミングで動作するattatchInterruptおよびサブルーチン群で構成されているが、基本的にMainLoop内はフィジカル・インターフェイス系を、

WS001675.JPG

WS001676.JPG

attatchInterrupt内はオーディオ処理系のタスクを中心に配置している。

WS001677.JPG

周波数を検知するFTM(Flexible Timer)は、これらのルーチンが処理を行うタイミングとは独立してカウンタを回しつつ、外部トリガ入力のアップエッジでカウント値の差分をキャプチャしているが、

WS001671.JPG

改装前のコードでは、FVC(Frequency to Value Converter)を総体として見た場合、FTMから駆動されるピッチ/ヴォリューム・コントローラーはMainLoop内に処理ルーチンが内包されていた。 

WS001672.JPG

WS001673.JPG

FTMのカウントデータは、周波数の確定フラグが立った時点でPitch/VolumeValueを生成する処理ルーチンに転送され、計算が始まる。 

今回の改良では、今までMainLoop内に展開されていたPitch/Volume Valueの処理ルーチンをサブルーチン化し、

WS001662.JPG

WS001663.JPG

FTMルーチンから直接これらを駆動することで、同一のタイミングで処理が開始されるようにした。
posted by Yasuski at 16:07| LaVoixski

2019年02月14日

出力波形のパラメーターを修正する機能を追加する

仕込んだ音色の修正を可能にしたいところではあるが、機能の実現にはパラメーター×チャンネル分のレジスタが必要で「Pot周り」の操作系が物凄くややこしくなってしまう。

そういえば、数年前にTeensy3.2の環境でメモリーバンクに直接アクセスして編集を行う機能を実装しようと目論んだが、タスクが重くなり過ぎて諦めたことを思い出した。 現在も既に処理限界に突入しそうな状況なので、これは無駄な改良と思える反面、将来的に採用するMCUの能力が上がった場合に備えて動作を実証する意義は否定出来ない。

いろいろと手段を考えた末、タスクの重い計算をロータリーエンコーダーのセンシングを行うルーチンに分散させること思い付き、リアルタイムで波形合成の編集を行う機能を実装することが出来た。 

Screen Shot 2019-02-14 at 2.02.03.png

サンプリングレートと連動して計算を行っていた時は、オーディオクロック毎に浮動小数点演算のタスクを強いられていたのだが、この場合は数値の確定後に計算をスルーできるのがミソだ。

パラメーターが増えた分だけ運用法が複雑になってしまったが、プリセット状態で演奏を行う場合は全く影響はない。

Screen Shot 2019-02-14 at 2.00.02.png

パラメーターの記録は、各々のアドレスで行うことが出来るようにした。 アドレス16番の波形編集専門チャンネルは不要となったので廃止。 同じアドレスには新たに記録可能なバンクを再構築している。

Screen Shot 2019-02-14 at 2.03.33.png

パラメーターをアサインした場合にヴォリュームがゼロになってしまう弊害が露見しているが、対策として予め存在するデータにロータリーエンコーダーの値を足す方向でプリセットを調整できないか検討を始めている。

追記:

波形選択モードで何故か破綻が発生した結果、ロータリーエンコーダーでパラメーターの差分を扱う計画は失敗に終わった。 これは、閾値がオーヴァーしてしまうために発生するトラブルだと思われるが、現状ではメモリーの仕様が93%超えとカツカツで動作に支障をきたすレベルに到達したため、リミッターを追加しても別件で不具合が発生する可能性は否めない。 ということで、残念ながらこの計画は断念することになった。

実際に編集機能を運用してみたが、差分で操作を行わない仕様であってもあまり違和感を感じなかった。 ただし、音声編集モードに入って編集を行ってしまうと、「電源を落として再立ち上げするまでは元の状態に復帰できない問題」が発覚している。

「電源を落とせば現状に復帰する」というのはあまりに前時代的で不便なので、シーンメモリーにバッファーを追加しよう。

追記2:

バッファーの設定を勘違いしてマヌケなことをやっていたので修正を行った。

Screen Shot 2019-02-14 at 18.20.36.png

要は、データを読みだした時の値を規定値として保持するためのレジスタを追加したということ。 ポットによっては、ローカルにこの手のバッファーを持っているものもあるが、今回はmicroSDからデータを読みだすタイミングでバッファリングを行い、アルペジエーターの起動スイッチがオフの時に保持したデータをポットのレジスタに戻す形で処理を集約している。

Screen Shot 2019-02-14 at 18.23.50.png

編集時に元の音に復旧させる場合に問題があって、トップスイッチのオン・オフは演奏モードの再現を優先するためにリセットにともなって再生アドレスが変わってしまう。 このズレから復帰する方法は簡単で、アルペジエーター起動スイッチ=トップスイッチのオン・オフを行った後にチャンネル選択ノブを1クリック動かして元に戻すタイミングでローカルバッファーのデータを読み込ませればよい。 事前に混乱を避けるには、予め演奏モード上で目的のチャンネルを設定するとよいのだが、2つしかないノブにすべての機能を集約する分、常にアクセスできる情報は2系統となってしまうわけで、インターフェイスの設定はなかなか難しい。

遊んでいるアルペジエーターのスレッショルド設定チャンネルを音声編集用として利用する方法もあるが、それを実現するための具体策はまだ持ちあわせていない。

追記3:

リセットワークをサブルーチン化すれば、UpperKnobの状態=mode2によってリセットを行う対象を切り分けることが出来そうだ。
posted by Yasuski at 02:47| LaVoixski

2019年02月13日

Distortion / LevelShifter の項目を編集可能にする

Distortion/LevelShifterをオン/オフするスイッチをロータリーエンコーダ下側のパラメーター#5・6番に追加した。

WS001651.JPG

選択したモードによって、ポットの機能を切り替える。

本来は、音色の編集を行った後にレベル管理やディストーションの調整を行うのが合理的なのだが、旧仕様では予め設定がプログラム上に仕込まれているために、音声出力をベストな状態に追い込めなかった。 今回の改変ではパラメーターの調整を手元で行えるようにフィジカルインターフェイスを追加して、出音を確認しながらエフェクトの調整が行えるようになった。

WS001650.JPG

コード上に記述したスイッチの状態を単純に切り替えていたのを、ファイルから読みだしたデータを元にオン・オフを判定する構造に変更している。

出力に非線形な効果をもたらすディストーション・エフェクトとレベル管理を行う項目は、音色に与える影響がことの他大きいのだが、固定パラメーターに合わせて直感的に音色の設定を行うのは大変難しい。 今回の改良によって手動で試行錯誤を行いつつシーンメモリーも可能となる予定だ。

WS001653.JPG

情報の量は知れているのだが、32項目×2と結構な量のファイルを取り扱うことになるので、凡ミスによるバグの発生が懸念される。

WS001653.JPG

データの記録はパラメーターの調整を完了した時点でポットを長押しして行う。

無事コンパイルは通したが、稼働状況は不明。 リザルトは実機にプログラムを書き込んだ明朝以降に判明する。

追記:

追加した機能の動作を確認、メモリーの読み出しも正常に行われている。 実際に運用してみると、Distortionの切り替えは問題なく行えていたが、levelShiftの有効性に?が出た。 これは、ハード側の不具合、もしくはチューンの失敗の可能性が高く、回路の精査が必要になった。
posted by Yasuski at 04:32| LaVoixski

2019年02月12日

Pitch/Volumeの処理を分離するために、FTM3を起動する

テルミンのPitch/Volumeアンテナは、要求される動作領域のスケールが異なるために、単一のタイマーによってValueを計測する場合は「どちらかを犠牲にして」サンプリングレートを決定する必要がある。

現時点のFVCはVolume側がスムーズに動作するレートを優先した分周率を採用しているのだが、遊ばせているFTM3にタスクを分散させることによって、それぞれの用途に合わせたサンプリングレートを選択した運用が可能となる。

WS001647.JPG

例のごとく、実験前に動作の保証はないのだが、コンパイルだけは通すことが出来た。

WS001648.JPG

端子の処理は、pin#23に接続されているVolumeAnt側の出力をpin#14にブリッジすれば良いので、明日の朝一番に実験を行おう。

追記:

実験の結果、ヴォリューム側の信号がピッチ側に漏れる謎現象が発生した。 

何故か、ヴォリューム側の動作がピッチに影響してしまう。 確認のためキャリブレーション・モードでオシレーター毎の素の挙動を確かめてみたが、ピッチ側では両手の動きがダダ漏れな一方、ヴォリューム側ではピッチの影響が排除されていた。

この状況から推測されるのは「入力信号の物理的な干渉」で、基板の配線を変更せずにPINの機能を殺して信号をブリッジしているつもりが、モロに影響を受けてしまったようだ。

何れにしても現状では全く使い物にならず、原因究明のために改めて基板の配線を変更しなければならない。別にテスト用の基板を用意してもよいが、FTM3の動作確認を行うためだけに基板を新調するのは無駄なので、これを機会にテストベッドを新調すべきなのだろう。 

試しにFTM3への接続を切った状態でFTM0のみの試験を行ってみたが、残念ながらピッチの安定度が改善することはなかった。

posted by Yasuski at 01:37| LaVoixski

2019年02月10日

Modulus 演算の速度を向上する

Webで発見した処理速度向上のためのTipsをヴォリュームコントロール関連の制御回路に導入した。

計算例では、ARM Cortex: 390 cycles が ARM Cortex: 384 cycles に改善されるという微々たるものではあるが、Transition系のヴォリュームは繰り返し演算を行うので、計算量はVoice分だけ加算される。 タイトなリソース情況に於いて、それが少しであってもクロックサイクルを稼ぐのが正道といえる。

Arduino上で C99 fast data types / uint_fast16_t の使用が有効かどうか心許なかったが、とりあえず必要な場所に導入する分に於いて問題は発生しなかった。

WS001645.JPG

uint_fast16_t の導入に併って %(modulus) 演算 C = A % BC = A - B*(A / B) に変換すると、速度の向上が達成できるということで、Transitionコントロール周辺のコードを改変した。

WS001646.JPG

確かに、左手の動きにともなって発生していた妙にザラついた音が消滅して動作がスムーズになった感触があり、速度向上のTips導入に成功した模様。
posted by Yasuski at 20:05| LaVoixski

ロータリーエンコーダのデータ更新について

Muteスイッチ周りで発生していたバギーなLEDの点灯パターンを修正しつつ、

Screen Shot 2019-02-10 at 1.45.52.png

ロータリーエンコーダの入力状態を参照→レジスタにアクセスというルーティンをスキップする仕掛けを組み込んだ。 

WS001640.JPG

特にレジスタから受取ったデータを加工するModuloや除算を行うルーティンが曲者で、これらの計算が元データが変化していない状態であっても常に規定された参照時間毎に行われていた。

WS001644.JPG

今回は、ロータリーエンコーダの状態の変化を感知する条件分岐の後にbreak;を組込んで、

WS001642.JPG

無用な計算をスキップする仕組みを追加したが、今のところ体感的な変化は実感出来ていない。
posted by Yasuski at 03:20| LaVoixski