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