LaVoixski@早速 ChordSequencer の改装を行う

ChordSequencer をループ状態にして、コードワークのヴァリエーションをチェックしたところ、配分していた ChordEditMode 編集分のコード群 pitchTablexx[4] の再生を失敗してしまうことが判明した。



この映像で該当する部分は、音列

G,@,@,E,@,@,F#@,@,G,@,@,F#@,@,E,@,@,G,@,@,E,@,@,
D,@,@,C,@,@,E,@,@,C,@,@,a,@,@,g,@,@,a,@,@,C,@,@,
E,@,@,C,@,@,D,@,@,E,@,@,

の F# で、対応する筈のコードワークが行われずにミュートされた状態が続く。

不具合が発生している箇所は、サブルーチン readSeq によって選別された ”D" = 29番 が対応する




要素 ”pitchTable09” で、これは　ChordEditMode によって生成された音列が転送されたものだ。



現在ここに登録されている音階の数値は、

0.32165527343750
0.55126953125000
0.28723144531250
0.49432373046875

となっていた。　

一方、通常のコード設定アレイに記載される値は、C,D,D#E, といった風にアルファベット表記されたものを変換テーブルによって数値化しているのだが、



ChordEditMode に於いて既に数値化されたデータを受け渡す過程で齟齬が生じていると思われる。

今回は不具合への対策として、ChordEditMode 由来のデータ群を、予めプログラム上に音列を登録したデータ・アレイ（ROMに相当する）に置き換えることにした。



残念ながら、メモリー管理のバグに引っかかる形で仕込み数を制限されてしまったが、とりあえず chd22 から chd36 までの登録が完了している。

これで、コードを登録したアレイの内容は、microSDからのデータ転送分が21、プログラム上のROM分が15、ミュートが1の、合計37種類となった。



結果は上々で、コードワークの幅を広げることが出来ている。



今回追加したコードワークの選定はあくまでも「趣味」によるものなので、汎用性を考慮して別の組み合わせに変更するかもしれない。

その後、ChordSequence を選択した時に、何故か MuteSW だけが効かなくなる現象が再発しているが、サブルーチンを挿入する場所を変えることで、対応することができた。



何れにしてもコンパイラの挙動がおかしいので、密かに別の齟齬が発生していないか、引き続き調査を行っていく。

追記:

案の定、ArpSequencerのシーケンス冒頭が誤動作する案件が再発した。　対処法は、シーケンス・ファイルにリザーブしたメモリを4096から1024に減量し、メモリの属性をRAM1に変更しつつ、不足分を補うためにコード記録用のアレイをDMAMEMに指定することで、緒問題の発生を回避することが出来た。

シーケンスにリザーブした分だけRAM1の残量が心許なくなったものの、現状は安定した動作が観測されている。　

LaVoixski@ChordSequencerの機能をまとめる

ChordSequencer は、リザーブされた２つのシーケンス・チャンネルのうち、



メインがルート音、サブがコードブックを担当している。



コードブックはコードを構成する残り2音を決定するが、コードは基本5つの音階を想定していて、



対応しているシーケンサモードのアドレス（#63以降）の前半2つは、構成音の2番めと3番目を選択、残りのアドレス2つはランダムに音階を選別する。



選択が固定されている方のアドレスでは、シーケンスをループさせることを前提として、長周期に擬似ランダム効果を発生させる手法が試せそうだ。

その具体的な方法は至ってシンプルで、ルート音＞コードブックといったように異なるステップを設定して、ループ再生を繰り返す毎にルート音とコードブックの相対位置にズレを生じさせる。　シーケンスは、各々の最小公倍数が一致した時点で「振り出しに戻る」。

これは、短いステップ数で演奏のヴァリエーションを展開できるアイデアなのだが、現状はメモリに4096ステップを確保してあるので物量的にはあまり意味が無く、ギミック的な要素といえるだろう。　



この例はステップの読み出しをバグった結果の産物ではあるが、予期せぬ形でこのアイデアを実践している。



どちらかというと編集作業の負荷を軽減するといった視点で有効な手法だが、実験を繰り返すことで面白いフレーズを生成できるかもしれない。

LaVoixski@ChordSequencerの音列選定にランダマイズ機能を追加する

ChordSequencer の後半2アドレスに、コードの構成音を２つランダムにピックアップする機能を追加した。



