LaVoixski@Pitch/Volume Value に絶対値を設定する

Pitch/Volume Detector から出力された負の数値によってクラッシュを含めた不具合が発生する状況を改善するため、Value を絶対値に加工することにした。







あと、Sequencer Mode の先頭に配置した Sequencial Arpeggiator の駆動時に、Sequence のループポイントに差し掛かるタイミングで、システムクラッシュが発生することが判明している。

ただし、クラッシュが発生する頻度はまちまちで、トラブルを予測することは難しいが、何れも破綻が発生するポイントは共通している。　試行錯誤の結果、クラッシュを回避する手段として AutoFade Mode に逃げる方法を探り出したがこれは根本的な解決には繋がらず、引き続き原因を探っていくほかはない。

クラッシュの原因を調査していく過程で「データ型の統一」を対症療法として思い付き、関連する変数を int 型に書き換えているが、結果は芳しくない。







クラッシュが発生するケースで明らかになっているのは、SequencerMode に於いて特定のアドレスを指定した場合で、クラッシュを引き起こす直接の原因は「負の数値」をデータアレイに入力した場合が考えられる。　つまり、可能性として間接的な原因を「メモリ管理の破綻」と考えているのだが、これはあくまでも想像であり、原因の特定は未了である。

追記：

SequencerMode の 2nd Address 選択後に AutoFadeMode で固定して数時間あまり通電を継続した結果、クラッシュは発生しなかった。　やはり、特定の機能を割振ったアドレスを選択した場合に不具合が発生するようだ。

クラッシュの発生に Sequencer を駆動するクロックが関与している可能性を確かめるために、トラブルが頻発しているアドレスでシーケンスを停止した状態で監視を行っている。



シーケンスを停止する前に10分間の動的運用を行ってみたが、問題は生じなかった。　ただし、安定した状態からいきなりシステムが落ちて再起動が行われるパターンを何回か経験しているので、この結果に安心することは出来ない。

LaVoixski@Teensyduinoの新しいヴァージョンとの互換性

結論から書くと、何をやってもダメだった。

まず、OSX 環境では OS のヴァージョンが低すぎることを指摘されてコンパイルを跳ねられた。　次に、制限がほぼ無い Windows 環境に VM を介してスイッチするも、今度はメモリ管理が破綻してコンパイルが通らない。　しかも「メモリが足りない」とダメ出ししてくれるのはオプティマイズを SmallestCode に選択したときのみで、他は完全に門前払いだった。



Paddingでこれだけの量が消費された例を見たことがないが、解決法が判らず完全にお手上げ状態となっている。

さて、メモリの消費で考えられるのは変数の割当をしくじっているケースで、



やたらと int を多用しているのがダメな感じだ。



そこで、int 型のデータを int8_t や int16_t に書き換えて、少しでもメモリの消費を減らすことにしたのだが、これらは一例に過ぎず、、、









無頓着に int 型に設定していた部分の修正にかなりの時間を費やされることになった。

昨日は、これらの変数を可能な限り書き換える作業を行っていたのだが、何故か map が機能しなくなる事象が発生した。



現れた症状は「波形の描画中に発生するフリッカ」で、座標のレンジを map で再設定したはずが、何故か周期的に map を行う前の元データが上書きされてしまい、結果として描画の乱れが生じていた。

この問題は、map の受け専用に新たにバッファを追加して解決できたが、他にもメモリの破綻を誘発する案件がチョロチョロ出てきていて、それは主に画像関連の処理に発生していた。　

結局、各所に点在する map にバッファを追加しつつ、描画を行う順番を整理する対症療法をおこなったのだが、この RAM1に関する妙な仕様はなんとかならないものだろうか。

LaVoixski@LCDのライブラリに手を入れる

LCDのライブラリをいじった結果、多少は描画の速度を稼げたかもしれない。



コンパイル時にIDEが考え込んでいたことから、何らかの変化が発生している可能性が高い。　実際、メモリのPaddingの消費に若干の変化が認められる。



(USE_FAST_PINIO)で最適なオプションが選択される可能性が高いが、一応ダメ押しで digitalWriteFast を記述している。



とりあえず、Clockを倍の80000000に上げたものの、これも有効化されるかどうかは判らない。



