2018年01月31日

OpenTheremin@OverloadModeの波形を観測する

先に録画したTransitionにOffsetを掛ける音声の波形を表示してみた。



複雑な倍音構成がシームレスに変化していくのが判る。
posted by Yasuski at 22:36| AudioElectronics

OpenTheremin@Shield上のオシレーターのチューニングを行う

取り敢えず通電してはみたものの、オシレーターのドリフトが半端無く修正が必要。

27336681_1745658995464551_6693773792431257881_n.jpg

Vari-Capを駆動するVolume側のDAC2Bの修正値は4095でフルレンジ。こちらは、オシレーターの周波数が低過ぎるということで、現状330pFの設定を小さくする必要が。一方Pitch側のDAC2Aはどのレンジも対応できず、周波数を下げる方向で調整が必要。 現状は150+10pFなので、これを180pF程まで調整しなければならない。

結局、オシレーターの周波数チェックに一日を費やしてしまったが、夕刻になってようやく適正値にチューニングを追い込めた感触があった。 LCタンクのコンデンサの設定値は、Pitch側は150pF+17pF、Volume側は220pF+100pFで手打ちとしたが、理想値は180pF/310pF辺りになるだろう。

ただし、温度変化や電圧変動によって周波数がドリフトする環境に於いて、最後は電池切れによって作業を中断した情況なので、最適値が確定したと判断するのは早計か。 温度や電圧の変動の影響を考えると、やはり相対誤差の減少を目指す方向でシステムを構築したほうが良いと改めて結論している。

充電池を使っていたのは、アンプの電源投入時にシステムが怪しい挙動を示したためで、案の定交換した電源ICのジャンクパーツに不調が見つかった。 一度何かの拍子に不具合が発生するとそのまま破壊が進行していくことが判ったので、トラブル対策として電源ラインに保護用のツェナーダイオードを絶対に入れるべきだろう。 

怪しい部品は別の動作が保証されたジャンク品と交換した。 これでアンプの電源電圧に対応出来る筈だが、そのアンプ自体も極低温環境によって早々に電池切れとなって仕舞ったため、今日の作業はここで終了。

posted by Yasuski at 18:20| open.Theremin

2018年01月30日

OpenTheremin@緑基板が復活するもShield側の不調が続く

修理したテルミンに通電を試みたが、ガサゴソいうだけでオシレーターの差分をセンシング出来ない。 そのうちに、ガサゴソが沈黙してレベル変換ICの発熱が始まった。

IMG_7857.JPG

緑基板単体に関しては、MCUの健全性が確定していないもののデジタル通信の出力・レベル変換は正常に動作している模様。 問題は周波数カウンタの入力が生きているかどうかだが、これの検証を行うにはオシレーター側の正常な動作が前提となってしまう。

一方、Shieldの方は唯一交換していなかったオシレーター周りのチップが仇になったのか、発振を確認できなかった。 これを交換した後に再チェックを行う予定だが、現状は故障のドミノ倒しを連想させられる情況であまり良い雰囲気ではない。

これ以上の延焼を防ぐためにはShield単体のチェックを行うべきなので、午後は専用の電源を用意して故障判定システムの立ち上げを行うことにしよう。

追記:

OpenThereminShieldの修理を完了した。 

死亡していたオシレーターのチップMC4069を、ピン配置が同等のHC14に交換。インバーターの反応スピードが異なるために発振周波数にも若干のズレが生じているようだ。

ついでに配線関連のリファービッシュを行った後に緑基板を繋いでオシロスコープで回路を検査したところ、DAC→VariCapの制御系の正常な動作を確認できた。 VolumeAntのアウトレンジ状態を表示する出力(目玉LED)も反応しているので、MCU上の周波数カウンタ入力はダメージを受けていない模様。

IMG_7858.JPG

あとはチューニングを行って動作を確認することになるが、これがセオリー通りには動かず、結構面倒な作業だったりする。
posted by Yasuski at 11:35| open.Theremin

2018年01月29日

OpenTheremin@白基板系の試作機も再起不能に

