2016年11月30日

open.theremin@dacHandlerを7chに統一する

ADATエンコーダーに複数のシリ→パラ変換レジスタを接続して使うことには無理がありそうなので、実装するチップの数を減らすことも考慮し、FPGA1チップに回路を詰め込めるだけ詰め込んだ。 流石に8回路を一気に仕込むにはレジスタの数が足りずにアウト、実装限界は7回路だった。

WS000927.JPG

汎用DACへの対応を考えて、ついでにデータ送り信号のSCKを端子に取り出しておいた。

WS000925.JPG

データ入力は、データ、シリアルクロック、共に一本化した。 データを選別するLatchは7回路分を配置している。 そして、ピン配置が劇的に変わった。

WS000926.JPG

結局のところ最終仕様は、オシレーターを個別に6chアウト+トータルミックスが1ch(同じ音声を2ch並列)となりそうだが、本体の16bitDACとの連携を考えた場合、使い勝手はこちらの方が良いかもしれない。

追記:

FPGAが絡むラインのレベル管理の問題は解決できず、ついにレベル・シフターを追加することになった。 設定の改変を行うと色々とややこしくなるので、出力のオープンドレイン仕様はそのまんま。 

データラインのうち、マイコン端子が絡むWCKのライン1本は5Vのロジック系を混在できないので、こちらは3.3V系で接続して、ADATエンコーダに向かうラインでレベルシフトを行っている。 レベルシフターは4回路あるので、残りはデータライン2本とSCKのラインを充てた。 残りの直結する2本はプルアップで対処している。 
SCKは汎用オーディオDACを接続する際に使用する予定だが、あくまでリザーブ端子扱い。

パワーオンリセットで、カウンタ周りは全てクリアされる。 信号はマイコンから送られる。 ADATの方は独自にスタートアップ回路を充てているが、こちらも一括してマイコン管理にするのもアリ。
posted by Yasuski at 10:52| FPGA

open.theremin@ステレオDAC搭載の下準備

16bitDACを実装する前に、裏ルーティン用の読み出し機構を作ってみた。

通常、波形の読み出しは、WCKにあたるオーディオクロックの立ち上がりを切欠に発生するインターラプトによって行われるが、それ以外の時間、すなはちクロックの谷間ではアンテナの状態やロータリーエンコーダーの変化を繰り返しセンシングしている。

このLoop内にADをぶち込んだ場合、それが即遅延に繋がって音質の低下を誘発することは実験で確かめた。 ADと同じような処理の段取りを踏むDAも、程度の差こそあれ同様に遅延が発生する。

なので、極力無用な繰り返しは避けたい。 そこで、Loopのなかで行われるアップロードを制限するためにフラグを設けることにした。 DACへのデータ・アップロードはフラグが初期値=ゼロの時のみが行われるが、フラグがリセットされるまでアップロードは繰り返されない。 

if(readFlag01 == 0) {
writeValue02(DAC16_R);
readFlag01 ++;
};


次にオーディオクロックが立ち上がってインターラプトが発生した瞬間、フラグはリセットされ、インターラプトからの復帰後最初のループ時に限定して再びアップロードが行われる。

画像が示すRchのデータがそれで、敢えて制限を設けていないLchのデータはループ毎にアップロードが繰り返されていることが判る。

WS000917.JPG

実際に行われるインターラプトは30kHz台の猛スピードで繰り返されるので、どこまで繰り返しが行われているのかは判らないが、ひとまずOTOTのプログラムにこの機構を実装してみたところ、音質への影響は発生しなかった。

一方のdacHandlerだが、data01/03の奇数コンビネーションがLch、偶数コンビネーションがRchを扱っている。マイコンからのデータ送信はインターラプト信号の表裏で行われるが、DACを扱う時のようなスピードの制限を意識せずにマイコン側が出せる最大のスピードでデータを転送できる。

WS000916.JPG

問題はWCKの扱いで、VHDL設計時に行った仕様変更の影響で複数個のチップをADATエンコーダーに接続するケースを失念していた。 現状、出力を直結してもOpenDrainによるWiredORとなるので、電気的に即アウトな情況にはならないが、タイミングのズレによる副次的な問題の発生が懸念される。 現在、同期を取る方法を模索しているところだが、システムを立ち上げる途中のSetUpRoutine内で、同時にリセットを掛ける位しか方法を思い付けない。 

データのハンドリングを襷掛け状態で運用しているデバイスにリセットを掛けるのはちと難しい。 
posted by Yasuski at 03:49| open.Theremin

2016年11月29日

open.theremin@基板デザインの更新

旧Alesis系のDACチップやADATエンコーダーは旧い設計のICで、5V環境で動作する仕様だ。 これを電源電圧3.3VのFPGAからドライブするのだが、データシートによると端子の"H"判定にはVDDの75%の電圧が必要だ。 

