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

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

2019年03月03日

pgm_read_word_nearの削除を行う

前のシステムの名残だった pgm_read_word_near を

WS001741.JPG

コード上から削除して、シンプルな記述に書き換えた。

本来はROMエリアに格納したデータアレイを参照するためのコードだったものを、処理スピードをアップするためRAM上にデータを展開した後も使っていたのだが、記述を変えることによって何らかの変化が生じるかもしれない。

WS001742.JPG

処理上のステップが改変後に1.5%程増加した一方、RAMの使用量に変化はなかった。 

コードを改変する前のヴァージョンでコンパイルを行った時の画像を示す。

Screen Shot 2019-03-02 at 13.22.26.png

こちらのコードではVolumeControl関連のルーチンから pgm_read_word_near を既に排除している。

ステップの増加イコール処理スピードの低下とは単純に言えないので、実際に運用して確かめてみるしか無いが、その差1,5%という数字は尋常では無いために、どういった変化が生じるのか気になってくる。

追記:

実験の結果、正常に発音することが出来た。



改変前には44.1kHzにオーディオクロックを設定した時に特定のシチュエーション下でフリーズが発生していたが、今回の改変でこれが解消された模様。 つまり、処理能力のキャパシティーに余裕ができたということで、この件によって処理の合理化の達成を確認できた。
posted by Yasuski at 04:55| LaVoixski

2019年03月02日

Wavetableを使って出力信号にコンプっぽいものを掛ける実験

昨日作ったWavetableを使って出力信号にコンプっぽいものを掛ける実験を行った。

単音を出力する場合は「少々歪みっぽい」程度の変化だったが、総体的にはあまり良い印象を受けなかった。

入力レベルが増加する和音やOVERDrive系の音源となると、マイルドに設定していた過渡領域が全て無効になる始末で、システムの稼働実績は確認できたものの、その有効性には大きな疑問が生じることになった。

多分、チューニングを詰めれば再現性の高い効果が得られるのだろうが、出音に制御波形そのものの性格が反映される為に、実際にカット&トライを行う場合のハードルは高いものとなるだろう。

因みに、現行のシステムでは条件分岐によって入力の過渡的な変動値を圧縮しているが、この処理を24bitで行っているのがポイントで、それを16bitで行おうとした場合にどうしても粗が出てしまうようだ。 特にoverdrive系のような過渡特性が命な音源のコントロールは非常に難しいと結論することになった。

確かにデジタルドメインの非線形処理は対周波数特性等の解決すべき難問が待ち構えている案件で、大メーカーが開発に携わったものの撤退しているような難物故に、ウエーブテーブルによる波形の書き換え程度で容易に結果が得られる筈がないのではあるが。

自分の場合、最終的にはアナログ頼りなところがあって、勝手にいろいろな計算をしてくれるアナログ素子は便利なので、頼るべきところは頼ったほうが良いと判断するのが信条だったりする。

実験はひとまず失敗に終わった形だが、出力波形そのものをより動的に制御できる手段が実現できたのは心強い。 また、Wavetableに搭載する波形に関しては、メモリー管理の関係でそれらを削っていく過程で「無駄だと思っていた構成」がそこそこ必要とされるものと再確認することが出来た。予め複雑な「形を仕込んだ」波形を揃えるよりも、倍音関係にある単純な波形を準備して、それらに動的な制御を行ったほうがより効果的に音造りが出来そうだ。
posted by Yasuski at 21:10| LaVoixski

Spresenseに関する愚痴

世間というかGoogleで検索しても何故かネガティヴな情報が出てこない、というかそもそも話題が殆ど流れていないSpresenseに関しての個人的な見解というか愚痴をつらつらと書いていく。

overview_hardware_mainboard_signal-2.jpg

最近になってようやくオンライン上にあるSpresenseのディベロッパー向けマニュアルが充実してきたので中身を検討していたが、Timerやカウンタの機能が単純化されていて、外部トリガでカウンタの値をキャプチャするようなMCUに有りがちな使い方が想定されていない印象を受けた。

