プログラムの大改装を行う

とりあえず、プログラムを安定して稼働する状態に持ち込んでいる。



バグが大量に発生した原因は「プログラムの改装」によるものだが、今まで動いていたものがいきなり動かなくなるどころか、単純にバッファを通してデータを受け渡しするだけのパートがアナログ様の発振を起こす始末で、訳が解らない。　



画像は、その発振状態の一部を切り取ったものだが、0から2000前後の振幅で数値が変動していた。つまり、データを参照する毎に本来ピックアップされるべき数値の代わりに、増減する振動波が代入されていたことになる。

この件については、ロータリーエンコーダの終段にバッファを追加して、出力をダブルバッファに改装することで解決出来たのだが、



面妖なことに並列配置された関数の名称が異なるだけで全く同じ構造のオブジェクト群は正常に動作していた。 厳密には、データをバッファに送る手前の、pot13 + 1 辺りが怪しいのだが、今まで一度も問題が発生していなかった箇所だけにコンパイラ側の解釈が変わったとしか思えない。　

ということで、原因はコンパイラの「仕様」が変更された故に発生した問題の可能性が否定できないため、後々トラブルの発生を考慮して、関連するパートは全てダブルバッファ化しておいた。



今回大改装を行った理由は、タイミングの制御が微妙なアンテナ入力周りの処理を行うパートの精度に関して、増加する描画処理の影響を懸念していたことにある。　実証試験を繰り返す際に、動作が不安定で連携が甘いLCDとLEDはシステム全体の状態を示す指針にはならないと判断し、両者の動作を完全に同期させることに改良の主眼をおいている。

M7にシステムを移行する際に考えるべきポイントは、M4に比べて極端に処理能力が上がっている点で、今まで破綻を避けるために必死でタスクの割り振りを行っていたメソッドを一度忘れる必要がある。　今回は、処理のタイミングが曖昧になるLoop内から、Arpeggiator系のトリガ機構を引き上げて、AudioClockによって支配されている音声処理のルーティン内にこれを移植している。　



描画された波形を見る限り、いまのところ音声データに大きな問題は発生していないように見える。

描画機構に関しては、Redrawを行うレートの制限をPITによって集中管理する方式を廃し、描画パート毎にローカルでArpeggiatorのクロックと描画のタイミングを同期させる方式に転換している。　



これにより、Arpeggiator によって制御されたLEDが発光するタイミングと、描画されたインターフェイスの同期を得ることが出来たのだが、LEDの再マッピングや描画の設定変更やらで、結構な作業時間が費やされることになった。



以上の改変を、サイズの違うOLEDに移植することを考えると今から頭が痛いのだが、記憶がクリアなうちに作業を貫徹すべきだろう。

OverClock時にMCUが発熱する温度について

1G超え運用を暫く継続して tempmonGetTemp(); で温度を観測してみたが、



冷房が結構効いた部屋でヒートシンク付き自然対流といった環境下の70℃超えは少々ヤバい。　

息を吹きかけると62℃まで下がったので、クーリング用のファンは必須となるか。

MCUに物理的な限界が来る温度が85℃という話を検索したトピックで見掛けたが、これは既にルビコン川に足を突っ込んでる数値らしく、即シャットダウンしてもハード的な健全さを維持できるかどうかは微妙なところだという。　狭い筐体の中では容易にこの温度に到達しそうなので、1G運用は諦めることにする。



楽器としての運用を考えると、クロックを落として最高でも自然対流で65℃程度に抑えるべきで、現在はクロックを912Mhzまで落として試験を継続している。



安全マージンを稼ぐためには「ヒートシンク無し」の状態を維持するのが望ましく、折衷案としてClockのスピードを816MHz辺りに設定するのが正解なのかもしれない、、、。

温度管理とは関係はないのだが、パソコンとのシリアル通信を行った途端に遊んでいたメモリーが半分くらいまで消滅したのが面妖で、今後は　Serial.println　を禁忌に指定することになりそう。

OverClockの実験

ヒートシンクを取り付けて実験を開始した。



いまのところヒートシンクの温度は人肌＋なレベルだが、数時間放置して温度の変化をチェックする。



描画それ自体のクオリティーよりも、リドロー時の反応が速い。　リドローに関しては、撮影時のフレームレートと液晶の描画速度との関係で、肉眼よりも動画の方に違いが目立っている。



