Sequencer使用時に「どの曲をセレクトしているのか判らなくなる問題」が発覚したので、メモリーCH毎に*Blink*するLEDの発色を変えることにした。
曲を選択する毎に色が変わって視認性が格段に向上したが、今度は点滅の間隔が気になりだした。
改装のついでに、TDMモード送信実験の前段階としてTDMに使用する通信端子の設定を行ってみた。 SCL0とSDA0をアサインする端子には、FPGAのラッチ信号を出力するためにリザーブしていた16・17番を使用する。
とりあえず、端子に通信機能を持たせるALT2にモードを切替える設定だけは行えているようだが、実際に使う段になると何をどうやればよいのかサッパリ理解していないので、ADMP1701の評価キットが到着次第TDMによる音声多重通信の実用化に向けて、これからフォーマットを学習していかなければならない。
2019年03月12日
LEDの表示モードを変更する（その２）
posted by Yasuski at 21:30| LaVoixski
2019年03月11日
LEDの表示モードを変更する
空きチャンネルに搭載した新機能の判別が辛くなってきたので、LEDによる表示機能を追加した。
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から外部に接続を行う際には必ずバッファーを挿入することを心掛けたい。
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という概念を仕入れたので、
これをあまりピーク値が重なって欲しくないオシレーターのtransitionコントロールに応用できないか、実験で試すことにした。
まずは下準備として、GNU/Octaveでヴォリュームを制御するための波形を生成する。 テンプレートには、以前記述したSin波を生成するコード使った。 Sinの手前にexpを書き足した後、カットアンドトライでオフセット値を探っていく。
当初は12bit精度で縦軸を設定したファイルを単体で試してみたが、音像の分解能が上がって、和音が美しく聞こえるようになった反面、OverDrive系の出音にパンチが無くなってしまった。
これでは本末転倒なので、処理ステップ及びRAMの消費量が上がってしまうが、波形を使い分けられるようにスイッチ機構を組み込んで、旧来のファイルと設定が共用できるようにシステムの改変を行った。
問題は、現用していた11bitスケールの波形との整合性で、アッテネーターの値をどう工夫しても境界値のコントロールが行えなくなってしまった。 結局、expSine波のスケールを11bitに縮小して再度試してみたところ、スムーズな動作を確認できた。
確かにこれは便利な機能で、和音演奏時のミックス具合を変更して、出力の飽和状態をコントロールすることが可能となった。
ちなみに、大人しい音色を使用した時には、効果の違いを殆ど感じられなかった。
Transition波形の切り替えスイッチには何故かアナログ部のスイッチ機能が「死んだ」状態で放置していたLevelControlを充て、出力端子のステイタスを波形の切り替えに反映させている。
これをあまりピーク値が重なって欲しくないオシレーターのtransitionコントロールに応用できないか、実験で試すことにした。
まずは下準備として、GNU/Octaveでヴォリュームを制御するための波形を生成する。 テンプレートには、以前記述したSin波を生成するコード使った。 Sinの手前にexpを書き足した後、カットアンドトライでオフセット値を探っていく。
当初は12bit精度で縦軸を設定したファイルを単体で試してみたが、音像の分解能が上がって、和音が美しく聞こえるようになった反面、OverDrive系の出音にパンチが無くなってしまった。
これでは本末転倒なので、処理ステップ及びRAMの消費量が上がってしまうが、波形を使い分けられるようにスイッチ機構を組み込んで、旧来のファイルと設定が共用できるようにシステムの改変を行った。
問題は、現用していた11bitスケールの波形との整合性で、アッテネーターの値をどう工夫しても境界値のコントロールが行えなくなってしまった。 結局、expSine波のスケールを11bitに縮小して再度試してみたところ、スムーズな動作を確認できた。
確かにこれは便利な機能で、和音演奏時のミックス具合を変更して、出力の飽和状態をコントロールすることが可能となった。
ちなみに、大人しい音色を使用した時には、効果の違いを殆ど感じられなかった。
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による波形変換システムを導入している。
導入を試行した当初は参照するWavetableをリアルタイムで組み替えようとしていたのだが、結果は失敗だった。 Dueを使って（オリジナルの記事による）AudioClockのタイミングでそれを行うのはExciterを単機能のみで実装した状態であっても流石に無理な話。 実際の回路は任意のタイミングでプッシュスイッチを押して、ヴォリューム・ポットの状態をアップロードする仕組みだった。
記事を読み飛ばしていた自分がそそっかしいのだが、ポットの状態が即出音に反映されないのはいささか残念な仕様ではある。 記事の内容に沿って、プッシュスイッチによりデータエントリーを行う構造に修正した結果、音声の出力を確認することができた。
ついでに、RGBロータリーエンコーダーにポットの状態を点滅速度で表示するギミックを追加しておいた。
点滅間隔が長くなるほど値が大きくなる表示方式で、最長0.5秒間隔でLEDが点滅する。
データトランスファーはオシレーターの音量調整ポットを流用する関係で、5倍音まで設定が可能な仕様とした。 記録は、トップ側のノブをch9に選択してエンコーダーのトップを長押しして行う。
現状はメモリー数を1chとしているが、今後必要に感じた場合はさらに記録バンクを増設する可能性もある。
この楽器は、5つのオシレーターによって波形合成を行う音源で構成されていて、現在第3出力にはオシレーター単体の出力をアサインしている。つまり、ここでピックアップされるのは単純なサイン波となる可能性が高く、その場合は少々パンチの乏しい音色となってしまうのが難点だ。
今回の改装では、波形合成との兼ね合いで矩形波やノコギリ波等「エッジの効いた波形」をアサインすることが出来ない場合に音色を変化させる方法として、先の記事に記載されていたWavetableによる波形変換システムを導入している。
導入を試行した当初は参照するWavetableをリアルタイムで組み替えようとしていたのだが、結果は失敗だった。 Dueを使って（オリジナルの記事による）AudioClockのタイミングでそれを行うのはExciterを単機能のみで実装した状態であっても流石に無理な話。 実際の回路は任意のタイミングでプッシュスイッチを押して、ヴォリューム・ポットの状態をアップロードする仕組みだった。
記事を読み飛ばしていた自分がそそっかしいのだが、ポットの状態が即出音に反映されないのはいささか残念な仕様ではある。 記事の内容に沿って、プッシュスイッチによりデータエントリーを行う構造に修正した結果、音声の出力を確認することができた。
ついでに、RGBロータリーエンコーダーにポットの状態を点滅速度で表示するギミックを追加しておいた。
点滅間隔が長くなるほど値が大きくなる表示方式で、最長0.5秒間隔でLEDが点滅する。
データトランスファーはオシレーターの音量調整ポットを流用する関係で、5倍音まで設定が可能な仕様とした。 記録は、トップ側のノブをch9に選択してエンコーダーのトップを長押しして行う。
現状はメモリー数を1chとしているが、今後必要に感じた場合はさらに記録バンクを増設する可能性もある。
posted by Yasuski at 17:48| LaVoixski
2019年03月08日
SigmaDSPの導入について
ADAU系列のDSPは導入の敷居が高いが、スタンドアロンで動くこのチップを扱った記事はハードルを超えるためのヒントになる。
Webを漁ると製作例が上がっていて、ハードを販売している人も居るようだ。
最終的にはこのコードが使えそうなので、DSPの試作ボードを購入してテストを行うことにした。
ただ、このチップを含めた最近のオーディオ製品は通信をI2Cで行うために、DACとして使用する場合にボトルネックの問題が出てくるかもしれない。 所謂「バーストモード」がMCU側の設定で使えるかどうかが決め手になるだろう。
DSPを使用する利点は、それ自体にオシレーションを行わせられそうなところで、波形の生成を外部に丸投げして、I2C/S等のシリアル伝送によって生じるデータトランスファーのボトルネックをスキップできる可能性がある。
オーディオデータのハンドリングに話を戻すと、LRCLKでオーディオデータを受けていては出力が間に合わないので、3ch以上の出力を行う場合は否応無しにTDMモードを選択することになる。 TDMフォーマットに関しては良く判っていないので、参考のために具体的な製作例を探したほうが良いだろう。
ADAU1701はデジタルオーディオ・フォーマットを直接出力できるので、MCUからDACに至る間に発生していた遅れ時間を気にせずに外部に設置したDACにデータを放り込める利点がある。 入出力で通信モードを切替えられそうなので、adatフォーマットに拠る通信を行えるかもしれない。
Webを漁ると製作例が上がっていて、ハードを販売している人も居るようだ。
最終的にはこのコードが使えそうなので、DSPの試作ボードを購入してテストを行うことにした。
ただ、このチップを含めた最近のオーディオ製品は通信を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コマンドで一旦クロックの生成を停止できるところが今回の用途にぴったりだ。
クロックを駆動するトリガーは、目玉スイッチのLEDと連動させている。 実際に運用を行ってみると、テルミンは出音の立ち上がりが遅く、sequecerの発音が遅れてしまうように感じることがあった。 ただし、これは用法で解決すべき問題なので、今後は実際の演奏体験を通じて特性に合わせた運用を模索していくことになる。
要は曲を演奏中にブレイク出来ないということで、ならば改良のために条件分岐を使って無音時にカウントを休止する機能を実装しようとしたが、何故かmetro環境下ではどうやってもクロックをストップ出来ない。
この問題に対処すべくchronoという新し目のライブラリを見つけてmetroと換装することにした。
chronoについての詳細はリンク先を参照してもらうとして、chronoは定常的にクロックを発生させるmetroとは異なり、インターバルが終了したあと常にrestartコマンドによってリトリガーを掛けなければ反復する信号を生成できない、所謂ワンショット系のデバイスを模したものとして考えればよいだろう。restartを行うまでは静的な状態を保持する一方、stopコマンドで一旦クロックの生成を停止できるところが今回の用途にぴったりだ。
クロックを駆動するトリガーは、目玉スイッチのLEDと連動させている。 実際に運用を行ってみると、テルミンは出音の立ち上がりが遅く、sequecerの発音が遅れてしまうように感じることがあった。 ただし、これは用法で解決すべき問題なので、今後は実際の演奏体験を通じて特性に合わせた運用を模索していくことになる。
posted by Yasuski at 09:55| LaVoixski
2019年03月04日
FVCの「丸め」を行う手順の修正など
今日は、テルミンの周波数ディテクター周りのコードをいじっていたのだが、間違った手順でデータを丸めていたことを発見、その部分の修正を行った。
要は、EMAで「データの丸め」を行った後に、暴れている元信号の差分を追加するというマヌケなことをやっていたのだが、改良の結果データのバラつきを格段に抑えることが出来た。 今後はEMAにプリセットする数値を調整していくことになる。
一方、動作が不安定で使用を諦めていた「ClickEncoderを排除した試作コード」に、無駄な処理ルーチンをスキップするbrakeポイントの追加やRAMの使用量を圧縮する改良点を思い付いたので、該当箇所の修正を行った後に再度運用をトライした。
ロータリーエンコーダーの入力にノイズサプレッサ用のCを取り付けない機械的に不備な状態下でのテストではあったが、出音に関しては正常な動作を確認できた。 起動時にチューニングノブの規定値がClickEncoder使用時と大幅にズレることから、処理時間の圧縮に関してはほぼ成功していると思われる。
今後プラットフォームを変更する場合には、Arduinoのライブラリに頼らないこのコードを中心に開発をすすめることが可能となった。
追記：
後日、低域の安定度がどんどん低下する案件が発生、コードの不備を疑うも過去の経験から物理的な要因の気配があったので、繰り返しキャリブレーションとチューニングを繰り返した結果、キャリブレーションによって得られるイニシャル値には明らかな適正値が存在することを確認した。 ピッチ・アンテナ側とは逆ベクトルで操作を行うヴォリューム・アンテナ側ではこの値が明白で、データ取得時に設定しているリミッターのフルスケール16383がそれに相当する。
もう一方のピッチ・アンテナ側だが、こちらはデータを扱うベクトルがヴォリューム側とは逆になるため、単純に最適値を算出することが出来ない。
イニシャル値の決定は、入力信号のアップエッジでフリーランするカウンタの値をキャプチャした結果から「差分値を引き出す」ディテクタ側のセンシングのメソッドと、カウンタをドライヴするクロックの分周率から影響を受ける。 MCUのシステムクロックや、クロック入力に設けられたフィルター等、関連するパラメーターが多過ぎて明確な回答を出すことが難しいが、カウンタのオーバーフローによって発生する字余り状態が誤動作の原因となることから、ピッチ側オシレーターのセンシングエリアの設定をオーバーフローが発生しない領域よりも上に持ち上げることが安定度をアップするための最適解といえるだろう。
ただし、この数値は楽器の発音域とのトレードオフで折衷することになるため、新たにアンテナ長等の楽器を構成する物理要因が絡んでくる。 よって機種依存しない普遍的な数値を出すことは難しいが、実測を繰り返した結果、イニシャル値20000前後が実用域なのではないか？と予想している。
現時点で実験に使用している楽器の発振器は設計に問題があり、より安定した性能の発振器を使った実験環境を構築しなければならないのだが、新たに設計した基板には配線ミスが発覚している。 修正版のオシレーター基板はすでに設計を終えているので、今月中にはこれを発注する予定。
要は、EMAで「データの丸め」を行った後に、暴れている元信号の差分を追加するというマヌケなことをやっていたのだが、改良の結果データのバラつきを格段に抑えることが出来た。 今後はEMAにプリセットする数値を調整していくことになる。
一方、動作が不安定で使用を諦めていた「ClickEncoderを排除した試作コード」に、無駄な処理ルーチンをスキップするbrakeポイントの追加やRAMの使用量を圧縮する改良点を思い付いたので、該当箇所の修正を行った後に再度運用をトライした。
ロータリーエンコーダーの入力にノイズサプレッサ用のCを取り付けない機械的に不備な状態下でのテストではあったが、出音に関しては正常な動作を確認できた。 起動時にチューニングノブの規定値がClickEncoder使用時と大幅にズレることから、処理時間の圧縮に関してはほぼ成功していると思われる。
今後プラットフォームを変更する場合には、Arduinoのライブラリに頼らないこのコードを中心に開発をすすめることが可能となった。
追記：
後日、低域の安定度がどんどん低下する案件が発生、コードの不備を疑うも過去の経験から物理的な要因の気配があったので、繰り返しキャリブレーションとチューニングを繰り返した結果、キャリブレーションによって得られるイニシャル値には明らかな適正値が存在することを確認した。 ピッチ・アンテナ側とは逆ベクトルで操作を行うヴォリューム・アンテナ側ではこの値が明白で、データ取得時に設定しているリミッターのフルスケール16383がそれに相当する。
もう一方のピッチ・アンテナ側だが、こちらはデータを扱うベクトルがヴォリューム側とは逆になるため、単純に最適値を算出することが出来ない。
イニシャル値の決定は、入力信号のアップエッジでフリーランするカウンタの値をキャプチャした結果から「差分値を引き出す」ディテクタ側のセンシングのメソッドと、カウンタをドライヴするクロックの分周率から影響を受ける。 MCUのシステムクロックや、クロック入力に設けられたフィルター等、関連するパラメーターが多過ぎて明確な回答を出すことが難しいが、カウンタのオーバーフローによって発生する字余り状態が誤動作の原因となることから、ピッチ側オシレーターのセンシングエリアの設定をオーバーフローが発生しない領域よりも上に持ち上げることが安定度をアップするための最適解といえるだろう。
ただし、この数値は楽器の発音域とのトレードオフで折衷することになるため、新たにアンテナ長等の楽器を構成する物理要因が絡んでくる。 よって機種依存しない普遍的な数値を出すことは難しいが、実測を繰り返した結果、イニシャル値20000前後が実用域なのではないか？と予想している。
現時点で実験に使用している楽器の発振器は設計に問題があり、より安定した性能の発振器を使った実験環境を構築しなければならないのだが、新たに設計した基板には配線ミスが発覚している。 修正版のオシレーター基板はすでに設計を終えているので、今月中にはこれを発注する予定。
posted by Yasuski at 18:06| LaVoixski
2019年03月03日
pgm_read_word_nearの削除を行う
前のシステムの名残だった pgm_read_word_near を
コード上から削除して、シンプルな記述に書き換えた。
本来はROMエリアに格納したデータアレイを参照するためのコードだったものを、処理スピードをアップするためRAM上にデータを展開した後も使っていたのだが、記述を変えることによって何らかの変化が生じるかもしれない。
処理上のステップが改変後に1.5%程増加した一方、RAMの使用量に変化はなかった。
コードを改変する前のヴァージョンでコンパイルを行った時の画像を示す。
こちらのコードではVolumeControl関連のルーチンから pgm_read_word_near を既に排除している。
ステップの増加イコール処理スピードの低下とは単純に言えないので、実際に運用して確かめてみるしか無いが、その差1,5%という数字は尋常では無いために、どういった変化が生じるのか気になってくる。
追記：
実験の結果、正常に発音することが出来た。
改変前には44.1kHzにオーディオクロックを設定した時に特定のシチュエーション下でフリーズが発生していたが、今回の改変でこれが解消された模様。 つまり、処理能力のキャパシティーに余裕ができたということで、この件によって処理の合理化の達成を確認できた。
コード上から削除して、シンプルな記述に書き換えた。
本来はROMエリアに格納したデータアレイを参照するためのコードだったものを、処理スピードをアップするためRAM上にデータを展開した後も使っていたのだが、記述を変えることによって何らかの変化が生じるかもしれない。
処理上のステップが改変後に1.5%程増加した一方、RAMの使用量に変化はなかった。
コードを改変する前のヴァージョンでコンパイルを行った時の画像を示す。
こちらのコードでは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に搭載する波形に関しては、メモリー管理の関係でそれらを削っていく過程で「無駄だと思っていた構成」がそこそこ必要とされるものと再確認することが出来た。予め複雑な「形を仕込んだ」波形を揃えるよりも、倍音関係にある単純な波形を準備して、それらに動的な制御を行ったほうがより効果的に音造りが出来そうだ。
単音を出力する場合は「少々歪みっぽい」程度の変化だったが、総体的にはあまり良い印象を受けなかった。
入力レベルが増加する和音やOVERDrive系の音源となると、マイルドに設定していた過渡領域が全て無効になる始末で、システムの稼働実績は確認できたものの、その有効性には大きな疑問が生じることになった。
多分、チューニングを詰めれば再現性の高い効果が得られるのだろうが、出音に制御波形そのものの性格が反映される為に、実際にカット&トライを行う場合のハードルは高いものとなるだろう。
因みに、現行のシステムでは条件分岐によって入力の過渡的な変動値を圧縮しているが、この処理を24bitで行っているのがポイントで、それを16bitで行おうとした場合にどうしても粗が出てしまうようだ。 特にoverdrive系のような過渡特性が命な音源のコントロールは非常に難しいと結論することになった。
確かにデジタルドメインの非線形処理は対周波数特性等の解決すべき難問が待ち構えている案件で、大メーカーが開発に携わったものの撤退しているような難物故に、ウエーブテーブルによる波形の書き換え程度で容易に結果が得られる筈がないのではあるが。
自分の場合、最終的にはアナログ頼りなところがあって、勝手にいろいろな計算をしてくれるアナログ素子は便利なので、頼るべきところは頼ったほうが良いと判断するのが信条だったりする。
実験はひとまず失敗に終わった形だが、出力波形そのものをより動的に制御できる手段が実現できたのは心強い。 また、Wavetableに搭載する波形に関しては、メモリー管理の関係でそれらを削っていく過程で「無駄だと思っていた構成」がそこそこ必要とされるものと再確認することが出来た。予め複雑な「形を仕込んだ」波形を揃えるよりも、倍音関係にある単純な波形を準備して、それらに動的な制御を行ったほうがより効果的に音造りが出来そうだ。
posted by Yasuski at 21:10| LaVoixski
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月だ。
最近になってようやくオンライン上にある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月だ。
posted by Yasuski at 07:38| AudioElectronics
