2018年06月30日

Open.Theremin@5voiceを選択する

今日は家人が留守だったので、一日中テルミンのプログラミングと演奏実験を繰り返していたのだが、ひとまず6voice版と5voice版のほぼマスター版を完成させることが出来た。

結論として、現在採用しているMCUの処理能力の限界から、adatを使用しない場合も、5voiceがバランス的に最良な選択とした。 

WS001336.JPG

また、処理能力とは関係なく、Overload出力時のバランスが6voiceでは崩れてしまうことも判った。

適当にでっち上げていた非線形増幅度可変システムは、

WS001337.JPG

Overloadモード時に欠かせない機能と判明したため、今後は絶対に保持すべき項目に昇格した。

今回省略したのはオシレーターの出力波形に噛ませていたLPFだが、

WS001339.JPG

これを外した場合に明白な音質の変化を認められなかった。

ご利益の度合いは不明だが、今回はプログラム全般にわたって可能な限り浮動小数点ユニットを導入している。

他に行った改良のポイントはインターフェイスの大幅な変更で、使用頻度が極端に少ない下側のRGBロータリーエンコーダーに上側にアサインしていた動的な機能を割振ることにした。

WS001334.JPG

変更の方針はライヴにおける運用性の向上で、上側に割り振っていた機能のうち、Pitch/Volumeの修正ポットと和声モードの切り替えを残し、他は下側に移行した。 これは、和音の構成を変更する際に発生するラグを排除するための選択でもある。 

WS001335.JPG

まず、波形選択を楽器の立ち上がりで表示されるページ1に割振った。 使わなくなった6voice目のオシレーターに関する項目は削除し、代わりにPitchのファインチューンとTransitionコントロールを項目の末尾に追加した。切り替える項目は17種類に増えたが、使用頻度の高い3項目は直近に配置している。

具体的には上が7項目

PitchVolume →2voice →3voice →4voice →5voice →ChordEdit 

を循環し、下方は

Waveselect →Pitch01 →Pitch02 →Pitch03  →Pitch04 →Osc1Vol →OSC1 waveform →OSC2 Vol →OSC2 waveform →OSC3Vol →OSC3 waveform →OSC4vol →OSC4 waveform →OSC5 vol →OSC5 waveform →Pitch Tune →Transition

を循環する。

初見なので未だ運用に混乱が生じているが、和音モード選択時にTransitionの調整と波形選択の直アサインが可能になったために、操作の自由度が上がったことが改良の成果といえるだろう。
posted by Yasuski at 00:53| open.Theremin

2018年06月28日

Open.Theremin@シールドスリーヴ付きアンテナ2作目

予備のピッチ・アンテナにシールド用のスリーヴを取り付けた。

IMG_8115.JPG

このアンテナは前作とはシェイプが違うために改造には大幅な加工が必要で、パイプを挿入するために一度アンテナを曲げ戻す必要があった。 

今回採用したシールドスリーヴ用のアルミパイプは径が大きく、前回試作したアンテナよりもクリアランスが稼げる筈だ。 また、パイプの内径が偶々GFRP製のパイプとマッチしていたお陰でスリーヴには保持材が不要で、基台の部分だけでパイプ全体を固定することが出来た。

アンテナ&スリーヴ間に発生する静電容量は実験してみないと判らないが、パイプの径が大きくなった分前回よりも影響を抑えられたかもしれない。

ローディングコイル入りのスリーヴは次回に製作する予定。 アンテナ・ロッドには取り扱いが容易な真鍮を使うことにする。 スリーヴの両端にはGFRPのガイシを配置し、そこにSMAコネクターとM2.6の接続ポートを取り付ける。 コイルを封入するアルマイト仕上げのパイプは絶縁できているので、あまり細かいことは気にせずに製作出来そうだ。 
posted by Yasuski at 21:14| open.Theremin

2018年06月27日

Open.Theremin@DACに供給するSCKのマージンをNOPで稼ぐ

新設したDACの動作試験を兼ねた記録映像。 左手の動きに連れて発生する音量のピークの配分を調整している。



SCKが立ち上がる前後にNOPを4セット×2噛ませることで、以前設定していたNOP2セット×2の時よりも動作を安定させることが出来た。 とはいえ、依然として出力に細かなノイズが乗っているのが残念。

そろそろ楽器の運用に慣れてきたおかげで、ロックの定石っぽい雰囲気の音作りが出来るようになった。 

が、癖の強い音なので予め使用する局面を練っておかないとダメだろう。
posted by Yasuski at 20:35| open.Theremin

Open.Theremin@また新たなバグが発覚する。

アンテナのセンシングが激遅くなるバグがコード編集モードにも波及してきたので、本格的に原因を探ることにした。

まず、5ヴォイスのモードでフリーズに近い状態にセンシングスピードが落ちる問題は、円環カウンタの数値を限定するだけでは上手くいかず、

WS001332.JPG

Wavetable読み出しポインターの制御を行っているコードをcli(); sei();で囲むことでようやく解決できた。

WS001328.JPG

が、コード編集モードでTransitionコントロールモードにアクセスした途端に速度が落ちる現象が発覚。 こちらは処理の遅れが重篤で、もはやエフェクトとはいえない状態になった。 

