2019年03月17日

PitchBendの運用ケースとパラメータの再配置について

運用には慣れが必要だが、左手の動作だけでトリガーを掛けるのは少々辛いことが判明。 より効果的にPitchBend機能を使用するには、外部からトリガーを入力出来る端子を追加すべきかもしれない。 

外部トリガーは、現在設定しているスレッショルドが設定可能な内部トリガーとExORを行って実装する。 入力端子のステイタスを変化させる方式は物理的なスイッチを接続するのがシンプルだが、よりフレキシブルに運用が可能なBluetooth等を使ったリモートデバイスの使用を検討している。



PitchBendの導入に伴い、パラメーターの配置を変更した。 インターフェイスの仕様がコロコロと変わるのは考えものだが、これが最新の操作法だ。



一方、プログラム上では循環するパラメーターの配置をこのように規定している。

<->op3(multiColors)<->PitchBend(pur/yel)<->distortion(sky/red)<->mute(yel)<->transition(pur)<->transitionEnvelopeSelecort(sky/pur)<->osc1_vol(grn)<->osc1_wfm(sky)<->osc2_vol(blu)<->osc2_wfm(sky)<->osc3_vol(red)<->osc3_wfm(sky)<->osc1_vo4(pur)<->osc4_wfm(sky)<->osc5_vol(yel)<->osc5_wfm(sky)<->arp_ptn(red)<->arp_spd(grn)<-> arp_seq(blu)<->

実際に設定しているニュートラルな位置のパラメーターは4番目の MuteSwitch(Yellow) で、今回の改装ではそこから前後する使い易い位置に使用頻度の高いパラメーターを再配置した。
posted by Yasuski at 14:35| LaVoixski

2019年03月15日

Gride機能にハーモナイズド・チョーキング風の機能を追加する / PitchBenderの製作

Gride機能にチョークアップする側のEnvelopeを追加した。



具体的な効果としてはハーモナイズド・チョーキングを模したものを目指している。

Screen Shot 2019-03-15 at 17.21.12.png

GrideのRate設定をゼロポイントを超えたマイナス側に回すと、int16_tのMSBからNegativeFlagを感知して、グライド・アップする方向に機能をスイッチする。 

Chronoは負の値を扱えないため、事前にMSBをマスクした数値をパラメーターとして使用するが、このままでは境界を超えた途端に最大値が入力されてしまう。 これを防止するために、マイナスのフラッグが立った場合には  を使って出力値を反転する機構への条件分岐を組み込んでいる。

実際に運用した場合にポットのゼロポイントの境目が判り難かったので、LEDの発色を変えて境界を示すようにインターフェイスを改良している。

追記:

EMAの処理時間を短縮する方法を見つけたので試してみたが、データが荒れて使い物にならなかった。
posted by Yasuski at 18:23| LaVoixski

EnvelopeGeneratorのようなものを実装した

Chronoを使ったトリガーを切欠にAttack=立ち上がりのエンヴェロープをオシレーターのピッチ制御に印加する機能、Envelope Generatorのようなものを実装した。

Lyle Maysな雰囲気を実現するまでの道程は遠いが、まずは第一歩から。

Oberheim名物なLyleMaysの"あの音"を思い出してから脳内再生が鳴り止まず夢にまで出てくる始末で、この日の午後はその実現に向けてひたすらに試行錯誤を繰り返していた。

基本的な構想は、データの極端な変化をサプレッションするEMAアルゴリズムの係数をChronoを使って段階的に変化させる方式で、Chronoによって発生させるトリガーの間隔が長くなると、EMA係数の変化量が抑制され、結果としてGrideTimeが伸びるという仕掛けだ。

最初のこれはおもいっきりコーディングを間違えているのだが、

WS001765.JPG

実装した結果「何となくそれっぽい動き」が観測されてしまい、これが迷路の入り口に入る切欠となる。

次に、実験を繰り返して到達したこの段階では、実用性は乏しいもののPitchをGrideさせる機能の実装がほぼ実現しつつあった。 ただし、変化量が大きすぎたり、Grideさせた結果が超低音になるなど、新たにピッチ制御のために用意した係数、add_vall2 に出力されるデータは正常なものとは程遠い状態だ。

Screen Shot 2019-03-13 at 15.47.24.png

そのうえ、Chronoの調整のためにノブを回していると、突然作動不能となるケースが頻発した。 

このケースには相当悩まされたが、SequencerにStart/Stop機能を実装したコードからそのままの仕組みを再利用して、「トリガーゲートがオフられた時にchrono.stopを使ってChronoの計数をストップさせていた」のが原因だった。 

