LaVoixski@新たにシステム・クラッシュが発生する

安定していたシステムが、また頻繁に落っこちるようになってしまった。

今回、プログラム面の改変は一切行っておらず、波形選択プリセット#25に制御波形として登録しているリニア鋸波を設定し、それを再生し続けたことが原因と考えられる。



これをサイン波合成タイプの鋸波に登録し直した結果、



安定した状態に復帰することが出来たのだが、メモリへの制御系と音源系の同時アクセスが問題になっているのだろうか？

もしくは、フルスケールの波形を読み出そうとする際に、何かが起こるのかもしれない。

これから、リニア波1波だけを選択したプリセットをアサインして様子を見ていくが、1Hを経過した時点でトラブルは認められない。　リニア5波分のWavetableに同時アクセスする状況が問題になるのかもしれない。

追記：　1H過ぎ、言っている側から再起動が掛かってしまった。

追記２：　どうも描画関連のメモリ配分に原因が潜んでいるようで、其処をいじった場合にトラブルが発生するようだ。

例えば、この部分にvolatile型を指定した結果、数分でクラッシュに至っている。



逆にこの画像処理系の変数には何故かvolatile型が指定されていて、（記述を行った時期が違うために、型を統一していなかった）それを外した結果、1H後にクラッシュが発生している。　掘っ立て小屋特有の記述の不統一がトラブルを誘発している可能性を考えてしまうが、気付いた部分だけを統一しても問題は解決しないようだ。



現在、新たにvolatile型を指定していなかったカウンタ関連の変数を書き直してクラッシュテストを行っているところ。

追記：　01_31_22

10H以上の安定状態のあと、何故か再起動が多発する状況に陥る。

起動後に2VoiceModeに移行してMute状態にすると、ほぼ2分弱で再起動が掛かるパターンを繰り返す。

UpperEncoderのModeを「一巡させた後」にMuteを行うとクラッシュが回避できるようだが、クラッシュを誘発する原因は不明。

対症療法として、StartUpルーチンにModeを一巡させる機構を組み込んで、クラッシュの発生を抑えることが出来た。



これから追試を行っていくが、RAM1以外の場所にデータを格納する場合に発生してしまう「初期化の不徹底」が原因なのだろうか。

追記２：

またシステムクラッシュが発生したが、原因の相関性が見えてこない。　バラック構造な試作環境によって発生する「物理的な要因」が影響している可能性を考えるべきか。

LaVoixski@PhaseShifter選択時に表示するフォントの色味について

ランダム色のバックグラウンドを背景にしたPURPLE固定のフォントは視認性が悪いので、配色を反対色に変更した。



コンパイル後にRAM1のフリーメモリが若干ではあるが漸減している他、



変更・再起動後に８H余り経過した時点で「システムが落っこちた」点が不安要因なので、これから経過観察を行うことにしている。



追記：

3H後にシステムが再起動した。想像では埒が明かないのでデバッガが欲しいところだが、リソースがジリ貧でクリティカルな動作をしているシステムをデバッグモードで動作させられるかどうかはまた別の問題だ。

そして、これも想像に過ぎないのだが、現状はどのようにすればインターラプトによって描画が中断される確率を下げられるのか？問題を解いているだけなのかもしれない。

追記2：

2H後に再起動が掛かった。　いまのところ再起動のトリガーとなる原因を確定できていないが、何らかの形でJPEGの描画ルーチンが妨害された結果再起動に至る、という機序がほぼ確定している。　今回の場合はArpeggiatorのクロックが関係している可能性が考えられるが、駆動クロックは停止状態にあった。

他にトリガーの可能性として考えられるのはPITとGPTから発生するインターラプトで、DMAMEMにアサインするメモリを増量した後にトラブルが頻発しだしたことがヒントになるか。

追記3：

