GUIの骨格がほぼ固まる。

この色味は、ランダムに色彩を選択するデモ用の機能。　



実機はGRNとBLUの組み合わせになる。

出力波形をモニターするモード。



L/R/Cの動的変化を表示する。

これは、Transitionのイメージ。　



GRN/BLU/RED/YEL/MAGの順に、オシレーターのVolumeが推移するカーヴを表現している。　オフセット値によって、Cosカーヴの間隔が増減する。

ChordEditModeでサブ・トーンの音程を表示している。　



GRNがマーカーとなる固定チャンネルで、BLU/RED/YEL/MAG の順にオシレーターのチューニングを示す。

Arpeggiatorは、Step数と再生パターンを表示する。



UP/DOWNの表示。　昇と降り分のオブジェクトを描画するため、STEP数が増えるにつれて視認性が低下してしまう。



描画のルールには色々と癖があって、その方面の初心者には色々と解らないことが多い。

WaveEditModeでは、選択したOscillatorの波形をGRN~MAGまでの５色で表示する。　



OSCのミックスレベルは縦棒で表現している。　WHTの波形は、Mix後の出力波形をモニターしたもの。

今回デザインしたUIは、レベルの増減をY軸で表現しているが、視認性に劣るX軸を操作する方がオフセットの設定が楽なので、今後どちらの方式を採用するか、検討を行うことになるだろう。

ExciterModeで、Volume Array の数値を表示するオブジェクト。



これはダミーだが、実機では、チェビシェフ変換を行う時のソースとなる「生成済みの波形」を読み出すことになる。

何れにしても、現状では波形のグランドレベルを補正する機能の実装が未了なので、これから悩むことになりそうだ。

Chord Edit Mode のUIを考える。

実際の使い方はこんな感じで、マーカーノートを基準に異なるピッチの4声を編集し、それを任意のアドレスに登録する。



この編集モードで作動するスペクトラム・アナライザ風のUIを追加したいのだが、元々がPitchデータをいじってオシレータを駆動する仕組なので、X軸のスケールをアンチログ化して結果を縦線で描画することで、機能を単純化出来るかもしれない。

今は、周波数をMidi note numberに変換する方法を模索しているところ。

リアルタイムに波形を描画する実験の続き

リアルタイムというには更新が半秒に一度というのが残念な仕様ではあるが、入力1（GRN）入力2（BLU）加算（RED）乗算（WHT）といった配分で描画を行ってみた。



今回は、視認性を確認するために、便宜上 pitch & volume のデータから描画を行っているが、本来 vol は出力レベルを決定する値故に、直接バッファーに数値を取り込むことはない。

7月31日/追記：

乗算した出力「白」のピークが頭打ちになってしまう原因が判らない。　桁上り？と思われたのだが、データの幅を2倍に大きくしても状況は改善されず。　一方、加算の結果を示す「赤」に問題は発生していない。



試行錯誤を繰り返した結果、描画を行う際のスケーリングとオフセットの追加を、事前に合成する波形毎に行うのが正解だった模様。



とりあえず、描画の問題はクリアできたようなのだが、加算と乗算の結果がほぼ同じで、



微妙にズレているところが何か変。

リアルタイム波形表示の複線化と、表示倍率を自動化する実験

波形キャプチャ機能をオブジェクト化した後、



適当な倍率調整機能を追加して、描画の倍率を調整してみた。



実際は、楽器の運用時に発生する数値に合わせて調整を行うが、ランダムに発振させた周波数には対応できている模様。　以下、1秒間隔でランダム発生した波形をキャプチャしている。



波形の動的推移を観測することが目的なので、視認性を現物で確かめることになる。



点描のノイズっぽい描画が行われることはほぼなくなったようだ。



あくまでもランダムに発生させた周波数を観測しているので、実用性の完全な証明には至っていないことを留意しなければならない。



とはいえ、視認性は格段に向上している。



位相がズレると各チャンネル毎の視認性が上がることが判るが、複雑な波形に対応するためには、更に倍率を下げる方向で調整することになるだろう。

出力信号のリアルタイム表示を行う。

オーディオクロックの分周に悩んでいたのだが、M7にはRAMを+16MBまで増量してあるので、消費を抑える意味はなかった。



出力を、EXTMEM上に確保した専用のポインタで駆動する4096stepのデータ・アレイにサンプリングすることで、リアルタイムサンプリングを実現することが出来た。



問題は解像度で、128x128では粗が大き過ぎる。



ついでに、ランダムに周波数を変化させた出力をサンプリングしてみたが、やはり高い周波数ではドットが粗過ぎて使い物にならなかった。