白基板に実装したTeensy3.5がSerialPortから認識されなくなる案件が発生。 試しにストックの3.5(未使用)を試したが、こちらも何故かポートが認識されない。 ArduinoのVersionは1.8.5、Teensyduinoは1.41とどちらも最新版をインストールしている。 パソコンの再起動後も症状は変化なし。

ちなみに、Teensy3.6は使用中のものもストックも問題なく認識されている、、、。

事故発生前の前兆現象として、RGBロータリーエンコーダーの赤LEDが反応せず、端子のラッチアップが疑われた。 静電気が悪さをしているのだろうか?

実装を試みているハモンド製のキャスト筐体は、クリアランスが厳しくMCUをソケットを介して実装できない。ID-292系列の基板も実装は厳しく、特別にオシレーターのみを分離した回路を組むことになりそうだ。ピギーバック系の基板を2階建てにして、片方をオシレーター専用のプラットフォームとする手もある。

部品調達のタイムラグが懸念されるので早急に追加発注を行うつもりだが、Teensyは3.6だけに絞ったほうが良さそう。


追記:


追試の結果、白基板の死亡を確認。 動作していたロータリーエンコーダが反応しなくなった。Teensyはどうも段階的に死亡に至るようで、経験則ではあるが、ラッチアップ → 通信の途絶 → 完全に死亡 というステップを踏むようだ。

仕方がないので白基板はドナーとして再利用することになるが、まずは緑基板にレベルシフトICを移植しておいた。 この緑基板にはTeensy3.6が搭載されているが、先のトラブルでカウンタ端子に過電圧が掛かっていた場合は、こちらも徐々に動作不能に陥っていくことになる。

posted by Yasuski at 15:59| open.Theremin

2018年01月28日

OpenTheremin@試作機の再組み立てを失敗/回路が死亡する

試作中の短絡事故で電源ICをぶっ飛ばしてしまったが、在庫がない(郵政の無能な職員が発注した部品を送り返した)ので作業がストップしている。

WS001227.JPG

他の基板から該当する部品を引剥して起動させたものの、今度はOpenThereminのShield基板がご逝去された様子。チップの半分位はリプレイス用の部品と交換すればなんとかなりそうだが、焦って部品を交換する前に、オシレーターの発振を確認したほうが良い。

起動音のピポパが出ていて、ロータリーエンコーダーのプッシュスイッチも動作していることから、MCUは飛んでいない模様。

発振器の動作やロジックラインの信号をオシロで測定した結果、運良くSheld側の破壊を免れていた模様。一方、MCUからの信号をShield側のDACが受信しておらず、オシレーターのチューニングが出来ない。 青基板の前例からレベル変換ICのご逝去が疑わしくなった。 

WS001226.JPG

幸いこのパーツは一個だけ在庫が存在したので、虎の子のそれを使うか、もしくはジャンク基板からサルベージを行って急場をしのぐことにする。 

ちなみに、注文した行方不明なパーツの発送は遅れてるというか、社内でもこれまた行方不明っぽい情況なので予断は許されず、必要なパーツは別途調達しておいたほうが賢いとの判断に傾きつつある。

事故は二回目なので、MCUの書き換え時にpinの接続を失敗してしまう試作機の仕様がオカシイのだが、次期モデルでは其辺の構造を改良しなければならない。

追記:

組み直した緑基板にアンプを接続して再通電を行ったところ、今度は緑基板上に設置していたシングルチップのドライバICがご逝去されたことから、

WS001228.JPG

Shield側のチップにも死亡・短絡が発生していることが確認された。

WS001225.JPG

アンプに接続する前にバッテリーで通電していた時にはShield側のオシレーターの作動と差分出力を確認していたことから、レベル変換ICの動作不良が疑わしいと結論し、レベル変換ICのみを交換して再トライしたのだが、交換した中古のレベル交換ICにも不良が発生していたようで(そういえば、ジャンクの供給元になった筐体も原因不明で沈黙していた)死亡したシングルチップICを交換した後に、Shieldを接続しない状態でレベル変換が行われていないことを確認している。

WS001229.JPG

これはつまり、短絡によって"H"レベルに固定された出力に過電流が生じた結果、レベル変換ICが破壊されたと想定されるが、同時に接続先のMCP4922も死亡していると結論せざるを得ない。 ひいてはOpenThereminShieldは全半導体パーツを交換することにした。 音声出力の死亡も事前に確認しているが、このICだけは手持ちが無く欠番として処理する他はない。