変更後LCDに生じた変化として、波形の描画が以前よりもスムーズに行えている反面、フォントのチラつきが気になった。



他の目立った変化としては、MUTEモードを選択した時に発生していたLCD下側の表示領域に発生していたフリッカが解消されている。



画像を撮影した際に気付いたことは、リドローと撮影のタイミングが外れて撮り逸れが発生する頻度が低下したことで、波形表示の追従性が改善された結果、撮影時に波形表示エリアがブラック・アウトするケースが殆どなくなった。



残念ながらテキストのフリッカが認められるが、実用上は問題がないレベルだった。



SequencerModeは表示のレイヤーが多く撮影が難しいケースだが、今回は一発で撮ることが出来た。



これはリフレッシュレートの上昇を示唆している。

すこし見難いが動画ではこんな雰囲気で、波形の追従性が改善されていた。

LaVoixski@Pitch/VolumeDetector周りのコードを改修した

前々から違和感があった Pitch/Volume ディテクターと波形読み出しのタイミングの誤差を修正するパートの間違いを正した。





ディテクターがオシレータ間の周波数を検知するタイミングは、オーディオクロックによってトリガされる波形読み出しの周期とは相関が無く、取り込まれたピッチのデータには微妙に段差が発生してしまう。　



この段差を取り除くために、ディテクターが周波数の数値を取り込んだ結果の差分を、InputCapture が発動した間隔分のオーディオクロックのカウント分で徐々に埋めていく手法を採っているのだが、





大元となるピッチ・データの更新場所を間違っていたために、固定した状態のピッチにバウンシングが発生していた。

修正後は、ピッチを固定した時の安定度が格段に向上したことが認められた。



プログラムを改正したあとの Pitch / Volume Value の安定度とレスポンスはこんな感じになっている。



追記：

ピッチが正確な Sequencer をガイドに演奏した場合。



これは、純粋な技量の問題になるが、固定ピッチなSequencerと演奏パートの音程の比較が容易に成されてしまう厳しさを感じた。

LaVoixski@Ritardandoの改装など

実行時に唐突感のあったSequencerModeのRitardando関連のコードを、緩やかにテンポのコントロールが行えるように修正した。



当初はタスクの軽い計算式 * 0.5 を追加したが、結果 RAM1 のマネージメントが破綻した。　試しにタスクが重い筈な除算 / 2 を試しに記述したところ、何故かコンパイルが通ってしまったのが謎だ。　乗算は、スピードが速くなる反面メモリを喰ってしまう処理なのかもしれない。

次に、待機状態から演奏状態に移行する過程で何故かピッチが変動してしまうアナログ・オシレータの挙動を観測した結果、オシレータの励起状態によって周波数に変動が発生することが判明しているが、これを解消する方法を探っている。



とりあえずドリフトを軽減する処置としては、待機時に「演奏を行うであろう中心周波数辺り」で発振周波数を固定する方法が考えられる。　具体的には、アースラインをアンテナの直近に配置した。

アンテナ基部にグランド電位のプレートを固定することで影響を軽減する方法を考えたが、発振周波数を演奏可能な帯域に調整した時点でその効果は無効になりそうだ。それよりも、待機時にグランドラインを近接させる仕掛けを作った方が効果が得られそうだ。

最後に、リモートコントロール対応のオフセット値を付加するパラメータ lowerPlusMinus を、muteSwitch に追加した。



これで、mode4 で他の操作モードを選択している時でも、デフォルト配置なエフェクトとミュートの選択モードにアクセスすることが出来るようになる（筈だ）。

既に実装している upperPlusMinus は、Voicing の切り替えに対応させているが、何れのスイッチも長押しでオフセット値がゼロに戻るように設定している。

LaVoixski@昨日のギグから得られたフィードバック

昨日のギグから得られたフィードバックその1。

フリーな環境でライヴ演奏を行って得られたフィードバックのひとつは、LCD表示の視認性の問題で、出来れば外部に補助的なデバイスが欲しくなった。

現状は、普通にSPIを使ってLCDに接続しているのだが、間にESP3系等のライトな描画システムを仲介して、端末を製作することは出来ないものだろうか。

フィードバックその２。

