2017年10月09日

Open.Theremin@VolumeControler周りの問題について

8bit処理時代に感じていた不具合が段階的に軽減されたきたものの、VolumeAntの反応について常に不満を感じ続けていることもまた事実。

Open.ThereminのVolumeControlの構造について解析すると、まずハード面の違いはオシレーターの中心周波数が40kHz程下なこと位で、Pitch側と殆ど構造は同じ。 ソフト面も似たような構成だが、周波数カウンタでカウント=センシングされた値をMaxVolumeの規定値4095=12bit/FSから減算するところに違いがある。 つまり、センシングされる周波数の差分が大きくなるほど、音量設定のデータは低くなっていく。 センシングされた差分の最大値は予め4095にリミットされているので、マイナスの値は出てこない。

一方、オシレーターの周波数変化にはリニアリティーが要求されているために、当然ながらValueの変化もリニアになる。 が、これは音量をコントロールする数値変化に要求される変化のカーヴとしては頂けない。 弱音から一気に音量が増えてしまう感覚は、このようなシステムの在り方に起因している。

ここで、今一度整理することを目的に、現時点で追加した改良点を列挙しておく。

1) 処理ビットの幅を8bitから11bitに拡大。 

8bit幅ではどうしても「段差」を感じてしまうため、より細かな変化幅でドライヴすることが望ましい。 が、分解能が上がると、それだけ計算に必要な時間が増える。 ので、トレードオフとして11bit程度が妥当と判断した。

WS001152.JPG

2) フィルターの追加。 

レジスタを追加して積分を行い、細かな反応を地均ししている。

Screen Shot 2017-10-09 at 9.15.03 PM.png

3) オーバーフロー対策用のリミッターを追加。 

トランジションをコントロールした場合、いきなりデータがフルになる情況が発生するので、それを回避するための仕掛け。

WS001151.JPG

4) トランジション使用時のオーバーフロー対策として、ヴォリュームカーヴ設定ファイルの最大値を変更。

リミッターでは吸収されないレベルの変化幅の発生を予め予防するために、ピークの重複を見越してWavetableの最大値を設定している。

WS001147.JPG

5) FTMカウンターの分周率を1/2から1/4に変更。

差分のセンシングを行う場合、反応の速さとセンス出来る最低周波数はトレードオフとなる。低い方のセンシングを安定させたい場合は分周率を上げる方向で調整するが、遅延時間が大きくなると音響処理に使用出来る時間が削られてしまう。

WS001148.JPG

6) VolumeCounterから出力される16bitデータを右に1bit分シフト。

4bit分の不感帯を多少なりとも解消するための細工。 センシングと同時にInitialValueに記憶されるレジスタの変更を忘れずに。

WS001149.JPG

以上の変更を行っていたが、イマイチ効果が薄い。

そこで、Wavetable方式で、ヴォリュームカーヴを読み取り出力に反映することにした。

Screen Shot 2017-10-09 at 9.13.11 PM.png

これにはかなり効果があって、ピアニッシモ時の息継ぎ現象や、急峻な音量変化を抑えることができている。

ただし、妙にノイズっぽい音質の改善は進んでおらず、引き続き対策を考えなければならない。
posted by Yasuski at 18:47| open.Theremin