43分後に再起動している。メモリのヒープ領域にトラブルの原因が蓄積するのか？　今回はArpeggiatorを起動せず、起動後のほぼ素の状態でButton4をアクティヴェイトせずに２VoiceModeを選択して様子を見る。　

追記4；

4H経過後、状態は安定している。これからButton04をオンにして様子を見る。

追記5；

そろそろ1Hが経過する頃だが、問題は発生していない。　やはり、Arpeggiatorの絡みでなんらかのトリガーが引かれている可能性が高くなってきた。

追記6：

9H経過の時点で安定状態が維持されている。　MuteをPhaseShiftに切り替えて、位相の変化を確認した。VoiceModeをArppegiatorに切り替えない限り、諸々の不具合は発生しないようだ。

追記7：

不要なタイミングで頻繁に画像が更新されるArpeggiatorのMute表示は不健全なので、描画を行う対象を選択する条件分岐をより厳密に設定することにした。



元々設定していたSwitchで条件分岐を行った後に画像表示に関するパートを挿入しているので、処理全体の行程数は変更前と変わらない筈だ。　（case 3: の”Mute”に関しては、むしろ行程数が減少している）

LaVoixski@SequencerModeのStepCounterの表示を変更する

シーケンスの進行をバーグラフのアニメーションで表す機能を実装した。



StepCounterから、データを引いて、、、



バーグラフの描画を行っている。



改装の過程で、OLEDディスプレイに表示系を移植する作業を行っていたが、これが全く使い物にならないことが判明、試作機のフロントパネルに設置していたOLEDディスプレイを全て撤去して、LCDにリプレイスすることになった。

追記：　01_31_22

視認性が極端に悪いSequencialArpeggiatorの表示色MAROONをPINKに変更した。

LaVoixski@LCDのデータラインについて

MCUからLCDまでの配線距離が10cm以上になる時は、高速でデータを流すSDAとSCLを隣接させてはいけないという話題がTwitterに流れていたが、そもそもデバイスの端子がそうなるように配置されているのが物凄く間抜け。



SDAとSCLの間に電源とGNDラインを挟んでシールドにするのが簡易な混信対策として有効らしいが、実際の運用は未了。

LaVoixski@MUTE発動時にシステムが再起動に陥る問題

音源をミュートモードにすると何故かシステムが落ちる現象の再現性をチェックしているのだが、ある特定の状況で起こるそれの原因を掴むことが難しい。

負荷の軽い2VoiceMode選択時にアルペジエータを走らせた状況でMUTEを行った場合、電源投入後に9Hが経過した時点でトラブルが発生しておらず、これをイニシャルモード（ピッチ変換なし）という最も負荷の軽い状況を選択した途端にシステムが落ちてしまうことが判明している。



過去の経験から鑑みて、どうもこれは「ミュート時にJPEG画像を表示する機能」が悪さをしている可能性が高い。　

MUTE時に再起動が掛かって音が出て仕舞うのは流石にマズいので、ひとまず対策を行うことにした。　まず思い付くのはJPEG画像を表示する際のオフセットの設定で、修正前のライブラリはこのポイントにバグが潜んでいた。



とりあえずの手当として、現行設定しているオフセットのpixelを-1方向にズラした結果、暫くの間は状況が安定していたものの、2Hほど経過した後にシステムにリセットが掛かった。　

原因は不明だが、実用上は問題がないレベルなので、とりあえずは現状で様子を見ることにする。

追記：

その後、再起動を繰り返す症状が再発した。タイマの閾値をHEXで記述したり、bitReadを使ったりといろいろ試してみたが、状況が改善する兆しは感じられない。

再現性に乏しい、よく解らないタイミングでシステムが落ちる原因には、インターラプトが絡んでいる可能性がある。　それを踏まえて描画のシーケンスを割り込みを禁止する cli(); / sei(); でラップしたところ、なんとか安定状態に持ち込むことが出来た。



