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