つまりは、さっさとシングルボード機を完成させろということになるのであろう。

追記2:

先程OpenThereminShieldを調査した結果、12bitDAC/MCP4922のパッケージ上にスポットを発見し死亡を確認した。 

IMG_7862.JPG

基板上の4069が動作していたのは、耐圧が15Vと旧CMOS系の仕様だった為と思われる。

電源レギュレータICの破壊が入出力のショートモードに進行したと仮定すると、過去に発生した事故による部品の損壊パターンの説明が付く。よって、過電圧を供給されたHCMOS系とDACは全滅したものと思って間違いないだろう。

同時に緑基板上の5V系も全滅した筈だが、MCUはTeensy上のレギュレーターによって破壊を免れたと判断している。
posted by Yasuski at 06:54| open.Theremin

2018年01月27日

OpenTheremin@試作機の再組み立てを失敗/回路が死亡する

試作中の事故で電源ICをぶっ飛ばしてしまったが、在庫がない(郵政の無能な職員が発注した部品を送り返した)ので作業がストップしている。

他の基板から該当する部品を引剥して起動させたものの、今度はOpenThereminのShield基板がご逝去された様子。チップの半分位はリプレイス用の部品と交換すればなんとかなりそうだが、焦って部品を交換する前に、オシレーターの発振を確認したほうが良い。

起動音のピポパが出ていて、ロータリーエンコーダーのプッシュスイッチも動作していることから、MCUは飛んでいない模様。

発振器の動作やロジックラインの信号をオシロで測定した結果、運良くSheld側の破壊を免れていた模様。一方、MCUからの信号をShield側のDACが受信しておらず、オシレーターのチューニングが出来ない。 青基板の前例からレベル変換ICのご逝去が疑わしくなった。 幸いこのパーツは一個だけ在庫が存在したので、虎の子のそれを使うか、もしくはジャンク基板からサルベージを行って急場をしのぐことにする。 

ちなみに、注文した行方不明なパーツの発送は遅れてるというか、社内でもこれまた行方不明っぽい情況なので予断は許されず、必要なパーツは別途調達しておいたほうが賢いとの判断に傾きつつある。

その後、国内に資材が無い事を確認して必要なパーツのみを海外に発注した。モノは消耗品っぽい汎用性が高い代物なので、発注が重複する分には問題ないが、価格が倍以上するのは頂けない。

しかし、電源の短絡でぶっ壊れるデバイスというのは、パワーエレクトロニクス系以外では(コレは当たり前)あまり見掛けないような気がする。レベル変換ICは、電源電圧の変動に対してデリケートなのだろうが、片方の電源が瞬断した場合に道連れとなる仕様は危なっかしい。

事故は二回目なので、MCUの書き換え時にpinの接続を失敗してしまう試作機の仕様がオカシイのだが、次期モデルでは其辺の構造を改良しなければならない。

posted by Yasuski at 18:45| open.Theremin

2018年01月26日

OpenTheremin@TransitionControlにOffset設定機能を実装する

TransitionControllerの参照波形に関する考察。

やはりピークのQを可変にしないと動作が破綻しそうなのだが、これを計算式で行うのと予め用意したWavetableを切り替えて行うという2つの方法を思い付く。

パラメーターの変化に即応性が要求されない一方で、発音時にDoubleで計算するとレイテンシーが発生する問題があり、RAMの専有領域が増えるものの速度面からするとWavetableを切り替える方式の方が良さ気な雰囲気だ。 既に、制御波形の後半に糊代分の無音地帯を1024アドレスくっつけた"Q"のピークが異なる8種類のWavetableを製作している。

で、既に実装済の単純に読み出しポイントをズラす方式を試してみた。



結果は必要十分だったので、暫くはこの方式で運用試験を継続することになる。

次は試行錯誤の過程で思いついた、音源の波形にオフセットを掛ける実験を行う予定。
posted by Yasuski at 16:10| open.Theremin

2018年01月25日

OpenTheremin@Transitionにオフセットを掛ける

