2019年07月12日

部品の実装を始める

チューニング・システム周りの操作性の向上を目指して、チューニング・ノブで操作出来る周波数の帯域を制限することを考えている。 

VRノブをサブチューナー扱いとしてノブの可動領域を1/9以下に制限しつつ、メインのチューニングをパネルマウントタイプの半固定抵抗で行う方式だ。

F2770228-01.jpg

このタイプのVRTでパネルマウントタイプのものが存在することを知らなかったのだが、

F7904221-01.jpg

VRTとVRポットと組み合わせても、マルチ・ターンタイプのVRポットを導入するより安上がりになるところが良い。

IMG_9247.JPG

組み上げたチューニングシステムは、ケースの側面に取付けることになるだろう。

IMG_9248.JPG

VRTの間には、ファームウエアを書き換えるためのUSB端子を挟んでいる。

IMG_9249.JPG

裸のVRTより操作性が向上するのも良いポイントだ。

IMG_9260.JPG

一方、新たに設計した赤いMCU基板の実装を開始している。

IMG_9261.JPG

基板は2種類で、80mm幅のOSC基板にスタックするタイプと、、、

IMG_9262.JPG

コンパクトな筐体に対応させた75mmサイズの基板を用意した。

IMG_9268.JPG

新たに購入したマルチターンVRポットのサイズが想像よりも大きかったので、これを機会に3種類のVRポットのサイズを比較することにした。

IMG_9269.JPG

SAKAE製は奥行きがあるために、ID-292への導入は不可能だった。 ID-292にはCopal製の13φと10φサイズのVRポットで対応することになる。

IMG_9270.JPG

SAKAE製のVRポットはHammond製ケースで使用することになる。
posted by Yasuski at 15:50| LaVoixski

2019年07月10日

アルミ製アンテナの製作

真鍮製で重いアンテナを改良するため、アルミ材を使った新しいアンテナを試作している。

IMG_9239.JPG

真鍮と比べて曲げ加工の難易度は下がったが、曲がり過ぎるのが問題。

IMG_9245.JPG

エクステンションの末端には、10mm径のアルミスペーサーにインチサイズのネジを切ったものを挿入しているが、エクステンション用のパイプの内径9mmに合わせて加工がを行う必要がある。

IMG_9242.JPG

スペーサーの外周を削った後にトンカチでガンガン圧入するのだが、作業は結構大変。

IMG_9244.JPG

試験運用で判明したのはTNCが意外と脆弱だったことで、特にストレートアンテナのアングル付きの基台にはSMA端子をハンダで強化したものを使ったほうが良いかもしれない。

IMG_9276.JPG

GFRP棒のアンテナ基台に孔を開ける際に使用するジグには、内径がGFRP棒とほぼ一致するアルミ・パイプを使用している。 当初はパイプ側に加工を行わず作業していたが、パイプの側面にスリットを入れることで、素材の取り外しを容易に行えるようになった。
posted by Yasuski at 19:33| LaVoixski

電源IC周りのリファインを行う

ID-292で連発した電源周りの事故に対応した基盤が届いた。

IMG_9229.JPG

今回、OSC系を緑、MCU系を赤、オーディオ系を黄に基板のカラーを設定している。

IMG_9203.JPG

電源部の改良は、放熱が厳しいID-292専用基板に帰還ダイオードの追加を行った他、

IMG_9210.JPG

レギュレーターICの放熱効率を改善する目的で大口径のスルーホールを設置し、基板裏側との熱結合を促進している。

IMG_9211.JPG
posted by Yasuski at 19:20| LaVoixski

2019年06月19日

microSDへの書き込みルーティンの修正

怪しげな重複動作が気になっていたmicroSDへのデータ書き込みルーティンの修正を行った。 

WS001904.JPG

処理をよりスムーズな流れで行うには、条件分岐の総当りを避けて、分岐先のサブルーティンを目的毎に細分化する他、switch(x){case n: brake;}を使用して余分な条件判定をスキップさせる方法が考えられる。

まず、LEDの点滅表示を行うサブルーティンを対象となる上下のLED毎に分離した後、無駄な条件判定を取り除いた。

WS001907.JPG