ハード的にチップの構成はどうなっているのかを知りたいのだが、アップロードされているPDFの内容が相変わらず適当過ぎるのが解せない。

まあ、家電屋系半導体のアプリケーションノートは昔からあんな感じだったので、このスタイルは伝統でもあるのだろう。NXPやSTMの分厚いマニュアルからするとペラ過ぎるSONYのアレがその傾向を象徴している。

確かに、あの2000頁もあるユーザーズマニュアルを「読みこなせ」とか言われてしまう現状は異常とも言えるのだが、そのレベルの難解で複雑な代物の解説が「たったの52p」というのは異様を通り越して非常にマズイのではないか。 しかも、発売から半年経った現在も末尾にRevの履歴が一切かかれてないのがこれまた凄い。 

https://www.sony-semicon.co.jp/products_en/spresense/PDF/CXD5602GG_technical_manual.pdf

pinの対応表を見ると、カウンタ関連の外部トリガが見当たらないので、これは自分の想定する用途には「使えない」ハードウエアである可能性が高くなった。 拡張ボードはわざわざUnoに寄せてきてるのでポートが足りないし、現状でサードパーティーが何かを出してくる気配は殆ど感じられない。

block_diagram_mainboard-1.jpg

デジタル化以降のWalkmanの失敗を見ても判るように、何処かピントがズレているのではないか。 オープンソースを謳うのであれば、ハードウエアの仕様公開は一番先にやるべきことなのに、どうも其辺のメーカーとしての思惑が解らない。 至極使い難いツールを出してくるのも同様で、STMの便利そうなツールを試した後はなおさらそう感じてしまう。

製作例は初歩的なものしか上がってないようだ。 ハイレゾとかあまりよく解らない価値観のものをプッシュして来るのが企画屋のプレゼン的な雰囲気で、これまたMakerっぽい人らの嗜好とは少しズレている気がする。  今後はトラ技の記事等から製作例が出てくるのだろうか。 ちなみにトラ技はどちらかというとGPS系の記事に注力しているように見える。

相変わらずTimer周りが気になるので、製作環境となるNuttXの構成を調べたところ、対応するチップ別に端子が設定されているコードを見つけた。

WS001739.JPG

で、肝心のCXD5602を探して見つけたのがこれ。

WS001738.JPG

つまり、外部からTimerを直接制御する端子は存在しないようだ。

これで諦めが付いたので、とりあえずSpresenseを実験機として購入してみよう、、、と、なんとなくというか何度目かの結論に至る。

Timerが3つあるので、それらをフリーランさせたのをGPIO設定した端子からattatchInterruptでカウンタの値をキャプチャすれば、なんとかFVCを構成できるかもしれない。 

タイマーの数や仕様をケチったのは、省電力化をメインに考えたためなのだろうか、、、と、先に読んだ記事から思い当たった。 

SONYはこれをNXPやSTと競合するような汎用性の高いMCUとしては開発していない可能性がある。つまり、顧客として想定しているユーザー層が先行しているMCUメーカー達とは全く違うのではないか。 ただ、そのターゲットとしているであろう対象そのものの形が明確に見えてこない。 AI云々をメインに言い出しているのも対象が茫洋としすぎているためにあまり印象が良くないが、実際のところは車載用のパターン認識システム等に応用したいのだろうか。 カメラとGPSという組み合わせからは、それっぽいベクトルを感じる。

Spresenseを自分の楽器に応用するためには、ロータリーエンコーダーとLED周りで16本、スイッチ類の表示用LEDを含めた入出力が6本以上、周波数入力に端子が2つと、合計24本の端子が要る。 だから出来ればpinが一杯取り出せるボードが欲しいところなのだが、現時点では端子拡張系の製品を出してくる気配がどこからも感じられないのが残念だ。 

overview_hardware_extboard_signal-2.jpg

あまり使い手の無さそうなマイク端子群をデジタル入出力として使用できないか、購入前にGPIO周りの仕様を検討なければならない。 

HW_Mic_placement_E-2.png