この問題に対処するために、割り込み禁止ポイントの増設やDACに送るSCKのタイミングを合わせるために挿入したNOPを減らす等いろいろと手を打ってみたものの

WS001331.JPG

情況は全く改善せず、これはMCUの処理能力の限界に達している感があった。 そこで、新たに追加したDACの処理を行わない方向に修正を行ったところ、問題は解決した。

ただ、せっかく搭載したDACを使わないのは惜しい。 動作が可能そうな移設場所を検討した結果、アンテナやロータリーエンコーダのセンシングを行っているループの先頭で処理を行うことにした。

WS001333.JPG

Loop内の処理が状況によって重複してしまう可能性を考慮して、DACのデータ処理ルーチンの終了後に読み出し完了のフラグを立ててタイミングを制御している。 フラグの解消は、サンプルクロックの立ち上がり後、メインのDACにデータが送信された後に行われる。

WS001330.JPG

DACへのデータ送信に要する時間は、NOPによるクロックの遅延によって左右されるが、実験の結果、安定した状態でデータを送るには3NOP以上のマージンが必要と判明している。

WS001327.JPG

残念ながら3rdDACの音質はイマイチで、実用に耐えうるかどうかギリギリの線のクオリティーだったが、ひとまずこれで3ch出力をバグ無しで実行できる体制を整えることが出来た。
posted by Yasuski at 15:12| open.Theremin

Open.Theremin@3個目のDAC&妙なバグが出た

サブCH出力用の3個目のDACを拡張基板に仕込んだ後、ケースに実装した。

IMG_8105.JPG

MAX5541のスピードが心配だったが、最低限のNOP命令でデータ取り込みのタイミングが合わせられているようだ。

IMG_8102.JPG

接続は5V電源とGND、アナログ出力、デジタル入力3線の計6本で行っている。

IMG_8103.JPG

配線はブレッドボード用のピンを使った。

IMG_8106.JPG

この状態は仮で、DACの接続を思い切り間違えている(写真)。 実験用とはいえ、このようなスパゲッティー状態は観るにしのびない。

配線の修正後にDACは難なく動いたが、5 Voice Modeのアドレス境界で妙なバグが出てきた。



アンテナのセンシングが遅れる気持ち悪くて面白い効果なのだけど、ライヴでいきなりこの状態にハマるのが怖い。 多分、原因はエンコーダーでドライヴするループカウンタの計数ミスで、妙なループにハマった結果と思われる。 幸いなことにアドレスを変更すればバギーな状態を脱出できる。 エンコーダーの循環数の管理をきちんと行えばバグを回避できる可能性が高いので、ひとまずは該当部周辺の手当を行ってみよう。

DACはMCU側のボトルネックが心配だったが、すんなりと音が出た。 現状は素直にOSC1のみのモノラル信号を再生しているが、これはadatに送信するデータの大元になるものを16bitにダウンサイジングした信号。 エンヴェロープにちゃんとピークが2つ出来ていることから、Transitionの個別制御が上手くいっている感触だ。
posted by Yasuski at 02:37| open.Theremin

2018年06月25日

Open.Theremin@操作マニュアルっぽい映像を製作する

IMG_8094.JPG













posted by Yasuski at 20:27| open.Theremin

2018年06月24日

死亡したTeensyを復活させる方法

USBによる接続が不可能となったTeensyを復活させる方法を見つけたので備忘録を書いておく。

原因は定かではないが、一種のシャックリのようなものと思えば良いらしく、接続が絶たれただけでMCU自体は死亡していないようだ。

対処法はMAC系のプラットフォームを使用する場合が簡単なようだ。 まずはArduinoを起動して、なんでも良いからスケッチのコンパイルを行い、Teensyの書き込みソフトを起動する。 次に、故障したMCUのリセットボタンを押しながらUSB端子を接続すると、あら不思議、何故かデバイスの認識が行われ始める。

これで、死んだと思って放置していたTeensy3.5と3.6の2個ずつ、計4つのデバイスを復活できた。 ここで断捨離をやらかしていたらこの発見はなかったわけで、とにかくゴミと思われるものであってもある程度は保持する必要があるのだな、、、と痛感させられた次第。
posted by Yasuski at 01:07| AudioElectronics

2018年06月23日

Open.Theremin@不安定な発音状態の原因を探る

テルミンのPitchが不安定なのだが、いきなり周波数が変動する現象は物理面の不具合を疑ったほうが良いかもしれない。 完成した楽器を修正のために分解しまくるのはこういった弊害を誘発する可能性がある。 試作機の構造はその辺を考えないとイカンなあと反省させられる。 

IMG_8092.JPG

低音域が安定しないのはその所為かもしれない。 電圧が変動する原因の可能性として電源コードを疑ったら、どうもこれが半分正解だったようだ。 Hiroseの6pin中継コネクタの接触が経年劣化で悪くなっていたのだろう。 不安定な状態を現出させる要因を取り除くために、試作テルミン専用のケーブルを造った方が良い。