Pitch/Volumeのセンシングが不安定だったので、其処を改良した。



変更の内容は、Pitch/Volume共に扱うレンジを現状の12bitから13bitに拡大し、データをWavetableに引渡す手前の最終段階で12bitに丸めることによって、常用する音域のデータがフラついてしまう現象を軽減している。



ただし、これでもまだ低音域の状態が不安定に感じるので、低音域の演奏を重視するチューニングを行う場合は、Wavetableのアドレスを12bitから13bitに増やす根本的な手当が必要になるだろう。

LaVoixski@無効化されていたSequencerModeのRitardandoを復活させる

Sequencer の Ritardando が無効化されている状態を発見したので、コードを精査して機能の有効化を行った。

今回の作業では、複数のサブルーチンに点在していた Ritardando 関連のコードをサブルーチン flag_vol に集約して、より簡易に再設定が行えるようにしている。





複数存在していた条件分岐を集約した結果、RAM1 に発生するマネージメントの破綻を回避することができた。

追記：

EMAの係数を帯域分割でスイッチするパートのチューニングを行っている。





ノイズサプレッション効果と反応速度はトレード・オフの関係で、これは折衷することになる。

LaVoixski@Sequencer/Arpeggiatorのクロックが死亡する現象への対応を考える

Sequencer/Arpeggiator の "step" を駆動するクロックが死亡する現象は、VolumeValue の OverFloor によって誘発されることが判明している。　

まず、データの OverFloor を防止するには VolumeValue に付加するオフセット値をマイナス側に振る手法が現実的で、設定次第である程度の防止効果が期待できる。



実際の運用で問題となってくるのは、温度変化等による周波数ドリフトが原因でクロックが死亡してしまったとき、常態に復帰するための手段の確保だ。

本システムに実装した Sequencer/Arpeggiator の駆動は ”Chrono” で行っているが、何らかの原因によって Chrono の再スタートが阻害された結果、"step" の加減算がストップしてしまうようだ。



Chrono が動作不能に陥る原因は不明だが、要は再起動を行えばよさそうな話なので、ScineMemory をリコールするタイミングで Chrono の再スタートを行うようにコードを改変した。



Button2（目玉）の Click が該当するスイッチで、ここに Chrono.restart(); を追記した結果、問題は解決できた。

追記：

SequenerMode 演奏を行う場合に、Pitch/Volume に設定した EMA filter の効きが深過ぎた場合に発生するポルタメント効果の影響で、タイトなタイミングで演奏を出来ないことが判った。　

対応策として、Pitch ディテクタの初段に設置したシングル仕様の EMA の２重化を行いつつ、



EMA の設定値を再調整した。



初段フィルタの設定を 0.016 → 0.011 と、一見するとフィルターの掛かりが深くなる方向に調整を行っているが、二重化されたフィルターの特性が急峻になっているのと、加工する元データのダイナミックレンジが広いため、変更によって生じた効果は相殺されずに若干のスピードアップにつながっている。

なお、今回の改変に伴い、EMA の選択肢を

1：折衷モード、ちょい速め　：デフォルト値
2：折衷モード、ちょい遅め
3：ピッチの安定度重視　　　：ポルタメントの発生を許容
4：ピッチの反応スピード重視：クロマチックモードに対応

に変更した。

LaVoixski@VolumeValueの最大値を入力した瞬間に、Arpeggiator/Sequencerのクロックが停止するバグについて

SequencerMode を選択したときに MUTE を行うとそれ以降 Arpeggiator/Sequencer のクロックが停止してしまうバグが発覚したのだが、原因が判らない。

とりあえず思い付いた対症療法として、未登録だったOneButton3/4のtickをPITに追加したところ、



今度はヴォイシングがおかしくなった。

原因は、コードを選択するアドレスに付加したオフセットにありそうなので、ボタンの割当を変更し、



単純な増減を行う構造に変更したところ、ヴォイシングに発生したバグの発生を回避できたようだが、クロックが停止する問題は解決出来ていない。

その後行った調査の結果、どうやら Ritardando を起動する領域でクロックが停止するようだ。　





直接的な原因はデータのオーバーフローによるもので、Volume Value の最大化時に混入するノイズの影響と判明している。