WS000914.JPG

3.3Vのシステムから要求値の電圧を出力するのは不可能なので、データを送信する側は出力端子に5Vのプルアップを行って出力電圧を嵩上げしなければならない。 ただし、デバイスによっては過電圧で回路を損傷することがあるので、事前の確認は必須だ。

幸いLatticeのFPGAは出力にオープンドレインの設定が可能で、

WS000915.JPG

出力ピンを再設定してインプリメントを行ったところ、合成に成功はしたものの全体のピン配置が微妙に変わってしまった、、、。

WS000912.JPG

仕方なく、基盤の設計をやり直すことになってしまったが、ピンの並びが整理されて更に最適化が行われたようにみえる。

実際、配線の引き直しをスムーズに行う事ができた。 見てくれもスッキリしている。

dacHandler01.png

1個目のFPGAはタクトスイッチの裏側に配置した。クロック系のpinがすんなりとまとまったので、オープンドレイン化と同時に出力ゲートのスピードアップを目指してFPGAの再インプリメンテーションを行ったのは結果的に正解だった模様。

dacHanler02.png

2個目のFPGAは基板表側に配置している。 データラインが綺麗にまとまっているのが判る。

otot3.83.png

まだDACの試験も終わっていない段階でこれを言うのも何だが、基板に配置しているTOSLINKは借付けで、このままの形で実装できるかどうかは微妙だ。 最終的には、アングルを使って基板表面とフロントパネルの間に部品を立てることになると思うが、その場合のクリアランスが未確認なので、事前に現物を使って実効値を確認しなければならない。  天板と基板のクリアランスは、ロータリーエンコーダーにシムを挿入して調整する予定だが、TOSLINKの厚みが調整域を超えた場合は別の実装場所を探さなければならない。

現段階で決定している仕様は、ROHM製16bitDACを標準装備としてアナログ16bit/Stereoで音声を出力する。 オプションで、dacHandler2個とADATエンコーダーが追加され、TOSLINKによるデジタル8chの光出力が可能になる。 ADATの受けは、試作中のデバイスを用いる予定。

IMG_6437.JPG

デバイスは2ch毎に出力の拡張が可能で、光ファイバーを使って音声回線をチェインしていく。

IMG_6439.JPG
posted by Yasuski at 19:36| open.Theremin

open.theremin@2'sComplimentaryフォーマットへの対応。

DACがようやく届いたが、ここにきて2'sコンプリメンタリのDAC送信フォーマットにデータを変換する際の”ゼロ”の扱いの複雑さに気付いてしまった。

以前音声の出力波形を観測した時に指摘したが、このシステムは負側の電圧を扱っていないので、音声データの見かけ上のゼロポイントは常に変動している。 

vlcsnap-2016-10-21-05h29m15s020.png

従って、2'sコンプリメンタリフォーマットでは必須といえるゼロ値の確定が行えず、そのままの状態でデータをハンドリングすることは出来ない。

2'sコンプリメンタリのフォーマットでは、ゼロの値は2進法そのままの形で表現され、MSBが極性を表す。 MSBでは"1"が負の値を表現するが、負側ではゼロを境目に全ての符号が反転する。 例えば4bitでは、1111が-1、1000は−7となる。 正の値をこのフォーマットに変換する場合、まずゼロポイントを決めなければならないが、これをフルスケールの1/2とした場合、MSBの符号を反転するだけで変換を行える。 先ほどの4bitスケールで例を示すと、1000をゼロとした場合、1001はMSBを反転して0001となって+1、0111は1111となって-1に変換される。 

基準点となるゼロポイントの変化は、ヴォリュームアンテナからのValueに比例しているので、ゼロポイントのオフセットをヴォリュームデータから直接代入することで、ゼロポイントを常に更新することが出来る筈だ。例えば、12bit×12bitの出力を想定した場合、音量ゼロ時はそのままゼロ、音量データが1bit増す毎に、2048段階ずつゼロポイントが移動する。 ヴォリュームのValueが0x000001の時、音声データの最大値は4096で、ゼロポイントはその中間値の2048、2bit時は8192の2048×2で4096というように、増幅値の変動に伴って2048ずつ移動していく。 

実際のコードはこんな感じになった。 32bit幅の音声データ出力のオフセットを算出したあと、実効値24bitのMSBを、XORを使って反転させている。

temp5_val = ((temp2_val - (2048 * vol_16)) ^ (0x800000));
temp6_val = ((temp2_val - (2048 * vol_16)) ^ (0x800000));


DAC16_L = ((temp5_val >> 8)) & 0xffff;
DAC16_R = ((temp6_val >> 8)) & 0xffff;


実際に動くかどうか自信はないが、まずはシミュレーションを行って有効性を確かめよう。

追記;