MUTEモードを起動して、11Hが経過しているが、いまのところシステムは安定している。　なお、PhaseShifterの機能が停止していたので、位相関係の初期化を行う必要があった。

結論は、描画中のインターラプトは禁忌で、データの転送中は割り込みを禁止にする必要がある。この設定をライブラリに組み込むのが正解かどうかは判らないが、試してみる価値はありそうだ。

追記２：

２VoiceMode選択時にシステムが再起動する案件が再発している。　再発した原因は不明。　対処法としてサブルーチンの記述場所を変更しているが、1H経過時点では安定状態を保っている。



トラブルを根本的に回避する方策として、microSDから直接JPEGファイルを読み出す方式を予めバッファに吸い上げたデータを読む形に変更を試みているが、DMAMEM/EXTMEMにバッファ領域を構築するとRAM1のメモリが破綻するという、機能の実装以前の状況に陥っている。

追記３：

SceneCaptureの設定値に関する表示を行う記述を修正した途端に「再起動」が頻発するようになった。　

JPEGの描画とは直接関係が無さそうな部位の変更から考えると面妖な反応だが、予想されるインターラプトの影響を軽減するため、プログラムの階層が一番浅いMainLoop内に条件分岐を移動する対策を採ることにした。



修正後1Hが経過した時点での動作は安定しているようだが、全く油断がならない。

追記４：

Arpeggiator選択時の映像。　Arpeggiatorをストップすると、JPEG画像の表示が固定される。



現時点で電源投入後12Hが経過しているが、システムの状態は安定している。

JPEGの描画は、処理を行うループの階層の浅いところで行うべきか。　トラブっていた時は、フリーランするMainの中のサブルーチンに入れ子になった条件分岐といった深いところから描画処理のサブルーチンを呼出していた。

今回は、処理上の最短距離を目指す観点で「合理的」と思われた配置から、見かけ上のステップが増えるものの、mainから直接描画処理のサブルーチンに飛ばすといった単純な構造にコードの配置を変更したのが正解だったのではないか。　この件に限らずトラブルが頻発する場合は、多重構造を避けるのが正解だろう。

LaVoixski@ArpeggioSequencerが読み出すStepDataのハンドリングを改善する

SequencerModeのアドレス#1と#2に割り振っている「ArpeggioをSequenceするモード」を選択した際に、LPF/PhaseShifterにアサインしたLFOのSpeedパラメータの更新が、「Arpeggiator関連の操作頁を選択した時のみに行われる」バグが発覚した。

要は、Arpeggiatorの状態を示すピアノロールが表示されている時のみに、Speedのパラメータが更新される現象で、それ以外ではArpeggiatorのstep数が反映されず、Speedはランダムな倍率で固定状態になってしまう。



Arpeggiatorの表示系にはstepを読み出す機能が仕込まれているのだが、



ピアノロールの表示を選択しない場合には、このstep数を読み出すパートが働かないことになる。

実は、リンクを張り忘れていたstep数をハンドリングするサブルーチンが存在していて、、、



これをSequencerを駆動するクロックのパートに組み込むことで、



常時データの更新を行うことが出来るようになった。

追記：

起動時にPhaseShifterが稼働しないのは、steps の初期値を ”0” に設定した結果、LFOのスピードを決定するための式、lpf_lfo2 = (arpSpdB * steps) * (pot00k * 0.001);　の値がゼロになってしまうことが原因だった。

初期値を”8”に修正することで、リセットを行わずにPhaseShifterを稼働状態に持ち込めている。



ついでに、Arpeggiatorの起動時にも steps をエントリーできるようにした。

LaVoixski@PhaseShifterの構造を決定する

本システムで採用しているPhaseShifterは、メインオシレータに追従するサブオシレータを駆動するWavetableのポインタをリセットすることで、位相差を作り出している。　



