chronoの導入

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

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

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



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



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

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

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



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

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

　

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

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

追記：

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

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

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

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

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

pgm_read_word_nearの削除を行う

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



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

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



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

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



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

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

追記：

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



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

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

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

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

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

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

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

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

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

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

Spresenseに関する愚痴

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



最近になってようやくオンライン上にある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に寄せてきてるのでポートが足りないし、現状でサードパーティーが何かを出してくる気配は殆ど感じられない。



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

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

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



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



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

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

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

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

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

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



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



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

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

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

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



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

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



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



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

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

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



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

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

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



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

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

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

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

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

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



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



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

STM32F407ZET6ボード

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

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



単価は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を書き込んで、ポートアサインの確認を行った。　



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



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



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

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

追記：

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



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

ロータリーエンコーダーの実装に関して

ここ数日間、新規に導入を検討しているロータリーエンコーダーシステムの実験を行っていたのだが、どうやっても増／減同一方向にしかカウントできない案件が発生。　当初はロータリーエンコーダーの故障を疑ったが、端子を変えても同じ動作をする。　また、プログラム側で極性を変えた場合でも、同一方向にのみカウントが亢進してしまう。

これは明らかに物理の問題なのだが、試しにPinA/Bに接続したノイズサプレッサ用のコンデンサを交換してみても状況は一向に改善しない。　回路的には変移する入力ステイタスのタイミングを見て、増減の方向を判断しているのだが、多分「特定パターンの変移」が読めないためにおかしな動作が発生しているようだ。

元記事を読んで、これが328向けに書かれたコードだったことを確認したが、328と比較して無闇矢鱈と処理速度が速いK-66では「pinの変移が読めないかもしれない」ことに気付いた。　

で、試しに数クロック分の無駄なタスクを追加した結果、



ロータリーエンコーダーの正常な動作を確認できた。



NOPは、無駄な動作を行っていないか確認を行うためのダミー。　pinに変移が発生した時のみ、タスクの処理を行っている。



プラマイ両極性の変移も良好。　ノイズサプレッサの威力は絶大で、見事に誤動作を排除している。

動作が確認できたので、これもダミーで本来のシステムに近い状態を作って実験を行ってみたが、ひとつのカウンタを使い回す状態ではポットの個別データを保持することが出来ない。



結局、ポット分のカウンタをロータリーエンコーダーの変移感知ルーチン側に仕込んで、スイッチで切り替えることになったが、これをパラメーターが多い側に仕込むのは結構な作業量になってしまう。



結果的にはこうなってしまったわけだが、まともに動かせる自信がなくなってきた。　実際、RAMの使用量は94%に突入しているので、ここ数日の努力が無駄に終わってしまう可能性が疑われ始める。



ポットの状態を管理するルーチンは、元のコードと比べて工程数が激減するわけでもなく、実際にMCU側の処理ステップ数で時間を計測してみたら存外遅延が増えている可能性もあるが、Timerで設定されたタイミンで定時に連絡を取りに行かないところがアドヴァンテージとなる筈だ。



とはいえ、導入には巨大なカウンタのクラスタを生成する必要があり、そろそろメモリの余裕が無くなってき￥た。　従来はローカル関数で処理していたのだろうが、これらのアドレスが固定されてしまった状況で、はたしてシステムが正常に動作するのか？　実験を行って確かめたいところだが、その前にノイズサプレッサ＝コンデンサの仕込みを行う必要がある。



一方、クリックを検出する機構はループの巡回毎に端子の状態を読みに行くが、こちらの処理は軽く、遅延の発生は最小限に抑えられる。

クリック・ダブルクリックを行う毎にpotの読み出しアドレスを増減するインターフェイスの構造は従来のものと同じ。　ただし、アクセス時にpotの値を読み込まないので、無駄なデータの処理にタスクを割かれることはない。

このように、バックグラウンドの処理を極力抑えられたのは良いことなのだが、パラメーターの移植は大変な作業になった。

添付してたライブラリ類がなくなって、ソフトウエアのパッケージとしてはかなり身軽になったように錯覚したものの、本体はデータ別腹で４万行超えている。　物理面でもメモリをバカ食いしてるのが大問題で、ウエーブテーブル等はClass10とオーヴァースペックなmicroSDから直読みすればいけそうな気もするんだが、現行システムでは何故か通信のデータレートが激遅過ぎるので、それは無理っぽい。

追記：

実験の結果、残念ながらattatchInterruputを使用したロータリーエンコーダーの導入は失敗に終わった。

理由は憶測ではあるが、オーディオクロックの立ち上がり毎にハードなタスクをこなさなければならない状況の中で、他の外部端子からのスイッチングに拠るインターラプトが競合した場合に、ロータリーエンコーダー側の入力が競り負けてしまう現象で、入力に対する反応が安定せず、正常な動作を保証することができなかった。　

比較実験の過程で、奇しくもClickEncoderのセンシング・レートを低く設定した時に入力の精度が落ちる似たような状況に陥ってしまった。　センシングの頻度を下げた場合は、フリーランするループ内でエンコーダーの状態を反映するタイミングを外してしまい、結果としてエンコーダーの動作がおぼつかなくなることが判った。

ピッチの揺れに関する問題は、新規に導入した読み出しシステムの環境下で若干の改善が見られたが、インターラプト起動時に発生するタスクの変化が音声に反映される弊害も発覚している。　これにより、ロータリーエンコーダーの使用に伴って発生する処理演算のタスクが音声に影響していることを証明する形になったが、楽器としての実用性を考えた場合、出力音声が外乱からの影響を受ける現象を看過することが出来ない。

よって、計画は棚上げ・中止とすることが決定した。　

ロータリーエンコーダーが消費するプロセッシングパワーについて

現在採用しているclickEncoderはTimer1に設定した1000usのタイミングに従って定期的にロータリーエンコーダーが接続された端子のセンシングを行っているが、毎時データを参照する分だけどうしてもタスクが増えてしまう。



オーディオクロックを基準にすると1000usは1kHzとなるが、1ms毎に発生するタスクは結構大きなものがある。

フリーランさせているLoopルーチン内で発生する無駄なタスクの増加を解消するために、ロータリーエンコーダーからの入力をattatchInterruptで検知させて、その都度出力を行う方式への転換を検討している。



clickEncoderを排除する手前、ダブルクリックの扱いにも変更を行うことになる。