temp5_val = (((temp2_val - (2048 * vol_mod)) & 0x1ffffff) ^ (0x1000000));
temp6_val = (((temp2_val - (2048 * vol_mod)) & 0x1ffffff) ^ (0x1000000));


が正解だった。 

24bitの帯域制限の必要があったのと、bitControlの値を間違えていた。

リザルトはこんな感じで、負の値がきっちりと出ている。

WS000909.JPG





posted by Yasuski at 04:34| open.Theremin

資材受領の記録

ROHM製16bitDAC、BU9480Fが到着した。
posted by Yasuski at 03:59| Diary

2016年11月27日

open.theremin@波形データの極性について

「いまさらな話」ではあるが、Open.Thereminのスケッチに同梱されているオリジナルの波形データを確認したところ、正負の値で構成されていることが判った。 

WS000905.JPG

所謂マイナス側のデータが存在するということで、オリジナルのプログラムではDACの出力に合わせて事前にデータの極性を判定し、これを正の値に置き換えている。

WS000907.JPG

実は、自分が新たに用意した波形データは、ラボ支援系サイトのサイン波自動生成プログラムを利用したもので、こちらの値はプラス側のみだった。

WS000906.JPG

要は、プログラム上で符号の変換なしにレアデータをそのまま使用していたことになるが、準備されたマイナス側をプラスに変換するシーケンスは常に無視されていたことになる。

で、試しに正負の符号を判定させる方式を試してみたところ、正負判定の手前で行っていたヴォリュームコントローラーが破綻した。

WS000908.JPG

これでは本末転倒なので、独自仕様として負側のデータを含まないままのプログラムを継続することにしたが、これはオーディオ系DACの仕様に合わない可能性がある。 混乱を予防するために、今一度DAC側のデータフォーマットを確認しておこう。

映像は、トーキングモジュレーターっぽいサウンドを作って演奏してみた記録。



VolumeAntennaによるオシレーター個別のエンヴェロープ・コントロールの威力は強烈で、いろいろと用法のアイデアが湧いてくるのだが、左手にはかなり微妙な操作が求められる。 

なので、こちらに注意を向けると右手がお留守になってオンチ状態に陥る危険性を一連の記録映像が証明していることに気付いてしまった。



先の符号調整にともなって設置されていた無駄なオフセット値の撤去した。 これの所為でダイナミックレンジが半分になっていたのだが、音量が稼げない割に突然妙な歪が発生する原因が特定できた。
posted by Yasuski at 06:46| open.Theremin

2016年11月24日

open.theremin@Voicingを左手でコントロールする

和音演奏時に左手の位置でヴォイシングに変化を与えている例。



ピッチと音色のコンビネーションの選定がなかなか難しいが、左手の位置を変化させて主旋律とバックグラウンドのバランシングを行っている。

posted by Yasuski at 20:46| open.Theremin

2016年11月23日

dacHandlerのピン配置を修正する

書き込み前にVHDLの回路合成の詳細を確認したところ、やはり無理なピン配置を行っていたようで、信号の精度が保証されていないことが判明した。

このピン配列は、プリント基板上の取り回しを優先したものだったが、Teensy側でCH毎に独立させていたデジタルオーディオ信号の扱いを、データライン共通でラッチクロックのみを独立させる仕様に変更した結果、再度基盤上の配線パターンを合理化する必要が生じている。

この時点で、独自のピン配置に拘る必然は無くなったので、今一度論理合成をやり直すことにした。その結果はこうなって、、、

PAD Specification File
***************************

PART TYPE: LCMXO2-256HC
Performance Grade: 4
PACKAGE: QFN32
Package Status: Advanced Version 1.38