ランダムな数列は、Sequencerのクロックと同期したタイミングでジェネレートされる。



ランダムに選択されたアドレスを表示することも考えたが、



メモリ不足により、断念することになった。



より明快な差異を演出したい場合は、コードの構成音を増やして乖離した音列を登録し、それをランダムに選別すれば良いだろう。

追記：

その後、SequencerMode の特定のチャンネルで Mute が効かないバグが発覚した。　

SequencerMode には、アドレス毎に MuteSwitch 関連のロータリーエンコーダを展開していたが、これらは同時に使用することが事実上不可能なことに気付いた。　



処理に使われるリソースを出来るだけ減らすために、これを1基にまとめて簡略化に努めたが、バグは解消されない。　問題点をクリアにするために、Mute 時にアドレスの変更を行えるようにコードを書換えた後、SequencerMode を Mute 状態にしてチェックしてみたところ、#61 から #66 までのミュートが依然として無効化されたままだった。　ちなみに、スイッチングを行うパートに間違った記述は一切認められなかった。

誤動作が確認されているサブルーチン MuteSwitch は ピッチの感知を行うサブルーチン InputCapture 内に収められていたが、試しにこれをオーディオ制御系のサブルーチン内に移設したところ、、、



問題はすんなりと解決した。

LaVoixski@ChordSequencerの実装を行う

デモ用にシーケンス・データの仕込みを考えている過程で、トラックの作成をサボってコードを生成できないかを考えたところ、、、

システムには既に未使用なコード専用アレイが実装されていて、、、



登録されたコードを呼び出せるようになっていた。

次に、コードを呼び出すためにトラックの構造だが、これはSequenceArpeggiatorの回路を参考に構築することになった。



今回は10進表記を採用して、リザーブに必要なアドレスを確保している。　後々条件分岐による機能拡張を試みる可能性があり、その場合は16進でマスク処理を行うことになる。

コードを読みだした後は、基音に対する音階を選択する。現状は暫定でコードを構成する音列 chdxx[5] のうち、 [1] と [2] （[0] は基音に相当する）を選択している。



SequencerMode へのエントリーは ５〜８ 番目とした。

今回は、一時的に音階データをストアするためのレジスタ群を追加している。



シーケースデータそれ自体は整数を扱うだけなので、データのタイプは int16_t に変更した。



不具合の発生を回避するために、関連する変数は可能な限り DMAMEM から RAM1 に配分の変更を行っている。

システムを構築する過程は平坦なものではなく、シーケンスデータに書き込まれた読み出せない文字列の所為で

クラッシュを繰り返していたが、該当する文字列をシーケンス・ファイルから廃した後に、

適当な音列と、、、

コードの選択を






記述した結果はこんな感じで出力された。



ちなみに、プールされたコード群の設定それ自体が任意によるものなので、和音を構成する自由度はかなり高いのだが、「楽曲の選定が先か・和音の構成が先か」の鶏と卵状態に陥ってしまう可能性があり、仕込みを行う段階での熟考が必要とされる仕掛と言えるだろう。

追記：

全体の動作確認のために他のファイルを再生したところ、あきらかにおかしな挙動が散見されたことから、関連するサブルーチンを精査したところ、CSVならぬ独自規格「C#SV規格」の”＃”をセパレータとして認識できないバグを発見した。



該当する部分は、63番から66番のシーケンスで、以前から「勝手に変拍子」や、ステップ数のカウントミス等の怪しげな動作を繰り返す兆候があったものの、シーケンサはあくまでもオマケ機能といった考え方からチェックが漏れていたようだ。

動作確認用に作ったガイド用のシーケンスファイルそれ自体が、動作レンジ外の記述やステップ数の非統一を含めてかなり適当な代物だったこともあり、いま一度「シーケンス・ファイルの文法チェック」から行う羽目に陥ったが、再生音域の問題等を考慮した検証用のファイルを各トラックに配分することで、ようやく動作の確認を終えることが出来た。



休符の設定等の「やり残し」がありそうなので、今後シーケンス・ファイルの作成を含めた実証試験を行っていく予定。　ちなみに、データの入力には独特な作法が必要な雰囲気で、何気に扱い辛いことが発覚している。

追記２：

SequencerMode を選択した際に、直前のモードで設定した Arpeggiator の状態が保持されたままで、出音に影響が生じるバグを発見した。