今日は、OverLoadモードと通常モードのレベル差をチェックしていたが、気になったのはTransitionModeのリエゾンの扱いで、選択するモードによって動作の違いがとても大きくなることが判明している。

問題を解決するには、和音のピッチ制御と同じような仕掛けでオフセット値を変化させるのが正解なのだが、これを大まかな設定値の切り替えで行うのか、ユーザーが微調整を行うのが良いのか、判断が難しいところだ。

現状は折衷案としてVolumeノブを使ってTransitionの感度を調整しているが、記録するパラメーターを増やした方がより便利に運用できそうだ。

現行のシステムではTransitionControllerの波形にサイン波のプラス側の山を半波使用している。

controlSignals.png

この波形の開始位置をズラしたWavetableを6波用意して各音源毎のヴォリュームコントロールに宛てているが、Transitionの間隔を変更する場合には基本とする1波にオフセットを掛ける形に変更する手法が正解だろう。 つまり、ヴォリューム・コントロール用のWavetableを読みだすアドレス用の関数、vol_mod にオフセットを掛ければよい。

で、実際のコードはこんな感じになった。

if ((vol_16> 0)&&(vol_16<4096))
{vol_mod = (((vol_16 + 2047 ) % 2047));
vol_mod_2 = (((vol_16 + 2047 + (vol_offset + 340)) % 2047));
vol_mod_3 = (((vol_16 + 2047 + (vol_offset + 680)) % 2047));
vol_mod_4 = (((vol_16 + 2047 + (vol_offset + 1020)) % 2047));
vol_mod_5 = (((vol_16 + 2047 + (vol_offset + 1360)) % 2047));
vol_mod_6 = (((vol_16 + 2047 + (vol_offset + 1700)) % 2047));
} // volume value as the controller if value in range

vol_mod = constrain(vol_mod, 1, 2047);
vol_mod_2 = constrain(vol_mod_2, 1, 2047);
vol_mod_3 = constrain(vol_mod_3, 1, 2047);
vol_mod_4 = constrain(vol_mod_4, 1, 2047);
vol_mod_5 = constrain(vol_mod_5, 1, 2047);
vol_mod_6 = constrain(vol_mod_6, 1, 2047);

temp_Volume_a = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod)));
temp_Volume_a = ((temp_Volume_a * vol_16)>>11) + 1;

temp_Volume_b = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod_2)));
temp_Volume_b = ((temp_Volume_b * vol_16)>>11) + 1;

temp_Volume_c = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod_3)));
temp_Volume_c = ((temp_Volume_c * vol_16)>>11) + 1;

temp_Volume_d = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod_4)));
temp_Volume_d = ((temp_Volume_d * vol_16)>>11) + 1;

temp_Volume_e = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod_5)));
temp_Volume_e = ((temp_Volume_e * vol_16)>>11) + 1;

temp_Volume_f = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod_6)));
temp_Volume_f = ((temp_Volume_f * vol_16)>>11) + 1;


posted by Yasuski at 14:50| open.Theremin

2018年01月24日

OpenTheremin@DACの選定に関して

オーディオ専用DACは基本形態がステレオ運用/データ型が2’sコンプリで右詰めなために、マイコンと接続を行うにはタイミングの制御が難しい。

IMG_7853.JPG 

ならば、FPGAで専用のデータレジスタを組んでもよいのだが、より直接的な方法として高分解能な工業用のDACを使う手もある。

去年はMAX5541という16bit分解能でコスパが良いチップを発見しているが、何故かこれの製作例を見つけらない。まあ、シンプルに運用できるものなので問題はないのだが、自作界隈ではマイナーな扱いなのだろうか。

オーディオ専用DACのデータ入力のタイミングチャートは最も単純なものでもこんな感じで、

WS001222.JPG

これにヴォリューム設定やらなんやらの付加機能がくっついてかなり難解なことになっているのが最近のトレンド。多分、カーステ用途を意識していると思われるも、単純な楽器に組み込むには無理がありすぎる。 オーディオ専用のチップは単機能なタイプであっても、WSが固定周期でDINが右詰めなのが使い難い。