MCUの放熱をチェックする過程で、3番目のオーディオポートの出力波形を記録した。
このポートはモノラル・アウト専用で、搭載するオシレータ5基のうち1chを選択して出力する。



出力形態は、1ch辺り Transition、Normal、Chebyshef Function の3通り、合計15パターンを用意している。　



前半の5パターンがTransitionに対応しているが、波形の振幅が位相を個別にドリフトされた制御信号によってコントロールされていることが判る。

Chopping Mode の記録

Arpeggiatorから出力されるミュート・トリガーのタイミングで、音声出力がチョップされる効果を記録した。



ミュート信号が入力されるタイミング（LEDの色が変わる）で、出力波形が消滅する。

クロックアップにトライした

MCUを816MHzのOverClockで運用した結果、描画のシェイプが明らかに改善されている。　



MCUの処理速度を上げることで、描画を行うプロセスに強制的に介入してくるAudioClockの影響を軽減する効果が認められた。　



OverClockの有効性を確信できたので、MCUに放熱器を装着後、最大値にチャレンジしたい。

Transitionの"Q"を切り替えた場合に発生する出力特性の変化を記録した

画像は、何れも音量を決定するパラメータに最大値が入力された際の反応をキャプチャしたもの。





繰り返し映像を眺めていて気付くのは、シェイプが急峻な方はノーマルで観測した波形が変化する過程が前倒しになっている点で、理屈通りに仕掛けが動いていることが判る。

左右別バンクの波形ガイドを出力する

LaVoixskiの波形編集モードでは、呼び出すアドレス毎に音源のパン設定が異なるために、直感的にオシレーターの配分を決定することが難しい。　



もし、波形を編集する際に、出力波形のレベル調整を行う前の素の出音による視覚的なイメージが得られると、より編集が楽になるかもしれない。

この楽器の「売り」の1つに「5つのオシレータによる加算合成」を謳っているのだが、たかだか5波しかない音源ソースが左右にバラける環境では、厳密な運用は望み薄だろう。　故に、モノラルの概念を引きずるのは却って弊害が大きい。　左右の音質的なバランシングの確認を目指し、出力レベルに破綻が発生しない範囲で、単純に波形を合成した場合の指針となるガイドが必要だ。　

その「ガイド」となる波形の生成を実現するために、、、



波形編集モードに展開される”スイッチ”のコピーを造り、描画と音声を合成する過程のリンクを強化した。

実際の運用はこのような形で行っている。



赤と青の線は、破綻が発生しないことを前提にそれぞれのオシレーターを等分にミックスされた状態を示している。　特に、動的制御が行われた場合に発生するフォルムの変移を、デフォルメされた形で表示出来るのが長所と言えよう。

VolumeAntの動きをシミュレートして、GUIの動的変化を観測した

VolumeAnt側の周波数ディテクターの内部に信号源を組み込んで、入力値に対応した波形表示機構の動的変化を観測した。



実験をすすめるうちに、出力波形をライヴで描画する際に発生する「オシロスコープのSYNCロック外れ的な症状」に悩まされだしたのだが、これは各オシレータが指定された音程に合わせてアドレスを読み飛ばすために設定するOffset値と、波形合成後のデータストリームをリサンプリングする際に設定するOffset値のミスマッチが原因と思われる。

解決の方法は無くはないのだが、そこそこの重タスクが予想される故に、肝心な発音機構の動作に影響が出る可能性が高い。

折衷案としては、オシレータの全出力を合成したガイド波の生成を試験的に行っている。



これは、おおまかなデータの推移を示すアウトラインとも言えるもので、赤い輝線は、左右の音源をミックスした状態を反映させている。　表現が単純化されているために必ずしも必要な機能と言えなくもないが、Arpeggiatorの起動時に同期が外れて乱れがちな輝線が変化する軸を見極めることが出来た。

この機能の弱点はステレオ出力に対応していないところで、出力形態をそのまま描画に反映した別ヴァージョンを試している。



こちらが左右の中間値を個別に算出するヴァージョンで、赤と青がL/Rのオーディを出力波形を表す。　LRのオーディオ出力は登録したアドレスによって、プリセットされた左右に振り分けられる信号の定位が異なるために、その状態と同じプロセスをなぞって波形を描画する。　この映像では、OP3に抽出したオシレーターの影響が主に左チャンネルに発生していることが判る。