これは、ChoppingMode を選択していた際に現れる現象で、Chopping を解除するには前のモードに戻って通常のモードをリコールするしか方法が無い。

対策は簡単で、問題が発生する箇所に未設定だった Arpeggiator 関連のパラメータを追加して、、、



そこに "0" を代入ればよい。

LaVoixski@「歪発生許容チャンネル」のヴォリューム設定を復活する

アドレス #15 / 29 / 30 / 31 / 32 に設定している「歪発生許容チャンネル」で



排除していたヴォリュームの設定を復活させた。



残念ながら、表示系に手を回した瞬間にメモリ不足に陥ったので、「歪発生許容チャンネル」に該当する15番地の表示は現状のまま "fixed" で据え置くことになったが、



実質的にはペアに指定している16番地の設定がそのまま適応される。



LFOを併用すると波形がマイルドに変化するのだが、、、



LFOのエッジを調整することで、クリッピングポイントを操作することが出来る。



今回復活させたヴォリュームの設定により、さらに細かな調整が行えるようになった。

LaVoixski@ChoppingMode起動時に発生するバウンシングについて

Transitionのダイナミックレンジを12bitに拡張した影響なのか？ChoppingMode起動時のエンヴェロープにバウンシングが見られるようになった。



波形を確認したところ、減衰の速度が遅すぎてミュートが間に合っていないように見える。　

エンヴェロープを制御する時定数を変更して対応できるかどうか実験で確かめる必要があるのだが、その前にまずミュートを行う機構を再検討していく。

ミュートの判定機構は、アルペジエータの#16から#19を呼び出した時に発動する。



該当するアドレスに於いて、inNotes の値が == 0 を検知した時にミュートを示すフラグ fEG が立つ。

一方、Arpeggiator の音階情報を microSD から読み出すサブルーチンでは、@と*を、それぞれ "0" と "87" に判定する。



判定された数値は、ピッチテーブルから対応する音階情報を引き出す。



この場合は、何れも（事実上）音階が存在しないことになるのだが、@ = 0 は、フラグ、fEG を励起し、ミュートが実行される。



ミュートのエンヴェロープは LFO1 の Depth によって、ある程度の傾きをコントロールすることが出来るので、ミュートのキレを悪く感じる場合は試しに数値を調整してみるとよいだろう。

今回追加した変数は * と emp で、 nop と同義の存在としてミュート命令の間隙を埋めることを目的としている。　改変前の表記法では、ミュートに加えて「ダミーの音階」を挿入する必要があり、SequencerModeでChoppingを使用する際に、これが予期せぬ形で音階として再生されてしまう弊害が生じていた。

改編以降、音階を排除したミュートの記述は、" *,*,@,*,@,*,@,@ " といった形で行うことになる。

追記：

新しく設けたルールに従い、アルペジエータのデータを書き換えた。



結果は良好で、、、





SequencerMode 選択時に発生していた「誤動作感」を払拭することが出来た。

追記　2：

何故か#17で Chopping 不能となる案件が発生した。　該当するコード周りのバグを探してみたところ、 #16 から #19 に追加したコードのうち、#17 に該当するデータアレイを全てのアドレスにコピペしていたことが原因だった。　重複していたアドレス毎に名称を修正した後に、、、



テストを行うも、今度は対象となる全てのアドレスでミュートが行われなくなる事態に陥ってしまった。

実のところ、これが当然の帰結と言えるのは、唯一まともに記述されていた ＃17 で動作不良が発生していたのが全てのアドレスに波及した訳で、ただちに記述を元に戻したのだが、何故か拡大された動作不良が解消されることはなかった。

この「面妖」とも言える現象に対症療法としてダミー用の新たなアレイを設置してみたものの、別の誤動作が SequencerMode で発生する始末で、とどのつまりは、"nop" が有効に活用されていない雰囲気である。

"nop" が無効化されていることは、Pitch を設定するデータアレイの不調を示唆しているのだが、記述を間違ってはいそうにないところが厄介だ。

結局、過去の経験から DMAMEM には特有のバグが潜んでいる可能性が考えられることから、データアレイの拡張を諦めて、nop を実行するために準備した変数の代わりに、エントリー済の最低音階をローカルで設定することにした。