一方、これがMAX5541のタイミングチャートで、CSの立ち上がりでデータが確定するという物凄くシンプルなルール。

WS001221.JPG

MAX5719は20bitなのが魅力的ではあるが、データ確定パルスを受けるLDACが追加されて通信に4線必要なのと、何故かBCKに24クロック要求されるのがややこしい。

WS001223.JPG

ちなみに、16bit版のMAX5717はLDACが必要であるもののBCKは16発でOKなので、使い勝手は良い。
posted by Yasuski at 10:52| open.Theremin

2018年01月23日

OpenTheremin@DAC動作不良の原因を発見か?

音楽を聞きながら、プレーン状態の基板を何気に見つめていたところ、DACに接続するリファレンス電圧を生成している回路周りの配線が怪しそうだと思いつく。

試しに、Eagleの回路図を調べたところ、"R16"の電源電圧側の端子が断線していることが判明した。 

WS001218.JPG

画像は修正済の回路パターンで、端子の直近に電源ラインが通っているために修正を行うのは容易だが、なんとも情けない話ではある。

WS001219.JPG

これで、問題が完全にフィックスされるという保証は無いが、ひとまず修正を行ってみよう。

複数チャンネルのDACが稼働すればOverLoadMode時に発生するレベル差の問題を物理的に解決出来るので、ここが頑張りどころだ。

追記:

無事、16bitDAC、MAX5541/2系統の動作を確認した。 

IMG_7851.JPG

OverLoad系の出力は新たに専用の出力系統を追加して、16bit精度でアウトすることになった。 

IMG_7852.JPG

次の改良ヴァージョンでは、基板上にレベル調整用のトリマを追加する予定。



posted by Yasuski at 11:01| open.Theremin

2018年01月22日

OpenTheremin@倍音構成のプリセットに関して

OverLoadModeを2音構成で実験しているが、多彩なパターンで倍音のコントロールを行えることが判ってきた。



例えば、2音で出力を構成した場合、

case 2: pointer = pointer + (add_val);
pointer2 = pointer + (add_val);
pointer3 = pointer + (add_val);
pointer4 = pointer4 + (add_val * pitch1);
pointer5 = pointer5 + (add_val * pitch1);
pointer6 = pointer6 + (add_val * pitch1);
break;


のように、前後半にバンクがハッキリと分かれているために、判り易い形で倍音構成の変化を体感できる。

これが3音になると、

case 18: pointer = pointer + (add_val);
pointer2 = pointer + (add_val);
pointer3 = pointer3 + (add_val * pitch5);
pointer4 = pointer4 + (add_val * pitch5);
pointer5 = pointer5 + (add_val * pitch9);
pointer6 = pointer6 + (add_val * pitch9);
break;


構成が複雑になった分、左手のオペレーションの難易度が上がってくる。 

4和音の場合は更にリエゾンが細かくなるが、

case 27: pointer = pointer + (add_val);
pointer2 = pointer + (add_val);
pointer3 = pointer3 + (add_val * pitch4);
pointer4 = pointer4 + (add_val * pitch4);
pointer5 = pointer5 + (add_val * pitch7);
pointer6 = pointer6 + (add_val * (2 + pitch2));
break;


実用性を考えて、自然な感覚の倍音構成を意識したチューンに変更を行うべきだろう。

つまりは、プリセット音階を用いて最適化するのが一番賢い方法と思われるので、今後は専用のアレンジを考えていくことにする。
posted by Yasuski at 21:16| open.Theremin

OpenTheremin@新たに認識されたバグを修正する

まず、Wavetableの選択時にフリーズが発生する深刻なバグは、potXが負の値にならないように対策を行うことで解決できた。

case 16: pot9 += encoder2->getValue();
if (pot9 != lastV ) {
lastV = pot9;}
if (pot9 < 0){
pot9 = 0;}

pot9b = ((pot9 >> 2) % 21);
if (pot9b > 21){
pot9b = 21;}
if (pot9b < 1){
pot9b = 1;}
else{
pot9b = pot9b; }; break;


次に、TransitionControl時に発生していたリエゾンでピッチに段が付く現象は、ヴォリューム設定値に+1のオフセットを加える事で解決。

