SDカードにデータをトランスファーする方法（その３）

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

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

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

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

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

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



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

SDカードにデータをトランスファーする方法（その２）

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

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

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



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



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



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



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



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

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倍に拡大する手段を思い付いて、問題は解決した。



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



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

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

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

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

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



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

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



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

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



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

Open.Theremin＠実験用モデルがほぼ完成する

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

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

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

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





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



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



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

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

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

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



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



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



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





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

Open.Theremin＠DigitalSequencerの実装

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

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

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



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

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

あくまでArpeggiatorの拡張機能といった扱いだが、7StepのみだったStep数の選択を７・８・９・１０・１２・１４・１６に拡大している。　

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



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

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

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

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



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



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

追記：



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



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

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

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

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



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



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

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

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

追記：

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

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



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

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



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

実験の結果、CodeMemoryMode選択時で感じていた処理の遅れによるザラザラ感が軽減された。

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

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



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

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

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



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

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



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

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



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

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



そしてアドレス"3"は先に説明した「擬似ランダム値」を発生させる関数が割り振られている。

Open.Theremin＠基板が届いた＆日誌みたいなもの

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



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



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

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



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

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



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

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



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



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



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

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

　

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

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



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

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