2016年12月30日

open.Theremin@受動部品の構成をSMDに変更する

受動部品の専有面積をセーヴするため構成部品をSMDに変更し、SOIC-8/SIL変換基板上にLPFを構築するための部品を展開することにした。

IMG_6597.JPG

DAC出力とLPFの入力ラインに挿入される抵抗は、従来通り1/4Wのリードタイプを使用する。

構成部品の変更に伴い、電源ラインの取り回しを再検討することになる。

IMG_6598.JPG

posted by Yasuski at 13:45| open.Theremin

2016年12月28日

資材受領の記録

Open.Thereminの分周回路用に購入した74HC4060/10pcsが到着した。
posted by Yasuski at 00:00| Diary

2016年12月24日

ArduinoIDE1.6.12でDueにスケッチのアップロードが行えない件

Dueへのアップロードが行えない問題は、このメソッドで解決するらしい。

具体的には、platform.txt内の記述、

tools.bossac.upload.pattern="{path}/{cmd}" {upload.verbose} --port={serial.port.file} -U {upload.native_usb} -e -w {upload.verify} -b "{build.path}/{build.project_name}.bin" -R

を、、、

tools.bossac.upload.pattern="{path}/{cmd}" {upload.verbose} --port={serial.port.file} -U {upload.native_usb} -e -w -b "{build.path}/{build.project_name}.bin" -R

に書き換えて、対応できるという。


他にも、別のファイルを改修するこんな記事を発見している。

後ほど、ファイルを書き換えて実験してみよう。
posted by Yasuski at 13:22| Arduino

2016年12月23日

資材受領の記録

Open.Thereminのオシレーター用に購入した74VHC14/10pcsが到着した。
posted by Yasuski at 21:14| Diary

2016年12月18日

試作基板V2の製作

Teensy3.6への乗り換えを行うための試作基板を製作している。

ototSch03.png

今回は、Teensy3.6の動作電圧に合わせて全回路を3.3Vで運用する予定だが、発振周波数のドリフトが心配。
LEDをドライヴするインバーターは74HC640に統一した。

ototAroundDA.png

SOIC8パッケージのDACとOpAmpは事前にSIL変換基板に実装している。LPFの設定はFc15kHz/12dB/Octとした。

供給電圧は5Vに平滑したものを一旦Teensyに入力し、Teensyからは3.3Vを各回路に分配する。 実験のため、温度センサーICを予め実装する予定だが、これには5Vの電源を供給する必要がある。

ototWire07.png

配線にはテフロン線を使う。 SILの変換基板上にLPF関連の部品をまとめると構造がシンプルになるので、試行錯誤を行うつもり。
posted by Yasuski at 00:28| open.Theremin

2016年12月09日

open.theremin@ハードウエア波形エディターの可能性

波形編集に関していろいろ考えていたのだが、テルミンという楽器の性格上、演奏しながら波形を作るのは物凄く手間が掛かる作業で、完璧にEditを行うのは結構大変。

で、落ち着いて波形を編集する方法はないかと思って考え出したのは、波形編集専用機。 要は、ツマミをパラメーター分並べて、直感的な音造りが出来る専用のプラットフォームで、音源にはアンテナから分離されたスタンドアロンなものを積んでいて、ローカルで出音を確認しながら編集を行う。

IMG_6466e.jpg

実装するパラメーターは、テルミン側に準拠して、モード&アドレス指定のRGBロータリーエンコーダー、ピッチ設定✕4ch、波形設定✕6ch、レベル設定✕6ch、といった構成で、17個(以上)のロータリーエンコーダーを実装することになる。 RGB仕様は贅沢なので、LEDで誤魔化す可能性があるが、Volume/Waveformを二面化するのもアリで、その場合のパラメーター実装数は、RGB✕7+LED無し✕4の計11個となる。

左手のシミュレーション機能はテルミンのVolume青モードを使って、左手の位置で音色が変わるシチュエーションをつまみ一つで再現する。

