2018年07月27日

LEMOの8pコネクターをアンプに取り付ける

数年ぶりに行うライヴ演奏からのフィードバック。 

IMG_8294.JPG

なかなかやる気が出なかったのを思い切ったのが運の尽きで、丸一日がこの作業に費やされることになった。

IMG_8279.JPG

嵩張るスピコンを排除するために、フォン端子を使ったスピーカーケーブルをアンプに増設しようとしたが、丁度よいサイズの取り付け穴を開けられず、作業が長引いてしまった。 スピコン端子には2ch分の信号線を仕込んでいるので、サテライトスピーカーを一個プラスする情況ではこちらを使用する。

IMG_8283.JPG

製作するスピーカー用のケーブルは10m。スピコンのケーブルは6m程だったので、長さが足りずに現場で微妙な状況に陥ることが多かったが、これでキャパの広い場所でもある程度は対応できるはず。

作業の過程で電源が短絡するトラブルが発生したが、原因はなんとebayで購入したLEMO製の8pケーブルそのものにあった。

IMG_8288.JPG

よく見るとなんだか変な構成のケーブル=所謂変態仕様なブツだったことが判明。

IMG_8289.JPG

その内実は、単線×3本とシールド線2組、それとグランドラインで合計8端子という、なんだかよく解らない構成の代物。

IMG_8290.JPG

このシールド線のグランドが短絡の原因だった。

IMG_8291.JPG

代わりに在庫していたジャンクの12芯シールドを使ってコネクターを改造した。

IMG_8292.JPG

パワーアンプ系の配線など大電流が流れるラインには2芯を撚ってそれに充てている。

LEMOのデザインはNeutrikとはまた違った雰囲気を持つ。

IMG_8275.JPG

サテライト化した4chデジタル・パワーアンプ&#1chスピーカーユニット。

IMG_8270.JPG

オーディオ的には、滅茶苦茶な設計である。

IMG_8267.JPG

これは本体っぽく見える電源部。

IMG_8285.JPG

日付が変わる前に、なんとか音を出す事ができた。

IMG_8286.JPG
posted by Yasuski at 02:56| AudioElectronics

2018年07月25日

Open.Theremin@アルペジエーターにオン・オフスイッチを追加する

やはりこれがあるのと無いのとでは使い勝手に雲泥の差があった。

パターン読み込み後にアルペジエーターをオフった場合はその和音構成のままフリーズするので、テキストベースで編集できる和音のチャンネルと思ってもよいだろう。
posted by Yasuski at 13:52| AudioElectronics

2018年07月23日

Open.Theremin@デジタルフィルターの復活

電池切れ対策を兼ねてAC駆動の多チャンネルアンプで演奏してみたら、コレが存外気持ちの良いものであった。



ただし、ここまで至るのには紆余曲折があって、当初は低域部のノイズが酷過ぎて、運用出来る状態ではなかった。

今回再確認したのは、このテルミンは通常のテルミンが周波数を扱うのとは逆の方向でセンシングを行っていることで、アンテナに手を近づけるほどゼロビートに近づいていく。 システム上の最低域の設定は、FTMカウンター上で測定可能限界の高い周波数を意味する。

このテルミンの妙な扱いにくさはここに原因があったわけだが、オシレーターの実験を行っていた段階で、ペアのうちどちらをリファレンスとして扱うかを選択する過程で、センシングの方向性が決定されていたことを失念していた。 現状行っているセンシングのベクトルを変更し、通常のテルミンと同じ方向でデータを扱えないかソフトウエア上でトライしてみたが、現時点でその試みは上手くいっていない。

低域が荒れるのは当たり前で、高い周波数のセンシングエラーがそのままノイズの発生につながっていた。センシングエリアのダイナミックレンジを狭めても、音域が狭まるだけであまり効果はなかった。 この問題を解決するには、やはりデータにフィルターを掛けるしか無い。

ということで、デジタルフィルターが復活した。使い様を間違えなければこれはかなり有効なノイズ排除の手段となった。

Screen Shot 2018-07-23 at 11.59.22.png

Screen Shot 2018-07-23 at 12.00.31.png

あとは、Arpeggiatorのポリフォニック化を行った。 これ以上タスクを増やしてどうするんだとも思ったが、とりあえず動作上の問題はあまり無さそう。

追記:

やはり、Pitchサイドの低域側が不安定なのが問題に感じたので、Pitchアンテナの接続をD-FFのデータ側接続されたオシレーターに変更した。これに伴い、調整用に取り付けていた66pFのコンデンサーをアンテナと同時に移設している。

ヴォリューム側は現状で安定しているので、回路はこのままにしておく。 D-FFのクロックで入力をクロップする構造は、DINがアンテナ、CLKがリファレンスとするのがオリジナルの回路だが、Volume側ではこれを入れ替えることで、アンテナに近接するポジションをゼロビート側に設定することが出来る。データが荒れないゼロビート側は、微妙な音量コントロールが必要な立ち上がり時の挙動を安定させる働きがあるので、今後はこの設定で回路を構成する。

追記2:

実際に楽器の運用を行って感触を試しているが、音のアラがよく見えるアンプはこの段階で重宝する。 電池駆動の弾薬箱アンプもJBLのカーステ用スピーカーを積んだ新版だったので、こちらもアラが見えるタイプのアンプだったが、AC駆動のアンプにはボロン製のコーンを持つスピーカーが積まれている。 これを鳴らすことで、今までに見えなかった問題点が浮き彫りになってきた。

低音域が不安定で音がフラフラする症状は、センシング時に取り込むデータの「ヒゲ」が原因と思われるが、ディテクターに細工を施した後も、程度の差こそあれ気持ちの悪い操作感はあまり改善されない。

ビットシフトでデータのLSBを削る方法がこの状態に対処する一番単純な方法だが、これをやってしまうとデータのレンジが狭まるために楽器の音域が狭くなってしまう。 Tootsの口笛のシミュレートがしたいのでこれは困る。

解決法として、結局は廃止していたデジタル方式の帰還型LPFを復活させるのだが、前回の作業でこれをディテクターの後のチューナー部に仕込んでみたところ、相応の効果は確認できた。

が、どうしても気になるレベルのフラフラが残ってしまう。 やはり、ゴミデータの元を断つには、ディテクターとして使っているFTMから差分データを取り込むその場所にフィルターを噛ますしかなさそうだ。

ディテクターは、PC_STATE1 / PC_STATE2 に入力されたオシレーターからのパルス5カウントを1ユニットとして、入力されたパルスの立ち上がる間隔を測り、その差分をデータとして出力している。 まずはこの差分出力にフィルターを掛けて、出来る限りデータの不連続ポイント=ヒゲを減らす。

データの中心値を設定するポイントでは、5カウント毎に地均しされたデータが送られてくるが、ここでさらにフィルターを掛けて異常値を取り除いている。

この作業は一度に行ったほうが良さそうだが、多段フィルター的な考え方で異なる係数を掛けるのが目的。最適値はまだ判明していないので、これから演奏に差し障りの無い範囲で、ヒゲを無くす方向にチューンを行っていくことになる。
posted by Yasuski at 19:17| open.Theremin

Open.Theremin@試験環境をAC駆動のアンプに移す。

結局、E-Kora用に作ったアンプで実験を継続することにしたが、アンプ&スピーカーによって、見えてくるアラが違うのが良く判った。 3chとはいえ妙なパンポット効果を確認できたので、これから面白そうな音源配置を考えていくつもり。 まずは、シーケンサのCHをここに割り振っておいたが、これが意外といける感触だった。

実験でサンプリングレートを変えてみたが、やはり32kはチューニングのレンジが狭まるので、ソフトウエア側の対処無しでの導入はアウトっぽい。 48kは意識されるような問題は無かった。 96kもチューニングのレンジが滅茶苦茶になるので、こちらも設定をこれに合わせないと使えない。

低域の不安定さが再発しているのは、過剰に機能を盛り込んだ影響なのか? そろそろ、ロジアナを使って処理ループの観測を行うべきだろう。
posted by Yasuski at 06:10| open.Theremin

2018年07月22日

Open.Theremin@バッテリードライヴ化を真面目に考える

テルミンのバッテリードライヴ化を考えた場合に、高価なHiroseのコネクターを1ペア使用するだけで6k以上が吹っ飛ぶことが大問題で、これを解消する方法を考えていたのだが、モバイルバッテリーをそのまま使用するのがお手軽なことに気付いた。

問題は接続端子で、丁度良いサイズの製品が見つけられない。ひとまずは、パネルマウントのMicroUSBポートを試してみることにするが、フットプリントが大きめなのが気に入らない。