Pinout by Pin Number:
+----------+-----------------------+------------+--------------+------+---------------+-----------+-----------+
| Pin/Bank | Pin Info | Preference | Buffer Type | Site | Dual Function | PG Enable | BC Enable |
+----------+-----------------------+------------+--------------+------+---------------+-----------+-----------+
| 1/0 | Reserved: sysCONFIG | | | PT6C | TDO | | |
| 4/3 | MCK | | LVCMOS25_IN | PL5C | PCLKT3_0 | | |
| 5/3 | rst | | LVCMOS25_IN | PL5D | PCLKC3_0 | | |
| 8/2 | dataOut1 | | LVCMOS25_OUT | PB2A | CSSPIN | | |
| 9/2 | dataIn4 | | LVCMOS25_IN | PB2C | MCLK/CCLK | | |
| 10/2 | ckW3 | | LVCMOS25_IN | PB2D | SO/SPISO | | |
| 11/2 | LATCH3 | | LVCMOS25_IN | PB4A | PCLKT2_0 | | |
| 12/2 | ckW4 | | LVCMOS25_IN | PB4B | PCLKC2_0 | | |
| 13/2 | WCK | | LVCMOS25_OUT | PB4C | PCLKT2_1 | | |
| 14/2 | LATCH1 | | LVCMOS25_IN | PB4D | PCLKC2_1 | | |
| 16/2 | dataIn2 | | LVCMOS25_IN | PB9A | SN | | |
| 17/2 | dataIn1 | | LVCMOS25_IN | PB9B | SI/SISPI | | |
| 20/1 | unused, PULL:DOWN | | | PR5B | PCLKC1_0 | | |
| 21/1 | dataOut2 | | LVCMOS25_OUT | PR5A | PCLKT1_0 | | |
| 23/0 | LATCH2 | | LVCMOS25_IN | PT9D | DONE | | |
| 25/0 | ckW1 | | LVCMOS25_IN | PT9B | PROGRAMN | | |
| 26/0 | dataIn3 | | LVCMOS25_IN | PT9A | JTAGENB | | |
| 27/0 | ckW2 | | LVCMOS25_IN | PT8D | SDA/PCLKC0_0 | | |
| 28/0 | LATCH4 | | LVCMOS25_IN | PT8C | SCL/PCLKT0_0 | | |
| 29/0 | Reserved: sysCONFIG | | | PT7B | TMS | | |
| 30/0 | Reserved: sysCONFIG | | | PT7A | TCK | | |
| 32/0 | Reserved: sysCONFIG | | | PT6D | TDI | | |
+----------+-----------------------+------------+--------------+------+---------------+-----------+-----------+

sysCONFIG Pins:
+----------+--------------------+--------------------+----------+-------------+-------------------+
| Pad Name | sysCONFIG Pin Name | sysCONFIG Settings | Pin/Bank | Buffer Type | Config Pull Mode |
+----------+--------------------+--------------------+----------+-------------+-------------------+
| PT7B | TMS | JTAG_PORT=ENABLE | 29/0 | | PULLUP |
| PT7A | TCK/TEST_CLK | JTAG_PORT=ENABLE | 30/0 | | NO pull up/down |
| PT6D | TDI/MD7 | JTAG_PORT=ENABLE | 32/0 | | PULLUP |
| PT6C | TDO | JTAG_PORT=ENABLE | 1/0 | | PULLUP |
+----------+--------------------+--------------------+----------+-------------+-------------------+


IDEが自動的に配置したピン配列はデータを扱う上で合理的なものだったので、プリント配線の方を新しい仕様に沿う形で基盤を再設計することになる。

dacHandler04.png

論理合成の結果、納得のいく合理的なものが出力されてきたので、下手にこれをいじらずに基盤の設計をピン配置に合わせることにした。 チップ側のキャパシティーは4chまで扱えるので、光出力を視野に入れた構成を考えることにするが、基本構成を2chとして本体側はアナログ2chの出力を固持し、残りの信号処理は欲張らずにピギーバックタイプの拡張方法を考えた方が良いだろう。

fpgaRouting.png
posted by Yasuski at 19:36| FPGA

open.theremin@EnvelopeControllerの実装

オシレーターのレベルを動的に制御する機構を新たに組み込んだ。 

これは、Volume側のエンヴェロープを使って6つの音源間のレベル推移を橋渡ししていくもので、レベル設定用として位相をズラしたサイン波のウエーブテーブルをゼロから2048段階までのValueを使って参照する構造。

当初は、ワウっぽい使い方を想定していたものの、、、単音の効きは今ひとつ、、、。 

原因は、制御に用いたサイン波のカーヴ、もしくは駆動する側の波形そのものにあると考え、今度は音源側に位相を30度ずつズラした基本波6種を準備してみたものの、ノイズが発生してしまってこれも実用には至らなかった。 この失敗の原因はレベル管理の問題と思われるが、アナログで適当にやれそうなことがデジタルではとたんに敷居が高くなる良い見本だったと思う。

通常の倍音関係の波形の選択も難しく、最適なコンビネーションは未だに発見できていない。 やはり、この機能で使う専用の波形を準備しなければならないのか、、、。

一方、和音の構成音を動的に制御する機能としては今後の発展が望めそうで、プリセット次第で相当面白い効果が得られるようだ。



とはいうものの、音の構成を直感的に理解するのは無理で、非常に難解な操作性の楽器となりつつある。

こちらはエンヴェロープのカーヴを変えたヴァージョン。





posted by Yasuski at 01:48| open.Theremin

2016年11月22日

open.theremin@擬似フェイズコントロールについての考察

ショボい仕様だが、擬似フェイズコントロールのような効果を思いついた。

OTOTにはオシレーターとなるWavetableが「6個」搭載されているが、これの波形を別々に登録できることを利用して、整数の倍音関係に並べた波形のヴォリューム・ピークを動的に制御する。