編集の内容はLCDに表示され、常にパラメーターの状態を視認できる。

問題は、必要となるPin数で、3✕7+2✕4と30本弱。合理化すれば、 2x11 + 1x2 までは減らせるが、、、。

テルミン本体との接続方法は、USBホスト機能を実装して直接データをアップロードするのが理想だけれど、これは例文を見つけられなければ実現は難しいだろう。 

折衷案として、ROM焼き用の数値データを単純に吐き出す仕様を考えているが、データの書き込みに手作業が必要になってしまうのが、イマイチ。 とはいえ、既にEEPROMのアップローダーが完成していて、

WS000953.JPG

テキストベースでデータを吐き出しさえすれば、データを反映できる環境を構築できた。 ボタンを押すと、シリアルにデータを吐いてくれる仕様にしておけば、シリアルモニタに表示されたテキストをアップローダーにコピペするだけで、準備が完了する。

スマートなのはSDカードを使用する形態だが、この場合はデータ型の変換が問題になってくる。
posted by Yasuski at 18:59| open.Theremin

open.theremin@EEPROMのアップローダーについて

EEPROMからのデータ書き出し機能を応用して、データを「書き込む」ためのスケッチが参照する設定値を「コピペ出来るように」出力ファイルの記述に細工を行った。

WS000948.JPG

が、このままでは編集無しでコピペ出来るレベルではないので、楽するための「修正」を掛けているが、延々と続くコードの書き換え作業は積んでも積んでも終わらない賽の河原状態となった。

WS000950.JPG

で、30分を超える地味な作業を行ってようやくテンプレートが完成した。 

WS000951.JPG

起動後のSetUpRouting内でEEPROMに記録されたデータを吐き出しているが、このままアップローダーにプリセットをコピペすると、他のマシンのEEPROMにも同じデータがアップロードできるはずだ。 

WS000952.JPG

修正は、エディタで行って結果をアップローダーにコピペする。 テキストベースの直感性に欠ける方式だが、各パラメーターの状態を想像するしか無い今よりはラクチンに編集が行える。 

楽器的な観点からすると、スタンドアロンではない点に少々不満を感じるが、Arduinoベースだと思えば納得がいくような。 無用な混乱を避けるために、「敢えて敷居を高くしておく」という価値観もある。
posted by Yasuski at 15:49| open.Theremin

open.theremin@EEPROMからデータを取得する

ひとまず、EEPROMにストアしたデータの読み出し機構が稼動状態になった。 

データは以下のような形態で出力される。

WS000946.JPG

ラベルの末尾"a"が音源の出力レベル、"b"が選択した波形のアドレスを示す。 レベルは"1"が最大値、波形は1が基音、2は2倍音という風に選択したWavetabeleを表している。 

例示したデータは女性ヴォーカルのシミュレートを行った音源のプリセットだが、波形は単純に合成されるのではなく、音源個々のEnvelopeカーヴをアンテナ左のValueによって変化させている。 
左アンテナによってドライヴされるEnvelopeカーヴは30度ずつズラしてあるので、Pot4とPot7はほぼ裏の関係となっている。 

例示した音色を構成しているデータを分析すると、、、、

基音2に対して倍音1の構成から、3倍音と5倍音をミックスした構成に徐々に変化するように設定している。 高音が気になる場合は、pot8の5倍音を4倍音に変更すると良さそうだ。

一方、ピッチデータはこのような形で出力される。

WS000947.JPG

表示はスケッチをアップロードした時のワンタイムのみだが、機能をボタンに仕込めば、USB経由で随意にデータを取り出すことが出来る。

このように、視覚化にはデータを客観視出来る利点があるが、実装した機能はあくまでデータの内容を確認するためのものなので、EEPROM上のデータを直接編集することは出来ない。。



追記:
 以下に取得した全データを掲載する。
続きを読む
posted by Yasuski at 10:52| open.Theremin