アクティヴェーションは、PitchBendModeのBendSpeedを設定するパラメータ”AtkEnv”をゼロに設定して行う。　エフェクトに関するパラメータは Interval と Speed の２つで、これらはLPF2のパラメータと共有されている。　



まず、Interval の設定はパラメータ "Lp2Lfo" = EMA_wf6b で行う。　設定値は、0.01=Continueとなっていて、あとは段階的にTriggerが発生する間隔が広がっていく。Speedは ”LfoWv2” = pot00m で倍率を設定する。



何れの項目も、LPF2本来のパラメータとは用法が異なることに注意が必要だ。

生成した波形に対してオフセットを掛けることで位相差を生み出す仕組みは、オーディオ入力に対してフィルタリングを行う通常のPhaseShifterとは概念が異なっている。　これはトリガが存在しない波形の描画システムと同じく「Wavetable方式の音源」に共通するポイントで、位相差によって発生するエフェクトはメイン＆サブのオシレータ・ペアのみを対象としている。

つまり、ミックスされた音声出力全体はエフェクトの対象外なので、5音がバラバラにチューニングされる5VoiceModeでは、(設定したチューニングのケースにもよるが)「位相差」が発生することはなく、



当然のことではあるが、位相シフトによるフィルタ効果は殆どの場合確認することができない。

一方、システムを改良する過程でRAM1の容量が厳しくなっていることが判明、これに対応するために纏まったメモリクラスタの割当をDMAMEM＝RAM2に変更した。　変更後はRAM1のフリー領域が8128まで回復している。



DMAMEMは確保したメモリ領域のリセットが出来ない仕様故に、システムが不安定になる傾向が認められるため、システムに実装された各機能を行使して「安定度」を検証しなければならないのだが、この検証を行っている過程でChordEditModeに潜んでいたバグを発見することになった。



バグは、編集したコードが正常に記憶されない症状で、その原因はEditorの改良時に変更したパラメータをmicroSDに記録を行うサブルーチンに移植し忘れていた事にあった。　サブルーチンの関連するパラメータを修正した結果、問題は解決している。

追記：

アンバランスなステレオ時の音源配置を修正した。



追記２：

PhaseShifter起動時における各Waveformグループの波形の推移を記録している。

LaVoixski@PhaseShifterの構成を考える(追記あり)

今回実装を行っているPhaseShifter=Phaserは、PitchBendModeに組み込まれた「ピッチシフトを行うタイミングを制御するトリガー」と、「エンヴェロープの継続時間を決定し、それをWavetableの読み出し機構に反映するシステム」を応用したもので、



本来は、ピッチの揺らぎを認知するに足りる時間分の出力（200msから2sec位まで）が維持されるべきエンヴェロープを「極小値」（10ms以下）に設定した状態でピッチの変位⁄復帰を行うことで、Wavetableの読み出しポイントにオフセットを掛けて、メインの音程を追従するサブオシレータの位相をシフトするという、位相制御の方法としては邪道な方式を採用している。　

位相の変化を反映するタイミング＝RATEパラメータの調整は、ピッチシフトを行うトリガー、THAR2をコントロールすることで行っているのだが、、、



トリガーの生成は、GPT2がInputCptureにより入力信号のValueを決定するタイミングと同期させている。



オーディオクロックはGPTを定期的に監視する周期を決定しているに過ぎず、RATEパラメータのデータが確定するタイミングは、あくまで外部オシレータからの入力に準拠する。

RATEのValueはLPF2のLFOと共有していて、値の更新はTHAR2と同様にGPT2から出力されたトリガーを切っ掛けに行われる



THAR2が生成されるタイミングは、LFO専用のWavetableを読み出す12bit幅のアドレスのLSBから4bit目をbitWiseすることで決定しているが、これはデータを更新する切っ掛けを作るためのトリガーに過ぎない。



PitchShiftを行う値にはLFOの出力をそのまま転用しているので、選択された波形に準ずる形でPitchShiftの変化量が決定される。