残念ながらこの機能は直感的に得られる情報が少なく、重めのタスクを要求する割には効果が薄いと判断しているが、以下の手法で行った動的試験を通して再評価を行うべきかも知れない。

波形編集モードのデモンストレーション

Chebyshev Transfer function の編集モードをデザインする

メモリー不足とExciterの編集画面に関する問題が解決した。

まず、メモリー不足の問題は、立ち上げ冒頭にSDカードからデータをシリアル通信で読み上げるセクションを全廃したところ、





劇的な改善が見られた。



ヒントは、動作検証用のシリアルプリント命令を追加した時にアラートが出たケースにあったのだが、これで採用を削ったUIを復活することが出来る。

メモリ不足の問題が解決したので、今後はExciterの編集画面のデザインを制限なく行える。　
まず、最初にトライしたのは、概念上の正弦波による倍音モデルを実際にグラッフィック上で加算合成していく方法だが、これは当然の事ながらチェビシェフ変換とは異なるシェイプを持つ波形が出来るだけで、編集のヒントにはならなかった。　

とはいえ、ひとまずはこの作業の過程で、波形合成を行うだけの余力がメモリに存在することを確認できた。

次に考えたのは、チェビシェフ変換の関数を廻しながら波形を合成していく手法で、これはリアルタイムで処理を行うことになる。



流石にこのような重タスクを継続するのは無理なので、あくまでLCDに描画するモデルの作成を行うに過ぎない。　画面上の辻褄が合えば良いので、データ幅はオーディオ用にリザーブされた4096ではなく、240で事足りる。



この程度の計算であれば処理に掛かる時間は知れているので、倍音構成を編集する際にパラメータの影響をダイレクトに観察することが出来る。

編集が完了したら、本来の計算を行うサブルーチンを起動して関数の計算を行う。　結果は、変換を行うデータアレイに記録する。



編集機能の動作を確認するために、240x240pixelの編集画面と、



4096stepのデータアレイを読み込んだ画像を比較すると、



分解能の粗さに起因する波形の歪が認められるものの、ほぼ同一の波形が記録されていることを確認出来た。　（この時点で位相の反転が判明、後に修正を行っている。）

ちなみに、ファンダメンタルのみを選択してレベルを最低に調整すると、理論通りに関数のカーヴは直線に近いシェイプになった。

今回行った実験の経験から、ポットのデフォルトの位置を最大値直前に設定することで、視覚的な変化の確認を行い易いようにしている。



そろそろ実機に組み込んで実験を行うべき段階だが、その前にDACを完成させなければならない。

Chopping Arpeggiator の動作不良を発見する

結論から言ってしまうと、今回もトラブルの原因はDMAMEM関連だった。

トラブルが発覚したArpeggiator にプリセットされたアドレス#17から#20は、音声出力を任意のタイミングでミュートする機能を搭載しているのだが、ミュートのタイミングを確認するために仕込んだ筈の「LEDがVioletに点灯する仕掛け」が動作していないようだ。



これはデータ型が怪しいということで、不具合を確認後に、、、



直接関係するDMAMEMを外してみたが、、、



それでもまともなデータを読んでくれずに、0が羅列されるだけの症状が続く。

これは、データの変換を行っているパートも怪しいということで、関連する場所から全てのDMAMEMを外した結果、問題は解決した。



DMAMEMは初期状帯がゼロではないということで、forを廻したゼロ代入でデータの初期化を試みるも、これは全く効果がなく、二回の上書きにトライしたがこちらの試みも徒労に終わった。



データの扱いが信用できないということで、念のために同様の問題を抱えているであろうEXTMEMに展開しているSequencerのフレーズを確認したが、問題は認められなかった。　データは Air on G string で、最初の無音からオクターブ分移動するベースラインのフレーズが確認できる。



要は、新たにデータを書き込みさえしなければ問題はなさそうだ。　一方、データの更新が行われるpot類にはDMAMEMは禁忌で、これの使用を全面的に禁止することにした。

映像は、復活した Chopping Mode のチェックを行っているところ。



IDEはこの調子で、大幅にアサインを変更してもメモリ類の使用率が変動しないという謎の現象が継続している。

出力波形の表示を行うデモ

元来はWaveformMixを含めて３種類あった描画モードを、Op3/ExciterとWaveformViewの２点に集約して、タスクを軽減化している。