temp_Volume_a = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod)));
temp_Volume_a = ((temp_Volume_a * vol_16)>>11) + 1;


ついでに、Wavetableを読みだすパートにもオフセットを追加しておいた。

temp2_val_a2 = ((temp_val_a * temp_Volume_a) >> 9)+ 1;
temp2_val_a = (temp_val_a * vol_16) + 1;
temp2_val_a = (temp2_val_a >> 9) + 1;


トランジションモードにおいて音色メモリー時のアドレス告知音が聞こえなくなる現象は、Wavetableの音量設定を行うパラメーターを並列化したために発生していた。 これをフィックスするため、該当部分に音量設定用の関数、 temp_Volume_a = 1024; を加える修正を行った。

以上で、新たに認識されたバグは全て潰すことができたが、起動時にオシレーターの周波数を設定するDACに値が読み込まれない現象は未だ解決の目処が立っていない。

posted by Yasuski at 15:34| open.Theremin

2018年01月21日

OpenTheremin@OverLoad機能専用のメモリーCHを設定する

利便性を向上させるために、新設したOverLoadModeの記録を行うためのアドレスを3ch分追加することにした。

改修後のアドレス設定は、TransitionControlModeが10ch、FixedAdditiveWaveformModeが3ch、OverLoadModeが3chといった布陣となっている。

OverLoadModeは追試を行った時の再現性が問題となっているが、メモリー機能の追加が助けになることを期待している。

実験の結果、基本波×6のセッティングが使い易い感触で、これを3和音モードによって倍音構成を決定し、トランジション=左手の振り幅をVolumeノブで調整する用法が的確と思われる。 各波形の選択に関しては、非対称波の扱い方次第で表現の可能性が広がることを感じているが、試行錯誤を行う前に予め左手の物理的な挙動と出音との相関関係を理解しておく必要がある。



また、波形選択時にアドレスの最小値以下(左回り)にノブを回転させた場合に発生するハングアップが問題となっていて、これの予防を行うべくコードの精査が必要だ。
posted by Yasuski at 12:33| open.Theremin

2018年01月20日

OpenTheremin@左手でディストーションをコントロールする

ヴォリューム機能を実装する過程で、アドレス#15の出力値固定で波形のみを選択できるモードが過負荷による機能不全に陥ってしまった。

が、これは使い方次第で面白い表現が出来そうなので、改善を行わずにこのままの状態を温存することにした。



ディストーションのコントロールは左手で行うが、操作できる位置はかなりクリティカルなので演奏にはある程度の熟練が必要。 この時点で選択した波形は全て基本サイン波。 同一波形を選択することで、より容易に歪を得ることが出来る。 和音モードを利用することで、波形を選ばず恣意的にそれっぽい倍音を構成できる。

また、波形の選択によって、より複雑な倍音を得ることが出来そうだ。

有感帯が狭いのが欠点だが、今後はそれを含めてセッティングを研究していきたい。
posted by Yasuski at 19:12| open.Theremin

Open.Theremin@VolumeControl系の改装案

夢のなかで、テルミンのヴォリューム回路の大改装を思いついたので、備忘録を書いておく。

現状は、全体の音量を決定するグローバルコントローラー vol_16 と、音源毎に過渡的な音量カーヴ=トランジションコントロールを持たせたローカルコントローラー temp_Volume_x が6系統の計7種類のデータをハンドリングしていて、前者はWaveTableの波形選択直後のデータ読み出しの段階で、後者は音源のミックスを行う段階で出力値を決定させている。

一方、トランジションコントローラーの各出力値は、グローバルコントローラーから出力される数値

vol_16 = (((uint16_t)pgm_read_word_near (volumeCurb[6] + vol_vd)));
if ((vol_16> 0)&&(vol_16<4096)) {vol_mod = (((vol_16 + 2047 ) % 2047));} // volume value as the controller if value in range


によって波形読み出し用に登録されたオフセットが掛けられたデータカーヴ群を呼び出して

vol_mod = constrain(vol_mod, 1, 2047);
temp_Volume_a = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod)));


生成されているが、この結果に対して何ら処理を行わず、波形を合成する段階で各音源バンクの出力に掛けあわせて

temp2_val_a = (temp_val_a * vol_16);