この改変によって、ようやく正常なミューティングが行われるようになった。　



が、、、如何せん原因がよく判らないところが不気味ではある。

LaVoixski@WaveformMixの仕様を変更する

音声出力 L/R チャンネル間の出力レベルを均質化するために、WaveformMix の構造を再検討することになった。



Transition による L/R 出力の分配比は、アドレス毎に 3 + 2 と 3 + 3 が並立していて、これが出力に不均衡が発生する原因となっている。　今回は、3 ＋ 2 の不足分に基音扱いとした Oscillator A を + 1 することで、全てのアドレスの分配比を "3 + 3" に統合することを試みている。

出力波形の表示にも、現実に音声を分配した状況を反映させるための改変を行う。



L/R出力のレベル差は、以下のように平均化することが出来た。











今回の実験では、改変の効果を確かめるために各オシレータの音量を「減衰無し」の状態にプリセットしていたが、当然ながらピークアウトによる歪みの発生が確認されたため、L/R ch の音量バランスを確認しながらオシレータの減衰値を再設定することになった。



32種類のミックスは、前半の14アドレスが固定、#15から始まる編集可能な領域に分かれていて、うち前半の#1から#13と、後半の#16から#19はTransitionが未対応、後半の#29から#32は、出力値固定のディストーション発生仕様となっている。

ディストーションの発生するポイントが前倒しになっている感があったので、増幅度を下げることで閾値を調整した。

LaVoixski@Transitionのダイナミックレンジを12bitに変更する

バグ潰しの一過程として出力波形の観察をオシロスコープで行ったところ、TransitionMode に対応する各オシレータのレベル設定が可能なアドレスと、固定レベルでピークアウトが許容されるアドレスの間に生じた音量差が、以前よりも拡大していることが判明した。

これは、TransitionMode の仕様変更によって、Transition のエンヴェロープをコントロールする波形の相対位置 ＝ 疎と密の関係が変化した影響で、歪が発生するまでのマージンを稼げるようになった反面、合算後の出力値が低下することになった。

Transition が推移する過程で発生する音量差を解消する手段として、Wavetable のダイナミックレンジを11bitから12bitに拡張する方法が考えられる。



音声制御データを 12bit 化した結果、旧来の 11bit に対応させたシステムではオーバーフローが頻発するので、オシレータの単独出力のゲイン調整に挿入していた * 2 をキャンセルしている。



自分の設計思想は、「もし歪が発生するのであれば、それはユーザー側が調整すべき」といった減算指向の考え方なので、過度な調整は行わない姿勢だ。



Wavetable の仕様を変更した結果は概ね良好だが、出音の雰囲気は予想を超えて変化していた。　



当初はモノラルの加算合成音源を設計したつもりだったのが、高々5chの合成で得られる効果はいま一つで、そこにTransitionという概念が導入された結果、そちらをメインに音を組み立てることになっていった。



このような開発の経過から、オシレータの音源をTransitionに配置するパターンの設定に関しても「加算合成」の概念に引きずられているところがあり、アンバランスな出力レベルに対する無頓着さがその傾向を示していた。　今回はその点を考慮して、WaveformMixの再構成を行うことになる。



ピーク値が2倍になった結果、歪が発生するタイミングが変わっているために、波形の選択と音量の組み合わせを好みの音質に再調整しなければならないが、パンニングの設定それ自体もリファインすべきなので、これから仕様を詰めていく。

LaVoixski@SequencerModeのバグを解消する

SequencerMode の演奏時に、リセットまたはループポイントに於ける先頭番地（今回読み出すデータの最後尾はNTE_15）のデータがランダム化してしまう現象が発覚している。



この映像では、本来 "NTE_1" が選択されるべきところを、NTE_10 と NTE_8 のコンビネーションで再生が行われている。　ランダムな対象に倍テンポでアクセスを行った後、何事もなかったかのように通常モードに移行する現象の機序を説明するのは難しい。

流石にこれは拙いので、色々と対策を施してみたものの全く対処することができない。　原因を探るために不具合が発生する状況を観察したところ、循環再生時にバッファから正常に数値を読み出せる確率がほぼ1/2、リセット後の再生時には100%の確率でランダムな数列を読み出している。

CSVで記述された数列の読み出しは、対応する文字列の条件分岐で行っているが、、、