あと、下の音域が暴れる問題は、Wavetableの読み出しレートを再検討すべきと感じているが、ハードウエアとソフトウエアの抱える問題を切離すために、一度アンテナによる制御を介しない固定ピッチで音源自体の素行を調査する必要がある。 要は、ノイズを誘発する「制御データの揺れ」が何処で発生しているかを見極めなければならない。 「読み出しレートの固定」は、既に和音を構成してプリセットを行うモードに導入済みだが、現在はフリーな状態のロータリーエンコーダー&doubleの定数でピッチを設定する3オシレーター分の周波数を固定化して評価を行うことになる。

アンテナへの電磁波の影響や、電源の多重供給が原因でMCUをぶっ飛ばす危険を防止するために、楽器の実証試験をPCと離れた場所で行うことにした。 プログラムをロードしたあと、楽器を抱えながらスタンドとアンプを置いた玄関とPCがある自室を行ったり来たりすることになるが、MCU一発4Kオーヴァーをご逝去させないためには安い苦労である。

で、クリーンな電磁環境下でテストを行ってみたところ、電源ケーブルの交換で多少マシにはなったものの、やはり低い方のピッチが安定しないことが判明。テスト時にアンテナのエクステンションは取り外してあったが、どうも物理要因で決定される方のレンジの狭さが原因な雰囲気ではない。

比較のためダイエット前のプログラムに戻してもこれといった変化はなし。 とにかく音が濁るのだ。 この感触はアンテナ経由でノイズが乗って来ている風なので、アンテナのノイズを消すためにデジタルLPFを復活させてみたが、こちらも効果はあがらず。

結局は消去法からデータのバタつきに起因するトラブルと判断してセンシング後のデータ幅を13bitに戻したが、コレが正解だった模様で、コード改修後の音源は低音域まで安定して動作している。 

定数の変更によるトレードオフは当然ながらアンテナの有感帯が狭まることで、これはチューニングがより難しくなることを意味するが、キャリブレーション時に安定した状態で可能な限り大きな変化幅を確保することで対処できるようだ。

この辺りのメソッドを確立しないかぎり製品化は難しいと思っているのだが、「こちらは土台を提供するだけなので、あとは勝手にやってくれ」というスタンスもアリだろう。

さて、どうしたものか。

この実験を行う前に見切り発車で次のヴァージョンの基板を発注してしまったが、これにはDACを3個まで載せることが出来る仕様とした。 実際に現用のハードウエア上でダミーのDACをカラ運用で駆動してみたが、システムは音が濁ることもなく安定して稼働している。
posted by Yasuski at 20:27| open.Theremin

Open.Theremin@処理システムのダイエットを行う

追加したOpen.Thereminの音響処理に関するタスクが増えすぎたので、あまり効果の無さそうなものからダイエットを始めることにした。

まずは、様子見でPitch/Volumeアンテナのセンシングを行っている部分のデジタルLPFを削除してみたが、これは機能を取り除いた後にあまり差が出ない感じだったので、そのまま削除を決定した。

次に、コンパイル時にアラートが出ていたVolumeCurbのWavetableを読み出すアドレスの閾値を設定する部分だが、事前にデータ型を符号無しから符号ありに変更してアラートを回避している。 この部分を仮に削除するとVolumeAntの遣い勝手が極端に悪くなることを確認できたので、残すことに決定。 

また、読み出したデータを丸めるLPF群は、削除後に音色が悪い方向に変化した雰囲気だったので、Wavetable系のデータを扱う部分の閾値設定&アウトプットに噛ますLPFは全て残すことにした。

ちなみに、これらの機能を除いても(ノイズが減る方向の)音質の改善は認められず、逆にOverloadモードのクリッピングが上手くいかなくなる弊害が発生していた。

今回は、本格的なダイエットを行う前の小手調べといった感触ではあったが、そろそろオシレーターの数を減らす、もしくは現時点で24bitに設定している音声系のデータ幅を16bitに縮小する等の大規模なタスクの削減にトライすべきフェイズになってきた。
posted by Yasuski at 05:58| open.Theremin

2018年06月22日

Open.Theremin@アンテナエクステンションの試作

試験的に演奏を繰り返すうちに、小型筐体のテルミンが持つ共通の問題、アンテナ間のクリアランスが気になってきた。

そこで、アンテナ基台から水平に伸びるロッドの部分をグランド電位に接続したスリーブで覆うことを思いついた。 スリーブは内部に格納した水平部分のアンテナに巻きつけたグラステープで保持・絶縁を行っている。

IMG_8073.JPG

問題は、実質的なアンテナ長が垂直部のみに減少してしまうことで、周波数のドリフトが気になる。で、結果は予想に反して、周波数のレンジが低い方にドリフトしてしまった。 アンテナ端子がグランド電位に近くなることでトータルの静電容量が増えるのだろうか。 ドリフトの量がトリマーでリカヴァー出来る域を超えて仕舞ったので、リファレンス側のオシレーターに22pFを追加して再度周波数のレンジを合わせこむことになった。

調整後、試験的に演奏を行ってみたところ、残念ながら低音域でセンシングが「荒れる」現象を観測できた。 このままでは実用がキツイと判断して、とりあえずアンテナを伸長するためのエクステンションとして、チタンパイプの切れ端にハットフランジを圧入したパーツを製作した。