リアルタイム波形の描画は、動的な変化を観測できる一方、基本波のブレンド具合といった情報を直感的に得ることが難しい。　



この欠点をカヴァーするために、基本波のブレンド（L/R）と、出力（L/R/C）の情報をレイヤーを重ねる形で、一度に表示する方法があり、描画の輝度によってある程度は視認性を高めることが出来るかもしれない。

例えば、動的な波形を 白/黄/赤 で、静的な波形を 青/緑 で表示することによって、視覚的な階層を演出することが可能だ。

SDカードから読み込んだ波形を表示する。

SDカードから波形を読み出す機能を追加した。



もしかすると、音色をデザインするモードでは「リアルタイム性」に拘る必要はなく、加工前の波形にミックス・レベルを掛合わせたもの5波分を合算するのが、よりスマートな方法かもしれない。　単純に合成した波形を確認するのであれば、シンプルに基本波を合算した結果を見るのが正解だろう。　SDから引っ張ったデータを直読みする方法には、左右のアンテナの影響を排除できる利点がある。

ただし、「非線形モード」に於ける出音は元波形から確認できる性格のものではなく、



選択したモードによって表示を切替えるべきだろう。

次は、リアルタイム・データの取り込みが課題だが、オーディオクロックを分周する手段を決定出来ずに、其処で作業がスタックしている。

ディスプレイ機能に疑似オシロスコープを追加する

ラフな造りではあるが、オシロスコープのプロトタイプを製作した。



デザインは、他のパラメータを踏襲して、上下にロータリーエンコーダの表示と同じ色味を持たせたオブジェクトを配置し、そこに該当するパラメータの数値を表示する。　波形の表示は中央部に配置するが、こちらは同じ表示領域に色味でレイヤーを分けた波形を重ねて表示する。



表示する波形のソースとしては、ADを介したサンプリング・システムをわざわざ構築してもあまり意味がないので、Transition用に生成したサイン波の描画データを加工したものをデータアレイに格納、それらを再度読み出して波形の表示を行っている。



この仕掛けを楽器に組み込む場合、オーディオクロックをディスプレイのピクセル値に合わせて分周したタイミングで、データ・アレイに出力値を取り込む形になるだろう。

OLED版はアカン感じだった

今日は夕刻からOLEDディスプレイをMCUに接続して実験を行っているのだが、



128x128ピクセルの表示領域は視認性に問題があり、240x240ピクセルのLCD用に組んだシステムを縮小して運用しても、同様の効果が得られそうにないことが判った。



最適化は現物合わせで行うしか無いのだが、これが結構な手間な上にあまり効果が期待できないのが悲しい。



OLEDは直射日光下の視認性に優れる長所がある一方、LCDと比較して価格が数倍ほど高いので、これを採用する可能性は低くなった。　試作機には、より単純化したUIを実装した方が良いと思われるが、組み始めているOLEDを搭載した試作機2機分のフロントパネルをリプレイスする必要が出てきた。

Transition/Arpeggiatorのパラメーターをデザインする

パラメーターの数値を単純に表示するだけでは芸がないので、より直感的に情報を取得できる表示法を考えることにした。

特に難物と思われるのは出力波形と、概念が一般的ではないTransitionの表示と思われるが、まずはデータの取扱が容易な後者から設計を始めていく。

実際の制御波形がCOS波なので、Arduino_GFXのdrawPixelを使って、波形の描画を行った。



プログラムの構造もオリジナルに準拠したもので、オフセット値を操作することで、COS波の間隔を変化させている。



次に設計を始めたのはArpeggiatorの表示で、これが思ったよりも難物だった。

設計のおおまかな概念は、fillRectを使ってピアノロール状のオブジェクトを表示する方法で、設定した表示領域を任意のSTEP数で分割・生成する。　問題となったのは、STEP数によって生じるオフセット値で、これを解消するために、多くの試行錯誤を行うことになった。



どうやっても解消されないオフセット値の狂いに悩まされたが、240x240の液晶の規格を、256x256と勘違いしていたことが原因だった。



プログラムは、Switchを使って再生パターン毎に描画ルーティンを選択している。　苦労したのはUP&DOWNの三角波で、この部分のオフセット値を解消することに、労力の大半が費やされることになった。



グラフィックで表示するパラメータとして、STEP数と再生箇所の推移を選択している。　まずSTEP数は再生パターンの表示も兼ねさせていて、ピアノロール状に発音順の配列を表示する。　