2016年12月08日

open.theremin@擬似フォルマント・コントロールの実験

posted by Yasuski at 05:50| open.Theremin

2016年12月06日

open.theremin@ポインタの統合

同音程を出力する波形データのポインタを統合して、発音の遅れを調整した。 

WS000945.JPG

遅れは音の唸りとなって音程のズレに聞こえるが、昔のシンセでは否応なくチューニングが狂うアナログオシレーターを並列化していた位なので、精度に拘るのは贅沢。 「うなり」が気になる場合は、オシレーターの数を減らせば良い。

ポインタの統合を行った理由は、オシレーター間の発音タイミングのズレがあまりにも酷かったたからで、調整後は自然にバラけた感じになった。

一方、ピッチ調整側でどうやってもドンピシャにチューンできない問題は、14bit精度にチューニング・ステップを妥協しているためもある。こちらも、あまり拘るべきポイントではないが、ステップの隙間を感じるのは気持ちの良いものではない。
posted by Yasuski at 23:35| open.Theremin

2016年12月05日

open.theremin@左手のエンヴェロープコントロールによるピッチのスイッチングについて

左手によるプリセット型ピッチ制御モードでコントロールを行う音源の配置=音列の配置がどうにも上手くいかない。

フィルター効果を狙う場合、音源間の音量の変遷はスムーズでなければならない。 一方、音列となると話は別で、場合によっては更に急峻なカーヴを持った波形によるスイッチライクな乗り換えが必要となる情況が出現するのだが、現状のエンヴェロープ管理システムを改変せずにこれを折衷するには音源の距離を離すしか方法は無い。

で、プリセットの仕込みが問題となるのだが、まず6個のオシレーターを一巡させるには位相を30度ずつズラした制御波形が必要で、最大音量のポイント間で相互影響が少ない音源の距離は90度となる。

今回、BLK/WHT表示のピッチ間を常に90度ズレるように仕込みの設定を改変したが、実際のところはこの間隔であってもスムーズな運用は難しい。 



完全な形で運用を行うには、Expを掛ける等いろいろと細工を行う方法がありそうだが、何れにしても計算による遅延の影響は免れない。

ひとまずは、用法で逃げる方法を研究してみるが、最終的には制御機構を改変することになりそうだ。
posted by Yasuski at 10:42| open.Theremin

open.theremin@ヴォリュームデータをRAMに上げる

Wavetable関連の処理のスピードアップを目論み、データ型を改変したヴォリュームデータをRAM上に展開した。 

結果、体感的なレスポンスが向上したのと、誤動作っぽい動きが減ったように感じる。

現在RAMの使用率は50%となった。 

WS000943.JPG

データパック1件あたりの消費量は4kBなので、残り32kBでWavetableをあと8波は乗せられる計算だ。

低い方の波形を優先すれば、プレイヤビリティーの向上が望めそうな気もするが、Tableの扱いが難しくなるのでこの作業は現在ペンディング中。 

ちなみに3.6は3.2では64kだったRAMを4倍の256kBも積んでるので、Wavetableの大半を楽勝で乗せられる。

RAMの扱いに関してはAdafruiteのサイトに上がっていた記事を参考にした。

追記:


波形データの型の宣言からconstを外して無理矢理RAMに載っけようとしたが、先頭の1波形以外は全部撥ねられた。 多分 波形Arrayを読む時のconst型の宣言が関係しているんだろうけど、何故か先頭のデータはconstを外していても読んでくれる不思議。 RAMの使用量は56%に増えたので、1波形あたり6%と換算すべきか。
posted by Yasuski at 03:17| open.Theremin

2016年12月04日

open.theremin@雑感メモ

今日は楽器の素性を知るために、演奏を繰り返しているが、いろいろと癖が解ってきた。

まず、リミッターを掛けないデジタル楽器のレベル管理はシビアで、波形合成時に失敗をやらかすと、予期せぬところでバリバリ言い出す。 