編集モードを削除したために、編集時に行う筈だったオシレータの出力レベルを視覚的に確認する作業をスキップし、出力波形そのものを観測している。　つまり、静的な環境で波形を編集を行うのではなく、アウトプットに反映される状況を確認しながら調整を行う本来のスタイルに戻ったとも言えるが、音波を視覚化して目視により客観的に調整を行えるのは格段の進歩である。

チェビシェフ変換後の信号の描画に成功する

やっとチェビシェフ変換を行った波形を描画することができた。



このチェビシェフ変換を確認する画面では、サイン波を入力した結果を表示している。　単純な波形のサイン波に激し目な変調が掛かっていることが判る。



シェイプがなだらかな変換関数では、出力もなだらかな結果に落ち着くが、これは逆の例。

以前はこの確認を行うプロセスが存在しなかったために、関数の生成には出たとこ勝負な面が強かった。　関数の生成はリアルタイム処理ではないので、実質的には依然として「出たとこ勝負」に変わりはないものの、生成後に変換された結果を視認できるのは格段の進歩であろう。



Exciter/Op3の編集・選択モードで、チェビシェフ変換された波形を選択した結果が、MixEditの画面に反映されている。



このように基本波を表示した場合に、どうしてもオフセットが気になってしまう。



レベルシフトによって、概念上のゼロセンターがドリフトする現象は、描画の起点がy軸のゼロ方向（この液晶ではデバイスの上側）になるために発生する。　



レベルの変動に対して自動的にオフセットを設定できないことはないが、その場合、画面中央に波形が収束して視認性が下がってしまう弊害が考えられる。



実のところ、描画不能の原因は相変わらずのレベルの低い代物で、32bitが必要なデータ型の設定を16bitにしていた点にあった。



あとは、2’sコンプリ変換後を受けるレジスタをuintに指定していたりと、いろいろマヌケなことをやった集積が、不調の原因となっていたようだ。

まだレベルの変動によって発生するオフセット値の調整が残っているが、これはやりだしたらキリがないのと、オフセットが生じるお陰で視認性が高まるという余り感心ができない理由があって、暫くの間は実際の使い勝手を確かめるのが良さそうだ。

2’Sコンプリ変換の修正と、MixOutの描画について

やっと、出力波形を映像で確認出来るようになったのだが、



未だチェビシェフ変換が全く描画出来ない。



コードの何処かに不備がありそうなのだが、その特定が進まない。

表示に関しては、できるだけ基本波の音程を決定するアドレス読みのオフセットをピックアップすることで、



動的な変化を抑えて固定した波形を表示するように努めている。

今回再検討を行ったのは2’Sコンプリメントの音声データ規格の変換機構で、



映像による動作の確認を行いながら動作の正常性を確かめたところ、怪しげな挙動が認められたため、正確な描画が行われるように修正を繰り返した。



当初は、12bitのデータを２’Sコンプリメントに変換したものにVolumeのデータを乗算していたのだが、どうもこれが間違いの元だったようで、乗算後に条件判定を行うことで、変換が正しく行われるようになった。

この問題を検討した結果、再生側にも不備が発見されたが、変換機構をリバースする形で見かけ上は正常に波形が描けるように工夫を行っている。



最初に気になったのは、波形で描画されたデータに重複する箇所は一切無いのだが「波形の半分の極性が逆転して描画される」現象で、暫くの間この妙な映像に戸惑わされることになった。

pinの直接参照時に発生した問題について・続報

昨日は、GUIが妙な挙動を示す箇所を探し潰していく作業を行っているのだが、ハードウエア由来ではなくIDEに原因がありそうなバグが散見され始めており、そのポイントを見抜くための仕掛けをLED等を使った物理で行わされることになった。

先日、動作を検討して問題がなかった筈の「pinの状態を判定するコード」が、何故か特定のpinで使用不能になっているようだ。

この物理状態を反映した判定のプロセスが有効かどうかを確かめるために、また別のpinにLEDを仕込んで様子を見てみると、これが全く反応がなく、不具合の発生箇所が確定することになった。
　
コード上に近接する行を見ると、別の状態判定のコードが外された痕跡が残っていて、



そういえば何故か動作がキャンセルされるのを嫌って、別の箇所に記述をやり直したことを思い出した。

現在、Arpeggiatorと和音作成用のSpectrum表示、およびホームとなるMuteと波形表示昨日の実装を完了しているが、Spectrumのチューニングが反映されず、これから原因を特定していく。

