2018年07月14日

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