歪の発生は、左手の設定とも関連していて、アンプリチュードを最大にすると、バリっとくるポイントが出てくる。 単純なレベル調整ミスの場合は奏法でなんとか誤魔化せるが、例のワウみたいなオシレーターの出力カーヴを個別に割り当ててオフセットを掛ける用法で演奏する場合には、カーヴの重なる部分でパリッと逝くことがあって、こちらは演奏しないと判らんところがあるので厄介。 レベル管理は通常モードと同様にVolumeアンテナの調整で行うが、こちらは安全圏に設定した場合に全体の音量が顕著に下がる傾向があって、妥協点を探すのが難しい。

あと、ピッチのスケールがオシレーター制御のタスクが増える毎に狭まる傾向があって、素のモードでは6オクターヴ超あったのが、低い方にどんどんズレて、しかもナローになっていく。 機能を欲張ると、処理に掛かる時間が増えて、レンジを確保する余裕がなくなっていくのだが、速いチップの選択でどこまで改善できるか興味が有るところ。

全体に歪みっぽい音質なのは12bitの限界と、回路のLPFをケッチていること、あとはリミッターを外してダイナミックレンジを稼ごうとして失敗した結果だと思うが、元々がArduinoベースのガジェットっぽい立ち位置のハードウエアを魔改造している手前、余り真剣にオーディオマニア的視点で音質を語るのはハズレだと思う。
posted by Yasuski at 18:44| open.Theremin

2016年12月03日

open.theremin@doubleの扱いについて

EEPROMに音色データを記憶させた特定のアドレスにアクセスすると、ヴォリュームコントロールが効かなくなり出力がラッチアップしてしまう現象が多発する。

調査の結果、トラブルが発生する特定の条件下では発音時に必要なdouble演算が3重に行われていた。

WS000935.JPG

影響は、上記の波形選択を行った後、3音以上の発音数を選択した場合に発生していた。

WS000941.JPG

WS000942.JPG

問題を単純化すると、やはり処理能力の限界ということになるが、PitchとVolumeの制御を積極的に行う情況で、特にメモリーに格納したオシレーター個別の音量データを制御に用いる時に最大量の計算が行われ、結果としてVolumeディテクターの更新が破綻するようだ。 

現状はPotの数値そのものを16bit=2Biteでメモリーし、再生時にdoubleの係数を掛けているが、

WS000936.JPG

データ格納時に計算の結果をdouble対応の32/64bit幅で記録すれば、処理の工程が一段階減って問題を解決できるかもしれない。 ただし、doubleを扱う場合は通常の書き込み命令は受け付けられず、EEPROMAnything.h を追加して独自の処理命令を書き加えなければならない。

WS000937.JPG

8biteで記録できるようにコードを改変した後は、例の如く読み出し時にハングアップが発生するが、以前から計画していたROMの一括クリアを行ってハングアップの発生を回避することが出来た。

WS000938.JPG

初期状態のROMは読み出し時にイロイロと悪さをするらしいので、新品のチップはまず初期化を行うべきだろう。 出来れば、立ち上げ時のスイッチのコンビネーションで消去が行える仕掛けを組み込んだ方が良いかもしれない。

格納データのdouble化直後は何故かデータを読み出せない状態だったが、これは単純なマヌケによる失敗で、一時的にデータを格納するレジスタを追加して解決。

WS000939.JPG

プリセット間の音量差が発生していた問題は、これもマヌケ由来ということで、オシレーターの出力レベルを個別にコントロールする2048段階の音量マップデータに4096段階用の係数を掛けていたために音量が1/2になっていた。

WS000940.JPG

Volumeアンテナの問題は残ったが、doubleの計算回数を軽減したお陰でVolumeのロックアップ現象は相当軽減された。 前述したようにプリセット間の音量差もなくなったことから、バギーな動作をしないようにVolumeをチューンすればなんとかなる事を確認した。

追記:

どうもストアされないデータが出てきたな、、、と思ってTeensy3.2の仕様を確かめ直したところ、EEPROMのデータ領域が2Kということを失念していた。

96bite毎にデータをストアする大盤振る舞いの結果生じた破綻だが、「ロータリーエンコーダー上の連番」でデータを管理したい思惑があるので、アドレスの変更は難しい。

とはいうものの、オーバーフローはマズいので、未使用の領域をできるだけ減らすことにする。 現状でdoubleを設定しているパラメーターは16種類、他のパラメーターは2bite設定のママだが、音色設定パラメーターは、これら2つの仕様が混在している手前、メモリーアドレスの推移は単純に96biteステップとしている。 ここで、パラメーターあたり36biteを16アドレス分浪費する仕様は正気の沙汰ではないが、ここでは敢えて利便性を採った。

そこで、ストア動作を分離したピッチ制御の側を確認したところ、こちらは連番ではあるが、音色設定パートの後ろにアドレスを振っているので、あまりややこしいことをせずに操作が可能だ。 オーバーフローが生じたのはこの部分なので、ここでアドレス配分を圧縮していく。

連番アドレスの最後尾は#1632なので、これにオフセットを掛けていく。 ちなみに、書き込み側は下記のように少々ややこしいことになっているが、

EEPROM.put( (((((pot22a -25)*96) - ((pot22a -42)*96)) + ((pot22a -42)*8)) + 0) , pot3a );


要するに、pot22aから出力される連番のアドレスにオフセットを自動配分して記録する仕掛けだ。 この計算は一見すると合理化出来そうに思えるが、それにはオフセットがゼロな初期値のみを条件分岐で分離する必要がある。

読み出し側は単純にオフセットを掛けたアドレスを指定するだけ。

EEPROM.get(((96 * 18)- 88) , pot11a_2);

”18”はロータリーエンコーダーから出力されるアドレスにオフセットを掛けた数値で、これにデータをストアする位置を対応させている。
posted by Yasuski at 18:28| open.Theremin

open.theremin@試作基板第2号の製作

DACの積み替えを考えているところで、いっそのこと試作ユニットを新調しようと思いたち、在庫しているジャンクパーツから資材を漁っている。

今回は、「ややこしい部品を使わない」というコンセプトで素直にインバーターを探してみたが、丁度使い勝手が良さそうなHC640なるチップを発見、これをロータリーエンコーダー周りのバッファリングとデータの反転に使用する。

image.jpg

あとは、OpenTheremin側のDACを駆動するためのオープンドレイン出力のバッファーを準備するだけ、、、と、思っていたが、Teensy3.6は5Vトレランスがご法度なことを思い出した。

端子が独立しているので、当然ながら受け側もオープンドレイン出力のデバイスで代用できるが、送りに4ch、受けに3chは必要。 出来ればOctalのチップが存在すればよいのだが、型番を失念したので検索を掛けてみる。

結果、端子が足らないものの、汎用品の74HC05が使えそうだが、何れにしてもインバーターに印加する電源電圧が問題になってくる。 5V駆動側は動かせないから、入力端子が3.3VルールでH判定してくれるかが問題となるが、HCT05の規格だとこれがギリギリでOKだろうか。 HCの場合はHに至る電圧が足らずにアウト。

その後、レベルシフター系のICはオープンコレクターのLS06をジャンクボックスから発掘したものの、インバーターは使い難い、、、。 入力は抵抗分割のレベルシフトで誤魔化すしかない雰囲気になってきた。

パーツの捜索を続けても埒が明かず、回路に適応できるオープンドレインのレベル変換用チップを見つけられないままフテ寝していたところ、逆転の発想でOpen.Theremin本体を3.3Vで運用することを思いついた。 そもそも、5V電源はUnoの仕様に合わせたものなので、これに拘る必然はない。

理屈では、全てのチップが3Vからの動作を保証されているが、汎用C-MOSチップ(HCではない)の動作速度が激遅くなりそうなのが問題か。