波形表示に関しては、オシレーターからの直読みは問題ないものの、加算合成した出力はオーヴァーレベルで、これは調整を行わなければならない。

残る実装待ちは、波形合成のルーティンで、これは難物となりそうな雰囲気がしている。

Appeggiator を Sequencer からコントロールするデモ映像

あくまで概念上のデモンストレーションだが、Sequencerから送出されるデータによって、Arpeggiatorのフレーズと演奏パターンを選択している。



この機能は既に実装済のものだが、GUIと連携することによってその機能を視覚的に確認することが出来る。

本来は、Sequencerによって消費されるデータの抑制を試みた仕掛けだったのが、これが存外に使い勝手が良さそうで、データ不足の問題が解決された時点でもこの機能は生き残らせることにした。

液晶画面の表示領域が不足している問題について

240x240pixelと中途半端な画素数のLCDが抱える「表示不能な領域」を解消することができた。

処理の負荷を抑えるためにBitShiftでデータの桁合わせを行う手法は、例えば128x128pixelのOLEDを対象とする場合、12bitから7bitへのダウンサイズは、＞＞5 で問題なく行える。　が、今回使用する予定の240x240pixelの液晶を対象に8bitへのダウンサイズを行うと、液晶側で対応が出来ない16x16＝256pixel分のデータを取りこぼしてしまう。



この表示不能な領域を解消するには、12bit＝4096を17で割って近似値を出すしか無いのだが、これがテストでは何故か上手く機能しなかった。　今回の、描画機構を楽器のプログラムに組み込む機会に再度挑戦を行ってみたのだが、不思議なことに8波の描画を同時に行う負荷を掛けても問題は発生していない。



一方で、合成波の描画は未だ実行出来ていないのだが、オシレーターから直接出力されている5波形の発振は観測できている。



当初は、各オシレーターの出力波形の描画位置が完全に一致してしまうために、個別の観測を行えなかったが、描画時にy軸のレベルを操作することで、全ての波形を確認することが出来た。

この際に気になったのが、例の描画不能な領域で、開発時に１周期の描画に拘った意味がなくなってしまう。　そこで、以前は不調だったx軸方向の除算に再トライしたのだが、描画の頻度を下げることで、なんとか対応することが出来たようだ。　改良後の波形は、オフセット値をレベルシフトに合わせて設定していないので一見すると不連続な描画に見えてしまうが、波形の描画が開始される位置が一致していることが確認できる。

残された課題は、現在機能していないMIX後の出力波形の観測や、レベル検知のロックが掛かって動作が確認できないロータリーエンコーダー下側のコントロール系の試験だが、これはソフトウエア的に手当を行わずに実機に近い形にテスト環境を組まないと却って手間が掛かる案件故に、これからシステム構築の方法を模索することになる。

メモリーの配分に関して

ポット類に予期せぬ巨大なオフセット値が付加されて制御不能となるバグが発生したが、



これはメモリーを初期化出来ないDMAMEMにポットのレジスタを配置したことが原因だった。

予想していたことだが、既にRAM1のメイン・メモリが絶望的に不足していて、



グラフィック系の処理を行うことができなくなってきている。　



これがバグなのか仕様なのかは判らないのだが、GFX系の命令の総量が決まっていそうなことで、せっかく時間を掛けてデザインしたGUIのほぼ半分がボツになってしまった。



負荷が掛かるのはなにも描画だけではなく、文字列の表示もメモリーを専有するので、とにかく必要と思う項目以外のファクターを削っていく作業を強いられている。

4.1の仕様変更について

Teensy4.1では、3.6までは有効だった

#define LED0_ON　　　　(CORE_PIN22_PORTSET = (1<<8))
#define LED0_OFF　　　　(CORE_PIN22_PORTCLEAR = (1<<8))

なる「pinを直接叩く呪文」が無効になった結果、これを

#define LED0_ON　　　　digitalWriteFast(LED0, HIGH)
#define LED0_OFF　　　　digitalWriteFast(LED0, LOW)

digitalWriteFastによってpinの状態を指定する命令文に置き換える必要ができた。



なお、「pinの状態を検知する呪文」

#define button_State3 　　　　(CORE_PIN3_PINREG & (1<<5))

は引き続き有効だった。



同様にTeensyduinoでは、マニュアルに記載されたPITの制御コード

　PIT_TCTRL2 = TIE; // enable Timer 2 interrupt
　PIT_TCTRL2 |= TEN; // start Timer 2

