2018年07月20日

Open.Theremin@左手に拠るSequencerの制御を考える

音量をオフっている期間が一定時間を過ぎるとSequencerのstepカウンターがリセットされる機能を思い付き、これを追加した。

スイッチの代わりに、音量がゼロの状態をトリガーにする仕掛けだが、スタートスイッチとして一瞬は働いたものの、長押し(音量ゼロの)を判定するタイマーのリセットが、カウント一巡で再トリガーが掛かる事案を解消できず、構想は失敗に終わった。

やはり、単純なスイッチを増設するのが正道だと思うが、もう少し構造を検討してみようと思う。

で、こちらも左手関連の技術で、テンポを変える機能を考えた。

これは、ある閾値を超えた時に左手のValueをStapRateに換算し、テンポを送らせていく機能だが、左手のセンシングのレンジが異様に狭いことが発覚。これによりVolumeAntennaをセンシングしたデータの処理に関する根本的な問題が発覚してしまい、本来の機能を実装する以前のレベルで修正を行うことになった。

と、紆余曲折があったものの、なんとか実装を完了することが出来た。

WS001382.JPG

実際の運用方法は簡単で、左手をアンテナからある程度の距離に離すと、テンポが徐々に緩くなるリタルダンドの機能が実現する。 自動演奏のテンポを意図的に揺らすことが可能になったのは割と大きな進歩かもしれない。
posted by Yasuski at 17:35| AudioElectronics

Open.Theremin@Sequencerのデータ入力にCS#V規格を新設する

CSVならぬ、C#SVなる珍妙な規格を思いつく。

これは、2biteの処理がややこし過ぎて自分の実力では導入が難しく、だったらカンマの代わりに#で音階を区切ることで、半音高い表現をする目論見。

要は、”n” とか ” p " などの音楽系としては使い慣れない文字を可能な限り排除したいだけ。

実際の使い方は、休符を入れて、

@,c,c#d,d#e,f,f#g,g#a,a#b,c

といった記述になる。 

'、'の代わりに '#'を検知すると、sharpのフラグを立てて、条件分岐を行う仕掛けで、とりあえずはまともに動作している。

WS001381.JPG