発生したノイズを除去する方法としてはフィルターの調整が正道ではあるが、レスポンスの問題が絡んでくるためにその選択が難しい。

そこで、2重化した EMA の導入を行うことにした。　現状では RAM1 のマネージメントがギリギリなので、作動が可能なレベルまで、使用している RAM1 のダイエットを行わなければならない。

今回行った対策は、EMA の導入箇所を既に配置済な Envelope を記録した Wavetable のアドレスを読み出すポイントに加えて、



Volume Value から 12bit のアドレスを生成するポイントに追加を行いつつ、



不要な EMA の設定を排除することで、



なんとか RAM1 の消費の辻褄を合わせることが出来た。

多重化した EMA の効果は絶大で、懸案だった「グリッチの発生」をほぼ抑えている。　レスポンスの調整に関しては、今後テストを通して検討を行っていく。

追記：

時間の経過と供にエラーが発生したことから、一面的ではあるがトラブルが発生する原因はデータのレンジの問題である可能性が高くなった。　とりあえずレンジを縮小することで対応したところ、エラーの発生はなくなっている。



追記２：

実験の結果、倍率は X1 となった。　あとは、Volume のデフォルト値の設定と用法でトラブルをキャンセルすることになりそう。



EMA の反応速度は 4 種類の選択が可能だが、ピッチの安定度とトラッキングに要するスピードはトレードオフの関係にある。　特に速いパッセージの演奏に対応する最適値の設定が難しい。　現状のセッティングは、、、

1：折衷モード、ちょい遅め
2：ピッチの安定度重視
3：折衷モード、ちょい速め
4：ピッチの反応スピード重視

となっている。　Sequencer/ChromaticMode 選択時は "4" の遣い勝手がよいので、このモードは”４”固定としてもよいだろう。

LaVoixski@LPFを2次化する

過去に参照したこのサイトの記事を参考に、効きがいまひとつだった LPF をの構成を2次化した。



RAM1 の破綻を回避するために、フィルターの2次化を行うのは LPF1/2 のみとし、LPF3/4 及び HPF は従来のまま変更は行っていない。



ついでに、Pitch や Volume ディテクタに強化型 EMA を実装しようと試みたのだが、、、



予想通りメモリ管理の破綻が発生してコンパイルが通らない。　メモリのマージンを確保するためにサブルーチンに掛けていた "FASTRUN" を全て外すことで、なんとか EMA をリプレイスすることが出来たものの、何故か Pitch が安定しない現象が発生、残念ながらディテクタに関する改良は見送ることになった。

MCUのクロックアップは 912MHz が限界で、それ以上の周波数ではスタートアップ時にフリーズに陥ることが判明している。

追記：

Sequencerの仕様変更に表示を合わせるのを忘れていたので、これを修正した。





追記２：

Pitch 揺れの発生は、EMAの肩特性が急峻になっていることを忘れて「設定値をそのままにしていたこと」が原因と判明、設定値を調整する（フィルターの効きを強くする）対処を行ったところ、問題を解決することができた。



flat_pitch や flag_volume の動作を調整するEMA群の初期値を case1: と一致させておく必要がある。





今回は、EMAフィルタの構成を減らすことで、RAM1の破綻を回避している。



追記３；

件のサイトの例に倣ってEMAをFunction化した。



なお、Pitchのコントロールが効かなくなることを確認した後に、データ型を int から float に書き換えている。

LaVoixski@ボディーアースを試す

音程は非接地時より安定したものの、シャックリは止まらず。

あと、演奏技術そのものにも問題が、、、。

次に、音域のレンジが広い楽曲を演奏してみたが、、、



低域の操作性と安定度が明らかに増していて、ボディーアースの有効性を再確認できた。

LaVoixski@オシレータの調整について

不調な Type_AN/PRC-6 に関連する回路のチェック項目を示す。
　
オーディオの音声ラインはこの辺りか、隣の回路に不具合がありそう。



OSC 基板は、調整が効かない Pitch 側のリファレンス用オシレータに問題がある。





実装しているオーディオ基板と OSC 基板は、共に設計が旧いタイプなので CAD からの映像とはラインが微妙に異なっているのだが、基本的な構造はほぼ変わっていない。