なんにせよ、アナログ入力固定な端子群を設定しながら「Unoと共通仕様でシールドを使えます」とか言っちゃう辺りの適当さが不思議な設計思想ではある。

開発はRTOSの使用が大前提となるが、それ以前に動くのがUbuntuだけとかシロートには敷居が高過ぎるのだが、去年の後半にまずはOSの使い熟しからトライすべく、実験的にOSの導入を試みたものの、開発環境を導入するどころではない状態が継続したまま半年以上の時間が過ぎた今はもう3月だ。

posted by Yasuski at 07:38| AudioElectronics

Wavetableを使用したコンプレッサーの実験

処理のタスクを少しでも減らせるように、このような非線形処理を行っているルーチンを省力化出来ないか検討を行った結果、GNU/Octaveを使って、出力波形圧縮用のWaveTableを作ることを思い付いた。 。

WS001268.JPG

問題はメモリーの残量だが、実際に24bitデータをリザーヴするのは非現実的で、そもそも処理が重すぎてOctaveからデータアレイを出力することができなかった。

いっそのこと理想としていた24bit/adatフォーマットを諦め、16bit長でデータをやりくりするという割切りもアリではある。  結局、16bit×16bitのデータは難なくアウトプット出来たが、、、

WS001735.JPG

これを適応させた場合、出力波形は相当なレベルで歪むことになる。

WS001734.JPG

解像度を上げると結構ガタガタになるが、まあこんなものであろう。

例えば、真空管アンプの実際の歪率は物凄いことになっているのだが、アレはアレでというかあっちのほうが音圧があって味を感じてしまうのが人情なので、出音が気に入るのであれば「波形のピュアさ」などという視点は無視したほうが良いのかもしれない。

で、予想はしていたがメモリーの総量が限界を超えてコンパイルが通らなくなったので、システム全体のダイエットを行うことにした。 まずは64bit長でエントリーしていた関数全てを32bit長に修正したところ、なんとメモリーの余裕が30%も増えた、、、。

WS001736.JPG

次に、エントリーしているWavetableのうち、cos波形を排除してRAMの使用量をさらに圧縮した。

全体に余裕ができたので、音量調整用の16bitFileをエントリーしてみたが、何故かRAMの使用量が二倍になって仕舞い、破綻が発生することが判った。

ローカルで関数を宣言しないのが正解かも?と考えて、Volume制御系のデータArrayに、出力直をアサインしてみたが、、、

WS001737.JPG

これもアウト。 サブルーチン上にWavetableを展開するとメモリーをリザーブしただけでは済まず、実質的にダブルエントリーとなってしまうようだ、、、。

結局、今回はコンプ機能の導入を諦めることになったが、どうしても出音が気になってくる。 

明日は徹底的にWavetableのダイエットを行った実験用のプラットフォームを作って結果を試してみよう。

ちなみにこの方式を応用すると、リングモジュレーターやFM音源が作れそうだ。

posted by Yasuski at 03:40| LaVoixski

2019年03月01日

タイマーカウンタのセットアップ

CubeMXは、このようにタイマーカウンタをセットアップするためのコードを吐き出してくれる。

WS001732.JPG

Arduinoで記述していたこの部分のコードがそれに相当する。

WS001559.JPG

データブックを引かなくてもさっさとコードを吐き出してくれるのはとても便利だ。

WS001727.JPG

WS001728.JPG

WS001729.JPG

WS001726.JPG

WS001730.JPG

WS001731.JPG



posted by Yasuski at 13:49| AudioElectronics

STM32F407ZET6ボード

去年の年末辺りからTeensyへのオルタナティヴとなりそうなボードを探っていたのだが、高性能なSpresenseは敷居が高すぎるうえに今のところ開発に必要なデータが揃わない。

そこで、まずは手軽に試せそうな STM32F407ZET6 を搭載したボードをArduinoに対応させてみた。

IMG_8942.JPG