0番地に指定されたデータの正当性は Arpeggiator の起動時に確認できていることから、変換ミスはありえない。

読み出した16進データは桁で分離して、、、



Arpeggiator の Note と、再生パターンの選択に対応させているが、この部分に問題が潜んでいるとは考え難い。

シーケンスの開始直後に不具合が発生することから、Click2 を使ってアルペジエータの駆動に関連するカウンタのリセットを試してみたが、



実行時にシステムクラッシュが発生するだけで、ランダムな数値を読み出してしまう問題は全く解決しなかった。

今回 SequencerMode を撮影する過程で、用法でリカヴァーする体の「かなり旧いバグ」を掘り起こしてしまったようで、そういえばシーケンス再生時のステップ１発目は体感上遅れるので、データの先頭に空打ち分の無音空間を入れておいた方がよい、、、といった用法を実行していたのだった。

長年潜んでいたバグが発覚したのは、M7の導入とともにループ再生を前提にシーケンサを運用するようになったことが原因だが、シーケンスの再生中に、無音で1シーケンスが空走する案件までが発生している。　空走が発生する箇所は、アルペジエータの登録アドレス10番/下り順を再生した時のみが該当するようだ。　なお、空走の発生頻度はかなり小さく、めったに観測することは出来ない。

上記に示した対策の他に、タイミング管理の最適化を模索する等の手を尽くしてみたが、何れの手法も決定打とはならず、最後の手段でデータのストア先をEXTMEMからより高速なDMAMEMに変更したところ、すんなりと問題を解決することができた。　



EXTMEMの選択はメモリ管理上の制限といった側面が絡んだ折衷案であり、



読み出し速度が遅いSequencerModeでは問題は発生しないだろうと踏んだ結果の選択でもあった。

プログラムの改装を行うついでに、同じ階層に並立していたSequencer/Arpeggiator02のタイミング管理部を、より動作が確実となりそうな入れ子構造に変更している。



分散していたローカルカウンタも、タイミングを管理するセクションにまとめている。



また、CortexM4時代に発生していた動作の問題をカヴァーするために敢えて分散させていたSwitchによる条件分岐を統合しつつ、、、





念の為に、先頭データのバッファリングを強化している。



以上、大改装とも言える内容によってメモリ管理が破綻する心配があったが、RAM2の残量僅かでなんとかコンパイルを通すことが出来た。　



結果は良好で、データの読み出しを開始した時の空走はなくなり、高速領域のレスポンスが改善されている。

この改良によって、ヴォリューム表示のカーソルに生じていた残像が消えるという副産物があった。



映像では、シーケンスがループするポイントに於いて「選択」が正常に行われていることを示す指標として、先頭アドレスに設定した STP_7 / NTE_1 が表示されている。



ベースラインのループ再生時に発生していた針飛びのような現象も解決することができた。



追記：

その後、Arpeggiator の編集モード選択時に Chopping によるミュート表示のタイミングが遅れていた LED の点滅制御を、WCK によってトリガーされる AttatchInterrupt 内 に移設することで、



レスポンスの改善を達成している。

LaVoixski@Teensyduinoのコンパイラの挙動について

Transition の Panning とオシレータの定位が移動する様をチェックしていたところ、何故か、Transition の信号が入れ替わってしまう謎案件が、勝手に解決していた模様で、スワップしていた2番と4番を元に戻した。



Transition の表示それ自体はあくまでも「オマケの機能」であって、表示の正確さは二の次な設計なのだが、流石に逆相が表示されてしまうのは異常事態だった。

表示系サブルーチンで重複処理を行っていた箇所を削除した後に、メモリの管理を含めていろいろと挙動が落ち着いているのだが、この反応もその現象の一環なのかも知れない。　

LaVoixski@arpSequencerのリファインを行う

前回行ったヴィデオの撮影の過程で諸々の問題が明るみに出てきたことから、いまいちどアルペジエータに関連するサブルーチンを精査することになった。



以前からシーケンサがアルペジエータの16番アドレスを読まない現象を確認していたが、原因はシーケンス・データを構成するキャラクタをアルペジエータのアドレスに変換する条件分岐を設定する際に、 0xn0 を出力するための記述を失念していたという初歩的なミスだった。　



運が悪いことに、読み取ったシーケンス・データにオフセット値 +1 を追加せずにアドレスを参照するといったミスが重なった結果、問題の発覚が遅れることになった。