具体的には、位相を60度ずつズラした9bit✕256stepのサイン波からなる制御カーヴを、オシレーターとなる各Wavetableのゲイン調整に用いる。サイン波の半波で構成された音量制御カーヴは60度ずつ(数値的には43step✕4 + 42step✕2) ピークがズレるので、6倍音のピークを256step掛けてスムーズに移行出来るはず、、、。

ゲイン調整用のカーヴはWavetableとして位相のズレた6ch分を登録し、そのデータアレイをなんらかの形で読み出すのだが、いまのところロータリーエンコーダーの空きはなさそうなので、これを左手のVolumeアンテナから出力される音量データのLSBにアサインする。 つまり、無音からの256stepがワウのように倍音を制御するというアイデアで、「なんとなく使えるかもしれない感触」はあるのだが、問題は処理に掛かる時間だ。

ひとまず、43stepずつオフセットを掛けた256step✕512bitのWavetableを作成したので、近日中にこれを実装してみよう。

追記:

早速実装してみたが確認は未完なるも、今日のところはこの辺で打ち止め、、、。

posted by Yasuski at 00:39| open.Theremin

2016年11月21日

open.theremin@音質の向上について

機能の実装がある程度実現されると、曲がりなりにもモノが「楽器」故に今度は「音質」が気になってくるのだが、音質を左右するファクターとなるオシレーターのピッチを検出するカウンターの分周値とオシレーターの周波数の摺り合わせがとても難しい。

これは、異なる周波数のカウントを同一のカウンターで行っているために発生している問題と想像しているのだが、2つあるVCOの片方の周波数に分周値を最適化すると、他方の周波数へのフィッティングが上手くいかなくなる。 まさに、こちらを立てればアチラが立たずの状態だが、原因が物理面の不整合に起因しているので、ソフト側で「何とか調整する」ことはほぼ不可能と思われる。

もちろん、VCO個別の周波数レンジを回路に最適化すればよいのだが、これが、外乱等のドリフトが発生するファクターが多く、周波数を合わせこむのがなかなか難しい。  そういった意味で、V3から採用されたオートチューン方式は正解と思われるのだが、これをドライヴするためのプログラムの製作は、Unoのハードウエアに依存する部分が多く、実現までのハードルは高い。

その他の問題としては、検知後のデータに乗るノイズの影響があって、これはどうやら楽器の応答スピードやダイナミックレンジとのトレードオフとなっているファクターえ、一方の価値観に最適化した場合、演奏レンジが狭くなったり、ノイズが増えたりと、なかなか上手く折衷したチューニングを決めるのが難しい。

不思議なのは、偶数倍の高調波が何故か「濁る」現象で、原因が全く判らないのだが、音質面の問題はこの波形を選択した時に集中している。 これは、Unoの時代から散見されていた問題なので、このシステムが持つ根本的な問題かもしれないが、一度出力波形を記録して、分析を行うことにする。

今後導入を画策しているTeensy3.6では、動作速度もさることながら、利用可能なFTMが2つあることが強みで、これによる検知機構の分離化による御利益が望まれるのだが、、、。o

posted by Yasuski at 19:01| open.Theremin

open.theremin@インターフェイス更新版





posted by Yasuski at 04:10| open.Theremin

open.theremin@通信機能の実装計画は現時点で全滅

midi受けを仕込んでは見たものの、再起動後にStartUpから先に進まず、例の筐体をバラしてRebootスイッチを押さないと再起不能となる現象が発生。

試しに、極初期の音が出ていたレベルのスケッチでmidi駆動を試すも、コレもアウト。

ということで、根本的にmidiを受けられそうにないことが発覚してしまった。

midiがダメな場合はI2C通信をする手もあると思って仕込んでみたものの、こちらは立ち上がりはすれど、最初の動作で凍る。

どうもマスターが通信先のスレーヴを探している雰囲気なのだが、I2Cはスレーブが常時接続されている状態を想定した仕組みのようなので、スレーヴが居ないと捜索続行≒凍る、、、という症状と思われる。 Timeoutで諦めた場合は楽器の体をなすようになるが、今度は設定していた音が何故か狂った=処理能力の限界を超えてしまう。

通信無しの状態にファームを戻すには、やはり筐体をバラしてリセット端子を押さなければならなかったが、一連の作業の結果通信系の実装がかなり難しいことが判った。

切手大の超小型Arduinoが1基余るので、それを内挿してmidi受け専用に使うという贅沢な選択肢もある。 困った時は処理を物理的に分散するのは常套手段といえるが、敗北っぽい印象は否めない。

単純にエンコーダーの線を延長する場合は、スイッチ無しのエンコーダーを1基増設できるが、一番簡易でこなれたmidiプロトコルをなんとか実装出来ないものか、引き続き調査を続行する。
posted by Yasuski at 03:54| open.Theremin

2016年11月20日