エクステンション追加時には若干動作の安定を確認できたが、何故か素の状態が一番安定しているようだ。 これは、グランドポイントを取る場所との関連も考えられるので、出来ればアンテナ基台直近からのラインを確保する方向で構造を再検討したいと思う。

IMG_8074.JPG

現状は、思い付きで現用パーツを細工して構造をデッチ上げた状態なので、次はもう少しマトモな構造の試作品を製作したい。 アンテナ長の問題は、カウンタのデータ幅を調整することでも対応できそうなので、同時にソフトウエア面からの対策も講じていくことにする。 それと、プレイヤビリティーの向上のためにローディングコイルの必要性を感じているが、これの収納場所としてアンテナスリーブが有効と思われる。 パーツの外径が問題となりそうなので、事前にサイズ合わせを行っておこう。

追記:

シッカリとしたアースポイントを取った結果、動作が安定した模様。

IMG_8080.JPG

敗戦間際のドイツ軍の戦車みたく、襲い来る問題に対処するために筐体がどんどん改造されて逝くいつものパターンに嵌っているような。

一方、ソフトウエア側でもレンジの問題を何とか出来ないか試行錯誤を続けている。

まず、ピッチ側の動作を確認するために、周波数の差分をカウントする幅を14bitから13→12と圧縮してみたが、低音域のザラザラ感はあまり変わらず、却って高音側が削られるだけだったので、元の14bitに戻すことになった。

自分のような音域が広い楽器が好きな人はこれで良いが、初心者や声域に近い演奏を目指す人は、演奏のスタイルに合わせて帯域を制限したほうが使い易い楽器になるかもしれない。

データ幅を14bitで運用した場合、大凡ではあるが余裕で6oct.をカヴァー出来はするものの、その一方でピッチの制御はかなり難しくなる。低域が怪し気なのは、どのデータ幅でも一緒なので、自分の場合は迷わず14bit制御を選択する。

事前の調整がキモな楽器だが、これの自動化は難しいと思う。 

ハードウエアの製作にかまけていてついつい忘れてしまうのだが、そもそもの間違いは機材が山積みにされたダンジョンでこの楽器のセットアップを行うことなので、原野とは言わないが一度だだっ広くて何も無い空間でテストを敢行すべきだろう。 

これは、撮影用のカメラを駆動するスイッチング電源をアンプの直近に置いただけでチューニングが発狂して仕舞うような代物だということを先ほど思い知らされたばかりだ。 
posted by Yasuski at 20:46| open.Theremin

2018年06月21日

Open.Theremin@テルミンが完成した時の恒例行事



OverloadModeは図に示すようなポジティヴサイドのサイン・カーヴをオシレーター群の出力に乗算して音量を個別にコントロールするTransitionModeの一環だが、

controlSignals.png

全ての出力を減衰無しで加算することで、トータル出力の波形をクリップさせている。 このTransitionの間隔=オフセット値はロータリーエンコーダーで調整することが出来る。

WS000903.JPG

つまり、ピークポイントの間隔を疎にすることで、ある程度は波形のクリップを抑制することができるが、この辺の使い勝手は感覚的に掴んでいくしか無いだろう。

posted by Yasuski at 16:25| open.Theremin

Open.Theremin@DACからCVを取り出す

オシレーターをチューニングするために必要なマルチターンなVRは単価が最低でも1kはする代物で、出来れば製品化時に使用したくない製品なんだが、これを排除するには諦めていたMCUの内蔵DACからの電圧コントロールを実用化する必要がある。

ということで、プログラムの変更を検討しているのだが、完成している楽器をイジってぶち壊すありがちなパターンを回避するために、、、

IMG_8071.JPG

事前調査を別の試作用プラットフォームで行うことにした。

WS001325.JPG

おおまかな変更点は2箇所で、キャリブレーション・モードによるポットの切り替えと、

WS001326.JPG

DAC及びEEPROMにアクセスする項目を追加する。

WS001323.JPG

起動時にDACの出力電圧のプリセットを行った後、Loop内でpot1/pot2をセンシングする通常モード(mode4)に移行する。

WS001324.JPG

スイッチ長押しで、Pitchアンテナのキャリブレーションを行うモード1に移行、pot23aによるDAC出力の変更が可能になる。

WS001317.JPG

スイッチ長押しで、VolumeAnt側のキャリブレーションを行うモード2に移行する。

WS001320.JPG

スイッチ長押しで、EEPROMにデータを書き込むモード3に移行する。

その後、メインプログラムに機能の実装を完了したが、ノイズの影響なのか今ひとつピッチが安定しない。 また、測定を行うまでもなく出音が濁ってノイズが増えているのが明らかだったので、残念ながらDACからCVを取り出す機能の追加は一旦棚上げすることにした。

理由が判然としないところが気持ち悪いが、機能を取り払った状態で再試験を行ったところ、VR単体でCVをコントロールした方が格段に安定している。 原因として処理のタスクが増えたことと、DACからのデジタルノイズの影響が疑われる。

DAC出力でCVコントロールを行う機能とEEPROMにデータを保存する機能は確実に実装できたので、将来的にはハードウエアによる解決も考えているのだが、、、やはりオシレーター系は純アナログシステムで組むのが正解なのだろう。
posted by Yasuski at 12:36| open.Theremin