chrono.stop を排除した結果、トリガーによってEGを発生させる機構の動作を安定させることが出来たが、この段階ではピッチが不思議な挙動を示す原因をまだ特定出来ていない。

その後の数時間に渡る試行錯誤の末に探し当てた、正常に動作するほぼ最終的な案以下に示す。 

機能をまとめてEGとしてサブルーチン化し、それをPitchディテクターのサブルーチン内からコールしている。

Screen Shot 2019-03-14 at 2.32.48.png

結局、発生させていた「Pitchの差分」そのものを add_val2 に代入するPitchデータ出力として取り扱っていたのが間違いで、元データ add_val に「差分を足す」のが正解だった。 これで、Pitchの扱いに関する問題はほぼ解決した。 制御波形の分解能は200だが、これは今後調整を行う必要があるかもしれない。

多分、これもまた「車輪の再発明」に過ぎないのだろう。 が、ひとまずはそれっぽい動作をする仕掛けが組み上がりつつある。

負荷が多いためか出音が微妙に荒れ出したのが危険な徴候だが、出来ればこの機能を外したくはないものだ。

ついでに、操作性を向上させるためにパラメーターの配置を一部変更している。
posted by Yasuski at 11:14| LaVoixski

2019年03月12日

LEDの表示モードを変更する(その2)

Sequencer使用時に「どの曲をセレクトしているのか判らなくなる問題」が発覚したので、メモリーCH毎に*Blink*するLEDの発色を変えることにした。

曲を選択する毎に色が変わって視認性が格段に向上したが、今度は点滅の間隔が気になりだした。

改装のついでに、TDMモード送信実験の前段階としてTDMに使用する通信端子の設定を行ってみた。 SCL0とSDA0をアサインする端子には、FPGAのラッチ信号を出力するためにリザーブしていた16・17番を使用する。

とりあえず、端子に通信機能を持たせるALT2にモードを切替える設定だけは行えているようだが、実際に使う段になると何をどうやればよいのかサッパリ理解していないので、ADMP1701の評価キットが到着次第TDMによる音声多重通信の実用化に向けて、これからフォーマットを学習していかなければならない。
posted by Yasuski at 21:30| LaVoixski

2019年03月11日

LEDの表示モードを変更する

空きチャンネルに搭載した新機能の判別が辛くなってきたので、LEDによる表示機能を追加した。

WS001762.JPG

Op3Modeは、選択したOscillator順に GRN/BLU/RED/PUR/YEL を、DistortionSWのオン・オフには SKY/RED TransitionControl/Sin/Exp.Sin の切替えには PUR/SKY をそれぞれ設定している。

改修の過程でDistortionSWの切り替えを検知するためにD13のStatusを読もうとしたところ、何故か読みだすことが出来ず。 対処法としてスイッチングを行う選択分岐の部分にスイッチングを行うための関数を代入している。 

PinのStatusが読めない案件は以前から偶に発生しているが、D13にはTeensyのボード上でLEDに接続されており、この回路によって発生する電圧降下がStatus"HIGH"の認定を阻んでいる可能性がある。 

何れにせよ、これは物理面の問題が疑わしく、MCUから外部に接続を行う際には必ずバッファーを挿入することを心掛けたい。
posted by Yasuski at 17:06| LaVoixski

2019年03月10日

Transition Control の制御波形に expSin を追加する。

何気に読んでいた大塚明氏のサイトからexpSinという概念を仕入れたので、

WS001755.JPG

これをあまりピーク値が重なって欲しくないオシレーターのtransitionコントロールに応用できないか、実験で試すことにした。



まずは下準備として、GNU/Octaveでヴォリュームを制御するための波形を生成する。 テンプレートには、以前記述したSin波を生成するコード使った。 Sinの手前にexpを書き足した後、カットアンドトライでオフセット値を探っていく。

WS001760.JPG

WS001756.JPG

WS001757.JPG

WS001758.JPG

WS001759.JPG

当初は12bit精度で縦軸を設定したファイルを単体で試してみたが、音像の分解能が上がって、和音が美しく聞こえるようになった反面、OverDrive系の出音にパンチが無くなってしまった。

これでは本末転倒なので、処理ステップ及びRAMの消費量が上がってしまうが、波形を使い分けられるようにスイッチ機構を組み込んで、旧来のファイルと設定が共用できるようにシステムの改変を行った。

Screen Shot 2019-03-10 at 16.23.42.png

