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