RATEはdrawLineによる縦線の移動で表現しているが、少々視認性に問題があるので、これは改善の必要があるかもしれない。

Teensy4.1@ OLED/LCDの接続を行う。

久々にやる気になってLCD系の試験を始めたのだが、ライブラリの書き換えに失敗したようで、全く反応が得られ無い。　念の為に配線をチェックしたが、物理面のミスは発生していない模様だ。　これは、ライブラリを未編集＝素の状態に戻して再トライするのが正解だろう。

使用するライブラリは、稼働実績が認められるArduino_GFXで、YoutubeにLCDをドライヴしている様子がアップロードされている。　が、現実には全く動く気配を感じられない。　仕方がないので、久々にロジアナを投入してSPIの通信波形を観測したものの、「何かが怪しい」程度の認識を得ることしか出来なかった。　ライブラリに手を入れていない「素」の状態がこれでは、非常に幸先が悪い。



不具合の原因を探るためにスケッチを眺めたところ、どうも初期設定を間違っている風だったので、該当する箇所にOLED/LCDの設定を追加したところ、やっとまともに動かせるようになった。



試しにベンチマークを走らせてみたのだが、、、

　

プロセスが超絶に速すぎて、初見では何が起こっているのか認知ができなかった。



ついでに、LCDのドライヴにもトライしてみた。



LCDが順調にドライヴできたので、次は表示内容の検討に入ることにした。　まずは、GPT2の Input Capture 1/2 とPWM_LEDを走らせた状態で、OLEDディスプレイに時計を表示してみる。



現時点ではOLEDにデータを送信するSPIはデフォルトのチャンネルで、目標のSPI1に出力を変更することには成功していない。

次に、センシングした周波数の表示を行ってみた。



視認性の向上を狙ってBoldフォントを追加して、背景とフォントの色味を1秒間隔でランダムに選択する実験を行う。　実際にはLoop内にdelayエレメントを配置せず、インターフェイスの操作時に発生させたトリガーのタイミングで描画を行うことになるだろう。





データの表示領域に余裕があるので、プリセットが可能なオフセット値の表示を追加した。



表示系のデザインは、実験を通して実現可能な落し処を探って行っていくことになりそうだ。　例えば、RGB_LEDでカヴァーできない部分を補助するのか、積極的にパラメーターの情報を表示するかで、表現の指向性が変わってくるのだが、LEDの状態に構わず全体の視認性を上げる方にデザインを行うべきかもしれない。

ライヴで演奏する場合は、実用性から事前にプリセットしたものを呼び出す形の運用それ一択と思われるので、多少視認性が落ちることがあっても、得られる情報を詰め込んだほうが良いのではないか？と思っているのだが、背景を工夫することで視認性と情報量の確保を両立できるかもしれない。

例えば、LCDの上下の背景は、ロータリーエンコーダで選択したモードの色味を反映しつつ、色味を反転させたフォントで、各パラメーターの数値を表示するようなデザインを考えている。

例外は波形表示で、これは音色のエディットモードに於いて実際の出力波形を観測しながら行う形になるだろう。　表示するデータのハンドリングは、波形一周期をサンプリングしたデータアレイを更新する方法になるだろうか、、、。



Transitionの設定は画像化によって直感的にその概念を理解出来そうなのだが、共有が望めない概念は「絵で説明する」のが一番だろう。　Webで見つけたコードを参考に、ダミーで描画してみたが、Transitionの表示はこんな感じでよさそそうだ。　サイン波を計算した結果をdrawPixelでプロットしている。



ロータリーエンコーダを操作した状況をシミュレートする際に、位相はCOSが正解と結論した。

GPT2の動作を確認する

なんとか、まともにセンシングを行えるようになった。







躓いたのは、InputCapture に関する全てのイベントを統合して出力される IRQ_GPT2 の扱いで、



何故かジャンプ前の条件分岐でタスクを振り分けることが出来ず、



必ず最後に記述されたイベントのみが優先されてしまう。



更に深刻なことに、キャプチャフラグによる選別が行われないために、例えば該当する input capture1 の入力には正常に反応する一方で、input capture2 に入力を行った途端に、input capture2 側にロックアップが発生し、出力データが input capture2 が出力する”０”に固定されてしまう現象が発生している。



この「仕様」に対処するために思い付いたのが、attachInterruptVector(IRQ_GPT2, capture);　でジャンプする先のサブルーチン ”capture” 内に於いて GPT2 input capture1/2 のキャプチャフラグを使って分岐を行う方法で、



これにより、2ch分の入力を同時に計測することが出来るようになった。