2018年06月20日

Open.Theremin@波形を観測しながらデモ演奏を行う



将来的には各種出力波形のプロジェクションと共に演奏を行ってみたい。
posted by Yasuski at 17:07| open.Theremin

2018年06月19日

Open.Theremin@波形の解析

AnalogDiscovery2でキャプチャしたOpen.ThereminOnTeensy3.6の出力波形を解析する。

まずは基本波形から。

vlcsnap-2018-06-19-18h43m05s445.png

基本波は普通のサイン波で、これの整数倍の波形をWavetableに登録している。例外的なものとしてサイン波のハーフウエーブ・三角波・ノコギリ波・ランダム等を登録しているが、波形の鋭いエッジがノイズ源となってしまうこともあるために、あまり選択する場面がない。

vlcsnap-2018-06-19-18h43m31s710.png

このシステムは基本的に加算合成方式で波形の編集を行うが、波形が登録されたアドレスにはプリセット14種類、編集が可能な記録バンクが16ch分用意されている。 この波形はプリセットされたもので、任意の波形を選択してレベルを調整したものを加算合成している。

vlcsnap-2018-06-19-18h43m48s632.png

参照波の位相差を利用して、このような波形を合成することが出来る。

vlcsnap-2018-06-19-18h44m16s192.png

プリセット波形のレベル調整は、処理を軽くするためにデータの右シフトという荒っぽい方法で行っているが、何れも開発の極初期段階に直感的にセレクトしたものなので、使用頻度等のフィードバックが得られ次第リファインしたいところ。

vlcsnap-2018-06-19-18h44m23s807.png

このような非常に高い音程の波形を使用する場合、妙な変調が耳についてしまうことがある。

vlcsnap-2018-06-19-18h44m30s567.png

音量の再検討等の運用面のバランスを考慮した改修が必要。

vlcsnap-2018-06-19-18h45m15s972.png

この波形のように、三角波を合成した場合、エッジの効いた「ヒゲ」の部分がノイズに聞こえてしまうことがある。

vlcsnap-2018-06-19-18h23m23s353.png

こちらは、Overloadモードの波形。 これはクリップする前の状態で、Transitionモードとあまり差異はない。

vlcsnap-2018-06-19-18h23m32s088.png

VolumeAntで増幅度を変化させると、このように波形がクリップしてくる。 この段階ではハーモニックエキサイター風のハーフウエーブ・ディストーションに近い波形が出現する。

vlcsnap-2018-06-19-18h23m38s648.png

更に増幅度を上げていくと、波形下側が完全にクリップする。

vlcsnap-2018-06-19-18h24m05s878.png

transitionのオフセット値を調整して、波形の粗密度を設定する。

vlcsnap-2018-06-19-18h24m29s838.png

波形の上下が完全に潰れた形。 波形のエッジをデジタル/アナログLPFで削ぐことで、ノイズ感を減少させている。

vlcsnap-2018-06-19-18h24m45s648.png

上側がクリップした波形。 このような歪の大きな波形が左手の加減によってシームレスに生成されていく。

vlcsnap-2018-06-19-18h25m25s440.png

増幅度を下げると、クリアな音質を得ることが出来る。

vlcsnap-2018-06-19-18h25m54s417.png

上下がクリップした波形とサイン波の下弦の部分を加算合成するとこういった波形になる。

vlcsnap-2018-06-19-18h26m08s662.png

音程が高くなるにつれて、トータルの音声レベルが低下していく。 また、出力コンデンサーに蓄積したDC成分が増大するにつれて、ダイナミックレンジが狭まっていく。 コンデンサーの放電を行うためには発音を中断しなければならない。

vlcsnap-2018-06-19-18h26m19s827.png

各オシレーター出力のピークにオフセットを掛けることで、更に複雑な動的制御が可能となる。

vlcsnap-2018-06-19-18h26m34s997.png

これは、ディストーション・サウンドの典型的な波形。

vlcsnap-2018-06-19-18h26m58s107.png

そこに、いきなりサイン波のスリットが入ってくる。

ここからは、Transitionモードの波形を紹介していく。

vlcsnap-2018-06-19-18h36m48s866.png

VolumeAntと相関させる形でオシレーターのピークポイントをズラすことで、倍音構成に動的な変化を与えている。 コードを演奏する場合は、これにピッチのグラデュエーション効果が加わる。

vlcsnap-2018-06-19-18h36m57s306.png

極限値なので判り難いが、和音の構成を操作している。

vlcsnap-2018-06-19-18h37m12s093.png

発振周波数が高くなった場合の反応。

vlcsnap-2018-06-19-18h37m20s623.png

和音の構成が、、、

vlcsnap-2018-06-19-18h38m10s468.png

段階的に変化していく。

vlcsnap-2018-06-19-18h38m40s293.png

TransitionControlはオシレーターに配分された和音の構成が順送りされる仕組みだが、オシレーター側の設定次第で中間地帯に高い音を仕込むことが可能。

vlcsnap-2018-06-19-18h39m07s340.png

Transitionの最終ポイントで波形は固定される。

vlcsnap-2018-06-19-18h39m25s627.png