choppingArpeggiator の発動時に LCD との通信が遅れた影響で、表示色の極性が反転してしまう現象は、アルペジエータの音響特性を設定するアドレス毎に「フラグのリセット」を設けることで解決できた。



今回修正を行った箇所は予想外に多く、、、



作業は食事を挟んだ半日仕事となった。



アルペジエータのプリセット 16 アドレスと、再生 4 パターンに対応する文字列（暫定）を示す。



こちらは、第二案。



ある程度の法則性を持たせたほうがよいので、こちらの案を採用した方がよいかもしれない。

追記：

結局、特徴的な機能を持たせた16番目のアドレスに、認識が容易な f / F / - / + を対応させた後者の配列を採用することにした。

また、Arpeggiator のシーケンスが入れ子構造になっている arpSequencer の使い勝手を考慮して、シーケンサのステップを駆動するクロックの最大値を 2000ms に拡張した。



最大で、3000ms 程度までは拡張が可能なので、必要な場合はさらにレンジを広げることになるかもしれない。



ついでに、シーケンサ選択時の PINK ベースでカラーコード前半の BROWN / RED / ORANGE 系の点滅と配色の相性が悪かった LED の視認性を向上させるために、



発色を DARKCYAN ベースに変更している。

LaVoixski@arpSequencerに関する最新の映像

Arpeggiator をコントロールする arpSequencer を使って、アクセラレータを最適化した ClickEncoder の動作を確認している。



arpSequencer は入れ子構造になったシーケンサで、同時に改装した Arpeggiator の動作をチェックしているが、ほぼ限界に近いスピードでシーケンスを実行できている。

LaVoixski@ChoppingArpeggiatorを選択したときの表示を改良する

ChoppingArpeggiator選択時の表示を改良した。



まず、LEDとの同期が不完全だった下部エリアの点滅表示を廃止して、トリガによって駆動されるランダム発色に変更、項目の表記を choppingARP とした。



パラメータは Arpeggiator と同様に、ノートのアドレス・ステップ数・トリガの間隔（ms）を表示している。



ヴィデオの撮影後にシーケンスパターンのオーバーフローを発見したので、バッファのサイズを増やしておいた。



休符を表現する ChoppingArpeggiator の場合には、特に分解能が重要になってくるのだが、32分音符では微妙なニュアンスが出せないことが判明、レンジを128に増設することにした。

以前は、DMAMEM を指定しているのにも関わらず、数バイトの変更がRAM1のメモリ不足を誘発してコンパイルが不可能になっていたのが、表示系の重複したコードを削除した後はある程度の増加が認められるようになった模様。

また、処理が高速なM7環境で行うPIT駆動の影響により発生していた、ロータリーエンコーダの加速度設定のミスマッチに対処するために、該当する定数を初期値から変更している。





ChordEditMode でピッチを設定するにはまだ加速度が足りないが、通常使用する分にはベストな設定と感じられたので、やむを得ずこの値で折衷することにした。

追記：

やはりピッチのチューニングがタル過ぎるので、折衷2案に加速度の設定を変更した。



ついでに、視認性が悪かった ChordEditMode の BLUE 系の UI をCYAN に変更、



ピッチを表示する CYAN / MAGENTA の Y軸 を中央寄りに調整している。

LaVoixski@PitchBend/PhaseShifterの記録

PitchBend の操作系は、パラメータが Threshold と BendDirection/Time = "AtkEnv" の2項目と単純なので、理解は難しくないだろう。

問題は、BendDirection/Time = "AtkEnv" の値が中点のゼロ時に発動する PhaseShifter の操作系で、



パラメータは mode4: case 5 の頁に配置された、Lp2Lfo と LfoWv2 の2点がそれに当たる。　













これらのパラメータは何れも LPF2 関連のパラメータと共有されているところに注意が必要だ。

LaVoixski@VoiceMode切替時に行うMuteについて

昨晩から音の段差が気になっていたVoiceMode切替時のノイズを軽減するためのミュート機能の実装を行っていたが、オートフェードの実装を含めた試行錯誤を繰り返した結果、リソースの消耗を鑑みる観点からハードウエア側にミュート機能を依存する方法を採ることになった。



サブルーチンにはフラグが実装されているだけで、、、