LPFの波形には8種類のWavetableがリザーブされているが、これらの波形が持つキャラクターによって、位相がシフトしていくパターンが微妙に変化する。

一方、RATEはPitchを更新するタイミングを制御するパラメータに過ぎず、周期のスピードをコントロールするという一般的な概念のものではないところに注意が必要だ。　

このシステムに於けるRATEは、極小値（スムーズ）から段階的（ステップ）に位相の変化量を決定するパラメータで、ステップ状に変化する位相からはSample&Hold的な効果が得られる。

追記：

LPFにDepthを追加した。　Modulationを掛けない状態でValueを設定するWavShpパラメータでオフセット値を設定する。



初期状態からノブを左回転させて値を加算する方法で、有効値に最も早くアクセスすることができる。

追記２：

システムの稼働開始後1時間で、PhaseShifterにロックアップが発生したが、位相のリセットを行うことよって動作が復活した。　

かなり厳しいタイミングとギリギリなメモリのリソースで処理を行っている所為で、この手のロックアップが生じている可能性が高いのだが、トラブルの発生を防止するよりも「リセット機能を充実させる」方向に設計が進んでしまっている現状を今一度認識すべきだ。　予想されるトラブルの発生を事前に防止する方策として、操作系の迷路に迷い込まないようにプリセットを充実することを考えているのだが、そのうえで「困った時はリセット」それも段階を経たリセットのシステム（最後は電源の再投入）を組むことが現時点に考え得る最適解だろう。

追記３：

ブレッドボードに回路を組んでいる「バラック状態」が原因で発生する物理系のトラブルは、無視することができない不安要素だ。既にVolumeオシレータの信号の乱れによるトラブルの発生が確認されている。　これはPhaseShifterのロックアップが発生する原因とも考えられるので、トラブルを切り分けるための試験機を早急に完成させたいところだ。

追記４：

位相が変化する周期はPitch入力の周波数に依存しているのだが、音程に比例して増加する周期のスピードが速過ぎることが判明、PhaseShifterの構造を根本的に考え直す必要が出てきた。以下、暫定ではあるが、変更点を列挙していく。

まず、bitWiseを使った条件分岐を撤廃して、トリガーをシンプルな構造に改変しつつ、、、



PitchBendを行う際の初期値を２倍に調整し、、、



PitchBendを行うサブルーチン EG(); をAudioClockのタイミングで更新するように構造を変更した。

結果、周期の速さをある程度は修正することができたが、今度は低音域の周期が長くなり過ぎたきらいがある。

やはり、周期を一定に保つためには入力された周波数とPitchBendの初期値が逆比例するような構造を導入した方が良いのだが、最適値を割り出すにはしばらく時間が掛かりそうだ。

追記5：

とりあえず、入力周波数の影響を排除できるようにコードを書き換えた。



問題は除算で、Arduinoは小数点以下の計算が反映されない。　解決策として、整数で除算を行った後に小数点以下の乗算を実行することで、なんとか結果を代入することが出来た。



これらの作業によって入力周波数の軛から逃れられた訳だが、副産物としてSpeedのパラメータを実装することが可能になった。　パラメータを追加するには新たにロータリーエンコーダの割り振りを考えなければならないが、既にメモリの使用量が限界なのが、苦しいところだ。



追記６：

やはりシュワンシュワンさせたいPhaserには「Speedの設定が不可欠」ということで、機能を追加した。



スピードを設定するパラメータには、LFOの波形選択にリザーヴされたものを流用している。

LaVoixski@Arpeggiator用GUIの変更／PhaseShifterのパラメータを操作する

PhaseShifter選択時のGUIは、色味の雰囲気がイマイチだったのでランダムな配色が行われるように変更しているが、



視認性はいまひとつといったところか。