open.theremin@操作系の構造を大幅に刷新する

運用を重ねるにつれて、クリック動作を上下のロータリーエンコーダーで統一して、シングル・クリック → 順送り/ダブル・クリック → 逆順送り に設定すると、操作性が格段に向上することが判った。

IMG_6578.JPG

ピッチ調整を行うBlk/Whtはパラメーターが別系統なので、Blk→Wht→Blk→Whtとした。

Wavetable関連のパラメーターは、Volume→WaveformSelectorの順でLEDの発色を統一している。 

ダブルクリックでひとつ前のパラメーターに戻れるので、調整の必要が生じた場合にパラメーターを一巡する必要がなくなった。

IMG_6586.JPG

アドリブでいろいろと仕様が変わっていった結果、操作系の洗練が要求されるようになったのだが、元来自分がこの手のシンプルな操作系を好まない(とにかく並べられるだけツマミを配置するのが好き)ために、シンプルな操作系の遣い勝手に関するノウハウが欠如していたのだなあ、、、と後知恵で思っている。

IMG_6588.JPG
posted by Yasuski at 19:31| open.Theremin

2016年11月19日

open.theremin@コネクターの追加・FPGAチップの実装他

3pinのLemoコネクターをリザーブ端子としてパネルに実装した。

IMG_6568.JPG

予想される問題はアンテナ端子への影響で、通信による電波障害が発生する可能性がある。

IMG_6570.JPG

残るは音声出力デバイスの実装だが、目当てのDACが届いておらず、ハードウエア面に関してはこれからペンディング状態となる。

一方、放置していたFPGAの変換基板への実装だが、物凄く手間のかかる作業だった。 

IMG_6571.JPG

コツは判ったものの、最低でも20分は掛かりそうな作業なので、なにか根本的な用法を考えないとダメ。

今回は、フラックスを接着剤代わりに使用したが、結局は指先で固定しながらのハンダ付けと、凄まじく原始的な手法で作業を貫徹した。 やはり、専用の接着剤でボンディングしてから作業を行うべきだったか。

IMG_6572.JPG

作業を行う過程で、期せずしてこの手の微細部品の配線デザインについてノウハウを得ることになった。 それは、できるだけ細くて分厚い銅箔面が円滑な作業を保証することで、逆に忌避すべきなのはグランドパターンのように「面積が広い接合面」で、これは絶望的にハンダが乗り難い。 チップの対角線上に配置されていたこの手のランドがそのケースで、最終的にはパターン面のレジストをカーヴィングナイフで削ってハンダを乗せなければ、端子の接合を行えなかった。

midiの実装はレイテンシーや処理能力の限界から迷っている案件ではあるが、とりあえず「midi受けの仕組み」を作る過程で、ハードウエア面の仕様を考えていた。

部品点数が増えるのは甚だ好ましくないのと、リモート機器の電源確保の問題等を考慮すると、3pinではプラグの端子数が足りず最低でも4pinは要る。

が、ここにきてサテライトから送信するデータはハードウエア的にmidiプロトコルに準拠する必然がないことに気付く。 要は、マイコンからバッファーを通した信号を直接送付してしまえば良い。 短い配線の直結なので、ヘタをするとバッファーも要らない。 

当初は単純なロータリーエンコーダの増設話だったが、この仕組だと別筐体にシーケンサー等を作り放題なので、これは実現すれば面白い企画だと思う。 テルミンが、いつの間にか単純ではあるものの、6オシレーターを装備したAdditiveSynthesizerのVCOに変身するわけだ。 その場合、VCFは無理としてもVCAの実装は必須と思われるが、Volume系の仕様が既に6ch分独立化されていることが有利に働いてくる。

ということで、電源ライン+シリアル通信ライン送信1本のみという独自仕様でまとめることになりそう。
posted by Yasuski at 21:03| open.Theremin

open.theremin@操作系のリファインを行う

立ち上げ時の「パラメーター間を行ったり来たり」がかなり手間に思えたので、操作系の流れを改変した。

まず、上段のクリックの流れを、波形選択 → 音量設定 → 周波数設定 に変更、次に下段のピッチ設定VRをパラメーター選択の先頭に持ってきた。黒、白で、ピッチを設定し、3番目の緑からが6ヴォイスの操作エリアという構成で、以前よりもクリックの回数を減らすことに成功している。

操作がややこしかった記録ルーティンだが、消去を廃止して上書きモードとした。これは、折角作った設定が、アドレスの順送りルールで無慈悲に上書きされることを反省した改変で、書き込み(変え)たい場所にノブを回してその場所のデータに上書きを行う。

コードエディットモードのアドレス設定は、1番目がピッチ固定のリファレンス仕様で、ガイドによって追加するノートの相対位置が解り易くなっている。記録エリアは2番目から15番目までがリザーブされていて、16番目は全ピッチが同一設定で、こちらには音色設定向けのリファレンスとした。