フラグによって駆動された出力でDAC側のXSMTをコントロールする。　現時点のパルス幅は1ms程度としている。



波形のアウトラインには豪快に段差が発生しているが、継ぎ目はこんな感じで、懸念されていた妙なクリップは発生していない。



スイッチングに伴う謎な反応によりクロスフェードっぽい挙動を示しているが、スムーズな乗り換えには程遠いレベルだ。



とはいえ、位相の乱れは殆ど発生していないようだ。



このような信号の変遷が行われるのは想定外で、切替時に何らかの問題が発生している可能性を示唆している。



一番信号が乱れた場所がこのレベルなので、PAに所謂「パッツン」をお見舞いする確率は低いだろう。



暫く観察を行っていく予定だが、いまのところは大きな問題は発生していない。



目玉スイッチ側にもミュート機能を設定し、



PITの更新速度を上げている。

LaVoixski@Arpeggiator周りの仕様変更とバグの解消を行う

Arpeggiatorのオルタネイト再生モードのstepが過少に表示されるバグに関連するサブルーチン群を精査したところ、重複や設定ミスが発覚、これらの修正を行った。

まず、サブルーチン arpView と readSteps の2つに重複していた step の計測ルーチンのうち、arpView から 該当する箇所を削除した。　変数 steps は予め volatile なグローバル変数に設定していたので、この簡素化による問題は発生していない。



次に、オルタネイト再生モードの step 数の不一致に関しては、単純にオルタネイト再生時の値を倍にしていなかったケアレスミスが原因だった。　また、サブルーチン readSteps に於いて、条件分岐で step 数が変化するケースは、オルタネイト再生のみが二倍に変化することから、スイッチの条件分岐を default と case 2: の二種類に整理し、コードを簡略化している。　switch は処理スピードの速いので、視覚上簡易な処理に見える if / else による条件分岐は敢えて組まない。



以上で、Arpeggiator 周りのバグを解消できたが、メモリに余裕が出てきた雰囲気なので、



ここで過去に失敗したランダム再生モードの改良を行うことにした。



この改良に伴い、readSteps で該当する箇所の step 数をプリセットしておく。



改装前は、#32 のランダムノート再生モードを ArpNote で選択した際に、再生モードの切替が効かず 0 ~ 35 のランダム音域のみで固定されていたが、



変更後は再生モードの切替により 0~12 /



0~24 /



12~24 /



0~36 の



四択の選択が可能になっている。

LaVoixski@randomArpeggiatorInJupiter4style

Jupiter4のRandomArpeggiatorのパターンを仕込むのに午前中を丸々費やしてしまった、、、。



所謂疑似ランダムっぽいのだが、鍵盤の押さえ方で音の順番が変わってくる可能性も。　どうも詰めが甘い感じがするので、後々精度を上げていく予定。

意外にもネットにデータが転がっておらず、結局は音源を漁って音を取ったのだがこれが中々に難しかった。



日本のメーカーの設計は基本的に金を掛けない方針なので、ノイズをS/Hしてランダムを発生させるような複雑な回路は組まない傾向がある。

ランダム風アルペジエータのデータを製作する過程で、該当するアルペジエータのアドレスに表示系のバグを発見したものの、修正した途端にメモリー管理のエラーが発生、どうやっても破綻を免れなかった。　

実用上の支障は何ら発生しないことから、とりあえずバグは現状のまま放置することになった。



変数の名称を変えてもトラブルは解消せず。　処理の順番を変えた場合もアウトだった。



メモリー管理の改善を試行錯誤する過程で、LEDの発色チェックを行う場所を変更している。



シーケンサ風のアルペジエータの精度を上げるために、メモリーの増設を行った。



Transitionの波形表示の位相をシフトしたために発生したドリフト分だけオフセットを修正している。



追記：

やはり仕事が適当だったので、シーケンスを組み直した。



オリジナルは例の曲だが、アルペジエータによって生成されたフレーズの版権は微妙で、Youtubeも判断に困っていた模様。



疑似ランダムな演奏パターンを再現しつつ、その音列をソースに再ランダマイズを行っている。

鍵盤楽器のランダム演奏が持つ独特のニュアンスは、鍵盤を押さえるタイミングでシーケンスのパターンが変化する仕様によるものだが、それをトリガーの介入を行うことなく再現するのは難しい。　