PhaseShifterのRateControlパラメータは、LPF2とLFOを共有しているために、LPF2のアクティベーションが必要＝同時稼働が前提となっていたが、この仕様が予想以上に遣い難いことが判った。　そこで、LPF2のアクティベーションを行う条件分岐からLFOを独立させて「常時稼働状態」にすることで、PhaseShifterとLPF2を別々に運用することが可能になった。



また、各パラメータへのアクセスが、トップに配置したプッシュスイッチと、Volumeに設定した閾値を同時に”オン”の状態にしないと行えない仕様がこれまた使い難いものだったので、この条件分岐をArpeggiator/Sequencerのアクティベーションに限定し、



他のパラメータへのアクセスをフリーで行えるように、システムを改変した。　Threshold設定モードに関しては、VolumeAnt側のValueを参照して動作点を決める構造なので、Arpeggiatorと同様の扱いとした。

プッシュスイッチで行っていたシーンメモリの呼び出しは、システムの立ち上がり時に自動的に行われるように変更、



メモリの再呼び出しは、暫定的に目玉スイッチのクリック＝位相のリセットと同時に行うことにしているが、別に専用のスイッチを設置したほうが良いかもしれない。

LaVoixski@PhaseShifterの実装

機能の実装は、PitchBendModeの為に製作したEnvelopeGeneratorのサブルーチン内に行っている。



位相を変化させる構造は、基音に対して極微小なピッチシフトを基音に追従するオシレータに行うことで実現している。　ピッチシフトは、LFO2から生成されるValueを流用しているので、RateはLFO2の設定に依存する。



PhaseShifterの起動は、PitchBendMode選択時にパラメータAtkEnvを”ゼロ”に設定することで行う。　

例に示した条件分岐により、位相の変化を励起するパルスを生成している。　システムの構造上、どうしても「段」が付いてしまうのが難点だが、LFOのRateを落とすことで、逆にそれを効果的に使ってS/Hっぽいエフェクトを掛けることが出来る。



映像を記録している途中で「Arpeggiator周りのGUI」があまりに使い難いことが判明したので、下側に配置した表示エリアの背景色を、現在選択しているエフェクトに関連する色味を表示するように、改良を行った。

追記：

Arpeggiatorのスピード設定にPhaserのRATEが依存する影響で、セッティングのメソッドがトリッキーになっているようで、特にChoppingArpeggiator使用時に可動領域が大幅にズレることが判明している。

LaVoixski@位相のズレを補正する

単音設定が可能な2VoiceModeの選択時に、PitchBendや和音・アルペジエータを演奏することで発生する「位相のズレ」を可視化した。



波形の位相がズレるのは、サブオシレータがメインオシレータと異なるピッチを選択した結果、各オシレータがWavetableを読み出すポインタの開始点に差異が生じてしまうことが原因で、



それを回避するためには各オシレータに配置されたWavetableが「読み出しを開始するアドレス」を強制的に一致させる必要がある。



今回採用した機能は自動的に同期を行うものではなく、ButtonPin03のシングルクリックによる任意のタイミングでポインタのアドレスをメインと同化させる設定だが、予期しない位相の変化を好まない場合は、2VoiceModeのアドレス＃1を選択すると同時に、リセットが行われる機構を組み込んだほうがよいかもしれない。

ついでに、ベンドの概念が逆になっていた(ベンド・アップでピッチを合わせるハーモナイズド・チョーキングはギターのテクニック/ベンド・ダウンでピッチを合わせるグライドはシンセサイザーの効果)PitchBendModeの表示を入れ替えておいた。



赤を”UP”、



緑を”DOWN”に表記の修正を行っている。

LaVoixski@周波数モニタの調整を行う

周波数レンジの設定が適当だったチューニング機構の調整を行った。

今回周波数の計数に使用しているGPTは32bit幅なので、低域のピックアップ時に解像度が落ちることが無くなった。　調整機構には実際の周波数レンジに対応した手当が必要となるが、現在設定しているレンジは測定器からの入力を確認するための暫定値となっている。