単価は1.3k程と激安だが、オーバークロックさせない素の状態では168MHzと処理能力はシステムクロックを最高速に設定したTeensy3.6の2/3位になるだろうか。 Spresenseとは違って、出せるpinを全て引き出している構成がとても好ましい。

Brand: Unbranded/Generic
Markings: STM32F4XX STM32_F4XX V3.0 1606

Specs:
STM32F407ZET6 ARM Cortex M4
168MHz, 210 DMIPS / 1.25 DMIPS / MHz
1.8V - 3.6V operating voltage
8MHz system crystal
32.768KHz RTC crystal
2.54mm pitch pins
JTAG/SWD header
512KByte Flash, 192 + 4 KByte SRAM
3x SPI, 3x USART, 2x UART, 2x I2S, 3x I2C
1x FSMC, 1x SDIO, 2x CAN
1x USB 2.0 FS / HS controller (with dedicated DMA)
1x USB HS ULPI (for external USB HS PHY)
Micro SD
Winbond W25Q16 16Mbit SPI Flash
RTC battery CR1220
1MB SRAM footprint, unpopulated (IS62WV51216-1M)
1x 10/100 Ethernet MAC
1x 8 to 12-bit Parallel Camera interface
3x ADC (12-bit / 16-channel)
2x DAC (12-bit)
12x general timers, 2x advanced timers
AMS1117-3.3V: 3.3V LDO voltage regulator, max current 800mA
Micro USB for power and comms
Yellow user LED D1 (PF9) active low
Yellow user LED D2 (PF10) active low
Yellow power LED D3
2x jumpers for bootloader selection
Reset button, Wakeup button, 2x user buttons K0 (PE4) and K1 (PE3)
2x30 side pins + 2x16 bottom pins + 1x4 ISP pins
2x16 FMSC LCD Interface
NRF24L01 socket
M3 mounting holes
Dimensions: 95.1mm x 74.6mm

ボード側のピン接続はこうなる。

<-----+
|_1 _2| Pin 1 = 3v3
|_3 _4| Pin 4 = GND
|_5 _6|
|_7 _8| Pin 7 = SWDIO
|_9 10| Pin 9 = SWCLK
|11 12|
|13 14|
|15 16|
|17 18|
|19 20|
<-----+

当初はボードが認識されずにあれこれ試行錯誤を行っていたが、単に配線が外れているだけだったという何時ものマヌケぶりを発揮してしまった。

凡ミスを防ぐために、書き込みケーブルには専用のコネクタ付きのものを購入したほうが良さそうだ。

今回は、Arduino IDEからBlinkLEDを書き込んで、ポートアサインの確認を行った。 

WS001723.JPG

Pinナンバーは数字単体ではなく、回路図にあるようにPF9と記述すれば良いようだ。 コンパイルには結構な時間が掛かっている。 単なるBlinkに数分掛かるようではこの先が思いやられてしまう。

WS001724.JPG

ボードへのデータの書き込みはST-Linkを介して行うことになる。 ST-Linkはファームウエアやドライバのアップデートを確認出来るUtilityを併用すると便利だ。

WS001721.JPG

何れは使用するであろう直アサインの記述は、MCUのアプリケーションデータで確認する必要がある。

STM32F4シリーズは、カウンタの構造などチップの構成がTeensyで使い慣れたFreeScaleのMCUとは大幅に異なるので、これからデータブックを読み込んでいかなければならないが、もしかするとST製のM3を搭載した Due に近い命令体型なのかもしれない。

追記:

KeilにExampleコードを引っ張ってきて検討しているところだが、Timerの構成はFreescaleのものと比べて複雑な印象がある。 あまりに項目が多くて選択肢がつかめないので、予め必要とされる機能を選択した使用例を探した方が早道だろう。

WS001725.JPG

基本的にはリングカウンターの瞬間値を入力PINのアップエッジでキャプチャー出来れば良いだけなのだが、入力信号の分周まで出来てしまうのが便利なのかどうか? 構造をよく理解していない現時点では何とも言えないがが、もしかするとコード側にも根本的な構造の改変が必要になるかもしれない。
posted by Yasuski at 06:22| Arduino