最終的に出力される音量を調整していた。

以上に示したように、現状のコードでは音量コントロール関連の計算工程が分散していて、余りスマートな処理とはいえない。 これを、予め各ローカル出力にグローバルコントローラーの数値を掛け合わせる形に改装することで、

temp_Volume_a = (((uint16_t)pgm_read_word_near (volumeCurb[0] + vol_mod)));
temp_Volume_a = (temp_Volume_a * vol_16);
temp_Volume_a = (temp_Volume_a >> 11);


よりスムーズに処理を行える可能性がある。

例えば、トランジションコントロールを行う為に煩雑な構成の波形合成を行うコード

case 17: temp2_val= ((temp2_val_a * (pot4a17 * volumeInc)) * (temp_Volume_a)) + ((temp2_val_b * (pot5a17 * volumeInc)) * (temp_Volume_b)) + ((temp2_val_c * (pot6a17 * volumeInc)) * (temp_Volume_c)) + ((temp2_val_d * (pot7a17 * volumeInc)) * (temp_Volume_d)) + ((temp2_val_e * (pot8a17 * volumeInc)) * (temp_Volume_e)) + ((temp2_val_f * (pot9a17 * volumeInc)) * (temp_Volume_f)); break;

上にある、WavwTableからの出力 temp2_val_a を、新たに製作したトランジションコントロール専用の出力

temp2_val_a2 = ((temp_val_a * temp_Volume_a) >> 9);

と置換することで、以下のように構成が簡略化された。

case 17: temp2_val= ((temp2_val_a2 * pot4a17) + (temp2_val_b2 * pot5a17) + (temp2_val_c2 * pot6a17 ) + (temp2_val_d2 * pot7a17) + (temp2_val_e2 * pot8a17) + (temp2_val_f2 * pot9a17)); break;

実験の結果、計算の処理が重くなる doubleな係数 volumeIncを排除出来たお蔭で、TransitionControl時に発生していた妙な歪みが解消している。
posted by Yasuski at 02:01| open.Theremin

2018年01月19日

chords

addr01.png
addr02.png
addr03.png
addr04.png
addr05.png
addr06.png
addr07.png
addr08.png
addr09.png
addr10.png
addr11.png
addr12.png
addr13.png
addr14.png
addr15.png
addr16.png
addr17.png
addr18.png
addr19.png
addr20.png
addr21.png
addr22.png
addr23.png
addr24.png
addr25.png
addr26.png
addr27.png
addr28.png
addr29.png
addr30.png
addr31.png
addr32.png
addr33.png
addr34.png
addr35.png
addr37.png
addr38.png
addr39.png
addr40.png
addr41.png
addr42.png
posted by Yasuski at 10:47| open.Theremin

2018年01月16日

Open.Theremin@VolumeControlModeの拡張を行う

ほぼ1年間/2モデルのハードウエアの運用でOpenThereminのプログラム可能な音源16アドレス分の使用頻度を吟味した結果、最後尾にアサインしていた音色固定モード8CHは殆ど使われることがなかった。

一方、直前にアサインしていた出力値を可変できるVolumeControlモードは使用頻度が高く、遊んでいるCHが勿体無い。 ということで、後半の4アドレスをVolumeControlモードに変更することにした。

やはり、動的制御の魅力は抗い難く、ノイズっぽい低品質な出力とトレードオフ出来る機能と判断している。

スケッチを改変してアップロードを行って確認したところ、処理アドレスの変更は問題なく行えた。

次に、沈黙している16bitDACのテストを行っが、オシロスコープでロジック出力の波形を観る限り破綻はなさそうだ。 これで、ハードウエア側に問題(電圧レベル等の)が発生している可能性が大きくなってきた。

試しにDACの出力を検証するためのスケッチを走らせて出力電圧を測ってみたが、何故か電圧が出ない。 この結果は後に回路図をチェックした結果、測定ポイントを勘違いしていたためと判明しているが、他にもコンデンサの実装を間違えたりとミスが散見されている。 機械的な失敗は測定以前の問題なので、一度修正と確認を行った後、再度試験を行うことにする。
posted by Yasuski at 03:42| open.Theremin