ただし、依然として統合された IRQ_GPT2 の影響は排除されておらず、キャプチャフラグのタイミングによってデータの不感帯（カウントが進まずに、”０” が出力されてしまう）が発生して、出力データに事実上のリセットが掛かってしまう。

この問題を解決するために、カウンタの数値が変化しない場合は、出力レジスタの計算をスキップしてゼロを出力しない条件分岐を増設している。



出力値のチューニングは、特に低い周波数をセンシングする時の分解能を確保する方向で行っていくことになる。

GPT2の動作確認を行うために作成したスケッチに不具合が発生する

M7チップを搭載したTeensy4.1上で、周波数ディテクタとLCD/PWM_LEDの働きを検証するためのシンプルな構成のスケッチを書いたものの、何故か立ち上げの途中でスタックしてしまう事案が発生した。

より複雑な構造の楽器そのものを構成するスケッチ（ただしLCDは未実装）では、無事にLoopまで辿り着くのが、これまた大きな謎だ。

仕方がないので、とりあえずマーカーを使って原因を辿っていくと、どうも周波数ディテクタのINIT時にスタックが発生しているようで、試しにサブルーチン内の動きをマーカーでトレースしてみると、レジスタを初期化する場所で処理が止まっていることが判った。

試しに、レジスタをクリアする位置をサブルーチンの最後尾に移動したところ、



すんなりとLoopまで辿り着くことが出来た。



この不具合の発生には、ライブラリの更新が原因しているのかもしれないが、複雑な構成のスケッチでは何故か問題なく動作しているように見えるのが面妖で、ひとまずは単純化したシステムで怪しげな箇所を潰していく。



今回は実験の簡易化を目指して、任意の周波数に設定したPWM出力をディテクターの入力端子に接続している。

Teensyduino1.54について

久々に更新されたTeensyduino1.54をインストールしたところ、SD関連のライブラリに変更があり、コンパイルが通らなくなった。



該当するファイルのパスを取り除くことで、コンパイルが通るようになったが、削除されたファイルを追加して対応することも可能だった。



一方、遅れている各パート（GPT/PWM/LCD）の稼働試験用に専用のスケッチを書いたものの、LCDとPWMで駆動するRGB_LEDの色味を指定している変数がコンフリクトを起こしてしまった。

コンフリクトを回避するためには、PWMの振幅設定とLCDの色味設定を行う変数のうち、どちらかの名称を変更する必要があるのだが、今回は書き換えに手間が掛からないライブラリ側に変更を行うことにした。



名称を書き換える箇所はArduino_GFX関連のライブラリのうち３ファイルで、色味を設定する変数の末尾に”２”を追加している。





あくまで暫定的な処置ではあるが、コンパイルは通っている。　次は、外部にデバイスを繋いで試験を行っていく。

Daisyのライブラリが新調されていた

暫定で行った、ロータリーエンコーダーを追加するための修正ポイントを例示しておく。

Daisyの新しいライブラリは変更点が多く、過去に追加したロータリーエンコーダ関連の記述はすべて無効となった。



まず、判り易い変更ポイントとして、DaisyDuino.hが、Utilityフォルダを参照することになった。



一方、DaisyDuino.cppでは、デフォルトで仕様が想定されているエンコーダーが単体なので、これを2個対応に変更する。



ハードウエア毎にインターフェイスの設定が異なるので、個別に対応を行っている。



コントローラーの総数は、この部分で設定を行うようだ。



こちらは、ハードウエア別の設定箇所。



基本的にはPodに対応するだけで良さそうなのだが、一応こちらにも手当を行っておく。



ProcessDigitalControlで、デバウンスの設定を行っているようだ。



DaisyPod.hでは、インターフェイスに対応する端子を設定する。



DaisyPod.cppでも、端子の設定を行うようだ。



エンコーダーの初期化ルーティンに、追加分のエンコーダを記述する。



ProcessDigital Control　にも項目を追加しておく。

9月13日追記：

CubeMXを新調した。　



TIM2/CH1のコンフリクトは、InputCapture端子をTIM2/CH2に変更することで解決できるかもしれない。

TIM2/CH2 は SAI2_MCLK_B = P31 に変更が可能、
TIM5/CH1 は SAI2_SD_B = P32 に従来通りにアサインする。

ClickEncoderの導入には、freescale版のPITに準ずるFreeRunを繰り返す単純な構造のTIMERを設定すれば良いのだが、



STMのTIMERはfreescaleのそれとは根本的に構造が異なるため、サービスマニュアルの解析から始めなければならない。