Type_AN/PRC6 は、アンテナの中継ポイントが多い構造の所為で、オシレータの特性が読み難いのだが、、、







そもそもが、オシレータそのものの調整にも問題を抱えていて、それはアンテナが折損した場合の対処である。



現用しているアンテナは特性のバラツキが大きく、それはオシレータ側の調整にも影響していて、代替品による交換が難しい。　これは、アンテナ側にある程度の調整機能を持たせることで対処できそうなのだが、これから有効な機構を考えていかなければならない。

つまり、現在使用しているGFRP製なガイシの規格化が急務だが、これは何処かに製造を外注すべきかもしれない。

例えば、アルミパイプのインナーに半分割したガラスエポキシの円筒を内装して、パイプの外から圧を掛けることで部材を固定する方式を思い付いたのだが、アルミパイプに切ったネジ穴の強度が問題で、パイプの肉厚は最低でも3mmは欲しい。

他に、GFRP製ガイシのSMA端子側にネジを切ったパイプを圧入する手法が有効そうで、バラついていた静電容量が安定するかもしれない。　アンテナ側にも、同様の手法で加工を行うことで、接続を確実に行えるようになるだろう。

LaVoixski@Type_AN/PRC-6で障害が散発する

回路を実装したAN/PRC-6に通電したところ、電源がショートモードに突入してしまった。

試しにオーディオボードを分離して電源を投入した結果、MCU基板の健全が確認できた。　どうやら新設計のオーディオ基板に問題が発生している可能性が高くなったが、念の為に MCU の USB 入力端子を中継するコネクタを外した状態で通電を行った結果、システムの立ち上がりを確認できた。



つまり、ショートの原因は自作した USB の中継ケーブルにあったのだが、問題はこれで解決されることはなく、電源投入時に「アンテナの接続を行わない状態」で、アンテナ入力と中継機を SMA ケーブルで繋いだ場合に、システムが立ち上がらないことが判明、また、「中継機にアンテナを繋いだ瞬間」にシステムがクラッシュてしまう現象が発覚している。

システムは、SMA ケーブルを取り外し、中継機毎アンテナを分離した状態で電源を再投入する手法で復活する。　ちなみに、オシレータ基板とMCU基板はピギーバックの状態で直結された状態なので、電源容量の不足により生じた問題では無いと思われる。

AN/PRC-6タイプのアナログ信号系の設計は、修正前の過渡期の故にレベルシフターの極性を判定する構造に混乱が生じている。　回路の働きは実機で確かめることになるのだが、現時点では音声出力が確認出来ておらず、まずはシステムクラッシュの原因を精査することから始めなければならない。

追記：

自作のUSBケーブルのジャックそれ自体に問題があったようで、



ケーブルを取り払ったあとにラップトップからのプラグを挿入した途端にアラートが出た。

追記２：

何故かスイッチの状態を反映する筈のLEDの点灯極性が逆で、これを修正しようと色々と手を尽くしたのがどうやっても反転しない問題でスタックしている。　



GPIOを直接叩いても極性が反転しないのは異常な状況だ。

追記３：

オーディオ・ボードの検証に関しては、あまり使わない機能故に当初は運用の方法を忘れていた「オーディオ出力のオートフェード機能」を実装していたのが助かっている。　アンテナを接続しない状態でPitchノブを使って音程を操作した結果、音声の出力を確認できた。　ただ、VCOの信号が漏れ出して聞こえているのが問題で、不要な音声が混入する経路を精査する必要がある。

追記４：

state4 を反転させるコードの位置を後ろに持ってくることで、LEDが点灯する極性を修正することが出来た。



追記５：

Pitch側がアウトレンジでお話にならず、何故かリファレンスの調整が効かない。　Volume側はリファレンスが低い方にズレていて、こちらも調整の必要あり。



オーディオ・アウトは 2nd ch が不調で、残りの 3ch は出力できている。　フロントパネルを強く押し込むと妙な発振が発生するのが謎。

なお、DAC1ch辺りのチェックポイントはこのライン上となる。



表面実装タイプの電解コンは実装に失敗することがあるので、其処を重点的に調査する予定。

LaVoixski@HPFを追加する

簡易なHighPassFilterを追加した。　