追記２：

Arpeggiatorのstepを読み間違えるバグの原因を内包するサブルーチン発見、問題をFix出来た。



今回は、検索を行うべき関数を勘違いしていたために発見が遅れた。



何故このような重複が発生していたのか？間違った理由は謎のまま。

LaVoixski@メモリの消費について

MemoryのPaddingがゼロになり、MAGENTAに発色していなかったLED（今までそれに気付かなかった）が復活していたり、いろいろと訳の解らないことが起こっているのだが、



とりあえず安定しているのでヨシ！とする。

メモリの消費を抑える方策としては、廃止したサブルーチンで使用していたChronoを取り除いたのが有効だったり



PWMの使用を控える等、試行錯誤をしながら探求している。

が、結果からは規則性が感じられず、何が有効なのかよく判らない。

LaVoixski@サブルーチンTransitionViewの値を詰める

現物合わせを繰り返した結果、、、



だいぶ近くなってきたが、今はこの値で妥協する。

追記：

何故か、表示する波形の2番オシレータ (BLUE) と4番オシレータ (YELLOW) が入れ替わっているのだが、原因が全く判らない。　



波形の表示は目安に過ぎないとはいうものの、あからさまな「不一致」は精神衛生上あまり好ましいものではないので、とりあえずは色味を入れ替える対症療法を行っておいた。



事情を知らなければ、さして気にする必要がないレベルの問題ではあるが、こうなってしまった原因を探りたい。

しかし、プログラムの何処をチェックしても、この謎なスワップ現象が発生する原因を特定できない。　エンヴェロープを描く絵面そのものが直接的に音声データと結びついていない＝概念の産物であり、一見すると両者を関連付けているのは上下エリアを動くカーソルという構造故に描画を行う部分が怪しいと思えるのだが、音声データを扱う側に問題がある可能性も、、、。

追記２：

結局、円形LCDの特性に合わせようと妙に数字を弄くらずにセオリー通りの倍率を描画を行う関数に掛けて、現物合わせでオフセットを設定することになった。　



描画と出音の不一致は、音声側の割振りを変更することで物理的に対応した。



TransitionはVolumeAntの出力を変換した12bit幅のデータを使って、5つのオシレータをクロスフェードする機能で、クロスフェードを行うエンヴェロープは11bitの分解能に設定され、それぞれが左手のセンシング領域を2巡する。

メイン・オシレータとその他4基の相対位置は、基本波に対してオフセットを掛ける形で均等に分散されるが、デッドポイントを発生させずに等分した角度は72度、データ的には約410となる。

実際には11bitに設定されたアドレスは2巡させることが前提で、オフセットを付加された信号の相対位置も同様に円環するのだが、LCDの限られた表示領域にデータを落とし込む際に、どうしても誤差が生じてしまう。

LCDに表示される位相差はあくまでも概念上のものなので、誤差の配分を気にならないレベルにまで折衷しなければならず、そこにはデザインのセンスが問われることになる。

最終的に描画はこのようになった。　





カーソルを駆動するヴォリューム・データにノイズキャンセラー用のウエイトが掛かっているために、上り下りで反応に遅延が生じているが、実用上の問題はないだろう。

LaVoixski@単独出力系のレベルを調整する

Transition関連の改良を行う過程で、TransitionMode 選択時に OutputThree と Four に無視できないレベルの音量差が発生していることが発覚した。



この問題に対処するために、各音声出力データの増幅度を調整している。





念の為、オーヴァーレベルの有無を確認すべく調整後の出力波形を測定したところ、、、







各出力の振幅は 5V pp 以下に収まっているようだ。　今回は、敢えて6Vフルスケールの調整は見送っているが、レベル差が気になる場合は * 2.3 程度に増幅度を調整することになる。　ちなみに、レベル合わせの実験を行った結果、* 3 は破綻するレベルで過大、* 2.4 まで下げた場合も波形の一部がクリップしていた。

こちらは、出力がフルスケールで振り切っている例。



所謂 ”WaveShaper 系” の処理を行っているのだが、他のプリセットとのレベル差が気になるところ。

波形観測のついでに、LPFのカットオフ周波数にLFOを使ってモジュレーションを掛けてみる。

















LFOのエンヴェロープが、カットオフ周波数が変化するシェイプに反映されていることが判る。