TransitionModeを単音で運用した場合、倍音の比率や位相の異なる波の干渉に因って出音の音色が変化する。

vlcsnap-2018-06-19-18h39m42s585.png

音色は段階的に変化したあと、、、

vlcsnap-2018-06-19-18h40m09s085.png

Transitionの最終ポイントに配置されたオシレーターの発音に固定される。

vlcsnap-2018-06-19-18h41m21s318.png

MCUの処理が追いつかなくなると、このように波形の不連続面が発生し、それはノイズとして認識されてしまう。

vlcsnap-2018-06-19-18h42m19s197.png

極端に低いピッチを設定した場合、波形に段差が発生する。

vlcsnap-2018-06-19-18h42m27s890.png

これは、TransitionModeに於いて、PitchMemoryModeで編集した和音構成を展開した時に生じる典型的な例。

vlcsnap-2018-06-19-18h42m35s995.png

このザラつきも、ノイズとして認識される。

vlcsnap-2018-06-19-18h42m43s610.png

処理に割かれるリソースが過大な現状ではadatの送信はかなり厳しいと言わざるをえないが、とりあえずはch数を減らした状態で送信実験を行ってみる予定。
posted by Yasuski at 20:12| open.Theremin

Open.Theremin@OverloadModeを実装する

Overloadモードがようやく稼動状態になった。



音声が出力されなかった原因は複数あって、、、

IMG_8069.JPG

1)DAC周りの回路の配線ミスで、BIAS電圧が供給されていなかった。
2)そのうえ、GNDの接続も適当で、断線している箇所があった。
3)OpAmpのSOIC/.DIP変換基板が不良品で、接続されるべき端子が浮いていた。

IMG_8070.JPG

と、1/3は自分の所為ではなかったのだが、全体的にアホっぽい原因なのが情けない。

で、ノイズをキャンセルするために追加した機能の所為でタスクがオーバーフローした結果、ポリフォニック動作時に出力がノイズまみれになるという本末転倒な事態が発生していた。

この問題を回避するために、WCKの立ち上がり毎に分けていたDACへのデータ送信を旧来のWavetableを参照してミックスを行った後に一括処理するスタイルに戻したところ、ノイズは消滅し、余録として起動時のピポパ音も復活させることが出来た。

Overloadモードは波形をクリップさせる手前、事前にレベルのプリセットが必要で、作業の1/4は最適値を探りだすために費やされることになった。

posted by Yasuski at 12:18| open.Theremin

2018年06月17日

Open.Theremin@TransitionModeを実装する



VolumeControl系のデータの扱いに関しての備忘録。

音量のコントロールには、Wavetableに記録したサインカーヴを使用する。 データのステップは12bitを基本とし、全体の音量を12bit/トランジションの音量を11bitの分解能で制御する。

周波数ディテクターは、オシレーター出力のデューティーサイクルを16bit幅の周波数カウンターでカウントしているが、Volume側ではその14bit分を扱う。 採取されたValueは最終的に3bit右シフトを行って11bit/FSに加工する。 

WS001303.JPG

この11bitステップで音声コントロール用に準備した1/4波長プラス側サイン波のWavetableを参照した後、結果にLPFを挿入してデータのフラつきを防ぐ。 これが、基本的な音声出力カーヴとなる。

WS001305.JPG

現在設定しているVolume側のウエイト値、EMA_b は暫定で0.33を設定しているが、今後は実際に運用を行って最適化を進めていく。

WS001296.JPG

一方、Transitionコントロールを行うための波形は、中央にピークを持たせたプラス側半波長のサイン波で、ステップ数/分解能が共に11bitのWavetableを参照する。 

WS001307.JPG

このデータを基本として、対象となる各オシレーター分の読み出しアドレスにオフセットを掛けたものを準備する。 オフセットの初期値はオシレーター毎に400ステップを設定しているが、これはロータリーエンコーダーよって変更が可能とした。 トータル音声出力のレベル設定は、先に出力した12bit幅の音声出力カーヴとローカルの音声出力パターンを掛けあわせたものを圧縮した12bit/FSで行う。 この出力にも最終段階でLPFによる丸めを個別に行っている。

WS001310.JPG

こちらは、トランジションモードの出力波形とVolume側のオシレーターの相関を記録した映像。



今後、レベル設定の最適化を行う必要があるが、実用上問題がない範囲で可変域を制限した方がよさそうだ。

その後、帰還型のLPFの時定数を変更して、よりデータの変動を抑える方向にチューニングを行った。



モノラル出力の場合には有効性が証明されたが、タスクが重いポリフォニック・モードでは時間切れでノイズが発現してしまうようだ。

以下のサイトをLPF製作の参考にした。

https://www.norwegiancreations.com/2015/10/tutorial-potentiometers-with-arduino-and-filtering/
posted by Yasuski at 23:33| open.Theremin

2018年06月16日

Open.Theremin@新型機がようやく稼動状態になった

開発がスタックしていたオリジナル基板を実装した新型テルミンについて。 

各種時定数の最適化に時間が掛かったが、ロータリーエンコーダーの極性の反転、Volumeコントロールを行う部分のデータ・ハンドリングの修正、誤記のチェック、オーバークロック化に対するカウンタ分周値の最適化等の対症療法を行った結果、曲がりなりにも音が出るようになった。