設置場所に悩んだが、BIAS_SHIFTの頁をスイッチから選択方式に変更して、機能を割当ている。



HPFの構造は単純で、無加工の音声データとLPF出力の差分を出して低域を減衰させる方式で、効果は薄いものの処理の負荷は軽く、それなりに動作する。　　HPFの特性は高域の入力時にクリップが発生しない範囲で最適化を行っている。　　

システムの構造上、低域方向の調整機能が限定されているため、実質的には「ラジオヴォイス」的な用法を目的とした固定フィルタとなっている。



操作系では、まずロータリーエンコーダの機能をスイッチからセレクタに変更し、、、



スイッチの構造もセレクタ方式に、、、



LEDの配色もセレクタに合わせて、項目を増やす。



文字の配列を調整して、修正は終了。



デジタルのクリップは嫌らしい音色なので極力発生させない方向でチューンを行っているが、その分だけ効果が薄味になってしまう点が悩み処だ。

追記：

HPFの導入に合わせて、15/29~32ch で固定していたレベルシフタの構成を切替方式に修正した。



追記２：

記録から漏れているが、LPF のモジュレーションをオンにすると、ディレイに AM 変調が掛かって面白いことになっていた。

あと、ディレイタイムの倍率設定と PhaseShifter の Rate 設定にミスマッチが発生することが判明したので、出来るだけそれを解消する方向でパラメータのハンドリングを折衷した。



追記：

整数のみに作用するmapに合わせてレンジの設定が正常に行われるように、コードを修正した。



これで、HPF選択時にオーヴァーレンジで音がブッ飛ぶ現象をある程度は回避できるようになった。

LaVoixski@AN/PRC-6型筐体の組み立て

とりあえず、MCUとLCDの動作を確認した。



LEDはインバータを介してドライヴしているので、発色の極性を反転する必要がある。



また、ID-292とは基板の配線が異なっているため、ソフトウエア側で修正を行っている。



LCDの配線はCSとRSTの交差が必要で、これはライブラリを書換えずにリボンケーブル側で対処を行った。



他のID-292版との変更点は以下の通り。











追記：

照光プッシュスイッチのLEDへの直結配線は発色のバランスが悪く、緑が強すぎる。



スイッチに至るリボンケーブルに抵抗を挿入して、LEDの輝度を合わせなければならない。

LaVoixski@ディレイの実装を行う

全出力chにディレイの実装を行った。　パラメータは暫定でLFO2と共有させている。



まず、EXTMEMに遅延素子として使用するデータ領域の確保を行う。　今回は 32bit × 65536 サイズのデータ・アレイを4つリザーブしている。



データ・アレイのアドレスは、オーディオ・クロックと同期した "timer" で指定している。　Delay Time を決定する数値は、Arpeggiator のパラメータ arpSpd から流用し、pot00m により倍率を決定する。　ディレイの最小単位は、「揺らぎを与える」目的もあってデータ・アレイのフルスケール 1/1000 ≒ 65 と大まかに設定しているが、いまのところ使用上の違和感は殆ど感じられていない。　正確な時間の精度に拘るのであれば、"65" から "44" もしくは "48" に数値を調整すればよいだろう。



データ・アレイのアドレスを「マイナスの数値」で指定した場合に、システム・クラッシュが発生して再起動に至ることが判明している。 　"timer" は32bit 幅なので、読み出しアドレスに入力する データの幅を & 0x0ffff により "16bit" に制限する必要がある。



Delay Feedback は、音の濁りを避けるために L/R を襷掛けに信号を分配している。



追記：

Ritardando の発動時に DelayTime が変動してノイズが発生する問題は、Ritardando が発動しないデフォルトの Tempo = arpSpdB を代入することで防止することが出来た。



なお、この問題は Delay Time に Modulation を掛ける Flanger や Chorus を実現する上でフィックスすべき課題でもある。

追記２：

DelayのフィードバックループにAM変調を掛けるエフェクト。

LaVoixski@ミュート→ピアニッシモ時の音量制御について

ゼロ・ヴォリューム → ピアニッシモ時の音漏れ対策として、DACにデータを出力する手前に再度フルスケールを”１”に加工した VolumeValue を乗算した結果、弱音ながら唐突に出力されていた信号を完全にマスキングすることが出来た。