今のところリファレンスのピッチは固定だが、任意のタイミングで主旋律のピッチを取り込む、またはmidi/nnによる設定機能の追加を考えている。

追記:

運用の過程で判明したのは、単純にメモリストアのスイッチを間違えるだけでEEPROMのデータが吹っ飛ぶということで、プログラムの書き換え&ROM消去まで再起不能となった。

とりあえずは、アドレス指定の帯域制限を設けて失敗のリカヴァーを行うが、用法を間違えてシステムがクラッシュする可能性が残っていると思うべきだろう。
posted by Yasuski at 01:36| open.Theremin

open.theremin@フリーズ案件の解析

プログラムを書き換えた時にEEPROM周りの設定ミスを行うと、必ずフリーズ案件に見舞われることが解ってきた。

対処法は、正常に動いていた時のプログラムに戻して、EEPROMの記録分野を全て上書きすることで、この作業でフリーズの発生が回避されるようになる。 

いっそのこと、EEPROMクリーナーを書いてしまおうかとも思っているが、運用歴が浅い現状では通常の使い方で発生する場合が無いとも言えない。 念の為に、スイッチの長押しなどを使って起動時にEEPROMの全消去が行えるような仕掛けを作ったほうが良いかもしれない。
posted by Yasuski at 01:36| open.Theremin

2016年11月18日

open.theremin@ベーシックな機能の実装を完了する

コード編集機能の解析を行っている過程で、エンコーダーのオモテ/ウラに配置したVolumePot設定が重複して、裏のデータが裏では読めずに、表とミックスされるという奇っ怪な現象の発生を確認した。 

機械的なトラブルの可能性も考えられたが、なかなか原因を突き止められずに半日が過ぎた。

記録関連の仕組みはほぼ完成している。 ただし、相変わらずフリーズ案件が散発しており、そろそろ処理能力の限界が来てしまったようだ、、、。

その後判明したトラブルの原因は、mode内で発生したデータのコンフリクトだった。 ダブルクリックでオモテウラを乗り換える時に、単純な発想でLEDが無点灯状態になるmode1をお互いに選んで切り替えていたのが原因だった模様。 

解決法は、NOPにあたる何も仕事をしないbreakのみの番外地を作ってそこに誘導すればよいだけだった。 

WS000898.JPG

これで、やっとコード編集機能の実装を行えたことになる。



プログラムのミスを探すうちに思いついたのが「ドローンをバックにソロを演奏するスタイル」で、こちらは、仕込みのピッチが主旋律に追従しない伴奏の形に近いものとなるが、エンヴェロープのみが左手の動きに追従するので、背景音が完全に独立したリズムを刻むことは出来ない。

これは、和音の構成を考える時に、テルミンのような不安定なピッチがリファレンスにならないことに気付いて、ドローン状態の背景音を設定したことから派生した奏法だが、

WS000899.JPG

メモリー再生ルーティンの設定をピッチを受け付けない固定音を元に構成すれば、バックトラックを製作することが出来る。 

切替のタイミングは今のところ手動だが、自動化もやる気になれば可能。 midi受けでルートピッチやアドレスを設定するのが一番便利な手法と思われる。

この考え方を進めていけば、midiを使って容易に外部スイッチを拡張できるので、インターフェイスの問題は一気に解決する。 例えば、ドローンバックの基音は基本60nn固定で、midiを外部接続するとこれを可変できるように設定することも可能。 当然、コードのシーケンス化も簡単に行える。

ルートノートを選択する問題は、基音を演奏しているピッチから任意のタイミングでサンプリングを行えば、混乱が少なそうだ。 ライヴではガチガチに仕込むよりも、こちらの方が臨機応変に対応できる筈だ。 筐体上にスイッチを展開するスペースが存在しないのが大問題だが、この辺の機能はmidiに投げるという考え方もある。 例の反射衛星砲発射スイッチも、midi化すれば接続は簡単だ。 外部電源が必要にはなるが、Lemoのコネクターも3ピンでシステムを構築できる。

ということで、修正が効くいまのうちに、リモートコントロールを視野に入れた操作系のリファインを行うべきだろう。
posted by Yasuski at 14:41| open.Theremin

2016年11月16日

open.theremin@制御機構のリファイン

実際の演奏を体験することで、楽器としてのインターフェイスの在り方を考えていく。



ノブに関しては、機能を集約すべきということで、演奏系を上側に、編集系を下側にまとめることにした。

また、「クリックのみ」で操作レイヤーの変更を行う方式は一方通行で非常に使い辛い局面が多かったので、上側のノブに関してはダブルクリックで操作方向が逆転するようにスイッチの設定を変更した。