が受け入れられず、これを

　IMXRT_PIT_CHANNELS[0].TFLG = 1;
　IMXRT_PIT_CHANNELS[0].TCTRL = PIT_TCTRL_TIE | PIT_TCTRL_TEN;

と書き直している。

確認された諸々の現象は、本家たるSDKとの連携が行われていない可能性を示唆しているのだが、どういった意図を持ってそれをやっているのか、ベータ版の開発スレッドを見ると何がしかの理由を発見できるかも知れない。

今回は、AudioClockの入力で起動されるインターラプトの動作を確認するためにサブルーチン内にカウンタで駆動するLEDを仕込もうとした結果、不具合が発覚することになったのだが、



現在開発中の描画システムをメインのプログラムに組み込む過程でバグが発生した場合、GPIOの直接制御が正常に動作していることを前提とする可能性が高い。　偶然の賜物ではあるが、無駄なデバッグの繰り返しを回避できたことを喜ぶべきなのだろう。

液晶画面を一眼レフで撮影した

一眼レフのマクロレンズを使って液晶ディスプレイの接写を行った。　

表示エリアの下側に、InputCaptureに対応するpin15/pin40に入力された信号のアップエッジをカウントした値を暫定的に表示している。　



ただし、これは音源を駆動するためのデータ幅にスケーリングされた結果の表示であって、周波数そのものを測定しているのではない。



楽器を立ち上げた時のデフォルトの操作面。　厳密には、上のエリアに緑のPitchTuneが表示される。



ワンクリックでエキサイターおよびOp3の選択を行う画面に進む。　小さな5本のバーグラフは、関数を生成するために使用するファンダメンタルから５倍音までのレベルを示す。

Op3には、ミックスを行わないオシレーター単体の音声を選択する。　準備されているチャンネルはオシレータ数5×3モードの15chで、最初のグループは単純なヴォリューム制御を行ったもの、2グループ目はTransitionの機能を振ったもの、3グループ目はExciterによって倍音構成が変換された信号が出力される。



各オシレーター出力のヴォリューム制御に、左手の位置に対応してピーク値の間隔を横に変移させる機能の概念を示している。　ただし、あくまでこれは「概念」であって、出力値そのものを反映した結果ではない。



TransitionのピークのQを選択する画面。　ピークの幅が狭い制御波形を選択すると、下のエリアがCYANになる。



DIistortion機能をオン・オフする画面。　この状態はオフられている。



Sequencerのステップ数と、オシレータの出力状態を表示している。



ChordEditモードを選択時にアドレス41番の編集アドレスを選択すると、スイッチ（下）のモード選択4番から7番にかけての操作レイヤーがチューニングノブに変化する。



画面は正確な状態ではないが、各VoiceModeに対応するArpeggiator Modeが選択されると、中央画面にピアノロールが表示される。



下のスイッチをクリックして、Arpeggiatorのスピードコントロール画面に進めた。



スイッチ（下）をワンクリックして、Arpeggiatorの演奏モード選択画面に移行する。　モードはエンコーダ（下）を廻してUp/UpDown/Down/Randomに切り替わる。



実際にはフレーズを選択するモードで、読み取ったシーケンスから自動的にステップ数が算出される。　現時点では、機能の評価のためにダミーでステップ数を入力している。



WaveMix＝波形合成のモード。　上のノブでオシレーターの波形選択とレベル設定機能を切り替える。　下側の表示エリアに各音源に設定したMixレベルが小さなバーグラフで表示されるとともに、色分けされた波形の振幅が変化する。



スイッチ（上）の9ページ目はスレッショルドの設定を行うモードで、スイッチ（下）で演奏モードを選択した場合にのみ、上の表示エリアにバーグラフが出現する。



演奏モード（スイッチ下）でミュートを選択したところ。



同じく、演奏モードでLFOを選択したところ。本来は、上のノブで速度と倍率を設定する。　



演奏モードでクロマチック・チューニングを選択したところ。

このように、綺麗な画面が撮れるのが一眼レフの真骨頂なのだが、SDカードのハンドリングが手間で、何故かMacbookに接続するとカードが死亡する案件を数回経験してしまうという困った事態に陥っている。　現状ではSDカードからデータを抽出するためにThinkpadを起動するのが非常に億劫で、ケータイが撮影の主力になってしまった理由はこの辺の不自由さにあるのだった。