現時点で、発音されるはずの起動音が聞こえない、メモリー登録時のアラートも同様に聞こえない、断線気味のPitchアンテナ端子による回路の不安定化、調整がクリティカル過ぎるVolumeオシレーター、サブDACの動作不良、、、等々、実際の運用に直結する問題が解決できておらず、現場への投入は無理と判断している。

時間を掛けて調整を行えばなんとか楽器っぽく動作するレベルに落ち着いているが、特にVolumeの扱いが難しい。

追記:

波形を確認したが、ノイズっぽいのはなんとかならんのか、、、。
posted by Yasuski at 16:13| open.Theremin

Open.TherminOnTeensy@pin configurations

#define log10f_fast(x) (log2f_approx(x)*0.3010299956639812f)

#define BAUD 115200 // uncomment if serial is implimented

#define LATCH01 27
#define LATCH01_ON (CORE_PIN27_PORTSET = (1<<15))
#define LATCH01_OFF (CORE_PIN27_PORTCLEAR = (1<<15))

#define LATCH02 20
#define LATCH02_ON (CORE_PIN20_PORTSET = (1<<5))
#define LATCH02_OFF (CORE_PIN20_PORTCLEAR = (1<<5))

#define LATCH03 21
#define LATCH03_ON (CORE_PIN21_PORTSET = (1<<6))
#define LATCH03_OFF (CORE_PIN21_PORTCLEAR = (1<<6))

#define LATCH04 18
#define LATCH04_ON (CORE_PIN18_PORTSET = (1<<3))
#define LATCH04_OFF (CORE_PIN18_PORTCLEAR = (1<<3))

#define LATCH05 16
#define LATCH05_ON (CORE_PIN16_PORTSET = (1<<0))
#define LATCH05_OFF (CORE_PIN16_PORTCLEAR = (1<<0))

#define LATCH06 15
#define LATCH06_ON (CORE_PIN15_PORTSET = (1<<0))
#define LATCH06_OFF (CORE_PIN15_PORTCLEAR = (1<<0))

#define LATCH07 17
#define LATCH07_ON (CORE_PIN17_PORTSET = (1<<1))
#define LATCH07_OFF (CORE_PIN17_PORTCLEAR = (1<<1))

#define CKW 25
#define CKW_ON (CORE_PIN25_PORTSET = (1<<5))
#define CKW_OFF (CORE_PIN25_PORTCLEAR = (1<<5))

#define DATA01 26
#define DATA01_ON (CORE_PIN26_PORTSET = (1<<14))
#define DATA01_OFF (CORE_PIN26_PORTCLEAR = (1<<14))

#define LED 7 // LED on D7
#define LED_ON (CORE_PIN7_PORTSET = (1<<2))
#define LED_OFF (CORE_PIN7_PORTCLEAR = (1<<2))

#define LEDgrn 8 // LED on D8
#define LEDgrn_ON (CORE_PIN8_PORTSET = (1<<3))
#define LEDgrn_OFF (CORE_PIN8_PORTCLEAR = (1<<3))

#define LEDred 9 // LED on D9
#define LEDred_ON (CORE_PIN9_PORTSET = (1<<3))
#define LEDred_OFF (CORE_PIN9_PORTCLEAR = (1<<3))

#define LED2grn 38 // LED on D38
#define LED2grn_ON (CORE_PIN38_PORTSET = (1<<11))
#define LED2grn_OFF (CORE_PIN38_PORTCLEAR = (1<<11))

#define LED2red 37 // LED on D37
#define LED2red_ON (CORE_PIN37_PORTSET = (1<<10))
#define LED2red_OFF (CORE_PIN37_PORTCLEAR = (1<<10))

#define LED2 39 // LED on D39
#define LED2_ON (CORE_PIN39_PORTSET = (1<<17))
#define LED2_OFF (CORE_PIN39_PORTCLEAR = (1<<17))

#define buttonPin01 11 // Button Pin on D11
#define button_State1 (CORE_PIN11_PINREG & (1<<6))

#define buttonPin02 36 // Button Pin on D36
#define button_State2 (CORE_PIN36_PINREG & (1<<9))

#define buttonPin03 3 // Button Pin on D3
#define button_State3 (CORE_PIN3_PINREG & (1<<12))

#define buttonPin04 4 // Button Pin on D4
#define button_State4 (CORE_PIN4_PINREG & (1<<13))

#define buttonPin05 5 // Button Pin on D5
#define button_State5 (CORE_PIN5_PINREG & (1<<7))

#define buttonPin06 6 // Button Pin on D6
#define button_State6 (CORE_PIN6_PINREG & (1<<4))

#define LEDvol 28 // LED on D28
#define LEDvol_ON (CORE_PIN28_PORTSET = (1<<16))
#define LEDvol_OFF (CORE_PIN28_PORTCLEAR = (1<<16))

#define LEDvol2 13
#define LEDvol2_ON (CORE_PIN13_PORTSET = (1<<5))
#define LEDvol2_OFF (CORE_PIN13_PORTCLEAR = (1<<5))