ID-292に実装しているV2ボードは、VCO周りをHC14に変換しているので、発振周波数への影響は4069よりは小さいと予想する。 MCP4921は2,7Vから動くので問題なし。 残るは分周ICだが、これがHCではない4060なので、動作の遅れが問題になりそうだ。

OPAMPは在庫しているOPA1662が3V対応なので、これを使う。  4069はそのままHC14にリプレイスできるので、これはラクチンに解決する。

image.jpg

現状で製作は可能になりそうだが、保険と実験のため4060とHC14のCMOSリプレイス品を発注に掛けた。
posted by Yasuski at 02:43| open.Theremin

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

OTOT関連の製作プロジェクトは、試作からそろそろ楽器としての量産が可能かどうかを判断する時期に来ているが、部品の汎用性を考えて出来るだけユニークなパーツを排除することにした。 その最たるものといえばGigaTrimだが、

IMG_6423.JPG

これは取り外さなくてもランドを転用できるのでそのままの設計とする。

汎用部品に変更が可能なパーツで特に目立ったのは、PhotoMosRelayと3回路封入のLogicICで、この2つで0.5K近く吹っ飛ぶのは健全ではない。 よって、ここをより汎用性の高いHC14にリプレイスした。

WS000934.JPG

残りの部品はFPGAを除き、何処にでもある平凡なものなので、調達は容易と思われる。

次に、旧いOpenThereminの基板をリプレイスするためのピギーバック基板について、電圧変換ICや高価なDA、オーディオクロック供給用のパーツ、後付けが可能な拡張端子群等をすべて取っ払って、シンプルな形に作り変えることにした。 

otot3.2x.png

こちらもPhotoMosRelayは撤廃するが、RGBロータリーエンコーダーはそのまま残す。 

回路の簡易化を踏まえて、対応ボードはTeensy3.2のみとするが、オーディオクロックが30kHz台なので、機能を欲張りさえしなければ問題は無いと思われれる。 販売を行うとすればこちらがメインで、既存のユーザーをターゲットとすることになる。 オーディオは16bitDACをステレオで搭載する予定なので、性能的には十分なアップグレードだと思うが、果たして需要はあるのか?ユーザー層の嗜好はイマイチ見えてこない。
posted by Yasuski at 02:25| open.Theremin

2016年12月02日

資材発注/受領の記録

16bitAudioDAC/PT8211@10個を受領済み。

Open.Thremin基板の3V駆動対応のリプレイス用にカウンタ/74HC4060とシュミット・トリガー・インバーター/74VHC14を共に10個、ebayにて発注した。 

HC14は既にオシレーターとしての動作を確認している。

posted by Yasuski at 00:00| Diary

2016年12月01日

open.theremin@dacHandlerの設計にミスを発見する

あろうことか、dacHandlerのリセット端子の設定に間違いを発見。 分周カウンタとSIPOフリップフロップのリセット端子の動作論理が逆になっていた。 つまり、端子の状態がどうであろうが、どちらか片方の回路が常にクリアされているという恐ろしい状況に陥る。

これは、SIPOに分周カウンタを付け足す時に両方のリセット回路の動作極性を考慮しなかった単純ミスだが、シミュレーターでは発覚しないタイプの失敗だった。

WS000930.JPG

リカバー不能なバグ以前の問題なので、ADATと同じレベルLOでリセットが行われるように直ちに回路を修正した。画像は、SIPOのリセット端子を修正した後のVHDL。

危惧した通り、インプリメンテーションの結果、端子が大幅に変更されて、半日掛かりの作業は水泡に帰した。 

WS000928.JPG

先ほど再配線を完了したが、

0t0t3.91.png

dacHandler7.1.png

これ以上この手の失敗が発覚しないことを祈るばかり。

dh7.bmp
続きを読む
posted by Yasuski at 08:42| open.Theremin