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