2018年01月15日

またもや機材車のエンジンにトラブルが発生する

夕方になって買い物に出かけるつもりがVWの6気筒エンジンにトラブルが発生、エンジン関連の警告灯が点灯してパワーが上がらない。エグゾーストパイプから異臭がするのは生ガスを吹き出している証拠。

出立を諦めてクルマに診断用のデバイスを接続して故障箇所を探るってみると、1気筒目がミスファイアを起こしている模様。フードを開けてイグニションコイルユニットを引き抜くと恒例のイグニッションコイル折損事故(3回目)な事が判明する。

とりあえず、工具を持っていそうなJAFを呼んで、折れた部分の引き抜きを依頼するも、サービスカーは狭い部分に届くプライヤーを持ちあわせておらず、当てが外れる。 結果、自力修理、もしくはディーラーまでクルマを牽引というアレな状況に。

折損するVWのイグニションコイルは明らかに欠陥品だが、何故か日本のディーラーはそれを認めず有償修理扱いという鬼畜な対応なので、出来れば自力で修理を行いたい。

こんなこともあろうかと1年半前に輸入していたスペアを活用する絶好の機会が到来したのだが、プラグホール奥に鎮座する折損部を引き抜かないことにはスペアパーツは役に立たない。

で、JAFのおっちゃんと協議した結果、歯医者が持っていそうな返しの付いた工具で対応できるのでは?との示唆を貰う。

ナルホドその手があったかと、ひとまずJAFにはお帰り頂いて、在庫している自転車用チタンスポークの折れ曲がった部分をダイヤモンドルーターで研磨、折損部のクリアランスにねじ込んで折れたパーツを引き抜くための工具を自作した。

チタンスポークは激硬いので強度的には問題なさそうだったが、押し込んだ工具を回転させるのが難しい。トルクを加えられるように、スポークのストレート側を折り曲げて持ち手に加工した後、折損部の一番奥に至るまでスポークを押し込み、これを回転させて詰まった折損部を引きぬくことが出来た。

心配だった代替パーツの互換性は問題なさそうな感触だったので、町内を一周してエンジンの動作を確認しておいた。

まだヤバそうな死亡が確定しているパーツがあと3本残っているので、保険のために改めて代替用のパーツを発注しておいた。製作した治具は使い易いように再加工して、故障判断デバイスのケースに入れておく。

今回は、合計で20K程の節約ができた計算だが、そもそもリコール扱いのパーツをなんで自腹で揃えにゃならんのかと微妙に納得いかないのがトホホ。
posted by Yasuski at 04:20| AudioElectronics

2018年01月10日

MEMSなスピーカーが発売されるらしい

これとMEMSマイクを組み合わせて、ホースから開放されたトーキングモジュレーターを造りたいのだが、とりあえずセンサーの構造を考えてみると、、、

usoundmoon630.jpg

細い棒の先に防滴構造に加工した振動体を取り付けたものを口盆内に挿入し、マイクはその同軸上に設置することになるのだが、、、センサーの支持構造に工夫が要りそうだ。

posted by Yasuski at 05:49| AudioElectronics

Open.Theremin@新型トップパネルを仮設する

到着した分割式のトップパネルをケースに取り付けてみた。

分割している分フレームの強度が落ちているので、実装時に無理をするとメイン基板が破壊される可能性を忘れないようにしよう。

次回は赤色と黄色を発注する予定。

IMG_7839.JPG

左右の接合部は全く問題なし。グランドのスポットはもっと増やしたほうが良いかもしれない。 固定周波数のオシレーターを裏側に仕込むのも一案か。

IMG_7838.JPG

今回は、四隅はOKだったものの、丁度「凹」のヘコミにあたる部分のカーヴが小さ過ぎ、修正を余儀なくされた。 この部分のRを大きくすればジャストフィットするのだが、現物合わせ故に後数回は失敗しそうな雰囲気ではある。

IMG_7842.JPG

ちなみに、以前製作した一枚板の黄色い基板よりも修正箇所が減ったので、修正作業の工程はそれなりに費やされるものの、難易度はより低くなっている。

IMG_7399.JPG
posted by Yasuski at 00:06| open.Theremin