問題は、現用していた11bitスケールの波形との整合性で、アッテネーターの値をどう工夫しても境界値のコントロールが行えなくなってしまった。 結局、expSine波のスケールを11bitに縮小して再度試してみたところ、スムーズな動作を確認できた。

WS001755.JPG

確かにこれは便利な機能で、和音演奏時のミックス具合を変更して、出力の飽和状態をコントロールすることが可能となった。

ちなみに、大人しい音色を使用した時には、効果の違いを殆ど感じられなかった。

Transition波形の切り替えスイッチには何故かアナログ部のスイッチ機能が「死んだ」状態で放置していたLevelControlを充て、出力端子のステイタスを波形の切り替えに反映させている。
posted by Yasuski at 17:40| LaVoixski

2019年03月09日

OutputCh#3に波形変換システムを導入する

元ネタは”Arduino Music and Audio Projects”の巻末近くに掲載されていたAudio Excitationという記事で、TransferFunctionを使って倍音構成を変化させる仕組みが紹介されていた。

この楽器は、5つのオシレーターによって波形合成を行う音源で構成されていて、現在第3出力にはオシレーター単体の出力をアサインしている。つまり、ここでピックアップされるのは単純なサイン波となる可能性が高く、その場合は少々パンチの乏しい音色となってしまうのが難点だ。 

今回の改装では、波形合成との兼ね合いで矩形波やノコギリ波等「エッジの効いた波形」をアサインすることが出来ない場合に音色を変化させる方法として、先の記事に記載されていたWavetableによる波形変換システムを導入している。

WS001748.JPG

WS001749.JPG

導入を試行した当初は参照するWavetableをリアルタイムで組み替えようとしていたのだが、結果は失敗だった。 Dueを使って(オリジナルの記事による)AudioClockのタイミングでそれを行うのはExciterを単機能のみで実装した状態であっても流石に無理な話。 実際の回路は任意のタイミングでプッシュスイッチを押して、ヴォリューム・ポットの状態をアップロードする仕組みだった。 

記事を読み飛ばしていた自分がそそっかしいのだが、ポットの状態が即出音に反映されないのはいささか残念な仕様ではある。 記事の内容に沿って、プッシュスイッチによりデータエントリーを行う構造に修正した結果、音声の出力を確認することができた。



ついでに、RGBロータリーエンコーダーにポットの状態を点滅速度で表示するギミックを追加しておいた。 

WS001753.JPG

点滅間隔が長くなるほど値が大きくなる表示方式で、最長0.5秒間隔でLEDが点滅する。

データトランスファーはオシレーターの音量調整ポットを流用する関係で、5倍音まで設定が可能な仕様とした。 記録は、トップ側のノブをch9に選択してエンコーダーのトップを長押しして行う。 

WS001751.JPG

現状はメモリー数を1chとしているが、今後必要に感じた場合はさらに記録バンクを増設する可能性もある。

WS001752.JPG
posted by Yasuski at 17:48| LaVoixski

2019年03月08日

SigmaDSPの導入について

ADAU系列のDSPは導入の敷居が高いが、スタンドアロンで動くこのチップを扱った記事はハードルを超えるためのヒントになる。

Webを漁ると製作例が上がっていて、ハードを販売している人も居るようだ

最終的にはこのコードが使えそうなので、DSPの試作ボードを購入してテストを行うことにした。

1401traningKit.jpg

ただ、このチップを含めた最近のオーディオ製品は通信をI2Cで行うために、DACとして使用する場合にボトルネックの問題が出てくるかもしれない。 所謂「バーストモード」がMCU側の設定で使えるかどうかが決め手になるだろう。

DSPを使用する利点は、それ自体にオシレーションを行わせられそうなところで、波形の生成を外部に丸投げして、I2C/S等のシリアル伝送によって生じるデータトランスファーのボトルネックをスキップできる可能性がある。

オーディオデータのハンドリングに話を戻すと、LRCLKでオーディオデータを受けていては出力が間に合わないので、3ch以上の出力を行う場合は否応無しにTDMモードを選択することになる。 TDMフォーマットに関しては良く判っていないので、参考のために具体的な製作例を探したほうが良いだろう。 

ADAU1701はデジタルオーディオ・フォーマットを直接出力できるので、MCUからDACに至る間に発生していた遅れ時間を気にせずに外部に設置したDACにデータを放り込める利点がある。 入出力で通信モードを切替えられそうなので、adatフォーマットに拠る通信を行えるかもしれない。
posted by Yasuski at 21:03| LaVoixski

2019年03月06日

chronoの導入

オマケ機能で実装している sequecer は、無音時にもステップを進める設定だが、これが意外と使い難いことが判明している。