総合出力にVolumeValueを掛ける手法のヒントは既に得ていたのだが、、、



メモリ管理の失敗からRAM1の配分が破綻したために、今日までこれを実現することが出来なかった。

追記：

ついでに、一部のプリセット(固定)音源に発生していたオーヴァーレベルの修正を行った。



追記２：

DMAMEMへのメモリ配分の変更を行う過程で、何故かDMAMEMよりもアクセスタイムが遅い筈のEXTMEMにメモリ・アレイを分配した方が動作が安定してしまうという謎な案件が発生している。



追記３：

Octave を起動して、Envelope 専用の Wavetable 生成プログラムを記述した。

LaVoixski@Arpeggiatorのバグを解消する

Arpeggiatorの Up/Down Mode に潜んでいたバグを修正した。



UP/DOWNの演奏パターンの不具合を解消しつつ、表示系の不一致点を洗い出して対策を行っている。

まず、Arpeggiator にリセット機能を追加し、、、



TopSwitch の DoubleClick に発動条件を組み込んだ。



Up/Down Mode 選択時に発音するノートの両端が重複してしまうバグを発見、該当する箇所に修正を行った。

ノートが重複して発音されるバグの原因は、昇降時のリミッターの設定値にあった。 　設定値の修正により、Up/Down Mode 選択時の Step 数の合計は (Step x 2) - 2 となった。



Step 数の変更に合わせて、Step 数を表示系にハンドリングするコードの修正を行っている。



Arpeggiator が選択したフレーズの概要を確認する表示系のコードにも修正を施した。



表示が不正確だったカーソルの位置を修正するために、Up/Down Mode の選択を条件分岐で判定する機構を追加した。



今回は、修正・追加したファイルが 6枚に至る、最近では中規模な改装となった。

LaVoixski@PWMの発振周波数が音声に与える影響について

LPFにModulationを掛けた時にノイズが発生することが判明した。　PWMを駆動するために発動されたインターラプトの頻度が音声に影響を与えているようだ。

制御波形 (LFO) のエッジの部分で出音にノイズが出現するパターンは、グリッチと似ている。

原因として考えられるのはPWMに行った可聴帯域外への発振周波数の変更しか思い付けず、周波数をより低い値に再設定して様子をみることになった。

まず、オリジナルの設定から周波数設定値の逆算を行った結果、16bitフルスケールの65535に設定した場合の発振周波数は約2289kHz、また、発振周波数を20kHzに設定する場合の数値は7499となった。

ちなみに、トラブル発生時に設定していた数値 4000 に対応する周波数は約37.5kHzで、これは流石にオーヴァースペックが過ぎた。

数値を変更しながら試験を行った結果、20KHz ≒ 7500 では完全にノイズが解消されず、倍の設定値 8000 から漸増した結果、最終的には設定値 10000 ≒ 15kHz で折衷することになった。



PWMから放射されるノイズに関しては、DACを物理的に分離することで逃げられるのだが、ID-292のようにギリギリの実装を行っている場合は別のアプローチを探さなければならなかった。

ソフトウエア側でハードウエアの処理能力と折衷できるポイントを探す一方、折衷を要求される原因は「パラメータを突っ込み過ぎた」結果なところもある。　最終的には何処かの（ハードウエアを含めた）機能を削ることになるのだろう。

何れにしても、動作が不安定になるポイントが発生してしまうので、ユーザー側はそれを回避する方向で、音色の設定を行うことになる。

追記：

LFOの波形を読み出すWavetableのアドレスを uint16_t でキャストした結果、グリッチ・ノイズをほぼ消滅させることが出来た。



追記２：

暫定で、PWMの周波数を20kHzまで上げている。

LaVoixski@反転出力選択時のレベル設定について

オーヴァーレベル設定のwaveMixアドレスの選択時に、Rchの出力を反転させると発生していた「過剰な歪」を防止する機構を追加した。



これは前触れなしに来る「パッツン系の歪」で、音楽的に美しくないタイプの音色。



追加したコードは neg_Out 作動時の出力に -0.5 が掛け算される仕掛けで、出力が過渡的な変化無しでいきなりクリップすることを防止している。