次に、パラメーターを選別する条件分岐をスイッチが長押しされた段階で実行しつつ、

WS001905.JPG

対応するパラメーター毎にサブルーチンを分離し、各々がシンプルな処理を行う形にコードを改変している。

WS001906.JPG
posted by Yasuski at 10:58| LaVoixski

2019年06月16日

Exciterに倍音生成関数を追加する

今朝は、ExciterモードでTransferを行う際に参照する倍音生成パラメーターに6/7/8次倍音の計算を行う関数を追加し、

WS001897.JPG

プリセット・パラメーターの生成時に参照する倍音構成をメモリーch毎に組み替える作業を行っていたが、

WS001898.JPG

コンパイルは通るものの、起動時のチェックポイント#6で何故か起動が停止してしまう案件が発生してしまった。

チェックポイント#7はデータ容量の多いWavetableの読み込みを完了したフラグなので、ここに至らない原因はフリーなメモリーの不足が考えられる。

WS001899.JPG

オプティマイズにLTOを選択して実験してみると、RAMの使用量が95%に増える一方、チェックポイント#3で起動が停止することから、RAMの使用限界を超えたことが不具合発生の原因とほぼ確定した。

いろいろと試行錯誤した結果、コンパイル時のオプティマイザーの選択によって、動作の可否が決定されることが判っているが、プログラム・メモリーの使用量を減らすことで、RAMの使用量をダイエットできる可能性を思いついた。

そういえば、高速化を論じたフォーラムでもこの手法が奨励されていたことを思い出し、ダメ元でSmallest Code with LTOを選択した結果、RAMの使用量が93%に減少して正常な起動を確認できた。

WS001896.JPG

「Arduinoのオプティマイザは挙動が読めない」とForumでは皆が同意しているのだが、プログラムの最小化がスピードアップに繋がる場合があることを今回の作業で実感させられた。

実際、オーディオクロックを96kHzに上げても動作に支障はなく、明らかに処理スピードが向上している。 

よって、現行システムに対応するオプティマイザとして Smallest Code with LTO の選択が最適解となった。
posted by Yasuski at 06:42| LaVoixski

2019年06月12日

Exciter周りの改装を行う

使い勝手が悪かったExciterの編集機能を多少はマシに扱えそうな構造に改良した。

WS001890.JPG

今までは、円環するパラメーターとは別のパラメーターを呼び出して記録を行う仕様で、インターフェイスの配置関係がややこしく、直感から外れた操作を強いられていた。

今回はこの外れた場所にある記録スイッチをパラメーターの円環の中に組み込む作業を行っていたのだが、

WS001887.JPG

ページ毎にシーンメモリーを仕込もうと企んだ所為で、これが凄まじく手間のかかる作業となってしまった。

WS001888.JPG

新たに追加した3ch分の記録・波形選択兼用インターフェイスは、倍音選択ルーティンの最後尾に設置している。 LEDの色味にはSky/Violet/Orangeの3種類を充てた。

WS001886.JPG

今回は、記録が可能なFrequencyTransferのチャンネルを3chまで増やせたので、ソロ音源に対する音色の加工機能が強化された。

WS001893.JPG

ほぼ、全モードでシーンメモリーが可能となっているが、

WS001889.JPG

あまりにややこしい構造なので、何処かにバグが潜んでいる可能性は否定出来ない。
posted by Yasuski at 07:19| LaVoixski

2019年06月11日

MuteSwitch使用時に発生していたポップノイズの除去を行う

MuteSwitchでEnvelopeのモードを切替える際に発生していたポップノイズを除去するためにEGを使用することを思い付いた。

WS001868.JPG

今まで音声レベルの設定を1/0で固定していた部分に、Chronoで制御されたEGを追加している。

WS001869.JPG

Mode切替えのサブルーチンでは音声出力値を直接扱わず、EGをコントロールするフラグを操作している。

フェードのスピードが若干遅い感があるので、今後の運用で最適値を探っていく。
posted by Yasuski at 04:51| LaVoixski

2019年06月10日

チューニング・モードを新設する

オシレーターのチューニングを行う過程で、「キャリブレーション」という言葉がどうにもミスマッチで、誤解が生じる原因となっているようだ。 