あとは、電源周りとの整合性をどうやって確保するか。 データインプットと共用する場合に、パソコン側の電源容量に影響が出ないか問題だが、最大消費電力はMCUなので、これは大丈夫かもしれない。

音声アウトをLEMOに、、、とか要らんことを考えてしまったが、これも6kを余裕で超えるので、現実味はない。 普通のステレオミニジャックがベストで、足りない分は増設すれば良い。

電源供給口の位置を何処にするか、判断が難しい。 諸々の条件を試作機で試すことになるが、現実的には実験機のボディーサイズがバランスが取れていて扱い易い気がしている。

それにしても、ミニジャック形状のパネルマウント型USB端子がこの世に存在しないのが不思議なんだが、よく探せば見つかるのだろうか???

ということで、自作を考えることにした。 多分この方法が正解の一つと思われる。

IMG_8261.JPG

音声端子はこの製品と組み合わせる。

TTRSbreakout.jpg

シャシはいつものNeutrikを使用するとして、材料費は合わせて0.7kから0.8k程になるか。

WS001384.JPG

電源供給用のmicroUSBケーブルとスリムな3.5mm規格の音声ケーブルで、スッキリと配線が行える。バッテリーと音声系が別接続なので、自己が発生する確立は低い。 なにより、既成品のモバイルバッテリーをそのままで使えるところが便利だ。

ID-292版の場合はあのデザインが最優先されるので、Hirose製コネクターはそのまま使用することになると思う。
posted by Yasuski at 09:35| open.Theremin

Open.Theremin@オシレーターのチューニング

この日も朝方からコーディングをやっていて、ついでにケースの加工を始めて気がついたら夕方というかなり感覚が飛んでしまう一日だったが、更に夕方からは楽器を完全にバラして端子の配線を始めてしまい、晩飯も食わずに日付が変わっていた。

ケースの加工後に実験を行ったところ、トリマによるオシレーター周波数の修正が可能な限界点を超えそうな状態に陥って仕舞った。 どうもスイッチ類の実装が影響してオシレーターのチューニングレンジが低い方に移動した結果のようだ。 このままでは楽器としての運用が不可能になるので、余り気が進まなかった全バラシを強行しオシレーターの再チューニングを行うことになった。

今回は以前から気になっていたアンテナ側のオシレーターの周波数を変更したかったのだが、これがなかなか上手く行かず、前回の作業と同様にリファレンス側を調整することになった。 対応方法としては、グランドに接続している220pfをさらに小さな値に交換する必要があるが、丁度使えそうな値のパーツが手持ちになかったので、実験は未了。 現在、Pitch側のオシレーターは480kHz辺りにチューニングされているが、Volume側が450kHz近辺に居るために、周波数のマージンが心配になってくる。

過去に追加したリファレンス側のコンデンサを取り除き、新たに33pf×2を並列に接続して作業は終了した。 ひとまず、Pitch側オシレーターの周波数はVRTの調整レンジ内に落ち着いた。 

その後、運用試験を始めたところ、何故かシステムが落ちて再起動が頻発する案件が発生しだした。

電池の減り具合の影響を予想しつつ調査を行ったところ、サンプリングレートの設定を行うつもりで増設した、デジタルスイッチのコモン端子をグランドに落とすのを忘れていたことが原因のようだ。 つまり、PLLの周波数設定端子がフルでオープンの時の設定、96kHzという無理な仕様で音を出していたことになる。 当初はまともに音が出ているので気付かなかったが、全体のタスクを減らせば96kHzによる運用が可能なのが証明されたということでもある。

今後は気軽にサンプリングレートを32kHzにダウンする実験が行える。 明日は楽器専用電源を製作して、楽器の挙動を確かめよう。
posted by Yasuski at 05:31| open.Theremin

2018年07月21日

Open.Theremin@実験用筐体にモメンタリスイッチとデジタルスイッチを増設する

昨日のアップデートからSequencerが不調で何をやっても修正が行えない。 理由が判らず原因を探っていたところ、ファイル書き換え時にファイル名を微妙に間違えていたという凡ミスが発覚した。 これを探るのに小一時間は掛けていたのは暑さの所為だと思いたい。