要は曲を演奏中にブレイク出来ないということで、ならば改良のために条件分岐を使って無音時にカウントを休止する機能を実装しようとしたが、何故かmetro環境下ではどうやってもクロックをストップ出来ない。 

この問題に対処すべくchronoという新し目のライブラリを見つけてmetroと換装することにした。



chronoについての詳細はリンク先を参照してもらうとして、chronoは定常的にクロックを発生させるmetroとは異なり、インターバルが終了したあと常にrestartコマンドによってリトリガーを掛けなければ反復する信号を生成できない、所謂ワンショット系のデバイスを模したものとして考えればよいだろう。restartを行うまでは静的な状態を保持する一方、stopコマンドで一旦クロックの生成を停止できるところが今回の用途にぴったりだ。

Screen Shot 2019-03-06 at 7.58.52.png

クロックを駆動するトリガーは、目玉スイッチのLEDと連動させている。 実際に運用を行ってみると、テルミンは出音の立ち上がりが遅く、sequecerの発音が遅れてしまうように感じることがあった。 ただし、これは用法で解決すべき問題なので、今後は実際の演奏体験を通じて特性に合わせた運用を模索していくことになる。
posted by Yasuski at 09:55| LaVoixski

2019年03月04日

FVCの「丸め」を行う手順の修正など

今日は、テルミンの周波数ディテクター周りのコードをいじっていたのだが、間違った手順でデータを丸めていたことを発見、その部分の修正を行った。

Screen Shot 2019-03-04 at 15.20.20.png

要は、EMAで「データの丸め」を行った後に、暴れている元信号の差分を追加するというマヌケなことをやっていたのだが、改良の結果データのバラつきを格段に抑えることが出来た。 今後はEMAにプリセットする数値を調整していくことになる。

一方、動作が不安定で使用を諦めていた「ClickEncoderを排除した試作コード」に、無駄な処理ルーチンをスキップするbrakeポイントの追加やRAMの使用量を圧縮する改良点を思い付いたので、該当箇所の修正を行った後に再度運用をトライした。

Screen Shot 2019-03-04 at 13.54.13.png 

ロータリーエンコーダーの入力にノイズサプレッサ用のCを取り付けない機械的に不備な状態下でのテストではあったが、出音に関しては正常な動作を確認できた。 起動時にチューニングノブの規定値がClickEncoder使用時と大幅にズレることから、処理時間の圧縮に関してはほぼ成功していると思われる。

今後プラットフォームを変更する場合には、Arduinoのライブラリに頼らないこのコードを中心に開発をすすめることが可能となった。

追記:

後日、低域の安定度がどんどん低下する案件が発生、コードの不備を疑うも過去の経験から物理的な要因の気配があったので、繰り返しキャリブレーションとチューニングを繰り返した結果、キャリブレーションによって得られるイニシャル値には明らかな適正値が存在することを確認した。 ピッチ・アンテナ側とは逆ベクトルで操作を行うヴォリューム・アンテナ側ではこの値が明白で、データ取得時に設定しているリミッターのフルスケール16383がそれに相当する。

もう一方のピッチ・アンテナ側だが、こちらはデータを扱うベクトルがヴォリューム側とは逆になるため、単純に最適値を算出することが出来ない。 

イニシャル値の決定は、入力信号のアップエッジでフリーランするカウンタの値をキャプチャした結果から「差分値を引き出す」ディテクタ側のセンシングのメソッドと、カウンタをドライヴするクロックの分周率から影響を受ける。 MCUのシステムクロックや、クロック入力に設けられたフィルター等、関連するパラメーターが多過ぎて明確な回答を出すことが難しいが、カウンタのオーバーフローによって発生する字余り状態が誤動作の原因となることから、ピッチ側オシレーターのセンシングエリアの設定をオーバーフローが発生しない領域よりも上に持ち上げることが安定度をアップするための最適解といえるだろう。

ただし、この数値は楽器の発音域とのトレードオフで折衷することになるため、新たにアンテナ長等の楽器を構成する物理要因が絡んでくる。 よって機種依存しない普遍的な数値を出すことは難しいが、実測を繰り返した結果、イニシャル値20000前後が実用域なのではないか?と予想している。

現時点で実験に使用している楽器の発振器は設計に問題があり、より安定した性能の発振器を使った実験環境を構築しなければならないのだが、新たに設計した基板には配線ミスが発覚している。 修正版のオシレーター基板はすでに設計を終えているので、今月中にはこれを発注する予定。
posted by Yasuski at 18:06| LaVoixski