この機会に、楽器を新規に導入する際の最初のハードルとなり得るこのモードの在り方を今一度考え直すことにした。

現状はスイッチを長押しする毎に

1:Pitchオシレーターの素の音
2:Volumeオシレーターの素の音
3:Aにあたるピッチの確認

と、モードが変遷する。

次のスイッチ短押しで

4:通常モード

に復帰する。

実装された機能を正確に表現すると、Pitch/Volume双方の素の音を拾うモードは、行為の実態を表して ”Monitoring the real Frequency” 等といった文言に改定すべきだろう。

一方、3番めに設定されているAピッチをモニターするモードだが、現状はあくまでも確認を行うだけのモードで、パラメーターを設定することが出来ない。 

そこで、ここに、Sequencerのルート音が設定出来る機構を組み込むことにしたのだが、既存のパラメーターは44.1kHzのサンプリングレートに対応させた数値に固定されているので、サンプリングレートを切り替えた場合に、当然ながらピッチが変化してしまう。 楽器をスタンドアロンで使用する場合にはある程度の誤魔化しが効きそうだが、他の楽器と絡むことを考えるとチューニングの機能は必須となってくる。 

以上の考察から、「キャリブレーション・モード」という呼称を「チューニング・モード」に改称することにした。

今回の改修では、先に解説した目玉スイッチの長押しで起動するサブルーチン3番めの長押しで選択されるモードに、Sequencerのルート音のチューニング機構を追加している。 

WS001866.JPG

対応するノブは上側の緑で、C1(仮称)の値を調整する。 

要は”ド”に合わせれば良いのだが、わざわざ業界標準な”A”にしなかった理由は、SequencerのC#SVのC0から始まるピッチ配分の仕様を優先した結果による。
posted by Yasuski at 21:01| LaVoixski

Envelopeの選択メソッド

ChoppingArpeggiatorの分岐処理を、総当りを強いられるif構文から、対象を選別後にバッサリとbrakeするswitch構文に切替えて処理時間の短縮を図ってみたが、効果はイマイチだった模様。

WS001862.JPG

条件分岐にOR(||)を使うと、処理に時間を取られることが実証されているが、これをswitchに書き換えると、記述が冗長になる一方、総当りで参照しない分だけ処理の行程が単純化される。

オプティマイズをFastestに変更した場合、コンパイル時間が1/4以下になったが、動作の違いは全く感じなかった。

WS001863.JPG

期待していた割にリザルトはイマイチどころか、96kHzのオーディオクロックを選択した場合には、ChoppingArpeggiatorが動作不能に陥っている。

Fastest + LTO + PureCodeに設定を変えて比較実験を行ったが、結果はFastest + LTOの勝ち。 Fastest + LTO + Purecord はメモリーの使用量が増えるうえに、劇的に処理が遅くなって96kHzでの運用が全く行えず、この選択肢は論外だった。

void の前に FASTRUN を記述すると若干のスピードアップが望めるということだったが、大容量のキャッシュを持つTeensy3.6ではほぼ効果は無かった模様。

結局、オプティマイゼーションのリザルトは Fastest + LTO が最速で、96kHz運用のベンチマークを難なくこなせた。 データの使用量はFastestよりも若干増えるようだ。

WS001864.JPG

Fastest + Purecord は未だ試していないが、過去の経験からあまり御利益があるようには思えず。 暇な時に実験を行ってみるか。

Pitchのオフセット固定に関しては、今のところ破綻は発生していない。
posted by Yasuski at 01:49| LaVoixski

2019年06月09日

周辺機器について・他

ミニプラグの変換ユニットを作った。

IMG_9192.JPG

あと、Hirose6p版が必ず必要になるが、こちらは電源入力とセットになるので、サイズは1590B辺りが妥当か。 

トランスの内装はサービス上の問題が生じるので、外部電源を使うのは規定事項だが、海外の場合220Vのアナログトランスの調達が難しく、この手の製品を組み合わせることになる。

ifi_audio_0306007_9v_ipower_9v_for_usb_1472146516_1275642.jpg
posted by Yasuski at 18:32| LaVoixski