で、Sequencerの動作をコントロールするのに良さ気なインターフェイスはないものかと調査していたところ、ボタンスイッチの便利なスケッチを発見。これはトリプルクリックと長押しに対応しているので、スイッチひとつで結構なタスクをこなせそうだ。

ということで、コードに機能を実装する前準備として、ハードウエア=現物の取り付けを行った。

IMG_8257.JPG

完成している楽器に横孔を2箇所空けるのは結構勇気要るのだが、完全にバラすのもアレなのでチタン板の装甲板を挿入して作業を行った。 

今回取り付けるパーツは、白色LEDの照光付きモメンタリ・スイッチと、4bitのデジタルスイッチ。デジタルスイッチは、サンプリングレートの変更等ハードウエア側の設定を直接行うために使用する。

途中、ドリルが噛んで楽器がぶん回される事故が起こったが、何とか無事作業を終えることが出来た。

IMG_8255.JPG

問題は、デジタルスイッチに取り付けるノブだが、カラー付きのライテルが現在欠品中なのがツライ。で、ジャンクを漁っていたら、一寸大きめだがシェイプが綺麗な地雷探知機のモード切替スイッチについていた面白い形のノブを発見し、コレを取り付けることにした。

IMG_8256.JPG

取り付けたパーツの端子はテフロン線で引き出して、とりあえずバックパネルに新設した中継ソケットに接続している。

IMG_8259.JPG

次は、コード側に機能を実装する番である。
posted by Yasuski at 17:11| AudioElectronics

基板デザインの変遷・失敗の記録

上の段はMCU変換基板というコンセプトで設計をスタートした。 

IMG_8254.JPG

最初に汎用性を重視したのが間違いで、(赤基板)その点に関連して色々と齟齬が出てきた反省がある。

http://audiohologram.sblo.jp/article/179140747.html

http://audiohologram.sblo.jp/article/179233996.html

この基盤群には規格を合わせる対象が存在するのだが、対象先の仕様変更に追いつけずに、使い難いものになったのが白基板だった。また、色の濃い基板は塗膜が厚く、SMDの実装に向かないことも判った。

http://audiohologram.sblo.jp/article/181087905.html

緑は2枚あって、1枚目は分圧抵抗の配線を失敗、2枚目は分圧抵抗の配線を修正しているが、1枚目でDAC用BIASのRoutingを忘れるという大失敗を察知できずに、2代続けて同じ間違いをやらかしている。

黄色いのはほぼ完成品で、多分このヴァージョンで更新はしない。

下の段はオリジナルのテルミンの基板だが、最初のヴァージョン(青)はadatへのこだわりがあって、Toslinkの基板上への実装を可能としていたた。ただ、AudioDACの選択を間違えたり、高価なチューニング用のDACが必要だったり、電源が容量不足だったり、、、とあまりに欠点が多い設計で、二代目の青基板で修正を行うことになった。

http://audiohologram.sblo.jp/article/179302990.html

http://audiohologram.sblo.jp/article/179650224.html

http://audiohologram.sblo.jp/article/179860956.html

が、2枚目はレベルシフトICの電源端子の極性を間違えるという大ポカをやってしまい、早々に三代目(緑)にバトンタッチすることになった。

http://audiohologram.sblo.jp/article/181037499.html

3枚目(緑)はLC方式とVari-Cap方式の2種類のチューニングシステムが混在する実験機だが、温度ドリフトの特性差や、調整の煩雑さを考えるとLCに拘る(しかも、Cは異常に高価な代物)意義が薄れてしまったうえに、adatの使用に現実味が薄れる過程で、予備のDACを実装したいという思惑は次の設計に反映される。

http://audiohologram.sblo.jp/article/183121123.html

4枚目(緑)はDACを2機搭載した拡張ヴァージョンだが、ここにきてオシレーターの配線ミスが発覚してしまう。

http://audiohologram.sblo.jp/article/183268999.html

そして5枚目(緑)では3機目のDACの搭載と、通信用光ケーブルの運用を可能にしているが、基板の発注の後にアナログ信号のレベルシフター機能が実用化された。

http://audiohologram.sblo.jp/article/183710547.html

http://audiohologram.sblo.jp/article/183718047.html

次のヴァージョンでその機能を盛り込む予定。 今回のは大きめな改変なので、次のヴァージョンは色を黄色か赤に変えてみることにする。
posted by Yasuski at 10:20| open.Theremin

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