キャプチャが可能な周波数を測定した結果、上は余裕で８kHzを超えていたが、



実際に使用するVCOの周波数が変化するカーヴはリニアではなく、直線性の高い部分を切り取って使用するアレンジが必要となってくる。

LaVoixski@Mute端子の設定を行う

基板上で既に配線を行っていたチップのMUTEpinを制御する機能を、





ようやくソフトウエアに実装した。



一方、DACの出力を受けるOpAmpのバイアス電圧を制御するために実装したアナログスイッチは、現時点で3pの切り替え運用を想定しているが、



これを並列4個のスイッチをペアで運用する方式に取替える案がある。　



3pスイッチによるアナログ出力モードの切り替えは、開発当初モノラル運用を前提に考えていた名残だが、ステレオ運用に設計の方向性を転換するにあたり、回路の構成を再検討する必要が出てきた。



現行の回路は実験の結果導き出された構成だが、MCU側で整理する筈のスイッチの運用が、ポートの不足により困難となった状況からもたらされた折衷案でもあった。　その後、開発の過程に於いてDACの構成が変わり、LEDの駆動がPWMに合理化された結果、ポートに余裕が出来たので、これを期に不整合を解消する方法を考えることにした。

例えば、スイッチのグループを音声トラック毎にまとめる or 機能別にまとめるかで、スイッチの選択が変わってくる。　理想はスイッチの制御ポートを独立させることだが、そこでまたMCU側のポートが不足する問題が立ち上がってしまう。

基板のスペースに余裕がある場合はジャンパによる選択に逃げられるのだが、ID-292ヴァージョンのような実装面積が高い基板の場合にはそれも出来ない。

当面はダイオードを挿入する為にリザーブされたポイントを使ってバイアス・ラインに接続されたSW3/4の配線を入れ替えた後に



SW1/4 ＆ SW2/3 と制御端子の配線を変更することで、音声トラック毎にスイッチをまとめたグループを運用することになるだろう。

ただし、実用性を考慮した場合、バイアス・シフトとアッテネーターの機能別にグループを分けた方が折衷案としては正解で、、、



スイッチの極性が同一に設定されているMAX4652等にデバイスを変更した後、SW1/SW2 ＆ SW3/SW4 のグループにまとめて制御を行なうことを考えている。

LaVoixski@謎の信号漏れについて

気になるピークノイズの由来がLCDなのか、測定器の影響（測定環境を変えるとピークがズレる）なのか、いまのところ判明していないのだが、



小さいながらも5kHzを超えた辺りのキーンという音が気になっている。



ピークの周波数に変調が掛からないことから、PWM独特のノイズではないと思われる。



測定を行なう周波数帯の設定を変更すると、ピークの位置がズレたり消滅したりする現象が認められる。



何れもミュート時に観測される信号漏れで、この他に小さな音でミュートした筈のメイン出力が聞こえている。



ミュート時の音漏れは、DACのソフトミュート機能をリンクすることで解決できそうだ。

LaVoixski@偶数次倍音を加算合成した波形と、リニアな波形の音質の違い

この音源では、各種制御を行う為の波形の参照先としてWavetableを使用しているが、12bit幅のリニアな波形とOcvaveによって高調波を合成されたSawToothでは挙動がかなり異なってくる。

今回スポットを当てたのは、判り易く音質という観点から行う比較だが、



再生システムの性能によって、大きく印象が異なってくることに留意すべきか。



SDカードに収録しているSawTooth波形は、以下に示すコードで生成している。



計算した出力をプロットしたもの。リニアな波形とは違って、アドレスの末端に於ける「データの飛躍」が発生しない点が特徴だ。



本来、リニア波に期待される役割には、LFOの制御波形の他にchebyshev変換を行う場合に参照する基本波の2点があり、後者に於いては視覚的に出力波形の予想を行うことが出来る。