演奏系の操作レイヤーは、上段側が Pitch、Volume、WaveForm、2VoiceSelect、3VoiceSelect、4VoiceSelect、5VoiceSelect、VoiceEditとなっている。 裏面の設定は無い。 下段の設定は、VoicePitch01a/b、VoiceLevel/WaveSelect1〜6、VoicePitch02a/b の二層構造となっていて、切り替えはダブルクリックで行う。

IMG_6566.JPG

上下のロータリーエンコーダーは双方とも、長押し(ホールド)でデータのストアと消去を実行する。上側はコード、下側は音色の記録に設定している。 ストアは既定のポジションで、消去は対象となるポジションで行われる。 記録時には、番地を表すモールス信号状のビープ音が発せられる。

WaveFormsはプリセット16種類とEditが16種類にアドレスを割振っていて、プリセットのうち1chはEdit専用のモニターとなっている。 操作上の混乱を避けるため、3・4・5声のプリセットは8種類とした。2声と記録が可能なEditedVoiceは16種類の合計40パターンのヴァリエーションを用意している。



コードの平行移動は面白いが、ポピュラー系の楽曲で使う局面は意外と少ない。 調性を変更するために、小型のリモートスイッチを準備したくなった。
posted by Yasuski at 22:30| open.Theremin

open.theremin@和音編集機能の実装は難しい

和音編集機能の実装がなかなか進まない。

機能を実装すると、何故かポリフォニック編集機能が死ぬ。 編集どころか、オシレーターが反応しなくなる。 どこかにバグが有るのかもしれないが、自分で対処できるレベルではない感じがする。

例えば、関連する項目は何もいじっていないのに、機能を実装した途端に楽器が立ち上がる時のオシレーターの(見かけ上の)周波数が変わる。 これは、処理のタスク量が余裕の無い方に変化していること示していて、もうそろそろ処理機能の限界が近づいていることのサインと思われる。

実際に楽器として運用しだして判るのは、これらの仕込み系の機能は「ライブでリアルタイムに操作するのはまず無理」ということで、実際のところは「ライヴ前にPCを立ち上げてスケッチを編集するよりはマシ」といったレベルだろう。

ただし、楽器としては「スタンドアロンでPCに依存しないこと」が重要なポイントなので、立ち上げ時に編集機能の選択を行う等、機能を活かす方向で方策を練ることにする。

追記:

EEPROMにデータを残す部分は、音色とコードのどちらの場合も成功しているが、コードを設定する時に必要な音程変化のモニターが拒否される不思議な現象が発生している。 プログラムの内容は問題無さそうなので、このあたりが処理の限界なのかもしれないが、とりあえずは先に実装した機能を停止して、コードの編集機能に特化させたプログラムを組むことにしよう。

追記2:

シロートなのでswitch/caseの挙動がいまいち判っていないのだが、処理を並列化出来る場合とそうでない場合があって、ややこしい。 例えば、LEDの点灯等はcase内で;で区切っても上手く動かないので、別個にswitch/caseを並列に記述している。

追記3:

その後、エンコーダーを襷掛けにして運用すればなんとかなる事が判った。 ヒントは、2音ポリ時に設定していたマニュアルピッチ設定のロータリーエンコーダーにあった。 波形選択を行っている下側のロータリーエンコーダーには該当するものを含めた4ch分のポートが余っていたので、これらを使ってピッチの設定を行うことが出来る。 和音の構成数は基音+4音なので、機能としてはこれで十分だろう。 あとは、LED表示の見てくれの問題だが、たまたま無点灯と白色の部分の表裏をピッチの選択に充てることが出来た。 問題は分解能で、現状ではデータの密度が荒い低音域で少々オンチっぽくなるところか。

追記4:

波形選択を行う際に発生していたフリーズの件に関して判ったことは、タスクが増える毎に発生の原因が変化することで、今回はROMの消去コマンドを行うと、その消去したポイントに差し掛かった途端にフリーズが発生していた。

これを補う方法は、何故か「全てのデータを埋めてしまう」というよく解らないメソッドで、データを書き込んだ後は、Wavetableの波形選択モードを含む全モードでフリーズの発生はなくなった。

この状況から、EEPROMの書き込みメソッドの中にバグが潜んでいる可能性が疑われるが、動作がおかしなピッチ関連の消去コマンドについてもついでに確認を行ったほうが良いだろう。

メモリー機能は便利なようで不便な使い勝手になってしまっているが、超スピードのモールス信号のようなスタイルで書き込み時に相対位置が判るようなサウンドを発生させる方法を考えている。

あと、編集モードの相関関係が複雑過ぎて、作った人間が混乱するレベルで操作性が酷い。 少なくとも、音程関係がイーヴンな初期状態のテンプレートからスタートするような「明確なヴィジョン」を得やすい編集メソッドを作る必要がある。
posted by Yasuski at 21:36| open.Theremin