オクターヴ上は大文字のCに、その上は、nnっぽく数字の0から9と o,p,q (A#からCまでに該当させる)を使うことにする。

結局はこの規格もなんかややこしそうだが、概念的には「普通」に近いので、慣れればなんとかなるかもしれない。
posted by Yasuski at 08:46| AudioElectronics

2018年07月18日

Open.Theremin@SequencerにCSVで記述されたノートを読出す

Arpeggiator/SequencerのCSV読み出し機構の構築が難航している。

ArpeggiatorやSequencerの場合は数列を直接呼び出して記録するWaveformsとは異なり、入力されたキャラクタから条件分岐で対応するピッチ関数を呼び出し、その数値をアレイに記録する方式なので、それだけ処理がややこしくなる。 

入力されるテキストデータはキャラクタをカンマで区切ったものを使うが、カンマが入力された時点でカウンタを一つ前に戻して、そこに記述されたカンマの一つ前のキャラクタを呼び出したのち、キャラクタを条件分岐で選別して、関連付けた数値を呼び出している。

WS001376.JPG

短いフレーズは問題無さそうだったのが、

WS001377.JPG

アレイにデータを延々と書き連ねて前のデータを間違って読んでしまうパターンにハマってしまったようだ。

昼過ぎになって、朝から悩まされていたBUGをフィックスした。

不具合の原因はいろいろとあったが、まずデータアレイの取り込みが上手く行えていなかった原因は、データバッファーを駆動するカウンターのリセットを忘れるという凡ミスだった。

37262219_1944948182202297_1382784211508789248_n.jpg

違うファイルを呼び出しているのに同じデータが繰り返し読み出される現象から、原因はすぐに察することが出来たが、試行錯誤を行う過程で件の要素のコピペを失敗したパターンと思われる。

次に改行が行われたCSVの読み出しが正常に行われない症状が見つかったが、ファイルから抽出したデータアレイのカウントは正常値を示している上、テキストデータを「改行なし」に修正した後も動作の不具合は何故か解消されない。

37310924_1944948052202310_5238640914523488256_n.jpg

根本的な原因はこちらも凡ミスっぽいとの判断でコードを精査したところ、Sequencerの音源をアサインしているアドレスに関連付けしたステップ数の設定を取り違えているのが原因だった。

以上の手当を行ったところ、無事ArpeggiatorとSequencerにCSV読み出し機能を実装できたが、試作機を設計した時点ではmicroSDを導入する可能性を全く考慮していなかったために、毎度毎度楽器をバラすはめに陥っている。 これを解消するために、USBからmicroSDに直アサインでデータを書き込めないか探っているのだが、いまのところ簡単な方法は見つかっていない。

現時点でRAMの使用量は9割を超えてしまったので、お気楽に機能を追加することはそろそろ出来なくなってきた。

WS001378.JPG

試しに2048stepのSequencerを8系統実装することに失敗している。波形メモリーに関しても16波登録している現状がギリギリといったところか。 プログラムのエリアはまだ3割弱しか使っていないので、起動時に取り込む波形を選択できるような機能の実装が望まれる。
posted by Yasuski at 14:41| open.Theremin

2018年07月17日

Open.Theremin@CSVファイルのインポートを可能にする

CSV形式で記述された波形データを外部から取り込めるように、SDカードからのデータ読み出しルーティンに細工を行った。



テストベンチでの動作は確認できているが、楽器上での運用試験は未了。
posted by Yasuski at 19:40| AudioElectronics

Open.Theremin@SDカードの実装

今朝も、好調なギニアからの音楽を聴きながらコーディングを行っていた。

アルペジエーターはシーケンサーの拡張版なので、32step程度に容量を抑えたアレイを作ってこれを展開すればよい。 画像はSequencerのパートだが、Arpeggiatorの構造はこれと殆ど一緒。

WS001369.JPG

ひとまず、チューニング(実はダミー)用に準備したもの以外はEEPROMを全廃して、SDカードにデータをストアする構造にコード全体を改変した。

SDカードは数列や文字列をパソコンで書き込めば良いので、音声の編集が楽になるのと、別の楽器にデータを移植できるようになるのが大きなメリットだろう。

そして、ついにRAMの使用量が8割を超えた。

昨日ハマったのは、SDカードを実装後に楽器を起動してしばらくすると楽器が発狂して失神&再起動を繰り返すという悪夢のような現象で、原因はSDカードに記録したパラメーターファイルの「空欄」だった。

これはEEPROMでもハマった現象で、なんらかのデータが書き加えられていないメモリーを参照した結果ループに陥るパターンと思われるが、これはメモリーにデータを書き込むことでこれを解消できる筈。

楽器はあまりバラしたくないが、一度実装したSDカードを取り外して、とりあえず”0”を書き込んだ結果、システムを復旧させることが出来た。

次に陥っているのは、SequencerやArpeggiatorが全くの無反応なトラブルで、どうもデータのハンドリングが上手く行っていない風である。

一方、波形/音量バランスやピッチの記録はまともに行われていて、こちらは一安心。

Screen Shot 2018-07-16 at 15.09.09.png

で、昨日は暑さに負けてシーケンス系のトラブルは放置していたのだが、一夜明けて思い付いたのは、ローカル変数の扱いを間違えていたのではないか?という疑問であった。

試しにトレーサーを追加してプログラムを走らせてみたところ、やはりMainLoopに入った途端にデータが消えるようだ。

WS001371.JPGWS001374.JPG

WS001373.JPG

SDカードをスロットに挿入するついでに、MCUにドイツから購入した放熱チップを取り付けた。

IMG_8225.JPG

別のMCUで実際にダミー運用を行ったところ、結構熱を持つことが判った故の保護策だが、出来ればもう少し表面積を稼いだ製品が欲しい。 

細かい工作を行ったものを以前見掛けた記憶があるのだが、最近は何処を探しても見つけられない。

ちなみに、ドイツからの送料は秋月で同一品を買うよりも安かった。
posted by Yasuski at 06:57| open.Theremin

2018年07月15日

SDカードにデータをハンドリングする

早朝ギニアからのアフリカンポップを聴きながら始めたコーディングは途中の小休止(居眠り)を挟んで、ようやくSDカードとのデータのやり取りのメソッドが確立しつつある。

SDカードのデータ型はcharなので、MCUとデータのやり取りを行う際に「翻訳」が必要になるが、一度に1biteずつしかデータを読み出せないところが大変に不便な仕様である。

WS001367.JPG

で、これを解消するためにはcharのArrayを組んで、そこに文字列を読み込ませたものを数値に変換するのだが、

WS001368.JPG

このメソッドを探すのに5時間ほど掛かってしまった。

日本語のサイトは殆どアテにはならず、最終的にTeensyのコミュニティーの記事に頼ることになったが、SDカードを使用する場合はその殆どがデータロガーシステムや映像系等だったことから、求める情報にたどり着くまでに時間がかかってしまった。

もちろん、英語の語彙の問題もあるわけだが、何故か日本語で検索しても埒が明かないという、結構ツライ体験をしたのだった。 やはり、嫌でも英語の理解は重要ということか。

画像は、立ち上げからSDカードのマウントを行った後、パラメーター群の初期値を読み込んで、Arpeggiatorのループが開始される模様。 

WS001363.JPG

後半に記録されているArpeggiatorのステップの変移は、読み込んだSequenceのステップ数がそのまま反映されている。

WS001364.JPG

昨日はこの「立ち上げ」に至らず往生したのだが、これは単にハードウエア単位の設定を間違えていたという凡ミスだった。

WS001366.JPG

作業が遠回りになった原因は、SDへのアクセスがままならない時期に予め実験でダブルクオートで変数を囲う形で変換のシミュレーションを行っていたことで、これを文字列を扱えるように改変する過程で思考が硬直してしまい、無駄な時間を過ごすことになった。

その後、シーケンサーの辻褄が合わないところを修正した。 

WS001369.JPG

何故かstep数が過大にカウントされていたが、3個多いという法則性があったので、問題なし。 

WS001365.JPG

これで、適当にフレーズを書き込んでも、勝手にステップを合わせてくれるようになった。

このまま上手く行けば、EEPROMを使わずに外部記録装置に設定を保存できるようになるわけだが、波形の記録から、ゆくゆくはバックトラック音源の再生など、さらなる機能拡張の可能性を確保できたのは大変有意義なことだと思う。

これから、各パラメーターの項目を地味に書き連ねていく作業に入るつもりだが、この気温の所為でそろそろ脳が沸騰してきた。
posted by Yasuski at 17:02| AudioElectronics

2018年07月14日

Open.Theremin@ピッチテーブルの扱いについて。

 @xx none
Char/1biteを#nnに対応させるテーブルを作った。
 cc 24nn 
 ics 25nn
左がSDカードに記述するノート、中央がスケッチ
 dd 26nn
上に抽象化された記号、右が実際の音程。
 jds 27nn
抽象化されている記号は実際には数値化されている。
 ee 28nn
例えば、c は0.25、cs は pitch1 * 0.25 と
 ff 29nn
なる。 pitch1 = 1.0600; で、これはcの半音
 kfs 30nn上の音程を意味している。
 gg 31nn 
 lgs 32nn 記述のメソッドは、スペースやカンマを用いずに
 aa 33nn 連続して行う。xxは休符。連続した音列は持続音
 mas 34nn となる。
 bb 35nn 
 CC 36nn 最終的には、数曲のシーケンスを格納して呼び出せる
 ICs 37nn ような仕掛けを実装する予定だ。
 DD 38nn 
 JDs 39nn 
 EE 40nn 
 F    F 41nn 
 KFs 42nn 
 GG 43nn 
 LGs 44nn 
 AA 45nn 
 MAs 46nn 
 BB 47nn 
 nC2 48nn 
 oCs2 49nn 
 pD2 50nn 
 qDs2 51nn 
 rE2 52nn 
 sF2 53nn 
 tFs2 54nn 
 uG2 55nn 
 vGs2 56nn 
 wAA2 57nn 
 xAs2 58nn 
 yB2 59nn 
 zC3 60nn 
posted by Yasuski at 13:19| AudioElectronics

SDカードにデータをトランスファーする方法(その3)

SDはキャラベースのファイル名でデータを管理するので、データをEEPROMに記録する場合に対応するアドレスをロータリーエンコーダーを回して順送りで呼び出していたようなことは出来そうにない。

混乱を避けるためファイルには関連するパラメーター群の数値を一気に記述せずに、対応するパラメーター毎にファイルを作る方法を考えている。 例えば、オシレーターのチューニングの場合、Memoryアドレスに対応する4つのパラメーターを別々に記録することになる。

つまり、記録を行う毎にファイル名を記述した条件分岐を設定する必要があるということで、これは結構な手間になる。

SDメモリー側には、予め対応するパラメーター分のファイル群を準備しなければならない。

パラメーターのアップデートに関しては、EEPROMで行っていた時よりも簡略化が出来るかもしれないが、何れにしても実験段階で記録装置の構造を詰めておかないと大混乱に至ってしまうだろう。

記述の煩雑さは、この例を見れば一目瞭然。

WS001360.JPG

検証用のシリアル通信が各所に挿入されているとはいえ、フォントサイズを4つ縮小しても、画面からはみ出してしまう。

WS001359.JPG
posted by Yasuski at 06:35| AudioElectronics

SDカードにデータをトランスファーする方法(その2)

単純に数値を変換するのであればあまり問題は無さそうだが、これをコード名などの抽象化されたものを扱う場合にどう処理すればよいのかが、イマイチ判然としない。 チューニング用のテーブルを作って、対応する数列をチョイスするような条件分岐を作り、それをシーケンス用のテーブルに登録することになるのだろうが、これは相当ややこしい。

作業の取っ掛かりとして、まずはチューニング表を作ることにしたが、5オクターヴもあれば十分だろうか。C4=60nnと同一の仕様にしたら概念が統一されて混乱が少なくなるだろう。 で、事前にあれこれ調べてみたが、Charを扱う場合は2biteになったとたんに処理がややこしくなるので、ASCIIキャラ1個につきnnを対応させるような独自表記で誤魔化したほうが良さそうだ。 データを1biteに抑えれば処理が簡単なので、無理くりではあるが独自規格の対応表を作ることにした。 一般的にはアプリ作って自動化するのが正解なのだろうが、いちいちIDEを開いて数列を撃ちこむよりは遥かに楽なので、アプリの製作には格別拘らなくても良さそうだ。

で、試しにラフな条件分岐を作って実験を行った。

WS001355.JPG

何故か理由は判らないが、Arrayの末尾に2つ空データを返していたので、その差分を引いて修正を行った結果がこれ。

WS001354.JPG

謎の空データが2つ追加されていた問題は、コピペ元が小数点のキャラクター分をアレイに追加していたのを失念していたこと、データを落としこむためにforで廻す際に、文字列の長さから1を引くのを忘れていたこと(1から16ではなく0から15になる)が原因と判明した。

WS001358.JPG

処理の違いを確かめるためにキャラクターを個別にダブルクオートで区切った場合と、

WS001356.JPG

羅列した文字列をダブルクオートでラップしたものを比較してみたが、同じ値が帰ってくるようだ。 ASCIIコードに準じてスペースやカンマは文字列として認識される。

WS001357.JPG

次のステップは、アドレスを読みだすシーケンサーを加えて、データをドライヴ出来るかどうか実験してみよう。 forを回している「n」が、そのままアルペジエーターやシーケンサーのstep数の設定に使える筈だ。
posted by Yasuski at 02:41| AudioElectronics

2018年07月13日

SDカードにデータをトランスファーする方法

microSDHC16GB class10 UHS-1の価格が1000円を切っていたので、これを評価用に購入した。

Teensy3.5/3.6にはmicroSDのソケットが標準装備されているので、これを使った実験を行いたい。 本当は1G程度でも十分すぎる位なのだが、最近は容量が小さくて速いものはまず商品化されていない。 SDカードの使用用途を考えると当然なのではあるのだが、、、。

SDカードのデータ型はキャラクターなので、数値を記録する場合はデータ型の変換が必要になってくる。

いろいろと調べてみたところ、まずSDカードにデータを送信する前準備の手段としてこのような記事を見つけた。

データを送る場合は、

dtostrf(write_var, 16, 14, outstr);

のように、データをWrapせねばならんようだ。

次に受けの方だが、Arduinoにはstring.toFloat()という便利なものがあるものの、これは下桁が丸められちゃうマヌケな仕様なので、別の方策を探すことになった。

で、見つけたのがこの方法で、

char inChar[inData.length() + 1]; //determine size of the array
inData.toCharArray(inChar, sizeof(inChar)); //put readStringinto an array
read_var = atof(inChar); //convert the array into a float

といった手段を取ることで、文字列のデータアレイから浮動小数点の結果を引き出している。

目的達成のための手段がはっきりしてきたので、ここからスケッチを書いていったのだが、 シリアル表示の関数 printIn は小数点以下2桁で丸めが行われてしまうために、浮動小数点を扱う動作の確認ができない。

その後、小数点以下がまともに表示されるprintfという関数を見つけたが、これの実装がどうやっても上手く出来ず、暫くの間悩まされることになった。 

折衷案として読みだしたデータを1000000000000000倍に拡大する手段を思い付いて、問題は解決した。

WS001352.JPG

が、、、若干の誤差が出るのが少々気持ち悪い。 果たして、これは「仕様」なのであろうか???

WS001351.JPG

SDカードはEEPROMのようなアドレス指定ではなく、ファイル名の指定でパラメーターを保持することになるのだろうか? 波形データ等大きめなファイルも格納できるので、ちゃんと仕組みを作ると相当便利になると思う一方で、データがぶっ飛ぶと全てが終わる。 その辺のリスクの重さは実際に運用してみないと判らないだろう。

データアレイは、sizeof( )を使うと自動でキャラクターの数を測って、文字列の長さが異なってもちゃんとデータを読み込んでくれる。これをシーケンサのステップ数の自動計測に応用できれば、パターンの作成がとても楽になると思う。

SDカードでデータの保持が行えるのであれば、ネット上に波形編集アプリ等の管理系サービスを展開するのが今風なのかもしれない、、、。
posted by Yasuski at 13:58| AudioElectronics

Open.Theremin@Arpeggiator/DigitalSequencer系列モードの記録

まずは、モノフォニック系から。



単純に1Voice分の発音をシーケンサーに振っている。 フレーズはCodeに直接記述するが、利便性に問題がある。 MicroSDのデータを読み込む等、外部データとのリンクを行えるようにシーケンサーとしての機能を研究する必要がある。 フレーズはよくあるブルース進行ベースなので、汎用性はある方だろう。 どちらかというとトレーニングモードの側面が重要なので、この機能自体は今後も保持する予定。

こちらは、実験で仮実装した2VoiceモードのDigitalSequencer。



ベースと伴奏でVoiceを2ch分専有しているため、主旋律が3Voiceに限定されて音が薄くなる弊害あり。 こちらも、外部とのデータリンクが行えない現状では実用性に乏しいだろう。

何れのモードも、事前にオシレーターの構成と波形の選択を厳密に行う必要がある。 Transition設定によって出音が激変するので、オシレーター相互の位置関係を吟味することが重要。 単音源故に音が単調になってしまうので、専用の楽器っぽい波形を準備したほうが良い。



こちらは、プリセット12種とChordEditモードのアドレス#1に記録した音列からフレーズを選択する7step系のシーケンサーのデモ。 実用性は十分なので、今後はプリセット分のフレーズを吟味していく予定。
posted by Yasuski at 02:03| open.Theremin

2018年07月11日

Open.Theremin@バグフィックス等の整備を行う

そろそろバグ潰しのタームに入っているが、運用上問題が発覚しているポイントから地道に潰していく。

まず、メモリのアサインが怪し気だったChordEditモードの不具合を解消。 これは、ArpeggiatorMode分だけ拡張したアドレスの処理を失敗していたのが原因だった。

次にTunerのピッチを確認したところほぼ完全な"E"だったので、これを慣習的に判り易い"A"に変更した。設定上偶々500という値が、偶然"E"と合致していたようだ。 

image.jpg

Screen Shot 2018-07-10 at 23.59.57.png

iPadのチューナーアプリで測定したところ、ほぼ完璧な440Hzを確認。

image.jpg

ついでに、Sequencerのフレーズを編集し易いように、変数を追加しておいた。

Screen Shot 2018-07-10 at 23.58.52.png

ChordEditMode上でチューニングの設定がいきなり不能になる現象は、ロータリーエンコーダーのデータ型がintなのが原因と判明したので、該当する箇所のデータ型をuintに変更。 同時に、ヴォリューム系など負の値を扱わない箇所のデータ型にも修正を行っておいた。

処理が重くなってきた感があるので、アルペジエーター周りのダイエットが必要になるかもしれないが、表面的な不具合は一通り解消できた模様。

課題としては、プリセット波形のチューンアップが望まれるので、これは今週中にこなすべき案件としたい。

ハードウエア面では、新しく届いた基板を仮組してみた。

IMG_8153.JPG

赤&黄のトップパネル基板は、精度が上がっているため緑基板よりも嵌め込みが容易になっていた。

IMG_8156.JPG

メイン基板との取り付けにはVRTの高さ分のギャップを解消するために、ロータリーエンコーダーにワッシャー3枚を挿入している。

IMG_8157.JPG

赤/黄基板の合せ目の精度が心配だったが、こちらも問題はない模様。

IMG_8183.JPG

IMG_8181.JPG

黄色い方の基板にはアンテナ側のオシレーターを実装できる仕様だが、温度変化による周波数変動の問題が心配される。
posted by Yasuski at 06:35| open.Theremin

2018年07月09日

Open.Theremin@DigitalSequencerの実装

ふと思い付いたのだが、メモリーしたコードをアルペジエーターに反映させたらシンプルで面白そうだ。

メモリーは16パターン登録できるので、伴奏の幅がさらに大きく展開する。 ROMの容量にはまだ相当余裕があるので、アルペジエーターのコードパターンを8から32に拡張しても問題は無い。

で、、、早速組み込んでみた。 



暫定でArpeggiatorと同じ7stepとしているが、これはMemoryの用法次第で最大64step(4note x16ch )まで拡張できる。 ただし、これをやるとChordMemory機能が使い物にならなくなるので、実質的には最後の4アドレス分を使った16stepとするのが正解だろう。 シーケンスの循環は、別のパラメーターで決定できるので、これは呼び出すシーケンスのチャンネルごとに個別に設定する。 現実的には7/8/9/10/14/16stepを準備することになる。 ランダムモードで演奏する場合はstepに拘る必要はあまりないのだが、とりあえず音符をバラす方向で考えることにする。

運用試験の結果ニーズがありそうに感じたので、思い切って16StepSeqencerの実装を行った。

あくまでArpeggiatorの拡張機能といった扱いだが、7StepのみだったStep数の選択を7・8・9・10・12・14・16に拡大している。 

全Stepへの対応はアップカウントとランダムのみで、オルタネイトとダウンカウントは7・8・9Stepのみに対応させているが、運用形態に依っては対象を拡大する可能性もあり。

WS001349.JPG

実用性を考慮して、SequencerがChordMemoryから参照するアドレスを使用頻度が少ないと思われる8番から16番をメインに指定して、本来の「コードを記録する」機能との整合性を図った。

スリム化は図ったものの、仕込みが大変で完全な実証試験は明日以降に持ち越すことにした。

何となくだが、Bluesっぽいベースラインが欲しくなって、ブルース進行専用のシーケンスを追加する事を思い付いた。 この場合はベースラインの繰り返しなので、メモリーの再利用が出来る筈。 しかも、bluesのベースラインは結構決め打ち?っぽいので、ルートの決定だけをメモリーでやって、あとはプリセットで問題ないかもしれない、、、。

ということでフレーズを解析したネタ元から、ノートのステップが96にもなってしまった。 

WS001347.JPG

ベースラインはアンテナ入力のピッチを追従せずに、MemoryChannelModeのアドレス1番のVoice01に記録したピッチをルート音に固定して運用する特殊な用法なので、対策を講じた2VoiceMode(赤)の#15を専用アドレスに振っておいた。 

WS001348.JPG

勿論、通常モードでもアサインは可能だが、多分ピッチが滅茶苦茶になるので対策が必要だが、予期せぬ形で妙なエフェクトが掛かる可能性もあるので、暫くは運用を行いながら様子を見ることにする。

追記:

36802317_1929762493720866_3058412427268849664_n.jpg

シャッフルっぽいフレーズの再生を目指したら、288Stepが必要になってしまった、、、。



シャッフルは実質3連符なので、一巡させるのに最低でも12stepが必要だったが、ノリがいまいち。 ノリの再現を考えれば16step以上が望ましいので改変するか。
posted by Yasuski at 04:10| open.Theremin

2018年07月08日

Open.Theremin@デバッグのまとめ

昨日の流れはデバッグ作業が中心だったのでその内容をまとめておく。

まず、記録不能だったアドレスを修正した。これは機能を削っていた部分を復活した際に、別の該当する部分のラインをコピペして、アドレスの修正を多なっていなかったために発生した不具合だった。

Screen Shot 2018-07-08 at 8.53.45.png

次に、用法上の問題で、ついオーヴァーレベルになってしまう波形編集のヴォリューム設定ノブのデータ出力を右シフトして、変化を鈍化させる手当を行った。これは、ロータリーエンコーダーのアクセラレーション機能が過剰に作用する弊害で、微調整が必要な項目には手当を行うべきということで、他のCHのパラメーターにも調整を行っておいた。

Screen Shot 2018-07-08 at 8.55.45.png

バックパネルに追加したMAX5541の接続が怪しいので、ハンダメッキなどの手当を行っておく。

実際に追加機能を利用した演奏方法を探っているが、やはり事前のプリセットが勝負どころというか、波形の選択が全てを決することが解りつつある。これは、プリセットを含めて全容を考え直す必要があるということだが、こればかりは、実際に運用を行った結果をフィードバックするしかない。

所謂楽器とガジェットの境目は、この用法の確立という点に掛かっていると自分は思っているので、機能の開発と同時に実践的な用法の発見を行うことを忘れないようにしていきたい。

追記:

ピッチデータのEEPROMの格納領域を拡大して、リアルタイム処理の負荷を軽減する事を目指した。

今いじっているプログラムは基本構造がTeensy3.2の仕様に準拠していて、限られたEEPROMの容量に合わせて記録するデータを圧縮していたが、その分リアルタイムの処理に負荷が掛かる構造だった。

Screen Shot 2018-07-08 at 8.51.41.png

Teensy3.6はEEPROMの格納領域が2倍もあるため、この処理に掛かるピッチ係数をEEPROMへの記録時に計算して登録してしまえば、その分リアルタイム処理負荷が軽減される筈。

ということで、データ幅をint16_tからfloat64_tに変更して記録を行うように、EEPROM関連のコードを書き換えた。

Screen Shot 2018-07-08 at 8.49.36.png

メモリーが足りなくなった後半部分ではセコく立ちまわっていたようだが、基本的には混乱を避けるために「足りないメモリー状況下であっても、余裕を持たせて大雑把にメモリーアサインを展開」していたことがラッキーだったようで、該当するメモリー領域の拡張はすんなりと行えた。

実験の結果、CodeMemoryMode選択時で感じていた処理の遅れによるザラザラ感が軽減された。
posted by Yasuski at 02:03| AudioElectronics

2018年07月06日

Open.Theremin@ランダムアルペジエーターの実装

昨日実装したMetroを使ったS&Hっぽい仕掛けを眺めていて、これはアルペジエーターに変身させられるのでは?と思いついたので、パターンを登録したデータアレイをロータリーエンコーダーで選択し、アレイをランダムに読み出す機能に改変した。

Screen Shot 2018-07-06 at 7.24.02.png

ランダム係数を音源の数だけ用意して、和音の再生を可能にしている。 ランダム音列(ややこしい)を読み出す場合も専用のランダム係数を用意してあるので、和音がランダムに展開する複雑な効果が得られる。

青色LEDをアサインした音列の選択を行うロータリーエンコーダーは18番目のパラメーターとして下側のノブに追加する。 インターフェイスは試験運用の経験から、デフォルトで水色の波形選択、一つ進めて紫色のtransition設定、一つ戻して青色の音列選択、更に一つ戻してMetroのRate設定といった風に、使用頻度の高いパラメーター群が近接するように仕様を小変更している。

ランダム機能はRateControlの最小値辺りで順送り/逆順送りを切り替えられるよう条件分岐を仕込むと、更に使い勝手が良くなりそうだ。 アップ&ダウンモードのアサインが難しいが、最小値近辺に3ポイントだけ機能を追加するのが正解か、、、。



とか言ってるウチに速攻で作ってしまった。 利便性を考慮して、専用のアルペジオパターンの切り替えノブ(赤)を準備した。 切り替えノブは、0〜3のアドレスを循環して出力する。

まず、アドレス"0"にアサインされているのは、トリガー毎に順送りで0〜6を出力する関数で、

WS001345.JPG

この出力を使って、pitchTableに記録した音列を順番に参照する。

次のアドレス"1"には出力が0〜6を昇り降りする関数がアサインされている。

WS001344.JPG

出力のオーバーフロー時に正負の符号を反転させて、昇降順を切り替えている。

アドレス"2"には"0"とは逆の減算方向にデータが変化する関数を配置した。

WS001346.JPG

そしてアドレス"3"は先に説明した「擬似ランダム値」を発生させる関数が割り振られている。
posted by Yasuski at 08:03| open.Theremin

2018年07月05日

Open.Theremin@基板が届いた&日誌みたいなもの

発注していた基板が到着したので検品を行った。

IMG_8125.JPG

メイン基板にはDAC3関連と光ファイバー送信ユニットを駆動するドライバを新たに追加している。 

IMG_8129.JPG

これで、アナログ出力は3ch体制となった。 なお、このヴァージョンではOverload対応のレベルシフターの実装は未了。

黄基板の裏に配置したVCO。 

IMG_8137.JPG

近接した本体側の2chを使わないための選択肢だが、アンテナ端子の配置を失敗している。 ただ、これをリファレンス源として考えれば問題はない。 回路の修正は、次回発注時に反映される。

多分最終ヴァージョンとなりそうなV3基板。 

IMG_8130.JPG

こちらにも、リファレンス用のオシレーターを実装してあるが、使い物になるかどうかは実験してみないと判らない。

検品後にトップパネルのシェイプの摺合せを行った。 

IMG_8138.JPG

単純な平ヤスリを使った都合数分の作業で形を合わせ込めたのは進歩といえるだろう。

IMG_8139.JPG

メイン基板(緑)は概ね問題無さそう。 VRTはロープロファイルな製品がなかなか手に入らず、安売りしていたメーカー製のこれで折衷することになった。 

IMG_8141.JPG

VRTの実装時にタッパが合わない問題が出てくるが、これはRGBロータリーエンコーダーのシャフトに5mm程度のシムを噛ますことでなんとか対応が可能だった。 懸案だったシャフト穴の位置もギリギリ誤差内で問題なし。

昨日設計した基板の裏面に配置していたアナログスイッチの端子配列を勘違いしていたのでコレを修正したが、またもやグランドパターンの接続がパズル状態に陥ってしまい、手当に1時間ほどが費やされることになった。

otot414e.png 

他の修正箇所として、ADATエンコーダと共通だった5Vアナログ電源ラインにラインフィルタを入れて軽く分離を行った。 また、出来る限りノイズの影響を回避するために、効果は未知数ではあるがアナログ回路の周りにグランドポイントを増設しておいた。、

ここ最近の実験の結果、FrequencyDetectorの動作が不安定に思えたので、FTM0_FILTERの項目を現状の7からFまで引き上げて実験を行ってみた。

WS001343.JPG

早朝なので大音響で実験は出来なかったが、ガサゴソするノイズっぽい不安定さがマシになったようだ。

あと、ロータリーエンコーダーのアドレス送りでゼロ未満の逆順方向でバグの発生を確認したので、これをフィックスしなければならない。 現状でも用法を間違えなければ問題はないレベルだが、演奏時の環境で混乱するのはいただけないので、出来ればフィックスしたいところ。
posted by Yasuski at 08:14| open.Theremin

2018年07月03日

Open.Theremin@OverloadモードとBIAS電圧について

今日は涼しくなった夕方からレベル調整システムの評価を行っていたが、修正したBIAS電圧の影響が思いの外大きく、Overloadモードの持ち味がかなり薄れてしまう弊害が発覚した。

これは、本来ならば間違いであったBIAS電圧をグランド電位に設定するという、アナログ的な手当を知らず知らずに行っていたために発生してた行幸だったが、修正を行った結果これによって得られていた効果が消失してしまった。

間違いであっても効果的な仕掛けは復活させねばならないが、そのために他の機能が犠牲になるのも考えもので、ここはBIAS電圧の切り替えを行う機構を追加するしか無い。

BIASの切り替えにはDPSTが必要で、この機能を持ったMAXIM製のICは確か在庫があるはず。 で、ストックを掘り起こしたところ、MAX4603というアナログスイッチを発掘した。

WS001341.JPG

4個のSPSTで構成されているスイッチはDPSTとして使用出来るように極性の違うものでペアを組まれているが、そのうち、一組は共通端子を設定せず個別にVRTのグランドラインの断続に使用する。 残りの2個はDPSTとして、Overload出力にアサインしているDAC2のBIAS電圧を切り替える。

少々ややっこしい回路の構成となったが、予め20pのICソケットを基板に展開していたことが功を奏して、素子の積み替えはスムーズに進んだ。 ソフトウエア側で、制御信号の極性を反転する必要があったが、概ねスムーズに転換は進んだ。

実験の結果は上々で、元の暴力的なサウンドが帰ってきた。



将来的には、BIAS電圧を可変して音質の変化を確認する機能を搭載する予定。

posted by Yasuski at 21:06| open.Theremin

Open.Theremin@出力レベル調整回路を実装する

アッテネーターのグランド電位を断続することで、ラフにレベル調整を行う機構をバックパネルに追加した。

IMG_8121.JPG

スイッチはMCUから制御信号のラインを完全にアイソレート出来るPhotoMosRelayを使用している。 MCUから送信されたフラグによって、アッテネーターのグランド側のオン/オフを行う仕組み。アッテネーターが介在した分だけ出力インピーダンスが上がることを避けるために、終段にオペアンプを配置した。

新たに追加した部品は、PhotoMosRelay/AQV203 ✕2、OpAmp/OPA2134、多回転トリマVR、3.3V電源IC、若干数の抵抗&コンデンサで、PhotoMosRelayとOpAmpの電源ラインは3.3V/5Vに分離している。

で、回路を組み上げて実験したところ、明らかに音が歪んでいる。

原因はバッファー入力のバイアス設定をグランド電位にした為と思われるが、既に入力する信号が歪んでいるOverload系は問題はなくても本線がこれではダメなので、セオリー通り1/2VCCのバイアスラインに接続し直して、歪の消滅を確認できた。

次に、肝心の音量の自動調整装置の実験に臨んだ。 ひとまず、ラフな減衰レベルを設定して音源の切り替えを行ってみたところ、音量差が激しいプリセットにアクセスしてもいきなり爆音状態に陥ることは無く、まともに音量調整機構が働いているようだ。 また、Overload系のラインに通常レベルの信号をアサインした時にアッテネーターをオフる回路だが、該当するプリセットにアクセスした場合に音量差が生じることは無く、正常に動作していた。

オプション扱いのDAC3用にも予備のバッファー回路をリザーブしておいた。 いまのところアッテネーターと出力コンデンサを実装してはいないが、レベル調整が必要になったら即応できる状態にしてある。

大改装前に接続ラインの確認と、部品の仮配置を行っているところ。

IMG_8120.JPG
posted by Yasuski at 07:50| open.Theremin