2019年03月25日

LFOの導入とインターフェイスの改良・その他

"Won'tGetFoolAgain"のイントロのような効果が欲しくなったので、音声出力のエンヴェロープにLFOを仕込んでみた。

  

Arpeggiator制御クロックのエッジをEMAでなまらせることで、Envelopeのシェイプを変化させている。

追加した新しい機能・PitchBendとEnvelopeChopperは何れも制御パラメーターへのアクセスがもどかしく、とりあえず機能を発現させるだけでも数ステップの作業が要求される始末で、これを改善する方法はないものかと考えていたのだが、MuteSwitchに元々追加分のアドレスをリザーブしていることを思い出した。 

Screen Shot 2019-03-23 at 3.52.21.png

現在、暫定でノーマル→ピッチベンド→ミュート→トレモロの演奏モードを円環させているが、おそらくはこの仕様で固定することになるだろう。 利便性を考慮した結果、ノーマルモードの前後にエフェクトを配置して全演奏モード上でベンドが行えるように変数を追加した他、各機能の発現を下段のLEDに表示させて状況の視認性を向上させている。

以上の改良によって、元々は2VoiceModeの#15に限定していたPitchBend機能を全チャンネルに拡大することになったが、この段階で処理機能の破綻は見られていない。

今回増設したPitchBendでは初めて積極的に負の値の設定を扱っているのだが、microSDにスナップショットの記録を試みた結果、単純にdtostrfでキャストを行っても負の値を記憶できないことが判明(世間的には自明なことなのかもしれないが)した。 

解決法をいろいろと思い悩んだが、フラグ代わりにMSBオンに相当する値をデータに足すことを思い付いた。 

WS001795.JPG

これはローカルで行った実験のスケッチ。 かなり怪し気なメソッドだが、12bit以下のデータ幅であれば問題なく動作している。

データの流れを解説すると、ロータリーエンコーダからの出力attackB1をmicroSDで受けられる形outstrに変換した後、レジスタread_var2に読み込ませ、そのデータを再変換してパラメーター制御用のシーンメモリーに戻す一連の動きをシミュレートしている。

WS001789.JPG

テストベンチでゼロ・ポイントを越境する際に問題なくデータをハンドリング出来たので、次は楽器に実装して動作を確かめることになった。

WS001793.JPG

実際にコードを埋め込むとこんな感じになる。 

WS001794.JPG

データをmicroSDに書き込む部分と、読みだす部分にそれぞれMSBの極性フラグに対する処理を行うコードを挿入している。 挙動に少々心配なところがあるが、極性判定の仕掛けは正常に動作している模様。

以上のように、インターフェイスに関しては折衷案を上手く見つけたと思っているが、連続した色味による機能の判別がややこしい。 対応策を試行錯誤した結果、 PitchBend/Toremolo各演奏モードの選択に伴ってUpperKnobのコード選択機能がパラメーターのValue設定に切り替わる方式を思い付いた。

負の値を扱うPitchBendモードでは、符号の変化を点灯するLEDの発色を切替えることで表現している。

WS001797.JPG

モード選択時にコードの選択が行えなくなるのが欠点だが、頁の移動量を考えると、こちらの方が現実的な運用を行えると思う。

実際にこれらのエフェクトを使用する頻度はそう多くないと思われるが、即興性の向上を狙う場合はこの手法が最適解だろう。

改装のついでに、LFOのDepthをVoicingMode毎に設定できるようにメモリーを増設した。

シーンメモリーの利便性を向上させるため、従来はArpeggiatorを選択した時のみ行えた記録を、全アドレスにおいて可能とした。 唯一、Pitchのプリセットを行った後に記録するアドレスを呼び出す必要がある ChordEditモード を選択した場合のみ、従来通り「アルペジエーターを選択した時だけ」シーンメモリーが行える仕様を継続した。

Mode毎にLFOのスピードを仕込めると更に便利だが、Arpeggiatorのスピードとの齟齬が発生する可能性がある。

結局、さらなる利便性の向上を目指してUpperKnobにチューニング系のパラメータを再配置することになったが、機能の被りを防ぐために大量のスキップルーティンを配置しなければならず、作業量は予想していたよりもかなり大きなものになってしまった。

WS001792.JPG

スキップの仕組みは、条件分岐が該当するモードと一致した場合にブレイクを掛けるだけの単純なものなのだが、switchを構成しているcase毎にこれを挿入しなければならない。

WS001791.JPG

より洗練された方法として関数化した発光ルーティンを呼び出す方式が考えられたが、コードの簡素化は遅延とトレードオフとなる可能性があり、今回は採用を見送ることになった。

WS001790.JPG

あんちょこの執筆時にインターフェイスの煩雑過ぎる構造が露見した為にやむなく作業を行っているのだが、つらい作文作業のおかげで客観的な視座を得ることが出来たのがラッキーだった。

要は、10を超える(概念的な)垂直移動が強要される環境ではパラメーターの認知に相当な負荷が掛かりそうなことが判ってしまったのだが、この問題を解決するには現状で20対9という不均衡なパラメーターの分布を、出来るだけ均等に分配する必要があった。

試行錯誤の結果、パラメーターのレイヤー化を進めて、下側のポットノブのアドレス#1・OP3の選択時に、倍音編集機能を、アドレス#10・MixSelectorにOscillatorの編集機能を割振ることになった。 

WS001796.JPG

要素をダイレクトに編集できるパラメーターの構造を採用できたのは大きな進歩ではあるが、



反面、ヴォイシングの選択レイヤーが減少する弊害が発生している。 

ネガティヴ面の評価については今後行っていく実験運用の過程で結論を出していくことになるが、レイヤーの移動を自動化出来た運用上のメリットはかなり大きい。
posted by Yasuski at 20:12| LaVoixski