#define SAMPCLK_STATE (CORE_PIN19_PINREG & (1<<2)) //sampling clock in
#define SAMPCLK_MASK (CORE_PIN19_CONFIG = PORT_PCR_IRQC(0)) //masking sampling clock in
#define SAMPCLK_ACTV (CORE_PIN19_CONFIG = PORT_PCR_IRQC(9)) //activate sampling clock in

#define SCK01 30
#define SCK01_ON (CORE_PIN30_PORTSET = (1<<19))
#define SCK01_OFF (CORE_PIN30_PORTCLEAR = (1<<19))

#define SD01 32
#define SD01_ON (CORE_PIN32_PORTSET = (1<<11))
#define SD01_OFF (CORE_PIN32_PORTCLEAR = (1<<11))

#define CS01 29
#define CS01_ON (CORE_PIN29_PORTSET = (1<<18))
#define CS01_OFF (CORE_PIN29_PORTCLEAR = (1<<18))

#define LDAC01 33
#define LDAC01_ON (CORE_PIN33_PORTSET = (1<<24))
#define LDAC01_OFF (CORE_PIN33_PORTCLEAR = (1<<24))

#define DAC16 40
#define DAC16_ON (CORE_PIN40_PORTSET = (1<<28))
#define DAC16_OFF (CORE_PIN40_PORTCLEAR = (1<<28))

#define DAC16_2 31
#define DAC16_2_ON (CORE_PIN31_PORTSET = (1<<10))
#define DAC16_2_OFF (CORE_PIN31_PORTCLEAR = (1<<10))
posted by Yasuski at 07:45| open.Theremin

2018年06月15日

Open.TherminOnTeensy@音声出力波形を観測する

テルミンのWCK強制同期回路の試作は失敗した模様。

インターラプトが動作するポイントにマーカーを追加して、動作不良の原因を探ることになるが、そもそもLoopの設定がアカン感じがする。

何故か単音しか出力されず、出力に妙な変調が掛かったり、インジケータのLEDが動作不能だったりするが、とりあえず左手でVolumeをコントロールできるまでにはなった。

Screen Shot 2018-06-14 at 19.51.05.png

とにかくチューニングがクリティカル過ぎてお話にならないが、アンテナ長分のオフセット設定は計算通りにはいかず、収納する筐体に因ってもズレが発生するのが大問題。

Screen Shot 2018-06-14 at 20.09.52.png

やはり、24bitの計算は無理っぽいので、16bit対応でひとまずまとめることにするかオーバークロックにトライするかで迷うところだが、まずはオーバークロックで無理を確認する。

Screen Shot 2018-06-14 at 20.11.10.png

その後、240MHzにオーバークロックして発音を確認。 相変わらず何かが変だけど、とりあえず音の制御は出来ている。



WCKを32kHzで廻すのもアリ。そもそもがハイファイを目指す意味が無さそうだし。
posted by Yasuski at 20:51| open.Theremin

2018年06月12日

Open.Theremin@attatchInterruptの項目を追加する

DACの読み出しを行うタイミングの制御に関して思いついたこと。

プログラムの基本的な構造は、アンテナのセンシングやロータリーエンコーダーの読み出しを行っているメインループと、そこにWCKが立ち上がるタイミングでDACへのデータ送信を行った後に波形データを読みだす一連のタスクが割り込む仕組み。

現状ではadat等のWCKの表裏でデータを扱うタスクの実現は難しく、当初はその対策としてメインループの先頭に音声データをDACに出力する仕掛けを追加していたが、データラインの波形を観測した結果、インターラプトからの復帰後に行われる筈のデータ転送のタイミングが安定していないことが判った。

当初、ズレの原因は波形読み出しのタスクの重さから発生する遅延の影響と仮定していたのだが、インターラプトから復帰するタイミングによってズレのバラつきが生じる可能性に思い至った。

この変動するズレの問題を解決するには、WCKの立ち下がりで発動する別のインターラプトを追加して強制的にDACにアクセスするタイミングを固定する方法が有効と思える。(波形を読み出す際のタスクの重さは無視して)とりあえずはこの機能を実装してみたところ、コンパイルだけは通せたのが現時点での状況。

前述したように、この機能はタスクの重さに因って破綻する可能性があり、まずは実験による観測が必要だ。

adatフォーマットの取り扱いに関しては、外部にFPGAによるデータラッチを追加し、WCKの裏面でバースト信号を受信/表でフォーマットに準拠したタイミングで送信を行わせている。

基板にadat系のチップを実装してはいるが、データのハンドリングを行うFPGAの有効性は実証されていない。データ送りのタスクに要する時間(1サイクルでクロックを40余りも消費する)の制限は大きく、実質的には4〜5chの送信が限界と思われる。

既に波形の観測によってattatchInterruptによる遅延が可視化されているが、タイミング的にはWCKに同期していれば問題はない。ただし、この遅れによってシステム全体の処理に要する時間的余裕が削られてしまうのはマズいので、直接的にピンの状態を参照する仕掛けを探る必要がある。

ダイレクトアクセスのアドレスとして既にSAMPCLK_STATEを仕込んであるので、ひとまずattatchInterruptにこれをアサインしてみよう。
posted by Yasuski at 10:42| open.Theremin